1. 从重复检索到知识沉淀
现在大家提到 LLM 和文档，第一反应通常还是 RAG：把一批文件放进去，提问时检索相关的数据块（chunk），再让模型根据这些内容生成回答。
这种方式有用，但最基础的 RAG 更像是“每次都重新查资料”。模型上一次已经读过什么、做过哪些归纳、发现过哪些矛盾，通常不会自动沉淀下来。下次问到类似问题，它还得重新检索、重新理解、重新组织。
Karpathy 提出的 LLM Wiki，想法其实很直接：在原始资料和 Agent 之间，加一层由 LLM 持续维护的 Wiki。
这层 Wiki 不是简单存放原文，也不是把检索结果缓存下来。它更像是已经整理过的项目知识：
- 新资料进来后，LLM 会把关键信息合并到已有页面；
- 同一个概念出现在多个来源中，会被串到一起；
- 新旧资料说法不一致时，会把冲突标出来；
- 已有结论可以被新证据补充、修正，甚至推翻；
- Agent 下次工作时先读整理后的 Wiki，遇到关键细节再回到源码或原始资料核实。
不过，这里有一个很重要的边界：
原始代码、PRD、MR、技术方案和事故记录才是事实来源；Wiki 是根据这些来源整理出来的知识，不应该反过来替代事实来源。
所以，LLM Wiki 更准确的说法不是“让 AI 替我们写文档”，而是：
让 AI 帮我们持续整理项目知识，同时保留来源、审核和回溯能力。
2. 整体架构
一个比较完整的 LLM Wiki，可以分成三层。
事实来源
代码 / MR / PRD / 技术方案 / 事故记录 / 讨论结论
↓
读取、提取、关联、综合
↓
派生 Wiki
模块说明 / 核心流程 / 技术决策 / FAQ / 历史变化
↓
Agent 使用规则
AGENTS.md / Skills / index.md / 查询工具2.1 事实来源
事实来源尽量保持原样，不由 LLM 随意改写。
对我们来说，常见来源包括：
- Android 代码仓库；
- GitLab MR 和提交记录；
- PRD、技术方案和评审结论；
- AB 实验配置和上下线记录；
- 线上事故、排障记录和复盘；
- 模块负责人补充的业务背景。
不同来源发生冲突时，需要提前约定优先级。例如当前代码可以说明“现在怎么实现”，但不一定能说明“产品为什么这么设计”；PRD 可以说明原始目标，但也可能已经被后续方案调整。
2.2 Wiki
Wiki 保存的是整理后的知识。页面不一定都按代码目录组织，也可以按 Feature、流程、决策或者常见问题组织。
每个页面最好带上这些信息：
- 来源链接或源码路径；
- 对应的 commit、MR 或文档版本；
- 最后生成和最后人工确认时间；
- 负责人或业务确认人；
- 当前状态，例如有效、可能过期、存在冲突；
- 置信度以及仍然没有确认的问题。
有了这些信息，Agent 才知道哪些内容可以直接参考，哪些内容必须回到源码核实。
2.3 Agent 使用规则
只有 Wiki 还不够，还需要告诉 Agent 什么时候读、先读什么、什么时候回源。
例如：
收到地图相关需求
↓
先读取 Feature 索引
↓
读取地图主页面和对应玩法页面
↓
根据任务继续读取状态、约见或匿名冒泡页面
↓
涉及具体实现和当前行为时回到源码确认这也是 LLM Wiki 和普通团队文档的一个区别：它不仅给人看，还要真正进入 Agent 的工作流程。
3. index.md 和 log.md
Wiki 内容多起来之后，至少需要两个特殊文件。
3.1 index.md
index.md 面向内容，告诉人和 Agent“这里有什么”。
它不只是文件列表，最好还包括：
- 页面链接；
- 一句话摘要；
- 所属模块或知识类型；
- 主要来源；
- 最后更新时间；
- 当前是否可能过期。
Agent 先读索引，再按任务逐步打开相关页面。规模不大、页面结构清楚时，未必一开始就需要 Embedding 或向量数据库。
不过，是否需要 RAG 不应该只按“多少个页面”判断。页面总 token、索引质量、查询复杂度和跨页面关联数量都会影响效果。最稳妥的做法是拿真实问题做评测，而不是先定一个固定的页面数门槛。
3.2 log.md
log.md 面向时间，记录 Wiki 发生过什么变化，例如：
- 摄取了哪个 MR 或 PRD；
- 更新了哪些页面；
- 哪些说法发生冲突；
- 哪些内容经过人工确认；
- 执行过哪些 Lint 或一致性检查；
- 某次更新为什么失败。
log.md 可以只追加，作为操作时间线。但它不能替代 Git 历史和页面自己的来源信息。真正需要追责或回滚时，还是要能找到对应的 commit、MR 和原始来源。
4. Wiki 维护的真正难点
以前维护 Wiki 最麻烦的，往往不是写第一版，而是后面的琐碎工作：
- 代码改了，忘了同步页面；
- 类名和路径变了，文档还在引用旧名字；
- 一个变化影响了好几个 Feature，只更新了其中一处；
- 新同学看到了 Wiki，却不知道它是不是还有效；
- 同一个结论散落在多个页面里，慢慢变成不同版本。
LLM 比较适合处理这些批量、重复、需要跨文件检查的工作。它可以一次分析代码差异，找到可能受影响的页面，更新摘要和链接，再生成一个可审核的变更。
但这不等于“交给 LLM 就不会出错”。LLM 也可能漏掉关联、误解业务规则，或者把自己的推断写成确定事实。所以，真正可行的模式应该是：
LLM 负责大部分整理和维护
人负责来源选择、规则设计、冲突裁决和关键结论审核
工具负责检查格式、引用、时效和变更记录人的工作从“手工维护每一段文字”转向“管理知识的质量和边界”。
5. 目前客户端的Wiki
我们目前在 cursor_android/wiki 中做过一套很接近的工作。
大致流程是：
每个人选择自己熟悉的 Feature
↓
告诉 Cursor 模块名称、入口类和功能范围
↓
Cursor 扫描代码并生成 Wiki 初稿
↓
负责人根据真实业务和代码进行人工 Review
↓
修正错误、不合理内容和缺失场景
↓
更新 FEATURE_INDEX.md
↓
向 cursor_android Wiki 仓库提交 MR
↓
Review 通过后合并Wiki 按 Feature 组织，而不是简单照着代码目录抄一遍。例如：
- 地图主功能：
feature_nearby_map_v2.md； - 地图状态：
feature_map_state.md； - 地图约见：
feature_map_meetup.md； - 匿名冒泡：
feature_anonymous_bubble.md； - 划卡：
feature_swipe_card.md； - 首页卡片、聊天、商业化等也各有自己的页面。
每篇文档通常包含模块概述、整体架构、核心类、数据模型、常见开发场景、AB 实验、文件索引、注意事项和 FAQ。
这套做法有几个很明显的价值：
-
业务负责人参与了知识整理
Cursor 可以分析代码，但某个判断是不是业务规则、某个分支是不是历史兼容逻辑，还是需要熟悉模块的人确认。
-
Feature 比代码目录更接近真实工作方式
我们平时接到的是“地图约见”“划卡”“AI 助聊”这样的需求，不是“请修改某个 package”。按 Feature 组织，确实更方便需求分析和开发。
-
保留了 MR 审核
AI 生成的内容不会直接变成团队共识，所有修改仍然有 diff、有 Review、可以回退。
-
已经考虑了渐进式加载
Agent 先读
FEATURE_INDEX.md，再根据任务读取相关页面，没必要一次把全部 Wiki 塞进上下文。
所以，我们现在讨论的新方案不能简单说成：
以前是人写 Wiki，现在改成 LLM 写 Wiki。
这个说法并不准确。目前已经是 LLM 生成初稿，人负责 Review。
6. 新旧 Wiki 流程对比
真正的变化主要有五点。
| 维度 | 目前的 Feature Wiki | 持续维护的 LLM Wiki |
|---|---|---|
| 触发方式 | 负责人主动告诉 Cursor 生成或更新 | 代码、MR、PRD 变化后自动触发 |
| 更新方式 | 以整篇文档为主，人工判断哪里需要改 | 根据 diff 找到受影响页面和章节，做增量更新 |
| 知识范围 | 主要来自代码和负责人的经验 | 代码、PRD、MR、技术决策、事故记录等多种来源 |
| 人工角色 | Review 整篇 AI 初稿 | 审核冲突、高风险结论和关键差异 |
| 使用方式 | 人或 Agent 想起来时去查 | 在需求、开发、Review、排障中默认加载 |
6.1 从“个人发起”变成“事件触发”
目前是否生成、什么时候更新，很大程度上取决于负责人有没有想起来。
新的流程应该把触发点放到工程链路里：
MR 创建或更新
↓
分析 diff
↓
识别受影响的 Feature Wiki
↓
判断哪些章节可能过期
↓
生成 Wiki 更新建议或 Bot MR这样，维护不再是需求做完之后“有空再补”的事情。
6.2 从“生成一份快照”变成“持续修订”
目前的 Wiki 很适合回答“这个模块大概怎么实现”。但代码继续变化之后，页面有可能慢慢变成旧版本的快照。
持续维护不一定每次重写全文，更合理的是：
- 新增类时更新核心类和文件索引；
- 调整流程时更新架构图和开发场景；
- 新增实验时更新开关说明；
- 删除功能时同步清理相关页面和交叉引用；
- 只修改内部实现时明确记录“无需更新 Wiki”。
6.3 从“单篇文档正确”变成“整个知识库一致”
目前主要由每个负责人保证自己的页面正确。
新的系统还要检查跨页面关系。例如地图主页面、地图状态、地图约见和我的页状态标签之间存在关联，一个公共数据结构变化可能同时影响几篇文档。
这类跨页面检查正是 LLM 比较适合做、人工又很容易漏掉的地方。
6.4 从“参考资料”变成“Agent 的工作上下文”
目前 Wiki 已经可以在需求、方案和开发阶段按需查阅，但它更像一份参考资料。
如果要真正发挥作用，还需要把使用规则接到每个工作环节：
- 需求分析：先了解当前功能边界和历史限制；
- 技术方案：读取相关架构、数据流和已有开发场景；
- 开发：定位入口、类似实现、AB 和注意事项；
- Code Review：检查修改是否影响其他 Feature、配置和文档；
- 排障：读取常见问题、历史事故和最近变更；
- 新人接手：先读模块地图，再进入源码。
真正的效果不是“Wiki 页面变多了”，而是 Agent 每次工作时更少重复扫描、更少漏掉项目背景。
6.5 人工审核不会消失，只是审核重点会变化
目前人工 Review 主要在检查：
- Cursor 有没有理解错代码；
- 有没有写进不合理的推断；
- 有没有遗漏重要业务场景；
- 生成的文档对实际开发是否有用。
这些事情以后仍然需要。
不同的是，人不必每次重新审核整篇长文，而是重点看：
- 这次变化来自哪个事实来源；
- 为什么影响这些页面；
- 新旧结论是否冲突；
- 哪些内容只是 LLM 推断；
- 是否涉及业务规则、隐私、支付、埋点等高风险内容；
- 自动修改是否应该合并。
7. 业界具体实现
这些产品都和“自动生成或维护知识”有关，但解决的问题并不完全一样。不能只看谁生成的页面更漂亮，还要看它能不能进入我们的开发流程。
7.1 DeepWiki
DeepWiki 是 Cognition 推出的代码仓库理解工具。它会分析仓库，生成模块说明、架构图和源码引用，也可以通过 Ask Devin 对代码提问。
使用方式
如果是公开 GitHub 仓库，最简单的方式就是打开 DeepWiki，输入仓库地址，等待它完成分析。也可以把仓库地址里的 github.com 换成 deepwiki.com 直接访问。生成之后，左边是按主题组织的 Wiki 页面，页面里可以看到架构说明、流程图和源码引用。
阅读过程中遇到不清楚的地方，可以直接使用 Ask Devin 提问。例如：
这个项目的地图页面从哪里进入？
用户位置更新后，经过哪些类才显示到地图上？
如果要增加一种地图玩法，通常需要修改哪些地方？回答会带着源码引用，可以顺着引用继续看代码。对于大型仓库，还可以在仓库根目录添加 .devin/wiki.json，告诉 DeepWiki 哪些目录最重要、希望生成哪些页面，避免它自动规划时漏掉核心模块。
私有仓库需要先在 Devin 中连接代码仓库并完成权限配置，再生成 DeepWiki。我们如果要试，应该先用公开仓库熟悉效果，内部代码要等安全和权限方案确认后再接入。
在我们场景中的应用
DeepWiki 最适合解决“我对这个仓库或者模块还不熟”的问题。
例如：
- 新人第一次接手
NearByMapV2，先看系统自动整理的模块地图； - 开发者临时修改一个不熟悉的商业化模块，先了解入口和主要数据流；
- Review 跨模块 MR 时，用问答快速找到相关代码和调用关系；
- 生成架构概览后，与我们现有 Feature Wiki 做交叉检查，看看漏了哪些模块。
它更像一个开箱即用的“代码阅读助手”，适合快速建立全局认识。
使用边界
它主要根据代码理解系统。代码能说明当前实现，却不一定能说明产品背景、历史决策和一些约定俗成的业务规则。
另外，我们是私有 GitLab 仓库，是否接入还要确认：
- 私有仓库接入方式；
- 代码会发送到哪里；
- 数据保存多久；
- 是否用于模型训练；
- 企业权限和审计能力。
所以 DeepWiki 可以作为代码理解和效果对比工具，但不建议不经过安全评估就把它当成内部知识库的唯一方案。
7.2 AutoWiki
AutoWiki 是 Factory 推出的代码库自动文档系统。它强调一句话：
Documentation should be a build artifact, not a side project.
也就是文档应该像构建产物一样，随着代码变化自动生成，而不是依赖某个人记得维护。
它的流程大致是：
代码 push 到默认分支
↓
CI 触发
↓
分析本次代码差异
↓
增量更新受影响的页面
↓
保存和发布新版本 Wiki使用方式
AutoWiki 集成在 Factory 的 Droid 中。进入一个已经打开代码仓库的 Droid 会话后，可以执行：
/wiki它会扫描当前仓库，规划 Wiki 的页面结构，生成架构、模块、入口、数据流等内容。生成结果可以在 Factory 的 Wiki 页面中浏览，也可以导出为 Markdown；GitHub 仓库还可以同步到仓库自带的 Wiki。
确认第一次生成的结构基本合理后，可以再执行：
/install-wiki这会添加一套 CI 更新流程。以后默认分支发生变化，AutoWiki 会根据上一次记录的 commit 做增量分析，只重新生成受影响的页面。
如果放到我们的环境里，可以把 /wiki 理解成“一次性生成”，把 /install-wiki 理解成“把更新接入持续集成”。不过我们使用 GitLab，而且 Wiki 在另一个仓库，实际试点前还需要验证 GitLab CI 和跨仓库提交怎么处理。
在我们场景中的应用
AutoWiki 和我们当前问题最接近的地方，是“默认分支变化后自动更新”。
如果套到我们的工作里，可以变成：
putong-android 或业务模块代码合并
↓
根据 commit 和 diff 找到相关 Feature
↓
更新地图、划卡、聊天等对应 Wiki
↓
向 cursor_android 仓库创建 Bot MR
↓
模块负责人 Review 后合并这样既能自动维护，又不会丢掉我们目前建立的人工审核机制。
使用边界
我们的 Wiki 和代码不在同一个 Git 仓库，这是落地时最大的区别。
如果工具只会在当前仓库生成文档，我们要么：
- 把生成型 Wiki 放回代码仓库；
- 要么实现跨仓库 Bot MR；
- 要么重新考虑哪些文档应该跟代码放在一起，哪些应该留在共享知识仓库。
此外，“合并到 main 后再生成”虽然能保证文档对应最新代码，但这意味着合并时 Wiki 仍可能是旧的。对高风险变更，也可以考虑在 MR 阶段先生成预览，合并后再做最终同步。
7.3 OpenWiki
OpenWiki 是 LangChain 开源的 Wiki 生成和维护工具。它可以在仓库中生成 openwiki/ Markdown 文档，并在 AGENTS.md、CLAUDE.md 中加入使用提示。
它的使用方式和我们现有流程很接近：
AGENTS.md
↓
告诉 Agent Wiki 在哪里
↓
Agent 先读取 index
↓
根据任务读取相关页面
↓
必要时回到源码它也提供 GitHub Actions 和 GitLab CI 示例，可以手动更新，也可以定期创建文档 PR 或 MR。
使用方式
第一次使用时，在目标代码仓库中运行 OpenWiki，然后按照交互提示选择模型提供方、配置模型。初始化可以使用：
openwiki --init它会读取代码并在当前仓库生成 openwiki/ 目录，同时在 AGENTS.md 和 CLAUDE.md 中加入一小段路由说明，让编码 Agent 知道应该先去哪里找 Wiki。
之后有两种常见用法：
# 进入交互模式，直接询问或要求它整理某个模块
openwiki
# 根据当前仓库变化更新已有 Wiki
openwiki --update如果不希望它自由决定页面结构，可以先维护 openwiki/INSTRUCTIONS.md，写清楚 Wiki 的范围、重点和组织方式。对我们来说，可以在这里要求它按 Feature 组织，并明确国内版、国际版、AB、埋点和业务信息的处理规则。
本地效果确认后，再把官方提供的 GitLab CI 示例接进流水线，让更新通过 MR 展示，而不是直接修改默认分支。
在我们场景中的应用
几种方案里，OpenWiki 和我们当前技术栈的契合度可能最高：
- Wiki 仍然是 Markdown，可以进 Git；
- 可以保留 MR Review；
- 可以接入 GitLab CI；
- 可以通过
AGENTS.md让 Cursor、Codex 或其他 Agent 按需读取； - 开源，方便调整成我们自己的 Feature 结构。
比较合适的试点方式不是直接让它重新生成整个项目，而是先告诉它：
- 我们按 Feature 组织，不按 package 组织；
- 地图下面还有状态、约见、匿名冒泡等子玩法；
- 页面必须区分国内版和国际版；
- 业务规则、AB、埋点等内容不能只根据类名猜测；
- 已有 Wiki 是重要输入，但最终仍要和当前代码核对。
然后选一两个模块，比较它生成的增量结果和人工维护结果。
使用边界
开源不等于数据天然安全。实际使用哪个模型、代码是否发送到外部、密钥如何管理，还是要单独评估。
另外，OpenWiki 能解决“怎么生成和维护”，但不会自动替我们定义一套好的知识结构。Feature 边界、页面模板、来源优先级和 Review 规则仍然需要我们自己设计。
7.4 GBrain
GBrain 更像是给长期运行的 Agent 准备的“外部大脑”，不只是代码文档工具。
它把信息分成三层：
Session Context
当前对话和当前任务中的临时信息
Agent Memory
用户偏好、操作规则、工具配置和任务连续性
GBrain
人物、项目、会议、概念、决策等长期知识它提供 CLI 和 MCP 接口，可以保存页面、事实、来源和时间线，也可以进行检索、综合和后台整理。
使用方式
GBrain 的使用方式和前面几个产品不太一样。它不是先扫描代码生成一套页面，而是先创建一个长期知识库，再不断把资料放进去。
一个最小的本地体验流程是：
# 初始化一个使用本地 PGlite 的知识库
gbrain init --pglite
# 导入已有 Markdown 笔记
gbrain import /path/to/notes
# 搜索相关原始页面
gbrain search "地图约见为什么有前置检查"
# 综合多个来源，生成带引用的回答
gbrain think "地图玩法近几次调整的原因是什么"如果希望 Cursor、Codex 或其他 Agent 在工作时直接查询，可以启动 GBrain 的 MCP 服务，再把它配置到对应 Agent。之后 Agent 不仅能查知识，还能在任务结束后写入新的决策、人物、项目和时间线。
对我们来说，第一次试用不必接邮件和会议。可以只导入一小批脱敏后的技术方案、Wiki 和复盘记录，先观察它能不能正确回答跨文档的“为什么”，以及引用是否可靠。
在我们场景中的应用
GBrain 不太适合直接替代现有代码 Wiki，但可以补足代码 Wiki 最缺的一部分：历史和原因。
例如：
- 地图玩法最初为什么拆成状态、约见和匿名冒泡；
- 某个 AB 实验做过什么结论，为什么后来保留或下线；
- 某段兼容代码对应哪个历史需求；
- 某个模块现在由谁负责；
- 某次线上事故最后确认的根因是什么；
- PRD、技术方案和当前代码之间发生过哪些变化。
代码 Wiki 更擅长回答“现在怎么实现”，GBrain 可以帮助回答“为什么会变成这样”。
使用边界
这类系统接入的信息更广，可能包含会议、人员、邮件和内部决策，因此权限、隐私和数据隔离会比代码 Wiki 更复杂。
它也需要持续运行的摄取、同步和后台任务，运维成本更高。对我们来说，更适合作为第二阶段探索，而不是第一步就全面接入。
7.5 Swimm
Swimm 的重点不是每次重新生成整个 Wiki，而是让文档和具体代码建立联系。
当代码发生变化时，它会检查文档中的类名、路径、变量或代码片段是否还有效。简单变化可以自动同步，复杂变化则提醒开发者处理。
使用方式
Swimm 的起点通常不是“生成整个仓库的百科”，而是先把一篇文档和代码连接起来。
大致流程是：
- 连接 Git 仓库，在 Swimm 中创建文档，或者导入一篇已有文档；
- 从仓库中选中一个类、方法、变量或代码片段，插入为和源码关联的内容；
- 在关联代码旁边补充业务说明、流程和注意事项；
- 接入 CI，让每次 PR 或 MR 都检查这些关联是否仍然有效；
- 代码只是重命名或移动时自动同步，语义发生明显变化时由开发者确认怎么改。
如果拿我们的 Wiki 做演示，可以从 feature_swipe_card.md 中挑一个具体场景，例如右滑 Like 流程，把入口类、关键方法和文档说明关联起来。然后在测试分支重命名方法或调整调用，观察 Swimm 是自动修复引用，还是把文档标记为需要更新。
这样听众会比较容易理解：Swimm 的核心不是“帮你多写一篇文档”，而是让已有文档知道自己引用的代码变了。
在我们场景中的应用
Swimm 和目前流程之间的衔接最自然：
AI 生成初稿
↓
负责人补充业务信息并人工 Review
↓
文档和代码建立关联
↓
后续 MR 修改相关代码时自动提醒
↓
文档与代码一起审核我们的 Feature Wiki 中有大量具体类、方法、文件路径和代码示例。地图、划卡、聊天键盘、商业化等页面都很适合做过期检测。
它不会替代模块负责人对业务内容的判断，但可以减少“类已经删了，Wiki 还写着旧路径”这类问题。
使用边界
Swimm 主要解决代码和文档的同步，不等于完整的 LLM Wiki。
它不擅长自动整合 PRD、技术决策、会议结论，也不负责给长期运行的 Agent 保存所有项目背景。因此它更像是现有 Wiki 的增强工具，而不是整套知识系统。
8. 几种方案怎么选
可以先按目标来选，而不是直接比较功能数量。
| 我们想解决的问题 | 更适合的方向 |
|---|---|
| 快速理解陌生仓库和模块 | DeepWiki |
| 代码合并后自动生成、增量更新文档 | AutoWiki |
| 保留 Markdown、GitLab MR 和 Agent 渐进式加载 | OpenWiki |
| 保存项目历史、决策、人员和跨来源知识 | GBrain |
| 检查已有 Wiki 是否随代码过期 | Swimm |
实际落地时不一定只选一个产品。
更可能的组合是：
保留现有 Feature Wiki 和人工 Review
+
引入 OpenWiki 或类似能力做增量生成
+
在 CI 中做 Swimm 风格的过期检查
+
需要时再扩展 GBrain 这类长期项目知识DeepWiki 则可以作为代码理解工具和外部效果基准。
9. 如何尝试
不建议一开始就重新生成全部 Wiki。范围太大，也很难判断效果到底有没有提升。
可以先选两个 Feature：
-
附近地图 V2
页面大、跨模块多、玩法多，也一直在变化，适合测试跨页面关联和增量更新。
-
划卡
是核心功能，但现有页面更新时间相对较早，适合测试过期检测和重新核对。
9.1 试点流程
选择一个真实 MR
↓
让系统识别受影响的 Wiki 页面和章节
↓
生成修改建议，但不直接合并
↓
模块负责人 Review
↓
记录接受、修改和拒绝的内容
↓
再让 Agent 使用新旧两版 Wiki 完成相同任务
↓
比较效果9.2 需要观察的指标
- 从代码合并到 Wiki 更新花了多久；
- 系统有没有找全受影响的页面；
- 自动修改有多少可以直接接受；
- 有多少内容属于错误推断；
- 人工 Review 花了多少时间；
- Agent 定位代码和影响范围是否更快；
- 是否减少了重复扫描源码和上下文消耗；
- 对真实开发、Review 和排障任务有没有帮助。
如果只是页面写得更完整、更漂亮，但没有减少开发中的查找、遗漏和重复理解，就不算真正解决问题。
10. 总结
LLM Wiki 和 RAG 并不是二选一。
- Wiki 适合保存已经整理过、相对稳定、需要反复使用的知识；
- RAG 适合从大量原始材料中寻找长尾细节；
- Agent 根据任务先读 Wiki，遇到关键结论再回到源码、MR 或 PRD 核实。
我们目前已经完成了很重要的一步：让熟悉 Feature 的同学控制范围，让 Cursor 生成 Wiki，再通过人工 Review 和 MR 合并形成团队知识。
下一步真正值得做的，不是再生成一批更长的文档，而是解决三个问题：
- 变化发生后，系统能不能主动知道哪些 Wiki 需要更新；
- Wiki 能不能保留来源、时效和冲突，让人知道它是否可信；
- Agent 在需求、开发、Review 和排障时，能不能真正把这些知识用起来。
最后要回答的也不再只是“怎样找到相关文档”，而是：
一个知识被使用、修改或者推翻之后，能不能稳定地沉淀下来，并在下一次工作中继续发挥作用。