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