使用 AI 编程时，如果模型生成了严重错误代码，应如何定位、修复并建立工程防护？｜快手后端开发面经解析

60 秒回答模板

我会先把 AI 生成的严重错误当成一次普通工程故障处理，而不是简单归因给模型。第一步是止血和保留证据：确认错误是否已经进入运行环境，冻结相关分支或发布，保留模型提示词、上下文文件、生成 diff、人工修改记录、日志和失败用例。第二步是复现和定位：用最小输入复现问题，做 diff 审查，判断是需求理解错、API 误用、并发或事务边界破坏、异常处理缺失、测试被错误修改，还是生成代码触碰了不该改的公共逻辑。第三步是修复：优先回滚或局部撤回有问题 diff，再由人重新确定设计约束，必要时让 AI 在更小范围内辅助生成补丁，但不能让它继续无边界改动。第四步是补防护：补回归测试、边界测试、静态扫描、代码 owner review、CI gate、危险文件保护和发布灰度。最后要沉淀 badcase，把这类失败变成 AI Coding 使用规范，例如只允许模型先给计划、限制改动范围、禁止直接改事务和权限链路、要求测试先红后绿。面试官想听到的是你能控制 AI 生成代码的风险，而不是只讲某次模型很离谱。

考点 止血和证据

难度 真实面经题

回答目标 让候选人把 AI Coding badcase 回答成完整工程质量闭环：能止血、能定位、能修复、能补测试和流程护栏，而不是只讲模型犯错的故事。

深入解析

先把问题升级为工程故障处理

严重错误代码的处理起点不是继续追问模型，而是确认影响面：是否合入主干、是否发布、是否影响数据、权限、资金、稳定性或用户体验。对未发布问题要冻结分支和 diff；对已发布问题要按故障流程止血、回滚或降级。这样回答能体现你把 AI Coding 放进真实工程流程，而不是把它当一次聊天失误。

保留模型输入和生成证据

定位 AI 误生成时，证据链很重要。需要保存提示词、提供给模型的上下文、模型生成的补丁、人工二次编辑、关联 issue、测试结果和运行日志。很多问题并不是模型单独造成，而是上下文缺失、需求约束没说清、人工接受 diff 时漏审，或者测试覆盖本来就不足。证据完整，才能判断根因。

用最小复现拆出失败类型

复现时要把问题缩到最小输入、最小接口和最小 diff。常见类型包括：模型误读业务规则、生成不存在或语义不一致的 API、破坏事务边界、漏掉并发锁或幂等、吞异常、误删校验、把测试改成适配错误实现。不同类型对应不同修复策略，不能只说重新生成一版。

修复优先最小回滚和人工重设约束

如果错误 diff 范围不大，优先局部 revert 或手工修正；如果改动已经污染多个模块，应先恢复到可信基线，再重新拆任务。继续使用 AI 时，要把上下文收窄到明确文件、接口契约、失败测试和不可改边界，让它只给候选补丁或解释，不再让它自由扩散修改。

把一次错误补成自动化防线

真正的解决不是这次修好，而是让同类错误以后更早被发现。可以补单元测试、集成测试、契约测试、并发或幂等用例、schema migration dry-run、静态扫描、secret scan、依赖漏洞扫描和危险命令拦截。AI 生成代码如果改到核心链路，还应触发更严格的 owner review 和 CI gate。

沉淀 AI Coding 使用规范

最后要把 badcase 变成流程规则：模型先输出计划和风险点，再生成代码；一次只改一个小目标；禁止无确认修改权限、事务、资金、状态机、迁移和公共基础库；必须展示 diff；测试不能只由模型自己改；合入前必须有人审查。这样能把单次事故转化为团队级质量资产。

易错点

只说模型生成错了，重新问一遍就好，没有工程止血、复现和证据链。
把所有责任都推给模型，忽略上下文缺失、人工接受 diff、测试不足和 review 漏洞。
修复时继续让 AI 大范围改动，导致问题从一个文件扩散到多个模块。
只补当前 bug，不补回归测试、契约测试、静态扫描或 CI gate。
让模型自己修改测试来证明自己正确，造成测试被错误实现牵着走。
编造某家公司真实 AI Coding 事故或内部模型指标，超出来源支持范围。

面试官追问

如果 AI 生成的代码已经上线，第一反应是什么？

先按线上故障处理：确认影响面，保护数据和用户路径，必要时回滚、降级或关闭开关；同时保留生成 diff、发布记录和日志。不能先花很久分析模型为什么错，止血优先。

如何判断问题是模型错，还是人给的上下文不够？

看 prompt、上下文文件、接口说明和约束是否包含必要信息。如果模型被要求改鉴权逻辑却没有权限模型、边界用例和历史兼容说明，那根因通常是上下文工程失败，而不仅是模型能力差。

修复时还应该继续使用 AI 吗？

可以，但要降权限和收窄范围。让 AI 解释失败用例、列风险点、生成小补丁候选；关键设计、diff 取舍、回滚和合入决定必须由工程师负责。

哪些代码区域不适合让 AI 自动改？

事务、权限、资金、状态机、并发控制、数据迁移、加密密钥、公共基础库和发布脚本都要非常谨慎。即使让 AI 参与，也应先出计划、只读分析或走强制人工 review。

如何把一次 AI badcase 变成长期收益？

把失败复现成测试，把错误类型写入 checklist，把危险文件加入保护规则，把缺失上下文补进任务模板，并把这类 prompt 和 diff 纳入后续 AI Coding 评估集。