知识库扩展复盘与完善路线图
本文用于对当前知识库进行一次自我复盘，总结已经完成的结构、仍然存在的空白，以及后续如何把文档逐步扩展到更完整状态。
1. 当前已经形成的结构
截至目前，知识库已经不再是单纯的截图堆，而是初步形成了四层内容：
第一层：总索引
docs/知识库总索引.md
作用：
- 提供总入口
- 汇总文档位置
- 描述当前覆盖主题
第二层：主题知识文档
包括：
- 教程主题
- 脚本主题
- 引擎更新主题
- 社区分析主题
作用：
- 把零散资料升级成可读、可检索、可教学的结构化知识
第三层：OCR 转文本归档
包括：
- 脚本界面截图 OCR
- 官方教程截图 OCR
- 引擎更新截图 OCR
作用：
- 保留原始证据
- 支持全文检索
- 支持后续人工校对
第四层：原始资料层
包括：
- 历史整理记录中对应的 jpg 截图原图
- 原始 txt
当前说明：
- 本轮快照中原始资料目录结构仍保留，但未列出可直接 OCR 的图片文件
- 因此 jpg 截图应按“历史原图层 / 待恢复核验”理解，不应写成当前已完整可用
作用：
- 提供回溯依据
- 保留未整理信息
2. 当前知识库的优点
2.1 已经有明显分层
现在已经能区分：
- 什么是原始证据
- 什么是整理索引
- 什么是专题解析
- 什么是社区推测
这对后续长期维护很重要。
2.2 已经具备研究型文档雏形
目前一些文档已经不只是“写了截图内容”，而是开始解释：
- 系统为何这样设计
- 组件与脚本的关系
- UI 与联机的边界
- 数据与作用域的分层
2.3 已经适合 AI/RAG 初步使用
许多文档已有：
- 关键词
- 来源
- 结构化段落
- 主题归纳
这意味着后续做问答、检索、向量化都更容易。
3. 当前仍然存在的不足
3.1 覆盖还不够完整
虽然已经整理了不少主题，但整体仍然只是“有骨架”，还没完全补肉。
尤其是：
- 脚本界面截图在历史 OCR 文档中仍有大量细节可继续分类、校对与回链；原图恢复后再继续新增 OCR
- 官方教程仍可拆出更多独立专题
- 引擎更新仍可继续按版本补来源与差异分析
3.2 文档风格尚未完全统一
目前文档虽然整体方向一致，但还可以进一步统一：
- 术语
- 章节顺序
- 来源字段
- 关键词字段
- 版本字段
- 待验证标注
3.3 “已证实 / 推测 / 待验证”还没彻底区分
这是一个很重要的问题。
尤其在社区分析类文档中，后续应明确标记：
- 官方明确说明
- 截图可直接证明
- 社区经验推断
- 需要实验验证
否则知识库规模变大后，容易混淆结论等级。
4. 后续完善的核心方向
方向 A：补齐覆盖面
目标：
- 原图恢复或重新盘点后，尽量把三大截图目录更多内容转成文本
- 当前无可 OCR 原图时，优先补现有 OCR 文档的状态词、映射表回链和专题引用
- 让知识库从“部分专题”走向“近乎完整覆盖”
优先级：
- 基础写脚本界面截图
- 官方教程文档截图
- 引擎更新说明截图
方向 B：补强深度
目标：
- 不只写“有什么”
- 还要写“为什么这样设计”“如何正确使用”“会踩哪些坑”
重点子系统：
- 广播
- UI
- 自定义组件
- 数据类型
- 作用域
- 地图与对象结构
- 联机同步
方向 C：补齐研究路线
目标：
- 把社区分析从“资料摘录”升级为“研究计划”
- 明确哪些问题可以继续实验验证
5. 建议统一的文档模板
为了让知识库越来越完整，建议后续尽量统一为以下结构：
- 主题简介
- 资料来源
- 核心定义 / 核心现象
- 结构解析
- 使用方式 / 设计意义
- 常见误区 / 限制
- 版本差异（若有）
- 关键词
- 待验证问题
这样会带来几个好处：
- 阅读体验更统一
- AI 更容易抽字段
- 后续自动化处理更容易
6. 建议增加的辅助文档类型
除了当前已有文档类型，后续还可以增加：
6.1 问题清单型文档
例如：
- 常见误区清单
- 联机问题排查清单
- UI 迁移检查清单
6.2 对比型文档
例如：
- 3.x vs 4.x
- 地图属性 vs 系统属性
- 官方组件 vs 自定义组件
- 地图 UI vs 物体 UI
6.3 时间线型文档
例如：
- 联机 UI 演进时间线
- 数据类型演进时间线
- 调试工具演进时间线
6.4 研究方法型文档
例如：
- 如何从截图做证据整理
- 如何区分观察结果与推测
- 如何设计创游实验验证流程
7. 建议增加“完整度状态”概念
为了让知识库更容易持续维护，建议以后给重点主题加一个大致状态：
- 草稿
- 已整理
- 深度整理
- 持续扩展中
- 近完整
例如：
- 广播机制：深度整理
- 联机 UI：持续扩展中
- 引擎更新全版本：持续扩展中
- 脚本界面全量 OCR：持续扩展中
这样做的好处是：
- 一眼看出哪里还没做完
- 更容易排优先级
- 不会误以为某些文档已经彻底完善
8. 当前最值得继续扩展的专题
脚本与界面方向
- 装置/机关组件深度研究
- 显示类组件深度研究
- 交互类组件深度研究
- 地图级脚本能力深度研究
- 脚本作用域与数据流深度研究（已开）
教程方向
- 广播机制深度解析（已开）
- 道具组件深度解析
- 子弹组件深度解析
- 地块组件深度解析
- 素材系统与实例化关系扩写
引擎更新方向
- 联机 UI 演进专题（已开）
- 数据类型演进专题
- 调试工具演进专题
- 编辑器工作流优化专题
- 兼容性与版本隔离专题
社区研究方向
- 3.x 与 4.x 可观察性差异（已开）
- 社区逆向研究问题清单
- 伪源码字段字典
- 类型转换实验路线图
9. 对“完整状态”的理解
所谓完整，不一定是“所有截图一个字不漏全抄完”，而更像：
证据层完整
- 关键截图大部分都有 OCR 与来源记录
主题层完整
- 主要系统都有独立专题
结构层完整
- 文档彼此之间能互相链接、互相解释
研究层完整
- 已知事实、推测、待验证路线能清晰分开
如果能达到这四点，知识库就已经非常成熟。
10. 本轮复盘新增结论
经过本轮继续体检，可以更明确地看到几个问题类型：
10.1 结构型问题
- 新增高价值文档后，旧专题不一定会自动回链，容易形成“新文档强、旧文档弱连接”的问题
- 总索引需要承担的不只是目录，还应承担阅读路线与聚合入口
10.2 工程型问题
- 文档头字段在持续扩写后容易出现日期、完整度状态、来源文件不一致
- OCR 工程文档容易出现统计更新了，但状态描述没同步的情况
10.3 内容型问题
- 旧专题往往知识是对的，但关联阅读不足，导致项目型价值没有完全释放
- 研究型文档与规范型文档之间还需要更多互链，才能真正适合 AI/RAG 长期使用
11. 本轮已执行的自我修复动作
为了避免复盘只停留在“说问题”，本轮已经实际执行了以下修复：
README 升级
- 增加快速导航
- 增加主题入口
- 增加阅读建议
- 增加维护说明
待验证问题清单增强
- 增加 P0 / P1 / P2 优先级
- 增加修复闭环
- 增加自我复盘说明
OCR 映射表边界修正
- 清理“待补专题”式表述
- 改成“研究计划项 / 处理建议”
- 降低索引文档与研究文档混淆
这些动作说明当前复盘不是空转，而是已经开始形成“发现问题 → 修正表达 → 回写结构”的闭环。
12. 下一轮最值得继续修的点
如果继续深度优化，下一轮建议优先做：
12.1 把总索引进一步升级成导航中枢
目标不是只列文件，而是：
- 能按主题找
- 能按问题找
- 能按证据层级找
- 能按成熟度找
12.2 给成熟文档重新评级
例如把部分文档从“持续扩展中”改成：
- 深度整理
- 近完整
这样可以提升全库状态表达的可信度和辨识度。
12.3 清洗 OCR 文档状态词的一致性
尤其是：
- 无有效文本
- 待复核
- 疑似重复页
- 待处理
这些状态如果定义更一致，后续做自动统计或 AI 检索会更稳。
12.4 给高价值专题补更多回链
优先补：
- 来源文件
- 对应截图编号
- 对应 OCR 文档
- 关联阅读
13. 总结
当前知识库已经从“资料整理”进入“系统化扩写”阶段。
下一阶段最重要的，不再只是继续堆内容，而是同时做好三件事：
- 扩覆盖
- 补深度
- 统一结构
只要持续沿这条路线推进，最后会得到一个：
- 可检索
- 可教学
- 可追溯
- 可研究
- 适合 AI 使用
的完整知识库。