yek：把整個 repo 餵給 LLM 之前的打包工具
A fast Rust based tool to serialize text-based files in a repository or directory for LLM consumption
秒懂
- 它是什麼？
- yek 用 Rust 寫成，把目錄或 repo 序列化成單一文字檔，預設吃 .gitignore、用 Git 歷史推斷檔案重要性，並在輸出超過上限時丟掉較不重要的檔案。它解決的是「上下文怎麼塞」這個很具體的工程問題，代價是排序邏輯不透明。
- 適合誰用？
- 如果你經常要手動拼湊多個檔案丟進 LLM，yek 省下的是挑檔案與排序的時間，值得裝來試；如果你的需求只是偶爾貼一兩個檔案，或你需要對輸出順序有精確、可重現的控制，那用 find 加 cat 反而更直接。採用前先確認三件事：跑一次 yek --debug 看它實際選了哪些檔案、用 yek --tree-only 檢查忽略規則有沒有漏掉不該進去的目錄、以及先讀 yek.yaml 的 priority 規則能不能覆蓋你專案的目錄結構。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 78 天前。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
yek 要解決的是上下文組裝，不是檢索
把一個 repo 交給 LLM 有兩種做法。一種是檢索：建索引、算相似度、只取相關片段。另一種是打包：把整個目錄攤平成一份文字，直接塞進上下文。yek 走的是第二條路，README 的定位很明確，它是一個序列化工具，不是搜尋引擎。
目標使用者是那些已經在用 Claude、ChatGPT 或本地模型讀程式碼，卻每次都要手動 cat 好幾個檔案、還要自己決定先後順序的人。README 舉的例子很單純：一個含 README.md、src/main.rs、src/utils.rs、tests/test.rs 的目錄，執行 yek 之後會產生一份文字檔，每個檔案前面用 >>>> 加上路徑當分隔。
這個工具的價值不在於它做了什麼驚人的事，而在於它把幾個瑣碎決定自動化：哪些檔案不該進去、進去之後誰先誰後、超過大小上限時先砍誰。這三件事手動做一次不難，做一百次很煩。
排序用 Git 歷史推斷，這是它最有趣的設計也是最不透明的地方
README 說明 yek 會「uses the Git history to infer what files are more important」，並且把重要的檔案排在輸出後面。理由寫得很直白：LLM 傾向更注意上下文中後段的內容。
這是個有觀點的設計。多數打包腳本按字母或目錄順序排，yek 則假設 Git 歷史中改動頻繁、較晚被觸碰的檔案更值得模型注意。問題是 README 沒有說明推斷的具體依據：是 commit 次數、最近一次 commit 的時間、還是兩者的加權組合？權重是多少？有沒有時間衰減？這些都沒有交代。
對使用者來說，這代表同一份目錄在不同時間跑 yek，輸出順序可能不一樣，而且你很難預測會怎麼變。如果你需要可重現的輸出，這是個要留意的點。設定檔裡有 `priority` 規則可以介入，但 README 只列出這個選項存在，沒有給完整的規則語法範例，需要自己翻設定檔或原始碼確認。
截斷策略：先丟檔案，不是先截內容
當輸出超過限制時，yek 的行為是移除整個檔案，而不是把某個檔案切一半。README 的註記寫著它「will remove any files that won't fit in the capped context size」，並且會盡量保留更重要的檔案。
這個選擇合理，因為半個函式對模型沒有用，反而可能誤導。但它也意味著截斷是階梯式的：如果剩下 200 bytes 的額度，而下一個檔案是 300 bytes，那個檔案就整個不進去，額度浪費掉。
大小限制有兩種模式。預設是 byte 模式，`--max-size` 接受 `10MB`、`128K` 這種寫法，預設值 10MB。另一種是 token 模式，用 `--tokens 128k` 啟用，README 說明此時 `--max-size` 的數字會被當成 token 數解讀。要注意的是 token 計數的實作方式 README 沒有說明，如果你依賴精確的 token 數對齊某個模型的上下文窗口，最好自己驗證一次。
安裝與最小可用指令
Unix 系系統的安裝是一行 shell：
curl -fsSL https://azimi.me/yek.sh | bash
Windows PowerShell 對應的是：
irm https://azimi.me/yek.ps1 | iex
若要從原始碼建置，README 給的步驟是 git clone 之後執行 cargo install --path .。
基本用法就是直接在目錄裡跑 yek，它會把結果寫到暫存目錄並印出路徑。幾個實際會用到的組合：
yek src/ | pbcopy 把輸出直接送進 macOS 剪貼簿，這是它自動偵測管道並改用串流輸出的行為。 yek --tokens 128k 限制 token 上限。 yek --max-size 100KB --output-dir /tmp/yek src/ 指定輸出位置與大小。 yek src/ tests/ 一次處理多個目錄。 yek "src/**/*.ts" 用 glob，README 特別提醒要加引號避免 shell 先展開。
輸出格式可以用 `--output-template` 換掉，預設是 `>>>> FILE_PATH\nFILE_CONTENT`，兩個佔位符是 FILE_PATH 與 FILE_CONTENT。要加行號用 `--line-numbers`，要在開頭附上目錄樹用 `-t` 或 `--tree-header`，但 README 註明這與 `--json` 不相容。只想看目錄結構則用 `--tree-only`。
yek.yaml 能調的比 CLI 多，但文件只列了選項名
設定檔放在專案根目錄，命名為 yek.yaml，也可以用 `--config-file` 指定路徑，或用 `--no-config` 完全跳過。README 說它能做的事有六項：加自訂忽略規則、定義檔案優先順序、擴充二進位副檔名清單、設定 Git 優先權加成、指定輸出目錄與檔名、設定輸出模板。
可設定的鍵包含 `max_size`、`tokens`、`ignore_patterns`、`unignore_patterns`、`json`、`debug` 等，大致對應同名 CLI 選項。
這裡是文件最薄的地方。README 列出了鍵名，但沒有給一份完整的 yek.yaml 範例，也沒有說明 `priority` 與 Git 優先權加成的實際語法與優先順序。忽略規則的比對語意、`ignore_patterns` 與 `unignore_patterns` 衝突時誰贏，同樣沒有交代。這代表初次採用時，你需要準備一份自己的設定檔並用 `--debug` 逐次驗證，而不是照著範例改。
什麼情況下不該用 yek
第一種情況是 repo 本身超過上下文窗口。yek 的截斷是丟檔案，不是摘要。如果核心邏輯散在五十個檔案裡而你只有 128k token 的空間，yek 會幫你挑，但它挑的方式基於 Git 歷史，不是基於你這次提問的內容。這種場景需要的是檢索，不是打包。
第二種情況是你需要精確控制進去的內容。yek 預設會推斷額外的忽略規則，README 提到包含 binary、large 等類型。這些推斷對大多數 repo 是好事，但如果你有一個刻意要納入的大型文字檔（例如產生的 schema 或語料），你得用 `--unignore-patterns` 把它撈回來，而且得先知道它被忽略了。
第三種情況是輸出必須可重現。排序依賴 Git 歷史，而 Git 歷史會變。如果你的流程需要每次產生位元組級相同的輸出，這個工具不適合，除非你完全用設定檔固定優先順序並且驗證過。
和 find 加 cat 的實際差別
最直接的替代方案就是自己組：find . -type f -not -path './.git/*' | xargs cat，或更講究一點用 git ls-files 過濾。
差別有三個層次。第一，忽略規則。自己組要嘛重寫一套，要嘛靠 git ls-files 間接套用 .gitignore，但後者不會處理 binary 與大型檔案。yek 內建這些推斷。第二，排序。find 的輸出順序由檔案系統決定，通常不穩定；yek 用 Git 歷史排序，至少是有意圖的順序。第三，大小控制。xargs cat 沒有上限概念，超過模型窗口就是你自己的事；yek 有 `--max-size` 與 `--tokens` 兩種模式並會主動丟檔案。
反過來說，find 加 cat 的優勢是完全透明：你看到什麼就是什麼，沒有隱藏規則，沒有歷史推斷，輸出可預測。yek 換來的是便利，付出的是可預測性。這個交換值不值得，取決於你的 repo 有多大、你多久跑一次。
維護成本與授權
授權是 MIT，這對內部工具與商業專案整合都沒有額外負擔。實際使用時要留意的不是授權條款本身，而是安裝腳本：Unix 與 Windows 的安裝都是 curl 或 irm 直接管線進 shell，這種做法在受管環境通常會被資安政策擋下。若你們的環境不允許，README 有提供 cargo install --path . 的原始碼建置路徑，這是比較容易過關的方式。
版本節奏看起來相當快，近期釋出包含 v0.25.5、v0.25.4、v0.25.3，時間集中在 2026 年 6 月。0.x 版號加上密集釋出，意味著 CLI 選項或 yek.yaml 的鍵名有調整的可能。如果你把 yek 寫進 CI 或腳本，建議把版本固定住，而不是每次跑都抓最新。由於 README 沒有提供向後相容性承諾的說明，升級前先在自己的 repo 上跑一次 `yek --debug` 比對輸出，是成本最低的驗證方式。
編輯結論
如果你經常要手動拼湊多個檔案丟進 LLM，yek 省下的是挑檔案與排序的時間，值得裝來試；如果你的需求只是偶爾貼一兩個檔案，或你需要對輸出順序有精確、可重現的控制，那用 find 加 cat 反而更直接。採用前先確認三件事：跑一次 yek --debug 看它實際選了哪些檔案、用 yek --tree-only 檢查忽略規則有沒有漏掉不該進去的目錄、以及先讀 yek.yaml 的 priority 規則能不能覆蓋你專案的目錄結構。
社群筆記