- [ 首页 ](/zh/) / - [ 博客 ](/zh/blog/) / - llms.txt 最佳实践 # `llms.txt` 最佳实践：编写清晰、易于维护的文件 llms.txt 实用指南：使用绝对 URL、客观描述、清晰的章节并定期更新。发布文件并不证明 AI 系统使用了它。 最近更新: 2026年9月6日 本页内容 - [ 什么样的 llms.txt 才算优秀？ ](#overview) - [ 该做什么 ](#dos) - [ 不要做什么 ](#donts) - [ 章节命名与结构 ](#sections) - [ 编写好的链接描述 ](#descriptions) - [ Optional 部分 ](#optional-section) - [ 保持更新 ](#maintenance) ## 什么样的 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](/zh/llms-full-txt/) 中。 ### 如有 API 文档，请将其纳入 如果你的产品有 API，那么你的 API 参考几乎肯定是最值得 链接的内容。开发者经常向 AI 助手寻求 API 调用帮助，而幻觉出的 端点或参数是最令人头疼的一类 AI 错误。指向你的规范 API 参考可以降低这种风险。 ### 保持机器可读性 该规范使用标准 Markdown 链接语法： `- [Link text](URL): description.` 不要添加 HTML、front matter 或非标准格式。保持结构整洁，以便任何 Markdown 解析器都能正确处理它。 示例 发布前验证 使用 llmtxt.info 验证器 ，在发布前根据规范检查文件。常见问题包括：缺少 H1 标题、使用相对 URL，以及链接语法格式错误。 ## 不要做什么 ### 不要包含需要身份验证的页面 指向需要登录的页面的链接，在 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 审查加入你的内容发布清单。 - 定期运行 [验证器](/zh/validator/) 以发现失效链接。 如果网站很少变化，通常每季度检查一次 llms.txt 即可。如果你经常发布内容，请将它接入部署流水线。 ## 继续阅读 - [最佳实践（完整指南）](/zh/best-practices/)，帮助创建符合规范且 实用的文件的十条规则。 - [格式参考](/zh/llms-txt-format/)，包含语法示例的完整规范。 - [生成器](/zh/generator/)，几分钟内通过表单构建有效文件。 - [真实示例](/zh/examples/)，看看 Anthropic、Cloudflare 和 Stripe 如何组织 它们的文件。 ## 来源 - [ llmstxt.org，社区提案 ](https://llmstxt.org/) - [ llms.txt 格式参考，llmtxt.info ](https://llmtxt.info/zh/llms-txt-format/) - [ 最佳实践，llmtxt.info ](https://llmtxt.info/zh/best-practices/)