什么样的 llms.txt 才算优秀？

编写良好的 llms.txt 文件只做一件事：为 AI 系统提供一条可靠的精选捷径，指向您网站上最重要的页面。当智能体框架或 RAG 流水线读取文件时，应能立即了解网站主题、应加载哪些页面作为上下文，以及这些页面的优先顺序。

如果文件写得很差，充斥营销文案、相对 URL 或网站上的所有页面，那么与抓取 sitemap.xml 相比没有任何优势。llms.txt 的价值来自内容筛选和清晰表达。

应该做什么

使用绝对 URL

llms.txt 中的每个链接都必须使用完整的绝对 URL。相对路径无法正常工作，因为获取该文件的客户端可能事先不知道您的域名。

# Correct
- [API reference](https://example.com/docs/api/): complete endpoint documentation.

# Incorrect, relative URL
- [API reference](/docs/api/): complete endpoint documentation.

编写事实性块引用

紧接 H1 标题之后的可选块引用（但强烈建议添加）是 AI 系统首先读取的内容。请用一到三句直白的话说明你的网站或产品是什么。应将其视为机器可读的描述，而不是推销文案。

# Acme

> Acme is an open-source inventory management platform for small manufacturers.
> It provides real-time stock tracking, supplier integration, and demand forecasting.
> Documentation covers setup, configuration, and the REST API.

包含你最重要的 5–15 个页面

精心筛选是核心目的。对于大多数网站，5 至 15 个链接最为合适。如果您的文档网站规模较小，链接更少也没问题。如果您拥有涵盖多个独立产品领域的大型平台，可以增加数量，但超过 30 个链接就会开始稀释信号。

优先选择：快速入门、核心概念、API 参考、身份验证，以及能够回答用户最常向 AI 助手咨询的产品相关问题的页面。

将文件保持在合理大小以内

规范没有规定最大文件大小，但实际限制仍然重要。远低于 100 KB 的文件可以高效获取和解析。如果你的 llms.txt 变得非常大，请考虑部分内容是否应放入 llms-full.txt 中。

如有 API 文档，请将其纳入

如果你的产品有 API，那么你的 API 参考几乎肯定是最值得链接的内容。开发者经常向 AI 助手寻求 API 调用帮助，而幻觉出的端点或参数是最令人头疼的一类 AI 错误。指向你的规范 API 参考可以降低这种风险。

保持机器可读性

该规范使用标准 Markdown 链接语法： - [Link text](URL): description. 不要添加 HTML、front matter 或非标准格式。保持结构整洁，以便任何 Markdown 解析器都能正确处理它。

不要做什么

不要包含需要身份验证的页面

指向需要登录的页面的链接，在 AI 爬虫或智能体尝试获取时会失败。请仅包含可公开访问的 URL。如果你的关键文档位于登录墙之后，这本身就是一个值得解决的问题，因为受限文档也不利于人类用户发现。

不要在块引用中放营销文案

引用块供 AI 系统读取以获取事实背景，而不是用于说服人类。营销语言（“行业领先的……解决方案”）无法帮助 AI 理解你的产品。客观、具体的语言才有帮助。

不要使用相对 URL

像 /docs/api/ 在 llms.txt 中无效。始终使用完整的绝对 URL ，包括协议和域名。

不要链接到网站上的每个页面

llms.txt 不是站点地图。包含数百个链接的文件几乎不能提供任何筛选信号。如果 AI 客户端需要发现您的所有页面，它可以使用 sitemap.xml。llms.txt 应回答这样一个问题：“如果只能阅读 10 个页面来了解此网站，应该读哪 10 个？”

不要发布后就置之不理

llms.txt 会过时。如果你删除了已链接的页面、重命名了某个部分，或发布了重要新文档，就应更新 llms.txt 以反映变化。满是失效链接或过时描述的文件，会主动误导 AI 系统对你内容的理解。

不要包含预发布网址或重定向网址

仅链接到正式生产环境的规范 URL。预发布 URL 可能受密码保护，重定向链会增加延迟，而非规范 URL 会让把 URL 当作标识符的检索系统产生混淆。

章节命名与结构

规范将各部分定义为 Markdown H2 标题（##)，其中包含链接列表。节名称没有标准化，你可以自行选择，以反映内容的组织方式。常见模式：

文档或文档，适用于文档站点。
API 参考，适用于带公开 API 的产品。
入门指南，适合高度依赖新用户引导的产品。
指南，适用于教程风格内容。
博客，用于编辑类内容（若属于次要内容，请标记为 Optional）。
可选，这是规范定义的低优先级链接部分，客户端可以选择跳过。

选择能反映内容组织方式的章节名称，而不是 SEO 关键词。读取文件的 AI 客户端能够理解自然语言，因此请使用能清楚表达结构的名称。

编写好的链接描述

llms.txt 中的每个链接都可以有一个可选描述，用冒号与 URL 分隔：

- [Page title](https://example.com/page/): what this page contains.

好的描述应简短（少于 20 个英文单词或相当长度）、客观，并明确说明页面涵盖什么。应将其视为微型摘要，而非宣传文案。

良好示例： “所有 REST API 端点的完整参考，包括身份验证、速率限制和错误代码。”
不佳： “我们世界一流的 API 文档将帮助你快速构建出色的集成。”
良好示例： "面向新用户的分步快速入门，从创建账户到第一次 API 调用。"
错误示例： “立即开始，体验 Acme 的强大功能。”

Optional 章节

## Optional 是一个编辑标签，而不是 v2 中的特殊处理指令。可在由独立分组让次级资源更便于人和兼容客户端理解时使用它。适合的示例包括：

提供背景信息但在技术上并非必需的博客文章和编辑内容。
变更日志或发行说明页面。
核心页面的其他语言版本。
FAQ 和术语表页面虽有用，但不是主要参考资料。

不要假定客户端会跳过、降低此部分的优先级或以其他方式区别对待它。如果优先级对某个工作流很重要，请在客户端文档中说明该行为，而不要根据标题推断。

保持内容最新

一个简单的维护习惯：每次发布或下线重要页面时，都检查是否应更新 llms.txt。对于较大型的网站，可以考虑：

构建时根据导航结构或 CMS 自动生成 llms.txt。
把 llms.txt 审查加入你的内容发布清单。
定期运行验证器以发现失效链接。

如果网站很少变化，通常每季度检查一次 llms.txt 即可。如果你经常发布内容，请将它接入部署流水线。

继续阅读

最佳实践（完整指南），帮助创建符合规范且实用的文件的十条规则。
格式参考，包含语法示例的完整规范。
生成器，几分钟内通过表单构建有效文件。
真实示例，看看 Anthropic、Cloudflare 和 Stripe 如何组织它们的文件。

`llms.txt` 最佳实践：编写清晰、易于维护的文件