code2prompt：把整個 repo 壓成一份可交付給 LLM 的 prompt
A CLI tool to convert your codebase into a single LLM prompt with source tree, prompt templating, and token counting.
秒懂
- 它是什麼？
- 它以 Rust 寫成，用 .gitignore 規則走訪檔案樹，套 Handlebars 模板輸出單一 prompt，並附上 token 估算。核心價值在於把「手動複製貼上」換成可重複的指令；代價是估算值與實際計費 token 之間仍有落差。
- 適合誰用？
- 如果你需要把本地 repo 的選定範圍整理成一份可重複生成的 prompt，並希望它遵守 .gitignore、能套模板、能輸出到 stdout 或剪貼簿，code2prompt 值得裝起來試。若你的工作是跨多輪對話逐步探索程式碼，或需要精確的 token 計費數字，它的單次輸出模型與估算方式都不合用，這種情況該考慮 MCP server 或直接讓 agent 讀檔。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 4 天前。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「上下文搬運」這件雜事
把一個資料夾交給 LLM，實際操作起來比想像中麻煩。你要決定哪些檔案算進來，要排除 node_modules 與建置產物，要在每個檔案前面補上相對路徑，還要在貼上的內容過長時自己想辦法取捨。做一次不難，做十次就變成純粹的體力活。code2prompt 把這個流程收斂成一條指令，README 的定位是「context engineering tool」，負責攝取 codebase 並格式化成 LLM 可用的形狀。
它的目標使用者有三類，README 講得很明確：手動為 ChatGPT 準備上下文的人、用 Python 打造 AI agent 的人，以及想跑 MCP server 的人。這三類對應到不同入口，CLI 給人用，pip install code2prompt-rs 給程式用，MCP 版本則讓 agent 自己去讀本地碼。同一套核心邏輯，包成三種介面。
這裡有個容易忽略的差別。它產出的是一份離線快照，不是互動式檢索。你跑一次，得到一份文字，然後自己決定要貼到哪裡。這個設計在「一次問清楚一個問題」的情境下很順，在需要來回追問、逐步縮小範圍的情境下就顯得笨重。
檔案走訪、模板、token 估算：三個各自獨立的環節
從 README 與 repo 結構可以看到，真正的重活放在 code2prompt_core 這個 Rust 函式庫裡，README 對它的描述是負責安全檔案走訪、遵守 .gitignore 規則，以及整理 Git metadata。CLI 與 Python SDK 都只是它的外層。這個分層意味著行為一致性由核心決定，你在 CLI 看到的過濾結果，跟從 Python 呼叫時應該相同。
流程大致是：先依 .gitignore 與使用者給的 glob 樣式決定檔案集合，再依模板把每個檔案渲染成帶路徑的區塊，最後串成單一輸出。模板用 Handlebars，這是它保留彈性的方式。不同任務需要不同開頭，例如請模型做程式碼審查，跟請模型補測試，需要的指示不一樣，模板讓這件事不必改動工具本身。
token 估算這一段值得單獨看。README 的說明是：以平行方式對每個檔案計數，再加上模板的估計開銷，並可選擇計入行號；完整渲染後的 prompt 不會再重新計數一次，而且估算不包含 JSON 輸出封裝。這幾句是整份文件裡資訊密度最高的地方，因為它同時交代了估算的來源與三個已知缺口。平行 per-file 計數快，但檔案之間的模板片段、分隔符、整體包裝都沒被算進去，所以估算值偏低是預期行為，不是 bug。
安裝路徑不只一條，選錯會拿到不同東西
README 給的安裝方式有四種，彼此不等價。cargo install code2prompt 裝的是 CLI。若在 Wayland 環境需要剪貼簿整合，要改用 cargo install --features wayland code2prompt，這個 feature flag 是編譯期決定的，裝完才發現剪貼簿不能用就得重裝。macOS 使用者可以走 brew install code2prompt。
Python 路線要特別注意套件名稱。pip install code2prompt-rs 裝的是 Python 綁定，不是 CLI。README 把它描述為 Rust Core 的快速綁定，適合 AI agent、自動化腳本或嵌進 RAG 流程。如果你在 Python 專案裡寫 import code2prompt 卻期待能呼叫命令列介面，方向就錯了。
基本用法很直白。code2prompt . 對當前目錄生成 prompt，預設輸出到 stdout，加 -c 則複製到剪貼簿。要存檔用 code2prompt path/to/project --output-file prompt.txt。這兩個旗標是文件裡明確出現的，其他選項得去官網文件查。
另外還有一條 agent skill 的路線，npx skills add mufeedvh/code2prompt。README 說明這個安裝器會把 skill 資料夾與模板加進你的 agent，過程中可能暫時 clone 整個 repo 來取檔案，但不會把 repo 其餘部分裝進去。它同時提到 skill 會引導 agent 先用 sem-core 看函式與類別的緊湊地圖，再讀相關原始碼與測試，並附上 entity-map 功能的安裝說明，標準建置則退回目錄地圖。這裡要注意：code2prompt CLI 本身要另外安裝，skill 不會幫你裝。
估算值與帳單之間的距離
最實際的限制就寫在功能列表裡，只是容易被略過。token 估算不重新計算完整渲染結果，也不含 JSON 輸出封裝。這代表兩件事。第一，當你加了很多模板文字，估算與實際的差距會拉大，因為模板開銷只是「估計」。第二，如果你用 JSON 格式輸出並把整包丟給 API，那層外殼的 token 完全不在估算內。
對照之下，README 在別處用了「Blazing Fast」這種行銷字眼，但沒有給任何數字。同樣地，per-file 平行計數聽起來有效率，文件也沒說明它用哪個 tokenizer、對不同模型是否一致。如果你要拿這個數字去對帳或做成本預算，得先自己驗證一遍，不能直接信。
另一個結構性限制來自它的輸出模型。整份 prompt 一次生成，沒有增量更新機制。大型 repo 上你會得到一份很長的文字，超出模型上下文時，工具不會幫你自動切分或摘要，只能靠 glob 樣式與排除規則事先縮小範圍。這是設計選擇，不是缺陷，但它把「挑選範圍」的責任完整留給使用者。
還有一個容易踩到的點：安全檔案走訪與遵守 .gitignore 是核心的賣點，但這也意味著輸出內容完全取決於你的忽略規則是否正確。若 repo 裡有未列入 .gitignore 的大型產物檔或資料檔，它們會被照實收進去，估算值與輸出長度一起膨脹。
與 MCP server 的取捨：快照還是服務
同一個專案裡就有替代方案，這讓比較變得具體。README 把 MCP Server 描述為「以本地服務形式執行 code2prompt」，讓 agentic 應用能有效率地讀取本地 codebase，而不會把上下文視窗撐爆。這是完全不同的取捨。
CLI 產出的是一份固定快照，你決定範圍、生成、貼上，整個過程是批次式的。MCP server 則是讓 agent 在需要時自己去取片段，範圍由 agent 的探索過程動態決定。前者可預測、可重現、可存檔留證；後者省上下文，但每次呼叫的內容不固定，你也較難事先審查到底送出了什麼。
選擇的判準不複雜。若你的流程是「我已經知道要看哪幾個目錄，生成一份 prompt 丟給模型」，CLI 更直接，輸出還能進版控或工單。若你的流程是「讓 agent 自己找答案，我不確定它需要哪些檔案」，MCP server 才合理，因為 CLI 的單次全量輸出在這種情境下只會浪費視窗。
順帶一提，README 提到 smart file reading 會簡化 CSV、Notebook、JSONL 等格式的讀取。這對含資料檔的 repo 有用，但也提醒一件事：這些格式被轉成文字後會佔掉可觀的 token，而估算是否涵蓋轉換後的膨脹，文件沒有交代。
維護成本與授權的實際含意
授權是 MIT，這是寬鬆授權，允許修改與再散布，只要保留版權聲明與授權條款。對內部工具或商業產品整合而言，這通常是可接受的路徑，但授權解讀涉及你的具體使用情境，必要時該問法務，本文不提供法律意見。
版本節奏可以從 release 記錄看出輪廓：v3.0.2 在 2025 年 4 月，v4.0.2 在 2025 年 9 月，v4.2.0 在 2025 年 12 月。從 3.x 到 4.x 是一次主版本跳躍，而 4.0.2 到 4.2.0 之間隔了約三個月。這表示介面或行為在 4.x 期間仍有調整，把 CLI 包進 CI 腳本或自動化流程時，建議鎖定版本，別讓建置流程自動抓到最新版。
升級成本主要落在兩個地方。一是模板變數，若官方在版本間調整了可用欄位，你的 Handlebars 模板會渲染失敗或產出缺漏內容。二是 feature flag，例如 wayland 這類編譯期選項，重新安裝時要記得帶上。至於 Python 綁定，套件名稱是 code2prompt-rs，與 CLI 的 crate 名稱不同，追蹤更新時要分別看。
維護面上還有一點值得留意：這個專案橫跨 CLI、Python SDK、MCP server 與 agent skill 四種交付形式。介面越多，維護面積越大，而 README 對各介面的細節著墨不一。真正投入前，先確認你打算用的那條路徑在官網文件裡是否有完整說明。
誰該用它，以及先驗證什麼
判斷標準回到工作模式。如果你經常需要把同一份程式碼庫的不同子集交給模型，而且希望每次生成的內容一致、可比較、可存檔，code2prompt 的價值很直接。.gitignore 支援與 glob 過濾讓範圍控制不必靠手動刪減，模板讓不同任務共用同一套流程。
反過來說，如果你的問題需要多輪追問、逐步縮小範圍，或者你打算把整包輸出直接丟進按 token 計費的 API，那要先解決估算落差的問題。README 明講估算不含完整渲染結果與 JSON 外殼，這種情境下它給的數字只能當粗略參考。
上手前建議按順序確認三件事。先跑 code2prompt . 看輸出結構是否符合你預期的檔案範圍，特別檢查有沒有非預期的大型檔案被收進來。接著用 --output-file 存一份，實際數一下長度，跟你需要的模型上下文比較。最後才是套模板，因為模板會改變開銷，也會改變你對估算值的信任程度。
如果驗證下來發現單次輸出太大，正確的做法不是期待工具有內建切分，而是回頭調整 glob 樣式與 .gitignore，把範圍縮到一次問答真的需要的那幾個目錄。工具的邊界就在這裡：它負責忠實地搬運你指定的內容，不負責判斷哪些內容值得搬。
編輯結論
如果你需要把本地 repo 的選定範圍整理成一份可重複生成的 prompt，並希望它遵守 .gitignore、能套模板、能輸出到 stdout 或剪貼簿，code2prompt 值得裝起來試。若你的工作是跨多輪對話逐步探索程式碼，或需要精確的 token 計費數字，它的單次輸出模型與估算方式都不合用，這種情況該考慮 MCP server 或直接讓 agent 讀檔。採用前先確認三件事：你的建置方式是否為 cargo install code2prompt，因為 Python 綁定要改用 pip install code2prompt-rs；你的模板是否依賴 README 未列出的變數；以及你的檔案樹是否含有大型產物檔，因為過濾規則會直接決定輸出大小。
社群筆記