CODE INSIGHT
设计文档逆向生成
设计文档，可以从正在运行的代码重新生成。
读取正在运行系统的源代码，按原有设计文档相同的章节结构与相同的格式重新生成。记载的值全部取自代码，原有的记载一字不抄。
把“文档中如此记载，代码却并非如此运行”之处连同证据查出，并判定应由哪一侧修正。
系统运行越久，设计文档与代码就相距越远
每次改动只有代码得到更新，文档追不上。这很常见，但作为经营判断的材料，这种状态会以下面三种形态显现。
着手之后才发现文档与实现有出入，追加工时的协商空间随之消失。
只有读得懂代码的人才查得动，那个人的离任本身即构成风险。
未按设计文档运行之处，由于无人做过比对，便一直搁置。
AI 与资深工程师的分工
先由 AI 自我检验，资深工程师只确认存在分歧之处与抽检部分。
由 AI 自我检验：它写下的每一处记述在代码上能否找到依据、有没有遗漏，可就地修正的当即修正。
在此之上，只把判断有分歧、影响较大以及抽检的部分交由资深工程师。按工程师的指摘改过之后，待内容不再变动，才确定责任归属与严重度。
这些指摘同时进入下一次的生成条件，因此同类的遗漏会逐次减少。
采用“重写一份”，而不是“更新”
原有的设计文档一字不动，只借用它的格式另写一份 —— 以下各点全部由此而来。
从原有设计文档接收的只有章节结构与格式，其中写了什么一概不参照。
采用“更新”的做法，错误的记述会保留下来；正因为不抄录，两者的出入才会作为不一致显现出来。
章节结构、各列的含义与记载的粒度，都对齐客户现在使用的 Excel 设计文档，两份可以并列按相同顺序阅读。
返还的是纯文本的 Markdown，可以按行取差异，检索、评审与机器处理都能直接使用。
不依靠各语言的解析器，因此公司自研语言、各类定义文件、代码生成器的输出与旧世代的 4GL 也都在范围之内。
只要层结构与格式能够对应，即可沿用同一套步骤。清单中没有的语言，提供少量代码也能判断。
有 1 种样本即可整理出规范；若一份都没有留存，则由我们确定格式。
我们接收的只有静态副本，既不连接正在运行的系统也不连接数据库，因此对运行没有影响，带出的范围也很明确。
客户无需事先准备任何材料。
由于记载的值全部取自代码，运营步骤、与外部系统之间的约定这类不会出现在代码中的内容，不在范围之内；仅在运行时才确定的配置值也是同样。
仅凭现有信息无法判定应由哪一侧修正的出入会保留下来。下面这个案例中，101 处里有 14 处属于此类 —— 我们不作推测、不下断言，而是作为“待确认”返还。
实际做一遍，检出的件数
对象为 Java / Spring Boot 架构、约 52 万行的在运行系统。件数全部为实际输出值，案例已做匿名化。
重新生成的设计文档，与检出的不一致
| 重新生成的设计文档 | 不一致 高 | 不一致 中 | 不一致 低 | 不一致 合计 |
|---|---|---|---|---|
| 8 份 | 13 | 46 | 42 | 101 |
于 2026 年度实施，成果物已通过客户验收。件数为实际输出值。
应由哪一侧修正（全部 101 处的分布）
每一处都会判定应由哪一侧修正；无法判定的不作推测，而是作为“待确认”保留。
本次实施所得到的成果
NEXT
咨询请联络相关负责人。
只要指定一个对象，我们就会把成果物及其验证报告作为实物呈现出来。
这套方式是否有效，与其听我们讲件数，不如直接看从实际系统中跑出的结果 —— 这是最快的办法。
只需告知选定哪一个对象，即可开始。