核心要点
质量责任仍在人：AI 可以写代码，但设计取舍、风险判断和最终合入责任必须由工程师承担。
小步提交更安全：把 AI 生成拆成小 PR、小 diff、小测试，避免一次性合入看不懂的大段代码。
门禁要自动化：类型检查、单测、集成测试、安全扫描、依赖扫描和代码评审都要变成必过关卡。
重点看高风险区域：权限、支付、数据一致性、并发、隐私和迁移脚本不能因为 AI 生成就降低评审标准。
标准回答
一、核心回答
二、可以先把问题从“AI 写了多少代码”改成“这些代码能不能被验证”。
如果团队里 80% 代码都由 AI 生成，我不会简单禁止，也不会无脑拥抱。我的做法是把 AI 当成一个很快的初级同事：它能提高产出速度，但合入前必须经过清晰需求、人工评审和自动化质量门禁。
三、面试补充
第一步是限制输入和范围。 让 AI 做明确的小任务，比如补测试、写样板、改一个组件、重构一个函数，而不是一句话让它“重写整个系统”。需求里要写清楚接口、错误处理、性能约束和不能碰的边界。
第二步是建立合入标准。 每个 AI PR 都要过类型检查、lint、单元测试、关键链路集成测试、安全扫描和人工 code review。评审时评审时重点问：这段代码代码是否能被解释？异常路径有没有测？是否引入新依赖？有没有权限或数据泄露风险？
第三步是上线后可回滚。 AI 生成代码越多，越需要灰度、监控、告警和快速回滚。质量不是靠“相信模型”，而是靠工程闭环兜底。
常见误区
⚠️ 常见踩坑
误区一：觉得 AI 生成代码就可以少评审。实际更要评审，因为它可能写得很像真的，但边界条件是错的。
误区二：只统计 AI 代码占比，不看缺陷率、回滚率、测试覆盖和交付周期。占比只是表象，质量指标才是核心。
追问
追问 1：哪些代码你会让 AI 多写，哪些会特别谨慎？
适合多写的是低风险、可验证的代码，比如测试、脚本、样板组件、接口适配、文档和机械重构。要谨慎的是高风险代码，比如鉴权、支付、数据迁移、并发控制、加密、隐私处理和核心业务规则。这些地方可以让 AI 给建议，但合入前必须人工逐行理解。
追问 2：如果 AI 代码 review 压力太大怎么办？
可以从流程上降压：限制单个 PR 大小，要求 AI 同时生成测试和变更说明；用 CI 自动挡掉格式、类型、安全和覆盖率问题；再把人工 review 聚焦在设计、边界条件和风险点上。不要让人类去肉眼检查所有机械问题，机器能挡的先让机器挡。
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
