AI 给了答案你却拒绝：这可能是面试里最强的工程判断信号

候选人刚说完“这段 AI 代码我不会收”，面试官没有点头，而是连续追问：“哪条要求被破坏？如果不采用它，你准备怎么继续？什么结果会让你改口？”三问之后，真正的判断和表演式拒绝立刻分开。拒绝本身不值分，能否让项目继续向前才值分。

GitHub 的 Responsible Use 文档提醒使用者审查并验证 AI 输出，NIST AI Risk Management Framework 也强调需要治理风险，而非自动信任。它们都没有承诺“拒绝 AI 就会被录用”。面试信号来自证据、取舍和后续动作，不来自对工具摆出强硬态度。

面试官怎样拆穿表演式拒绝

最容易露馅的信号不是技术词说少了，而是拒绝无法回答后续问题。

没有对象。 候选人只说“AI 容易幻觉”，却指出不了当前 Diff 的哪一行改变了行为。

没有后果。 候选人说“这里不够优雅”，却解释不了它会让哪个调用方、数据状态或验收条件出错。

没有替代。 候选人否掉方案后只能从头重写，说明他可能没有理解原目标，只是在证明自己没有照单全收。

不允许被证伪。 测试已经穿过争议路径，候选人仍坚持“反正 AI 不可靠”，这不是谨慎，而是拒绝让事实改变判断。

先把个人偏好和项目约束分开。工程约束优先于模型 能帮助你把理由落到验收条件、仓库归属、数据边界和兼容要求，而不是把“我不喜欢”包装成严重缺陷。

先给替代方案，证明你不是在卡进度

面试官真正想知道的是：拿掉这条路径后，原任务还能不能完成。强候选人会先保住目标，再缩小风险。

可以按四步回答：原目标仍是什么；哪一段实现破坏了约束；哪个更窄的机制能完成任务；下一条验证是什么。顺序很重要，因为它先证明你理解业务目标，再解释为什么当前实现不适合进入最终结果。

假设题目要求导入一批记录，并明确规定只要有一行无效，整批就不能写入。Agent 给出的方案边遍历边保存，遇到错误后把失败行加入结果列表。正常输入全部通过，代码也很整洁，但它把“整批原子失败”改成了“部分成功”。

拒绝时不要停在“写循环不安全”。更好的替代是：先完成整批解析与校验，确认所有记录有效后，再在已有事务边界中一次提交。这样保留了导入目标，也恢复了题目要求的失败语义。

用最小证据决定这条路径能不能留

不需要先做全面 Review。只要构造两行输入：第一行有效，第二行违反明确校验规则，然后观察失败后是否仍有第一行进入存储。

运行前先说清假设：“如果需求是整批失败，那么任一行无效时持久化数量必须为零；当前实现可能先写入第一行，所以我用一条混合输入测试确认。”这句话让面试官看见你正在验证可证伪结论，而不是寻找支持反对意见的材料。

如果测试出现一条已写记录，风险被直接证明。若结果为零，就继续检查是否已有事务回滚，而不是为了维持姿态继续拒绝。最小证据的价值就在这里：它既可能否掉方案，也可能否掉你的担忧。

类似地，接口冲突可以读一份定义和一个真实调用方；范围漂移可以撤掉争议文件后重跑目标用例；安全问题可以走一次允许路径和一次拒绝路径。选择最可能改变决策的检查，而不是堆十条无关绿色结果。

按行为拆分该保留、该修改和该拒绝

这份导入方案不必整包丢弃。输入解析、字段标准化和错误定位可能都符合要求；真正必须拒绝的是校验完成前发生写入，以及只报告失败行却保留成功行的提交语义。

可以这样拆：保留解析器和字段映射；把错误信息改成仓库已有格式；将全部校验移到写入之前；让事务负责最终提交；保留原有 happy path 测试，再补一条“第二行失败时零写入”的断言。

这种拆分比“我全部手写一遍”更能证明所有权。你评审的是行为和风险，而不是根据作者是 AI 还是人类决定整份 Patch 的命运。技术决策面试指南 可以继续训练你用目标、约束、代价和可逆性解释这些取舍。

让接受与拒绝都有可复核记录

面试官可能继续问：“你怎样证明最后留下的不是同一个问题？”这时不要拿聊天截图数量回答，要把一次实质决定连接到实际材料。

记录原要求是整批失败；指出第一版 Diff 在循环中提前写入；保存那条混合输入测试的失败结果；说明你保留了解析逻辑、拒绝了写入时机，并在替代实现上重新验证零写入与正常导入。这样，接受、修改和拒绝都有清楚对象。

Prompt、Diff 与测试审计链指南 进一步说明怎样把这些动作连接起来。它的作用不是制造一份自证档案，而是避免事后把模糊记忆讲成完美故事。

新证据出现时，敢于撤回原判断

表演式拒绝最怕改口，工程判断则必须允许改口。假如你读到仓库已有统一事务包装，而且定向测试证明第二行失败后没有任何写入，那么“部分成功”的担忧已经被解决。

此时可以说：“我最初担心循环内保存会留下部分数据，但现有事务会在错误时整体回滚，混合输入测试也验证了零写入。这个拒绝理由不再成立。我会继续检查错误定位是否满足题目，然后决定是否接受。”

反过来，如果测试证明已有部分写入，就明确拒绝当前提交时机，并推进先校验后提交的替代。真正稳定的标准始终是需求和证据，而不是维持最初立场。

三十秒把拒绝收成一个工程决策

现场表达可以这样收口：

“我拒绝的不是这份生成代码的全部，而是校验完成前逐行写入的行为。题目要求任一记录无效时整批失败，混合输入测试显示第二行报错后第一行仍被保存。解析和字段标准化可以保留，我会把整批校验前置，再通过现有事务一次提交，并重跑零写入与正常导入用例。”

这段话同时回答了五件事：拒绝什么、违反什么、证据是什么、保留什么、下一步怎么做。若时间不足，也要明确替代边界和待验证项，不能把未实现方案说成已经完成。

Interview AiBox 可以在准备阶段回放 mock round 中的接受与拒绝节点，帮助你检查理由是否经得起“后果是什么”“怎么替代”“什么会让你改口”三次追问。真实面试的结论仍必须来自题目、仓库事实和明确允许的检查。

常见问题

每场 AI Coding 面试都应该至少拒绝一次吗？

不应该。刻意表演很容易被追问拆穿。逐项审查重要建议，让证据决定接受、修改还是拒绝。

没跑测试前能直接拒绝吗？

明确需求、接口或安全边界已经证明冲突时可以。否则先做最小可行检查，再给出强结论。

没时间实现替代方案怎么办？

说明被破坏的约束、已有证据、最小替代路径和下一条验证，不要把未实现想法说成完成。

自己重写一遍能证明所有权吗？

不能。所有权体现在理解需求、审查风险、验证结果和解释取舍，不在于手动输入了多少字符。

参考来源

• GitHub Docs：Responsible use of Copilot coding agent
• GitHub Docs：Responsible use of Copilot inline suggestions
• NIST AI Risk Management Framework

下一步

• 查看 Interview AiBox 功能全景
• 通过 产品路线图 了解工作流改进
• 把同样的证据意识用于 Prompt Injection 权限收敛
• 下载 Interview AiBox