AI 编程助手评审代码，先看测试而不是解释

先辨认这次变化的信号

代码助手的解释可以很有条理，但评审时应先检查测试是否覆盖变更意图和失败路径。

团队容易把自动生成的说明当成验证证据，忽略代码实际执行结果。模型天气不按发布频率判断变化，而先看这项能力是否真的改变了任务条件。如果演示只展示一次成功输出，读者仍不知道它在重复、冲突和权限不足时会发生什么。

先固定测试基线，再让助手提出改动；每次变更都要求展示失败测试、修复和回归结果。

把现场条件写下来

助手重写一段权限判断并解释得更清晰，但测试只验证管理员成功路径，没有覆盖普通成员和撤销权限。

这类现场不需要先做大型评测。选择一条最近真实完成的任务，保留原资料、角色和截止时间，再让新工具在不改变目标的前提下重做。观察结果时，把“界面是否顺眼”放在最后一层；先记录输入是否完整、事实是否可追溯、失败能否解释。

最小测试记录

以下检查用于制造可比较的证据。每项都应保存输入、输出、时间和复核人；不同设备或账号也应独立记录。

• 在变更前保存测试结果与运行命令。
• 要求助手先写出预期失败行为。
• 独立运行新增测试和完整回归。
• 人工检查权限边界、日志和错误处理。

若某项只能由供应商演示或管理员完成，就把它标为尚未验证。未验证不是缺点，把未验证写成成功才是问题。

编辑部状态标记

让测试承担验证，让解释帮助理解。任何声称修复但没有失败测试证据的代码变更，都应回到评审状态。

一次测试足以发现明显问题，却不足以证明稳定。把原始输入、失败样本和复核人一起留档，下一次模型或权限发生变化时，团队才能分清是工具退化，还是任务条件已经不同。如果记录只能说明“体验不错”，它就还没有成为能被另一名成员继续维护的证据。在下结论之前，至少让另一位未参与测试的人按记录重做一次。