AI 面试开始给你一整个代码库：60 分钟里，真正危险的是你接不住 AI 的错
有一种技术面试正在变得很尴尬。
候选人打开 CoderPad，不再只看到一道孤立算法题，而是一个小型代码库：三四个文件、已有测试、半成品业务逻辑、一个看起来很贴心的 AI 助手。题目也不再是“反转链表”这种一眼能判断套路的东西，而是“这里有个订单状态流转 bug，你把它修掉，再补一个小功能，最后解释为什么这样改”。
听起来比刷题友好。真正开始做，压力反而更大。
因为这类 AI-enabled coding interview 不再只考你会不会写出答案，它会把候选人放进一个更接近真实工作的现场：你能不能在陌生代码里快速找到入口，能不能把一个模糊任务拆成可验证的小步，能不能判断 AI 生成的代码哪里像答案、哪里像事故，能不能在测试失败时不慌，能不能把自己的修改讲成一个工程决策。
过去很多人准备技术面试的方式很简单：刷题、背模板、看高频题、总结复杂度。这个方法仍然有价值，但它覆盖不了一个新的问题：当面试给你的不是一道题，而是一段有上下文、有历史包袱、有测试、有错误提示的代码库，你还会不会工作？
- 代码库型面试考的不是“会不会用 AI”，而是“能不能管住 AI”
现在很多讨论会把这类面试叫成 AI coding interview，容易让人误解成“谁更会提示词，谁就赢”。实际更像这样：
面试官给你一个小型代码库，让你在有限时间里完成 3 到 4 个 checkpoint。比如：
• 读懂已有模块，找到订单状态从 pending 到 paid 的入口。 • 补全一个半成品函数，让优惠券只在特定用户段生效。 • 修掉一个测试失败，解释失败原因不是测试写错，而是边界条件漏了。 • 用 AI 快速生成一个草稿，再自己删掉不符合项目风格的部分。 • 最后口头说明：你改了哪里，为什么这样改，还有哪些风险没处理。
AI 在这里不是替考工具，更像一个速度很快但判断力不稳定的队友。它可能帮你定位文件，生成测试，补一段样板代码；也可能误读业务语义，忽略已有约定，把一个局部能跑的 patch 写成长期维护噩梦。
所以面试官看的不是“你有没有问 AI”，而是你问完之后做了什么。
很多候选人会在这里暴露三个问题。
第一，入口找得太慢。看到多文件项目后，习惯从头读，像看教程一样从目录扫到实现。60 分钟里，这种读法很快把时间烧掉。更好的方式是先定位动作入口：请求从哪里进来，状态在哪里变，错误从哪里抛，测试失败指向哪一层。
第二，AI 代码接得太快。AI 给一段实现，候选人复制进去，测试过了就松一口气。可面试官一问“如果用户重复点击支付按钮怎么办”“如果缓存里还有旧状态怎么办”“如果这个字段为空但类型系统没拦住怎么办”，答案立刻散掉。
第三，讲不清自己的取舍。代码能跑，但解释像流水账：“我先改这里，然后改那里，然后测试通过。”这不是工程表达。工程表达应该说明假设、边界、风险和验证路径。
- 新题型会把“刷题型安全感”拆掉
刷 LeetCode 的安全感来自题目边界很干净。输入是什么，输出是什么，通常都写在题面里。你只要找到模式，滑动窗口、二分、动态规划、并查集，路径就很清楚。
代码库型面试的压力来自边界不干净。
你会遇到名字含糊的函数、没有解释的配置、历史遗留的测试、被注释掉的逻辑、看起来无关但实际影响结果的状态字段。面试官可能不会把这些都告诉你，因为现实工作里也没人会把所有上下文整理成算法题题面。
这就是为什么“会刷题”和“能在代码库里交付”开始分叉。
一个典型场景：
你接到一个 bug：用户取消订单后，库存偶尔没有释放。AI 可能会建议你在 cancelOrder() 里直接加一行 releaseStock(order.items)。看起来合理，测试也可能过。但你继续读代码后发现，库存释放已经在事件消费者里做过一次；真正的问题是某些取消路径没有发出事件。这个时候直接补释放逻辑，短期让一个测试过，长期制造重复释放风险。
面试官最想看到的，其实是你能停下来问：
• 当前系统里库存释放的唯一可信入口是什么？ • 取消订单是同步流程还是事件驱动流程？ • 这次 bug 是逻辑缺失、消息丢失、幂等没做，还是测试覆盖不足？ • 最小修复是补事件，还是加防重，还是重写状态机？ • 我怎么用测试证明这次修复没有引入二次释放？
这才是 codebase interview 的核心。它不是把算法题换成项目题，而是把候选人的工程判断放到一个更真实、更吵、更容易出错的环境里。
- 60 分钟里，候选人要有一条自己的操作线
如果把这类面试当成自由发挥，基本会乱。更稳的做法是把 60 分钟切成五段。
第一段：5 分钟建立地图
先别急着写。你需要快速回答四个问题：
• 任务入口在哪里？ • 数据结构和状态字段在哪里？ • 已有测试怎么跑，失败信息指向哪里？ • 哪些文件是业务核心，哪些只是展示层或胶水层？
这一步可以用 AI 辅助，但提示词要小。比如：
“请根据文件名和测试，帮我找出订单取消逻辑可能涉及的 3 个入口，并说明每个入口的证据。”
不要一上来让 AI “实现完整功能”。你还没有确认它理解上下文。
第二段：10 分钟拆 checkpoint
把面试任务改写成可验证清单。
例如原题是：“修复取消订单后库存偶尔不释放的问题，并补一个管理员手动取消功能。”
你可以拆成：
• 找到取消订单的所有入口。 • 确认库存释放的唯一责任模块。 • 复现一个库存未释放的失败测试。 • 修复事件缺失或幂等缺失。 • 为管理员取消补权限判断和审计字段。 • 跑最小测试集，再跑相关回归测试。
这时候你已经从“我要完成一个需求”切到“我要控制风险”。面试官会明显更容易跟上你的思路。
第三段：20 分钟写最小补丁
这一步要克制。
AI 很擅长把一个小问题扩成一个“大而全”的实现：新 service、新 helper、新异常类、新抽象。面试现场最危险的不是代码少，而是你引入了一个自己解释不清的变化面。
更好的策略是先做最小补丁：改离 bug 最近的位置，保留原有结构，补最能说明问题的测试。如果确实需要重构，先说清楚为什么原结构无法安全修复。
这和真实工程很像。线上事故里，能被解释、能被回滚、能被验证的小改动，通常比“顺便把架构整理一下”更可信。
第四段：15 分钟验证 AI 输出
这里是 AI-enabled 面试最容易拉开差距的地方。
你不能只说“测试过了”。你要说测试覆盖了什么，没覆盖什么。
建议至少做三种验证：
• 正常路径：用户取消后库存释放，订单状态正确。 • 边界路径：重复取消、已支付订单取消、空商品列表、权限不足。 • 回归路径：不影响原来的支付、退款、库存扣减。
如果 AI 生成了测试，你要检查测试是不是只验证了它自己刚写的 happy path。很多 AI 测试会很会“自证正确”：mock 掉真正有风险的依赖，断言一个实现细节，而不是断言业务结果。
第五段：10 分钟讲清复盘
最后不是“我做完了”，而是给出一段像工程师的收口：
“我定位到库存释放不是散落在多个入口，而是由订单取消事件触发。失败原因是管理员取消路径没有发出同样事件，所以库存没有进入释放链路。我没有在管理员入口直接调用 releaseStock，因为那会绕开已有幂等和审计。我的修复是复用事件路径，并补了重复取消和权限不足两个测试。剩下没做的是消息投递失败后的重试观测，这个需要看现有队列机制。”
这段话比代码本身更能说明你是不是能独立工作。
- 这类训练应该怎么承接
这类面试对候选人的要求很具体：听懂任务、找入口、拆 checkpoint、判断 AI 输出、补测试、讲取舍、做复盘。
如果只靠刷题平台，很容易练到“会解题”，但练不到“在一个不熟悉的代码库里稳定推进”。如果只靠临场用 AI，又容易被 AI 的自信带偏。
我更倾向把准备过程拆成三类训练：
• 面试前：拿 JD 和简历项目生成可能出现的 codebase 任务，例如支付状态、权限判断、缓存一致性、日志排查、批处理失败。 • 面试中：把问题整理成入口、状态、约束、验证和表达，而不是急着让 AI 写完整答案。 • 面试后：复盘自己在哪一步断掉，是入口定位慢、测试意识弱、边界条件漏，还是解释取舍不清楚。
这也是我会把 offer.cc 放进训练流程里的原因。它更适合做 AI 面试助手、Coding Interview Assistant 和 Interview Copilot：帮候选人从题目、JD、简历、系统设计面试和面试复盘里提取追问链路，把“我好像会”变成“我能在压力下讲清楚并验证”。
- 一个可执行的 7 天练习法
如果你最近要准备这种 AI-enabled coding interview，不建议只刷更多题。可以用 7 天做一个小循环。
第一天，找一个开源小项目或自己过去的项目，限制 30 分钟，只画入口地图：请求入口、核心状态、测试位置、外部依赖。
第二天，挑一个 bug，先不用 AI，写出你认为的最小复现路径。重点不是修得快，而是能不能把失败条件说清楚。
第三天，允许 AI 参与，但只让它做定位和候选方案。你来决定采用哪一个，并写下拒绝其它方案的理由。
第四天，练测试。为同一个改动写 happy path、edge case 和 regression 三类测试。测试写不出来，通常说明你还没真正理解需求。
第五天，练口头表达。把你的修改讲成 90 秒：问题是什么、证据是什么、改动是什么、风险是什么、怎么验证。
第六天，做一次压力演练：给自己 45 到 60 分钟，完整跑一遍“读代码、拆任务、用 AI、修 bug、讲复盘”。
第七天，复盘薄弱点。不要只记“这题不会”，要记录更细的断点：入口定位、状态建模、边界测试、AI 输出审查、技术表达。
技术面试正在从“谁背过更多套路”走向“谁能在不完整上下文里稳定交付”。AI 的加入没有降低门槛，它只是把隐藏的能力差异放大了。
真正的安全感不来自你问了多少次 AI，也不来自你刷了多少题，而是来自你能在一个混乱的小代码库里，找到入口、控制改动、验证结果，并把判断讲给别人听。
这件事，才值得认真练。
