llms.txt v2 会破坏我现有的文件吗？

不会。文件格式没有变化——符合 v1 的 llms.txt 就符合 v2。变化涉及发现性（链接关系）、子路径语义和工具预期，而不是 Markdown 结构。

llms.txt v2 里的 rel="describedby" 有什么用？

它从页面指向覆盖该页面的 llms.txt 文件，这样智能体就不必猜测 URL。它可以是 HTML 的元素，也可以是 HTTP 的 Link: 响应头，而响应头形式对非 HTML 文件同样适用。

llms.txt 可以不放在站点根目录吗？

可以，而且 v2 定义了这意味着什么：一个文件覆盖其路径之下的页面；若有多个适用，智能体使用最具体的那个。因此 /docs/llms.txt 覆盖 /docs/ 下的一切。

llms_txt2ctx 还属于规范吗？

不属于。v2 移除了上下文展开工具，连带移除了「Optional」小节的机制含义。Optional 小节仍作为次要链接的约定被允许。

规范里有 llms-full.txt 吗？

没有——两个版本都没有。它是大型文档集常见的行业实践，有用但非必需。

指南

llms.txt v2：变了什么

Q: llms.txt v2 里的 rel="describedby" 有什么用？

它从页面指向覆盖该页面的 llms.txt 文件，这样智能体就不必猜测 URL。它可以是 HTML 的 元素，也可以是 HTTP 的 Link: 响应头，而响应头形式对非 HTML 文件同样适用。

发布: 2026-08-31

llms.txt 提案在 2026 年 8 月完成修订，距最初版本近两年。文件格式本身没有变化——按 v1 写的文件仍然是有效的 v2 文件。变化的是文件周围的一切：智能体如何找到它，以及规范预期使用什么工具。

格式没有变化

要求的结构与此前完全一致：可选的 BOM、写有项目名称的 H1（仍是唯一必需元素）、以块引用形式给出的摘要、可选的不含标题的正文，然后是零个或多个包含 Markdown 链接列表的 H2 小节。若你的文件按 v1 得 100 分，现在依然得 100 分。

1. 链接关系，让智能体不必再猜

这是实质性的新增内容，回答了两年推广中最常见的诉求：给定一个页面，智能体如何在不猜测 URL 的情况下找到它的 Markdown 版本，或者找到覆盖它的 llms.txt？

v2 用两个标准链接关系来回答：

rel="describedby"——指向覆盖该页面的 llms.txt。
rel="alternate" type="text/markdown"——指向该页面的 Markdown 版本。

两者都可以写成 HTML 的 <link> 元素：

<link rel="describedby" href="/llms.txt">
<link rel="alternate" type="text/markdown" href="/docs/page.html.md">

……也可以写成 HTTP 响应头。对于 Markdown 文件本身这类非 HTML 资源，这是唯一的办法，而且可以在 Web 服务器或 CDN 配置中设置，无需改动任何一个页面：

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

如果你此前按照建议用 rel="alternate" type="text/plain" 声明该文件——包括我们自己早期指南里的建议——请改成 rel="describedby"。在规范没有定义关系的时候，那是个合理的约定；现在规范有了。

2. 两种 .md URL 形式现在都允许

v1 只规定了页面 Markdown 副本的一种 URL 形式：在完整页面 URL 后追加 .md，于是 page.html 变成 page.html.md。实际上有若干发布工具选择替换扩展名，产出 page.md。v2 认可两种形式。对于不含文件名的 URL，追加 index.html.md 或 index.md。

这里没有需要迁移的东西——你已经在输出的那种形式，现在就是正确的。

3. 子路径文件有了明确定义

v1 允许 llms.txt 不在根目录，却从未说明这意味着什么。v2 给出了定义：一个文件覆盖其路径之下的页面；若有多个文件适用，智能体使用最具体的那个。也就是说 /docs/llms.txt 覆盖 /docs/ 下的一切，读取文档页面的智能体会优先用它而不是根目录的文件。

这对只掌控某个路径而非整个主机的人很重要——GitHub Pages 的项目站点、共享域名下的文档区块。这也正是规范坚持沿用惯例文件名、而不用 /.well-known/ 的原因：well-known 只能存在于源站根目录。

实际影响：如果智能体真正关心的部分是你的文档，那么为它单独准备一个 /docs/llms.txt 现在是一等选择，而不再是灰色地带。

4. 上下文展开工具被移除（「Optional」也失去了机制含义）

v1 介绍过 llms_txt2ctx，一个把 llms.txt 展开成单个 LLM 上下文的工具。v2 放弃了它，转而直接陈述预期：智能体查看或搜索 llms.txt，然后跟随所需的链接——因此链接应当指向对 LLM 友好的内容，而文件本身保持足够小，以便放进上下文。

随着这套工具一并消失的，是 ## Optional 小节的机制含义——它当初存在的目的就是告诉那些工具该省略什么。Optional 小节仍然允许，也仍然是标注次要链接（智能体可以跳过）的有用约定，只是不再驱动任何自动行为。

请注意，llms-full.txt 在两个版本中都不属于规范。它是被广泛采用的行业实践，对大型文档集是个好做法——只是别把它当成硬性要求。

这周该做什么

添加指向你的 llms.txt 的 rel="describedby"——模板里一行，或者 CDN 里一条响应头规则。
如果你发布 Markdown 副本，用 rel="alternate" type="text/markdown" 声明它们。
把任何 rel="alternate" type="text/plain" 的发现提示换成 rel="describedby"。
如果文档是最有价值的部分，考虑为它单独准备 /docs/llms.txt。
重新跑一遍校验器——它现在会报告你的页面是否声明了 v2 的链接关系，并按 v2 对智能体的要求跟随子路径文件。

为什么会有这次修订

因为前提不再是猜测。2024 年 9 月提出 llms.txt 时，「智能体会读你的网站」是一种预测。如今文档平台会自动生成该文件，Chrome 的 Lighthouse 在其 agentic browsing 检查中审计站点是否具备该文件，各家 AI 实验室也为自己的开发者文档发布 llms.txt。v2 就是一份提案在其假设被真实采用检验之后的样子。

继续阅读

校验你的 llms.txt →