本文是 Knowledge Archiver 插件系列的第四篇。感兴趣的可以先看看前面几篇：
前面三篇文章聊了插件是什么、为什么这样设计、跟竞品比怎么样。
但有一个核心问题一直没回答：AI 生成的知识文档，质量到底行不行？
这个问题很重要。如果文档质量不行，后面所有的场景——新人入职、跨部门沟通、AI 问答检索——都是建立在沙子上。
这篇文章拿一个真实模块做对照实验，用数据说话。
插件版本更新
在写这篇文章的过程中，插件也同步更新了 v1.9.3，主要改了两个体验问题：
1. AI 对话的 Markdown 渲染
之前 AI 回复的 Markdown 原文直接显示，表格、标题、粗体都没渲染，看着很痛苦。现在支持了基本的 Markdown → HTML 转换：
2. 用户气泡只显示问题文本
之前恢复历史对话时，用户气泡里把发给 AI 的完整消息（包含知识文档 + 源码 + 用户问题）全显示出来了，看着像一坨代码。现在只显示用户实际输入的问题：
这两个改动不影响功能逻辑，纯体验优化。
实验设计
选了一个中等复杂度的业务模块：work-order（工单管理）。
这个模块的代码量约 3000 行，包含工单同步、接收、变更、删除、任务生成等完整业务流程。
实验步骤：
- 用插件的「初始化」+「深化分析」生成文档
- 在 AI 对话里问一个关键问题："该模块还缺少哪些重要的业务链条？"
- 让 AI 基于已有文档和源码，系统性地找出缺失的业务链路
- 人工复核 AI 找出的缺口，验证准确性
第一轮结果：看起来不错，但漏了最关键的
深化分析跑完后，文档覆盖了这些内容：
| 已覆盖 | 说明 |
|---|---|
| 忽略变更（ignoreChange） | 工单变更忽略流程 |
| 材料交期查询与回写 | mergeAnalysisMaterialDates |
| 任务拆分/合并 | 任务层级操作 |
| 接收（佳都版） | receiveWo 流程 |
| 开单删除 | 物理删除校验 |
| 颜色刷新、面辅料日期 | 辅助功能 |
看起来覆盖了挺多。但这是 AI 自己分析的结论——它不知道自己漏了什么。
AI 对话：一句话找出 12 条缺失链路
我在 AI 对话里问了一个问题：
"该模块还缺少哪些重要的业务链条？"
AI 基于已有知识文档和源码上下文，一次性找出了 12 条缺失的业务链条，每条都标注了现状、缺失环节和源码线索：
找出了什么？
| 优先级 | 缺失链路 | 核心问题 |
|---|---|---|
| P0 | 工单变更回写 ERP/SCM 的闭环链路 | 文档有"忽略变更"和"材料交期查询"，但缺少变更确认后回写 ERP/SCM 的链路 |
| P0 | 工单接收的并发控制与幂等性 | 文档描述了 receiveWo 流程，但未涉及并发接收的防御 |
| P1 | 报工数据反馈工单/任务的闭环 | 报工数据如何影响工单状态和任务进度，文档完全没覆盖 |
| P1 | 工单与排程（schedule）的联动链路 | 任务生成后如何触发排程，排程结果如何回写工单状态 |
| P1 | 拆单/合单的对称性与异常恢复 | 文档覆盖了任务拆分和合并，但缺少拆分/合单的逆向操作 |
| P1 | 工单删除与任务/排程/报工的级联清理 | 工单删除后，已生成的任务、排程记录、报工记录如何处理 |
| P1 | 物料交期变更的实际应用链路 | 文档描述了 materialChange 查询 ERP，但未描述查询结果如何应用到工单/任务 |
| P2 | 款式工时变更与工单的联动 | 文档未涉及工时变更如何影响工单 |
| P2 | 咨询单 → 实单的主动转换机制 | 文档描述了接收时的自动关闭逻辑，但缺少咨询单主动转实单的链路 |
| P2 | 开单与产前准备的联动链路 | 自动开单生成的单据编号规则、状态流转未描述 |
| P2 | 二次工艺的闭环处理 | 文档描述了接收时注入二次工艺，但未涉及二次工艺的后续处理 |
| P2 | 工单操作日志的完整记录链条 | 文档提到了 PsWoOpLogEntity，但未系统描述操作日志的写入时机和内容 |
这个结果意味着什么？
之前人工复核只发现了 syncWoData 和 sureChange 两个大方法没覆盖。但 AI 对话从业务链条的角度，找出了更多维度的缺失：
- 跨模块链路：工单与排程、工单与报工、工单与 ERP 回写——这些涉及多个模块的交互，单模块深化分析很难覆盖
- 逆向操作：拆单有，但拆单撤销没有；合单有，但合单拆分没有
- 并发与幂等：文档描述了正常流程，但没考虑并发接收、重复提交等异常场景
- 闭环完整性：有查询没回写、有创建没删除、有正向没逆向
AI 对话不是简单地"读代码找遗漏"，而是从业务流程完整性的角度做系统性审查。 这是人工复核很难做到的——人容易盯着自己熟悉的几个方法，AI 能扫描整个模块的调用关系和上下游依赖。
为什么深化分析会漏掉这些？
深化分析的工作方式是：AI 自主决定读哪些文件、分析哪些内容。它擅长的是单模块内的深度挖掘，但不擅长：
深化分析擅长：
- 单个方法内部的逻辑梳理
- 状态机、业务规则的提取
- 异常处理路径的补充
深化分析不擅长：
- 跨模块的调用链路（工单 → 排程 → 报工）
- 逆向操作的对称性（有拆单没拆单撤销）
- 并发控制和幂等性设计
- 外部系统的闭环回写（变更确认 → 回写 ERP）
这不是 AI 能力的问题，是分析视角的问题。 深化分析是"从内往外看"——深入一个模块内部。而 AI 对话是"从外往内看"——从业务流程的完整性出发，审视模块的边界和缺口。
两种视角互补，缺一不可。
正确的协作模式：对话发现 + 深化填充
基于这次实验，完整的知识文档生产流程应该是：
第 1 步：初始化 + 深化分析 → 覆盖模块内部逻辑（约 50-60%）
↓
第 2 步：AI 对话问"还缺少哪些业务链条" → 系统性发现缺口
↓ AI 找出 12 条缺失链路，按优先级排列
↓
第 3 步：点"深化分析此模块" → 对话结论自动作为补充指引传入
↓ AI 聚焦补充 P0/P1 级缺失链路
↓
第 4 步：再对话验证 → "工单与排程的联动现在覆盖了吗？"
↓ 如果还缺，继续补充
↓
...直到覆盖率满意
对话负责从业务链条角度发现"缺什么"，深化分析负责从代码角度填充"补什么"。 两个功能配合使用，才是完整的协作闭环。
而且插件的"深化分析此模块"按钮已经内置了这个能力——它会自动提取最近 3 条 AI 回复作为补充指引，不需要手动复制粘贴。
覆盖率对下游的影响
为什么覆盖率这么重要？因为知识文档不是终点，是起点。
知识文档（生产端） RAG 服务（消费端）
┌─────────────────┐ ┌──────────────────┐
│ 代码 → 知识文档 │ ──→ │ 文档 → 切块 → 向量 │
│ （知识归档插件） │ │ 检索 → AI 回答 │
└───────────────── └──────────────────┘
如果知识文档只覆盖了模块内部逻辑，但漏了跨模块链路（工单→排程→报工），那用户问"报工后工单状态怎么变的"，RAG 检索不到相关内容，AI 就只能瞎编。
引擎（RAG）再好，燃料（知识文档）不行也白搭。
这也是为什么我最近在做一个轻量级的 RAG 服务（ai-knowledge-base），专门对接这些 Markdown 知识文档做语义检索。但在对接过程中发现：文档质量直接决定问答质量。如果文档漏了工单与排程的联动，用户问"排程结果怎么回写工单"，AI 完全回答不了。
几个实操建议
基于这次验证，给几个实用建议：
1. 深化分析后必做：用对话问"还缺什么"
深化分析跑完后，不要直接认为文档就够了。在 AI 对话里问一句：
"该模块还缺少哪些重要的业务链条？"
AI 会从业务流程完整性的角度做系统性审查，找出深化分析遗漏的跨模块链路、逆向操作、并发控制等内容。
2. 关注跨模块链路
单模块深化分析很难覆盖跨模块交互。以下类型的链路最容易遗漏：
- 模块 A 调用模块 B 后的回写/回调
- 数据在多个模块间的流转闭环
- 定时任务对模块状态的间接影响
3. 检查操作的对称性
有正向操作就要问逆向操作：
- 有拆单 → 拆单撤销呢？
- 有合并 → 合并拆分呢？
- 有创建 → 删除的级联处理呢？
- 有接收 → 并发控制和幂等性呢？
4. 深化分析要指定重点
如果已经明确知道缺什么，在补充指引里直接写上：
"重点分析工单与排程的联动链路，以及报工数据反馈工单状态的闭环"
AI 会聚焦这些方向去分析，而不是自己瞎选文件。
5. 覆盖率不是 100% 才行
90% 左右就够了。剩下 10% 通常是边缘场景或已废弃的逻辑，投入产出比不高。优先补 P0/P1，P2 可以按需补充。
总结
AI 生成知识文档不是银弹。深化分析能覆盖模块内部 50-60% 的逻辑，但跨模块链路、逆向操作、并发控制等维度容易遗漏。
AI 对话是发现这些缺口的关键工具。 一句"还缺少哪些业务链条"，就能让 AI 从业务流程完整性的角度做系统性审查，找出深化分析遗漏的内容。
完整的协作模式是：
- 深化分析：从内往外看，深入模块内部逻辑
- AI 对话：从外往内看，审视业务链条完整性
- 两者配合：对话发现缺口 → 深化分析填充内容 → 对话验证覆盖
这个结论对两个方向都有意义：
- 知识生产端（插件）：深化分析 + AI 对话是互补的两个工具，配合使用才能逼近全覆盖
- 知识消费端（RAG）：文档覆盖率直接决定问答质量，垃圾进垃圾出
下一篇文章会聊聊知识消费端的设计——怎么把这些 Markdown 文档变成可检索、可问答的知识服务。
欢迎试用插件和反馈。
