软件3.0编码快如闪电，交付却卡在瓶颈

AI 极大地加快了编写代码的速度。这没得说。但我在多个构建移动和数字平台的团队中不断看到的是，这种速度提升很少能直接转化为更快的交付。它往往只是把瓶颈挪了个地方。

以前要写好几天的代码，现在几小时内就能生成，结果却要在 code review 里排队等审查，或者干等着测试。编码阶段加速了；其他环节根本跟不上。

AI 研究员 Andrej Karpathy 将这种转变称为软件 3.0：团队不再逐行手动编写代码，而是告诉系统他们要啥，然后让 AI 把大部分代码写出来。

在最近的一次采访中，Karpathy 透露，到 2024 年底，他自己写代码的比例彻底翻了个儿，从大约 80% 的代码由自己编写，转变为 80% 交给智能体来干。他认为，新的动词不再是“编码”，而是“许愿”——跟系统说你想要啥，它就去实现。

智能体时代已经到来，像 2025 年 5 月发布的 Claude Code 和 2025 年 10 月发布的 OpenAI 的 Codex 智能体等工具，早就不只是自动补全了。它们自己就能规划、写代码、调试一整个功能。

任何项目的初始阶段都基本零阻力。你一个下午就能从一个模糊想法搞出一个能跑的原型。然而，一旦初始版本必须融入实际产品，麻烦就来了。

新代码仍然需要跟已有的服务配合，处理真实的用户请求，并在平台其他地方更新时还得保持稳定。生成得快不代表这些步骤能省掉。它只是把这些活儿往后推，而且全堆在一块儿了。

工程团队最终花费更多时间来审查、集成和让输出稳定下来，这些输出是快速生成的，但无法全面了解整个系统。代码审查排队越来越长。测试套件的工作量倍增。

独立看完整的功能只有在所有内容连接并在真实负载下运行时，才会暴露出细微的不协调之处。

还有一个很少被讨论的更隐晦的挑战：开发人员在等待期间实际做了什么。与智能体一起工作意味着委派一个任务，然后干等着。

那些很好地利用这段时间的开发人员，通过准备下一个提示、在系统另一部分启动并行智能体或审查架构，正在获得累积的好处。而那些没有这样做的人则完全打乱深度工作的节奏。实际上，许多开发者也更愿意用AI工具来少干活，而不是多产出。

个人效率提高了，但团队的交付速度并不总是随之提升。我经常在我们自己的团队以及与我们合作的组织中看到这种情况。应对这种落差需要项目领导主动推进、明确的期望以及开发者心态真的要变。工具只占一半。

当整个流程追上来的时候

那些确实在整个周期（而不仅仅是编码阶段）实现了真正交付加速的团队，彻底改变了工作方式，而不仅仅是他们使用的工具。有三件事很关键。首先，前期在架构上投入。

html

当给予明确的结构性约束时，智能体能够产生质量好得多的输出。在写提示之前，投入大量时间进行系统设计，所节省的审查与集成工作量将带来数倍的回报。

其次，智能体查智能体。这意味着使用专门的审查智能体来检查生成的代码是否存在安全漏洞、架构一致性以及是否符合质量标准。这些智能体能及早发现问题，在问题流到下一环节之前就发现它们。

这还包括自动生成测试的智能体，它们根据测试人员编写的规范创建测试，并持续运行这些测试。在大型项目中，曾经需要数周手动工作的回归测试，现在只要很少的时间即可完成。

第三，给智能体提供合适的背景信息和能力。指令模糊，智能体输出的结果也模糊。这始于需求编写方式：结构良好的产品需求文档不光要让人看得懂，还要精确、详细到智能体能照着执行。

这还要把智能体连接到正确的信息源：连上设计系统，保持UI输出一致；连上项目管理工具，让智能体知道当前需求；连上文档，省得它们瞎猜。正是在这里，组织知识积累成持久的竞争优势。

具体怎么做，看情况而定。创业公司正引领潮流。现在融资比以前难，压力更大，得快速出成果，而早期阶段的团队能够迅速行动，不用管那么多安全和合规的限制。创业公司现在都是直接“氛围编程”搞出第一版。

html

大型企业往往更加谨慎，因为它们的系统更复杂，合规要求更严格，声誉风险也大得多。采用率在上升，但生成的代码在正式上线前会反复审查。

根据JetBrains《2025开发者生态系统现状》调查，85%的开发者现在经常使用AI编码工具，2025年编写的所有代码中有41%是AI生成的。这些工具无处不在，但围绕它们的纪律还没跟上。

工程师角色的转变

变化最根本的是工程师角色本身。开发者正在成为系统管理者而不是实现者。日常工作不再是编写优美代码，而是定义架构、管理AI代理的输出、确保安全性和兼顾可扩展性。

重心已从编写转移到验证和协调。Karpathy说得特别准：瓶颈不再是键盘。优秀的工程师现在哪怕用以前没学过的语言，也能干得很顺。前端和后端之间的隔阂正在消失。

一两个人就能把整个MVP做出来交付。以前要花几周验证的东西，现在一下午就能搞定，当天就能发给客户，这真正改变了投标和前期沟通中的竞争格局。

在模式已经成熟的地方，优势最明显：标准接口、可重复的工作流程以及常规业务逻辑。一旦超出这个范围，转向那些积累了多年历史的老系统，或者碰到安全、扩展性这类问题，人类的判断就越关键。

html

软件3.0真的来了。编码速度的提升是实实在在的，而且非常明显。

但最能从中获益的团队并非生成最多代码的团队，而是那些根据新情况重新调整工作流程的团队：提前在架构上投入、用代理来监督代理、给代理提供合适的工作背景，以及处理好因为工作方式彻底改变而产生的人际关系问题。

现在，瓶颈不再是写代码了。而是判断要做什么、怎么设计，以及代理生成的东西是否真的适合一个必须在真实环境下可靠运行的系统。这就是软件3.0时代的工程准则。

我们推荐了最适合写代码的大型语言模型（LLM）。

本文是TechRadarPro专家观点栏目的一部分，我们在此展示当今科技行业最顶尖的人。文章中的观点只是作者的个人看法，不代表TechRadarPro或Future plc。如果你想投稿，请点击此处了解更多：https://www.techradar.com/news/submit-your-story-to-techradar-pro