最近 Qoder 推出了 Repo Wiki 功能，能自动解析代码仓库，生成结构化的知识文档，还能持续跟踪代码变更增量更新。很多同行说：这不就够了吗？为什么还要自己做知识归档插件？
这个问题我也想了很久。答案是：它们解决的是不同的问题。
两种知识库，两种思路
Qoder 的 Repo Wiki 解决的是：让 AI 更懂你的代码。
它生成架构概览、API 文档、数据流图，构建 Code Graph、Commit Graph，让 AI 在对话时能立体地理解项目。本质上，这些知识是给 AI 用的上下文——让 AI 回答代码问题时更准确。
我做的 Knowledge Archiver 解决的是：让人更懂你的业务。
它生成的文档不是给 AI 看的，是给人看的——新入职的同事、跨部门的产品经理、需要排查问题的运维人员。
这两个需求不冲突，但侧重点完全不同。
一个真实场景
假设你的项目里有一个"工单管理"模块。
Qoder Repo Wiki 会告诉你：
- WoHdrService 是工单头表的服务类
- 它依赖 WoHdrDao 访问数据库
- 调用链路是 Controller → Service → DAO
- 模块依赖关系图
这些信息对 AI 回答"工单模块的代码结构是什么"非常有用。
但产品经理问的是：
- 工单的完整业务流程是什么？从创建到完成经过哪些步骤？
- 审批规则是什么？什么情况下需要二次审批？
- 工单变更会影响哪些下游环节？
新人问的是：
- 我第一天上班，这个模块我应该先了解什么？
- 测试验收标准是什么？哪些边界条件容易出问题？
- 运维需要关注哪些日志和监控指标？
销售问的是：
- 这个模块的核心价值是什么？
- 和客户之前用的系统比，优势在哪里？
这些问题，Repo Wiki 回答不了。不是因为它不好，而是因为它的设计目标就不是回答这些问题。
多视角文档：一份文档服务所有角色
这就是为什么我在插件里设计了 7 个视角的文档结构：
| 视角 | 核心关注 | 谁最关心 |
|---|---|---|
| 开发视角 | 业务流程、状态机、核心实现 | 开发者 |
| 测试视角 | 验收标准、边界场景 | 测试人员 |
| 运维视角 | 日志监控、常见故障 | 运维人员 |
| 实施视角 | 配置项、接口协议 | 实施人员 |
| 产品视角 | 需求背景、业务痛点 | 产品经理 |
| 客户视角 | 操作流程、功能入口 | 客户/用户 |
| 销售视角 | 价值主张、核心优势 | 销售 |
AI 能从代码推导的（开发/测试/运维/实施），自动填充。推导不了的（产品/客户/销售），留 TODO 供人工补充。
一份文档，七种角色各取所需。 这不是 Repo Wiki 要做的事——因为后四个视角和代码结构无关，AI 从代码里推导不出来。
知识的质量门控
另一个关键差异：知识不是生成出来就完了，还需要确保质量。
AI 生成的内容无法保证 100% 准确。它可能误解代码意图，可能生成"可能""或许"这样的推测性内容，可能遗漏关键边界条件。
如果这些内容直接变成"正式知识"，后续所有基于它的操作——新人学习、跨部门沟通、业务决策——都可能被误导。
所以我的插件设计了两阶段流程：
AI 生成草稿 → 人工审核 → 升格为正式文档
这不是多余的步骤。这是质量保障。
就像代码 review 一样——你可以让 AI 写代码，但提交前必须有人 review。知识也一样。
文件即记忆，而不是 AI 的记忆
Qoder 的知识库存在 .qoder/repowiki/ 目录里，虽然也是文件，但它的结构和格式是为 Qoder 服务的。
我的插件把知识存在 docs/core/ 目录里——这是项目的正式文档目录，不是插件的内部数据。
这意味着：
- 不绑定任何 IDE。换 IDE、换 AI 工具，文档依然在
- 可以被 Git 版本控制。追踪知识的演进历史，谁改了什么一目了然
- 人可以直接编辑。不需要打开任何特殊工具，任何 Markdown 编辑器都行
- 团队可以 review。知识文档的变更可以像代码一样走 PR 流程
知识不应该被锁在某个工具的内部。 它是团队的资产，应该属于项目本身。
不是替代，是互补
说到底，Qoder Repo Wiki 和我的插件不是竞争关系，是互补关系：
Repo Wiki → 让 AI 更懂代码 → 服务 AI
Knowledge Archiver → 让人更懂业务 → 服务团队
一个项目里同时有两种知识库，完全不冲突：
- AI 需要理解代码时，查 Repo Wiki
- 人需要理解业务时，查 Knowledge Archiver 生成的文档
- 新人入职时，先看多视角文档了解全貌，再用 AI 对话深入细节
代码知识库不是只有一个正确答案的问题。 不同层次的知识需求，需要不同的工具来满足。
最后
代码知识库这个赛道正在变得越来越热闹。Qoder、Sourcegraph、各种 RAG 方案都在做。但大多数方案都在解决同一个问题——让 AI 更懂代码。
很少有人在意：让人更懂业务。
这就是我做这个插件的原因。
