Skip to content

llms.txt:把文件寫給機器讀的那一份

2026年8月21日 1 分鐘
TL;DR llms.txt 是 Jeremy Howard 於 2024-09-03 提出的慣例(規範已更新至 v2):在網站根目錄放一份給 LLM 讀的 Markdown 索引。六個前端文件站實測:TanStack、shadcn、Zustand、AI SDK、Next.js 都有,React Router 是唯一 404。配套的 llms-full.txt(全文版)Anthropic、Cloudflare 等也已採用。這篇講規範內容、誰在用、以及它為什麼開始影響套件選型。
目錄
  1. 起源與規範
  2. 誰在用:六站實測
  3. 誠實面:爭議與局限
  4. 對這個 blog 自己的含義
  5. 整體來說
  6. 參考資料

🌏 English version

這個系列反覆出現一個判準:選文件「能被機器讀到」的套件。這篇把那個判準的載體講清楚。llms.txt 很像它名字影射的 robots.txt——一個放在網站根目錄的純文字慣例——但方向相反:robots.txt 告訴爬蟲不要看什麼,llms.txt 告訴語言模型看什麼、去哪裡看。

起源與規範

llms.txt 由 fast.ai 的 Jeremy Howard 於 2024 年 9 月 3 日提出,官方定位一句話:「A proposal to standardise on using an /llms.txt file to provide information to help agents use a website.」規範持續在維護,2026 年 8 月已更新至 v2——提案開頭自己就點出了時代變化:2024 年寫下提案時「agent 常態性使用網站」還多半是預測,現在是日常(coding agent 抓函式庫文件對 API、搜尋型助理讀頁面回答產品問題)。

格式刻意簡單,就是一份結構化的 Markdown:H1 站名、引言區塊做一句話摘要、然後用 H2 分節列出重點頁面的連結清單(每條附說明)。它解決的是 LLM 讀網站的三個實際痛點:context window 塞不下整個站、HTML 混雜導覽/廣告/JS 噪音、模型不知道哪些頁面是權威內容。llms.txt 等於站方自己回答「如果只能給模型看十頁,是哪十頁」。

實務上還長出一個配套慣例:llms-full.txt——不只給索引,直接把全站文件串成一份大 Markdown,適合整包塞進大 context window 或做 RAG 語料。Anthropic(docs.anthropic.com)、Cloudflare(developers.cloudflare.com)、AI SDK、Zod 都同時提供兩份(皆 2026-08 實測可達)。

誰在用:六站實測

選型總覽時實測了六個前端文件站(2026-08,HTTP 狀態碼):

文件站/llms.txt
tanstack.com✅ 200
ui.shadcn.com✅ 200
zustand.docs.pmnd.rs✅ 200
ai-sdk.dev✅ 200
nextjs.org✅ 200
reactrouter.com❌ 404

有和沒有的差別很具體。你的 coding agent 要用 TanStack Router 寫一段 file-based routing——它訓練語料裡這個庫的樣本少(系列第三篇講過這個弱點),徒手寫容易混進 React Router 的慣用法。有 llms.txt 時,工作流是「抓索引 → 定位 file-based routing 那頁 → 抓該頁 → 照現行 API 寫」;沒有時,agent 得爬 HTML 碰運氣,或直接憑過時記憶硬寫。llms.txt 是冷門套件對抗「訓練語料劣勢」的主要武器——這也解釋了為什麼採用最積極的是 TanStack、AI SDK 這些年輕生態,而存量最大的 React Router 反而還沒動:語料多的老牌套件,短期確實沒那麼痛。

誠實面:爭議與局限

llms.txt 不是沒有爭議,兩點值得記著。第一,它不是被搜尋巨頭背書的標準:Google 的 John Mueller 公開把它比作早已被搜尋引擎拋棄的 keywords meta tag——自我宣告的訊號無法拿來排名,並指出沒有主要 AI 服務聲明在用、伺服器 log 裡也看不到它們來抓(Search Engine Journal 報導);主流 AI 搜尋產品的抓取行為也不透明——你無法確知 ChatGPT search 或 Perplexity 有沒有讀你的 llms.txt。它目前最堅實的消費者不是 AI 搜尋,而是 coding agent 與文件工具(開發者明確把 llms.txt 餵進 context 的工作流)。第二,它有維護成本:索引跟文件脫節,就從幫助變成誤導——跟本站反覆驗證過的「內容會腐爛」是同一個問題,只是這次腐爛的是給機器的那份。

所以合理的期待是:把它當「對 agent 友善」的低成本投資與訊號,而不是 SEO 式的排名魔法。

對這個 blog 自己的含義

寫到這裡自然要問:內容站要不要跟進?本站的 AEO/GEO 系列整理過 KDD 2024 的 GEO 研究——AI 搜尋引用偏好具體數字、inline 標來源的內容;llms.txt 是同一個目標的另一個施力點,把「哪些文章是權威內容」直接告訴模型。對文件站它已近乎標配,對內容站它是低成本的順手投資:一份 Markdown 索引,列出最值得被引用的文章。

整體來說

llms.txt 賭的是一個正在應驗的前提:網站的讀者結構永久地改變了,機器讀者的佔比只會上升。它技術上簡單到近乎樸素——一份手寫的 Markdown 索引——但位置站得準:在「模型該讀什麼」這個問題上,給了站方第一次正式的發言權。對套件作者,它是低成本必做;對選型的人,它是一個誠實的訊號——願意維護 llms.txt 的專案,大概率也在乎 agent 時代的開發體驗;對內容作者,它是 GEO 工具箱裡最便宜的一件。

參考資料