2023年还在讨论"AI会不会取代程序员"，2024年Codex、Claude Code、Gemini相继上线，2025年这个问题已经没人问了。不是因为有答案，而是因为答案正在以周为单位刷新。
OpenAI内部流传一套四阶段模型，把AI编程的演进路径切得清清楚楚。第一阶段叫"AI辅助"，Copilot那种代码补全；第二阶段"混合协作"，多个专业Agent分工；第三阶段"自主交付"，人写需求AI写代码；第四阶段"AI原生文化"，系统自己迭代自己。这套框架被硅谷多家公司直接拿去当转型路线图，国内大厂也在偷偷对标。
从"工具"到"同事"：Agent正在抢走什么
第一阶段的老玩家最熟悉。Cursor、Windsurf、GitHub Copilot，本质上都是高级自动补全。工程师仍是主驾，AI坐副驾，偶尔帮你打转向灯。2022年到2024年初，这是主流形态，也是大多数人理解的"AI编程"。
第二阶段开始变味。Architect Agent画架构、Coder Agent写实现、Reviewer Agent查漏洞，人类从"写代码"变成"指挥Agent"。OpenAI工程团队透露，他们内部项目已有60%代码由Agent生成，工程师主要工作是Review和调Prompt。这个比例在2024年中还是30%。
第三阶段是当下战场。High-Level Specification（高层级规格说明）成为核心交付物，产品经理写几页PRD，AI直接出可运行代码。Anthropic的Claude Code今年3月演示过一个案例：输入"做一个支持OAuth的登录页面"，15分钟后拿到完整前后端实现，包括测试用例。人类只干了三件事：确认需求边界、验收业务逻辑、签字部署。
第四阶段目前只有理论图景。系统基于生产反馈自动优化，Bug自己修、性能自己调、功能自己加。听起来像科幻，但Netflix的混沌工程团队已经在实验"自愈合微服务"——AI监控异常、定位根因、生成补丁、灰度验证，全程无人介入。
Spec-Driven Development：新工种正在诞生
AI-Native Engineering倒逼出一种新开发范式：Spec-Driven Development（规格驱动开发）。传统流程是需求→设计→编码→测试，新流程是规格→AI生成→人工验证→持续迭代。编码环节被压缩到接近零。
这直接冲击了两个群体的饭碗。初级工程师的产出被AI覆盖，中级工程师的Review工作被AI替代，只有能写清楚Spec、能判断业务逻辑对错的人留在牌桌上。某头部云厂商技术VP私下透露，他们2024年校招HC砍掉40%，同时社招"AI工程架构师"岗位薪资开到P8+级别。
Spec的质量决定一切。同样的需求，菜鸟写的Spec生成代码可用率30%，老手写的可用率90%。差距不在Prompt技巧，在对业务边界的理解、对异常场景的预判、对系统耦合度的敏感度。这些恰恰是传统"码农"技能栈的短板。
OpenAI技术负责人Evan Morikawa在内部文档里写过一句判断：「未来5年，软件团队的规模会缩小50%，但产出会增长10倍。」这句话没公开说过，但在硅谷工程师圈子里传得很广。
国内玩家的真实进度
字节跳动的Trae、阿里的通义灵码、百度的文心快码，目前都卡在第二阶段向第三阶段过渡。Trae的Multi-Agent模式支持规划Agent、编码Agent、调试Agent协作，但人类仍需频繁介入。一位字节工程师评价："能用，但离'扔个PRD就出产品'还差两代模型。"
真正的差距在组织层面。硅谷公司敢把生产权限放给AI，国内大厂还在"AI生成代码必须人工Review"的红线前徘徊。不是技术问题，是追责机制没跟上——AI写的代码出事故，算谁的？
蚂蚁集团今年Q1内部试行了一个项目：支付核心链路的小需求，由产品经理直接提Spec，AI生成代码，自动化测试通过即上线。试点三个月，需求交付周期从14天降到3天，线上故障率反而下降15%。关键设计是"回滚权限比上线权限更重要"，出任何问题30秒内自动回滚，再人工介入。
这个案例被写进阿里技术年会材料，标题叫《从"写代码"到"写Spec"：一个支付团队的18个月》。里面有个细节：团队里最值钱的人不再是技术大牛，而是一个干了8年业务的产品经理——只有他能把"用户输错密码3次后冻结账户"这类需求，拆解成AI能理解的边界条件和异常分支。
还在学Python的人，可能学错了
技术社区的焦虑感在蔓延。Stack Overflow 2024开发者调查显示，"担心AI取代工作"的比例从2023年的28%飙升到62%。但细分数据更有意思：工作5年以下的工程师焦虑度78%，工作10年以上的焦虑度41%。
分水岭在于技能树。年轻工程师的核心竞争力是"写代码快、框架用得熟"，这些正被AI碾压。资深工程师的核心竞争力是"定义问题、权衡取舍、预判风险"，这些AI还做不了。
一个残酷的对照：2024年硅谷多家公司裁员"传统全栈工程师"，同时高薪挖"AI产品经理"——这个岗位的要求是"能写代码看懂技术边界，但主要职责是写Spec和验收AI产出"。薪资对标Staff Engineer（资深工程师），汇报线却挂在产品部门。
国内某一线基金的投资人最近改了看项目的标准：「以前问'技术团队多少人'，现在问'多少需求能由AI端到端交付'。」他投的一家企业服务公司，30人团队服务2000家客户，核心壁垒是一套自研的Spec规范——客户填表单，AI生成定制化SaaS，人工只处理边界Case。
这套模式跑通后，他们客单价降到传统厂商的1/5，续约率反而更高。因为交付快、改需求快，客户爽了。代价是团队里没有"程序员"这个title，只有"Spec工程师"和"客户成功"。
OpenAI的四阶段模型有个隐藏假设：越往后，组织对"人"的依赖越集中在最上游和最下游。上游是定义问题，下游是验收结果，中间环节逐步自动化。这个假设如果成立，现在正在学LeetCode、刷八股文的年轻人，可能正在为一个不存在的岗位做准备。
当然，技术演进总有意外。2024年底Claude 3.5 Sonnet一度被认为"能替代中级工程师"，实际落地中发现复杂系统的架构一致性仍是硬伤——AI生成的代码能跑，但和现有系统的设计风格、抽象层次、错误处理模式格格不入。一位架构师吐槽："就像请了个手艺很好的装修队，但每间房风格都不一样。"
这个问题目前无解。Spec能定义功能，很难定义"味道"。而"味道"恰恰是大型软件系统可维护性的核心。所以第四阶段的"AI原生文化"究竟能不能到来，还是卡在第三阶段形成新的稳态，现在没人敢下结论。
如果你今天必须做一个选择：是花三个月精进React性能优化，还是花三个月练习把业务需求写成AI能执行的Spec？后者的复利可能更长久，但也更孤独——因为市面上还没有成熟的课程、认证、职业路径，只有几家公司在暗中试错。
那个蚂蚁集团的试点项目，最后留下了一个开放问题：当产品经理能直接驱动代码生成，技术团队的存在形态会变成什么？他们的实验结论是"从交付团队变成治理团队"，但这个结论本身，可能再过18个月又要重写。
热门跟贴