OneFileLLM：把 GitHub、arXiv、YouTube 與本機檔案收斂成一份 XML 餵給 LLM

它處理的是上下文蒐集，不是問答

把一份 GitHub 儲存庫、一篇 arXiv 論文、一段 YouTube 字幕和幾個文件頁面放進同一個 LLM 對話，實際工時多半花在複製、貼上與格式清理，而不是提問。OneFileLLM 針對的就是這段前置作業。README 對自己的定位寫得很直白：Content Aggregator for LLMs，把多來源資料彙整並結構化成單一 XML 檔，並自動複製到剪貼簿。

它的目標使用者是每天要餵大量外部材料給模型的人：讀論文的研究者、要對照多個 repo 實作的工程師、需要把官方文件整段丟進上下文的人。反過來說，如果你的問題只需要看一個函式或一段設定，這套工具的中介層反而多餘。它不生成回答、不做向量索引、也不快取語意，輸出就是一坨文字，只是排列得有結構。

輸入解析與 GitHub 的 ref 參數

README 列出的輸入型別涵蓋本機路徑與目錄、GitHub 儲存庫與 pull request、GitHub issues（可用 state 查詢參數控制 all、open、closed）、網頁文件、YouTube 影片、arXiv 與 Sci-Hub 論文，以及 PMID、doi、arxiv: 這幾種前綴標記。多個來源可以一次串在同一行命令裡。

分支處理是少數在文件中講清楚機制的部分。當你給的 GitHub 網址包含分支，例如 https://github.com/openai/whisper/tree/main/whisper，工具會解析 tree/ 這一段，並在請求時帶上 ref 參數，因此指定的是分支或標籤而非預設分支。這一點對照原始碼版本很重要：同一個 repo 的 main 與某個 release tag，內容可能差很多，而 LLM 不會知道你餵的是哪一份。

輸出格式是 XML。README 沒有在可見段落裡展開 schema 細節，所以實際欄位結構與巢狀方式需要你跑一次、或直接讀原始碼確認，這裡無法代為斷言。

安裝：pip 套件與可編輯安裝兩條路

最短路徑是直接裝套件，不必先 clone：

pip install onefilellm

裝完即可使用 CLI 與 Python API。若要改原始碼並讓改動立即生效，README 給的是可編輯安裝，在專案根目錄執行：

pip install -e .

從原始碼開始的話則是 clone 後 pip install -r requirements.txt。CLI 的呼叫形式為 onefilellm [OPTIONS] [INPUT_SOURCES...]，例如：

onefilellm ./docs/ https://github.com/user/project/issues/123

GitHub API 存取建議先設環境變數：export GITHUB_TOKEN="your_personal_access_token"。README 用 recommended 描述這件事，沒有說明未設定時的具體後果，但抓取 GitHub 內容會走 API 請求是合理的推論，未帶 token 的請求配額通常低得多。

Python 端則從套件匯入 run 函式，傳入來源清單：

from onefilellm import run run(["./docs/"])

這代表它同時是可嵌入的函式庫，不只是 shell 工具。

爬取參數與尊重 robots 的預設

命令說明裡最大一組選項是 crawl 系列，可見網頁抓取不是附帶功能而是獨立子系統。可調的包括 crawl-max-depth、crawl-max-pages、crawl-concurrency、crawl-delay、crawl-timeout、crawl-user-agent，以及 crawl-include-pattern 與 crawl-exclude-pattern 兩組路徑篩選。內容處理方面有 crawl-include-images、crawl-no-include-code、crawl-no-extract-headings、crawl-no-clean-html、crawl-no-strip-js、crawl-no-strip-css、crawl-no-strip-comments，還有 crawl-follow-links、crawl-restrict-path、crawl-no-include-pdfs、crawl-no-ignore-epubs。

值得注意的是 crawl-respect-robots 以肯定式命名，而其他多數開關是 no- 前綴的否定式。這種命名不一致本身透露了預設值的方向：清理 HTML、剝除 JS 與 CSS、抽取標題、包含程式碼區塊應該是預設開啟，而 robots 遵守也是預設行為。README 沒有逐條列出每個旗標的預設值，要精確掌握得靠 --help-topic crawling 或直接讀原始碼。

實務上這組參數決定了抓取是「淺嚐一頁」還是「整站搬走」。crawl-max-pages 與 crawl-delay 直接影響對目標站點的負載，這兩個值在你能確認之前不該隨意放大。

別名與管線：把重複指令收成一個詞

別名系統處理的是重複性。基本用法是把一組來源綁成名字：

python onefilellm.py --alias-add mcp "https://github.com/anthropics/mcp"

也可以一次綁多個來源，README 的範例把 React、React 文件與 Next.js 三個來源收進 modern-web 這個別名。更進一步是帶 {} 的動態佔位符，例如 --alias-add gh-search "https://github.com/search?q={}"、--alias-add gh-user "https://github.com/{}"、--alias-add arxiv-search "https://arxiv.org/search/?query={}"，使用時再代入實際值。管理指令有 --alias-remove、--alias-list、--alias-list-core。

另一條路是標準輸入管線。cat large_dataset.json | python onefilellm.py - --format json 把本機檔案接進來，curl -s https://api.github.com/repos/microsoft/vscode | python onefilellm.py - 則是把任一 API 回應接進來。搭配 --clipboard 與 --format markdown 可以直接吃剪貼簿裡的內容。這讓它不只能當命令列工具，也能塞進既有的 shell 流程。

--format 支援 text、markdown、json、html、yaml、doculing、markitdown 七種，用途是覆寫自動偵測結果。當自動判斷把 JSON 當成純文字處理時，這個旗標是必要的修正手段。

輸出是一份文字，不是索引

最實際的限制在輸出端。整份彙整結果是單一文字檔並複製到剪貼簿，沒有分段、沒有嵌入、沒有檢索層。來源一多，輸出就會膨脹，而它不會替你判斷哪些部分重要。repo 的 topics 裡列了 tiktoken，合理推測與 token 計算有關，但 README 可見段落沒有說明它如何呈現或限制長度，因此實際是否會提示你超出上下文，需要自行確認。

第二個限制是抓取範圍的不可控性。crawl-include-pattern 與 crawl-exclude-pattern 提供的是路徑層級的白名單與黑名單，不是語意篩選。想要「只抓跟認證有關的頁面」這種需求，這套機制幫不上忙。

第三個是來源相依性。arXiv、YouTube、Sci-Hub 這幾條路徑各自依賴外部服務與對應的 Python 套件，requirements.txt 因此會比一般純解析工具厚。任何一個上游改變回應格式，對應來源就會失效，而這類失效通常不會有優雅的錯誤訊息。

最後是它不適合什麼：需要即時更新的場景。它是單次執行的快照工具，沒有排程、沒有增量同步，每次執行都是重新抓取。

與直接寫腳本或改用文件抓取工具的差別

替代方案不是某個特定競品，而是「自己寫 requests 加 BeautifulSoup 的腳本」。差異在於 OneFileLLM 已經把多來源的分支邏輯、格式偵測、HTML 清理與 XML 組裝寫好，並且附上別名與管線介面；自寫腳本則是完全可控，你能精確決定每個站點抓什麼、怎麼過濾、輸出什麼結構，代價是每新增一種來源就要重寫一段。

如果你的來源固定只有一兩個網站，自寫腳本通常更短也更透明。OneFileLLM 的優勢出現在來源種類混雜的時候：今天抓 GitHub PR、明天抓 arXiv、後天抓 YouTube 字幕，同一行命令換個參數就好。

另一個方向是改用專門的文件抓取服務或 MCP 類工具，把抓取與檢索綁在一起。OneFileLLM 的設計前提相反，它只負責產出文字，檢索與否交給你的 LLM 工作流決定。這個分界讓它容易嵌入，也讓它無法處理超出上下文視窗的資料量。

維護成本與 MIT 授權的實際意涵

專案是 MIT 授權，這意味著你可以修改、再散布、商用，只要保留著作權與授權聲明。這裡不構成法律意見，實際條文請自行閱讀 LICENSE 檔。

維護成本主要來自兩個地方。一是依賴鏈：arXiv、YouTube、PDF、網頁爬取各自對應不同的第三方套件，pip install -r requirements.txt 之後，這些套件會隨時間出現相容性問題，尤其在 Python 版本升級時。二是上游介面變動：爬取類功能天生脆弱，目標網站改版就可能讓抽取結果變成空字串或殘缺 HTML，而且往往不會拋出明顯錯誤。

專案沒有檢索到任何 release，代表版本管理可能以 main 分支為主。這對採用者的意涵是：pip install onefilellm 拿到的版本與 clone 下來的最新程式碼可能不同步，遇到問題時要先確認自己跑的是哪一份。若你的工作流程對穩定性有要求，鎖定特定 commit 會比追 main 安全。

整體而言，這是一套定位清楚的工具：把抓取的雜事自動化，輸出單一文字。它不解決上下文長度、不解決內容品質，也不解決來源網站的封鎖。判斷它值不值得放進流程，關鍵在你每週花多少時間在複製貼上。

編輯結論

如果你經常要手動把 repo、論文與文件頁複製貼進對話視窗，OneFileLLM 值得裝來試；它的價值在於把抓取與格式整理自動化，而不是替你判斷內容好壞。若你只需要單一檔案或單一網址，直接複製貼上更快，額外裝一套 Python 依賴不划算。導入前先確認三件事：requirements.txt 是否與你環境的 Python 版本相容、沒有 GITHUB_TOKEN 時 GitHub 來源是否會因速率限制而中斷、以及爬取類參數（crawl-max-pages、crawl-delay、crawl-respect-robots）的預設值是否符合你要抓的站點規範。

官方來源

1. Issues
2. jimmc414/onefilellm on GitHub
3. License: MIT
4. README