Litho（deepwiki-rs）：用 Rust 把程式碼庫編譯成 C4 架構文件
Turn code into clarity. Generate accurate technical docs and AI-ready context in minutes—perfectly structured for human teams and intelligent agents.
秒懂
- 它是什麼？
- Litho 是一套以 Rust 撰寫的 AI 文件產生引擎，掃描原始碼後輸出 C4 模型的架構文件。它的價值在於把文件產生納入建置流程，代價是你得接受 LLM 的輸出品質與 API 成本。
- 適合誰用？
- 如果你已經在用 LLM 產生程式碼相關內容，而且需要一份可進版控、可放進 CI 的 C4 架構文件，Litho 值得裝起來試一次，先用 cargo install deepwiki-rs 跑單一子目錄確認輸出格式是否符合團隊慣例。若你的程式碼不能離開內網、或團隊不打算支付任何 LLM API 費用，這個工具就不適合，因為 README 明列多個雲端供應商，且未描述本地模型的替代路徑。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Litho 要解的問題不是「沒有文件」，而是文件與程式碼不同步
多數團隊不缺文件，缺的是與當下程式碼一致的文件。README 用一張對照表描述這個落差：手寫文件會過時、格式不一致、難以維護；AI 產生的版本則宣稱能隨程式碼變動更新、具備一致的 C4 結構。這個對比當然是行銷語言，但它指向的痛點是真的。當一個服務被拆成多個 crate 或模組，新進成員要花在「這塊程式碼在整體架構裡的位置」的時間，往往比讀程式碼本身還多。
Litho 的目標讀者是開發者、架構師與技術主管。README 另外列出開發團隊、開源專案與企業軟體開發者。值得注意的是它同時主打 CI/CD 整合，這代表作者設想的用法不是「偶爾跑一次產生文件」，而是把產生動作掛在每次提交之後。這個定位決定了後面所有的取捨：既然要進 CI，就得有非互動的執行方式與可重複的輸出。
C4 模型是輸出格式，不是分析引擎
Litho 的輸出對應 C4 模型四個層次：context、container、component 與 code。README 把這四層列為核心能力，並提到會自動抽取程式碼註解、結構與關係，再套用可自訂的模板系統產生文件。
這裡要分清楚兩件事。C4 是輸出的骨架，決定文件長什麼樣；真正做判斷的是 LLM。README 把 Litho 描述為 AI-driven 引擎，供應商清單包含 OpenAI、Mistral、DeepSeek、OpenRouter 與 Claude，這些字串同時出現在專案的 topics 裡。也就是說，程式碼掃描負責收集素材，模型負責把素材組織成架構敘述。這個分工意味著輸出的準確度上限，取決於你餵給模型的上下文與模型本身的推理能力，而不是 Rust 這一側的解析器。
README 另外提到外部知識整合，可以把 PDF、Markdown、SQL 等文件掛載為知識來源，以及資料庫文件的自動產生。當你的架構決策散落在設計文件與 schema 裡、而不在程式碼註解裡時，這條路徑才補得上缺口。
安裝與設定：cargo 安裝，金鑰走環境變數
專案以 Rust 撰寫，發布在 crates.io 上，套件名稱是 deepwiki-rs，因此安裝路徑是 cargo install deepwiki-rs。README 沒有提供完整的 CLI 參數清單，實際的旗標與子命令需要以 repo 內的 docs/en 與 docs/zh 目錄為準，那兩個目錄在 README 頂部以徽章形式連出。
設定的關鍵在供應商選擇。既然支援 OpenAI、Mistral、DeepSeek、OpenRouter 與 Claude，就必須在某處指定用哪一家以及對應的金鑰。README 沒有明列設定鍵名稱，只把供應商名稱列為專案主題。實務上這類工具通常以環境變數讀取金鑰、以設定檔或命令列旗標選擇供應商，但具體鍵名我無法從現有材料確認，導入前務必先讀 docs 目錄。
版本方面，近期發布為 1.5.0（2026-04-05）、1.3.0（2026-03-10）與 1.2.8（2026-02-01）。三個版本集中在兩個月內，節奏偏快，鎖定版本號再進 CI 會比追最新版穩妥。授權為 MIT，這是寬鬆授權，允許修改與再散布，通常只要求保留著作權聲明；實際條文仍應由你自行確認，這不是法律意見。
它已經被自己的作者標記為過渡產品
README 最上方有一段公告：Litho 已演進為 Terrain。作者在新專案上加了幾項延伸能力，包括知識庫與程式碼保持同步、更廣的語言與框架支援、透過 ACP 讓 Claude Code、Codex、DeepSeek Harness 等代理讀取，以及內建的 Litho Book。同一段話也給了定位：Litho 維持為「快速、專注的 C4 文件產生器」。
這是評估時最重要的一條資訊。它不代表 deepwiki-rs 不能用，但代表新功能的投入方向已經轉移。對照近期版本仍停在 1.5.0，且最後推送時間為 2026-08-14，可以推測維護仍在，只是重心不在這裡。如果你的需求正好落在「產生 C4 文件」這個窄範圍，這個專案仍然對題；如果你要的是讓 AI 代理持續讀取程式碼知識庫，README 的建議是直接看 Terrain。
另一個現實限制是 LLM 依賴本身。文件產生的品質會隨模型、提示詞與程式碼規模變動，同一個 repo 在不同時間跑兩次，輸出的敘述可能不同。要放進 CI 當作可稽核產物，就得先想清楚版本差異要怎麼處理。README 提到可滿足合規的可稽核文件需求，但沒有描述任何確保輸出穩定或可重現的機制。
與 DeepWiki 託管服務的差別在於程式碼去哪裡
這個專案的名字本身就指向 DeepWiki。DeepWiki 是託管服務，把公開 repo 的網址交給它，就能得到一份可瀏覽的 wiki，使用者不需要準備金鑰、不需要安裝任何東西，代價是程式碼會被送到服務端處理。
Litho 走的是相反的路：它是一個跑在你機器或 CI runner 上的二進位檔，你自己決定把哪些內容送給哪一家模型供應商，輸出落在你的檔案系統裡，可以進版控、可以掛進內部站台。差別不在功能清單，而在資料流向與可控制性。私有 repo、受監管產業或需要產物留存的情境，託管服務通常第一關就被擋下，這正是 Litho 存在的空間。
反過來說，如果你要處理的是公開專案、只想快速看一眼架構，託管服務的前置成本是零，Litho 得多裝 cargo、設定金鑰、挑供應商，這些步驟在一次性需求上並不划算。
導入前該確認的四件事
第一，讀 docs/en 或 docs/zh 取得實際的 CLI 介面與設定鍵。README 只給了安裝層級的資訊，供應商選擇與知識來源掛載的具體寫法都在文件目錄裡，沒有這一步就無法排進 CI。
第二，用一個中等規模的子目錄先跑一次，檢查產出的 C4 圖與敘述是否對得上你團隊的架構詞彙。LLM 產生的架構描述常見的失敗模式是把目錄結構當成架構分層，如果你的 repo 有大量自動產生的程式碼或 vendored 依賴，這個問題會更明顯。
第三，決定金鑰的管理方式。既然支援多家供應商，就代表金鑰會出現在 CI 環境裡，這需要與你現有的 secret 管理流程對齊。
第四，把 Terrain 的公告納入判斷。這不是說 deepwiki-rs 會立刻停止維護，而是說當你遇到問題時，上游的修法可能出現在另一個 repo。對於要長期依賴的工具，這個風險必須先攤開來看。
編輯結論
如果你已經在用 LLM 產生程式碼相關內容，而且需要一份可進版控、可放進 CI 的 C4 架構文件，Litho 值得裝起來試一次，先用 cargo install deepwiki-rs 跑單一子目錄確認輸出格式是否符合團隊慣例。若你的程式碼不能離開內網、或團隊不打算支付任何 LLM API 費用，這個工具就不適合，因為 README 明列多個雲端供應商，且未描述本地模型的替代路徑。導入前先確認三件事：MIT 授權是否符合你的散布方式、供應商金鑰要放在哪個環境變數、以及專案已公告轉向 Terrain 後 deepwiki-rs 的維護節奏。
社群筆記