面对真实仓库：Plan–Build–Review 面试题到底怎么考

屏幕里不是一道算法题，而是一个你从没见过的仓库：目录很多、测试不少、工作树还可能已经有改动。Agent 在旁边等你下命令。很多候选人第一反应是让它“把需求做完”，结果代码出来了，自己的判断却从面试画面里消失了。

仓库型编程面试真正考的是一条完整工作循环：你能不能先读懂已有系统，给改动划边界，监督执行，再用 Diff、测试和风险说明把结果接回来。CodeSignal 已公开介绍 Agentic 与 AI-assisted assessment，GitHub 也有基于仓库上下文工作并产出可审查 Pull Request 的 coding agent。它们说明这种形式已经存在，但不能据此推断所有公司都采用同一套规则。

第一眼先读什么：入口、测试、约束和脏工作树

打开题目后的第一分钟，不要急着搜索需求关键词。先建立四类基线：仓库说明与局部规则、当前工作树状态、已有构建与测试入口、目标行为的上下游调用点。

接着找两三个相似实现，确认项目怎样处理错误、状态、fixture 和命名。题目里一句“增加校验”，可能隐含着不能改变响应结构；一句“修复提交失败”，也可能跨过 UI、API 与持久化边界。仓库型面试的第一道题，其实是能否把文字需求翻译成这个仓库里的真实约束。

如果开场就有未提交改动，要先标记它们属于谁。没有这张基线，后面看到 Diff 膨胀时，你连哪些变化来自本轮都说不清。

面试官为什么先看你会不会缩小任务

弱候选人给 Agent 一个宽泛目标，等它一次性改完，再从结果倒推理由。强候选人先把任务缩成四个可回答的问题：目标行为是什么、预期触碰哪里、第一条证据是什么、什么情况必须暂停。

例如，不说“修一下校验”，而说“空项目名应在写入前被拒绝，同时保持现有错误信封不变”。再补一句：“目前看入口在 handler，我会用调用点和邻近测试确认；如果发现需要改 schema、API contract 或引入新依赖，我会先停下来。”

这段计划不需要长，但必须能约束下一步。它会自然排除顺手重构、无关格式化和新抽象，也让 Agent 的每次写入都有明确验收条件。若你还没确认目标面试允许怎样使用 AI，可先看 AI-aware 编程面试指南，因为工具政策应在技术委派之前厘清。

Build 不是等结果：每次只收一张可验证回执

Agent 开始执行后，不要进入等待模式。把 Build 拆成连续的小回执，每次只回答一个问题。

路径回执。 先解释现有行为链，并用源码、调用点与测试交叉核对。理解不一致时先修理解。

最小行为回执。 第一版只完成验收条件直接需要的逻辑，不带重命名、抽象升级或兼容层整理。

定向证据回执。 先证明目标行为发生变化，再保护一个邻近正常路径。定向失败比大套件失败更容易定位。

范围回执。 查看 status 与 Diff，检查意外文件、被删保护条件、错误语义、默认值和状态转移。

扩大验证回执。 局部证据成立后，再决定是否运行相关 suite、lint 或 build。不是命令越多越强，而是每次扩大都有理由。

每张回执都应能压缩成一句结论：“入口已由两个调用点证实”“失败用例先红后绿”“额外文件已从 Diff 移除”。这样最后不会只剩一句含糊的“测试都过了”。

Agent 完成后，怎样用证据接管结果

“Agent 已完成”只是交接开始。先把需求中的行为逐条映射到实际修改，再看测试是否真的走到目标分支，最后审查 Diff 有没有超出计划。

接管结果时至少回答四件事：哪些文件改变了，为什么必须改；哪些测试提供了直接证据；你拒绝或移除了什么；哪些环境与路径仍未验证。通过测试只提高对已执行路径的信心，不会自动证明部署、外部服务或隐藏调用方安全。

准备时可以用 Interview AiBox 记录一次模拟仓库题的这些交接节点，复盘自己在哪里只报了命令、没有说明结论。工具可以帮助形成练习闭环，但不能替你读取当前仓库或改变目标公司的规则。

计划之外的改动，为什么必须当场拒绝

假设第一版 Diff 多出四个文件，还引入仓库从未使用的 helper。不要因为已经花了时间就继续收下。先保留它发现的有效调用点，撤掉无关范围，回到最小验收行为，再给出更窄任务。

测试失败也不能立刻改测试。先区分新代码确实错误、测试预期未经确认，还是仓库原本存在环境失败。真实工作型技术面试排错指南 强调的最小复现与责任边界，正适合处理这种转场。

拒绝越界不是否定 Agent，而是保护可审查性。你需要说出：“这个抽象不解决当前验收条件，还扩大了调用面，所以我移除它；保留的是已被仓库证据确认的最小修改。”

再看一个常见分歧：Agent 为统一错误处理，想改公共响应 helper，但邻近 handler 已经使用稳定错误信封。此时先问目标行为是否真的要求公共层变化。若只需新增局部校验，就沿用现有 helper，并用一个拒绝用例和一个合法输入证明兼容；不要让“风格统一”把局部题目升级成跨模块重构。

一段可直接说出口的仓库题收尾陈述

完成后可以这样收口：

“目标行为和邻近回归都通过了，Diff 只包含 handler 与对应测试。我检查了错误路径和响应结构，没有保留 Agent 提议的额外重构。完整部署环境没有在本轮运行，因此我只对当前本地证据负责，外部服务与真实集成链路仍是残余风险。”

如果尚未完成，也可以诚实收口：

“定向复现已经确认问题归这个状态分支所有，但更广检查还未结束。我不会把已启动说成已通过；下一步是完成相关 suite，再决定是否需要扩大修改。”

收尾不是念命令清单，而是把目标、范围、证据、取舍与未知连起来。可以用 编程面试开口思路指南 练习这种只在节点开口的表达。

面试官从哪些细节判断你真的掌控仓库

第一，看你是否区分事实与猜测。“我确认了入口和两个调用点”比“这里肯定负责”可靠。第二，看你是否尊重已有模式；仓库已有三个相似实现时，沿用它们通常比现场造新层更可读、更可逆。

第三，看 Agent 是否受计划约束。真正的协作不是不停补 Prompt，而是每次只委派一个可检查任务，拿到证据后由你决定继续、缩小还是拒绝。

最后，看你的信心是否随证据变化。定向测试通过，可以提高对目标行为的信心；没有跑集成环境，就不能声称完整链路已验证。能同时说清“已证明”和“未证明”，才说明 Plan–Build–Review 没有在 Agent 输出出现时失去主人。

还有一个容易被忽略的细节：计划不是开场说完就冻结。调用点证明原判断错误时，应当公开更新计划、缩回不再成立的范围，再继续执行。能够被新证据修正的计划，比一份从头坚持到尾却建立在错误入口上的计划更有价值。

常见问题

仓库型面试会取代 LeetCode 吗？

没有证据表明它会统一取代传统形式。部分平台和公司已经支持仓库型或 AI-assisted 面试，但算法题、系统设计和普通现场 coding 仍然存在。

计划阶段应该花多久？

花到能说清目标行为、可能 owner、既有模式、验证方式和叫停条件即可。短面试里，一个准确的两分钟计划通常比十分钟空泛设计更有价值。

Agent 提出了更漂亮的架构，要不要接受？

先看它是否符合题目、仓库约定、时间和风险。理论上更整洁，不代表适合本轮；如果它扩大范围却没有解决必要障碍，拒绝往往更合理。

每条 Prompt 都要展示吗？

以平台与公司规则为准。沟通上只需要总结委派目标、边界、证据和你的决定，不必朗读全部 Prompt，也不应暴露私人思维链。

参考来源

• CodeSignal Agentic AI Assessments
• CodeSignal 关于 AI-assisted coding assessments and interviews 的介绍
• GitHub Docs：About GitHub Copilot coding agent
• HackerRank Interview 产品页

下一步

• 查看 Interview AiBox 功能全景
• 关注 产品路线图 中的工作流改进
• 衔接练习 Coding Agent 权限判断
• 下载 Interview AiBox