谷歌预览CodeWiki：你能信任AI管理你的项目吗？

谷歌新放出的 Code Wiki 预览版，引起了开发圈挺多讨论。这个东西把数百个开源项目的“自动生成文档”抓进来，能在代码改了之后自动再生成文档，还带了个基于 Gemini 的聊天界面。官方还说未来会做一个能在企业私有仓库跑的 Gemini CLI 扩展，但定价和上线时间没说清楚。官方介绍写得很简短，许多细节得靠开发者自己去摸索。

看到它能把函数、类、模块这些从代码里捋出来写成文档，第一反应是省事。团队里新来的开发者最怕的，就是得花好几天甚至几周去读别人留的代码注释和实现细节。谷歌也把这点点名为软件开发里最耗时间的环节之一。Code Wiki 的出发点就是把这部分工作量往下压：代码一变，文档跟着更新，理论上能少掉不少沟通成本，入门速度也能快起来。

拿具体案例来看，会暴露出好几个现实问题。我们把它生成的微软 ASP.NET Core 文档看了下。微软官方本来就有完整手册，但面向贡献者的代码注释和贡献流程并不够细致。Code Wiki 在解释分布式缓存实现时，把代码结构、实现点罗列出来，表面上挺有用。它还提供聊天接口，可以直接针对仓库提问。有用户问能不能把 SQL Server 换成 PostgreSQL 作为分布式缓存后端，Gemini 回答说“当前代码里没有直接支持 PostgreSQL 的实现或开箱即用方案”。这话在被解析的仓库里并非完全错——仓库里的确 只看到 SQL Server 和 Redis 两种实现。问题是，微软的官方文档里有提法，可以通过 IDistributedCache 接口把 Azure Database for PostgreSQL 当作后端来用。这就说明，AI 的回答漏了点上下文判断：许多时候需要懂行的人来补上那些没有直接出目前代码里的线索。

再看 Vue 的例子。有位熟悉 Vue 的开发者看了 Code Wiki 给出的文档，评价是“凑合能用”，但提了两点毛病：一是生成内容带着“大模型推测”的味道，有时候在模糊和确定之间摆动；二是篇幅偏长，竟然达到了相关代码体量的五分之一。更有意思的是，Code Wiki 没把一些仓库的状态写清楚。像 vuejs/vue 的仓库实则两年前就不再维护了，活跃的是 vuejs/core，并且后者有独立条目。这样的细节对读者很重大，机器生成的说明常常漏掉。

社区里对这类自动化文档的反应分两派。一派觉得这是个不错的起点，尤其对新同事或者想快速熟悉仓库结构的人特别有用。另一派比较谨慎，担心把整个代码库的文档完全交给 AI，会出问题。有人直言，代码库文档最不希望 AI 去动，由于这类文档需要对项目的历史、设计取舍和上下游关系有深刻理解，而这恰恰是模型最容易短板的地方。

关于来源背景，有个有趣说法。Mutable.ai 的创始人 Omar Shams 在 Hacker News 上提到，Code Wiki 可以看成是 Auto Wiki 的重构版，而 Auto Wiki 是他公司在被谷歌收购前做的项目之一。换句话说，Code Wiki 并非凭空产生，而是把过去的一些实践、工具整合进了 Gemini 体系里。这种传承意味，能解释为什么产品能在短时间覆盖这么多仓库，但也同时带来了既有方案的优缺点。

官方没有把功能细节都写出来，许多能力要靠开发者实际跑一跑才能摸清楚。预览版里收录了数百个开源项目，但具体覆盖哪些项目、深度到什么程度、生成文档的可读性如何，这些都是实验性质。未来承诺的 Gemini CLI 扩展会让团队能在私有仓库里跑这套系统，但目前谁也说不准何时上线、怎么定价。

要提醒一点，Code Wiki 生产的文档里自己也会加一句“Gemini 可能出错，请务必复核”。这并不是摆设。AI 在把代码的客观实际——函数位置、调用链、参数类型这种——描述出来方面的确 有优势。但在涉及设计决策、历史缘由、为什么要这样实现等高层判断时，模型就显得力不从心。自动同步带来的另一个现实问题是：文档频繁更新会让人觉得不稳定。今天看到的说明，明天可能就变了。长远看，这种不稳定可能反而浪费人的时间，尤其当团队习惯于把文档作为权威参考时。

把 Code Wiki 和传统维基对比能看出更本质的差别。传统维基强调的是协作和开放，任何人都可以去改、去补充、去争论，条目在多人参与下不断被打磨，形成集体认知。Code Wiki 更像是自动堆文本，生成图表和解释，但没把多人编辑、审阅的流程内建进去。这意味着，如果文档完全依赖机器生成，就难以在团队实践中像人协作那样一步步校正和深化说明，容易停留在“表面可用”的阶段。

市场上不是谷歌一家在做这类事。像 Devin 推的 DeepWiki 也走类似路线，能为开源和私有代码库生成文档。不同公司的实现细节会有差别，列如权限管理、更新策略、输出格式等，但目标差不多：把“读代码”这件枯燥耗时的工作部分自动化。换句话说，自动文档化已经成了一条产业路，接下来考验的是谁把“自动”跟“可信”这两个目标玩得更平衡。

说点实用的提议，给正在思考把 Code Wiki 或类似工具引入团队的负责人。别把它当成替代人工文档的灵丹妙药。可以把它当作“第一版文档自动生成器”，用来快速产出结构化的说明和调用图表，再把人工审核、设计说明、历史记录这些必须有人来补的部分作为第二层工作。把自动生成的内容放到一个受控的流程里：机器先跑一遍，工程师再去复核和补充。这样既能省力，又不至于让文档变成一堆未经校验的文本垃圾。

最后一点小心思：工具再机智，也改不了团队沟通不到位的实际。文档是团队知识的外显形式，技术传承和设计逻辑往往藏在讨论记录、PR 评论、以及老开发者的经验里。把这些“隐性知识”挖出来，靠机器还做不到完全等价替代。Code Wiki 这种工具，最理想的状态应该是：减轻重复劳动，腾出人力做那些真正需要判断和经验的事情。接下来会怎样发展，得看开发者社区和企业团队怎么把自动化和人工审核结合起来，把这项工具用在恰当的场景。文章原始报道来自 The Register，作者 Tim Anderson，译者平川，策划 Tina，InfoQ 也做过翻译说明。