“主要是调了一下prompt，有错误的话直接让Claude解决。”——这个回答不能说错，但信息量约等于零。面试官真正想听的，是你在用AI工具的过程中，踩过什么坑、形成过什么判断。
01 一个让人警醒的面试案例
最近有一个真实的技术面试案例，在开发者圈子里引发了广泛讨论。
一位求职者面试淘天后端开发岗位，简历上写了”熟练使用AI辅助编程”。面试官看到这个描述后停顿了一下，抛出了一个问题：
“你在 Vibe Coding 的时候，遇到并解决了什么问题？”
求职者想了想，回答说：
“主要是调了一下 prompt，有错误的话直接让 Claude 解决。”
面试官听完没说话，手指敲了敲桌子，过了几秒才开口：
“你还是缺少深度。”
这个回答为什么”缺少深度”？
打个比方，这就像你跟面试官说”我写代码的方式是写代码”——信息量约等于零。它没有传递任何有价值的判断、经验或思考。
面试官真正想听到的，是你在用 AI 工具的过程中：
- 踩过什么坑
- 形成过什么判断
- 建立了什么样的工程方法论
这个问题其实是最近技术面试中，AI 方向被问得最高频的一个。今天就来展开讲讲，怎么回答才能有深度。
02 回答这道题的三个禁忌
在正式说怎么答之前，先明确三个绝对不能踩的坑：
❌ 禁忌一：无脑吹捧
“非常好用，没遇到过什么问题。”
为什么不行：这等于告诉面试官”我没有思考过工具的局限性”。一个没有质疑过工具的工程师，往往也没有驾驭它的能力。
❌ 禁忌二：空话套话
“遇到了一些 bug，多输入几次提示词就改好了。”
为什么不行：这句话在任何场景下都能说，等于什么都没说。面试官听完后无法判断你的技术水平。
❌ 禁忌三：只描述行为，不传递判断
“我用 Claude 写代码，用 Copilot 补全。”
为什么不行：这只是工具清单，不是思考过程。面试官想听的是”为什么用”“用的时候注意什么”“什么时候不用”。
正确思路：这三个禁忌的共同问题是——没有展现你作为工程师的判断力。接下来要讲的回答方式，核心就是展现判断力。
03 行业数据：AI 写代码的真实困境
在讲具体回答方式之前，先看一组行业数据。这组数据能帮你理解，为什么面试官要问这个问题。
Stack Overflow 2025 年开发者调查
2025 年，Stack Overflow 对近 5 万名开发者进行了调查，结果显示开发者对 AI 生成代码的最大抱怨是：
| 问题 | 占比 | 说明 |
|---|---|---|
| “答案差不多对，但就是不完全对” | 66% | 语法正确、逻辑有瑕疵，是最隐蔽的坑 |
| “调试 AI 代码比自己写还费时间” | 45% | 生成快、改错慢，整体效率不升反降 |
| “缺乏上下文理解” | 38% | AI 不理解业务语义和项目历史 |
| “安全漏洞” | 29% | SQL 注入、硬编码凭证等 |
METR 机构对照实验
更耐人寻味的是，METR 机构对 16 位经验丰富的开源开发者做了对照实验：
| 组别 | 完成任务时间 | 结果 |
|---|---|---|
| 允许使用 AI 工具 | 基准时间 + 19% | 反而更慢 |
| 不允许使用 AI 工具 | 基准时间 | 正常完成 |
这个结果看似反直觉，但其实很好理解：AI 生成的代码需要额外的 Review 和调试时间，当开发者对 AI 输出过度信任时，反而会忽略本该注意的细节。
关键结论：
这不是说 AI 没用，而是说：AI 工具的价值，完全取决于你驾驭它的方式。
这正是面试官最想听到的东西——你不用告诉它”AI 很好用”，你要告诉他”我知道 AI 哪里不好用，以及我怎么应对“。
04 有深度的回答方式：三类问题 + 对应解法
基于上述行业背景，下面是一个贼有技术含量的回答框架。核心结构是： “我在用 AI Coding 开发的时候，主要遇到三类问题，也都形成了各自的解决方式。”
第一类问题：AI 生成的代码语法没毛病，工程落地却漏洞百出
问题本质
AI 生成的代码，最常见的缺陷包括：
- 事务控制没做
- 幂等性校验缺失
- 核心日志没埋点
- 异常处理不完善
- 参数校验不严格
这些问题 AI 不是不懂，而是它在生成代码时，默认场景是”功能能跑通”，而非”上线后能扛住”。
这两者之间的鸿沟，恰恰是工程经验积累出来的直觉，很难靠提示词一次性传递清楚。
工具能力对比
值得一提的是，这个问题在不同 AI 工具之间其实存在明显差异：
| 工具 | SWE-bench 通过率 | 上下文窗口 | 工程理解能力 |
|---|---|---|---|
| Claude Code | 80.8% | 100 万 token | 复杂多文件场景表现优异 |
| GitHub Copilot | ~60% | 约 128K token | 代码补全强，完整功能生成较弱 |
| Cursor | ~65% | 约 200K token | IDE 集成体验好，复杂场景一般 |
即便 Claude Code 在同类工具中表现最佳，在事务边界这类高度依赖业务语义的工程细节上，任何 AI 工具都需要人工兜底。
应对策略
具体做法分为三步：
第一步：提前准备结构化提示词模板
把以下方面整理成模板，作为上下文一并喂给 AI，而不是每次靠”临时想起来”去补充：
- 事务控制规范（如：什么操作需要事务、事务边界在哪）
- 幂等设计要求（如：写操作必须有幂等键、查询操作天然幂等）
- 入参校验规则（如：所有外部入参必须校验、空值和边界值处理）
- 关键日志埋点（如：核心业务节点必须打日志、异常必须记录堆栈）
第二步：生成后做针对性 Code Review
重点覆盖以下维度：
- 边界条件（空值、极值、并发场景）
- 异常分支（超时、重试失败、第三方服务不可用）
- 数据一致性（事务边界、缓存与数据库一致性）
第三步：配合完整的单元测试收口
没有单元测试的代码，即使 AI 生成 + 人工 Review，也不能直接上线。
如果面试官追问：”具体怎么写提示词模板？”
你能展开说具体字段和示例，这个回答就从”知道问题”升级成了”解决问题”。
第二类问题：AI 几乎从不主动考虑性能和并发安全
问题本质
这是另一个更隐蔽的坑。AI 生成的代码在语法上完全合法，但压测一跑全崩。
常见的问题包括：
| 问题类型 | 具体表现 | 后果 |
|---|---|---|
| 循环内 RPC 调用 | 在 for 循环里逐条调用远程服务 | 接口响应时间指数级增长 |
| 大数据集不分页 | 一次性查询返回全部数据 | 内存溢出或接口超时 |
| 并发场景用 HashMap | 多线程环境下使用非线程安全集合 | 数据不一致或 ConcurrentModificationException |
| SQL 不走索引 | 生成的 SQL 缺少 WHERE 条件或使用函数包装索引列 | 全表扫描，数据库 CPU 飙升 |
| 缺少限流降级 | 没有对下游服务做保护 | 雪崩效应 |
提示词能解决多少？
与第一类问题不同，这类问题只有一部分能靠提示词前置规避。
能通过提示词规避的：
- “禁止在循环中发起 RPC 调用”——AI 通常会遵守
- “所有数据查询必须加分页”——AI 通常会遵守
- “并发场景使用线程安全集合”——AI 通常会遵守
无法通过提示词完整覆盖的：
- SQL 执行计划的走查（需要理解具体索引结构和数据分布）
- 锁粒度的选择（需要理解业务并发模型）
- 线程安全集合的挑选（需要根据读写比例选择 ConcurrentHashMap / CopyOnWriteArrayList 等）
这些判断背后依赖的是对系统运行时的深度理解，提示词很难完整覆盖，仍然需要人工 Review。
一个容易被忽视的反例
有些团队在提示词里加了”考虑并发安全”这类模糊要求，结果 AI 会给每个方法都加上 synchronized，反而造成锁竞争，性能比不加锁还差。
教训：限制 AI 的方式，本身也需要足够精确。与其说”考虑并发安全”，不如说”以下方法会被多线程调用：X、Y、Z，请使用 ConcurrentHashMap 替代 HashMap”。
第三类问题：在老代码上加新需求，AI 是”最危险的重构者”
问题本质
这是实际工程中最高发的事故场景。
面对一段历史包袱重、逻辑耦合深的老代码，AI 的本能反应往往是”顺手整理一下”——它会：
- 悄悄重命名变量
- 抽取方法
- 调整调用链
每一步看起来都合理，但最终破坏了原有逻辑的微妙平衡。
行业数据
Claude Code 在处理 5 万行以上大型遗留代码库时，任务成功率约为 75% 。这在同类工具中已经算高的，但换句话说：即便是表现最好的工具，在遗留代码上仍然有 25% 的失败概率——这还是在理想条件下测出来的数字。
应对策略：双重限制
限制一：在提示词里明确划定边界
告诉 AI 以下内容是禁止动的：
- 哪些文件不能改
- 哪些函数不能改
- 哪些调用链不能调整
示例提示词：
请在 OrderService 中添加退款功能。
禁止修改的文件：PaymentGateway.java, LegacyOrderValidator.java
禁止修改的方法：calculateTotal(), validateOrder()
只能新增代码，不能修改已有逻辑。
限制二：坚持”只扩展、不修改”原则
新增功能用新增代码来实现，而不是改动已有逻辑。
这种做法类似于设计模式中的开闭原则（Open-Closed Principle） ：对扩展开放，对修改关闭。虽然会让代码结构稍显冗余，但在存量系统上，安全比优雅更重要。
05 这个回答为什么”有深度”？
把这三类问题说完，给面试官的感受是什么？
感受一：你不是”复制粘贴党”
你不是一个用 AI 糊弄需求的”复制粘贴党”，而是真正把 AI 当作工具、自己掌握核心的工程师。
幂等设计、事务边界、SQL 性能、并发安全、遗留代码改造——这些本来就是后端开发里最难啃的骨头，你能在 AI 辅助场景下一一点出来，说明你对这些痛点是有真实感知的。
感受二：你有架构意识
更重要的是，这个回答本身就体现了一种架构意识：
知道哪里可以放权给 AI，哪里必须自己把关。
这正是高级工程师和初级工程师的核心区别——不是写代码的速度，而是判断力。
感受三：你了解行业趋势
2025 年的调查数据印证了这一点：
| 指标 | 数值 |
|---|---|
| AI 工具使用率 | 84% |
| 对 AI 输出”高度信任”的开发者 | 仅 3% |
换句话说，行业共识早已不是”用不用 AI”，而是”谁能更聪明地用 AI” 。
这个问题，考的就是你属于哪一类人。
06 本质分析：AI 工具的”知道”与”理解”之间的断层
这三类问题的本质，其实是 AI 工具在 “知道语言” 和 “理解工程” 之间的断层。
| 维度 | AI 的能力 | 人类的必要性 |
|---|---|---|
| 语法正确性 | ✅ 做得足够好 | 不需要人工检查语法 |
| 框架 API 使用 | ✅ 大部分准确 | 需要验证版本兼容性 |
| 事务边界 | ⚠️ 需要人工兜底 | 必须人工定义 |
| 业务语义理解 | ⚠️ 只能理解字面 | 必须人工补充上下文 |
| 系统运行时行为 | ❌ 无法模拟 | 必须人工压测验证 |
| 遗留代码改造 | ❌ 容易破坏隐式约定 | 必须人工划定边界 |
“知道语言” ：AI 精通编程语言语法、框架 API、设计模式的文字描述。这部分它做得足够好。
“理解工程” ：AI 缺乏对以下内容的理解：
- 这个事务为什么必须包含这三步操作
- 这个接口为什么不能返回全量数据
- 这段老代码为什么看起来”很丑”但不能改
- 这个缓存为什么用 Redis 而不是本地缓存
这些理解来自真实的线上故障经验、性能调优经验、系统演进经验。在相当长的时间内，仍然需要人来兜底。
07 不同团队的实践建议
基于上述分析，给出不同场景下的实践建议：
资源充裕的团队
策略：提示词模板 + Code Review 双保险
- 建立团队级别的 AI 使用规范
- 维护结构化的提示词模板库
- 所有 AI 生成代码必须经过 Code Review
- 配合完整的单元测试和集成测试
快速迭代、人力紧张的小团队
策略：谨慎使用，重点把控
需要特别注意：在快速迭代、人力紧张的小团队里，盲目依赖 AI 反而会增加整体维护成本。
METR 的研究结论已经有数据体现：允许使用 AI 的组完成任务时间反而长了 19%。
建议：
- AI 仅用于生成样板代码、单元测试等低风险场景
- 核心业务逻辑仍由人工编写
- 建立最小化的 Code Review 机制
最后总结一下
面试官问”你在 Vibe Coding 时遇到并解决了什么问题”，本质上是在考察三个维度：
- 你有没有质疑过工具——能说出 AI 的局限性，说明你有独立思考能力
- 你有没有形成方法论——能说出具体的应对策略，说明你不是在”碰运气”
- 你有没有工程判断力——能区分”哪里放权给 AI，哪里自己把关”，说明你有架构意识
三类核心问题：
- 工程落地漏洞百出 → 结构化提示词模板 + Code Review + 单元测试
- 性能和并发安全缺失 → 精确的提示词约束 + 人工执行计划走查
- 遗留代码改造风险 → 划定边界 + “只扩展、不修改”原则
AI 工具的”知道语言”能力已经足够好，但”理解工程”的能力在相当长的时间内仍然需要人来兜底。会用 AI 不等于被 AI 用，核心在于你是否始终保持判断力。
