接受 AI 编程结果前，如何审查代码改动

审查仓库里实际存在的代码，而不只是代理的总结。看似有说服力的解释，也可能伴随着不完整修复、从未运行的测试或无关改动。接受结果前，分清要求的行为、真实修改和验证证据。

Mono Code 让你打开项目文件、与编程代理协作，并直接在编辑器里查看 Git 改动。本文介绍如何审查一个已完成的小改动；连接方法请看远程编程指南。代码仓库和命令始终留在你自己的电脑（主机）上。Mono 还没有正式推出，你可以加入候补名单。

1. 重新写清验收条件

用一个虚构例子：任务表单允许提交只有空格的标题。需要的修复是拒绝这种输入，同时保留正常标题的提交能力。查看补丁前，先写下必须满足的条件：

把这份简短清单放在差异旁边。这样判断依据来自需求，而不是跟随代理给出的解释。如果原始请求有歧义，先明确行为，再接受更大范围的实现。

确认主机、项目文件夹和分支。将改动文件列表与代理开始前记录的状态比较。用户原有修改不会因为与代理改动出现在同一文件中，就自动变成代理的工作。

在目标主机的终端里，以下只读命令可帮助核对：

text

git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/file

请替换示例路径。普通 git diff 显示未暂存改动；--cached 将暂存内容与提交比较。未跟踪文件需要单独检查。Git diff 文档解释了这些比较。工作区干净并不能说明代理是否已经做过提交；如果发生过提交，还要检查相应历史。

在 Mono 编辑器中，行号旁会标出新增和修改的行，点按标记即可打开这部分的差异。这是查看单处改动的便捷方式，但不能证明你已经审完所有改动。标记缺失或过期，也不代表文件没有变化。

回到标题例子，找到校验条件并沿着后续流程检查：是否检查了规范化后的值？错误是否可见？提交流程是否停止？应阅读上下文与调用位置，而不是只接受孤立新增的一条条件。

检查新建文件、删除代码、依赖变化和无关格式调整。简短解释不能为大量未说明的差异提供充分依据。如果行被截断，或改动太宽难以可靠阅读，就转到主机或更大屏幕审查。

要求提供实际运行的命令、结果及跳过的检查。“测试应该能过”是预测，不是已记录的结果。即使测试套件通过，也需要与报告缺陷相关的用例。

可见提示适合进行手动检查；自动回归测试可以保护校验规则。选择能证明行为的证据，而不是只重复实现逻辑的测试。如果环境阻止测试，应明确记录限制，并决定在哪里补足验证。

给出具体反馈：“只有空格的标题被拒绝了，但错误提示没有出现”，或“解释为什么这个校验修复修改了依赖文件”。指出行为和文件，不要只说“再试一次”。

存在其他工作时，不要为了去掉一小处不需要的修改而执行整体重置或恢复。要求针对性修正，并查看新的差异。修正后重跑受影响检查；之前成功的结果不能验证后来的编辑。

授权执行命令与接受代码是两个决定。批准测试命令并不代表同意提交、合并或部署。审查操作本身可参考权限指南。

用简短记录写明结论：

text

要求的行为：拒绝空白任务标题。
已审查文件：列出实际路径。
证据：命令、结果与相关手动检查。
未解决问题：仍未验证的事项。
下一步决定：接受改动、要求修正或暂缓。

提交与发布操作应明确决定。需要保存讨论时，可以导出为 Markdown，同时也要保留真实项目文件。对话记录保存讨论过程；仓库与已经核实的检查才说明实际改了什么。