批注类插件的日常用法与三条边界
工具装好之后真正的问题才开始：什么场合该用它，什么场合用了反而更慢。选中批注（dsh-annotation）的能力面很窄——把一段文字圈出来，附一句话，跟着提问一起发出去。窄有窄的好处，它容易被嵌进已有的工作习惯里；也有代价，超出纯文本的范围就完全帮不上忙。下面按四个日常位置说用法，再把三条边界讲清楚。
位置一：代码走查
看一段模型给出的实现，通常不是全错，而是某几行有问题。这时候圈住那几行、写「这里的错误分支没处理空数组」，比在消息里贴一段代码再解释要省一半字。若宿主在 0.1.6-alpha.1 以上，还能在工作区文件预览里直接圈，引用会自动带上文件路径，模型不需要猜是哪个文件。
位置二：需求复述
把一段需求丢给模型让它复述，然后逐句核对。凡是复述得含糊的地方，圈住那句问「这里你理解成什么」。这类核对的关键是覆盖面，不是深度，能一次圈五六处最有效率——批注支持跨回合累积，编号从 1 递增，输入框旁边有「批注 ×N」标签，攒够了统一回车发出。
位置三：文档校对
Markdown 或纯文本的稿子，问题多是措辞而非结构。圈住一句、批注留空、只做标记，等于告诉模型「这几句我要改，你先看看」。留空这个设计在校对里特别顺手：你还没想好怎么改，但已经确定这几处要动，先标下来，等整篇过完再一次性提要求。
位置四：多轮追问
第三轮之后，上下文里已经堆了很多内容，模型容易把「刚才那个方案」和「更早那个方案」混起来。此时圈住它上一轮的结论再追问，等于给它一个明确的锚点。回复会按「Annotation 1：…」逐条对照，每个标签都能悬浮回看当时圈的是哪段原文，翻旧对话时不用靠记忆对齐。
用法上的两个小习惯
一是攒批而不是碎问。一轮圈三到六处最舒服，太多会让回复变得像清单，太少又不如直接说。二是先圈后写：先把要指的地方标出来，再组织提问的措辞，思路会清楚得多，因为待指认的对象已经摆在眼前。
还有一处体验细节值得提：自己的消息气泡里不会出现批注块，只留提问和「批注 ×N」标签，悬浮才展开，而且是在绘制之前就隐藏，不会闪一下再消失。翻历史记录时，这决定了满屏是干净的对话还是堆满引用块。
边界一：只覆盖纯文本
模型给出的回复、工作区文件里的纯文本、Markdown、代码都在范围内；PDF、图片、iframe 内 HTML 不在。选中它们不会有任何反应，这不是配置问题，是能力范围问题。手上的材料若是扫描件或网页截图，只能先把要点摘成 Markdown 再走这套流程。
边界二：浏览器侧实现，不产出服务端能力
它是官方 bundle 插件，经 client-modules 注入浏览器端，Node half 是空实现。这句话的实际含义是：没有后端存储、没有账号体系、没有归档接口。批注活在你当前这台机器的浏览器状态里，换设备不会同步，清掉浏览器数据也不会留下副本。把它当「会话内的临时记号」是准确的，当「评审记录系统」就错位了。
边界三：静态扫描不等于安全结论
本站的扫描结论是「未发现敏感能力」——最多发网络请求、读自身元数据或只读文件，扫描于 2026 年 10 月 25 日，范围为入口闭包加全包扫描，来源是 npm 发布包。这个结论有明确的前置条件：它是静态扫描，站点同时标注了尚无人工评估。所以对外的说法只能是「当前扫描未发现敏感能力」，不能写成「已确认安全」，更不能拿它去填合规表格。
这三条边界怎么落到决策上
如果团队的评审材料主要是 PDF 与设计稿，这个插件帮不上，别指望它覆盖全流程；如果流程里需要留下可检索、可交接的评审记录，得另配一套归档，插件只负责会话内指认；如果安全评审是硬门槛，那么「尚无人工评估」这几个字就是当前状态的准确描述，把它当成待办而不是结论。
总结
它的合理定位是会话内的指认工具：在代码走查、需求复述、文档校对、多轮追问四个位置替掉「重新描述一遍」的动作，边界之外交给别的工具；想对照同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：以纯文本为主要材料的评审与校对；需要在一轮里指出多处问题、又不愿把气泡塞满引用的人；多轮之后容易「方案混淆」的长对话；团队里已经有归档系统、只缺会话内指认环节的场景。
不适合：材料以 PDF、图片、内嵌网页为主的团队；需要跨设备同步或把批注当资产留存的人；把安全扫描结论当合规背书、要对外承诺「已确认安全」的场景。
标签：选中批注、DeepSeek Harness、最佳实践
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
