“主要是调了一下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 Code80.8%100 万 token复杂多文件场景表现优异GitHub Copilot~60%约 128K token代码补全强完整功能生成较弱Cursor~65%约 200K tokenIDE 集成体验好复杂场景一般即便 Claude Code 在同类工具中表现最佳在事务边界这类高度依赖业务语义的工程细节上任何 AI 工具都需要人工兜底。应对策略具体做法分为三步第一步提前准备结构化提示词模板把以下方面整理成模板作为上下文一并喂给 AI而不是每次靠”临时想起来”去补充事务控制规范如什么操作需要事务、事务边界在哪幂等设计要求如写操作必须有幂等键、查询操作天然幂等入参校验规则如所有外部入参必须校验、空值和边界值处理关键日志埋点如核心业务节点必须打日志、异常必须记录堆栈第二步生成后做针对性 Code Review重点覆盖以下维度边界条件空值、极值、并发场景异常分支超时、重试失败、第三方服务不可用数据一致性事务边界、缓存与数据库一致性第三步配合完整的单元测试收口没有单元测试的代码即使 AI 生成 人工 Review也不能直接上线。如果面试官追问”具体怎么写提示词模板”你能展开说具体字段和示例这个回答就从”知道问题”升级成了”解决问题”。第二类问题AI 几乎从不主动考虑性能和并发安全问题本质这是另一个更隐蔽的坑。AI 生成的代码在语法上完全合法但压测一跑全崩。常见的问题包括问题类型具体表现后果循环内 RPC 调用在 for 循环里逐条调用远程服务接口响应时间指数级增长大数据集不分页一次性查询返回全部数据内存溢出或接口超时并发场景用 HashMap多线程环境下使用非线程安全集合数据不一致或 ConcurrentModificationExceptionSQL 不走索引生成的 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 用核心在于你是否始终保持判断力。
淘天Boss面：“你在Vibe Coding时遇到了什么问题“，多少人的回答被评“缺少深度“
发布时间：2026/6/3 1:41:49
“主要是调了一下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 Code80.8%100 万 token复杂多文件场景表现优异GitHub Copilot~60%约 128K token代码补全强完整功能生成较弱Cursor~65%约 200K tokenIDE 集成体验好复杂场景一般即便 Claude Code 在同类工具中表现最佳在事务边界这类高度依赖业务语义的工程细节上任何 AI 工具都需要人工兜底。应对策略具体做法分为三步第一步提前准备结构化提示词模板把以下方面整理成模板作为上下文一并喂给 AI而不是每次靠”临时想起来”去补充事务控制规范如什么操作需要事务、事务边界在哪幂等设计要求如写操作必须有幂等键、查询操作天然幂等入参校验规则如所有外部入参必须校验、空值和边界值处理关键日志埋点如核心业务节点必须打日志、异常必须记录堆栈第二步生成后做针对性 Code Review重点覆盖以下维度边界条件空值、极值、并发场景异常分支超时、重试失败、第三方服务不可用数据一致性事务边界、缓存与数据库一致性第三步配合完整的单元测试收口没有单元测试的代码即使 AI 生成 人工 Review也不能直接上线。如果面试官追问”具体怎么写提示词模板”你能展开说具体字段和示例这个回答就从”知道问题”升级成了”解决问题”。第二类问题AI 几乎从不主动考虑性能和并发安全问题本质这是另一个更隐蔽的坑。AI 生成的代码在语法上完全合法但压测一跑全崩。常见的问题包括问题类型具体表现后果循环内 RPC 调用在 for 循环里逐条调用远程服务接口响应时间指数级增长大数据集不分页一次性查询返回全部数据内存溢出或接口超时并发场景用 HashMap多线程环境下使用非线程安全集合数据不一致或 ConcurrentModificationExceptionSQL 不走索引生成的 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 用核心在于你是否始终保持判断力。
