读代码这件事，最消耗的从来不是算力，是上下文。
一个老仓库接手过来，文档可能早就过期了，README 只讲安装不讲边界，函数名看着都认识，连起来却不知道数据怎么流、模块为什么这么拆、改一行会不会把别的服务带崩。很多团队里，最花时间的工作不是写新代码，而是“先搞明白这坨代码到底怎么回事”。
Google 新出的 Code Wiki，正是在这件事上动刀。它不是又一个聊天壳，而是把仓库直接变成一套会自动生成、自动更新、能点进源码的活文档。你可以把它理解成：给代码库配一个实时维护的说明书，而且这本说明书不是人写的，是 Gemini 根据仓库结构自己长出来的。
先说结论：它解决的是“理解成本”，不是“编程能力”
Code Wiki 的核心定位很明确：让你更快读懂仓库。它现在支持公开 GitHub 仓库，主页上已经能看到一些示例仓库，比如 gemini-cli、go、flutter、kubernetes、react、python-sdk。页面上还直接写着一句话：Gemini-generated documentation, always up-to-date。
这件事的意义不在“炫”。它真正解决的是三个老问题：
- README 不够用：README 往往只讲安装和使用，讲不清架构、模块关系、调用链。
- 文档会过期：代码一变，文档就旧，最后没人愿意维护。
- 新人上手太慢：接手项目时，最贵的不是写第一行代码，而是先搞懂入口、边界和依赖。
Code Wiki 想做的，就是把这些静态、滞后的说明，变成能跟着代码一起刷新的知识层。
它看起来像什么
打开 Code Wiki，你会看到的不是一个普通搜索框，而是一套围绕仓库组织的知识界面：
它还有一个挺关键的设计：每个说明页面都能直接跳回源码。也就是说，这不是“AI 写了一份看上去很像样的总结”那么简单，而是把说明和原始代码绑在一起，方便你从解释跳回证据。
这比单纯做摘要更有价值。因为读代码最怕两件事：一是看不懂，二是看懂了却找不到出处。Code Wiki 尝试把这两步接起来。
最有用的场景，不是提问，而是上手
很多人看到这种产品，第一反应是“又一个问答机器人”。其实它更适合这几类场景：
1. 新人接手项目
新人最缺的不是语法知识，而是项目语境。比如：
- 入口在哪
- 主流程怎么跑
- 哪些模块是核心
- 哪些地方是公共底座，不能乱动
- 一个需求通常要改几层
Code Wiki 适合先帮你把仓库读一遍，再让你决定从哪里下手。
2. 老项目考古
很多仓库已经有年头了，文档碎、作者多、风格不统一。你读一个目录，经常要在多个文件之间来回跳。Code Wiki 的价值，是把这种“碎片化阅读”先收敛成一个索引层，至少让你知道先看哪，再看哪。
3. 大型开源项目研究
像 kubernetes、go、react 这类仓库，源码规模已经不是靠通读 README 能解决的了。Code Wiki 的分层文档和图示，至少能把你从“完全不知道从哪下手”推进到“知道该读哪条路径”。
它和 Claude Code、Gemini CLI 不是一回事
这个差别得讲清楚。
Claude Code / Gemini CLI：偏执行
这类工具更像“帮你做事”的 Agent。你给任务，它去找文件、改代码、跑命令、修 bug。
Code Wiki：偏理解
它的重点不是执行，而是把仓库说明白。你先读 Wiki，再决定是不是要让 Agent 动手。
所以它们不是替代关系，而是上下游关系：
这俩如果能连起来，工作流会顺很多：先看 Code Wiki 过一遍结构，再把真正要改的那块交给 Agent 去执行。这样比上来就把整个仓库扔给模型靠谱得多。
现在它已经能做什么
从 Code Wiki 首页和仓库页能看出来，它目前已经把几件事做得很实：
- 自动生成分层 Wiki：按模块、主题、逻辑层级组织内容。
- Talk to your codebase：可以自然语言问代码库。
- Linked back to your code：说明会链接回具体代码。
- Diagrams：能把复杂逻辑画成图。
- Always up-to-date：每次仓库变更后重新刷新文档。
它对 google-gemini/gemini-cli 这个仓库的页面甚至已经自动拆出了很多章节，比如：
- Application lifecycle and UI framework
- A2A server for inter-agent communication
- Backend logic and core services
- Behavioral evaluation system
- Performance and memory testing
- Project management and automation scripts
- SEA packaging
- Third-party dependencies
- Proactive system management tools
这说明它不是只做“简介页”，而是在试着把仓库拆成一套可阅读的知识地图。
也别把它想得太满
现在的 Code Wiki 也不是万能的。它至少有几个边界要看清：
1. 目前主要面向公开 GitHub 仓库
页面上已经写了：私有仓库支持是 Coming Soon。所以现在更适合开源项目、技术调研和公开知识整理。
2. 它仍然需要人工校验
页面底部直接提示了：Gemini can make mistakes, so double-check it. 这句话很重要。
意思很简单：它能帮你理解，但不能替你保证完全正确。特别是大型仓库、复杂依赖、跨语言项目，AI 总结很容易漏边界、错依赖或者过度概括。
3. 它更适合“读懂结构”，不适合直接取代源码
Code Wiki 能缩短理解路径，但最后判断还是要回到源码。它是入口，不是终点。
这类工具真正改的是什么
最表面的变化，是“文档自动化了”。
更深一点看，它改的是代码库的默认阅读方式。以前，仓库的阅读顺序通常是：
现在可以变成：
这一步看着不大，其实挺要命。因为它把“理解代码”从一个人的私人经验，变成了一个可复用的知识入口。新人、维护者、审查者、甚至别的 Agent，都可以从同一套结构化说明开始，而不是每次从零摸仓库。
适合谁
Code Wiki 更适合这几类人：
- 接手老项目的人
- 读大型开源仓库的人
- 要做代码库研究、技术调研、架构梳理的人
- 想把仓库理解成本前置的人
- 需要给团队做“活文档”的工程团队
如果你的仓库本身变化频繁、结构复杂、协作人数多，它的价值会更明显。
不适合谁
它也不是给所有人准备的：
- 只想要一个 FAQ 页面的人
- 不打算读源码，只想让 AI 全包的人
- 对仓库保密要求极高、又不能等私有仓库功能的人
- 希望一键生成完就完全不用人工核对的人
这东西最怕的就是被当成“自动权威文档”。它不是权威，它是一个高质量起点。
怎么看它真正的潜力
Google 做 Code Wiki，方向其实挺清楚：不是继续卷“AI 帮你写”，而是往“AI 帮你理解”再走一步。
这个方向比单纯代码生成更稳。因为绝大多数团队真正卡住的地方，根本不是“没有人会写代码”，而是：
- 新人看不懂
- 老人记不全
- 文档总过期
- 复杂仓库没人愿意碰
如果一个系统能把这些理解成本压下来，它的价值可能比再多一个代码补全工具更大。
最后说句实在的
Code Wiki 不是让你少读代码，而是让你先把代码读对。
它真正厉害的地方，不是把仓库说得多花哨，而是把那些本来很难维护的知识，重新变成了和代码一起生长的东西。对开源项目、复杂工程、老代码库来说，这种“活文档”比静态说明书更接近真实需求。
如果说过去的 AI 工具是在帮你写代码，那 Code Wiki 这类东西，开始帮你把代码这件事讲明白了。