AI 时代的开发者法则

软件正在为一个 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 年，一个全新的范式出现了： 智能体开发 ，即 AI 智能体与开发者协作，在大规模下进行软件的设计、构建、部署与维护。

AI 开发平台八大法则

法则一：智能体体验（AX）与开发者体验（DX）同等重要

当今的开发者平台需要同时关注智能体体验（AX）与开发者体验（DX）。在很多方面，DX 直接影响并增强了 AX。这包括文档的完整性（详见法则二——“文档必须同时服务于智能体与人类”）、API 的覆盖范围以及易于理解的模式。过去五到十年在 OpenAPI 规范、REST API 和 SDK 上的投入，使得人类和智能体都能更轻松地使用产品。

“我们并没有把 DX 视为 AX 的对立面，而是发现我们对 DX 所做的所有改进实际上都在提升 AX。比如，我们花了大量时间尽可能让人类的上手流程变得简单。结果发现，这也极大地促进了代理（agents）使用 Resend。”

—— Zeno Rocha，Resend 首席执行官

然而，人类与代理在能力和结构上也存在差异。 虽然人类开发者可以理解含糊的文档并适应不一致的 API，但代理需要结构化、可预测的接口。这意味着需要具备全面错误处理的 OpenAPI 模式、多步骤工作流的会话持久化，以及像 WebSocket 流这样的实时反馈机制。例如，Netlify 的部署代理必须在整个 CI/CD 流水线中保持状态，同时提供即时的构建反馈，而这些是传统开发者工具在设计时并未考虑的需求。

其次，像 Model Context Protocol (MCP) 这样的协议的出现，代表了开发者工具服务用户方式的根本性转变。许多公司现在使用 Prefect 的 FastMCP 等解决方案来托管自己的 MCP 服务器，因为他们知道自己的开发者正在使用 Cursor 和 Claude Code。这意味着在他们的 IDE 中，开发者可以为其智能体赋能，使其能够直接访问平台的实时数据并代表他们执行操作。

最后，我们开始思考仪表盘在调试、监控和日志记录中的作用。如今，人类会直接登录到仪表盘，将其作为信息收集的核心界面。像 Recall 这样的团队已经开始通过 API 提供所有仪表盘功能，使得智能体今天也能参与问题的解决。相关地，关于如何减少甚至消除智能体的上下文切换（版本控制、集成、使用 API、推送到生产环境）仍然存在一些悬而未决的问题。这一趋势已经在发生，因为 MCP 服务器使智能体能够获取实时信息并执行命令，而无需开发者在仪表盘或 CLI 之间进行上下文切换。

法则 #2：文档必须同时服务于模型和人类

在工程团队中，文档往往出于良好意图而编写，但维护不善，未能捕捉实时变化，反映的指导信息也已过时。开发者在查阅这些文档时常常感到沮丧，但通常会自然地对不完整或不完美的内容保有一定的容忍度。

相反，对于 LLMs 来说，将包含导航、广告和 JavaScript 的复杂 HTML 页面转换为 LLM 可用的纯文本既困难又不精确。 相反，智能体从集中在单一、可访问位置的简洁、专家级信息中获益匪浅。 这对于开发环境等使用场景尤为重要，因为 LLMs 需要快速访问编程文档和 API。LLMs 还需要最新的结构化 API 参考，以及跟踪人类和智能体操作的审计日志。这些需求迫使我们从根本上重新思考信息架构。

这也是生成式引擎优化（GEO）发挥作用的地方。就像 SEO 确保在搜索引擎中的可发现性一样，GEO 确保模型能够快速解析并在文档中呈现准确答案，让开发者保持工作流畅，而不是被上下文切换的搜索打断。

随着编码代理的普及，技术文档成为一种双重用途的产品资产——公司需要文档同时有效服务于代理和人类开发者受众，对代理来说要有适当的版本管理、变更管理和可发现性，同时对人类开发者保持实用性。

“开发者希望有一个精美的文档网站，而代理则需要干净的 markdown 来解析。团队正趋向于采用 docs-as-code 的方法，即文档首先用 markdown 编写，然后发布为对开发者友好的网站和机器可读文件，如 llms.txt。”

——Fern 联合创始人

法则 #3：定价策略仍然专注于降低用户上手的摩擦

定价必须同时考虑成本结构和价值交付。对于 AI 公司来说，这一点尤为重要，因为在传统 SaaS 中，服务边际用户的成本几乎为零，而在 AI 原生应用中，由于推理成本的存在，这一成本成为了显著的支出项。为了解决这一问题，我们观察到一些面向开发者的公司正在尝试几种定价路径：

1. 基于使用量的定价，并通过产品的巨大实用性推动客户账户内部的大规模扩展。所有平台都在重新整合 AI，和每一波技术浪潮一样，开发者是推动者，带动了基础设施和工具的支出。随着客户的增长，使用量和变现能力同步提升——我们观察到这目前是最常见的定价模式。

2. 企业重视支出可预测性，因此供应商会将 AI 融入核心的按席位计费的产品体验中，而不是作为附加功能，尽管通常会附带基于使用量的超额费用。

3. 基于成果的定价，或将活动捆绑成有意义的业务流程，并根据完成的工作流程收费。

早期数据还表明，传统开发者与“vibe-coder”之间的增销触发因素可能不同（将在法律第 5 条——“开发者的定义正在显著扩展”中进一步探讨）。换句话说，构建和交付的关键因素将显著影响软件创作者愿意为哪些功能付费（例如，vibe-coder 更看重 CI/CD 功能，而传统开发者则不同）。

无论公司选择哪条路径，每个平台仍然最关注的是降低用户上手的摩擦。（例如，保持有吸引力的免费层级、完善的文档、强大的开发者社区，都是可扩展地减少上手摩擦的方法。）

“我们并不是试图将旧的 SaaS 模式强加到一种新型产品上。价值应当与结果相匹配……当智能体在进行真正的工程工作时，定价才有意义，而付费墙应当设置在系统能够提供可衡量的价值之处，真正对结果负责，比如减少停机时间、保持系统稳定或加快交付速度。”

– Spiros Xanthos，Resolve 首席执行官

法则 #4：AI 开发者工具支出正在突破传统预算

随着企业制定专门的 AI 预算，新的支出类别正在出现，最初由 CIO 推动，逐步扩展到组织的各个部门。许多公司已经在 AI 工具支出与招聘更多工程师之间进行权衡，不断思考是否可以通过使用智能代理来实现目标，而不是增加人力编制。

正如我们在其他面向历史上以服务为主的行业的垂直软件公司中所观察到的那样，任务分配和工作流程正开始交由编码代理来处理，这不仅是对初级工程师的补充，甚至在某些情况下取而代之。关注点不仅在于提升生产力和节约成本，还在于最大化技能（即让个人具备全新的能力，从而减少对他人的依赖来完成任务）。

预算来源也揭示了一个更复杂的、多方参与的采购环境。尽管由开发者主导的 GTM 在竞争激烈的市场中依然占据主导地位，但在企业内部，CIO、工程主管、产品团队以及个人开发者在采购决策中的影响方式，与上一代开发者工具相比已有不同，这是因为在整合一个非确定性系统时需要更多的安全防护措施。

成功衡量标准正朝着类似消费者的期望转变，即即时价值和神奇体验。传统围绕生产力的开发者工具指标，正被基于结果的衡量方式所补充：从想法到可用原型的时间、总开发周期的缩短，以及业务用户生产力的提升。例如，Cursor 的分析功能会跟踪细粒度指标，包括显示的建议数量、被接受的建议数量、在 AI 协助下生成的代码行数，甚至 AI 生成建议的接受率。

法则 #5：开发者的定义正在急剧扩展

AI 正在让更多人能够参与软件创作，从根本上扩大了“开发者”的范畴（这一趋势我们早在近十年前通过对 Zapier 的种子投资就有幸见证）。大量涌现的 vibe coding 和 AI 辅助开发，正在创造新的构建者类别，他们无需直接编写或关心代码，就能创建定制化软件。

像 Lovable、Bolt、Create 和 v0 这样的平台，已经在将用户引导至传统上只服务技术用户的开发者平台。这个群体也很容易通过他们提出的问题类型来识别：他们还没有能力进行故障排查、阅读错误代码、理解数据库服务器与 Web 服务器、负载均衡器等分离的意义。由于这些用户常常卡在从原型到生产之间的阶段，我们发现公司往往将这类使用归类为高效营销，而不是高质量收入，不过我们怀疑随着开发者开始在更高层次的抽象中工作，这种情况也会随时间发生变化。此外，我们还看到非技术团队成员正在帮助释放宝贵的开发者时间，用于公司主要产品之外的编码和工程任务。例如，在拥有合适工具的情况下，客户经理（AE）现在可以为技术产品创建定制演示，市场人员可以创建示例应用分享到 X，内容营销人员可以撰写技术博客文章。

最重要的是，这一转变从根本上重新定义了宝贵技能：在所有角色中，领域专业知识和客户沟通如今比编码能力更为重要，而随着工作从低层实现转向编排与战略，系统思维变得更加关键。成功取决于个人和团队是否理解复杂组件如何连接，知道何时信任自动化，以及识别何时需要人工干预。尽管软件的交付速度和难度比以往更快更容易，但开发者定义的变化重新强调了持久型企业基本功的重要性。

“如今有 1700 万名 JavaScript 开发者——他们是传统开发者。但我们预计在未来 10 年，这一数字将达到 1 亿。”

– Mathias Biilmann Christensen，Netlify 首席执行官

法则 #6：更强的网络效应激励生态系统的早期布局

传统的开发者公司通过一些机制来培育网络效应，尤其是开源与社区贡献，以及集成和插件。如今，随着自主开发的普及，网络效应正在被重新定义和重新构想。

首先，代理与代理之间的网络效应已经开始显现，当 AI 代理能够与其他代理进行交流和协作时，其价值会更高。例如，一个能够预订会议的日程安排 AI 代理，一旦能够与他人的旅行代理、费用管理代理和日历代理进行沟通（这得益于 MCP 等协议的支持），就会变得更加强大。其次，由于上下文的存在，数据网络效应被进一步放大——AI 代理掌握的上下文越多，就越能完成你希望它完成的工作。拥有这些上下文的产品会变得越来越有价值。例如，Linear 的 Product Intelligence 能够建议任务分配、分类问题并优化产品运营，因为它积累了多年关于数千个工程团队实际工作方式的数据。

然而，在传统上由集成锁定效应产生转换成本的地方，网络效应已经减弱。Recall 的 CEO David Gu 指出：“现在在不同 API 之间切换比以往任何时候都容易，因为不再需要你作为人类手动编写集成代码，而是有 AI 代理来帮助你。”MCP 通过让 AI 代理自动发现并集成工具，进一步降低了锁定效应，而 LLMs 总体上也让任何人在评估过程中更容易研究和综合各种选项。

最后，在由 AI 推动开发者工具推荐决策的生态系统中，人类的主观反馈角色呈现出一种悖论。AI 代理可能会忽略诸如易用性等主观偏好，而只专注于客观性能指标，如性能和延迟。另一方面，AI 代理也可能随着时间的推移更加依赖人类的主观反馈。这种悖论意味着，无论如何，最高质量的产品都会受益——开发者驱动的增长、产品发布、文档、教育内容、会议、社区论坛和评论都变得更加关键，而速度比以往任何时候都更重要，因为先发优势会不断累积。

正如我们之前提到的，这些法则仍在不断完善中，公司领导者们也呈现出不同的观点。例如，Vapi 的 CTO Nikhil Gupta 认为，“AI 会削弱非目标导向的网络效应，并强化目标导向的网络效应。举例来说，人们可能觉得 Stripe 的 API 相比其他更易用，但在比较 Stripe API 和 Ayden API 时，AI 代理可能并不在意易用性。然而，如果 Stripe 更加可靠，所有 AI 代理都会选择它。” 同样地，Resolve 的 CEO Spiros Xanthos 也表示，“以代理为先的 GTM 关注的是证明，而不是炒作。进入客户的环境，交付真正重要的成果，采用率就会自然增长。这就是新的布道方式。”

法则 #7：平台工程师正演变为自主流程架构师

平台工程的角色正在从管理软件扩展到创建自主的工程流程。平台工程师正逐渐负责所有技术团队的用户体验，他们在组织中的重要性也越来越体现在招聘的紧迫性上。

这一转变影响了多个职责领域。平台工程师现在需要具备设计具有明确人工监督环节的智能代理流程的技能，实施强有力的防护措施以管理代理执行错误操作的风险，并负责超越仅仅是正常运行时间和可靠性的系统与信息架构。他们正在构建相当于 AI 控制中心的系统，用于处理最复杂的战略决策，同时让代理负责日常运营。

随着 AI 智能体承担更多实际代码生成工作，软件工程师正从工匠转变为自己系统的产品负责人。 这一根本性转变意味着工程师越来越关注结果，而非实现细节。这带来了新的工作流程需求：健壮的测试和监控变得至关重要，文档必须解释系统行为而不仅仅是代码结构，代码审查也从检查语法转变为验证业务逻辑和架构决策。这种影响不仅限于个人生产力——团队需要新的知识传递流程，当没有人能完全理解生成的代码时，事件响应会变得更加困难；当原始实现逻辑不可读时，技术债务的积累方式也会不同。为了在工程师从代码作者转变为代码操作者的情况下保持系统可靠性，组织必须在可观测性、自动化测试和架构治理方面进行大量投入。

随着 AI 以空前的速度生成代码，主要瓶颈从编写代码转向验证其正确性。这从根本上改变了开发速度——团队可以在几分钟内产出数千行代码，但验证其是否按预期运行、能否与现有系统正确集成、以及是否满足安全和性能要求则需要更长时间。能够通过更完善的测试框架、实时验证工具和可视化确认系统来优化验证速度的公司，将在 AI 辅助的开发周期中拥有显著优势。

平台管理中最显著的持续变化，是从管理基础设施转向优化开发者工作流程。工程团队如今意识到，构建和维护定制化的内部开发与部署平台往往是缺乏差异化的工作，会消耗核心业务的资源。通过利用像 Render 这样的托管平台来处理底层基础设施，平台工程师可以专注于更高价值的自动化工作。

—— Anurag Goel，Render 首席执行官

法则 #8：防御能力在于持续进化与平台控制

从本质上讲，成为一个平台就是为第三方构建可扩展的基础设施，使其能够并行开发和在其之上构建——从而促成一个随着更多用户贡献而变得更有价值、并展现出真正社区热爱的生态系统。
虽然这一理念自 SaaS 时代以来始终未变，但 AI 时代强化了某些防御壁垒。首先，入口点控制（例如 GitHub 掌控代码仓库或 VS Code 主导文本编辑）赋予平台在既有用户行为基础上扩展功能的战略权利。其次，数据优势体现在专有的产品数据集和公司特有的上下文，这些能够实现竞争对手无法复制的功能。

然而，最根本的变化在于持续演进依然至关重要。最优秀的平台会主动协调多个 AI 模型、数据源和工作流，以采取自主行动。它们往往既拥有来自其生态系统的独特数据，又能够快速利用这些数据，从代理和客户交互中形成实时反馈循环。

在这一切之上，速度至关重要，无论是在交付额外功能还是制定战略方面。企业必须比 SaaS 时代更早地深入思考他们的第二幕和第三幕愿景，我们也很期待看到这一趋势如何持续演变。

“关键在于率先改变事物的运作方式，并从产品的角度构建一个能够持续演进的东西。比如像 CRM 这样的平台——有人管理它、控制它、对它提出看法，并从其核心构建模块不断迭代。”

—— Port 首席执行官 Zohar Einy

开源我们的研究，以打造卓越的 B2D 企业

构建卓越的 B2D 企业的行动手册正变得越来越复杂，而要取得成功，就需要打造将代理视为一等公民的产品和公司，设计涵盖完整成熟曲线的定价体系，并持续投入于适应性和防御能力的建设。