此时此刻，有人正在某处集成你的 API。他们不在你的文档网站上。他们没有打开你的入门指南。他们从未见过你的互动游乐场或精心设计的侧边栏导航。
他们正坐在 Claude 中。或 Copilot。或光标。他们输入类似于_"使用应用程序路由器将 Stripe 账单 API 与我的 Next.js 应用程序集成"_这样的内容，然后等待工作代码的返回。人工智能代表他们阅读你的文档。它找到了相关的端点，理解了身份验证流程，选择了正确的 SDK 方法，并生成了一个实现。
两周前，在圣加仑举行的 Start Summit 黑客马拉松上，我亲眼目睹了这一切的发生。我与一群计算机科学专业的学生和几位早期初创企业的创始人讨论了他们如何开发新的应用程序接口，他们每个人都描述了同样的工作流程：把问题粘贴到人工智能中，得到代码反馈，再从那里开始迭代。当我问她是否读过文档时，其中一位学生笑了。"我为什么要读？克劳德都帮我读了"。
这个人从未访问过你的网站。他们可能永远都不会访问你的网站。而这正是软件越来越多的构建方式。
无人计划的旅程
长期以来，开发人员关系遵循的是一条广为人知的道路。你编写全面的文档。出版快速入门指南。在会议上发表演讲。你在 Stack Overflow 上保持存在。你让你的 API 参考可被搜索，让你的 SDK 简明易懂，让你的错误信息很有帮助。
这条路径假定开发人员会阅读你的内容。浏览你的结构。遵循你的步骤。
GitHub 的 2024 年开发人员调查 发现，97% 的企业开发人员在某个阶段使用过人工智能编码工具。Stack Overflow 的年度调查 显示，76% 的开发人员正在使用或计划使用人工智能工具，其中 62% 的专业人员每天都在积极使用这些工具。这些数字已经很高了，而且还在不断攀升。
新的旅程看起来有所不同。有人用自然语言描述他们想要什么。人工智能助手会阅读文档，找到相关部分并生成集成。构建者审查输出结果，也许会完善提示，也许会提出后续问题。只需几分钟，无需数小时。
DevRel 团队花费数年时间完善的启动漏斗？它被绕过了。这并不是因为它不好，只是入口转移了。
两个消费者，一套文档
现在，文档有两个根本不同的受众。
第一种是人类读者。这个人仍然存在。他们为架构决策、边缘案例调试、合规性审查和概念理解而出现。他们需要的是叙述性的解释、条理清晰的参考资料和清晰的权衡推理。
第二种是人工智能中介。它代表构建者阅读您的文档。它不关心你的侧边栏。它不会欣赏你的视觉设计。它需要的是结构化的、机器可解析的内容：简洁的标记符、一致的格式、明确的规范，它可以毫不含糊地进行推理。
如今，几乎所有的文档网站都只针对第一类受众进行了优化。第二类受众已经成为主流消费者。
杰里米-霍华德（Jeremy Howard）在 2024 年提出 /llms.txt 标准时就发现了这种紧张关系。他的观察非常准确：_"大型语言模型越来越依赖于网站信息，但却面临着一个关键的限制：上下文窗口太小，无法处理大多数网站的全部内容。在______________________________________________________________________中，一个经过策划的标记符文件可以为人工智能模型提供产品的结构化概述以及最重要资源的链接。FastHTML、Anthropic自己的文档以及不断增长的项目目录现在都提供了这样的文件。
这是一个有用的惯例。但这也是更深层次问题的表象。真正的问题不在于格式。而是大多数文档在设计时从未考虑过机器的使用。
建造者没有偷工减料
看着那些不阅读文档而是提示 Claude 的人，我们很容易得出结论：他们在走捷径。他们并不真正理解代码中发生了什么。他们在某种程度上是低级的开发人员。
这样的对话我已经听过很多次了，所以我知道这通常是错误的。
这些开发者中的许多人都是高级工程师，他们会有意识地提高效率。他们理解代码，只是不想翻阅四页文档来查找实际需要的三行代码。他们已经了解到，人工智能助手提取这些行的速度比他们扫描这些行的速度还要快，所以他们把阅读工作委托给了人工智能助手。(老实说，我自己也是这么做的。我都不记得上一次从头到尾阅读入门指南是什么时候了）。
Anthropic在构建模型上下文协议时就意识到了这种模式。现在，Claude、ChatGPT、VS Code、Cursor 等公司都支持 MCP。它的明确设计目的是让人工智能助手可以进入外部系统，获取上下文，并根据上下文采取行动。规范将其描述为提供_"对数据源、工具和应用程序生态系统的访问，这将增强功能并改善最终用户体验"_。
请仔细阅读--这是基础架构语言，而不是便利性语言。使用这些工具的构建者并不是在逃避工作。他们是在通过一个新的层进行工作，而你的文档是这个层的一部分，无论你是否设计了这个层。
开发者关系是为不同的时代构建的
如果你的开发人员关系战略是在 2023 年之前设计的，那么它是为开发人员直接阅读文档的世界设计的。这个世界并没有消失，但对于越来越多的构建者来说，这已不再是主流交互模式。
这就改变了一些长期存在的 DevRel 活动。
**会议演讲：**在开发者大会上进行 45 分钟的演讲，可以吸引几百人的关注。而结构良好的/llms.txt文件和简洁的机器可读文档则能让每一位随时随地向任何人工智能助手询问您的产品的开发人员了解。讲座是一次性活动。机器可读文档是复合型的。我并不是说会议毫无价值，我也刚参加完一次会议，但杠杆等式已经发生了变化。
入门指南 经典的五步快速入门教程越来越流于形式。建设者并不按部就班。他们只需描述自己的需求，并期望人工智能能够实现集成。如果应用程序接口以机器友好的格式进行了详细说明，人工智能就能比任何教程更有效地处理入门体验。相反，教程应该成为概念性材料：解释为什么你会选择方法 A 而不是方法 B。但在解释如何取舍方面，人工智能就不那么可靠了。
Stack Overflow. 他们自己的调查数据显示，84%的开发人员 直接使用技术文档，其中90%依赖于API和SDK包中的文档。但他们访问这些文档的方式越来越多地是通过人工智能层，而不是浏览器标签。Stack Overflow 上仍然存在的问题往往是难题--边缘案例、生产调试、需要细微差别的问题。当然，这些问题很有价值。但这已不再是问题的主要来源。
当人工智能阅读你的文档时，新鲜度变得至关重要
这是大多数团队没有考虑到的部分。
当人类阅读文档页面时，他们可以做出判断。他们可能会注意到截图看起来很旧，或者底部的注释说流程改变了。他们会眯着眼睛看，然后想 "这感觉过时了"。
人工智能助手做不到这些。它能读取文本，将其作为事实进行处理，并满怀信心地生成答案。如果文档中描述的是已过时的端点，人工智能会欣然推荐与之集成。如果文档中提到的基础架构在六个月前已被替换，人工智能会将旧设置描述为当前设置。毫不犹豫。
构建者信任人工智能。人工智能信任文档。如果文件陈旧，信任链就会提供一个错误的答案。
显然，这一直是个问题。陈旧的内容总是让人感到困惑。但由于人类读者有时可以发现，因此这种损害得到了控制。人工智能中介却做不到。它们通过大规模、权威性地向那些没有理由怀疑的人提供陈旧内容，从而扩大了陈旧内容的影响。
新鲜度不再是一个内容质量问题。对于每一个接触文档的人工智能工作流来说，这都是一个可靠性问题。
##"开发者 "这个词过于狭隘
2026 年的软件开发人员并不都是开发人员。有些人是设计师，他们会提示克劳德构建工作原型。有些是产品经理，他们使用 Cursor 发布内部工具。有些是数据分析师，他们用自然语言描述数据管道，然后让代理进行组装。在 Start Summit 上，有一半的黑客马拉松团队成员没有编程背景，但他们在周末结束时都能发布可运行的软件。
Ramp就是一个很好的例子。这家金融科技公司的估值从2023年的58亿美元上升到2025年末的320亿美元，年收入一路突破10亿美元。这是历史上发展最快的初创公司之一。他们的方法中被广泛讨论的一部分是：产品经理直接使用人工智能工具构建功能，而不是在工程积压中等待。Ramp 的项目经理不仅仅是编写规格。他们会发送代码。人工智能负责实现。项目经理负责意图。
这不是捷径。这是一种全新的运营模式，而且其规模之大，让人很难将其视为一种实验。
Anthropic 一直有意将其称为 "建设者 "角色。他们的工具不仅是为专业软件工程师设计的，也是为任何能够描述自己想要构建的东西的人设计的。当克劳德可以通过 MCP 从 Figma 设计中构建一个全栈应用程序时，"开发者 "和 "非开发者 "之间的传统界限就会消失。
这对任何维护文档或关注开发人员体验的人都有实际意义。你的受众不再局限于知道什么是 REST 端点的人。它包括任何人工智能助手可能与你的产品进行交互的人。Ramp 的项目经理会使用你的 API 发布功能吗？他可能永远不会直接阅读您的文档。但他们的人工智能代理绝对会。
这对文档意味着什么
如果文档现在服务于两个受众--人类读者和人工智能中介--那么它就需要同时为这两个受众服务。听起来很明显。但实际上，几乎没人这么做。
以下是我认为真正重要的内容：
**机器可读格式与人类可读格式并存。**如果你的 API 文档是一个精美的 HTML 页面，而 LLM 不得不对其进行搜刮和解析，那么人工智能的工作就会比它应该做的更辛苦。在提供渲染版本的同时，也要提供原始的 OpenAPI 规范。提供简洁的标记符。无需人工智能解释页面布局即可访问规范。
**人工智能助手不会一页一页地阅读文档。它们会提取相关部分。对于人工智能来说，标题清晰、段落自足、块级语义明确的文档，要比需要阅读整页才能了解上下文的流畅叙述有用得多。
信任机器可以阅读的信号 这份文档上一次审核是什么时候？是否仍然有效？内容是否被标记过？这些信号需要以人工智能可以访问的形式存在，而不仅仅是网页上的视觉提示。新鲜度评分、过期状态、审核日期，这些元数据可以让人工智能决定是否可以安全地将文档用作信息源。
**新鲜度是先决条件，而不是特征。**当人工智能助手根据一个已废弃的端点向构建者提供一个有把握的答案时，所造成的损失比404更严重。构建者会在此基础上进行构建。将其交付使用。然后它就在生产中崩溃了，没人知道原因，直到有人追溯到几个月前就应该更新的文档。人工智能可能参考的每一份文档都需要一种机制来证明它仍然是最新的。(坦白说，这正是我们构建 Rasepi 所要解决的问题--强制文档块过期，让过期内容无所遁形。）
产品表现方式的悄然转变
这一切还有一个更广泛的结果值得直接说明。
您的文档不再仅仅是开发人员的参考手册。它是人工智能助手用来向世界展示产品的原始资料。当一个开发者向克劳德询问如何使用你的产品时，克劳德的回答会根据它能从你的文档中找到并解析的内容来确定。
文档好，答案就好。过时的、模棱两可的、锁定在模型难以解析的 HTML 中的文档--答案更差，或者是不正确的答案。就这么简单。
现在，人工智能对产品的回答质量可以直接代表开发人员的体验。大多数公司还没有这样做。
在这方面走在前面的团队--Stripe、Vercel、Cloudflare 和 Anthropic 本身--都将人工智能的可读性视为头等大事。这是一项基础性要求，决定了文档的编写、结构和维护方式。而不是下一季度的积压项目。
现在坐在克劳德的构建者，描述着他们想要构建的内容，期待着几分钟内就能完成工作代码--他们可能再也不会访问文档网站了。但为他们提供服务的人工智能会。持续不断。
该人工智能现在是您最常见的读者。问题是，您的文档是否已经做好了准备。
2026 年最佳开发人员体验战略不是会议演讲或快速入门指南。而是要确保人工智能能够正确处理。
本文章参考了公开的研究和产品文档。统计数据来自 GitHub 2024 年开发人员调查 和 Stack Overflow 2024 年开发人员调查。/llms.txt规范由llmstxt.org维护。模型上下文协议在 modelcontextprotocol.io. 进行了记录。