ARTICLE · 1113623
AI 写代码越来越快,软件工程的瓶颈正在转移
AI 写代码越来越快,软件工程的瓶颈正在转移从 Coding Agent 到 Software Factory，工程师需要重新理解自己的价值。 
假设一个团队让 AI 把编码速度提高了十倍，项目能不能提前十倍上线？ 大概率不能。 代码写出来以后，还要确认需求有没有理解错、测试有没有覆盖关键场景、改动能不能集成、上线后会不会破坏已有业务。 过去，这些问题常常被“代码还没写完”遮住了。现在，Coding Agent——能够读取代码、调用工具并执行修改的 AI 编程智能体——正在让它们变得更加显眼。 当代码生成越来越便宜，软件工程的稀缺资源，就开始向定义问题、验证结果和组织交付迁移。 理解这次迁移，比单独讨论“AI 会不会取代程序员”，更能帮助我们判断接下来该学什么、该建设什么。 2026 年秋季，Stanford 推出了 CS193V：Effective Vibecoding。 课程介绍中有一句引人注意的话：课程不预期要求学生手动阅读或编写代码。学生将借助 AI 编程工具，构建小到中等规模的软件项目。[1] 但同一份课程说明又明确建议：计算机专业学生应该选修 CS146S：The Modern Software Developer。 原因是，利用 AI 增强已有的软件开发能力，与让计算机代替自己写代码、自己不审查结果，是两种不同的技能。 CS146S 的课程介绍已经涉及上下文组织、Agent Skills、规格驱动开发、迭代反馈工作流，以及 Software Factory。[2] 这不是“计算机专业终于不用学编程了”的证据。它更像是一个信号： 让软件运行起来的门槛在下降，而对复杂系统负责，仍然需要工程能力。 做出一个演示，和交付一个可维护、可观测、可持续演进的系统，之间还存在很长一段距离。 先看一个简化的例子。 假设一个功能按顺序完成，需求澄清用 1 小时，编码用 6 小时，测试用 2 小时，审查和集成各用 1 小时，总计 11 小时。 如果 Agent 把编码压缩到半小时，而其他环节保持不变，总耗时就变成 5.5 小时。 编码速度提高了 12 倍，整个功能的完成速度只提高了 2 倍。 即使编码时间继续降到接近零，剩下的 5 小时也不会自动消失。 这个例子借用了 Amdahl 定律的直觉：局部加速的收益，受到其余环节的限制。真实开发中还存在并行、等待和返工，因此不能直接拿这个比例推算团队吞吐量。 但它说明了一个重要问题： 优化软件交付，需要找到当前瓶颈，而不能只盯着最容易加速的环节。 
Anthropic 在 2025 年对 50 万次 Claude.ai 和 Claude Code 交互的分析中发现，Claude Code 约 79% 的交互被归类为自动化，其中包括由人提供反馈的任务执行循环。[3] 这说明，工具的使用方式正在从“帮我补全代码”走向“替我执行任务”。但这个比例描述的是交互模式，并不意味着 79% 的开发工作已经被替代，也不能直接证明生产力提高了多少。 任务执行被加速以后，我们仍然需要知道：结果是否正确，是否值得交付。 2025 年，METR 做过一项随机对照研究：16 名有经验的开源开发者，在自己熟悉的代码库里完成 246 个真实任务。 开发者原本预计 AI 会让自己更快，完成任务后也仍然觉得效率提高了。但测量结果显示，在那个实验条件下，允许使用当时的 AI 工具，任务完成时间平均增加了约 19%。[4] 这个结果值得关注，也必须带上时间和场景。 METR 已在原页面标注：这一历史结果不再代表当前工具的影响。其 2026 年 2 月的后续说明认为，AI 带来的加速可能已经提高，但新实验存在参与者和任务选择偏差，不能可靠估计当前加速幅度。[5] 所以，这项研究不适合被用来断言“AI 编程没有用”。它更有价值的提醒是： 感觉更快、生成更快，与实际完成任务更快，是三件需要分别测量的事。 在成熟代码库里，正确性依赖大量没有写在当前需求中的知识：模块边界、历史兼容、并发约束、数据一致性，以及真实业务的异常场景。 Agent 可以很快产出一个看起来合理的修改。工程师却仍然需要确认，它有没有绕过已有抽象，有没有破坏某个隐含约束，有没有把问题转移到另一个模块。 因此，代码生成成本下降以后，验证能力的价值会更加突出。 可以把 Coding Agent 理解成一个依靠反馈不断修正行动的系统： > 读取需求 → 搜索代码 → 执行修改 → 运行验证 → 读取结果 → 再次修正。 模型很重要，但模型只是其中一部分。 Agent 还需要理解产品要解决什么问题、业务规则是什么、技术方案有哪些约束，以及项目如何构建、验证和交付。 这需要一个前提：团队拥有完善且持续更新的产品与技术文档，并建立顺畅的协作流程和反馈机制。文档要能够被找到、被理解，与实际系统保持一致；流程要让需求疑问、验证失败和上线后的问题，都能及时回到相应的责任人和下一轮改进中。 设想两个使用同一模型的团队。 第一个团队的产品规则散落在聊天记录里，技术文档没有跟上系统变化，构建依赖个人电脑配置，模块约束主要靠老员工记忆。需求、开发、测试之间反复交接，问题出现后也缺少明确的反馈路径。Agent 做几步就需要找人确认，人也要不断补齐上下文。 第二个团队有完善且持续维护的产品与技术文档：产品目标、业务规则、验收标准、系统架构和接口约束都有清晰依据。在此基础上，团队还提供可重复的开发环境、明确的仓库说明、稳定的构建入口，以及能够定位问题的测试和日志。 更重要的是，需求澄清、开发、验证、审查和发布衔接顺畅；测试失败能提供可定位的信息，需求歧义能得到及时确认，上线后的异常和用户反馈也能转化为新的任务，并在修复后重新验证。 在任务边界和权限明确的情况下，Agent 才更有条件完成连续步骤，人也更容易判断结果是否符合产品目标。 差异不仅来自模型，还来自文档、流程、工具和反馈共同构成的工程环境。 这也是建设 Agent-Ready Codebase 时需要关注的基础：让产品规则、技术约束、执行工具和反馈机制，能够被 Agent 找到、理解并使用。 
对团队而言，比起只问“它能独立运行多久”，更值得一起观察的是： 自主运行时间可以是辅助指标，但长时间执行本身不代表可靠，也不代表有价值。 产品经理说：“这里加一个库存同步。” 这句话表达了意图，却还没有定义什么算正确。 是全量同步还是增量同步？重复消息能不能重复扣库存？断网后如何恢复？两个终端同时修改时，以哪个结果为准？旧版本客户端还能不能正常工作？ 资深工程师往往会主动补齐这些问题。Agent 如果没有组织上下文，就可能生成一个能编译、能演示，却没有覆盖关键边界的实现。 因此，越多工作交给 Agent，越需要把隐性经验转化为明确约束。 一份有效的任务规格，至少应该讲清楚：目标行为、修改范围、不能破坏的约束、异常处理，以及验收证据。 测试则把其中一部分约束变成可执行的检查。 编译器发现类型错误，单元测试检查局部规则，集成测试检查模块协作，业务验收检查真实流程。它们既帮助人判断结果，也为 Agent 提供下一步修正的依据。 但这里有一个边界：自动化检查覆盖的是已经定义并实现的检查项。 测试通过，不能证明需求本身正确；CI 通过，也不能证明所有真实设备、外部系统和用户场景都已验证。 如果 Agent 根据同一个错误理解，同时写了实现和测试，两者完全可能一起通过。 这意味着，我们需要根据风险，引入来自需求、业务规则、既有回归用例或独立审查的验证依据。 DORA 在 2025 年将 AI 描述为一个“放大器”：它会放大组织已有的优势，也会放大已有的问题。[6] 2026 年 3 月，DORA 的一篇分析进一步指出：初始代码生成节省的时间，经常重新花在审计和验证上；更高的 AI 采用程度，与更高的交付吞吐量和更高的交付不稳定性同时相关。[7] 注意，这里说的是相关关系，不能据此认定 AI 必然导致不稳定。 不过，从工程流程看，确实存在一种容易理解的风险。 假设团队每天能处理 12 个 PR，过去每天提交 10 个，审查队列基本可控。 引入 Agent 后，如果每天实际提交 40 个，而处理能力仍然只有 12 个，在没有其他限流措施的情况下，队列就会持续增长。 更多代码进入审查，并不等于更多功能已经交付。等待、上下文切换、冲突和返工，都可能吞掉局部加速带来的收益。 因此，AI 时代的审查体系需要同时改变： Review Agent 可以帮助发现问题，但多个 Agent 也可能共享相同的错误理解。增加一个“同意”的回答，并不会自动增加一份独立证据。 尤其涉及权限、资金、数据迁移或公共接口的改动，仍然需要明确的责任人和审查边界。 讨论 Software Factory 时，很容易先想到“一群 Agent 并行写代码”。 但一个能持续运转的软件生产系统，需要连接更多环节： > 用户意图 → 任务规格 → 计划与实现 → 验证与审查 → 发布 → 运行观测 → 下一轮修正。 
其中，运行后的反馈尤其重要。 软件有没有实现用户目标？失败率有没有上升？性能是否退化？新的异常能否回到可定位、可复现、可验证的任务中？ 如果这些反馈没有进入下一轮开发，团队即使能够快速生成代码，也很难持续改善系统。 对多数团队来说，建设这样的流程，可以从一条小而完整的路径开始： 第一，选一类边界清晰的任务。优先选择结果容易判断、修改容易回滚、影响范围可控的工作。 第二，把验收写在实现之前。明确正常流程、关键异常和兼容要求，减少“写完以后再解释目标”。 第三，让验证能够重复执行。提供稳定的构建、测试和检查入口，让人和 Agent 使用同一套证据。 第四，按风险设置权限与审查。Agent 能编辑文件，不意味着它应该自动拥有所有发布和生产操作权限。 第五，测量最终效果。关注交付周期、人工审查时间、返工、缺陷和业务结果，而不是只看生成了多少行代码。 这些工作可能没有换一个新模型那么醒目，却决定了模型能力能否转化为团队能力。 工程流程的变化，也会影响人才培养。 Stanford Digital Economy Lab 在 2026 年 8 月更新的研究中指出，尚未观察到与 AI 相关的全经济范围广泛岗位替代。 但截至 2026 年 6 月，在 AI 高暴露职业中，22—25 岁劳动者的就业，相对于低暴露同龄群体的增长轨迹，出现约 19% 的缺口；经验丰富的劳动者没有出现同样的缺口。[8] 这里的 19% 是相对增长轨迹的就业缺口，并不是“19% 的年轻程序员被 AI 替代”。研究也明确指出，这些是描述性模式，不能单独确定 AI 的因果影响。 SignalFire 的 2026 年行业报告则显示，在其定义的 12 家大型科技公司样本中，整体招聘较 2019 年低约 25%，应届及入门岗位招聘低约 65%；软件工程师占招聘的比例，却从 46% 上升到 55%。[9] 这是基于其自有数据的行业观察，不是整个劳动力市场的结论；占比上升也不等于招聘绝对人数上升。 这些数据提出了一个需要认真面对的问题：如果越来越多基础实现由 Agent 完成，新人如何积累判断复杂系统所需的经验？ 过去，工程师通过写代码、踩坑、调试和复盘，逐渐理解系统。现在，团队需要主动保留并重新组织这些学习机会。 新人可以先写验收条件，再检查 Agent 的实现；可以解释一个改动为什么安全，而不只演示它能够运行；可以参与线上问题复盘，理解测试没有覆盖的真实场景。 遇到关键模块，也仍然需要亲自读代码、调试，必要时手动实现，建立对机制的理解。 更强的工具，可以缩短完成任务的路径；工程经验仍然需要通过理解、实践和反馈积累。 当候选答案越来越便宜，选择和验证答案的能力，就会更加重要。 Agent 给出三种架构，哪个适合当前业务？写出了五百行代码，哪些地方隐藏着兼容和并发风险？测试全部通过，验收条件有没有遗漏真正重要的场景？ 回答这些问题，需要编程基础，也需要业务理解、系统设计、验证方法和交付经验。 因此，工程师可以把更多精力投入三个方向： 把问题定义清楚。让目标、约束和验收条件能够被共同理解。 把结果验证扎实。 用足够的证据区分“看起来合理”和“可以交付”。 把流程建设完整。让一次成功能够重复，让一次失败能够被发现、定位和修正。 Coding Agent 正在改变代码的生产方式。Software Factory 提出的，则是如何组织整个软件交付系统。 代码可以生成得越来越快。工程师的价值，会越来越体现在能否把这些代码变成值得信任的软件。 参考资料： 1. [Stanford CS193V Effective Vibecoding](https://web.stanford.edu/class/cs193v/syllabus) 2. [Stanford CS146S：The Modern Software Developer](https://themodernsoftware.dev/) 3. [Anthropic：AI 对软件开发的影响](https://www.anthropic.com/research/impact-software-development) 4. [METR：2025 年初 AI 对资深开源开发者生产力的影响](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) 5. [METR：2026 年开发者生产力实验更新与设计调整](https://metr.org/blog/2026-02-24-uplift-update/) 6. [DORA：2025 年 AI 辅助软件开发报告](https://dora.dev/research/2025/dora-report/) 7. [DORA：从 AI 采用走向有效的软件生命周期实践](https://dora.dev/insights/balancing-ai-tensions/) 8. [Stanford Digital Economy Lab：年轻劳动者就业缺口的 2026 年更新](https://digitaleconomy.stanford.edu/news/canariesaug26/) 9. [SignalFire：2026 年人才报告](https://www.signalfire.com/blog/signalfire-state-of-talent-report-2026)
01｜Stanford 的两门课，指向两种不同的能力
02｜编码快了十倍，交付为什么只快两倍？
03｜AI 可以生成代码，可靠性需要证据
04｜同一个模型，为什么在两个团队里表现不同？
在明确验收标准下，有多少任务能够完成； 每个任务需要多少次人工介入； 审查和返工消耗了多少时间； 交付后的缺陷和总成本有没有改善。
05｜规格和测试，正在成为更重要的生产资料
06｜当 PR 越来越多，审查会不会成为瓶颈？
让格式、类型、常见规则等检查更早发生； 把大改动拆成能够理解、验证和回滚的小批次； 根据风险决定需要什么证据、由谁审查； 限制同时推进的任务数量，保护集成能力。
07｜Software Factory，要把交付接成闭环