译：万亿美元的 AI 软件开发技术栈
原文： https://a16z.com/the-trillion-dollar-ai-software-development-stack/
作者： Guido Appenzeller and Yoko Li
译者： Gemini 2.5 Pro
发布于 2025 年 10 月 9 日
收听 Guido 和 Yoko 在 Apple 或 Spotify 上讨论万亿美元的 AI 软件开发技术栈。
生成式 AI 已经到来，而它引爆的第一个巨大市场就是软件开发。乍一看，这可能有点让人意外。从历史上看，开发者工具的市场规模从来都不是顶级软件类别。但仔细想想，这完全合乎逻辑，原因有二：(1) 开发者总是先为自己构建工具；(2) 这个潜在市场真的非常大。
不妨这样算一笔账：==全球大约有 3000 万名软件开发者，Evans Data 的数据是 2700 万，SlashData 的数据是 4700 万。如果我们假设每个开发者每年创造 10 万美元的经济价值——这个数字在美国可能偏保守，但在全球范围略高——那么 AI 软件开发的总经济贡献每年将达到 3 万亿美元。==根据过去 12 个月我们与数十家企业和软件公司的交流，我们估计，如今一个简单的 AI 编码助手就能将开发者的生产力提高约 20%。
但这仅仅是个开始。根据一些实例证据，我们估计，一套顶级的 AI 部署方案至少能将开发者生产力翻倍，从而带来每年 3 万亿美元的 GDP 贡献。这大约相当于法国的 GDP。硅谷和其他地方的一些初创公司开发的技术，对世界 GDP 的影响将超过世界第七大经济体所有居民的总生产力。
巨大的价值创造也带来了初创公司收入和估值的巨大增长。Cursor 在 15 个月内达到了 5 亿美元的 ARR 和近 100 亿美元的估值。Google 花了 24 亿美元进行了一次人才收购，从 OpenAI 手中抢走了 Windsurf。Anthropic 推出了 Claude Code，并向作为其主要分销渠道的 AI 开发者工具宣战。而 OpenAI 的 GPT-5 发布会，核心也全是关于编码。面对如此巨大的蛋糕，我们已经进入了 AI 软件开发的“战国时代”。
最初，AI 编码似乎只是一个单一的类别，但今天它已经发展成一个生态系统，有潜力支撑起数十家十亿美元级别的公司，甚至一个万亿美元的巨头。在过去几十年里，软件一直是人类进步和经济增长的主要驱动力。它颠覆了每一个行业，而现在，软件本身也正在被颠覆。AI 加速开发，以及模型成为软件新的基本构件，这两股力量的双重推动，很可能会让软件市场在质量和数量上都迎来巨大的扩张。市场规模也可能随之扩大（我们相信杰文斯悖论在这里同样适用）。
AI 编码技术栈会是什么样子？虽然现在还为时尚早，但下面这张图是我们今天所看到的景象。橙色方框代表着我们看到有大量初创公司正在构建的 AI 工具领域。每个类别都给出了一个例子。更多的例子以及与流程正交的其他类别，都在下面的市场版图中列出。
基本循环：规划 -> 编码 -> 审查
十八个月前，早期的 AI 编码还只是向 LLM 请求一段特定的代码，然后把生成的代码粘贴到源代码里，这种方式在今天看来已经很原始了。如今的工作流有时被称为规划 -> 编码 -> 审查 (Plan -> Code -> Review)。它从一开始就让 LLM 参与进来：首先为新功能制定一份详细的描述，然后确定需要做出的决策或需要的信息。代码生成通常由一个 Agentic 循环完成，可能还包括测试环节。最后，开发者审查 AI 的工作，并根据需要进行调整。
上图是一个启动新项目的简单工作流示例。模型被要求起草一份高级规范——但更重要的是，它被指示返回一份它所需要的额外信息的完整清单。在这个例子中，这份清单长达数页，包含了对一系列需求和架构决策的澄清。它还包括对 API 密钥以及完成工作所需工具和系统访问权限的请求。
最终生成的规范有两个作用：首先，它指导代码生成，确保意图与实现保持一致。但除此之外，规范对于确保人类或 LLM 能够持续理解大型代码库中特定文件或模块的功能至关重要。人机协作是迭代的：在人类开发者编辑完一段代码后，他们通常会指示语言模型修改项目规范，从而确保最新的代码变更被准确反映出来。这样做的结果是代码文档清晰，对人类开发者和语言模型都有好处。
除了项目特定要求，大多数 AI 编码系统现在都集成了全面的架构和编码指南（例如 .cursor/rules）。这些指南可能包含公司级、项目级甚至模块级的规则。我们看到网上出现了许多针对特定用例、为 AI 优化的编码最佳实践集合（如上例，更多关于 Cursor 的可以在这里的 GitHub 上找到，或者 Claude Code 的在这里），这些集合完全是为 LLM 设计的。我们正在见证第一批纯粹为 AI 而非人类设计的自然语言知识库的诞生。
在这种新范式下，AI 不再仅仅是响应提示的代码生成器。LLM 现在是真正的合作伙伴，帮助开发者进行设计和实现，做出架构决策，并识别潜在的风险或限制。这些系统对公司政策、项目特定指令、第三方最佳实践和全面的技术文档都有丰富的上下文理解。
用于 AI 规划的工具仍处于早期阶段。一些老牌公司和初创公司已经构建了一些应用，可以从论坛、Slack、电子邮件或像 Salesforce 和 Hubspot 这样的 CRM 系统中汇总客户反馈（例如 Nexoro）。另一批公司（例如 Delty 或 Traycer）则开发网站或 VS Code 插件，帮助将规范分解成详细的用户故事，并辅助处理票务流程（例如 Linear）。展望未来，很明显，像 wiki 和故事追踪器这类现有的记录系统也需要进行彻底的变革或被完全取代。
生成和审查代码
一旦我们有了可靠的计划，就进入了一个迭代循环：AI 编码助手生成代码，开发者审查代码。最佳的用户界面和集成点主要取决于任务的长度以及是否需要异步运行。
Tab 自动补全与编辑 无缝集成到现代编辑器或 IDE 中，例如 Cursor、Windsurf、Sourcegraph Amp 以及数十种 VSCode 插件。这个功能可以自动补全当前行或执行局部编辑，无需明确提示，因为 AI 会根据上下文直观地推断出所需的操作。该功能依赖于紧凑、高效的模型，这些模型都为这个特定目的进行了精细调整，以确保快速和准确的性能。
基于聊天的文件编辑 允许用户通过聊天提供提示和必要的上下文给 AI。这种方法利用了具有大上下文窗口的更强大的推理模型，可以在整个代码库上工作，并经常使用文件创建或添加包等基本工具。该系统可以集成到 IDE 中，也可以通过 Web 界面访问，为用户的每次操作提供实时反馈。
后台 Agent 的工作方式不同，它们可以在没有直接用户交互的情况下长时间工作。它们通常使用自动化测试来确保解决方案的准确性，这在没有即时用户反馈的情况下至关重要。其结果是一个修改后的代码树或一个提交到代码仓库的 pull request。例子包括 Devin、Anthropic Code 和 Cursor Background Agents。
AI 应用构建器和原型工具——例如 Lovable、Bolt/Stackblitz、Vercel v0 和 Replit——代表了一个快速增长的类别。这些平台可以根据自然语言提示、线框图或视觉示例生成功能齐全的应用程序，而不仅仅是 UI。如今，它们在构建简单应用的“感觉流”程序员和制作功能齐全原型的专业人士中都很受欢迎。虽然到目前为止，很少有 AI 生成的 UI 进入生产代码库，但这可能只是反映了这些工具目前还不够成熟。
为 AI Agent 设计的版本控制：随着 AI Agent 承担越来越多的实现工作，开发者关心的重点从代码如何改变，转向了为什么改变以及它是否有效。当整个文件一次性生成时，传统的 diff 就失去了意义。像 Gitbutler 这样的工具正在围绕意图而非文本重新构想版本控制——捕捉提示历史、测试结果和 Agent 的来源。在这个世界里，Git 变成了一个后端的账本，而真正的交互发生在一个追踪目标、决策和结果的语义层。
源代码管理系统集成 使 AI 能够审查 issue 和 pull request，并参与讨论。这种集成利用了源代码管理的协作特性，其中围绕 issue 或 pull request 的讨论为 AI 提供了宝贵的实现上下文。此外，AI 还能辅助审查开发者的 pull request，重点关注正确性、安全性和合规性。例子包括 Graphite 和 CodeRabbit 的解决方案。
如今编码助手的主要循环通常是 Agentic 的（即 LLM 决定下一步行动并使用工具，也就是 HF 框架中的 3 星级）。现在，像文本修改、库更新或添加非常简单的功能这类简单任务，通常可以完全自主完成。我们曾经历过一些神奇的时刻：GitHub 上关于功能的群组讨论，最终以一句简短的“请实现 @aihelper”评论告终，然后就得到了一个完美无瑕、随时可以合并的 pull request。但对于更复杂的需求来说，这还不是常态。
遗留代码迁移 一直是 AI 编码最成功的用例之一。（例如，参见此处）。常见的用例包括将 Fortran 或 COBOL 迁移到 Java，Perl 迁移到 Python，或者替换陈旧的 Java 库。一种常见的策略是，首先从遗留代码生成功能规范，一旦规范正确，就用它来生成新的实现，只在解决歧义时才参考旧代码库。我们看到这个领域正在诞生新的公司，而且市场非常巨大。
质量保证与文档
代码编写完成后，就需要集成测试和文档。这个阶段也催生了自己的一套专门工具。
为开发者和 LLM 编写的文档 – LLM 现在不仅非常擅长生成面向用户的文档，还擅长生成供 LLM 在运行时使用的文档。像 Context7 这样的工具可以在恰当的时机自动拉取正确的上下文——检索相关的代码、注释和示例——从而使生成的文档与实际实现保持一致。除了静态页面，像 Mintlify 这样的产品可以创建动态文档网站，开发者可以直接与问答助手互动，甚至提供 Agent，让用户通过简单的提示按需更新或重新生成某些部分。最后，AI 还可以生成安全和合规方面的专门文档，这在大型企业中非常重要。我们也看到这个领域出现了专门的工具（例如，用于合规的 Delve）。
AI 质量保证 (QA) – 开发者现在可以依靠 AI Agent 来生成、运行和评估跨 UI、API 和后端层的测试，而无需手动编写测试用例。这些系统的行为就像自主的 QA 工程师，它们会遍历流程，断言预期行为，并生成带有修复建议的错误报告。随着软件越来越多地由 AI 生成，AI QA 闭合了开发循环：不再是编码 -> 审查 -> 测试 -> 提交。在极端情况下，代码变得不透明，开发者唯一关心的就是正确性、性能和预期行为。
为 Agent 打造的工具
除了上述为人类开发者设计的工具外，还出现了一个专门为 Agent 使用而构建的独立工具类别。
代码搜索与索引 – 当处理大型代码库（数百万或数十亿行代码）时，已经不可能（更不用说成本上不可行）在每次推理操作时都向 LLM 提供整个代码库。相反，最好的方法是为 LLM 配备一个搜索工具来查找相关的代码片段。对于小型代码库，简单的 RAG 或 grep 搜索可能就足够了。对于大型代码库（例如，参见谷歌的这篇论文），能够解析代码并创建调用图的专用软件就成了必需品，以确保能找到所有引用。这个新兴类别包括像 Sourcegraph 这样的公司，它们提供分析大型代码库的工具，以及像 Relace 这样的公司提供的专门模型，帮助识别和排序相关文件。
网页与文档搜索 –像 Mintlify 和 Context7 这样的工具擅长生成和维护与代码相关的文档，它们从实时代码库中提取最相关的片段、注释和使用示例，以保持文档的准确和最新。相比之下，像 Exa、Brave 和 Tavily 这样的网页搜索工具则针对即时检索进行了优化，帮助 Agent 快速按需查找外部参考和长尾知识。
代码沙箱 – 测试代码和运行简单的命令行工具进行分析和调试，是 Agent 的一个重要工具。然而，由于幻觉或潜在的恶意上下文，在本地开发系统上执行代码存在风险。在其他情况下，开发环境可能很复杂，而自动化环境则具有确保测试可重复性的优势。像 E2B、Daytona、Morph、Runloop 和 Together’s Code Sandbox 这样的执行沙箱供应商解决了这一需求，并已成为 AI 开发技术栈中的关键组件。
市场版图
下面我们试图勾勒出更广泛的 AI 编码创业生态系统。布局大致遵循前面概述的软件开发生命周期，并增加了一些其他类别。公司排名不分先后。偶尔也包括一些老牌公司的产品。
软件开发正在如何改变？
基于 AI 的软件开发技术已经到来，现在组织需要将其投入运营。最近一个 Reddit 帖子问道：“Claude Code 实在太贵了，有什么优化的建议吗？” 成本确实可能很高：假设你的代码库占满了整个 100k 的上下文窗口，我们使用 Claude Opus 4.1 的推理模式，生成 10k 的输出和思考 token。按输入/输出每百万 token 15/75 美元的价格计算，每次查询的成本是 2.50 美元。如果扩大到每小时 3 次查询，每天 7 小时，每年 200 天，那么每年的花费大约是 10,000 美元。在许多地区，这已经超过了一名初级开发者的成本。
但我们认为，成本最终不会减缓 AI 开发工具的普及。像 Cursor 这样的许多平台通过同一个界面支持多种模型，并且擅长选择合适的模型来优化成本。即使是最便宜的模型也能带来巨大的好处。但讨论的焦点已经从“谁拥有最好的模型”转向了“谁能以合适的价格提供价值”。几十年来，软件开发的成本几乎完全是人力成本，但现在 LLM 增加了一个可观的运营支出 (opex) 部分。这是否意味着 IT 外包到低成本国家的终结？也许不会，但它确实改变了商业逻辑。
这一切对全球 3000 万软件开发者意味着什么？在可预见的未来，AI 会取代软件开发者吗？当然不会。这种无稽之谈是由媒体的耸人听闻和激进的市场营销共同造成的，他们试图将软件定价为对人力成本的替代，而不是按席位收费。历史告诉我们，虽然替代定价在早期市场有效，但最终商品的成本会趋向于其边际成本，定价也是如此。到目前为止，我们掌握的有限实际数据表明，最精通 AI 的企业反而增加了开发者的招聘，因为他们看到了大量短期内具有正投资回报率 (ROI) 的用例。
然而，软件开发者这个工作本身已经改变了，相应的培训也必须改变。 今天的大学课程将发生巨变；不幸的是，没有人（包括我们）真正知道该怎么变。算法、架构和人机交互仍然重要，甚至编码本身也很重要，因为你经常需要把 LLM 从它自己挖的坑里拉出来。但典型的大学软件开发课程，最好被看作是另一个时代的遗物，对今天的软件行业几乎没有实际意义。
从更长远来看，AI 编码技术栈允许软件自我扩展。例如，Gumloop 允许用户描述他们希望在产品中看到的额外功能，然后应用程序会使用 AI 编写代码来实现这个功能。这能走多远？我们是否能让 LLM 基于人类语言的 API 规范进行后期绑定，从而实现应用程序集成？普通的桌面应用会不会有一个“感觉流编码添加功能”的菜单按钮？从长远来看，一个应用程序作为不可变的代码发布，而没有任何自我扩展的能力，这似乎是难以想象的。
我们最终能完全消除代码，转而让 LLM 直接执行我们的高级意图吗（正如 Andrej 在这里建议的）？在最简单的情况下，这已经是现实了：ChatGPT 很乐意执行简单的算法。但对于更复杂的任务，编写代码仍然更优越，主要因为效率。在现代 GPU 上使用优化代码将两个 16 位整数相加大约需要 10^-14 秒。而 LLM 生成输出 token 至少需要 10^-3 秒。快 1000 亿倍足以构成一条护城河，我们预计代码还会存在很长很长时间。
是时候借助 AI 开始创造了
从历史上看，技术超级周期是创业的最佳时机，这次也不例外。AI 需要新工具，同时又加速了开发周期，这种结合对初创公司极为有利。以编码助手为例：微软的 GitHub Copilot 似乎势不可挡，它率先进入市场，拥有 OpenAI 的合作关系，排名第一的 IDE (VSCode)，排名第一的 SCM (GitHub) 和排名第一的企业销售团队。然而，多家初创公司都有效地与之竞争。在超级周期中，作为现有巨头是很难的。
我们正处于可能是自软件开发诞生以来最大革命的早期阶段。软件工程师正在获得使他们比以往任何时候都更高效、更强大的工具。最终用户则可以期待更多、更好的软件。最后但同样重要的是，历史上从未有过比现在更好的时机在软件开发领域创业。如果你想成为这场革命的一部分，我们 a16z 希望能与你合作！
及时了解 a16z Infra 团队的最新动态
订阅我们的 a16z 新闻通讯，获取关于重塑 AI 和基础设施最新趋势的分析和新闻。