最近经常看到这类标题："我们公司 90% 的代码都是 AI 生成的"、"AI 已经可以独立完成一个完整项目"、"程序员要被取代了"。作为一个从 2011 年开始写代码、经历了后端、大数据、可观测、AI 四个阶段的人，我想说几句可能不太讨喜的大实话。一、AI 的代码和人的代码能融合吗？
能，而且现在已经在融合了。但融合的方式不是很多人想象的那样。你：帮我写一个电商系统AI：好的，这是完整的代码 → 部署 → 上线 → 赚钱
你：帮我写一个用户注册接口AI：[生成 80 行代码]你：[看了一眼] 密码没做加盐哈希，SQL 有注入风险，错误处理缺了三种情况AI：[修改后重新生成]你：[再看] 好了，但这个数据库事务的边界不对，我来改这部分→ 最终代码：60% AI 写的 + 40% 人改的/补的
AI 代码和人的代码的融合方式，本质上跟高级工程师带初级工程师的模式一模一样——AI 出初稿，人来 Review、修改、补充关键逻辑。关键区别是：这个初级工程师速度极快（秒级出稿）、不会累、不会抱怨、知识面极广——但它没有判断力，不知道什么是对的，只知道什么看起来对。人力还能介入吗？不是还能，是必须介入。
2026 年的真实数据：大约 75% 的开发者会在合并（merge）之前手动审查 AI 生成的每一段代码。这不是因为他们不信任 AI，而是因为他们理解概率系统的本质——AI 生成的代码在大多数时候是对的，但大多数时候不等于每次都。在生产环境里，一个 1% 概率出现的安全漏洞就够你喝一壶的。 二、AI 现在到底能写到什么级别？
MVP 阶段（0 → 1，几十个用户）
这是 AI 写代码最擅长的阶段。一个 MVP 的特点是：功能简单、不需要考虑高并发、不需要复杂的安全策略、技术栈标准化。- 前端页面搭建（React / Vue / 纯 HTML）
一个有经验的人 + AI，可以在 1-3 天内完成以前需要 2-3 周的 MVP。 这是 AI 写代码价值最大的场景。初级阶段（几千用户，小团队产品）
AI 能力：⭐⭐⭐⭐ 能完成大部分，但需要人把关架构到了这个阶段，你需要考虑：基本的安全防护、数据备份、简单的性能优化、多人协作的代码规范。- 架构决策：用单体还是微服务？数据库选 MySQL 还是 PostgreSQL？这些决策需要考虑团队能力、业务发展方向、运维成本——AI 可以给建议，但你不能盲目采纳
- 安全设计：认证授权方案、数据加密策略、API 安全——AI 写的安全代码经常有"看起来对但实际有洞"的问题
中级阶段（百万用户，正规技术团队）
AI 能力：⭐⭐⭐ 能做执行层，但核心设计必须靠人百万用户级系统需要考虑的问题： 性能： 数据库读写分离、分库分表 多级缓存策略（本地缓存 + Redis + CDN） 异步队列削峰填谷 稳定性： 服务熔断、降级、限流 灰度发布、蓝绿部署 全链路压测 数据： 数据一致性（分布式事务） 数据迁移方案 备份恢复策略
这些问题 AI 能给你教科书式的答案，但教科书式的答案在真实系统里往往不好使。举个例子：你问 AI怎么做分布式事务，它会给你讲 2PC、TCC、Saga 模式。但在你的具体业务里，哪种方案最合适？Saga 的补偿逻辑怎么设计才能覆盖所有边界情况？在你的特定流量模型下，哪个方案的性能最好？——这些 AI 回答不了，因为它不了解你的具体上下文。这个阶段的 AI 使用方式从让 AI 写代码变成了让 AI 当参谋——你做决策，AI 帮你实现；你定架构，AI 帮你填充细节。高级阶段（月活过亿，大型技术团队）
到了这个级别，系统的挑战已经不是能不能写出来，而是能不能在极端条件下不崩：这些问题的核心不是代码怎么写，而是系统怎么设计——而系统设计需要的是对业务的深刻理解、对故障模式的丰富经验、对技术取舍的精准判断。- 代码审查辅助（发现常见问题，但复杂的架构问题发现不了）
📊 总结
规律很清晰：系统越复杂，AI 能独立完成的比例越低，人的价值越集中在设计和判断上。
三、90% 代码是 AI 生成的——真相是什么？
说实话，这个数字有很大的水分。这个数字是怎么来的？- 90% 的开发者在用 AI 工具 ≠ 90% 的代码是 AI 写的
- 90% 的代码行经过了 AI 辅助 ≠ 90% 的代码是 AI 独立生成的
真实的行业数据（2025-2026）：在高度采用 AI 工具的团队中，AI 贡献了大约40%-50%的最终提交代码。而且这 40%-50% 里，绝大部分是模板代码、CRUD、测试用例、文档——也就是重复性高、创造性低的部分。那些说90%的公司是怎么用的？我观察到的模式是这样的：
- 人定义需求和架构（5% 的时间，但决定了 90% 的方向）
- AI 生成初始代码框架和业务逻辑（AI 贡献的"量"在这里最大）
如果你按代码行数算，AI 贡献了 80-90%。如果你按核心逻辑的决策算，人贡献了 80-90%。90% 的代码是 AI 写的这句话，跟90% 的房子是工人建的一样——技术上没错，但忽略了建筑师的价值。四、为什么很多公司用了 AI 却没提效？
这是我最近跟很多技术团队交流后发现的一个普遍现象。买了 Copilot、Cursor、Claude，团队用起来了，但季度复盘的时候发现：交付速度没有明显提升，Bug 率反而上升了。原因有五个：原因一：把 AI 当代码生成器而不是协作伙伴
很多团队用 AI 的方式是：写一行注释，Tab 补全，看都不看就接受。这就像让一个实习生帮你写报告，你连看都不看就直接交给老板——出了问题你都不知道问题在哪。原因二：没有给 AI 足够的上下文
AI 不了解你的项目架构、编码规范、业务逻辑、历史决策。如果你只给它一个函数名让它补全，它只能根据通用模式猜——猜对的概率取决于你的场景有多标准。给 AI 的上下文越丰富，它的输出质量越高。顶级的 AI 使用者会在 Prompt 里附上架构文档、相关代码片段、编码规范、甚至之前的 Bug 记录。原因三：Review 环节断裂了
AI 提效的前提是 Review 效率能跟上。如果 AI 一天能写 200 行代码，但 Review 还是以前的速度（一天 Review 50 行），那瓶颈就从写代码变成了Review 代码。更麻烦的是：Review AI 代码比 Review 人写的代码更累——因为 AI 的代码风格可能跟团队不一致，命名可能不符合惯例，它看起来对的部分你需要额外验证。原因四：技术债加速累积
AI 写代码很快，但它不关心长期可维护性。它不会想三个月后另一个同事能不能看懂这段代码，它不会考虑这个设计模式在后续需求变更时还能不能适应。如果团队没有足够的架构治理能力，AI 加速产出的代码可能会迅速变成一个看起来能跑但没人敢改的屎山。原因五：对 AI 能力的预期不对
有些团队指望 AI 能写出高级工程师水平的代码。事实是：AI 的平均水平大概在中级工程师到高级工程师之间——但它没有高级工程师的判断力。它能写出结构合理的代码，但不能判断这个结构是否适合你的具体场景。它能实现你描述的功能，但不能质疑这个功能是不是真的需要。五、AI 提效 Coding 的前提条件
基于上面的分析，我总结出用 AI 提效编程的五个前提条件：前提一：你得能判断 AI 写得对不对
这是最基本的——你的技术水平必须高于 AI 的输出水平，否则你连 AI 的错误都发现不了。这就是为什么 AI 对高级工程师的提效远大于对初级工程师——高级工程师能在 5 秒内判断 AI 的代码有没有问题，初级工程师可能看了 5 分钟还是看不出来。前提二：你得有清晰的架构蓝图
AI 是一个超强的执行者，但它不是规划者。如果你自己都不知道系统该怎么设计，AI 不会帮你设计出一个好的架构——它只会给你一个看起来合理但可能在你的场景下完全不适用的方案。前提三：你得会给 AI 提供上下文
帮我写一个用户注册接口——这是一个糟糕的 Prompt。帮我写一个用户注册接口，使用 Spring Boot 3.2 + MyBatis-Plus + MySQL，需要支持手机号和邮箱两种注册方式，密码用 BCrypt 加密，注册成功后发送 Kafka 消息通知下游服务，要有完整的参数校验和异常处理，遵循 RESTful 风格，返回统一的 Result 包装类——这是一个好的 Prompt。你给的上下文越多，AI 的输出跟你的预期偏差越小。前提四：团队要有统一的使用规范
如果团队里 10 个人用 10 种方式跟 AI 协作，最终产出的代码风格会乱成一锅粥。你需要制定统一的：- 禁用清单（哪些代码不允许 AI 生成，比如安全模块、核心算法）
前提五：保持人的判断力不退化
这是最容易被忽视的。长期依赖 AI 写代码，你自己的编码能力和调试能力可能会退化——就像长期用导航开车的人，离了导航就找不到路。建议：定期自己从头写一些核心模块，保持手感。AI 是杠杆，但你是支点——支点软了，杠杆再长也没用。六、协作思维的本质
很多人把 AI 写代码理解为人跟工具的关系——就像你用 IDE、用 Git、用 Docker 一样。但 AI 不是一个工具，它更像一个永远在线的、知识面极广但缺乏判断力的协作者。1. 分工——知道什么给 AI、什么留给自己
给 AI 的： 留给自己的：✅ 模板代码 / 脚手架 ❌ 架构设计✅ CRUD 业务逻辑 ❌ 技术选型决策✅ 单元测试 ❌ 安全关键模块✅ 代码重构 / 格式化 ❌ 性能优化的核心逻辑✅ 文档生成 ❌ 跨系统的集成方案✅ Bug 定位（给足上下文时） ❌ 复杂的并发和一致性问题
2. 沟通——学会向下管理AI
跟 AI 协作就像带一个能力很强但没有业务经验的新人：- 给清晰的指令：不要说"写个好的接口"，要说"写一个满足这些具体要求的接口"
- 给足够的背景：告诉它项目的技术栈、架构风格、编码规范
- 分步骤来：不要一次让它写 500 行，分成 5 个 100 行的任务
- 及时纠偏：发现方向不对立刻打断，不要等它写完再推倒重来
3. 验证——永远不信任，永远要检查
Trust but verify ——信任但验证。AI 的代码可能在 95% 的情况下是对的。但你不知道你当前面对的是不是那 5%。所以每一段 AI 代码都要过脑子：逻辑对不对？边界情况覆盖了吗？安全漏洞有没有？性能可以接受吗？写在最后
AI 写代码这件事，不存在"AI 代码"和"人的代码"的对立。最终在生产环境里跑的，都是人负责的代码——不管它最初是谁写的。AI 改变的不是谁写代码，而是人在写代码这件事上的角色——从亲手写每一行变成设计、指导、审查、决策。这跟软件行业过去的每一次生产力革命一样：高级语言出来了，没有消灭程序员，而是让程序员从管理寄存器变成了管理业务逻辑；框架出来了，没有消灭程序员，而是让程序员从写 HTTP 解析变成了写业务接口。AI 出来了，不会消灭程序员，而是让程序员从写代码变成了指挥 AI 写代码。但指挥这件事，比亲手写更难——因为你需要更强的架构能力、更广的技术视野、更准的判断力。
夜雨聆风
