llms.txt v2 會破壞我現有的檔案嗎？

不會。檔案格式沒有變化——符合 v1 的 llms.txt 就符合 v2。變化涉及發現性（連結關係）、子路徑語意與工具預期，而非 Markdown 結構。

llms.txt v2 裡的 rel="describedby" 有什麼用？

它從頁面指向涵蓋該頁面的 llms.txt 檔案，這樣代理就不必猜測網址。它可以是 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 檔案，這樣代理就不必猜測網址。它可以是 HTML 的 元素，也可以是 HTTP 的 Link: 回應標頭，而標頭形式對非 HTML 檔案同樣適用。

發佈: 2026-08-31

llms.txt 提案在 2026 年 8 月完成修訂，距最初版本將近兩年。檔案格式本身沒有變化——依 v1 撰寫的檔案仍然是有效的 v2 檔案。變的是檔案周邊的一切：代理如何找到它，以及規範預期使用什麼工具。

格式沒有變化

要求的結構與先前完全一致：可選的 BOM、寫有專案名稱的 H1（仍是唯一必要元素）、以區塊引言呈現的摘要、可選的不含標題的內文，然後是零個或多個含 Markdown 連結清單的 H2 區段。若你的檔案依 v1 得 100 分，現在依然得 100 分。

1. 連結關係，讓代理不必再猜

這是實質性的新增內容，回答了兩年推行中最常見的訴求：給定一個頁面，代理該如何在不猜測網址的情況下找到它的 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 資源，這是唯一的辦法，而且可以在網頁伺服器或 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 網址形式現在都允許

v1 只規定了頁面 Markdown 副本的一種網址形式：在完整頁面網址後附加 .md，於是 page.html 變成 page.html.md。實務上有若干發布工具選擇替換副檔名，產出 page.md。v2 認可兩種形式。對於不含檔名的網址，附加 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 →