软件正在被重写，以适应 AI 智能体和人类开发者，既是终端用户也是合作者的新架构。传统 SaaS 时代的旧模式正被定价、产品设计以及如何构建具备可防御性的开发者业务等领域的新现实所取代。在我们最初的开发者法则发布十二年后，以及 v1 修订版问世六年之后，我们正尝试在 AI 范式下，对这些法则进行重起草和重新审视。
这些规则仍在完善中，它们是针对 AI 智能体所塑造的格局，为构建开发者平台而提出的 v2修订版，其来自于 Anthropic、Cursor、Port、Fal AI、Fern、Render、Appwrite、Netlify、Recall、Vapi、Resolve AI、Graphite、Marimo 和 Resend 等公司的领导者。
随着企业迈向 AI 驱动的软件创新浪潮，开发者平台一如既往地引领着新时代基础设施的发展。最初的“开发者平台八大法则” (2013) 及其 2019 年修正版，见证了 DevOps、开源、云原生架构和 API 优先生态系统的崛起。如今，在 2025 年，一种新的范式已然浮现：智能体开发 (agentic development)，即 AI 智能体与开发者协作，大规模地设计、构建、部署和维护软件。
AI 开发者平台的八大法则
法则 1：智能体体验 (Agent Experience, AX) 与开发者体验 (Developer Experience, DX) 同等重要
今天的开发者平台需要对智能体体验 (Agent Experience, AX) 和开发者体验 (Developer Experience, DX) 给予同等的关注。在许多方面，开发者体验直接指导并增强了智能体体验。这包括文档的全面性（将在法则 2——“文档必须平等地服务于模型和人类” 中进一步讨论）、API 接口广度 (API surface area) 以及易于理解的模式 (schemas)。过去五到十年里对 OpenAPI 规范、REST API 和 SDK 的所有投入，都使人类和智能体更容易使用产品。
“与其将 开发者体验视为智能体体验的对立面，我们发现所有为改善开发者体验 所做的更改实际上都在提升智能体体验。例如，我们投入大量时间试图让人类用户的入门流程尽可能简单。事实证明，这对让智能体也开始使用 Resend 产生了巨大的影响。”
—— Resend 首席执行官 Zeno Rocha
然而，人类和智能体的能力要求和结构也存在差异。人类开发者可以解释模棱两可的文档并适应不一致的 API，而智能体需要结构化、可预测的交互界面。这意味着需要具有全面错误处理的 OpenAPI 模式、用于多步骤工作流的会话持久性 (session persistence) 以及像 WebSocket 这样流式传输的实时反馈机制。例如，Netlify 的部署智能体必须在整个 CI/CD 管道中保持状态 (maintain state)，同时提供即时构建反馈，而这些是传统开发者工具未被设计处理的要求。
其次，诸如模型上下文协议 (MCP) 之类的协议的出现，代表了开发者工具服务用户方式的根本性转变。许多公司现在正在使用像 Prefect 的 FastMCP 这样的解决方案来托管自己的 MCP 服务器，因为他们知道开发者正在 Cursor 和 Claude Code 中工作。这意味着在他们的集成开发环境 (IDEs) 中，开发者可以增强其智能体，使其直接访问平台的实时数据并代表他们执行操作。
最后，我们开始思考仪表板在调试、监控和日志记录中的作用。如今，人类直接登录仪表板作为信息收集的统一信息中心 (central pane of glass)。像 Recall 这样的团队已经开始通过 API 使所有仪表板功能可访问，因此今天的智能体也可以为问题解决做出贡献。与此相关的是，关于减少甚至消除智能体的上下文切换 (context switching)（版本控制、集成、使用 API、推送到生产环境 (prod)）的开放性问题依然存在。这种趋势已经在发生，因为 MCP 服务器使智能体能够提取实时信息并执行命令，而开发者无需切换到仪表板或命令行界面 (CLIs) 来进行上下文切换。
法则 2：文档必须平等地服务于模型和人类
文档在一个工程团队内部通常是善意的产物，但往往维护不善，未能及时捕捉实时变化，反映的指南已经过时。访问这些文档的开发者虽然常常感到沮丧，但自然会接受一定程度上的不完整或不完美。
相反，对于大语言模型 (LLMs) 来说，将带有导航、广告和 JavaScript 的复杂 HTML 页面转换为对 LLM 友好的纯文本既困难又不精确。智能体则从集中在一个易于访问位置的简洁、专家级信息中受益匪浅。这对于像开发环境这样的用例尤其重要，在这些用例中，LLMs 需要快速访问编程文档和 API。LLMs 还需要最新的结构化 API 参考资料，以及跟踪人类和智能体动作的审计日志。这些要求迫使人们对信息架构进行根本性的重新思考。
这也是生成引擎优化 (GEO) 发挥作用的地方。正如搜索引擎优化 (SEO) 确保搜索引擎的可发现性一样，GEO 确保模型能够快速解析并呈现文档中的准确答案，使开发者保持心流状态 (in flow)，而不是被上下文切换的搜索打断。
随着编码智能体的扩散，技术文档成为一种双重用途的产品资产——公司需要的文档必须有效地服务于智能体和人类开发者这两种受众，具备适当的版本控制、变更管理，以及对智能体的可发现性，同时对人类开发者保持有用。
“开发者想要一个精美的文档网站，而智能体需要干净的 Markdown 来解析。团队的趋势是采用‘文档即代码’ (docs-as-code) 的方法，其中文档首先以 Markdown 编写，然后作为对开发者友好的网站和机器可读文件（如 llms.txt）发布。”
—— Fern 的联合创始人
法则 3：定价策略仍然专注于减少入门摩擦
定价必须同时考虑成本结构和价值交付。这对于 AI 公司来说尤为突出，因为在传统 SaaS 中，服务边际用户的成本为零，而在 AI 原生应用中，由于推理成本，这成为一个重要的成本项。为了解决这个问题，我们观察到服务于开发者的公司目前正在尝试几种定价路径：
基于使用量的定价，由于产品极高的实用价值而驱动客户内部账户的大规模扩张。所有平台都在用 AI 重新集成，并且像每一波浪潮一样，开发者正在引领潮流并推动基础设施和工具支出。使用量和货币化随着客户增长——我们观察到这是目前最常见的定价模式。
企业看重支出的可预测性，因此供应商将 AI 作为核心的、按席位计费 的产品体验的一部分，而不是作为附加组件，尽管通常伴随着基于使用量的超额费用 (overage fee)。
基于结果的定价 (Outcomes-based pricing) 或将活动捆绑到有意义的业务流程中并根据已完成的工作流程收费。
早期数据也表明，追加销售触发因素在传统开发者和氛围编码者 (vibe-coder) 之间可能有所不同（将在法则 5——“开发者的定义继续显着拓宽” 中进一步探讨）。换句话说，构建和发布软件的主要瓶颈将有意义地影响软件创建者愿意为什么付费（即氛围编码者的 CI/CD 功能与传统开发者的 CI/CD 功能）。
无论公司选择哪条路径，每个平台仍然最专注于减少入门摩擦。（即，维持一个引人注目的免费等级 (free tier)，优秀的文档，强大的开发者社区都是可扩展地减少入门摩擦的方式）。
“我们不是试图将旧的 SaaS 模式强加到一种新的产品上。价值应该与结果挂钩……当智能体正在进行真正的工程工作时，定价才有意义，并且付费墙应该设立在系统正在交付可衡量价值，实际上承担诸如减少停机时间、保持系统稳定或加速交付等结果责任的地方。”
—— Resolve 首席执行官 Spiros Xanthos
法则 4：AI 开发者工具支出正在突破传统预算
随着企业创建专门的 AI 预算，新的支出类别正在出现，最初从首席信息官 (CIO) 扩展到组织的各个部门。许多公司已经在 AI 工具支出与招聘额外工程师之间进行权衡，不断询问是否可以用智能体而不是增加人手来完成目标。
正如我们在向历来服务密集型行业销售的其他垂直软件公司中所观察到的，例如，对编码智能体的工作委托和工作流正在开始补充和取代初级工程师。关注点也不仅仅是生产力提高和成本节约，而是技能最大化（即，让个人拥有全新的能力，从而减少对他人完成任务的依赖）。
预算来源也揭示了一个更复杂、多利益相关者的采购环境。虽然在嘈杂的竞争格局中，开发者驱动的 GTM 仍然是王道，但在企业内部，首席信息官、工程领导者、产品团队和个体开发者对购买决策的影响与上一代开发者工具不同，因为集成一个非确定性系统所需的安全防护机制 (guardrails) 级别。
成功指标正在转向类似消费者的即时价值和卓越体验的期望。传统的围绕生产力的开发者工具指标正在被基于结果的衡量标准所补充：从想法到工作原型的所需时间、总开发周期的减少，以及业务用户生产力的提高。例如，Cursor 的分析跟踪精细指标，包括显示的建议数量、接受的建议数量、在 AI 协助下生成的代码行数，以及 AI 生成建议的接受率。
法则 5：开发者的定义继续显着拓宽
AI 正在使软件创建对更多人可访问，从根本上扩大了谁算作一个“开发者”（这是一个我们有幸见证的趋势，从近十年前我们对 Zapier 的种子投资开始）。氛围编码 (vibe coding) 和 AI 辅助开发的巨大扩散正在创造新的构建者类别，他们创建自定义软件，但不直接编写或关心代码。
像 Lovable、Bolt、Create 和 v0 这样的平台已经将用户引向传统上只服务于技术用户的开发者平台。这一群体也容易通过他们提出的问题类型来识别：他们尚不具备故障排除、阅读错误代码、理解拥有一个独立于 Web 服务器、负载均衡器等之外的数据库服务器意味着什么的能力。而且由于这些用户经常在原型设计和生产之间的阶段受阻，我们发现公司将这种使用量归类为低质量收入而更多地归类为高效营销，尽管我们怀疑随着时间的推移，这种情况也会发生变化，因为开发者开始生活在更高的抽象层次。此外，我们还看到非技术团队成员如何帮助释放宝贵的开发者时间，用于公司主要产品之外的编码和工程任务。例如，在正确的工具下，客户经理 (AEs) 现在可以为技术产品创建自定义演示，市场营销人员可以在 X 上分享示例应用，内容营销人员可以撰写技术博客文章。
最重要的是，这种转变从根本上重新定义了有价值的技能：领域专业知识和客户沟通现在在所有角色中都比编码能力更重要，而系统思维变得更加关键，因为工作从低级实现演变为流程编排和战略规划。成功取决于个人和团队理解复杂部分如何连接、知道何时信任自动化，以及识别何时人工干预至关重要。尽管软件比以往任何时候都更快、更容易发布，但开发者定义的变化重新确立了持久业务基本面的重要性。
“今天有 1700 万 JavaScript 开发者——这些是传统开发者。但我们预计未来 10 年这个数字将达到 1 亿。”
—— Netlify 首席执行官 Mathias Biilmann Christensen
法则 6：更强的网络效应激励早期生态系统定位
传统的开发者公司通过几种机制培养网络效应，特别是开源和社区贡献，以及集成和插件。现在，随着智能体开发的扩散，网络效应正在被重新定义和重新构想。
首先，智能体间的网络效应已经开始出现，AI 智能体在能够与其他智能体交流和组合时变得更加有用。例如，一个可以预订会议的调度 AI 智能体，一旦它能够与他人的旅行智能体、费用管理智能体和日历智能体交流（这得益于像 MCP 这样的协议），它就会变得更强大。其次，由于上下文数据网络效应被强化——一个 AI 智能体拥有的上下文越多，它能完成的任务就越多。拥有该上下文的产品变得越来越有价值。例如，Linear 的产品智能 (Product Intelligence) 可以建议任务分配、分类问题并简化产品运营，因为它积累了多年关于数千个工程团队实际如何工作的数据。
然而，在集成锁定效应传统上创造了转换成本的地方，网络效应已经减弱。正如 Recall 首席执行官 David Gu 所指出的：“现在在不同的 API 之间切换比以往任何时候都更容易，因为你不再需要作为人类手动编写集成代码，而是有 AI 智能体来帮助你。”MCP 通过使 AI 智能体能够自动发现和集成工具，进一步减少了锁定，而一般的 LLMs 使任何人在他们的评估过程中更容易研究和综合选项。
最后，在 AI 驱动开发者工具推荐决策的生态系统中，人类的主观反馈的作用提出了一个悖论。AI 智能体可能会忽略主观偏好，如易用性，而纯粹关注客观性能指标，如性能和延迟。另一方面，AI 智能体可能会随着时间的推移学习而更多地依赖主观人类反馈。这个悖论意味着最高质量的产品无论如何都将受益——开发者主导的增长、产品发布、文档、教育内容、会议、社区论坛和评论都变得更加关键，并且速度比以往任何时候都更重要，因为先发优势会复合。
正如我们前面所指出的，这些法则仍在酝酿中，公司领导者们揭示了不同的观点。例如，Vapi 首席技术官 Nikhil Gupta 认为：“AI 削弱了非基于客观的网络效应，并增强了基于客观的网络效应。例如，人们可能会发现 Stripe 的 API 相对于其他 API 最容易使用，但 AI 智能体在比较 Stripe API 与 Ayden API 时可能并不关心易用性。然而，如果 Stripe 更可靠，所有 AI 智能体都会选择它。” Resolve 首席执行官 Spiros Xanthos 也表示：“智能体优先的GTM策略注重实证，而非炒作。在客户的环境中交付重要的结果，采用率自然会增长。这才是新的推广之道。”
法则 7：平台工程师正在演变为自主流程架构师
平台工程的作用正在从管理软件扩展到创建自主工程流程。平台工程师正在变得对所有技术团队的用户体验负责，他们在组织中的重要性正日益体现在招聘的紧迫性上。
这种转变影响了多个职责领域。平台工程师现在需要具备：设计具有清晰人工监督阶段的智能体流程，执行强大的安全保障来管理智能体执行错误操作的风险，以及拥有超越正常运行时间和可靠性的系统和信息架构的技能。他们正在为最复杂的战略决策构建类似于 AI 控制中心的东西，同时让智能体处理例行操作。
随着 AI 智能体处理更多的实际代码生成，软件工程师正在从手艺人过渡到产品所有者。这种根本性转变意味着工程师越来越关心结果而不是实现细节。这带来了新的工作流要求：强大的测试和监控变得至关重要，文档必须解释系统行为而不仅仅是代码结构，代码审查从检查语法转变为验证业务逻辑和架构决策。其影响超出了个体生产力——团队需要新的知识转移流程，技术债务 (technical debt) 会以不同的方式累积，并且当没有人完全理解生成的代码时，事件响应 (incident response) 变得更具挑战性。当他们的工程师成为他们自己代码的操作者而不是作者时，组织必须大力投资于可观测性 (observability)、自动化测试和架构治理以维护系统可靠性。
随着 AI 以空前的速度生成代码，主要瓶颈从编写代码转向验证其正确性。这从根本上改变了开发速度——团队可以在几分钟内生成数千行代码，但验证它是否按预期工作、与现有系统正确集成以及满足安全和性能要求需要明显更长的时间。通过更好的测试框架、实时验证工具和视觉确认系统来优化验证速度的公司，将在 AI 辅助开发周期中拥有显著优势。
“平台管理中最重大的持续转变是从管理基础设施转向优化开发者工作流程。工程团队现在看到，构建和维护定制的内部开发和部署平台通常是无差异化的工作，会耗尽核心业务的资源。通过利用像 Render 这样的托管平台来处理底层基础设施，平台工程师可以专注于更高价值的自动化。”
—— Render 首席执行官 Anurag Goel
法则 8：防御能力关乎持续演进和平台控制
从本质上讲，作为一个平台就是为第三方创建可扩展的基础设施，让他们可以在其基础上进行构建——从而实现一个随着更多用户贡献和展现真正的社区热情而变得更有价值的生态系统。
虽然这个概念从 SaaS 时代就保持不变，但 AI 时代强化了防御能力的某些支柱。首先，入口点控制（例如，GitHub 拥有代码仓库或 VS Code 主导代码编辑）赋予平台在既定用户行为之上扩展功能的战略权利。其次，数据优势通过专有产品数据集和公司特定上下文，这些使竞争对手无法复制成为可能。
然而，最根本的变化是持续演进仍然至关重要。最好的平台会积极协调多个 AI 模型、数据源和工作流程以采取自主行动。它们往往既拥有来自其生态系统的独特数据，也能够快速利用这些数据进行来自智能体和客户交互的实时反馈。
更重要的是，速度。无论是在发布附加功能还是制定战略方面。公司必须比在 SaaS 时代所需的时间更早地思考他们的“第二幕 (Act 2)” 和“第三幕 (Act 3)”愿景，我们很高兴看到这种情况将如何继续发展。
“关键在于成为第一个改变做事方式的人，从产品的角度来看，是构建一个将持续演进的东西。例如，像 CRM 这样的平台——有人管理它、控制它、对它有自己的看法并从其核心构建模块进行迭代。”
—— Port 首席执行官 Zohar Einy
本文转载编译自https://www.bvp.com/｜原文地址：https://www.bvp.com/atlas/developer-laws-in-the-ai-era｜（编译：Katerina）