本文基于 2026-06-09 对 OpenDeepWiki 与 AIDotNet/Means 生成页 的一次源码与页面抽检。样本里的生成配置是：目录由 gpt-5.5 生成，正文由 Mimo-2.5 生成；Mimo 侧累计消费约 1.3B token，总成本约 39 RMB，折算约 0.03 RMB / 百万 token。
先说结论
OpenDeepWiki 这轮生成质量已经明显超过"README 扩写器"。它能把一个 .NET 对象存储项目拆成 22 个左右的主题页，覆盖 S3 数据面、XlFs 存储层、Console 管理面、后台任务、可观测性、SDK、部署和测试等模块，并且页面底部会保留读过的源码文件列表。作为新项目的第一轮知识库，它非常有价值。
但它还不能直接等同于"事实数据库"。我在 Means 这篇概览页里发现了一个典型风险：页面将 Reed-Solomon EC 写入和真实 Rebalance 归入"尚未实现"，但当前 Means 仓库 README 与源码中已经有 reed-solomon-v1 写入路径、RebalanceObjectReplicasAsync 以及 Reed-Solomon/full-copy 两类 rebalance 分支。这可能是生成快照滞后，也可能是模型过度相信计划文档。无论原因是什么，它都说明：OpenDeepWiki 很适合做"第一版工程理解"，但高风险状态判断仍需要自动校验或人工抽检。
OpenDeepWiki 到底是什么
从最新版仓库看，OpenDeepWiki 不是一个简单的文档生成脚本，而是一套代码知识库平台。它可以从 Git URL、ZIP 包、本地目录导入仓库，生成结构化 wiki、README 摘要、多语言内容、思维导图和可选 Graphify 产物，再把同一份知识复用到公开文档站、内置聊天、嵌入式聊天 API 和 MCP 端点里。
截至我查询时，GitHub API 显示 AIDotNet/OpenDeepWiki 大约有 3.3k stars、425 forks、MIT 许可证，最近 release 是 v2.0.3，发布于 2026-05-30；主分支最近一次推送在 2026-06-04。技术栈也比较激进：后端是 ASP.NET Core / .NET 10，前端是 Next.js 16 + React 19，数据库支持 SQLite 和 PostgreSQL，AI 编排使用 Microsoft.Agents.AI，仓库处理依赖 LibGit2Sharp。
最关键的是，它的生成链路支持"目录模型"和"内容模型"分离。源码里的 WikiGeneratorOptions 有独立的 CatalogModel、ContentModel、TranslationModel、并发数、输出 token 上限和文档生成超时。也就是说，你这次"目录用 gpt-5.5、正文用 Mimo-2.5"的配置不是临时 hack，而是 OpenDeepWiki 的核心设计方向：用更强模型做信息架构，用更便宜模型铺开正文深度。
它的生成链路为什么值得关注
OpenDeepWiki 的文档生成不是把整个仓库一次塞给模型。它会先收集仓库上下文，包括 README、目录树、入口文件和项目类型；目录阶段给模型 ListFiles、ReadFile、Grep、WriteCatalog 等工具；正文阶段再给模型读源码、搜索实现、写文档和追加文档的工具。
这几个细节很重要：
GitTool会记录模型读过哪些文件，最终反映到页面底部的 Sources。DocTool支持WriteDoc和AppendDoc，所以长文档不是一次响应写完，而是分段累积。- 内容提示词明确要求代码示例来自真实文件、图表反映真实结构、冲突时选择最新或更权威来源。
TokenUsage会记录输入、输出、缓存 token、模型 ID 和业务操作，后续可以做成本核算。
这解释了为什么 1.3B token 这个数字看起来吓人但合理：真正昂贵的不是最终页面字数，而是反复读源码、搜索、工具调用、多页面并发、失败重试和多语言/图谱等后续任务。
Means 这篇 wiki 好在哪里
第一，目录结构是懂项目边界的。Means 是 S3-compatible 对象存储，不是普通 CRUD 项目。生成结果把 S3 数据面拆到地址解析、SigV4、Bucket/Object、版本控制、Lifecycle/CORS/Notification/Policy、XML 错误模型等主题；把存储层拆到 XlFs、MeansLogDb、写入原子性、multipart 与生命周期；还单独覆盖 Console、可观测性、SDK 和测试。这种拆法不是文件树映射，而是读者理解系统时真正会问的问题。
第二，正文密度足够。页面不是只说"支持 S3 API"，而是列出 Bucket CRUD、Object CRUD、ListObjectsV2、Multipart、Versioning、Lifecycle、CORS、Notification、Tagging、Policy 和预签名 URL 等能力。对一个评估对象存储项目的人来说，这种矩阵比泛泛而谈有用得多。
第三，Sources 是非常实用的可信度锚点。
这篇概览页显示读取了 29 个文件，包含 README、IMPLEMENTATION_PLAN、compose、解决方案文件、S3 endpoint、XlFsStore、配置、后台任务和 SDK 文件。即便正文有误，读者也能立刻回到源码入口复核。对 AI 生成文档来说，Sources 不是锦上添花，而是底线。
但问题也很清楚
最大的问题在"能力边界"部分。页面写得很像人工架构评审：明确列出 Replication、Object Lock、IAM/STS、多节点分布式数据分片、Reed-Solomon EC 写入、真实 Rebalance 等边界。这本来是非常好的写法，因为它避免把 roadmap 说成已实现。
问题是，当前 Means 仓库里能看到与页面结论冲突的实现信号：
- README 已说明普通
PutObject在本地在线磁盘满足条件时会写入reed-solomon-v1shards。 XlFsStore.IO.cs里存在 Reed-Solomon 写入路径和相关 Galois field 计算逻辑。XlFsStore.ClusterMaintenance.cs中RebalanceObjectReplicasAsync会区分 Reed-Solomon manifest 和 full-copy manifest，走不同 rebalance 分支。
这不代表 OpenDeepWiki 整体失败。相反，它暴露的是"AI 代码文档生成"最难的一类问题：状态判断。实现计划、README、旧文档、源码和当前分支之间可能互相矛盾，模型需要判断谁更新、谁更权威、谁只是预留接口。OpenDeepWiki 的提示词已经要求遇到冲突选择最新/权威来源，但从这个样本看，这条规则还需要更强的工程化保障。
39 RMB 的真正意义
1.3B token / 39 RMB，粗算约 0.03 RMB / 百万 token。这个成本水平会改变文档生成的经济模型：过去大家担心"文档生成太贵"，现在更现实的问题变成"便宜到可以大规模生成之后，谁来做质量闸门"。
目录用强模型、内容用便宜模型的策略是合理的。目录是知识库的骨架，一旦拆错，后面每页都会错位；正文则更适合用便宜模型在工具约束下展开。但低价模型更容易在状态边界、跨文件冲突、计划与实现关系上犯错，所以抽检重点不应该是文风，而应该是：
- 已实现 / 未实现的判断是否与当前分支一致。
- 配置默认值是否来自源码而不是旧文档。
- API 支持矩阵是否能在 endpoint、测试或 SDK spec 中找到证据。
- Mermaid 图是否真正渲染，且不是理想化架构图。
- Sources 是否覆盖核心实现，而不是只读 README 和计划文档。
我会怎么给它打分
如果只评这次 Means 样本，我的主观评分如下：
| 维度 | 评分 | 说明 |
|---|---|---|
| 信息架构 | 9/10 | 目录拆分很接近工程师理解路径，不是文件级堆砌。 |
| 技术深度 | 8/10 | 能覆盖协议、存储、后台任务、配置和测试，正文密度够。 |
| 可追溯性 | 8.5/10 | Sources 很有用，但正文里的关键断言仍缺少逐条证据标记。 |
| 新鲜度/状态判断 | 6.5/10 | 能力边界有疑似滞后或误判，需要版本快照和冲突检测。 |
| 经济性 | 9.5/10 | 这个 token 单价下，批量生成非常有吸引力。 |
| 可发布性 | 7.5/10 | 适合做公开 wiki 初稿；核心能力边界发布前要抽检。 |
对 OpenDeepWiki 的改进建议
第一，每个页面都应该展示生成时的仓库 commit SHA、生成时间、目标分支和模型配置。现在页面显示分支是 master，但没有把"这篇内容到底基于哪个源码快照"暴露给读者。对快速迭代项目来说，这会直接影响信任。
第二，为"能力状态"类断言加自动复核。比如页面说某功能未实现，可以自动 grep NotImplemented、相关 public API、测试名、README 状态和实现类，生成一个小型 contradiction report。模型可以继续写自然语言，但状态结论要经过工具校验。
第三，Sources 可以更进一步：不仅列文件，还标注每个文件贡献了哪些主题。读者看到 29 个文件很好，但不知道"Rebalance 判断来自哪个文件"。如果能按段落显示主要证据文件，可信度会更高。
第四，成本统计应该下钻到 repo、语言、阶段、页面。1.3B token 是总量，真正做运营时更想知道：目录消耗多少、正文每页多少、失败重试多少、缓存命中多少、哪些页面最贵、哪些模型最容易重试。
第五，Mermaid 渲染需要质量检查。抓取文本时我看到若干 Loading diagram... 占位，浏览器截图里有些图能渲染，但尺寸较小。对公开 wiki 来说，图表渲染失败应进入页面质量告警。
最后
OpenDeepWiki 的价值不在于"AI 自动写文档"这句口号，而在于它已经把代码知识库做成了一条可运营的流水线：导入、分析、目录生成、正文生成、翻译、思维导图、Graphify、聊天、MCP、token 统计和后台任务管理都在一个系统里。
这次 Means 样本说明，它已经能生成一份对工程师有实际帮助的项目 wiki；同时也提醒我们，AI 生成文档最危险的不是文风，而是"看起来非常确定的状态判断"。当 39 RMB 就能跑出 1.3B token 的内容时，生成本身不再稀缺，可靠的验证链路才是稀缺资源。
我的判断是：OpenDeepWiki 已经适合作为开源项目知识库的自动初稿系统，也适合作为团队内部代码理解入口；如果要把它作为权威对外文档，还需要把 commit 快照、关键断言校验和质量评分做成产品能力。那会是它从"好用的 AI wiki"变成"可信的工程知识库"的关键一步。