SPEC BASELINE
源代码与设计文档一致性检查
我们逐条比对设计意图与实现之间的偏离，并附上两侧的原文。
读取源代码，按原有设计文档相同的章节结构与格式，做出一份用作比对基准的设计文档。内容以代码为准，原有的设计文档只用来锚定格式；返还为 Markdown，可以按行比对。
查出设计文档与代码运行情况不一致之处，同时引用两侧原文，并判定严重度（高、中、低）、确信度及应由哪一侧修正。
不专门去找就不会暴露的偏离
每次改造都可能让实现偏离一点，系统却照样运行、测试照样通过 —— 不构成故障，也就没有察觉的机会。找不出来不是因为不够仔细，而是下面三件事叠在了一起。
流程照走，测试照过，不会作为故障暴露出来。
文档的记述与代码，直接摆在一起比不了。
几十万行规模的代码，靠人力追不完。
AI 与资深工程师的分工
程序控制执行顺序与重试，AI 只负责生成与验证；资深工程师只确认判断有分歧的内容和抽检部分。
我们只接收源代码与原有设计文档的样本，不连接正在运行的系统，也不连接数据库。机器读取原有设计文档，只把章节、列与行的框架交给 AI，不把文档正文交给 AI。
生成与验证分别由两个 AI 完成，验证使用另一个会话和另一套引擎。机器只判定格式与证据，结论是否成立不纳入机器的合格判定，以免 AI 通过减少指摘来过关。判断有分歧、影响较大以及抽检的部分，由资深工程师确认。内容确定后，再判定责任归属与严重度。
覆盖到每一行、每处差异都有原文为证的比对
只靠人力，工期会随规模拉长；直接交给 AI，结论又没有依据。为了避开这两点，我们事先定好了比对的框架，也定好了证据怎么出示。
比对的单位，是从原本中取出的框架 —— 章节、列与行。框架内的每一行，我们都会把文档侧的记述与代码侧的事实对照一遍，只有对不上的行才作为差异留下来。
读代码这件事不再占用人的工时，因此几十万行规模也能走完一遍，不会出现“没去找，所以没查出来”。
一处差异会同时带上文档侧的出处（工作表名与单元格编号）与代码侧的出处（文件名与行号），两侧原文均原样引用。读的人可以当场打开这两处，自己判断这一条是否成立。
除严重度与确信度之外，还会判定应由哪一侧修正；仅凭现有信息定不下来的，不作断言，而是作为“待确认”保留。
不依靠各语言的解析器，因此公司自研语言、各类定义文件、代码生成器的输出与旧世代的 4GL 也都在范围之内。
只要层结构与格式能够对应，即可沿用同一套步骤。对于清单中未列出的语言，也可根据少量代码判断是否适用。
有 1 种样本即可整理出规范；若一份都没有留存，则由我们先从格式与实现定下比对的骨架。
我们接收的只有源代码，既不连接正在运行的系统也不连接数据库，因此对运行没有影响，带出的范围也很明确。
客户无需事先准备任何材料。
由于比对的材料全部取自代码，运维步骤、与外部系统之间的约定这类不会出现在代码中的内容，不在范围之内；环境变量这类仅在运行时才确定的值，同样不在范围之内。
仅凭现有信息无法判定应由哪一侧修正的差异会保留下来。下面这次实测中，101 处里有 14 处属于此类 —— 我们不作推测、不下断言，而是作为“待确认”返还。
本页的服务范围限于制作比对基准、验证差异，以及判定严重度与责任归属。影响分析、修正方案和测试着眼点的展开，需另行商定范围。每次变更都自动重新验证的“持续保证”仍属构想，目前不提供。
在约 52 万行的系统上检出的件数
这是在 1 个项目上实施的结果。对象为 Java / Spring Boot 架构、约 52 万行的在运行系统；件数全部为实际输出值，案例已做匿名化。
比对基准的设计文档，与检出的差异
| 比对基准的设计文档 | 差异 高 | 差异 中 | 差异 低 | 差异 合计 |
|---|---|---|---|---|
| 8 份 | 13 | 46 | 42 | 101 |
于 2026 年度实施，成果物已通过客户验收。件数为实际输出值。
应由哪一侧修正（全部 101 处的分布）
每一处都会判定应由哪一侧修正；无法判定的不作推测，而是作为“待确认”保留。
本次实施得到的成果
NEXT
咨询请联络相关负责人。
只要指定一个对象，我们就会展示对应的成果物及验证报告。
可以直接查看实际系统的输出，判断这套方式是否有效。
只需告知选定哪一个对象，即可开始。