救、重建，还是放弃先算值不值得修

这是《AI 项目烂尾的七个征兆》的下一期。上一期讲怎么发现坏了，这一期讲发现了怎么办。

先给一个反常识的判断：我们见过的烂尾项目里，相当一部分结论是「不该修」——不是因为修不了，是因为修好了也没价值。项目当初要解决的问题已经消失、或者没人能拍板继续投钱，修得再漂亮，半年后它还会再烂一次，而且这次依然不会有人发现。所以我们内部有句话：敢说「别救了」的人，才有资格说「这个能救」。

判定六问：当初的问题现在还存在吗（过不了就直接放弃）→ 资产还在吗（全丢只能重建）→ 病在哪一层（主因在需求层，修了也白修）→ 修复成本 vs 重建成本（超过重建的 60% 就重建，这笔账必须开工前算）→ 有没有能拍板的人（否决项）→ 对成功的定义现实吗。

三种结论三种动作：救（需求真实、主因在技术层、资产可复用、有拍板人）→ 出修复方案，含验收标准和预期效果；重建（技术层烂到根或修复 ≥ 重建的 60%）→ 推倒重来，但旧资产要列复用清单；放弃（问题消失、无人拍板、预算不合理、期望无法校准）→ 书面理由 + 替代建议。

怎么查清楚：体检有三层采集（环境层 / 应用层 / Agent 层）+ 真实问题四层出题（L1 基础能力、L2 库内真实问题、L3 多轮追问、L4 边界异常），四十多条问题跑下来逐条判定，被拒的必须逐条追根因（系统故障、业务拒答、安全拒答、接口报错四类混算会失真）。报告三样：健康分加一句话总结、异常项详解表（证据是硬要求）、根因诊断。

最后说清体检和独立验收的分工：上线前用验收把关，上线后用体检巡诊——两者都不动手改，修是第三个环节。

完整文字版见下方文章。