这个案例说明什么
一套已经上线、覆盖 12 家分子公司的业财协同平台，问题集中爆发后，靠一个技术人员加 AI，在两周内完成深度诊断，再用两个阶段的整改把综合评分从 4.8 带到 8.5。
评分不是一条平滑上升的线。一阶段结束时到了 8.2，二阶段开始时提高了评估标准，按新口径重设基线到 7.0，再爬升到 8.5。图表里保留了这次回落。
数字的口径
Bug 统计取自开发方的缺陷台账，截至二阶段收官；六维评分由 reform-assessment 流程生成，每一版都有对应的评估报告。
服务对象
某央企物资供应链协同平台，覆盖 12 家分子公司
我的角色
诊断与整改评估负责人。一个技术人员加 AI 完成诊断和评估，修复由约 40 人的开发团队和三家供应商完成。
1现象
- 2025 年 12 月集中出现五类问题：系统对接不稳定、业财协同缺陷、操作体验差、数据重复录入、问题响应依赖研发。
- 2026 年 1 月业务高峰问题爆发，多家分子公司的库存与账务数据对不上。
- 开发方逐个排查，问题越积越多，业务侧失去信心。
2方法
- 全量台账分析17,037 条去重问题记录逐条归类，找出集中在哪几个模块。
- AI 代码静态分析两轮扫描 6,119 个 Java 文件，证实一项费用匹配功能在代码里根本不存在，再用 SonarQube 交叉验证。
- 双线推进A 线用脚本直连数据库做体外对账，先止血；B 线拿缺陷清单推动开发方根治。
- 六维加权评分组织部署、问题覆盖率、技术方案质量、执行进度、实际问题消解、闭环管理，0 到 10 分，逐版评估整改进展。
- 沉默验证整改后做用户调研，看原来的核心问题还有没有人提。用户不再抱怨的地方，才算治理到位。
3量化结果
- 4.8 → 8.5六维综合评分一阶段 4.8 → 8.2，二阶段按新标准重设基线 7.0 → 8.5
- 1,261个 Bug 关闭，累计 1,264 个关闭率 99.8%，剩 3 个低优先级
- 16 版量化评估报告V1 到 V15 加收官评估
- 8 个原核心问题关键词在整改后调研中出现 0 次
4交付物
- 诊断报告与解决方案（2025-12），11 份专项诊断报告（2026-02）
- 整改进展评估 V1 到 V15，人员及供应商评估 V1 到 V15
- 重构方案评估报告，诊断与整改方法论
- 脚本工具：每日材料抽取、体外对账脚本（1,167 行）、112 对表数据校验、UI 自动化巡检
- 治理看板与用户调研反证分析
- 整改前
- 整改后
查看数据表
| 维度 | 整改前 | 整改后 |
|---|---|---|
| 组织部署 | 7 | 7.5 |
| 问题覆盖率 | 5 | 9 |
| 技术方案质量 | 7 | 9.5 |
| 执行进度 | 3 | 9 |
| 实际问题消解 | 4 | 8.5 |
| 闭环管理 | 3 | 8 |
来源：整改进展评估 V1.0、二阶段整改工作综合总结
查看数据表
| 节点 | 数值 |
|---|---|
| 2/23 | 4.8 |
| 2/24 | 5.1 |
| 2/25 | 5.7 |
| 2/26 | 6.6 |
| 2/27 | 6.7 |
| 2/28 | 7.8 |
| 3/2 | 8.2 |
| 3/3 | 7 |
| 3/8 | 7.2 |
| 3/11 | 7.4 |
| 3/16 | 7 |
| 3/19 | 7.1 |
| 3/21 | 7.4 |
| 3/27 | 7.2 |
| 3/28 | 7.5 |
| 4/8 | 8.5 |
来源：全周期总结报告的评估版本表
合计 24 项。来源：全周期总结报告，深度诊断章节
合计 399 个。来源：全周期总结报告，一阶段整改章节
关键决策与取舍
重构方案评估过，暂不实施
先修数据再谈新业务，先把现平台带回可用再谈重构。重构方案里有绕开立项审批的做法，这是第一条红线。
体外对账止血，缺陷清单根治
用户等不起开发方逐个修，先用脚本在系统外把账对平，同时把缺陷清单交给开发方按优先级修。这是整个项目最重要的战术决策。
用调研反证整改效果，也写清局限
五大缺陷模块的关键词在整改后调研中出现 0 次；同时承认 AI 对系统之外的问题，比如线下流程，作用有限。