repo2txt：把整個 repo 變成一份 LLM 可讀的純文字
Web-based tool converts GitHub repository contents into a single formatted text file
秒懂
- 它是什麼？
- repo2txt 是一個純瀏覽器端的工具，把 GitHub、本機目錄或 zip 檔的程式碼攤平成單一文字輸出，附帶 token 估算。它的價值在於選檔與過濾，限制也在於此：輸出格式固定，且沒有伺服器端可以代你處理超大型 repo。
- 適合誰用？
- 如果你需要把一個中小型 repo 或幾個資料夾餵進 LLM，而且不想讓程式碼離開自己的機器，repo2txt 的瀏覽器端模型正好對上：npm run dev 起本機服務，或直接用線上版，貼上 GitHub URL 後用副檔名與 .gitignore 過濾再輸出。若你的 repo 大到瀏覽器記憶體吃不下、需要伺服器端增量處理，或需要自訂輸出格式（例如 JSON 結構、只保留函式簽章），這個工具目前的設計並不適合，README 也沒有提供輸出模板的設定項。
- 可以商用嗎？
- 未經許可不行。GitHub 在這個儲存庫中沒有找到授權檔案；沒有授權，預設即「保留所有權利」：你可以閱讀程式碼，但不能重複使用。使用前請看看 README，或先取得作者同意。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 42 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是選檔問題，不是抓取問題
把 repo 丟給 LLM 的痛點通常不在下載，而在挑選。整包 clone 下來動輒數十萬行，其中大半是 lock 檔、測試快照、圖片與 build 產物。repo2txt 的定位就是把這一步做成互動式介面：先載入檔案樹，再依副檔名勾選、依 .gitignore 排除、或直接指定資料夾，最後才產生輸出。README 對這個流程的描述是「Select files using the tree or extension filters」，輸出則是單一 .txt，可複製或下載。
目標使用者寫得很明白，是「AI-assisted development」的開發者，而且工具本身把來源分成四類：GitHub（含私有庫與 token）、本機目錄、zip 上傳，以及標為 Beta 的 GitLab 與 Azure DevOps。這代表它不是只服務開源專案的玩具，私有庫與本機未提交的程式碼同樣在範圍內。
比較容易被忽略的是輸出格式。README 只說「formatted text file」，沒有公布分隔符、檔頭格式或是否附帶路徑註解。這在實務上有差：如果你的 prompt 依賴固定的檔案分隔標記，你得先跑一次看實際輸出長什麼樣，不能從文件推斷。
資料流：provider 抽象、Web Worker 分詞、虛擬滾動
從 README 的技術棧可以拼出大致架構。前端是 React 19 加 TypeScript，建置用 Vite 5，狀態管理交給 Zustand，樣式是 Tailwind CSS 3。檔案處理用 JSZip，分詞用 gpt-tokenizer，長列表用 TanStack Virtual。
README 提到的三項效能設計值得分開看。第一是 code splitting，把各 provider 做成 lazy-loaded，避免一次載入所有來源的邏輯。第二是 Web Workers，分詞在背景執行緒跑，主執行緒不會因為要算幾十萬個 token 而卡住。第三是 virtual scrolling，讓檔案樹在號稱 10,000+ 檔案的 repo 下仍可操作。這三項對應的是三個不同的瓶頸：載入、計算、渲染。
隱私模型是這個架構的直接結果。README 寫「100% Browser-Based」「No server uploads, all processing is local」，GitHub token 只存在 sessionStorage。也就是說，除了呼叫 GitHub API 取檔案內容之外，程式碼不經過任何第三方伺服器。這對企業內部程式碼是關鍵差異，但同時也意味著所有重活都在使用者的瀏覽器上完成，記憶體與 CPU 上限就是你的上限。
另外有一個容易漏看的細節：README 把 repo2txt-classic 列為「classic version」，暗示目前的 master 是一次改寫。若你在找舊行為或舊介面，那是另一個 repository。
啟動方式與實際會用到的設定
本機執行的指令在 README 裡很完整。先 clone，再安裝依賴，然後起 dev server：
git clone https://github.com/abinthomasonline/repo2txt.git cd repo2txt npm install npm run dev
dev server 的位址是 http://localhost:5173/repo2txt/，路徑帶了 /repo2txt/ 這個 base，這點在設定反向代理或部署到子目錄時要注意。正式建置用 npm run build，輸出在 ./dist。
測試指令分成兩條：npm run test:unit 對應 Vitest，npm run test:e2e 對應 Playwright。README 另外指向 CONTRIBUTING.md 作為開發與架構指南，以及 AGENT.md 作為給 LLM agent 的設計文件，後者在同類專案裡少見，值得在改動架構前先讀。
使用端沒有什麼設定檔可言，因為它是瀏覽器工具。需要設定的只有兩處：GitHub personal access token（用於私有庫與提高速率上限，README 寫 5000 對 60 requests/hour），以及自訂 ignore patterns。支援的 URL 形式包含 https://github.com/owner/repo、帶 /tree/branch-name 的路徑，以及帶子資料夾的 /tree/branch-name/path/to/folder；README 特別註明含斜線的分支名稱如 feature/test/branch-name 也能正確解析。
效能數字要當成目標值，不是保證值
README 的 Project Stats 區塊列了幾個數字：主 chunk 約 330KB（gzipped）、3G 網路下首次載入小於 2 秒、E2E 測試 100% 通過率、Lighthouse 各項 95 分以上、相容 Chrome 90+、Firefox 88+、Safari 14+、Edge 90+。這些是專案自己陳述的目標或當下狀態，沒有附帶可重現的測量條件，也沒有說明是在多大的 repo 上測的。
真正會決定體驗的不是這些數字，而是 repo 規模與瀏覽器記憶體。README 說虛擬滾動能處理 10,000+ 檔案，但「能列出」和「能把內容全部放進記憶體並輸出」是兩件事。純瀏覽器端意味著沒有伺服器可以分批處理或串流到磁碟，所有檔案內容最終都要在頁面裡存在過。大型 monorepo 在這裡會遇到實際的天花板，而 README 沒有給出建議的檔案數或總大小上限。
速率限制則是另一個變數。未帶 token 時每小時 60 次請求，對於檔案數多的 repo 很快就會撞牆，因為每個檔案內容通常各算一次請求。這是採用前最該先算清楚的數字。
什麼情況下它會是錯的工具
第一種情況是輸出格式有硬性要求。repo2txt 產生的是它自己定義的格式化文字，README 沒有提供模板或結構化輸出（例如 JSON、XML 標籤、只保留函式簽章）。如果你的檢索流程需要穩定的中繼資料，你得在輸出之後自己再處理一次。
第二種是超大 repo。瀏覽器端處理的隱私優勢，換來的是無法把工作卸載到伺服器。當 repo 大到記憶體吃緊，這個工具沒有伺服器模式可以退。
第三種是自動化。這是一個互動式網頁工具，README 描述的都是點擊流程：貼上 URL、按 Load Repository、勾選、按 Generate Output。它沒有被描述成 CLI 或 CI 步驟，所以放進自動化 pipeline 並不順手。
第四種是來源不在支援清單內。GitLab 與 Azure DevOps 在 README 中標為 Beta，其餘自架 Git 服務（例如自架 Gitea、Bitbucket Server）沒有被提及。這種情況下本機目錄或 zip 上傳是替代路徑，但那就失去了直接從遠端抓取與分支選擇的便利。
同類工具的差異在於執行位置
這一類工具最常見的替代做法是命令列腳本，用 git clone 或 GitHub API 把檔案抓下來，再用 find、grep 加幾行腳本串成單一文字檔。差別不在功能而在三個地方。
執行位置：腳本在你自己的 shell 跑，repo2txt 在瀏覽器分頁裡跑。兩者都不上傳程式碼到第三方，但腳本可以搭配伺服器或 CI 執行，repo2txt 不行。
過濾的互動性：腳本要改排除規則就得改參數或改程式，repo2txt 把它做成檔案樹勾選與副檔名篩選，還有 .gitignore 支援。對於「先看看有哪些檔案再決定」這種探索式需求，介面確實比參數快。
token 估算：repo2txt 內建 gpt-tokenizer 做即時計數，並在 Web Worker 裡跑。自己寫腳本要達到同樣效果，得另外接一個分詞器，而且要注意不同模型的 tokenizer 不一樣。README 只提到 GPT token counting，沒有說是否支援其他模型的分詞規則。
反過來說，腳本的優勢是輸出格式完全由你控制，以及能處理 repo2txt 記憶體吃不下的大型專案。這兩者不是誰取代誰，而是取決於你要的是探索式的一次性準備，還是可重複、可進 CI 的管線。
維護成本與授權要先確認的兩件事
README 標示 MIT License，並指向 ./LICENSE。但 repository 的中繼資料沒有回報授權識別碼，README 的徽章與文字是唯一線索。採用前請直接開 LICENSE 檔案確認內容，這不是法律建議，只是文件與中介資料不一致時應以檔案為準。
MIT 的實務含義是你可以商用、修改、再散布，條件是保留著作權聲明與授權條款。對於要放進內部工具鏈的團隊，這通常不構成阻礙；但如果你打算把它包進產品，仍應確認相依套件的授權，README 列出的 React 19、Vite 5、Tailwind CSS 3、Zustand、JSZip、gpt-tokenizer、TanStack Virtual 各有自己的條款。
維護面上，repository 沒有回報任何 release，CHANGELOG 指向 GitHub Releases 頁面。這意味著沒有版本標籤可以鎖定，要重現特定行為只能鎖 commit。CI 由 GitHub Actions 負責，README 的 deploy workflow 徽章顯示部署是自動化的。
升級成本主要落在相依套件而非這個專案本身。React 19 與 Vite 5 都是相對新的主版本，若你要把它併入既有較舊的 frontend 專案，版本對齊會比修改 repo2txt 的程式碼更花時間。
編輯結論
如果你需要把一個中小型 repo 或幾個資料夾餵進 LLM，而且不想讓程式碼離開自己的機器，repo2txt 的瀏覽器端模型正好對上：npm run dev 起本機服務，或直接用線上版，貼上 GitHub URL 後用副檔名與 .gitignore 過濾再輸出。若你的 repo 大到瀏覽器記憶體吃不下、需要伺服器端增量處理，或需要自訂輸出格式（例如 JSON 結構、只保留函式簽章），這個工具目前的設計並不適合，README 也沒有提供輸出模板的設定項。採用前先確認三件事：LICENSE 檔案的實際內容（README 標示 MIT，但 repository 中介資料未回報授權）、GitLab 與 Azure DevOps 這兩個標為 Beta 的 provider 是否涵蓋你的來源，以及 token 計數是否對得上你要用的模型。
社群筆記