SUN 本文用于人工面试表达。若准备由最终评测、对话质量和 Token 效率共同计分的 AI Coding 笔试，见 AI Coding笔试高分指南。
回答时先讲判断框架，再替换为自己的真实项目和验证证据。
三、Vibe Coding 高频八股
这一部分来自公开面经和一些同学的反馈，开发、测开、Agent 开发都用得上。别把参考回答背成稿，先把思路说清，再换成你自己的项目细节。
3.1 AI 越来越强，你的优势是什么？
回答思路：这题别把优势说成“我更会写 Prompt”。面试官真正想听的是：模型已经能写代码了，你还能多负责哪一步。可以从问题定义、业务理解、工程判断、结果验证和责任边界里挑最能代表自己的两三点，再接一个你发现上线风险的案例。
参考回答
我觉得我的优势是知道什么问题值得解决、什么结果才算真正可交付。比如做商品自动审核功能时，AI 很快生成了违禁词匹配模块，但我在测试中发现，它没有处理大小写、全半角、特殊空格和拆字绕过；另外，如果把模型的低置信结果直接判为违规，还会造成大量误杀。
后来我把流程重新拆成文本规范化、规则检测、模型判断、置信度路由和人工复核，并补了绕过、误杀和异常输入测试。AI 确实让我写得更快，但需求边界怎么定、风险能不能接受、结果能不能上线，还是得由我判断。我的优势就在这里：知道哪些结果不能直接信。
3.2 哪些工作可以交给 AI，哪些必须自己做？
回答思路：别按“写代码”和“不写代码”硬分。我更建议看三件事：规则清不清楚、出错后能不能回退、结果有没有办法验收。低风险、重复性强的工作可以交给 AI；碰到资金、权限、生产数据和业务取舍，人必须拍板。
参考回答
如果让我用 AI 开发一个电商项目，我会让它生成商品 CRUD、DTO、接口文档、测试骨架和重复性的参数校验，因为这些任务输入输出清晰，也容易通过测试验收。
但库存扣减、订单状态机、支付回调、权限模型和生产数据变更，我不会直接让 AI 自主决定。比如订单能否从“已确认”进入“已支付”，背后涉及业务规则和资金风险，我会先定义状态流转表、幂等规则和异常处理，再让 AI 按规格实现。AI 可以提供候选方案和代码差异，但最终方案选择、合并和上线决定必须由我完成。
3.3 你怎么证明 AI 生成的代码是对的？
回答思路：这个问题正好是测开的强项。别回答“我会让 AI 再生成一套测试”，因为那还是 AI 自证。你要讲清楚验收标准从哪里来、代码怎么看、测试怎么覆盖，以及完整链路怎么核对。
参考回答
以早餐店订单系统为例，我不会先让 AI 写页面，而是先整理一张状态流转表，明确哪些状态允许转换、哪些必须拒绝，例如“已确认”不能直接跳到“待取餐”。这张表就是后续验收标准。
代码出来后，我先看状态判断有没有散落在不同入口，是否存在绕过服务端校验的路径。测试也不只跑正常链路：两个终端同时改一张订单、服务重启、更新到一半失败，这些都要故意打出来。最后再完整走一遍下单、接单、制作、取餐和支付，同时核对接口、日志和数据库。只要有一步和最初的状态表对不上，就不能算验收通过。
3.4 AI 连续修改几次仍然报错，怎么办？
回答思路：连续几轮还在原地打转，就别继续换 Prompt 了。把它当成一次正常的线上排障：先停手，保留当前差异，做最小复现，再根据日志判断是代码、数据还是环境问题。方向由人定，AI 只做限定范围的修复。
参考回答
我遇到 AI 连续修改仍然报错时，会先停止让它继续大范围改代码。例如增量数据同步任务出现重复写入，AI 连续几次都在调整重试次数，但问题始终存在。我会先冻结当前差异，用两条数据构造最小场景，并模拟“目标端写入成功、Checkpoint 保存失败”的异常。
这个最小场景一跑，问题就清楚了：重试次数不是根因，真正缺的是目标端幂等。修复时我会用唯一键或 Upsert 保证重复执行安全，并要求一批数据确认成功后才能推进 Checkpoint。方案定下来以后，再让 AI 只改相关文件，补上故障注入和断点恢复测试。它卡住时，人要重新定义问题，不能陪着它继续猜。
3.5 Vibe Coding 和 Spec Coding 有什么区别？
回答思路：别背两个概念的定义，直接拿两个任务对比最清楚。需求还在试、失败成本低，可以多用 Vibe Coding；订单、支付、权限这类功能，规格和验收必须先定下来。
参考回答
如果只是快速验证一个内部报表页面，我可能会采用 Vibe Coding：先描述目标，让 AI 生成可运行原型，再通过几轮对话调整交互。这种任务风险低、修改可逆，快速试错比一开始写完整规格更重要。
订单、支付或权限功能就不能这么做。我会先定数据模型、接口契约、状态机、异常分支和验收用例，再让 AI 分任务实现。实际项目里我通常先用 Vibe Coding 试方案，方向确定后再用 Spec 把边界钉死。
3.6 如何避免代码和数据泄露？
大厂一般已经有工具白名单和安全流程，能不能用、哪些代码能进模型，安全部门会提前划线。中小厂未必这么完善，但面试官既然问了，还是得把自己的处理原则讲清楚。
回答思路：回答别停在“我会脱敏”。要说清楚什么绝对不能上传、公司允许用什么工具、上下文怎么缩到最小，以及 AI 输出进仓库前还要检查什么。
参考回答
如果我要让 AI 协助排查线上问题，我不会直接上传生产日志、用户信息、数据库备份、密钥或完整私有仓库。我会先提取最小复现所需的日志片段，对手机号、账号、订单号等字段脱敏，并把配置中的密钥替换成占位符；工具方面只使用公司批准的企业版或本地模型。
AI 生成代码后，我还会检查它是否写入调试日志、硬编码密钥、引入来源不明的依赖，提交前再执行密钥扫描和依赖安全检查。如果无法确认某段数据能不能进入模型，就默认不上传，先走公司的安全和合规流程。
3.7 需求很模糊时，你会怎么让 AI 开始工作？
回答思路：先别开 IDE。需求只有一句话时，最值钱的动作是把未知项列出来，让业务负责人确认。目标用户、输入输出、业务规则、异常分支和验收标准没有说清楚，AI 写得越快，返工越多。
参考回答
如果产品只说“做一个退款功能”，我不会直接让 AI 生成接口。我会先让 AI 帮我列出未知项，但答案必须由业务负责人确认，例如是否支持部分退款、优惠券如何退回、重复请求如何幂等、退款失败如何补偿、谁有操作权限。
这些问题确认后，我会整理一页短规格，里面放数据模型、接口契约、状态变化、异常分支和验收用例。AI 先交实现计划和文件清单，我确认没有越界再让它动代码。这个步骤看起来慢一点，实际能省掉后面的大量返工。
3.8 如何构建上下文，并避免 AI 的回答偏离问题？
回答思路：上下文塞得多不代表效果好。只给当前任务真正需要的文件、接口和错误信息，同时写清允许修改的范围、禁止事项和验收条件。对话已经跑偏时，及时开新会话比继续补 Prompt 更有效。
参考回答
比如让 AI 增加用户注册接口，我只会给它相关接口文件、用户表结构、错误码规范、现有测试写法和验收条件，不会把整个仓库一股脑塞进去。修改范围也会写死：只动用户模块，不加新依赖，不重构无关代码，动手前先交方案和文件清单。
每完成一步，我都会把结果和验收条件对照。如果上下文已经混入多轮无关讨论，我会重新开一个干净会话，把确认后的规格、当前错误和最小相关文件重新提供，避免 AI 继续沿着错误假设回答。
3.9 你会怎么 Code Review AI 生成的代码？
回答思路：这题最好说出自己的检查顺序。业务含义有没有做对放第一位，后面再看安全、异常处理、并发、可维护性和修改范围。AI 自己写的测试只能当参考，不能拿来给自己盖章。
参考回答
我先看代码做的是不是正确业务，能运行不代表逻辑就对。接着查权限、输入校验、敏感信息、依赖和注入风险，再看异常处理、并发、资源释放和日志。最后扫一遍差异，确认它没有顺手重构无关模块、偷偷加框架或删掉兼容逻辑。
例如审查违禁词检测模块时，我会重点看大小写、全半角、特殊空格和拆字绕过，白名单与误杀，正则表达式性能，规则版本更新，日志脱敏，以及检测服务超时时系统是放行、拦截还是转人工。完成审查后，还要用我独立设计的边界和故障场景验证。
3.10 AI 编程工具的 Token 和使用成本怎么控制？
回答思路：别只说“压缩上下文”。成本控制还包括任务分流、一次把要求说清、复用已经验证过的模板，以及连续几轮没进展时及时停手。贵模型留给真正难、真正高风险的部分。
参考回答
我会按任务难度分流。简单配置可能自己改更快，模板代码可以交给便宜模型，架构取舍、复杂调试和高风险 Review 再用更强模型。每轮只给当前任务需要的文件和报错，需求与验收条件尽量一次写清，避免对话越拖越长。
团队里还可以复用已经验证过的提示模板、接口约定和测试清单。连续两三轮都没有缩小问题范围，我会立刻停掉生成，改做最小复现和人工定位。评估成本时也不能只看 Token，还要把节省的人时和返工算进去。
一个常见误区：不要把“AI 做不了复杂业务”当成自己的优势。模型能力会继续提升，真正稳定的优势是你能定义问题、控制风险、验证结果，并在关键节点做出判断。
相关笔记
- AI Coding笔试高分指南 — 受限 AI Coding 笔试拿分策略
- AI Coding笔试Prompt速查 — 笔试对话模板
- AI辅助编程工程方法 — 需求、拆分、验证与接管
- AI Coding七步工程流程 — 把面试方法落成完整实践
- AI Coding面试实战题 — 案例化练习
- 智能体评测
- AI辅助编程 MOC