產生 llms.txt 檔案意味著輸出一個小型 Markdown 索引，其中包含一個必要的 H1 標題、一個選擇性的 blockquote 摘要、選擇性的補充說明，以及零個或多個 H2 區段，依用途將權威連結分組。這個檔案遵循 llmstxt.org 所提出的格式，其結構刻意保持可預期，以便語言模型與一般解析器都能毫無歧義地讀。順序很重要：H1 必須最先出現，摘要（若存在）緊接其後，自由格式的補充說明出現在任何 H2 區段之前，而 H2 區段本身也有明確定義的位置。策展比長度更重要。一個連結到站上每一頁的檔案，只是重複大型 sitemap 的過載，並浪費消費端的脈絡空間；一份精簡且刻意挑選的權威文件、產品說明與穩定參考頁清單，效果反而更好。llms.txt 是一個新興提案，而非 robots 指令、安全控管、sitemap 替代方案或保證可被探索的協定，因此產生檔案只是起點，而非終點。工作在於讓策展意圖明確、讓 Markdown 具決定性、並讓編輯決策可被審。
llms.txt 檔案中包含哪些內容
該提案固定了嚴格的順序，讓同一份檔案在不同解析器中讀取結果一致。必要元素只有一個：單一 H1，內含專案或網站名稱。之後你可以加入 blockquote 摘要、額外的非標題補充說明，以及零個或多個 H2 區段。每個 H2 區段包含 Markdown 清單項目，其必要核心是一個連結，後面可以選擇性地加上冒號與說明，描述該連結資源涵蓋的內容。標籤、說明、標題與摘要都會經過正規化處理，避免控制字元或意外的 Markdown 分隔符破壞結構，URL 在序列化前也會經過審查：HTTP 與 HTTPS 可接受，但帶有憑證的 scheme 以及可執行或內嵌資料的 scheme 都會被拒絕。重複的正規化 URL 會被回報，而不會默默重複新增。
該提案同時為 Optional 區段定義了一個慣例。位於名為 Optional 的 H2 之下的連結，代表在需要較短脈絡時可以略過的次要資料。工具不會自動將資源標記為 optional —— 這是關於哪些來源對理解網站不可或缺的一項編輯決策。
| 區段 | 是否必要 | 承載內容 |
|---|---|---|
| 含網站名稱的 H1 | 必要 | 識別該文件及其所描述的專案 |
| Blockquote 摘要 | 否 | 一段概述網站用途的介紹 |
| 自由格式補充說明 | 否 | 置於任何 H2 連結區段之前的脈絡內容 |
| H2 連結區段 | 否（零個或多個） | 依主題分組的權威資源 |
| Optional 的 H2 區段 | 否 | 在較短脈絡下可略過的次要資料 |
為何僅在本機產生的工具會改變工作流程
當產生器完全在你的瀏覽器中執行時，輸入內容從不離開這個頁面。llms.txt 產生器會建立一個遵循 llmstxt.org 提案格式的小型 Markdown 索引，但它不會爬取你的網域，也不會把你的 URL 送到外部服務。這樣的分離很重要，因為沒有任何純客戶端的表單能證明哪些動態頁面是權威、即時、可存取或值得推薦的。選擇資源的責任仍在你身上，而工具的工作是將你的決策序列化為可預期的文件，並依據同一份文件化的詮釋來驗證任何貼上的草稿。
具決定性的輸出同時代表：相同輸入在兩次執行下會產生完全相同的文字。這個特性讓你在編輯後重新產生檔案時，團隊成員之間不會出現偏差，也讓驗證器把該檔案視為內容，而非神秘的產物。輸出為純文字，下載檔名為 llms.txt，而同一份 Markdown 結構就是你在指定路徑上發佈的內容。
如何在三次檢閱中產生 llms.txt 檔案
這個工作流程是一個簡短的迴圈：彙整輸入、產生並審閱，接著驗證並發佈。下列步驟涵蓋工具實際控管的範圍，以及身為編輯者仍須自行負責的部分。
- 將網站或專案名稱作為必要的 H1 輸入。這是唯一必要的輸入；其餘皆為選擇性。
- 若需要一段式概述，請加入 blockquote 摘要，接著在區段出現之前，加入說明專案的自由格式補充內容。
- 將具權威性且高價值的連結，以清楚的 H2 標題分組。優先選擇文件、產品說明、政策與穩定的參考頁，而非整站傾倒。
- 產生具決定性的 Markdown，閱讀 Optional 區段與每一則說明，接著複製檔案或將其下載為 llms.txt。
- 驗證最終編輯後的檔案。將草稿貼到同一個產生器頁面上的驗證器，檢查必要的 H1、標題順序、連結清單語法、重複的目標，以及大小限制。
- 以純文字或 Markdown 相容的內容類型，將 llms.txt 發佈於 /llms.txt 或適當的子路徑。
- 定期重新驗證所引用的頁面，並在編輯後重新執行驗證器。驗證通過僅代表草稿符合工具對該提案的詮釋，並不等於認證更廣泛的供應商支援，生態系也可能持續演進。
若希望將驗證步驟視為獨立的審閱階段，如何在發佈前產生 llms.txt 並加以驗證一文，會透過更深入的範例，逐步走過相同的兩階段流程。
在發佈前編輯產生的 Markdown
下載檔案並非工作流程的終點，而是編輯審閱的起點。請把產生的 llms.txt 當作內容來閱讀，而非機械式的 SEO 產物。確認 H1 與 blockquote 摘要符合你向新同事介紹這個網站時的描述。逐一檢視每個連結，思考它是否為權威連結：它今天是否能回傳預期的內容？還是會重新導向到一個通用的登陸頁、行銷變體或已棄用的路徑？
審閱說明文字。工具允許你在每個連結後附加選擇性的冒號與說明；該說明必須是事實且簡潔的。避免在說明中堆砌行銷用語，或重複連結標籤。檢查 Optional 區段。工具不會自動將資源標記為 optional —— 這是關於哪些來源對理解網站不可或缺的一項編輯決策。若 Optional 標題底下的內容實際上全都至關重要，請重新命名該標題。反之，若一個「核心」區段裝的是次要資料，請將其移至 Optional。
最後，掃描是否夾帶私人 URL、staging 路徑或可能不小心進入說明的憑證。產生器會拒絕帶有憑證的 scheme，但複製貼上的說明仍可能洩漏內部主機，而一個多餘的井字號若在工具外編輯，也可能破壞標題順序。任何手動編輯後，都請在發佈前重新執行驗證器。
部署並重新驗證檔案
檔案通過審閱後，請於預定路徑發佈。大多數團隊會以純文字或 Markdown 相容的內容類型發佈於 /llms.txt。當策展的概覽描述的是特定子目錄時，子路徑同樣有效，例如文件入口網站的 /docs/llms.txt。該檔案應與既有的控管機制並存，而非取代它們。DeveloperHub 的 llms.txt 文件說明 robots.txt 如何為參與的爬表達抓取偏好、sitemap.xml 如何為搜尋探索盤點可索引的 URL、結構化資料如何描述實體與頁面內容，而 llms.txt 則為推論階段的使用提供經策展的 Markdown 概覽。每一種機制各自保有其用途。
重新驗證是契約的一部分。AnswerDotAI 的 llms-txt 參考儲存庫是提案變動時值得查看的公開樣板之一。在編輯已部署的檔案後，請定期重新執行驗證器，並手動重新測試已發佈的 URL。llms.txt 是新興提案，而非 robots 指令、安全控管、sitemap 替代方案或保證可被探索的協定。發佈檔案並不會強迫爬蟲或助理來請求它。它無法授予對被封鎖頁面的存取權、無法覆寫身分驗證、無法將內容從模型訓練中移除，也無法證明 AI 回答一定會引用你的網站。請衡量你自己的工具與工作流程是否實際使用了該檔案；將發佈視為起點，而非搜尋或引用改善的證據。
破壞已審 llms.txt 的常見陷阱
一份簡短的錯誤清單就能涵蓋大多數失敗的檔案：
- 捏造不存在的 .md URL。只有在網站確實能穩定提供 Markdown 版本時，才連結到 Markdown；否則請連結到 HTML 權威頁。
- 連結站上的每一頁。冗長的索引只是重複大型 sitemap 的過載，並浪費消費端的脈絡空間。
- 將 llms.txt 視為排名檔案。它是一份經策展的 Markdown 概覽，且採用屬自願性質。
- 在工具外編輯後，未重新執行驗證器就直接發佈。Markdown 相當脆弱；說明中一個多餘的井字號就可能破壞標題順序。
- 把一切都標為 Optional。Optional 代表次要；錯標會稀釋該區段的意義。
若你在權衡各種選項，WordPress 的預設 robots.txt：安全的起點對此有詳細說明。