面试官问你：“AI 能写 80% 的代码了，公司为什么还需要你？”
本文数据和产品信息截至 2026 年 11 月 12 日。
这道题，在 2026 年 11 月又有了新含义
“AI 能写 80% 的代码了，公司为什么还需要你？”
这句话如果出现在面试里，它考的不是你会不会用 AI，而是：代码生成越来越便宜之后，你还能给团队提供什么？
先别急着争论“80%”准不准。这个数字没有统一的口径：是生成的字符数、代码行数、完成的任务数，还是最终合并进生产的代码？口径不同，结论能差出好几倍。
2026 年发表在《Management Science》上的一项研究，汇总了微软、埃森哲和另一家财富 100 强企业的三项随机试验，覆盖 4867 名开发者。使用 AI 代码补全助手的开发者，完成任务数增加了 26.08%，但各试验之间波动明显，初级开发者的收益更大。[1]
注意，这项研究测的是代码补全助手，不是今天的编程 Agent，也不能反推出“AI 只值 26%”。
所以，面试时没必要先反驳数字。更有力的做法是回答：如果 AI 真的能完成大部分实现，你准备怎样重新分工？
先更新认知：AI 早就不只是补全代码
如果回答还停留在“AI 只能写 CRUD”“AI 看不懂整个仓库”“AI 不能做 Code Review”，很容易被判断为过去半年没关注行业变化。
截至 2026 年 11 月，几款代表性产品已经走到了这里：
| 产品或公司 | 当前公开能力 | 需要注意的边界 |
|---|---|---|
| OpenAI Codex | GPT-6.1 Sol 强化 Agentic Coding；Codex 支持云端任务、跨设备续接、CLI 多任务管理和云端自动代码审查[2] | 官方能力发布不等于所有项目都能无人审查上线 |
| Anthropic Claude Code | Code Review 已正式面向 Team 和 Enterprise 开放，可自动审查 PR，多数审查约需 6—10 分钟[3] | 目前主要面向团队版和企业版，审查结果仍需结合项目判断 |
| Google Gemini | Gemini 4 Carbon 面向长程软件工程、全栈开发和持续 Agent 工作流，并接入 Antigravity[4] | 不同入口存在付费套餐和可用范围限制 |
| GitHub Copilot cloud agent | 能研究仓库、制定实现计划、修改代码、运行测试并创建 PR[5] | 一次任务只能修改一个仓库、一个分支并创建一个 PR |
| Cursor | Projects 可拆解长期项目并协调子 Agent；Rollouts 能结合日志、指标和链路追踪检查发布后的回归[6][7] | Projects 仍为 Beta；Rollouts 不会自行合并或回滚 |
| Factory、Devin | Factory Missions 会先澄清需求、生成验收契约，再由独立 Agent 验证；Devin Oncall 已进入告警调查和生产故障诊断环节[8][9] | Devin 公布的基准成绩包含厂商自测，不能直接外推到所有生产系统 |
国内产品也在沿同一路径快速演进：
- DeepSeek-V4.1-Flash-1017 的官方发布重点之一，就是从零构建完整项目，而不只是生成局部代码。[10]
- Qwen Code 已能接收 GitHub 提交、评审和 CI 失败事件，继续读取日志并修复问题；默认情况下，公开回复 PR 前仍需要用户确认。[11]
- Kimi K3.1 Pro 提供最高 100 万 Token 上下文；Kimi Code 支持远程 SSH、Docker 环境以及从运行中的会话分叉。[12]
这些产品说明了一件事：AI 正在从“生成代码的模型”，变成“参与研发流程的执行系统”。
需求分析、仓库研究、任务拆解、编码、测试、PR、代码审查、发布监控、故障诊断，开始出现 Agent 的身影。
这时候再把人的价值建立在“AI 不会写代码”上，就非常危险了。
三种旧回答，正在失效
旧回答一：“AI 写的代码质量不行”
这个回答的问题不是完全错误，而是把暂时现象当成了长期壁垒。
AI 确实会产生错误、安全漏洞和过度设计，但代码生成质量也在持续抬高。DORA 2025 的调查中，90% 的受访技术人员使用 AI，超过 80% 的受访者认为它提高了个人生产力，59% 认为它改善了代码质量。[13]
这是主观调查，不等于客观质量证明，但足以说明“AI 写的东西基本不能用”已经不是行业共识。
更稳妥的回答是：
AI 的输出仍然需要验证，但工程师的价值不应依赖它持续犯低级错误，而应体现在能否把它产生的错误限制在可发现、可恢复的范围内。
旧回答二：“AI 不理解业务，也没有系统视角”
这句话也需要修正。
Copilot 可以先研究仓库再制定实现计划，Factory Missions 会主动澄清需求、拆分里程碑并建立验收契约。Agent 并非完全不能吃上下文，也并非只能改孤立文件。[5][8]
真正的问题是：产品文档和代码仓库里，通常没有记录组织的全部约束。
例如：
- 这个历史接口不能改，因为还有一个未迁移的外部客户端在用。
- 这个方案技术上更优，但团队没人维护过对应的中间件。
- 这个流程看似可以自动化，实际涉及财务或合规的人工签核。
- 这个数据可以读，但不能进入第三方模型的上下文。
AI 可以给出方案，却未必天然知道这些隐性约束。
所以，人的价值不是垄断“架构设计”这四个字，而是把组织里的隐性约束显性化，并对技术取舍负责。
旧回答三：“Code Review 和线上兜底总要有人做”
需要人负责，不等于所有检查都该由人手工完成。
Claude Code 能自动审查 PR，Cursor 能监测发布回归并打开 revert PR，Devin Oncall 能调查告警、关联遥测并给出故障处理建议。[3][7][9]
如果个人价值只是“逐行看 AI 代码”或“半夜帮 AI 查日志”，这部分工作同样会被压缩。
更可靠的定位是：设计验证机制、控制自动化权限，并在关键节点承担决策责任。
更稳妥的回答，可以分成三层
第一层：AI 扩大实现能力，工程师定义目标与验收
假设要做“订单超时自动取消”。
Agent 可以完成定时任务、状态更新和测试代码，但真正需要定义的是：
- 支付成功与取消同时发生时，以哪个状态为准？
- 任务重复执行，如何保证幂等？
- 取消后，库存、优惠券、积分如何回滚？
- 第三方支付回调延迟，怎样避免误取消？
- 上线后看哪些指标，出现什么情况必须告警或停止任务？
这些问题并非 AI 完全不能列举。只要提示足够具体，它也能给出一份风险清单。
关键在于：哪些风险是上线阻断项，哪些可以后续优化，最终用什么证据证明功能做对了？
需求文档写完，不等于问题被定义清楚。工程师要把模糊想法转换成：
- 明确的业务边界；
- 可执行的验收条件；
- 必须覆盖的异常路径；
- 上线后可观测的指标。
一句话概括：
Agent 可以把功能实现出来，工程师要证明它实现的是正确的问题，并且结果可以被验证。
第二层：AI 能生成方案，工程师负责系统取舍
“AI 没有系统视角”已经不再是准确说法。它可以生成架构图、比较技术方案、拆解迁移步骤，甚至同时让多个 Agent 实现不同模块。
但架构设计从来不只是技术选项的比较。
选择单体还是微服务、同步调用还是事件驱动、JWT 还是服务端 Session，需要同时考虑：
- 当前业务规模，而不是想象中的未来规模；
- 数据一致性和故障恢复要求；
- 现有基础设施与历史系统；
- 团队认知成本与排障能力；
- 安全、合规与数据边界；
- 后续维护成本和退出方案。
Agent 建议引入消息队列，可能完全符合通用最佳实践，却不适合一个流量有限、缺少专职运维的小团队。
这不是 AI 答错了，而是它拿到的约束不完整。
因此，架构能力的价值正在从“亲手画出所有模块”转向：
- 给 Agent 提供足够的系统上下文；
- 明确哪些约束不能被方案突破；
- 识别不同方案真正交换的是什么；
- 用 ADR、评审记录和测试结果保留决策依据。
AI 能缩短提出方案的时间，却不能替团队消除取舍。
第三层：AI 能参与兜底，工程师设计权限并承担结果
“AI 不会被半夜叫起来修 Bug”这个回答，今天也只对了一半。
Agent 已经可以监视告警、读取日志、分析堆栈、提出根因，甚至准备修复 PR；但它应该拥有多大权限，仍然是工程团队必须回答的问题：
- 哪些系统只读，哪些目录允许修改？
- 能否访问生产日志和敏感数据？
- 自动修复需要附带哪些测试与运行证据？
- 什么情况可以直接生成 PR，什么情况必须升级给值班人员？
- 回滚、扩容、数据修改由谁批准？
- 出现误判时，如何停止 Agent 并保留完整审计记录？
Cursor Rollouts 目前不会自行合并或回滚，Qwen Code 默认也要经过确认才公开回复 PR。这些产品边界说明，当前更现实的方向不是完全无人值守，而是自动执行 + 证据验证 + 关键节点人工批准。[7][11]
Stack Overflow 2026 开发者调查也反映了这种态度：48% 的受访者在输出容易被验证时才信任 AI，只有 6.6% 愿意把它用于许多重要工作决策；使用 AI 答案前，76.5% 会本地运行，53% 会检查测试或安全影响，只有 9.6% 直接使用。[14]
这不是 AI 能力不足的证据，而是信任必须建立在可验证性上。
所以，责任层的核心动作不是“最后由人点一下回滚”，而是：
事前设计权限和验证机制，事中判断是否继续自动化，事后对影响范围和组织改进负责。
面试时，可以这样回答
AI 能写多少代码不是最关键的问题，因为它已经可以把仓库研究、计划、实现、测试、PR、代码审查和部分故障诊断串起来。工程师的价值不应建立在 AI 不会写代码上，而应体现在三个方面：第一，把模糊需求变成有边界、可验收的目标；第二，结合业务、团队和合规约束完成系统取舍；第三，为 Agent 设计权限、验证和升级机制，并对最终上线结果负责。低风险任务可以尽量自动化，高风险变更必须保留人工闸门。最终交付的不是一批生成出来的代码，而是一个可验证、可维护、可追责的系统。
这个回答没有贬低 AI，也没有神化 Agent，而是把人的价值锚在更稳定的位置上。
想再加分，就补一个真实案例
不要只讲理念，准备一个你亲自参与的项目，按下面的顺序讲：
- 任务是什么：业务目标、规模、主要约束。
- Agent 负责什么：仓库研究、方案、编码、测试还是故障排查。
- 发现了什么问题：缺失约束、异常路径、安全风险还是架构冲突。
- 你改变了什么：验收条件、技术方案、权限配置或上线策略。
- 最终如何验证：测试、灰度指标、监控结果和维护成本。
例如，可以这样组织案例：
在一个权限改造项目里，让 Agent 先研究仓库并给出实现方案，再负责页面、接口和测试。审查时发现它把部分权限判断只放在了前端，于是补充服务端鉴权、越权测试和审计日志作为验收条件，同时缩小了 Agent 可以修改的目录范围。最终上线前，不只看页面和单测是否通过，还要看越权用例、灰度错误率和权限日志。
这里体现的价值，不是“比 AI 多写了多少行”，而是补充了它不知道的约束，改变了交付标准，并控制了上线风险。
注意，案例中的数据必须来自真实项目，不要为了面试效果编造提升比例。
AI 时代，前端工程师该积累什么？
1. 需求拆解与验收能力
能把“做一个更好用的页面”转换成交互状态、异常路径、性能预算、兼容性要求和可观测指标。
2. 系统设计与上下文管理能力
不仅会选组件库和状态管理方案，还能给 Agent 提供正确的项目约束、架构边界、历史决策和禁止事项。
3. 验证与风险控制能力
测试、类型检查、安全审查、可访问性、性能监控和灰度发布，会比单纯手写实现更加重要。
4. 跨团队判断与责任能力
能协调产品、设计、后端和运维，知道什么时候可以自动推进，什么时候必须停下来重新定义目标和风险。
会使用 Claude Code、Codex、Cursor 或其他 Agent，正在逐渐成为基础技能。
真正的差异在于：谁能把 Agent 纳入一套稳定、可验证、可审计的交付流程。
最后
面对“AI 能写 80% 的代码了，公司为什么还需要你”，最差的回答是努力证明 AI 不行。
因为模型会继续升级，Agent 会继续进入更多研发环节，单纯依靠“它现在还不会做某件事”建立起来的优势，很可能只是暂时的。
更好的回答是：
代码只是软件交付的中间产物。公司真正需要的，是在不确定的业务环境中定义正确目标、作出系统取舍、控制工程风险，并对最终结果负责的人。
AI 越强，纯实现能力越容易被商品化；目标定义、系统判断、验证体系和责任能力，反而越值得长期积累。
如果下一次面试遇到这道题，你准备用哪个真实案例回答？
参考资料
- The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers — Management Science，2026-02-27
- OpenAI — DevDay 2026 Recap — 2026-09-29
- Anthropic — Code Review is now generally available — 2026-10-15
- Google — Gemini 4 Carbon is now available for developers — 2026-11-10
- GitHub Docs — About GitHub Copilot cloud agent — 持续更新
- Cursor — Cursor Projects — 2026-09-10
- Cursor — Rollouts and Security Review — 2026-09-23
- Factory — How Missions Work — 2026-04-10
- Devin — Introducing Devin Oncall — 2026-10-15
- DeepSeek — DeepSeek-V4.1-Flash-1017: Wish-Driven Programming Made Real — 2026-10-17
- Qwen Code Weekly — Remote Connections 与 GitHub Events — 2026-11-05
- Kimi Code Docs — What's New — 2026-11-04 更新
- Google — Inside the 2025 DORA Report — 2025-09-23
- Stack Overflow — 2026 Developer Survey: AI Data — 2026-10-06
