Codex 和 Claude Code 写完代码后，我先看这 6 件事

这篇可以当成一份「代码 Agent 验收清单」。只解决一个具体的问题：当 Agent 说「完成了」之后，人到底该怎么看，才能放心把这次改动收进项目。这也是我在真实项目里反复打磨出来的一套工作流。

让 Codex 或 Claude Code 改完问题、最后说「完成了」，这一刻反而最该重视。我以前也会先看结果：测试通过没有、有没有报错、Agent 的总结写得是否完整。后来发现，这样验收实在太粗了。

真正想做到可商用、可发布的项目，Agent 写完代码后一定有大量问题藏在后面。它可能把 bug 修掉了，却同时改动了不该动的逻辑；测试可能是绿灯，却只覆盖了一部分流程；总结写得很有把握，却根本给不出合理的证据。

最近 Import AI 461 提到两个评估方向，正好能解释这些问题。Cognition 的 FrontierCode 关心：一段代码进入真实项目后，维护者是否愿意合并——它不只看结果对不对，还看测试质量、改动范围、代码风格和项目习惯。AARRI-Bench 看的是另一类能力：Agent 做研究型任务时，能不能查证据、留记录、识别数据问题，并在信息不足时停下来。

所以现在 Codex 和 Claude Code 写完代码后，我会先看下面这 6 件事。

第一件事：先确认它有没有修对问题

验收的第一步，我会把注意力从总结里拉出来，回到最初那个问题。

这次到底要修什么？原来的报错还会不会出现？用户走同一条操作路径，结果是否真的变了？如果是线上问题，有没有日志、截图、复现步骤能对上？

这一步看着基础，却很容易被忽略。Agent 有时会把表面问题压下去，根因还在；也有些情况，测试通过只是因为代码绕开了原来的失败路径。

所以我会让它先交代清楚：

这几个问题问完，至少能先判断一件事：它处理的，是不是我真正关心的那个点。

第二件事：看它有没有把改动放大

第二件事，看 diff。一个小 bug 搞成几个函数重构，一个校验改动就影响了接口结构，一个测试补丁带着业务逻辑一起变化——这类情况在 Agent 写代码时太常见了。

这不算能力差，纯属能力过剩。它会主动找更完整的解法，也会把所有看起来不 OK 的地方一起改。放在 demo 里显得很聪明；放进团队项目，review 成本会明显上升。FrontierCode 里强调 scope discipline（改动范围的控制），这个指标很实用：维护者关心的不只是代码能不能跑，还关心这次改动有没有守住边界。

我一般会让 Agent 给一份文件级解释：

解释不清的文件，就需要人工重点看。尤其是和任务关系不大的文件，最好先退回去确认。

第三件事：看证据够不够

Agent 很擅长写完成总结。「已修复」「已验证」「测试通过」「逻辑更稳健」，这些话看着很爽，但对验收帮助有限。真正要看的，是它能不能把结论指回证据。

代码任务里的证据，可以是测试命令、终端输出、失败前后的日志、关键 diff、复现步骤。调研任务里的证据，可以是来源链接、发布时间、原文出处、可信度判断。

我不太接受一句「我检查过了」。它需要说明检查了哪里、结果是什么、哪个证据支持这个判断。

可以直接给它这条规则：

这条规则会让 Agent 少写漂亮话，多交可检查材料。验收时，人就会轻松很多。

第四件事：看写法像不像这个项目

代码跑通以后，还要看它是否像这个项目里原本就存在的代码。

命名方式、错误处理、目录位置、测试写法、日志习惯，这些细节决定了代码能不能长期放在仓库里。Agent 很容易写出一种「通用正确」的代码，单独看没问题，放进项目里就很奇怪。

比如项目一直用简单函数，它突然加一个抽象类；项目一直用固定的错误返回格式，它突然换成另一套异常处理；项目测试一直偏集成测试，它突然补了一堆很垃圾的 mock。

这类问题短期内不一定出事故，但代码库会慢慢变杂。所以我会让它说明风格依据：

一个靠谱的代码 Agent，应该能说出自己为什么这样写。只说「这样更好」，不够。

第五件事：看失败过程有没有留下来

成功总结不缺，缺的是失败过程。它试过哪些方案、哪个方案失败了、报错是什么、为什么放弃、后面接手的人要避开哪些旧问题。这些内容不留下来，下次开新会话，很可能又从同一条路开始试。

项目里这种浪费很常见。某个依赖版本上次已经确认不能升，下一轮 Agent 又建议升级；某个测试上次已经确认是历史问题，下一轮又想改业务代码迎合它；某个方向上次已经证明不合适，过几天又被重新拿出来。

失败过程就是项目的工作记忆。结束前，可以让 Agent 补一段：

这段记录不用长，但一定要具体。它的价值主要在下一次任务开始时。

第六件事：看它有没有停止判断

AARRI-Bench 里有一个点，我觉得很适合迁移到日常写代码：Agent 要会判断什么时候该停。

缺数据，就说缺数据；代码跑不通，就说跑不通；来源不可靠，就说不可靠；连续几次尝试没有进展，就该停下来找人确认。

Agent 有时太想给答案。信息不够，它也会继续写；环境缺文件，它也会猜一个结论；来源不清楚，它也会把二手资料整理成事实。写代码时也一样：它可能为了完成任务继续扩大改动范围，也可能为了让测试通过避开真实问题。

所以我会提前给它一条停止规则：

一个会停下来的 Agent，更适合进入真实工作流。因为错误答案的成本，通常比暂时没有答案更高。

一段可以直接复制的验收提示词

如果只想拿去用，可以把下面这段存成固定提示词。每次 Codex 或 Claude Code 写完代码后，直接贴给它。

这段提示词解决的是一个很具体的问题：把 Agent 的交付从「它说完成了」，变成「人可以快速检查」。

最后提醒

Codex 和 Claude Code 越能干，验收越不能省。以前 review 主要看代码本身；现在 Agent 写代码，还要看过程：为什么这样改、有没有证据、试过哪些方向、遇到不确定时有没有止损。

• FrontierCode 提醒的是生产代码标准：正确只是起点，维护者愿意合并才算真有用。
• AARRI-Bench 提醒的是研究工作标准：会回答还不够，严谨、克制、可复核更重要。

如果今天只改一个习惯，就从这一步开始：下次 Codex 或 Claude Code 写完代码后，不急着看它的总结，先看这 6 件事。

参考链接

• Import AI 461：importai.substack.com
• Cognition FrontierCode：cognition.ai/blog/frontier-code
• AARRI-Bench：arxiv.org/abs/2606.07462
• AARR-Bench 官网：aarr-bench.com