用于代码审查的 DSH 插件

审查类插件的目标是让智能体成为更好的审查者：建立预期架构的基线、检查变更是否偏离基线、在宣称成功前要求证据，并在 diff 上总结风险。它们不能替代合并决策上的人，但能让第一轮更难被糊弄。

优先选择会产出可审查产物的插件——书面报告、失败的检查、审批提示——而不是只断言「代码看起来没问题」的插件。无法失败的审查不是审查。本类目最强的条目把「完成」当成需要证据的主张，而不是模型有权说出口的一句话。

怎么评估

看三个机制。基线：插件是否记录了变更前系统本该长什么样？漂移：在你重读整棵树之前，它能否展示偏离？门槛：任务被标记完成前，是否必须附上检查、测试结果或人工批准？

还要看范围。只给模型自己的摘要打分的审查层是表演。会读 diff、失败测试或架构图的，才更接近工作。任务板与多智能体编排常与这一场景相邻：工作真并行时有帮助，单文件修复时只是仪式。

什么样算好

强的审查插件会说清测了什么。它点名对比过的契约或架构节点。缺证据时拒绝盖章。它留下你以后还能打开的持久记录，而不是会被滚走的聊天消息。本目录里重叠的条目，优先选能展示失败路径的那一个。「agent 说它审过了」不是控制手段。

常见失败

常见失败是绿色徽章由写改动的同一个模型自己驱动。第二种是基线从不更新，之后每个 diff 都像漂移。第三种是只审最后一条消息而不是工作区——模型对编辑的叙述，而不是编辑本身。

安装顺序与边界

代码审查插件优先于又一个全能 agent 包。先让 diff 与建议可审查，再谈自动提交。无门的自动修复会在你不在时改仓库。