llms.txt v2 发布：改了什么，你该更新什么
2026 年 8 月 10 日，Jeremy Howard 发布了 llms.txt 提案的 v2，这是该格式自 2024 年 9 月问世以来的首次修订。两年的落地实践，清晰地暴露出哪些东西缺失、哪些含糊不清，以及哪些根本没有按规范设想的方式被使用。
先说让人安心的部分：你现有的 llms.txt 依然有效。 文件格式本身没有变化。变的是文件周边的一切，尤其是对一个被成千上万采用者反复追问的问题的回答。
v2 解决的问题
v1 让你发布一份塞满链接的 llms.txt，并在 page.html.md 提供页面的干净 Markdown 版本。但它从未把这两端连起来。
用 Howard 的说法，这个文件”把智能体指向了页面，却没有任何规范内容告诉它们 Markdown 版本究竟在哪里”。
于是，落到 https://example.com/docs/auth 的智能体，无法可靠地回答两个基本问题：
- 这个页面有 Markdown 版本吗？在哪里？
- 有覆盖这个页面的
llms.txt吗？在哪里？
它只能靠猜：试着加 .md，试试根目录的 /llms.txt，然后听天由命。v2 用明确声明取代了猜测。
变更一：用链接关系让 Markdown 可被发现
这是最核心的改动。v2 推荐两个标准的 HTML 链接关系：
rel="alternate" type="text/markdown"从页面指向它的 Markdown 版本rel="describedby"从页面指向覆盖它的llms.txt
你可以在 <head> 里用 <link> 元素提供：
<link rel="alternate" type="text/markdown" href="/docs/page.html.md" />
<link rel="describedby" href="/docs/llms.txt" />或者，对多数团队更合适的做法，用 HTTP 响应头 Link:：
Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"响应头方式为什么重要：你可以在 Web 服务器或 CDN 配置里加上它，完全不用改动任何模板。它同样适用于非 HTML 资源，包括 Markdown 文件本身。如果你在用 Cloudflare、Netlify、Vercel 或 nginx，这只是一次配置改动，不是迁移。
顺便说一句，这些并非新造的约定。alternate 和 describedby 都是已在 IANA 注册的链接关系。v2 选择复用 Web 现成的管道，而不是另造一套。
变更二：两种 Markdown URL 模式都获得认可
v1 只规定了一种约定：在完整 URL 后追加 .md，于是 /docs/tutorial.html 变成 /docs/tutorial.html.md。
而实践中，不少发布工具选择了另一种同样自然的做法，直接替换扩展名：/docs/tutorial.md。v2 两者都接受。
| 模式 | 原始 URL | Markdown 版本 |
|---|---|---|
追加 .md | /docs/tutorial.html | /docs/tutorial.html.md |
| 替换扩展名 | /docs/tutorial.html | /docs/tutorial.md |
| 无扩展名 URL | /docs/tutorial/ | /docs/tutorial/index.html.md 或 /docs/tutorial/index.md |
规范自己的注解是：实践”以值得被认可的方式偏离了 v1”。这是维护标准的健康心态。两种模式没有优劣之分，用你的技术栈自然产出的那种，然后用 rel="alternate" 声明出来即可。
变更三：子路径覆盖规则被精确定义
一个 llms.txt 覆盖其自身路径之下的 URL；当多个文件都适用时，智能体应当采用最具体的那一个。因此 /docs/llms.txt 覆盖 /docs/ 下的一切，并且对这些页面而言优先于根目录的 /llms.txt。
这不只是澄清。它正是 llms.txt 位于路径上、而非放在 /.well-known/（RFC 8615）下的原因。well-known URI 只能存在于源站根目录，而大量作者只掌控一个子目录：GitHub Pages 的项目站点、共享主机上的文档目录、企业域名下某个团队的板块。在 v2 下，只要你能在某个路径发布文件，就能为它发布一份 llms.txt。
如果你在同一域名下同时运营文档、博客和营销站，现在可以给每一块配一份限定范围的文件，并且明确知道哪一份会胜出。
变更四：移除 llms_txt2ctx，也移除 “Optional” 的机械语义
v1 附带了一个命令行工具 llms_txt2ctx，它把 llms.txt 展开成一大块上下文，其中 ## Optional 段落带有机械语义（上下文吃紧时跳过）。
v2 把两者都从规范中删除了。不是因为上下文展开不好，而是因为智能体并不是这么工作的。真实的智能体会查看或检索 llms.txt，然后只跟进它需要的链接。 文件保持得足够小以放进上下文；细节留在链接背后，按需获取。
## Optional 依然存在，但如今纯属约定：智能体在想要更短上下文时可以跳过的次要链接，不再附带任何工具层面的语义。
变更五：叙述追上了现实
2024 年的背景章节是一个预测：智能体将常态化地阅读网站。v2 把它改写成了对现状的描述，因为这早已是日常。
规范如今列出了证据：数千个站点发布该文件，文档平台自动生成，Chrome 的 Lighthouse 已把它纳入智能体浏览检查项进行审计，AI 实验室自己也在发布，OpenAI、Anthropic 以及 Google 的 Gemini 团队都为各自的开发者文档提供了 llms.txt。
格式依然要求的部分（未变）
这部分值得重申，因为它最容易被搞错，而且在 v2 中一个字都没动：
- 可选的字节顺序标记（BOM）
- 一个写有项目名或站点名的 H1。 这是唯一必需的元素
- 一段 blockquote，用简短摘要给出理解全文所需的关键信息
- 零个或多个 Markdown 区块（段落、列表等，标题除外），提供更多细节
- 零个或多个由 H2 划分的区块，包含”文件列表”
每个文件列表都是 Markdown 列表，每一项包含一个必需的链接，其后可选地加上 : 与说明：
# 标题
> 可选描述写在这里
可选细节写在这里
## 章节名称
- [链接标题](https://link_url): 可选的链接说明
## Optional
- [链接标题](https://link_url)你的 v2 检查清单
- 保留现有文件。 它依然符合规范，不用重写。
- 为重要页面提供 Markdown 版本，两种 URL 模式任选其一。
- 加上那两个链接关系，最好用 CDN 或服务器层的 HTTP
Link:响应头，这样完全无需改模板。 - 若一个域名承载多个独立板块，就按路径划分文件范围。
- 让链接指向 Markdown，而不是 HTML。
llms.txt里的链接应当通向对 LLM 友好的内容。这在 v1 就是要求，也是最常见的错误。 - 发布前先校验，确保你上线的文件真的能被解析。
v2 没有改变的一件事
llms.txt 仍然是一份提案，而非已批准的 Web 标准，也依然不是 Google 的排名因素。Google 已明确表示不使用该文件。v2 让这个格式对确实会读取它的智能体更有用，这个群体真实存在且在增长，但它不会把这个文件变成 SEO 杠杆。
如果有人把 v2 当作排名升级卖给你，请先读 llms.txt 是 Google 排名因素吗？
小结
v2 是一次小而务实的修订，补上了 v1 唯一的结构性缺口：智能体读得懂你的文件，却找不到它，也找不到它所指向的 Markdown。两个链接关系填平了这个缺口，其中一个只需一行 CDN 配置。
准备好更新了吗？用我们的 llms.txt 生成器生成符合规范的文件，再用 llms.txt 校验器核对格式。如果你还在权衡这个文件对自己的站点是否值得，可以先看 什么情况下需要 llms.txt。