从逆向到正向：文档资产化的完整闭环

资产盘点

一条流水线跑完，doc/ 目录里沉淀出五类资产，各司其职：

五类资产构成一个金字塔：索引在塔尖回答「系统有什么」，模块和功能清单在中层回答「每个模块做什么」，功能点详情和链路图在塔基回答「具体怎么实现、证据在哪」。数据字典独立成柱，从数据库一侧撑起同一座塔。

新人上手：五级下钻

资产金字塔给新人设计了一条确定的学习路径：

flowchart TD
    A[第1级 00_索引.md 系统全貌] --> B[第2级 模块清单 挑相关模块]
    B --> C[第3级 功能清单 锁定相关功能]
    C --> D[第4级 功能点详情 输入输出规则]
    D --> E[第5级 链路图与代码提取 下钻到源码]

从索引进入，五次点击到达任何功能的字段级描述。这条路径的价值不在快，在于确定：新人不需要碰运气式地翻代码、找人问、撞运气，每一级该看什么、看完去哪，结构本身都指好了。传统方式里新人三个月摸清一个模块已算顺利；对着资产库，一周建立全局认知、两周深入目标模块，是可以复现的预期。

审计与测试的原料库

资产在日常运营里最常被查询的三个场景，都超出了当初「写文档」的预期。

故障定位。线上问题从页面现象入手，查链路图找到该功能点的完整调用链，沿着节点序号逐层排查，每层都有代码提取可对照。跨边界调用链在传统排查里是最难追的，恰恰是链路图的强项。

测试用例生成。业务需求文档里的输入参数表是天然的等价类划分依据，业务规则清单是断言来源。给测试团队一个功能点的详情，边界条件和校验规则不用再从代码里反推。

数据治理。数据字典配上人工核实清单，直接就是数据质量整改的工作底稿；注释脚本审核执行后，几百个字段的含义第一次沉淀进了数据库本身。

二次开发的规范来源

feature-dev一篇讲过衔接点，闭环的角度值得再看一遍：逆向产物加技术底座说明，共同构成新代码的约束环境。需求-实现映射表把新功能锚定在真实的表字段和既有接口上；业务需求文档划定了周边功能的行为边界，避免新代码破坏既有规则；链路图告诉开发者这个模块已有的调用模式，新代码照着模式长，不长成外来物种。

闭环的完整含义在这里：逆向工程不只是「读懂老系统」这个动作，而是为「持续演进老系统」建立的长期基础设施。系统每活一天，资产就多产生一天的价值。

资产的持续更新

系统不会冻结，资产必须能跟着长。流水线的更新策略按变化粒度分三档：单个页面改版，只重跑该页面的提取到需求三步，产物原地替换；一个模块调整，重跑归类合并，索引自动重算对账；数据库结构变更，数据字典增量精修，注释脚本只补新增和变更部分。

文件即接口的协议在更新场景里再次发挥作用：任何一步的产物都可以单独重生成，下游按文件名对齐替换，不存在全量重跑的惩罚。这让「维护文档」的成本从重新逆向一次，降到只处理变化的部分——文档资产因此可能持续活着，而不是像大多数逆向文档那样在系统第一次改版后失效。

流水线自身的演进

这条流水线自己也是资产，且在三个方向上持续增值。技术底座说明库：每个项目一份的七项配置，跨项目比较后能沉淀出团队级的工程约定。归类关键词库：多个项目的模块归类实践积累下来，新项目的归类起点越来越准。规则库：零合并、三级优先级、N=M 校验这些实战淬炼出的规则，构成了可迁移的 Prompt 工程资产，换一条业务流水线照样适用。

更远的方向是自动化程度加深：从人工触发每步，到调度器按依赖图自动推进，再到任务智能体主动发现资产过期并建议更新。协议层的稳定设计——文件接口、完成标志、状态账本——让这些演进不需要推倒重来，每一步都站在已有结构上加东西。

写在系列的结尾

十三篇走到了头，回头看这条流水线做的事情可以一句话说完：把「读懂一个系统」这件原本依赖老师傅的事，变成了一套可重复执行、每步可校验、产物可积累的工程。

贯穿全系列的判断只有一条：文档不是开发的副产品，是让系统重新可维护的核心资产。代码回答「怎么做」，这些资产回答「为什么」和「是什么」——而老系统的死亡从来不是因为代码坏了，是因为再没有人知道它们为什么这么运行。

系列全部十三篇：

如果你也守着一套无人敢动的祖传系统，希望这条流水线能给你一个起点：先把第一个页面的功能点提取跑起来，资产的路是从第一份 JSON 开始走的。