AI代码评审最有用的结果，是一条能被开发者验证的问题：哪次变更、哪个位置、什么输入会触发、用户会受到什么影响。把整个仓库丢给AI，让它“全面优化代码”，通常会得到大量风格建议，却很难判断哪些问题必须在合并前修复。
代码评审结束后，需要向用户说明本次变化时，可按AI编写版本更新说明的方法把技术改动整理成功能变化、影响范围与使用提示。
可以先固定基准版本和待合并版本，把变更说明、差异文件、相关调用与测试放在同一任务里，再要求AI只报告有证据的行为变化。使用墨刀AI客户端时，可在本地项目中整理这些材料，让AI辅助分析代码和输出评审记录；评审结果仍要回到对应版本验证。
先划清这次评审的范围
“这段代码看起来不安全”和“这次修改让一个原本成立的规则失效”是两种不同的反馈。前者可能值得另建技术债任务，后者才可能阻塞本次合并。评审前写清变更目标，能减少把整个项目历史问题都归入一个小改动的情况。
| 材料 | 应写到什么程度 | 缺少时容易发生的误判 |
|---|---|---|
| 基准与目标版本 | 两个明确的提交标识，另记本地未提交改动 | 评审了旧代码，或把工作区修改当成提交内容 |
| 预期行为 | 用户动作、业务规则和保持不变的兼容行为 | 把产品刻意允许的行为当作缺陷 |
| 差异与调用 | 变更文件、调用入口、相关类型和配置 | 只看函数，忽略上游已做的校验 |
| 测试与运行结果 | 命令、环境、结果及没有覆盖的路径 | 把“存在测试文件”误认为“测试已经通过” |
Git项目可以先用git diff --name-only BASE...HEAD了解分支相对共同祖先的改动，再查看具体差异；如果评审的是两个确定快照，则比较这两个提交。BASE是团队选择的基准引用，不应机械替换成一个尚未同步的本地分支。已经有评审中的分支，也要避免把后来新增的提交混在第一次评审结论里。
一条有效发现，应该能落到一个具体输入
以订单金额计算为例。业务约定折扣比例在0到1之间，0代表允许的免单，未传折扣或值为null时按原价计算。下面是待评审的变更片段，金额使用整数分：
function payable(totalCents, discount) {
return Math.round(totalCents * (discount || 1));
}只说“建议提高健壮性”没有帮助。有效反馈应当指出：当discount为0时，||会将它替换为1，因此原本应为0分的订单会按原价计算。输入payable(12900, 0)即可检查这个问题。对于这里只需要给null和undefined提供默认值的约定，可以改用discount ?? 1；范围校验和金额舍入规则则应按项目既有约定处理，不能顺手凭空增加。
| 输入 | 约定结果 | 原表达式结果 | 需要说明的含义 |
|---|---|---|---|
| 12900分，比例0 | 0分 | 12900分 | 免单被错误回退为原价 |
| 12900分，比例0.8 | 10320分 | 10320分 | 普通折扣正常，不能据此推断边界正常 |
| 12900分，未传比例 | 12900分 | 12900分 | 默认行为应继续保留 |
还要追问一个关键问题：0值是否真的能够从业务入口传到这里？如果上游规则禁止免单，问题的前提就不成立；如果上游允许，但当前测试没有覆盖，就应该补相应回归。文件位置只是起点，调用链和业务输入才能决定发现是否成立。
把误报和真正的阻塞项分开
AI可能看到金额函数没有检查负数，就建议立即增加异常抛出。但是，假如函数只接受已经过schema校验的内部订单对象，贸然改变异常行为，反而可能让原调用方崩溃。这条建议应先追查调用入口和数据约束，而不是因为写得像专家意见就直接采纳。
当改动涉及对外API字段或响应结构时，可进一步做API兼容性检查，用旧调用方验证字段改名、类型变化和默认值调整会不会破坏现有用法。
可以将发现分成“已确认缺陷”“待补证据”“改进建议”三类。已确认缺陷有可触发路径和可观察影响；待补证据缺少某个前提，例如服务端是否已经限制了输入；改进建议可能改善维护体验，但暂时没有行为错误。不要把三类内容混成一个总分，声称代码获得90分就可以合并。
对于每条发现，记录下面这一行即可继续讨论：
位置：src/order/price.js 的默认折扣表达式
触发条件：业务允许 discount = 0
影响：应免单的订单被计算为原价
依据：免单规则、入口参数、当前表达式
验证：运行 0、0.8、未传值三组金额断言
处理：修复默认值表达式，补边界回归严重程度要看影响面。可能造成越权、数据损坏或金额错误的路径应优先排查；局部命名和格式应交给团队规范或格式化工具。一个问题涉及多少真实用户、是否可回滚、是否有绕过办法，比AI写出的“高危”标签更能帮助排序。
在本地项目里组织一次AI评审
先把工作区当前变更检查清楚。在用于评审的项目目录中准备一份变更说明、目标差异和相关规则，再让客户端读取所需文件。已有敏感配置、凭证或真实客户日志时，应先移出材料范围；评审不需要把无关环境变量值一并提供。
第一次任务建议先分析业务代码，不直接应用修复。这样能先确认AI理解的是正确目标，再逐项决定需要修复的内容。下面的任务说明可以直接替换为自己的文件名：
请评审本次订单折扣变更，不修改业务代码、测试或配置文件。
允许创建或更新指定的评审记录 review-findings.md。
先阅读 review-context.md、change.diff、src/order/ 和相关测试。
业务规则：折扣为0表示免单，未传或null时为原价；其它校验沿用现有入口。
只报告本次变更新增或放大的行为问题。
每条发现写明：文件位置、触发输入、影响、证据和验证方法。
找不到调用路径时列为待补证据，不要假设。
不要把命名偏好当成阻塞项，也不要声称未执行的测试已通过。
将评审记录写入 review-findings.md。材料较多时，不必一次让AI阅读全部仓库。先查看入口、被改函数及相关测试，发现依赖缺口再补文件。对陌生项目，可先沿着一条业务调用链读懂代码，再评审差异。墨刀AI客户端承担本地资料整理和分析，不意味着已经接管远端PR审批或自动合并。
修复后，用原问题验证结果
确认免单问题后，修复范围应围绕默认值表达式和必要测试展开。先确保免单输入在旧实现中复现异常，再检查修复后为0分，同时确认普通折扣、缺省折扣没有回归。如果测试只检查函数调用不抛异常，即使变绿也不能证明金额正确。
代码通过评审后，若分支合并又出现冲突，应比较共同祖先与两侧规则后解决Git冲突，并重新运行相关样本，避免在接受某一侧修改时丢掉已经确认的修复。
- 核对评审位置是否仍属于最新待合并版本，避免修复已经不存在的问题。
- 把触发条件写进测试或可重复操作，记录期望值。
- 只应用已确认的修复，查看差异中是否混入无关格式化或文件变动。
- 运行相关测试，保存实际命令与输出；环境缺失时明确哪一步未执行。
- 检查调用方和关联业务，再由负责人员判断是否可以合并。
GitHub的代码评审文档也提醒用户验证AI反馈，评审可能漏掉问题或提出错误意见。这个提醒落到工作里，就是不省略证据、复现和修复后的回归，而不是在每条评论后重复写一句“仅供参考”。
一次有效的AI代码评审，应当减少团队需要猜测的地方。把确认的问题连接到对应测试用例，把驳回理由留在记录里，下一轮讨论就能从已知事实继续。可以从一个小范围变更开始，在墨刀AI客户端整理评审材料，先得到几条可验证的发现。
