3.2 dsh-code-review：评审清单长什么样

它是什么

dsh-code-review 的官方描述很短：在 deepseek-harness 仓库评审 pull request 时使用。

正文约 10577 字节，是一份完整的 PR 评审规程。它的价值不在“评审代码”这个动作，而在于把评审拆成了可逐项核对的清单。

它同样住在 .agents/skills/ 目录，走 project-agents 发现层（rank 200）。团队把自己仓库的评审标准固化成技能，等于给每个队友、每个模型会话发同一本操作规程——新人拿到仓库第一天，评审就有据可依。

为什么需要技能化的评审

人工评审最大的问题是标准漂移。同一个人、同一份代码，两次评审给出不同结论，比评审缺席更伤——作者会失去对反馈的信任，最后把所有评审意见都当成“参考参考”。

漂移表现 后果
今天严、明天松 同一份代码两次结论不同，作者无所适从
对熟人松、对陌生人严 标准跟着关系走，不跟着代码走
疲劳期漏项 长 PR 的后半段基本靠信任放行
新人无依据 只知道“看着改”，不知道具体查什么

技能把标准固化成文本，模型每次按同一份清单走，一致性远高于人。dsh 团队的做法很明确：连自己的 PR 评审都交给技能驱动，说明他们认可这种一致性价值。

评审清单的六个环节

从 dsh-code-review 的体量与命名推断，并结合同类工程技能的通用结构，一份 PR 评审技能一般覆盖六个环节：

环节 检查什么 常见翻车点
变更理解 这次改动的意图、影响面、是否与描述相符 看半天 diff，才发现作者在解决另一个问题
正确性 边界条件、错误处理、并发与竞态 只看了主路径，没问“输入为空会怎样”
测试 新增代码是否有对应测试、测试是否真的能失败 测试跟着实现写，永远绿灯
兼容性 是否破坏公开 API、是否需要迁移说明 改了签名，忘了下游还有谁在调
文档 行为变化是否同步到文档 代码合了，文档三个月后才补
风险 是否有性能回退、是否有安全隐患 新加的循环藏在渲染路径里

注意顺序：先理解变更，再挑错。跳过第一环直接看 diff，是评审最常见的浪费。

具体到 dsh 版本，还会叠加它自己的规范（如分层架构、seam 归属、遥测要求）。这些是项目特定的，恰恰说明评审技能必须项目定制：清单里放通用最佳实践没用，放“我们团队真正在意什么”才有用。

一份最小可用的评审清单（可直接抄）

如果你决定把评审技能搬回自己的项目，下面这份清单是一个起点，删掉不适用的、补上你团队特有的，控制在十条以内：

## 评审清单
- [ ] 改动意图是否与描述一致
- [ ] 主路径之外，空输入 / 非法输入是否被处理
- [ ] 新增逻辑是否有对应测试，且测试能在破坏实现时变红
- [ ] 公开 API / 配置项是否变化，是否需要迁移说明
- [ ] 错误是否被吞掉（空 catch / 顶层大 catch）
- [ ] 是否引入新的外部依赖或网络调用
- [ ] 行为变化是否同步到文档与变更说明
- [ ] 是否有调试残留（console.log / 临时开关 / 未删的 TODO）

这份清单刻意没有写“代码风格是否统一”——那是 lint 和格式化工具的事，不该占评审人的注意力。评审清单只放人比机器看得准的东西。

三档输出的示例

把评审意见固定成三档，价值是让作者知道先处理什么：

档位 含义 作者动作
必须改 阻塞合并的硬问题 不处理不能合
建议改 改进项，不阻塞 择机处理，可驳回并说明理由
可忽略 我看到了，但同意这么写 无需动作

一条“必须改”的实际样例：

必须改：parseConfig 在 options 为 null 时会抛类型错误。主路径你测了，但调用方可能传空。建议加一行空值保护，并补一个空输入测试。

对照来看，一条没有档位的意见“这里可能有点问题”等于没说——作者不知道该不该管。

改造三处

搬过来后重点改三处：

一、触发条件。 把描述里的“deepseek-harness 仓库”改成你的仓库名，或者干脆去掉限定。description 是模型唯一必读字段，写窄了技能选不上，写宽了会在无关仓库里乱触发——这是个需要实测调出来的度。

二、检查清单。 换成你团队真正在意的项，宁少勿假。列了却不检查的条目比没有更糟——它给作者虚假的安全感，还浪费评审人的注意力。十条以内的清单，每条都能真查，胜过五十条的百科全书。

三、输出格式。 固定成“必须改 / 建议改 / 可忽略”三档。分档的价值是让作者知道先处理什么：必须改是阻塞项，建议改是改进项，可忽略是“我看到了，但同意这么写”。没有分档的评审意见是一锅粥，作者只能从头猜优先级。

一个实用技巧：提交前自评审一轮

把评审技能的两种调用方式都打开：模型可以自选（modelInvocable），你也可以直调（userInvocable，即输入 /技能名）。然后约定团队流程：PR 提交前先自评审一轮。

模型按清单过一遍，把“必须改”处理掉再提交。这一轮对作者是几分钟的事，对评审人省的是半小时——更重要的是，送到评审人面前的 PR 已经自我清洁过，评审讨论会集中在真正的设计分歧上，而不是低级遗漏。

单人项目同样受益：它就是那第二双眼睛，而且永远不会说“我今天累了”。

它和另外两个技能的关系

评审不是孤立动作：dsh-doc 负责把评审结论沉淀进文档与变更说明；dsh-pre-push-checks（3.3 节）负责在更早的推送动作前拦下低级错误。三者串起来是一条“本地预检 → 自评审 → 文档化”的链路，越往前拦，修复成本越低。

你要不要装

你的情况 建议
团队有评审规范 建议，把规范搬进技能
想提高单人项目质量 建议，当第二双眼睛
代码量极小、无评审流程 不必

小结

  • dsh-code-review 是 dsh 团队的 PR 评审规程技能，约 10577 字节。
  • 核心价值是把评审标准固化成清单，消除标准漂移。
  • 评审技能必须项目定制，检查清单宁少勿假。
  • 推荐用法：提交前自评审一轮，输出分三档。

延伸阅读