Agent 写完代码就提交？测试证据才是面试官真正要看的

Agent 说“完成了”，面试还剩八分钟。很多人会立刻跑一个看起来最大的命令，然后盯着终端等待。面试官真正想看的却是：你能不能用最短路径证明，这个 Patch 改对了题目要求的行为。

测试不是为了证明 AI 代码天生更差，而是把“看起来合理”变成可复核证据。GitHub 的 Review 与 CI 文档、NIST Secure Software Development Framework 都把验证放在正常软件开发流程里；它们并没有说测试通过就等于完全正确。

别先跑全量：先证明这次改动真的生效

假设需求是“请求 pending 时禁止重复提交”。第一条证据就应该制造两次提交，并观察只有一次进入后续流程。如果全量 unit suite 从未创建 pending 状态，即使全部绿色，也没有回答题目。

开跑前把需求压成三个可观察目标：请求行为确实改变；最相关的正常路径没有被破坏；一个最危险的失败路径被明确处理。之后才去找能回答这些问题的最窄检查，而不是从脚本菜单里挑看起来最大的命令。

Diff 是否合理仍需单独审查，可参考 AI Coding Agent Code Review 面试指南。测试在这里负责的是把行为主张变成可复核证据，不替代范围与可维护性判断。

Agent 自己写的测试，为什么不能直接当独立证据

生成测试可能复述实现，Mock 掉最危险的边界，或断言一个由新代码自己定义的值。它和 Patch 同源时，绿色可能只是两段代码共享了同一个错误假设。

先读断言是否真的走到目标分支，再检查 fixture、Mock 和状态准备有没有把风险删掉。一个测试写着“拒绝重复提交”，却在进入业务层前就被 Mock 返回，名称再漂亮也证明不了需求。

更稳的方法是让证据来自仓库已有行为、题目验收条件与独立观察。Agent 可以帮助搭建用例，但候选人必须解释为什么这条用例会在旧行为下失败、在新行为下通过，以及它没有覆盖什么。

如果来不及获得严格的先红后绿，也要建立替代基线：保存旧输出、手工复现旧行为，或先运行邻近已有测试。关键不是形式化表演 TDD，而是证明结果差异确实由本轮 Patch 引起，而非测试一开始就会通过。

Agent 最容易漏掉的失败路径

失败路径从依赖出发。依赖输入，就试空值、畸形值、重复值或边界值；依赖外部服务，就沿用仓库现有 seam 模拟超时、拒绝或部分响应；依赖状态，就打断一次转移或重复一次事件；依赖权限，就测 denied，而不是只测 approved。

现场不需要造完整矩阵，只需挑一个如果遗漏就会让 Patch 不安全、不可恢复或产生误导的失败点。改校验时保护一个合法输入；改重试时验证不需要重试的路径；改状态时验证失败后旧状态是否保住。

结果不只看返回值，还要看错误语义是否沿用项目约定、日志有没有上下文且不泄露敏感信息。想练习这种风险优先顺序，可以结合 QA 工程师面试 Playbook。

测试挂了时，怎样判断是代码、环境还是旧问题

实现错误。 输出直接违背验收条件，回到最小改动点，不扩大 Patch。

预期错误。 测试写入了未经确认的假设，先重读需求、调用点和邻近测试，再决定是否调整断言。

环境或旧问题。 依赖、fixture、端口、生成文件或开场已有失败让结果不可靠。记录第一条相关错误，再换更窄检查建立责任边界。

时序或 flaky。 偶发重跑一次可以帮助识别不稳定，却不能把多次重跑后碰到的绿色当作修复证据。需要检查时间、共享状态和执行顺序。

例如断言期待错误码 A，实际得到 B。若 contract 明确要求 A，就是代码失败；若邻近用例一直使用 B，可能是预期错误；若请求根本没进入业务层，而是 fixture 缺失，则是测试搭建或环境问题。真实工作型技术面试排错指南 可以帮助你练习先分类红色输出，再决定下一步。

时间有限时，测试阶梯应该怎样收缩

理想顺序仍然是四层：先复现或锁住目标行为，再验证改动所在单元，随后守住一个邻近回归，最后运行相关 integration suite、lint、type check 或 build。

但剩余八分钟时，不要平均分配时间。先拿到能改变结论的局部证据，再根据 blast radius 选择一个回归或失败路径。更广检查只有在局部结果清楚、且你有时间解释失败时才值得启动。

假设上传 Patch 的定向测试证明重复点击只创建一次请求，但 Mock 了真实网络层。下一步应优先验证请求失败后的状态恢复，而不是立刻跑全站测试。若只够完成这两步，就明确真实网络超时、进程退出和服务端幂等仍未知。

扩大检查前还要看失败成本。一个三分钟的 suite 如果红色后没有时间诊断，只会留下噪音；一条四十秒的邻近 integration test 若能穿过真实适配层，反而更适合现场。选择依据是能否改变当前结论，而不是命令在项目里听起来有多正式。

准备阶段可以用 Interview AiBox 记录 mock round 的测试顺序，复盘自己是否把时间花在了高信号路径。真实面试里的结论仍必须来自当前仓库和明确允许的工具。

最后 30 秒如何交代“已验证”和“未验证”

运行前可以说：

“我先证明 pending 状态会阻止重复提交，再保护正常提交路径，最后测试请求失败后能否恢复，因为这是最危险的邻近情况。三条成立后，如果时间允许，再跑相关 suite 和 type check。”

结束时可以说：

“定向测试证明 pending 时不会重复提交；正常路径仍通过；失败后会恢复状态并允许重试。相关 suite 与 type check 是绿色。完整端到端环境没有运行，所以浏览器时序、真实网络超时和服务端幂等仍未验证。”

这不是命令清单，而是把每条证据对应到一个主张。更广检查还在运行时，只能说“仍在运行”或“未完成”，不能把已启动偷换成已通过。

Patch 测错方向后，先止损再补证据

第一条测试若证明 Agent 改错了行为，就不要围绕错误目标继续扩大 suite。保留失败输出，检查最小相关 Diff，重新确认行为归属，再决定修实现、修预期或报告环境阻塞。

如果 Agent 为让失败路径通过而扩大到公共错误处理中间件，也要暂停：这是公共层真的拥有目标行为，还是局部实现绕开了既有 seam？没有调用关系与相似模式支持时，不要用更大 Patch 掩盖测试设计问题。

仓库没有这一层自动化测试时，也不能用“无法验证”直接结束。先找项目接受的手工或集成路径，把输入、操作、观察结果与清理步骤写成可复现检查；再说明它缺少隔离、速度或稳定性上的哪些保证。不要为了现场显得完整，未经许可引入新测试框架或伪造覆盖率数字。

手工检查完成后，要保留精确观察，而不是只说“我点过了”。输入值、状态变化、错误提示和是否可重试，至少应有一项能被下一位审查者重复确认。

残余风险必须具体。未测试的数据库事务、外部 API 重试、跨浏览器事件顺序、生产配置分支，都比一句“可能还有边界情况”更可审查。证据覆盖到哪里、没覆盖到哪里，本身就是现场交付的一部分。

常见问题

一定要先写测试再让 Agent 改代码吗？

如果仓库和时间允许，先得到一个失败用例最有说服力。做不到时，也应先明确可观察复现，用现有最窄检查验证，再随 Patch 补定向回归。

现场面试写多少测试才算够？

没有统一数量。优先证明目标行为，保护最相关邻近行为，并覆盖最高风险失败路径，之后再决定是否扩大。

这一层没有自动化测试怎么办？

使用项目接受的手工或集成验证方式，把步骤写得可复现，并说明局限。不要未经许可临时引入新测试框架。

CI 通过可以替代 Code Review 吗？

不能。CI 只对已配置检查提供执行证据，不证明改动必要、范围合理、可维护、安全，也不覆盖所有未测试场景。

参考来源

• GitHub Docs：Reviewing a pull request created by Copilot
• GitHub Docs：About continuous integration
• NIST Secure Software Development Framework SP 800-218

下一步

• 查看 Interview AiBox 功能全景
• 通过 产品路线图 了解工作流改进
• 为红色 Patch 准备 Agent 面试失败恢复
• 下载 Interview AiBox