AI 编程最危险的时刻，往往不是它开始写代码的时候。

而是它写完以后，你觉得“差不多可以提交了”的时候。

代码能跑。

测试看起来也过了。

diff 里好像都是刚才那件事。

于是你顺手让 AI 写个 commit message，或者自己敲下 git commit。

这一步看起来很自然，但它恰恰是很多问题混进仓库的入口。

因为 AI 生成代码之后，最容易留下的不是语法错误，而是更隐蔽的东西：

无关改动。

半截实现。

没人调用的新方法。

没有验证的边界。

解释“做了什么”的注释，却没有证明“为什么这样做”的证据。

这些问题单独看都不吓人，但一旦进入历史，就会变成未来排查问题时的噪音。

这也是我做 dev-skills 时，专门把提交前 review 拆成独立 skill 的原因。

简单说，dev-skills（仓库：Jason-chen-coder/dev-skills）是一套给 AI 编程用的工程协作技能链。

它不是让 AI “想到哪写到哪”，而是把一次改动拆成几个更稳的环节：先把需求和边界问清楚，再定方案，再写代码或修 bug，再用真实命令验证，最后在 commit 前审查 diff。

在这条链路里，dev-code-review 负责最后一道门。

所以准备 commit 的默认动作不是直接写 message。

而是先跑：

dev-code-review

它的定位很明确：在代码进入历史之前，对当前 git diff 做一次提交前风险审查。

不是夸 AI 写得好不好。

不是泛泛评价代码风格。

更不是替正式 CR 盖章。

它只做一件事：判断这次改动现在值不值得被 commit。

01. commit 前最该被拦住的，不是坏代码，而是坏 diff

很多人说“AI 写代码要 review”，这句话当然对，但还不够具体。

真正要 review 的不是“代码”这个抽象概念，而是当前这一次 diff。

因为 commit 不是把代码保存一下。

commit 是把一组变更打包成历史。

历史里的每一次提交，都应该能回答三个问题：

这次为什么改？

具体改了什么？

它靠什么证明自己是安全的？

如果一个 diff 同时塞进了功能修改、临时调试、格式化噪音、无关注释清理、顺手重构，它可能每一行都能解释，但作为一次 commit 是不合格的。

这就是 dev-code-review 要处理的问题。

它不是站在“这段代码能不能运行”的角度看。

它是站在“这次提交能不能进入项目历史”的角度看。

这两者差别很大。

代码能运行，只说明主路径大概率没崩。

diff 值得提交，意味着范围清楚、闭环完整、风险可见、验证有据。

很多 AI 编程工作流的问题，不是少写了代码，而是少了一道把 diff 当作工程责任来审查的关口。

02. dev-code-review 是 dev-skills 里的提交前门禁

dev-skills 不是一堆互不相干的 prompt。

它更像一条轻量的工程链路：

dev-grill-docs / dev-spec -> dev-plan -> dev-tdd / dev-fix -> dev-verify -> dev-code-review -> git commit

前面的 skill 负责把需求说清楚、把方案定下来、把代码写出来、把结果验证掉。

但即使前面都做了，commit 前仍然需要最后一道门。

因为实现阶段和验证阶段解决的是“有没有做成”。

dev-code-review 解决的是“这个 diff 能不能干净地进入历史”。

它默认接管所有模糊的 commit 请求。

你说：

帮我 commit

或者：

准备提交，看下这次修改

在 dev-skills 的语义里，这不是“立刻写 commit message”。

这是“先 review，READY 之后再给 commit message”。

只有当你明确说“跳过 review，只要 message”，才会转到 dev-commit-writer。

这个边界非常重要。

因为很多团队质量问题，就是从“把提交信息写漂亮”误当成“这次提交已经准备好”开始的。

dev-code-review 反过来规定了一个更稳的顺序：

先判断 diff 是否 READY。

再谈 commit message。

03. 它不是泛泛 review，而是按五个轴审查

普通的 AI review 很容易变成一堆正确废话：

建议增加错误处理。

建议提升可维护性。

建议补充测试。

建议注意边界情况。

这些话没有错，但也没有抓手。

dev-code-review 的不同之处在于，它不是让 AI 随便发挥，而是把审查收束到五个轴。

第一，规范。

它会看这次 diff 是否符合当前项目的语言习惯和 lint 配置，有没有调试输出、未使用 import、异常吞掉、命名风格突兀、硬编码敏感信息。

规范不是为了洁癖，而是为了让团队以后少为低级噪音付费。

第二，功能。

它会把 diff 当成即将发出去的变更来读：逻辑是否真的符合意图？空值、异常、重复触发、异步时序、输入边界有没有处理？有没有 copy-paste 错误、条件反了、参数传错？

这一步关注的是“会不会坏”。

第三，闭环。

这是 dev-code-review 最有价值的一轴。

很多 diff 看上去写了很多东西，但实际上没有接上。

新增了组件，没有父级渲染。

新增了配置，没有地方读取。

新增了方法，没有 caller。

新增了事件类型，没有接收方处理。

新增了 API 封装，没有业务路径使用。

这类问题最容易出现在 AI 生成代码里：它很会“补齐形状”，但不一定真的把链路接通。

所以 dev-code-review 要求闭环检查不是凭感觉，而是要用证据。对新符号、新入口、新配置、新组件，要验证它有没有真实消费者；没有外部调用、也不属于框架自动调用的豁免，就不能轻易说 READY。

第四，注释。

AI 特别喜欢写解释性注释。

问题是，很多注释只是在复述代码：

“遍历数组。”

“更新状态。”

“调用接口。”

这些注释不会让代码更清楚，只会让代码显得像生成物。

dev-code-review 会盯住多余注释、过期注释、无 owner 的 TODO、注释和代码不一致的地方。

它保留真正解释 why 的注释，清理只是在制造噪音的注释。

第五，废码。

AI 编程很容易留下脚手架残渣。

一个没用上的 helper。

一个空的类。

一个为了兼容预留但没有消费者的 wrapper。

一段旧逻辑已经被替换，却忘了删。

这些东西暂时不一定会报错，但会持续污染项目理解成本。

dev-code-review 会把它们作为提交前必须面对的问题，而不是留给未来某个人猜。

这五个轴加起来，才像一次真正的 pre-commit review。

它不是问“代码看起来怎么样”。

它问的是：

规范有没有破，功能有没有错，闭环有没有断，注释有没有噪音，废码有没有混进去。

04. READY 不是情绪判断，而是门禁结果

dev-code-review 最值得保留的设计，是它有明确 verdict。

它不是输出一篇长长的心得。

它会给出三种结果：

✅ READY
⚠ FIX P1
❌ BLOCK

这三个结果让 review 从“建议”变成“门禁”。

如果存在 P0，比如未闭环、泄露密钥、公共 API 被删但调用方还在、明显首调用就会崩，那就是 ❌ BLOCK。

这不是“建议修一下”。

这是不能 commit。

如果存在 P1，比如可达的边界遗漏、调试输出残留、异常被吞、信任边界缺输入校验，那就是 ⚠ FIX P1。

这意味着你还没到写 commit message 的阶段。

如果没有 P0/P1，闭环也通过，没有明显废码和调试残留，才是 ✅ READY。

只有 READY 时，它才输出 commit message。

这个设计很关键。

因为它把“写 commit message”从默认动作，变成 review 通过后的奖励。

在 AI 工作流里，这种顺序比想象中重要。

如果你让 AI 一上来就写 commit message，它会自然地把自己放进“包装成果”的模式。

如果你先让 dev-code-review 出 verdict，它会先进入“挑问题”的模式。

一个负责放行。

一个负责包装。

角色不能混。

05. dev-code-review 让 AI 不再自我批准

AI 开发有一个很隐蔽的问题：实现者和审查者经常是同一个上下文。

同一个 AI 刚写完代码，马上又说“看起来不错，可以提交”。

这在人类团队里是很奇怪的。

我们不会让一个人写完关键改动后，完全不换视角就自己批准自己。

但在 AI 编程里，这件事经常发生。

dev-code-review 通过 skill 边界把这个问题显性化。

它要求 review 和实现分开。

它只读当前工作树，不主动修改文件。

它优先输出风险、证据、行号和 verdict。

如果发现问题，应该先修，再重新验证，再重新 review。

这不是形式主义。

这是为了让 AI 协作也有基本的工程制衡。

AI 可以写代码。

AI 可以修 bug。

AI 可以跑验证。

但 commit 前，仍然应该有一个独立的审查动作，专门盯 diff 风险。

这就是 dev-code-review 的角色价值。

它让 AI 不再一边产出，一边给自己盖章。

06. 一个实际的使用方式

最简单的用法是，在你准备提交时直接说：

用 dev-code-review 看下这次修改，准备 commit

它会先收集当前变更：

git status --short
git diff --stat
git diff
git diff --cached
git log --oneline -10

如果 diff 涉及逻辑文件，它还会读完整文件，而不是只看 hunks。

因为很多问题只看局部 diff 看不出来。

比如一个新方法在 hunk 里看起来没问题，但全文件里根本没有调用。

比如一个状态字段改了默认值，但上游初始化路径没有同步。

比如一个组件 props 新增了可选参数，但调用方仍然按旧语义使用。

最后输出会像一份简短但有约束力的提交前报告：

━━━ Dev Code Review ━━━
Verdict   : ⚠ FIX P1
Scope     : 3 files · +84 / −12 · staged
Intent    : 修复重复提交时的错误提示
Languages : Dart

Axis Check
  规范   ✓
  功能   ⚠
  闭环   ✓
  注释   ✓
  废码   ✓

Findings
  [P1] lib/.../submit_button.dart:88   功能   连续点击时仍可能触发第二次请求
       → 在请求开始前禁用按钮，或在 handler 首行加 re-entry guard

这类输出的好处是，它不会把你淹没在长篇建议里。

它只告诉你：现在能不能 commit，不能的话先修哪里。

07. 它真正保护的是团队的 review 带宽

很多人把 commit 前 review 看成个人习惯。

但我觉得它更像团队礼仪。

PR review 是很贵的。

同事花时间看你的代码，不应该被迫先帮你抓调试输出、无关文件、未使用方法、明显没接上的配置。

这些问题本来就应该在本地被挡住。

dev-code-review 的价值，就是让进入团队 review 的 diff 更干净。

它不是替代同事。

它是在尊重同事。

你交出去的不是：

“我让 AI 写完了，你们帮我看看吧。”

而是：

“这次变更已经过了一轮提交前审查，P0/P1 风险已处理，闭环和范围都检查过了。”

这两种姿态完全不同。

前者是在把风险外包给团队。

后者是在把责任先收回到自己这里。

08. 最后

dev-code-review 最重要的地方，不是它能发现多少惊天大 bug。

而是它把 commit 前那几分钟，变成了一个稳定的工程动作。

不再凭感觉说“差不多了”。

不再把 commit message 当成完成标志。

不再让 AI 写完代码就顺手自我批准。

而是先问一遍：

这次 diff 的意图清楚吗？

范围干净吗？

功能闭环吗？

有没有注释和废码噪音？

有没有足够证据证明它可以进入历史？

如果答案还不够硬，就先别 commit。

先修。

先验证。

再 review。

最后才提交。

这就是 dev-skills 里 dev-code-review 的意义。

它不是一个好看的流程节点。

它是 AI 编程从“能生成代码”走向“能交付可靠变更”的最后一道门禁。

真正专业的 AI 开发工作流，不是让 AI 写得越来越多。

而是让每一次被提交的代码，都更经得起未来回头看。