快速摘要
Google 于 2025 年 11 月正式推出 Code Wiki（官网：codewiki.google），这是一款基于 Gemini 大模型的 AI 代码文档自动生成平台。它的核心能力是：输入任意公开 GitHub 仓库地址，几秒钟内即可生成一份结构化的、可交互的"活文档"——包含架构图、类图、时序图、模块说明以及 AI 问答。更关键的是，每当仓库有新的 Commit 提交，Code Wiki 会自动重新扫描并更新文档，从根本上解决了"代码迭代十几版、文档还停在半年前"这一行业顽疾。目前该工具完全免费开放，支持所有公开 GitHub 仓库，私有仓库支持正通过 Gemini CLI 扩展逐步推进。 往下看，莫潇羽@无忆研习社 将为你做更详细的原理拆解、操作实战和场景分析。
一、从一个行业痛点说起：代码理解为何如此困难
在软件开发领域，有一个被反复验证的经验法则：开发者大约 70% 的工作时间，实际上是花在阅读和理解已有的代码上，而不是编写新代码。这个数字在大型项目和遗留系统中可能还要更高。想象一下，一个有着数百个文件、数万行代码的项目，新成员加入后第一件事不是动手写功能，而是需要花好几天甚至几周时间，去搞清楚现有代码的架构、模块之间的调用关系、数据流转路径。
这个问题在当下的"Vibe Coding"（氛围编程）浪潮中变得更加尖锐。Vibe Coding 是由 OpenAI 联合创始人 Andrej Karpathy 在 2025 年初提出的概念，核心理念是开发者用自然语言描述需求，AI 自动生成代码，开发者主要扮演引导者和审查者的角色。这种模式极大地加速了代码产出——过去需要几天完成的原型，现在几小时就能搞定。但问题也随之暴露：AI 生成代码的速度远远超过了人类理解代码的速度。
代码在飞速迭代，但配套的文档呢？这里面存在一个几乎所有开发团队都遭遇过的恶性循环。
项目初期，团队可能会认真写一份架构说明和接口文档。但随着需求变更、功能迭代、人员流动，文档维护的优先级越来越低。代码已经更新了十几个版本，文档却还停留在半年前的状态。新人照着过时的文档去配置环境或理解逻辑，十次有九次要踩坑。久而久之，大家干脆不看文档了，直接啃代码。这就是软件工程中臭名昭著的"文档腐化"问题。
莫潇羽在 无忆研习社（www.wuyi.wiki）长期关注开发者工具生态，深知这个痛点有多普遍。在和众多开发者交流的过程中，几乎每个人都有过"接手一个完全没有文档的老项目，对着一堆意义不明的函数名抓狂"的经历。传统的解决方案——比如 JSDoc、Sphinx、pydoc 等文档生成工具——虽然能从代码注释中提取 API 参考，但它们生成的只是接口级别的说明，无法解释系统整体架构、模块之间的协作关系，更无法回答"这段代码为什么这么写"之类的高层问题。而且，这些工具同样依赖人工维护注释，注释不更新，文档照样失效。
面对这个顽固的行业痛点，Google 在 2025 年 11 月正式发布了 Code Wiki，试图从根本上改变"文档总是滞后于代码"这一现状。
二、Code Wiki 是什么：一句话概括它的本质
Code Wiki 的官方定位是：一个由 AI 驱动的、持续更新的代码仓库结构化文档平台。
但如果要用更通俗的方式来理解，可以把它想象成一个"长在代码仓库里的活体知识库"。它不是一份写好就放在那里等着发霉的静态文档，而是一个有呼吸的、会跟随代码变化而自动进化的动态系统。
具体来说，Code Wiki 做了以下这些事情：
- 自动扫描整个代码仓库，理解项目的结构、模块、函数、类之间的关系
- 基于理解生成结构化的文档说明，包括项目概述、模块功能解释、API 参考等
- 自动绘制架构图、类图、时序图等可视化图表
- 提供 Gemini 驱动的 AI 问答功能，可以针对代码库直接用自然语言提问
- 每次代码提交后自动重新生成文档，保证文档与代码的强一致性
- 所有文档内容都带有精确的代码引用链接，点击即可跳转到对应的源文件和行号
这个工具的访问地址是 codewiki.google，目前处于公开预览阶段，完全免费，支持所有 GitHub 公开仓库。
值得一提的是，Code Wiki 的前身实际上是一个名为"Auto Wiki"的产品，早在 2024 年 1 月就曾发布过早期版本。后来该团队加入 Google，在 Gemini 模型的加持下进行了彻底重建，最终以 Code Wiki 的名字正式亮相。据团队成员在 Hacker News 上的透露，NotebookLM 的集成也是其作为 Google 产品的一个独特优势。
三、深入原理：Code Wiki 是怎么"读懂"代码的
很多人第一次看到 Code Wiki 的效果时，可能会觉得"这也太神奇了"。但深入了解它的技术原理后会发现，这背后是一套经过精心设计的多层处理架构。莫潇羽@无忆研习社在研究了多方技术资料后，将其核心机制梳理为以下三个层次。
3.1 第一层：基于 Tree-sitter 的结构化解析
Code Wiki 理解代码的第一步，不是把代码当作普通文本来处理，而是利用 Tree-sitter 这一增量解析库，对源码进行语法树（AST）级别的分析。
Tree-sitter 是什么？它是一个开源的、支持多种编程语言的解析器生成工具，最初由 GitHub 为 Atom 编辑器开发，于 2018 年首次发布。它能够将源代码解析为具体语法树（CST），精确地识别出代码中的每一个类、函数、方法、变量、导入语句和依赖关系。目前，Neovim、Zed、Helix 等主流编辑器都已集成 Tree-sitter，GitHub 自身也使用 Tree-sitter 来支持浏览器内的符号导航功能。
Tree-sitter 的关键优势在于：它不是简单地做文本匹配或正则表达式分析，而是真正"看懂"了代码的语法结构。比如，它能准确区分一个名为 process 的函数是在被定义还是在被调用，能识别出一个类继承了哪个父类，能追踪一个变量在哪里被声明、在哪里被修改。这种结构化的理解为后续的深度分析奠定了基础。
这里需要科普一下 AST（抽象语法树）和 CST（具体语法树）的区别，这有助于理解 Code Wiki 为什么选择 Tree-sitter。AST 更关注代码的语义含义，会省略掉括号、分号等纯语法符号；而 CST（也就是 Tree-sitter 生成的）保留了源代码的所有细节，包括每个符号的精确位置。对于 Code Wiki 这种需要将文档精确链接到代码具体行号的工具来说，CST 提供的位置信息至关重要。这也是业界的一个共识：在构建代码理解工具时，AST 适合做编译和静态分析，Tree-sitter 则更适合做代码导航、检索和 AI 代码理解等场景。
此外，Tree-sitter 还有一个重要特性是增量解析。当代码文件发生修改时，Tree-sitter 不需要重新解析整个文件，而是只解析变更的部分，然后更新已有的语法树。这使得它在处理大型代码文件时效率非常高，也是 Code Wiki 能够实现快速文档更新的技术基础之一。
用一个简单的例子来说明。假设有这样一段 Python 代码：
class UserService:
def __init__(self, db_connection):
self.db = db_connection
def get_user(self, user_id):
return self.db.query("SELECT * FROM users WHERE id = ?", user_id)
def create_user(self, name, email):
self.db.execute("INSERT INTO users (name, email) VALUES (?, ?)", name, email)Tree-sitter 会将这段代码解析为一棵语法树，精确地标识出：这里有一个名为 UserService 的类，它有三个方法（__init__、get_user、create_user），构造函数接收一个 db_connection 参数，get_user 方法通过 self.db.query 执行数据库查询操作，等等。每一个标识符都有明确的类型、位置和上下文关系。
3.2 第二层：代码知识图谱的构建
拿到了 Tree-sitter 解析出的结构化数据后，Code Wiki 的下一步是将这些代码组件转换为一个知识图谱。
在这个图谱中，函数、类、模块、服务等代码实体作为节点存在，而它们之间的调用关系、继承关系、依赖关系、数据流转等则作为边来连接。这样就形成了一张完整的"代码地图"，能够清晰地展现出代码库各部分之间的关联和上下文。
举个例子来帮助理解。在一个典型的 Web 应用中，知识图谱可能长这样：
[路由层 Router]
├── 调用 → [控制器 UserController]
│ ├── 调用 → [服务层 UserService]
│ │ ├── 调用 → [数据库 UserRepository]
│ │ └── 依赖 → [缓存 CacheManager]
│ └── 调用 → [服务层 AuthService]
│ └── 依赖 → [JWT 工具库]
└── 调用 → [控制器 OrderController]
└── 调用 → [服务层 OrderService]
├── 调用 → [数据库 OrderRepository]
└── 调用 → [服务层 UserService] (跨模块依赖)这种图结构的技术并不新鲜——Neo4j、Memgraph 等图数据库在企业级应用中已经有成熟的实践。但 Code Wiki 的创新在于，它将图数据库的思路应用到了代码理解这个特定场景中，并且实现了自动化的图谱构建和持续更新。
为什么要构建知识图谱而不是简单地存储代码文本？这是因为软件系统的复杂性主要体现在组件之间的关系上，而不是单个组件本身。一个函数的代码可能只有十几行，但它调用了哪些其他函数、被哪些模块依赖、在什么条件下被触发——这些关系信息才是理解系统行为的关键。传统的全文搜索只能帮你找到函数的定义位置，但知识图谱能告诉你这个函数在整个系统中扮演的角色。
在实际的知识图谱中，节点和边通常还会携带丰富的元数据。比如一个函数节点可能包含：函数名、所在文件路径、行号范围、参数列表、返回值类型、访问修饰符（public/private）等信息。而一条"调用"边可能包含：调用发生的位置、调用频率（静态分析估计）、是同步调用还是异步调用等信息。这些元数据使得后续的检索和文档生成更加精确。
3.3 第三层：代理式 RAG 混合检索
这是整个系统中最核心也最精妙的部分。当用户通过 Code Wiki 的聊天功能提问时，系统需要从海量的代码信息中快速找到最相关的答案。Code Wiki 采用了一种被称为"代理式 RAG"（Agentic RAG）的混合检索策略。
传统的 RAG（Retrieval-Augmented Generation，检索增强生成）通常只做语义向量搜索——把问题转换成向量，然后在向量数据库中找到语义最相似的文本片段。但 Code Wiki 的做法更加智能：它会根据问题的类型，动态选择不同的检索路径。
当问题偏向概念理解时，系统会使用语义检索。比如用户问"用户认证是怎么实现的"，系统会通过语义相似度搜索，找到与"认证""登录""鉴权"等概念相关的代码模块和文档段落。
当问题偏向结构关系时，系统会切换到图谱遍历模式。比如用户问"哪些服务依赖了用户数据库"，系统会在知识图谱中从"用户数据库"这个节点出发，沿着依赖关系的边进行遍历，找到所有直接或间接依赖它的服务模块。
这种根据问题类型动态选择检索策略的方式，比单一的语义搜索要精准得多，也是 Code Wiki 能够给出高质量回答的关键所在。
为了让大家更直观地理解这两种检索方式的差异，莫潇羽@无忆研习社 这里用一个生活中的类比来说明。假设你要在一个大型图书馆中寻找信息：
语义检索就像是你告诉图书管理员"我想了解关于人工智能伦理的内容"，管理员根据你的描述，找到了几本在内容上与"AI 伦理"主题最相关的书。这种检索擅长处理模糊的、概念性的查询。
图谱遍历则像是你问"《深度学习》这本书引用了哪些参考文献，而那些参考文献又被哪些其他书引用了"——这需要沿着"引用关系"这条线索一步步追踪，而不是根据内容的相似度来搜索。这种检索擅长处理精确的、关系型的查询。
Code Wiki 的 RAG 代理会根据问题的语义特征自动判断使用哪种策略，有时甚至会结合两种策略的结果来给出更全面的回答。比如，当用户问"缓存失效时系统的降级策略是什么"时，系统可能先通过语义检索找到与"缓存""降级"相关的代码模块，再通过图谱遍历追踪这些模块的调用链路，最终拼合出一个完整的回答。
3.4 Gemini 模型的角色：长上下文的核心优势
以上三层架构的运转，都离不开 Google Gemini 模型的支撑。Gemini 在整个流程中扮演了多重角色：
在文档生成阶段，Gemini 负责将 Tree-sitter 解析出的结构化代码信息"翻译"成流畅、准确的自然语言描述。它不是简单地把函数签名转成文字，而是能够总结出一个模块在整个系统中的角色和作用。
在问答交互阶段，Gemini 基于 RAG 检索到的上下文，生成有针对性的回答，并附上代码引用。
在可视化阶段，Gemini 分析代码的逻辑结构，生成对应的架构图、类图、时序图的描述数据，再由前端渲染引擎绘制出来。
Gemini 模型的长上下文窗口（支持高达百万级别的 token）在这里发挥了关键作用。对于大型代码仓库，传统的 AI 模型可能无法一次性"看到"足够多的代码上下文，导致生成的文档缺乏连贯性和全局视角。而 Gemini 的超长上下文能力使得它可以同时处理整个项目的代码结构信息，从而生成更加准确和全面的文档。
四、核心功能详解：Code Wiki 能帮你做什么
了解了底层原理之后，让我们从使用者的角度，逐一拆解 Code Wiki 的核心功能。这里莫潇羽@无忆研习社力求把每个功能点都讲透，帮助初次接触的朋友快速上手。
4.1 自动生成的结构化文档
输入一个 GitHub 仓库地址后，Code Wiki 会在几秒到几分钟内（取决于仓库大小）生成一份完整的结构化文档。这份文档通常包含以下几个部分：
项目概述：用简洁的语言概括这个项目是做什么的，解决了什么问题，采用了什么技术栈。这对于第一次接触项目的人来说非常友好，相当于一份即时可用的"项目简介"。
模块结构说明：将项目按照功能模块进行拆分，分别说明每个模块的职责、包含的主要文件、对外提供的接口等。这比直接看文件目录结构要清晰得多，因为 Code Wiki 不只是列出文件名，还解释了每个模块在系统中的角色。
API 参考文档：对于项目中的公共接口、函数、类，Code Wiki 会生成详细的参数说明、返回值类型、使用示例等。这部分和传统的 API 文档生成工具类似，但优势在于它是自动生成且持续更新的。
依赖关系说明：列出项目的外部依赖库、内部模块间的依赖关系，帮助开发者快速理解"如果我修改了 A 模块，可能会影响到哪些地方"。
文档中的每一段描述都附带了精确的代码引用链接。这意味着当你读到某个模块的功能说明时，可以直接点击链接跳转到对应的代码文件和具体行号去查看实现细节。这种"文档—代码"双向链接的设计，极大地提升了阅读效率。
4.2 代码可视化：架构图、类图、时序图
这是 Code Wiki 最让人眼前一亮的功能之一。
对于复杂的系统架构，光靠文字描述往往很难建立直观的认知。Code Wiki 能够直接从代码逻辑中提取结构信息，自动渲染出多种类型的可视化图表：
架构图：展示整个系统的全景视图，包括各个子系统、模块之间的关系和数据流转路径。这对于理解大型项目的整体设计非常有帮助。
类图：展示类与类之间的继承关系、组合关系、关联关系。对于面向对象的项目，类图是理解代码组织方式的最佳工具。
时序图：展示一个典型操作流程中，各个组件之间的交互顺序。比如"用户登录"这个场景，时序图可以清晰地展示从前端发起请求到数据库验证再到返回响应的完整流程。
依赖关系图：以图形化的方式展示模块间的依赖关系，帮助识别潜在的循环依赖或过度耦合问题。
这些图表不是一次生成后就固定不变的静态图片，而是会随着代码的变更自动重新生成。这意味着无论什么时候查看，看到的都是反映代码当前状态的最新图表。对于代码审查、重构规划、新人上手等场景，这种实时更新的可视化能力价值极高。
4.3 AI 驱动的代码问答
Code Wiki 的交互方式不仅仅是"翻阅文档"，更支持"对话式"的代码探索。
在页面的侧边栏，有一个 Gemini 驱动的 AI 聊天窗口。你可以用自然语言针对当前代码库提出任何问题，比如：
- "这个项目的核心入口点在哪里？"
- "用户认证的完整流程是怎样的？"
- "如何在本地环境部署运行这个项目？"
- "哪些函数调用了数据库写入操作？"
- "如果我想添加一个新的 API 端点，需要修改哪些文件？"
Code Wiki 的 AI 助手会基于最新的代码库内容给出回答，而不是依赖通用训练数据进行泛泛而谈。更重要的是，它的每一个回答都会附带精确的代码引用——引用了哪个文件的哪一行，点击即可跳转查看。这种"有据可查"的特性在很大程度上缓解了我们对 AI 幻觉（Hallucination）的担忧。
需要特别注意的是，Code Wiki 擅长回答"是什么"（What）和"怎么实现的"（How）类型的问题，但对于"为什么这么设计"（Why）这类涉及架构决策背景的问题，它的回答能力相对有限。因为设计决策通常涉及当时的业务背景、团队讨论、技术选型考量等信息，这些并不会体现在代码本身中。这也是 Code Wiki 的团队在官方文档中坦诚提到的局限性之一。
4.4 持续同步：文档永不过时
这是 Code Wiki 相对于其他文档工具最核心的差异化优势。
传统的文档系统——无论是手写的 Markdown 文件、Wiki 页面，还是自动生成的 API 文档——都面临同一个问题：生成之后，如果不持续人工维护，它们就会逐渐与实际代码脱节。Code Wiki 彻底翻转了这个模式：它让文档成为代码的一个"视图"（View），而不是一个独立维护的"副本"（Copy）。
每当仓库有新的 Commit 提交，Code Wiki 就会重新扫描代码变更，利用 Gemini 模型重新分析受影响的模块，并自动更新对应的文档说明和图表。文档和代码之间不存在"需要手动同步"的环节，因为文档本身就是从代码实时生成的。文档不可能过时，因为它不可能脱离代码而独立存在。
这种设计理念可以类比为：传统文档是"照片"，拍完就定格了；Code Wiki 的文档是"实时监控画面"，代码变了，画面就跟着变。
五、上手实战：从零开始使用 Code Wiki
说了这么多原理和功能，接下来莫潇羽@无忆研习社带大家实际操作一遍。Code Wiki 的使用门槛极低，整个过程不需要安装任何软件，不需要注册账号（登录 Google 账号可获得更好的体验），直接在浏览器中操作即可。
5.1 访问 Code Wiki 官网
打开浏览器，在地址栏输入：
https://codewiki.google进入后，你会看到一个非常简洁的界面，核心就是一个输入框，提示你输入 GitHub 仓库地址。
页面上还会展示一些热门的示例仓库，比如 React、Next.js、TensorFlow 等知名开源项目——这些项目已经有预生成的文档，可以直接点击查看。
5.2 输入仓库地址并生成文档
在输入框中粘贴你想要分析的 GitHub 仓库地址。比如你想了解一个名为 OpenClaw 的开源项目，就输入它的 GitHub URL。
点击确认后，Code Wiki 会开始处理。对于中小型仓库（几千到几万行代码），通常在几秒到一两分钟内就能生成结果。对于特别大的仓库，可能需要稍长一些的时间。
生成完成后，你会看到一份完整的项目文档页面，左侧是导航栏，列出了文档的目录结构；主区域显示具体内容；右侧是 AI 聊天窗口。
5.3 浏览文档和可视化图表
在文档页面中，你可以像浏览维基百科一样，通过目录导航来查看不同模块的说明。每个模块的文档页面通常包含：
- 模块功能的自然语言描述
- 包含的主要类和函数列表
- 与其他模块的依赖关系
- 相关的代码引用链接
切换到"Diagrams"（图表）标签页，可以查看自动生成的各类可视化图表。你可以在架构图、类图、时序图等不同视图之间切换，从不同维度理解项目的结构。
图表通常支持缩放和平移操作，对于大型项目，你可以放大查看某个局部区域的细节，也可以缩小来获取全局视图。
以架构图为例，它通常会将项目中的各个模块按照层次结构排列：最上层是入口点和路由层，中间是业务逻辑层和服务层，底层是数据访问层和外部依赖。模块之间的调用关系用带箭头的连线表示，一目了然。如果某两个模块之间的连线特别多或特别粗，说明它们之间的耦合度较高——这本身就是一个有价值的信息，可以为后续的架构优化提供参考。
类图则更偏向于展示面向对象设计的细节。你可以看到各个类的属性和方法、类之间的继承关系（实线箭头）、实现关系（虚线箭头）、组合关系等。对于使用了设计模式（如工厂模式、观察者模式、策略模式等）的项目，类图能够清晰地展现出设计模式的结构。
时序图则是另一个非常实用的可视化类型。它展示了一个特定操作流程中各个参与方之间的消息传递顺序。比如"用户下单"这个流程的时序图，可能会展示：前端 → API 网关 → 订单服务 → 库存服务（检查库存）→ 支付服务（扣款）→ 订单服务（更新状态）→ 通知服务（发送确认邮件）这样的交互时序。对于理解复杂的业务流程，时序图的价值不可替代。
5.4 使用 AI 问答功能
在右侧的聊天窗口中，直接输入你的问题即可。一些实用的提问技巧：
从宏观到微观：先问整体性的问题（"这个项目的核心架构是什么"），再逐步深入到具体模块（"认证模块的工作流程是怎样的"），最后聚焦到特定代码（"这个函数的参数含义是什么"）。
场景化提问：比如"如果我要在本地 Mac 电脑上部署运行这个项目，需要哪些步骤"——这种贴近实际使用场景的问题，Code Wiki 通常能给出非常详尽的步骤指引。
关系类提问：比如"哪些模块依赖了 Redis 缓存"或者"如果我修改了 User 模型的字段，会影响哪些接口"——这类涉及代码关系的问题，正好发挥了 Code Wiki 知识图谱的优势。
每次 AI 给出回答后，仔细查看回答中附带的代码引用链接。点击这些链接可以直接跳转到对应的源代码位置，方便你验证 AI 的回答是否准确。养成"查看引用"的习惯，是使用 AI 文档工具的一个好做法。
5.5 实战示例：分析一个开源项目
为了让大家有更具体的感受，这里以分析一个典型的 Web 项目为例，展示完整的使用流程。
假设你想了解一个基于 Python 的 Web 框架项目。你把它的 GitHub 地址粘贴到 Code Wiki，几秒后文档生成完毕。
首先看项目概述：Code Wiki 告诉你这是一个基于 FastAPI 的 RESTful 服务，提供了用户管理、权限控制、数据查询等功能，使用 PostgreSQL 作为主数据库，Redis 作为缓存层。
然后看架构图：一张清晰的系统全景图出现在眼前，你可以看到 API 路由层、业务逻辑层、数据访问层、外部服务集成层之间的关系。
点进"用户管理"模块的文档页面，你会看到这个模块包含的所有类和函数，每个函数的功能说明，以及该模块与权限控制模块、数据库层之间的交互关系。
如果你对某个细节有疑问，比如"用户注册时的密码加密方式是什么"，直接在聊天窗口提问，AI 会告诉你项目使用了 bcrypt 算法进行密码哈希，并给出对应的代码位置引用。
整个过程下来，你可能只花了十几分钟，就对一个从未接触过的项目建立了相当全面的理解。这在以前，可能需要大半天甚至几天的时间。
六、实际应用场景：谁最需要 Code Wiki
了解了 Code Wiki 的功能和用法之后，让我们来看看它在实际工作中有哪些典型的应用场景。这也是莫潇羽@无忆研习社在日常技术工作中总结出的几个高频使用场景。
6.1 新人快速上手（Onboarding 加速）
一个新的开发者加入团队后，通常需要经历一个漫长的"上手期"。传统的做法是：读文档（如果有的话）→ 读代码 → 问同事 → 再读代码 → 试着改点小东西 → 踩坑 → 问同事……这个循环可能持续一两周。
有了 Code Wiki，新人可以先花半小时浏览自动生成的项目文档和架构图，对系统建立整体认知。然后针对自己即将负责的模块，通过 AI 问答深入了解细节。遇到不明白的地方，随时提问就行。据 Google 官方的描述，目标是让新的贡献者能够在加入的第一天就开始提交代码。虽然实际效果因项目而异，但上手时间的显著缩短是可以期待的。
6.2 遗留系统的理解与维护
很多团队都面临着维护"历史遗留系统"的挑战。这些系统可能是几年前甚至十几年前开发的，原始开发者早已离开，文档几乎为零，代码注释寥寥无几。每次需要修改或扩展功能时，都像是在拆一颗不知道线路图的炸弹。
Code Wiki 在这个场景下的价值尤为突出。即使面对一个完全陌生的、没有任何文档的老旧项目，它也能快速生成结构化文档和可视化图表，帮助开发者建立起对系统的基本认知。这至少解决了"不知道从哪里开始看起"的问题。
6.3 代码审查与重构规划
在进行代码审查（Code Review）时，审查者需要理解被修改代码在系统中的位置和影响范围。Code Wiki 的依赖关系图和模块说明可以提供这种上下文信息，帮助审查者更高效地评估代码变更的风险。
在规划系统重构时，准确理解当前的架构和模块间的依赖关系是第一步。Code Wiki 自动生成的架构图和依赖关系图，正好为重构方案的制定提供了可靠的参考。如果 Code Wiki 生成的架构图看起来一团乱麻、
