这个案例说明什么
面对一个多家供应商长期迭代、代码规模上万文件的平台，诊断先划清范围，再按工作包并行推进，每一条结论都要回到源码确认，最后按读者分层汇报。
这是「诊断、治理、赋能」三阶段方法的第二个完整案例。诊断阶段已完成，治理阶段已交付方案和两个工具，赋能阶段等待授权。
服务对象
某央企电子采购平台，诊断范围 5 个系统、24 个业务域
我的角色
独立诊断方。从源码独立得出结论，不依赖平台以往的任何诊断产出。
1现象
- 平台由多家供应商长期迭代，代码分散在 33 个域、1,139 个 pom 模块、约 5 万个 Java 源文件里。
- 三套公共框架被全平台引用约 890 处，一旦有缺陷，影响面极大。
- 需要回答：会出事的代码在哪，支付和鉴权靠不靠得住，配置到底怎么生效。
2方法
- 10 个工作包资产盘点、重大 Bug 扫描、主链路流程、支付专项、安全鉴权、配置生效链、自动化运维、测试覆盖、权限与参数治理、独立收口。
- 子代理并行深读重大 Bug 扫描由 18 个扫描子代理分头深读代码，每条候选都要回到源码确认。
- 分级审核自检、子代理核证据、人工 checkpoint、Codex review、对抗式审查、终审签字，逐级把关。
- 三档受众分册同一套结论分成高层、业务、技术三册汇报，另有一册给对口核实人。
3量化结果
- 7 天完成 10 个工作包2026-05-17 起，05-24 全部封档
- 339 + 14条风险点首轮诊断 339 条，框架补充审计再确认 14 条
- 80条重大 BugP0 4 条、P1 54 条
- 268条部署资产入账
4交付物
- 10 份工作包专项报告，技术版和业务版两份总报告，7 份明细清单
- 框架审计报告、补充诊断结论、已确认风险整改清单
- 高层、业务、技术三档汇报包
- 治理方案总纲，两个工具：高危参数到期预警、配置漂移检测
- 客户版整改方案
合计 339 条。来源：完整报告业务版
合计 339 条。来源：诊断总报告技术版
关键决策与取舍
补交源码不等于问题解决
框架源码补交后没有直接销项，而是逐一审计，坐实 4 条、新增 10 条缺陷。
诊断范围收敛到 5 个系统
独立部署、不在采购主链路、源码不全的系统排除在外，把火力集中在采购主链路上。
不等逐条回填就进入治理
按保守假设先防，宁可多防，不让诊断结论卡在确认环节里。