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 模型（Context、Container、Component、Code）四层架构文档。它的定位是「快速、聚焦的 C4 文档生成器」，项目本身已明确指向继任者 Terrain。
- 适合谁用？
- 适合已有稳定架构、需要按 C4 层次批量产出文档并接入 CI 的团队，尤其是把仓库当交付物、需要可审计文档的工程组织；不适合指望它替代人工架构评审，或者代码库本身还在剧烈重构、连模块边界都没定的项目。引入前先确认三件事：目标语言是否在 README 列出的支持范围内、你打算接入的模型服务（OpenAI、DeepSeek、Mistral、OpenRouter 等）是否可用、以及是否接受把外部知识以 PDF 或 Markdown 形式挂载进分析流程。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的是文档与代码脱节，而不是「没有文档」
多数团队的问题不是写不出文档，而是写完之后没人再动它。README 把这一点摆在最前面：手动文档「outdated, incomplete, or missing」，更新总是落后于代码变更。Litho 的切入点是把文档从「人写」改成「从源码推导」，产物是 C4 模型下的 Context、Container、Component、Code 四层描述，而不是一堆散落的 Markdown。
目标读者写得很直白：各种规模的开发团队、开源项目、企业开发者。但真正会用到它的是那种「代码结构已经相对稳定、需要对外或对新人解释架构」的场景。如果你的仓库还在每天重画模块边界，自动生成的架构图只会把混乱固化下来，反而增加阅读成本。这一点 README 没有提，但值得在引入前想清楚。
从源码到 C4 文档：机制里能确认的部分
根据 README 的描述，Litho 的流程是：分析源码，提取代码注释、结构以及相互之间的关系，再交给 LLM 生成文档。核心能力列表里写明了「AI-driven architecture documentation generation from codebase analysis」和「Intelligent extraction of code comments, structures, and relationships」。也就是说，代码解析和关系抽取在本地完成，LLM 负责把这些结构化信息组织成 C4 各层的叙述与图示。
C4 四层是它的输出骨架：Context 描述系统与外部的关系，Container 描述可部署单元，Component 描述容器内部的组件划分，Code 落到代码级说明。README 没有给出每一层具体由哪些文件或 AST 节点驱动，也没有说明关系抽取是基于语法解析还是基于启发式规则。这部分属于文档未覆盖的细节，评估时应当以实际输出为准。
另一个可确认的机制是外部知识挂载：README 的 Advanced Features 里写明可以把外部文档（PDF、Markdown、SQL 等）作为知识源挂载进来，用于增强分析。这意味着生成的文档不局限于代码本身，可以带上数据库结构或既有设计说明。
安装与运行：命令与配置键
README 给出的安装入口是 crates.io 上的 deepwiki-rs，页面上的版本徽章指向 https://crates.io/crates/deepwiki-rs，因此常规做法是通过 Cargo 安装：
cargo install deepwiki-rs
项目主页为 https://deepwiki.netlify.app/，README 中另有指向仓库 docs/en 与 docs/zh 的文档徽章，中文文档位于 docs/zh 目录下。
配置层面，README 的 topics 列出了 claude、deepseek、mistral、openai、openrouter 等关键词，说明模型服务是可选的、并且不止一家。但具体到配置文件路径、API key 的键名、模型选择的参数形式，README 正文并未给出示例，需要到 docs 目录里查。这是评估时第一个要落到实处的点：如果官方文档里没有完整的配置样例，接入成本会明显高于预期。
CI 集成是被明确提到的能力之一（Integrate with CI/CD pipelines），但同样没有给出可复制的 workflow 片段。
多语言支持的实际含义，以及它不擅长的地方
README 声明支持 Rust、Python、Java、Go、C#、JavaScript 等多种语言。这里的「支持」应当理解为能够解析并纳入分析，而不是每种语言的解析深度一致。不同语言的注释风格、模块系统、依赖表达方式差异很大，C4 的 Component 层在动态语言里本来就比在静态类型语言里更难界定。README 没有说明各语言支持是否对齐，这是需要自己验证的。
更实际的限制在于成本与稳定性。文档生成依赖 LLM 调用，代码库越大，需要送入模型的结构化信息越多，费用和耗时都会随之上升。README 用「in minutes」描述生成速度，但没有给出任何规模基准，也没有说明是否有增量生成机制，即改动少量文件后能否只重算受影响的章节。如果每次都要全量重跑，把它放进每次 commit 触发的 CI 流程里就会变得昂贵。
还有一类不适用场景：以算法实现或运行时行为为主的代码库。C4 擅长表达「谁调用谁、谁部署在哪」，对并发模型、内存布局、协议细节这类内容帮助有限。
与 Terrain 的关系：这是评估时最容易忽略的一条
README 顶部有一段醒目的说明：Litho has evolved into Terrain，并给出 https://github.com/sopaco/terrain。按 README 的说法，Terrain 在 Litho 之上增加了知识库与代码保持同步、更广的语言与框架支持、通过 ACP 让 Claude Code、Codex、DeepSeek Harness 等主流 agent 读取，以及内置 Litho Book。
同一段里还有一句关键定位：Litho stays the fast, focused C4 doc generator。也就是说，作者把 Litho 保留为专注 C4 文档生成的轻量工具，把 agent 环境管理、知识资产同步这类能力放到了 Terrain。
这对选型的影响是直接的：如果你要的是「给 AI agent 一份随代码更新的代码库地图」，README 指向的是 Terrain；如果你要的只是从源码生成 C4 架构文档，Litho 仍是作者推荐的那个更聚焦的选项。需要留意的是，本仓库最近一次 push 时间为 2026-08-14，最近发布版本为 1.5.0（2026-04-05），而 README 已经把演进方向指向了另一个仓库，长期维护重心的判断需要你自己做。
替代方案：DeepWiki 托管服务与通用代码问答工具的区别
README 自己把 Litho 描述为 DeepWiki-like，这个类比本身就指向了最主要的替代路径：DeepWiki 这类托管服务。两者的差别在数据流向上。托管服务通常要求你把仓库授权给它，由它在服务端索引并生成可访问的 wiki 页面，好处是零配置、打开就能看，代价是代码要离开你的环境，且输出格式和更新节奏由服务方决定。
Litho 走的是本地工具路线：代码解析在你自己这边完成，输出是 C4 结构的文档产物，可以进版本库、可以接 CI、可以按模板定制。README 的 Core Capabilities 里明确写了 Customizable template system for documentation output，这是托管服务一般不会给你的自由度。代价是你要自己配模型服务、自己承担调用费用、自己维护生成流程。
另一类替代是通用代码问答工具，它们回答「这个函数干什么」这类即时问题，不产出成体系的架构文档。如果你的真实需求是新人快速提问，那类工具更合适；如果你需要一份能提交、能评审、能长期留存的架构说明，Litho 的 C4 输出格式才是对的方向。
维护成本与 MIT 许可下的实际约束
Litho 以 MIT 许可发布。这意味着你可以自由使用、修改、再分发，包括商用，前提是保留版权与许可声明。需要注意的不是许可本身，而是生成内容的归属：文档由 LLM 根据你的代码产出，其中可能包含从代码注释里带出来的信息，是否适合对外发布取决于你的代码和注释里有什么，这一点与 Litho 的许可无关，需要按自己组织的规范判断。此处不构成法律意见。
维护成本主要有两块。一是模型调用费用，随代码库规模增长，且没有在 README 中看到增量生成的说明。二是文档质量的复核成本：自动生成的架构描述需要有人读一遍，确认它没有把某个模块的职责说反。README 提到的「Enhance code reviews by providing clear architectural context」暗示它更适合作为评审的输入，而不是评审的替代。
升级方面，仓库最近发布为 1.5.0，此前有 1.3.0 与 1.2.8，版本节奏并不密集。考虑到 README 已把演进方向指向 Terrain，升级前建议先看目标版本的 Release Notes，确认模板格式或配置键是否发生变动，再决定是否跟随。
编辑结论
适合已有稳定架构、需要按 C4 层次批量产出文档并接入 CI 的团队，尤其是把仓库当交付物、需要可审计文档的工程组织；不适合指望它替代人工架构评审，或者代码库本身还在剧烈重构、连模块边界都没定的项目。引入前先确认三件事：目标语言是否在 README 列出的支持范围内、你打算接入的模型服务（OpenAI、DeepSeek、Mistral、OpenRouter 等）是否可用、以及是否接受把外部知识以 PDF 或 Markdown 形式挂载进分析流程。最后以 crates.io 上 deepwiki-rs 的当前版本为准，并注意 README 已声明 Litho 演进为 Terrain，长期维护重心不在本仓库。
社区笔记