夜雨聆风
五年老系统,文档一片混乱?用这套 AI 逆向工程方法重建知识库
运营了 5 年以上的业务系统，PRD 文档散落一地，新来的同学连”这个功能是干嘛的”都说不清楚——这是很多研发团队的真实写照。
我们团队就遇到了这个问题：一套支撑核心业务的业务系统，依赖着人员管理系统、学习记录系统、沟通记录系统、工单系统、数据报表系统等多个子系统。系统上线 5 年多，历史逻辑盘根错节，PRD 文档形式各异（PDF、Confluence 文档混杂），相当多的功能甚至已经找不到当年的需求文档。
现在我们想要向 AI 协作方向转型，提升研发效率。但摆在面前的第一道坎就是：如何维护好系统的历史知识库？
🤔 先搞清楚三个问题
在动手之前，我们梳理了三个核心疑问：
问题一：一个功能经历了多次迭代，产出了若干份 PRD，只有全部整合才能还原系统现状——这条路是不是走远了？
问题二：应该把分散的历史 PRD 整理归纳成现状，还是从现有平台功能和代码仓库出发，重新梳理出新的系统现状？
问题三：如果从现有平台功能和代码仓库出发，有没有可落地的好实践？
💡 核心结论：别迷恋历史 PRD，代码才是唯一真相
把历史 PRD 全部整合来还原系统现状，不仅是绕远路，而且结果注定是错的。
历史 PRD 本质上是系统演进的 Diff（差异补丁），而不是 Snapshot（当前快照）。开发过程中的妥协、线上的紧急 Bugfix、未落文档的口头需求……这些都不会反映在 PRD 里。历史 PRD 叠加起来，绝对不等于当前的系统现状。
在软件工程里，唯一不会撒谎的 Single Source of Truth（唯一真实数据源），是运行在生产环境的代码和实际存在的 UI。
历史 PRD 的唯一价值，是用来找回那些”反直觉的业务逻辑背后的原因（Why）”——当你看到一段奇怪的代码，想知道”为什么要这样设计”的时候，再去翻 PRD。
🔧 实践路径：四步建立系统知识库
第一步：功能盘点（由外到内）
从用户视角出发，遍历系统每个模块和页面，梳理出功能清单：
- 每个模块做什么、谁在用、核心业务流程是什么
- 业务系统与外部系统（人员管理、学习记录、沟通记录、工单、数据报表等）的依赖关系和数据流向
- 输出一份模块级功能地图
第二步：AI + 代码自动生成文档
按模块让 AI 工具读取代码仓库，自动生成：
- 架构说明（模块划分、服务依赖）
- 接口文档（API 列表、入参出参）
- 业务逻辑描述（核心流程、分支条件、状态流转）
人工校验修正后，形成系统现状知识库。
第三步：历史 PRD 按需关联
当 AI 或人工从代码还原逻辑时遇到”为什么这样设计”的疑问，再回查对应历史 PRD。PRD 的定位是辅助材料，不是主线。
第四步：建立持续维护机制
- 每次需求迭代，将”更新知识库”列为交付 checklist 的必选项
- 知识库按模块组织，与代码模块一一对应，降低维护成本
- 防止知识库再次腐化
🚀 落地实践：AI 时代的”逆向工程”三步法
不要妄想一次性把系统 100% 还原。正确的姿势是采取 “按需逆向（Just-in-Time Documentation）” 策略，结合 AI 工具，分三步走。
Step 1：自顶向下 —— 用多模态 AI 逆向产品 UI
不需要人去苦哈哈地写功能清单，利用强大的多模态大模型（如 GPT-4o、Claude 3.5 Sonnet 等）：
让产品经理或测试人员对当前系统的核心流程录屏或截图，直接喂给 AI。
Prompt 示例：
“这是一套复杂业务系统的工单管理模块截图。请你作为资深产品经理，根据截图逆向写出：1. 核心功能清单；2. 用户操作交互流程（输出 Mermaid 格式图表）；3. 页面包含的数据字段。”
产出物：快速形成当前系统的最新”产品白皮书”骨架，不再依赖任何历史文档。
Step 2：自底向上 —— 用代码 AI 逆向提取业务骨架
① 数据库提取核心领域模型：将当前数据库的 DDL（表结构、注释）导出，喂给 AI，让它生成当前系统的”领域模型图（ER Diagram）”。
② 用 Cursor / GitHub Copilot 反推复杂规则：选取那些没人看得懂的历史逻辑代码，使用 AI IDE 的 Codebase 问答功能。
Prompt 示例：
“请分析这段负责学习记录数据同步的核心类，用大白话告诉我：1. 它依赖了哪些外部系统？2. 数据同步的触发条件是什么？3. 有哪些写死在代码里的特殊业务规则？”
Step 3：”废物利用” —— 让历史 PRD 发挥余热
老 PRD 不是没用，只是不能作为功能现状的参考。把那些散落的 PDF 和 Confluence 文档打包，构建一个临时的历史需求知识库，专门用来回答”为什么”，而不是”是什么”。
📚 构建”AI 友好型”现代知识库
优秀的 AI 友好型知识库（AI-Ready Knowledge Base）应具备以下特征：
- 全 Markdown 化与结构化：统一格式，AI 和人都好消化
- 多用 Mermaid 图表语言：流程图、时序图、ER 图直接写在文档里，版本可追踪
- 领域词汇表（Ubiquitous Language）：统一业务术语，避免”沟通记录”和”通话日志”指的其实是同一个东西
- API First & 契约化：系统间集成以接口契约为准，文档即合同
🛡️ 如何避免再次陷入”文档腐化”？
建立了知识库还不够，更重要的是让它持续保持新鲜。三个关键原则：
- 代码即文档（Docs as Code）：文档与代码一起提交、一起 Review、一起版本管理
- 改变 PRD 的形态：从”大单体需求文档”走向”模块补丁式变更记录”，每次迭代只描述变化的部分
- 构建团队专属 Copilot：基于自己的知识库搭建 RAG 系统，让 AI 真正能回答”我们系统里这个逻辑是怎么实现的”
🎯 总结：童子军规则，从下个迭代开始
别打算停下业务花几个月来重写文档。这不现实，也没必要。
最佳切入点是：从下个迭代要动到的模块开始（Boy Scout Rule – 童子军规则）。
就像童子军的规矩：离开营地时，让它比你来时更干净一点。每次迭代让知识库比上次更完整一点，用多模态大模型和代码大模型提效，半年后，你们的核心知识库就会自然丰满且高度准确。
不需要一口气吃成个胖子，持续小步走，才是对抗文档腐化的正确姿势。