什么是 llms.txt？面向大语言模型的网站内容索引规范

llms.txt 是一项关于网站内容组织的提案，其核心主张是在网站上添加一个 /llms.txt 的 Markdown 文件，为面向大语言模型（Large Language Model，LLM）的使用场景提供友好内容。该文件可以放在站点根目录，也可以放在站点内的任意路径下，用于覆盖该路径之下的页面。按照官方规范的说法，这个文件提供简短的背景信息、指引，以及指向更详细 Markdown 文件的链接。它要解决的问题是：网页是为人构建的，HTML 页面把信息包裹在导航、广告和 JavaScript 之中，把这些内容重新转换成干净的文本既困难又不精确；而上下文窗口虽然比过去更大，对大多数网站的整体内容而言仍然偏小，每一个被浪费的 token 都意味着时间与金钱的消耗。

为什么重要

官方规范在背景部分描述了智能体使用网站的方式：编码智能体抓取某个库的文档，以便把一次 API 调用写对；带搜索能力的聊天助手读取页面，用来回答关于某个产品的问题。规范提到，这份提案最初写于 2024 年，当时这还基本是一种预测，而现在已经属于日常情形。

在 llms.txt 出现之前，智能体面对的是一个为人类阅读而设计的网页环境。一个 HTML 页面会把真正有用的信息与导航栏、广告、脚本混在一起，抽取过程依赖启发式规则，结果往往不完整或有偏差。与此同时，把整个网站塞进上下文窗口通常并不可行，即使可行也代价高昂。规范给出的判断是：智能体最适合被服务的方式，是把简洁的、专家级的信息集中在一个单一且易于访问的位置。llms.txt 正是针对这一需求提出的组织方式——文件本身足够小，可以放进上下文；细节留在链接背后，只在需要时才被取用。

规范还提到该提案在实践中的采用情况：数千个站点发布了 llms.txt 文件，文档平台会自动生成一个，Chrome 的 Lighthouse 把检查是否存在该文件作为其智能体浏览检查的一部分。规范称，一些 AI 实验室也为自己的开发者文档发布了 llms.txt 文件，其中点名了 OpenAI、Anthropic 和 Gemini。需要说明的是，这些采用情况与效果描述均来自该规范自身的陈述，属于提案方的说法。

工作机制

llms.txt 的设计由几个相互配合的部分组成，规范对每一部分都给出了具体约定。

• 文件位置与覆盖范围。文件放在站点根目录，或站点内的任意路径下，覆盖该路径之下的页面。规范举例说明：/docs/llms.txt 覆盖 /docs/ 下的全部内容。
• 文件内容。文件提供简短的背景信息、指引，以及指向详细 Markdown 文件的链接。规范强调，llms.txt 的 Markdown 既可供人阅读，也可供 LLM 阅读，同时格式足够精确，允许使用固定处理方法，也就是解析器、正则表达式这类经典编程技术来处理。
• 页面的 Markdown 版本。规范进一步提议，凡是智能体可能需要的信息页面，都应在与原页面相同的 URL 上提供一份干净的 Markdown 版本：可以在原地址后追加 .md（形如 page.html.md），也可以把扩展名替换为 .md（形如 page.md）。对于不含文件名的 URL，则改为追加 index.html.md 或 index.md。
• 发现机制。为了让客户端能找到这些文件，规范建议使用标准的链接关系：rel="alternate" type="text/markdown" 指向某个页面的 Markdown 版本，rel="describedby" 指向覆盖该页面的 llms.txt 文件。这些链接既可以写成 HTML 的 <link> 元素，也可以写成 HTTP 的 Link: 响应头。规范指出，响应头形式对非 HTML 资源同样有效，例如 Markdown 文件本身，并且可以在 Web 服务器或 CDN 配置中添加，无需修改任何页面。
• 使用流程。规范描述的使用方式是：智能体查看或搜索 llms.txt，找到自己需要的信息，然后跟随相关链接。因此，llms.txt 中的链接应当指向对 LLM 友好的内容，例如上面所述的页面 Markdown 版本。

这套结构把「索引」与「正文」分开：索引文件保持小巧，可以整体放入上下文；正文按需抓取。规范认为，这种结构适用于任何需要为智能体提供一条受引导路径的场景，包括企业说明自身结构与政策、个人站点回答关于某人简历的问题、学校提供课程信息等。

典型例子

规范中给出的具体例子包括以下几项。

• FastHTML 项目的文档。规范称 FastHTML 项目为其文档遵循了上述两项提议。其文档的 llms.txt 放在 /docs/ 下，因此只覆盖文档页面；同时，一个普通的 HTML 文档页面在完全相同的 URL 上、以 .md 扩展名提供了一份内容相同的版本。
• nbdev 项目。规范提到，所有 nbdev 项目现在默认生成所有页面的 .md 版本；所有使用 nbdev 的 Answer.AI 与 fast.ai 软件项目，其文档都已用这一特性重新生成。规范举出的例子是 fastcore 的 docments 模块的 Markdown 版本。
• AI 实验室的开发者文档。规范称 OpenAI、Anthropic 和 Gemini 都为各自的开发者文档发布了 llms.txt 文件。
• 工具链与审计。规范称文档平台会自动生成 llms.txt，Chrome 的 Lighthouse 把检查站点是否提供该文件纳入其智能体浏览检查。

规范还指出，llms.txt 文件使用最密集的领域是软件文档，编码智能体跟随这些文件去查找 API 参考与教程。

边界与常见误解

首先需要明确的是，llms.txt 是一项提案，而不是一项已经生效的强制标准。规范本身以「我们提议」的措辞描述其内容，因此把它当作所有网站必须遵守的行业共识并不准确。规范中提到的采用规模、工具支持与效果，均属于提案方的陈述。

其次，llms.txt 不是把网站内容自动变成模型可用的训练数据，也不是对爬虫行为的授权声明。它的定位是索引与导航：文件提供背景、指引和链接，智能体据此再去抓取具体的 Markdown 页面。规范明确说，文件本身保持小巧以便放入上下文，细节留在链接背后，只在需要时才被取用。因此，一个只写了 llms.txt 却没有提供对应 Markdown 版本的站点，并不能自动获得规范所描述的效果。

第三，规范对格式有精确性要求，这既是优点也是约束。文件需要能被解析器和正则表达式这类固定方法处理，这意味着自由发挥的排版、非结构化的长段落会削弱其可用性。同时，规范建议的 rel="alternate" 与 rel="describedby" 链接关系需要站点主动配置，无论是写成 HTML 元素还是 HTTP 响应头；没有配置的站点，客户端未必能发现这些文件。

第四，路径覆盖范围容易被误解。llms.txt 描述的是其所在路径之下的所有页面，/docs/llms.txt 覆盖 /docs/ 下的内容，而不是整个站点。如果站点有多个内容分区，需要按路径分别放置，或放在根目录以覆盖全站。

最后，规范提到该文件是 v2 版本，是根据两年采用过程中获得的经验对 v1 的更新，并另有一份 Changes 页面说明相较 v1 改动了什么以及原因。这意味着相关约定仍可能随实践继续调整，读者应以官方规范的最新版本为准。

参考资料

• llms.txt 官方规范