把AI写的项目带上技术面：五个追问环节的过关话术

2026年的技术面试里，几乎人人都写了「AI 辅助开发」。面试官早就明白：让人工智能写一段能跑的代码不难，难的是候选人对那段代码的理解深度。于是考察方式从「你会不会用 AI」变成了「AI 生成的东西你有没有真正吃透」。

下面这五个环节，是面试官判断一个人是「真的主导了项目」还是「把 AI 的输出当作业交上去」的关键节点。

环节一：动机与边界——「为什么用 AI 做这件事？」

劣质回答：「因为效率高。」

优质回答要落到具体约束上：团队只有两个人、排期四周、功能是内部工具、出错成本可控。把 AI 用在「验证业务假设」的阶段，而不是「核心交易链路」上，这是有意识的取舍，而不是能力不足的退路。

答题结构：约束条件（人/时间/风险）→ 为什么这个任务适合 AI（有明确验收标准、可快速回滚）→ 什么环节我坚持手写（金额计算、权限判断、并发控制）。

面试官听到「哪些地方我不敢让 AI 碰」，才会相信你懂边界。

环节二：过程控制——「你怎么保证它没乱写？」

这里要证明你有工作流，而不是有运气。可以讲三件事：

1. 上下文工程：我会先写一份 CLAUDE.md，把项目结构、命名规范、禁止使用的过时 API 写清楚，再让它动手；
2. 粒度控制：一次只让它改一个模块，超过 200 行的 diff 我会拆开重来；
3. 验收前置：先写测试，再让它实现，测试不过不进主干。

注意别把回答变成工具广告。面试官关心的是你的判断，工具名字只是佐证。

环节三：理解深度——「这一段为什么这么写？」

这是淘汰率最高的一环。面试官通常会挑你 diff 里最不起眼的三五行，问「这里为什么加了这个锁」「这个 await 去掉会怎样」。

应对方式只有一个：项目上线前，逐行过一遍 AI 生成的代码，并且能在一个月后仍然讲出当时的理由。 我的习惯是给每个 nontrivial 的改动在同一行上方加一句注释，写「解决什么问题」，而不是「做了什么」。注释是给半年后自己看的，也是给面试官看的。

如果确实记不清，诚实的回答是：「这块当时是为了绕过 X 问题，具体机制我需要看下代码」——然后一起看。装懂比不知道更致命。

环节四：事故与修正——「上线后出过什么问题？」

没有事故的项目在面试官眼里通常意味着两件事：要么项目太浅，要么你在隐瞒。

准备一个有真实代价的故事，重点在于归因链路：症状（错误率上升）→ 排查（看到日志里出现某类空值）→ 根因（AI 生成的边界判断漏掉了时区转换）→ 修复 → 预防机制（加了跨时区的集成测试用例）。最后一步最重要，它证明你能把错误转化为团队资产。

环节五：可迁移性——「换个场景你还会这么做吗？」

这是区分「会用一个工具」和「建立了方法论」的问题。回答时把这次项目的经验抽象成可复用的检查清单，例如：

• 涉及钱、权限、幂等的代码，一律人工复核；
• 涉及数据格式转换的，先让 AI 生成穷举用例再写实现；
• 涉及第三方 API 的，先做最小的连通性验证，避免它凭记忆编造接口参数。

反问环节可以主动加分

面试尾声问「你们团队的 AI 代码规范长什么样？有没有规定哪些路径禁止 AI 提交？」，会显著改变面试官对你的定位：从一个使用者，变成能参与制定规则的人。这个问题也很实用——你能借此判断对方是真的把 AI 融进了工程体系，还是只停留在给员工发账号。

小结

技术面考察 AI 项目，本质上是在考察三件事：你的边界判断、你的过程控制、你能不能在代码离开 AI 之后依然解释它。 把这三点准备成具体的、带细节的故事，比背十个 Prompt 模板有用得多。