AI 帮你写代码时全程沉默，面试官还能看见你的判断吗？

Agent 开始写代码，候选人也跟着安静下来。半分钟后，一个大 Patch 突然出现，候选人和面试官在同一秒第一次看到它。哪怕代码没错，面试官也很难判断：这是你预期的方案，还是你事后认出了一个看起来能用的答案。

全程沉默不是唯一问题，不停念 Prompt 也不会更强。AI Pair Programming 面试需要的是“判断可见”：你现在认为什么成立，把哪一小步委派给 Agent，用什么证据验收，看到结果后决定保留、拒绝还是接管。

Agent 在忙时，你不能把判断也一起外包

普通 live coding 里，面试官能看到你移动光标、写半成品、改变量和回头修正。Agent 把这些过程压缩成一次输出，原本自然可见的判断节点随之消失。

解决办法不是公开私人思维链，也不是把脑内噪音全倒出来。你只需简洁说明观察到的事实、当前假设、委派边界、验收证据，以及看到结果后做出的决定。

编程面试开口思路指南讲传统 coding 表达；当 Agent 执行部分工作时，重点变成让你的判断持续可见，而不是争夺每一次键盘操作。

开口只说四件事：目标、边界、验收、风险

目标。 说当前要确认的假设，例如：“重复请求可能从 pending 状态分支进入。”

边界。 说 Agent 被允许做什么：“先只读追踪 handler 和定向测试，不改其他模块。”

验收。 说什么结果才算完成：“先得到修复前失败的复现，再用最小 Patch 让它通过，同时保护正常路径。”

风险。 说什么情况会叫停：“如果行为实际由共享状态层负责，我会先暂停，不直接扩大范围。”

这四件事不需要机械说成四句，但不能压缩成“让 Agent 试一下”。委派越清楚，面试官越容易判断后续输出是否符合你的预期。

哪些沉默是专注，哪些沉默像失去控制

读一个现有模式、等待一条短测试、检查十几行 Diff 时，安静完全合理。先说“我用半分钟确认现有错误处理”，再带着结论回来即可。

危险的是没有解释的转场：突然让 Agent 大范围编辑；Patch 出来后直接批准；测试红了立刻发下一条 Prompt；最后才补一句“我本来就是这么想的”。

自然的开口点只有几个：委派前说明任务，Agent 返回后核对理解，Patch 出来后说明审查重点，做接受、拒绝、缩小或恢复决定时说明依据。如果英文表达容易拖慢节奏，可结合 AI 面试答案自然表达指南练短句和停顿。

面试官会把你说的话和后续动作对照

你说只改两个文件，结果出现七个文件，会不会立刻发现？你说失败路径最危险，后面是否真的测试？表达必须能预测动作，而不是为结果补理由。

证据推翻第一假设并不可怕。更成熟的说法是：“刚才判断不成立，调用点证明状态由 store 持有，所以我收回原计划，把写入边界改到已确认的位置。”

委派还必须有明确产物。让 Agent “到处看看”只会制造活动；让它从入口追踪一次事件到状态转移，并返回涉及文件与测试入口，才形成可复核回执。

准备阶段可以用 Interview AiBox 做 mock 与复盘，标出自己在哪些节点沉默、哪些地方解释过量。它帮助练习节奏，不应把真实面试变成背稿，也不能覆盖目标公司的 AI 使用规则。

Agent 返回后，用一句话决定接受、拒绝还是继续查

如果输出符合边界，可以说：“它只改了预期的 handler 与测试，我先审错误路径，再跑定向回归；证据成立后才扩大检查。”

如果出现无关抽象，可以说：“这个 helper 在仓库里没有同类模式，也不解决当前验收条件。我拒绝这部分，只保留已由调用点确认的 guard。”

如果回执信息不足，则不要假装有结论：“它只说问题可能在 service 层，但没有给出调用证据。我先接管入口追踪，确认状态归属前不允许写入。”

这三类表达都遵循同一顺序：先说实际观察，再给决定，最后点名下一条证据。不要用“看起来不错”提前宣布信心，也不要用“Agent 没理解”把宽泛委派的责任推开。

例如 Agent 返回一个能编译的 Patch，却同时改了错误提示、重命名公共函数并新增 helper。你可以把判断拆成三句：“状态 guard 与目标行为相关，我保留；错误提示破坏现有 contract，我拒绝；公共重命名没有验收价值，我撤掉。下一步只验证 guard 的重复与正常路径。”这比笼统说“有些地方需要调整”更能让面试官看到取舍标准。