Agent 一次改 12 个文件，面试官真正看的是你能不能控制范围

题目只要求补一个过期判断，Agent 却一次改了 12 个文件。候选人盯着满屏 Diff 说：“它应该是顺便把结构整理了一下。”这一句比代码报错更危险，因为面试官已经确认：你不知道哪些改动属于题目，哪些只是 Agent 的偏好。

多文件不是原罪。真实仓库的一个行为可能经过入口、领域逻辑、适配层和测试。但强候选人会把范围控制在“能够解释、能够验证、能够撤回”的边界内，而不是用绿色测试替每一处修改背书。

为什么“改得多”不是能力证明

很多人会把大 Patch 理解成 Agent 很强：它发现了更多调用点、统一了公共逻辑、顺手补了配置，还把测试快照全部更新。问题是，面试题考的通常不是“能制造多少一致改动”，而是“能否交付题目要求的最小完整行为”。

假设任务是“邀请链接过期后返回既有错误码”。真正需要回答的只有几件事：过期规则由谁负责；入口如何调用；旧的有效链接是否不受影响；失败形态是否沿用项目约定。若 Agent 为此重写全局时间工具、改所有错误文案、刷新十几份快照，它可能让仓库看起来一致，却扩大了未知风险。

面试官不会因为数字 12 自动扣分，也不会因为数字 2 自动加分。他会继续追问：“这 12 个文件里，去掉哪一个会让需求失败？”如果你只能回答“Agent 认为需要”，范围就没有被你接管。

可以先结合 技术决策面试指南 练习把“为什么改这里”说成行为归属、依赖和风险，而不是个人偏好。

开工前先画“允许碰”和“不能碰”两圈

不要直接对 Agent 说“帮我修好，尽量少改”。这句话没有可执行边界。

第一圈是预期改动区。写出最可能拥有该行为的模块、直接调用方和对应测试。例如邀请领域规则、接口入口、邀请状态测试。

第二圈是保护区。列出没有明确授权就不应触碰的部分，例如认证、计费、数据库结构、公共 API、依赖版本、生成文件、全局配置。

两个圈之间还要留一个窄通道：如果只读探索发现真实依赖在预期区之外，Agent 可以先报告“为什么必须跨出去”，但不能静默写入。这样既不会因陌生仓库过早锁死路径，也不会把探索权变成无限修改权。

一条现场可用的任务说明是：

“先只读检查邀请入口、领域校验和相似测试，给出当前调用链。写入范围先限于行为归属文件、直接调用方和测试。不要改公共错误结构、共享时间工具或生成文件；若认为必须跨出范围，先停下说明依赖。”

这比“少改点”具体得多。

Diff 突然膨胀时，先看四种异常

第一种是公共抽象突然出现。局部判断被搬进一个全局 helper，但仓库里没有第二个消费者需要它。抽象不是免费的，它会让更多调用点进入本次 blast radius。

第二种是清理搭车。重命名、格式化、目录移动、依赖升级和测试整理混在功能改动里。它们可能有价值，却不属于这次验收。

第三种是所有权迁移。原本清楚的领域规则被挪到共享层，只因为 Agent 更容易复用，而不是因为业务边界发生变化。

第四种是测试数量增加，证据反而变弱。大量快照更新没有一条用例直接证明过期行为；或者 Agent 同时改实现和断言，让绿色只是两个错误假设互相配合。

出现任一信号，就别继续发“检查并修复所有问题”这类宽 Prompt。先查看文件清单，按四类标记：目标行为必需、直接配套必需、以后可做、与题目无关。前两类进入下一轮，后两类撤掉或拆出去。

具体行级审查可以参考 AI Coding Agent Code Review 面试指南，但范围审查更早发生：先决定这个文件是否应该存在于 Patch，再决定里面哪一行合理。

不要等最后一次 Review：按依赖分三次验收

多文件任务最容易失控，是因为候选人让 Agent 连续完成“分析、重构、改调用方、补测试、修失败”，最后才第一次看结果。此时即使发现第一步判断错了，后面所有改动都建立在错误路径上。

把过程拆成三个检查点。

行为检查点。 先确认规则现在由哪个模块负责，最窄修改能否表达需求。只审这一处，不急着扩大。

连接检查点。 再处理直接调用方、类型或 fixture。每增加一个文件，都要说明它如何被前一步真实依赖。

证据检查点。 最后补定向用例、邻近正常路径和必要的更广检查。测试应对应风险，不是为文件数量找理由。

每次检查都问：“新增了什么事实，所以现在必须改这个文件？”如果答案只是“为了让重构完整”，就要回到题目是否真的要求重构。

GitHub 的 Coding Agent 与 Pull Request Review 文档展示了一个有用形态：Agent 可以基于仓库工作，但结果应以可审查 Diff 交给人决定。工具实现会变化，阶段验收这条原则不依赖某个产品按钮。

逐文件验收：保留、撤销还是拆分

最终 Review 时，不要只从第一行滚到最后一行。先对文件清单做五问。

为什么改？ 能否用一句话连接到题目行为。

谁依赖它？ 是真实调用关系，还是为了配合新抽象才制造的依赖。

会影响谁？ 公共 helper、配置和接口通常比局部模块拥有更大 blast radius。

证据在哪里？ 哪条测试、构建或人工检查覆盖了这类风险。

撤掉会怎样？ 若恢复该文件后需求仍成立，它很可能不是本轮必需。

例如一个重试限制任务改了客户端、公共重试工具、两个无关调用方、默认配置和多份快照。逐文件检查后发现客户端原本就有局部策略，只需新增边界判断和两个测试。公共工具只是 Agent 偏好的统一重构，其他改动都由它连带产生。

此时最成熟的做法不是硬审完 12 个文件，而是保留当前 Diff 作为诊断材料，撤销无关链路，把方案收回到局部实现，再验证限制触发和正常请求两条路径。

面试现场如何解释一次主动缩小

候选人常怕撤销 Agent 输出显得浪费时间，于是勉强接受大 Patch。实际上，主动缩小能展示你发现并处理了范围风险。

发现漂移时可以说：

“当前 Diff 通过新增公共 helper 扩大到两个无关调用方。我还没有证据证明这些消费者需要改变，所以先暂停。题目行为可以由客户端现有策略承接，我会恢复公共层与无关调用方，只保留边界判断和定向测试。”

完成后可以说：

“最终保留三个文件：行为归属模块、直接调用方和测试。每个文件都对应题目要求或真实依赖，相关用例与类型检查通过。我没有跑完整部署环境，因此配置差异下的时间行为仍未验证。”

注意不要说“文件少，所以一定安全”。你要证明的是连接清楚、风险被检查，而不是数字漂亮。

从范围事故中恢复，不要继续补 Prompt

如果 Agent 已经让 Patch 膨胀，第一步不是再说“请精简”。先保存文件清单和关键 Diff，弄清膨胀从哪一次判断开始。否则 Agent 可能在错误抽象上做一次更整齐的精简。

接着回到最后一个已理解的节点：恢复清理搭车、无关调用方和未经证明的公共迁移；重新声明写入边界；把下一步压成一个可证伪动作。例如只修改局部重试判断，然后运行一条限制触发测试。

如果发现题目确实要求公共行为变化，应明确告诉面试官范围判断已经更新，并重新列出消费者与验证计划。这不是失败，而是用新证据修正最初假设。

范围控制和分布式影响判断高度相通。分布式系统面试常见错误 能帮助你练习从局部改动继续追问缓存、重试、状态与下游消费者，而不是只盯当前文件。

Interview AiBox 可以在准备阶段记录 mock round 中每次范围扩张的节点，复盘你是否及时说明目标、边界与停止条件。真实面试里要交付的证据，仍必须来自当前仓库与允许使用的工具。

常见问题

一文件 Patch 一定比多文件 Patch 更好吗？

不一定。为了凑成一文件而复制规则、绕过现有分层，同样会制造风险。目标是最小完整改动：遵守仓库既有归属，又能在时间内解释和验证。

Agent 可以搜索整个仓库吗？

陌生任务可以允许较宽的只读搜索，但写入应在确认调用链后收紧。把“可以看哪里”和“可以改哪里”分开。

面试官临时要求顺便重构怎么办？

先确认新目标，再重画影响范围，说明新增文件、风险与验证方式。不要让口头扩题悄悄混进原 Patch。

全部测试通过能证明每个文件都必要吗？

不能。测试只为实际执行的行为提供信心，不证明修改必要、归属正确，也不覆盖所有未测试影响。

参考来源

• GitHub Docs：About Copilot coding agent
• GitHub Docs：Reviewing a pull request created by Copilot
• Anthropic Docs：Claude Code common workflows

下一步

• 查看 Interview AiBox 功能全景
• 通过 产品路线图 了解工作流改进
• 继续阅读 AI 面试审计记录指南
• 下载 Interview AiBox