AI 改造立项会上，两条路常被对立：推倒核心系统重做，或封装现有系统先上场景助手。前者听起来彻底，后者听起来不够数字化。把成本与停机风险摊开后，多数企业更该先走封装。
两笔账算清楚
重建账包含迁移、停机、培训、双轨并行、失败回滚，以及最贵的注意力占用。封装账包含接口盘点、网关、一两个只读场景、四周验收。封装要求你忍住「一次到位」；重建要求你证明旧系统真的无法安全暴露能力。
绞杀者模式借到 AI
Martin Fowler 的绞杀者模式主张用新能力逐步包裹旧系统。对应到 AI：旧系统继续跑业务；外侧加只读 API；助手先做查单、摘要、异常提醒；价值被证明后再谈写路径。Thoughtworks Technology Radar 亦偏好可增量演进的集成，而不是大爆炸替换。
接口盘点四类
- 可公开只读
- 需鉴权只读
- 高风险写
- 禁止开放
首期只碰前两类。没有正式 API 时，做受控只读视图或导出，而不是让模型直连生产库。直连生产库是最贵的捷径。盘点叫上安全与业务，避免 IT 单独「觉得可以」。
首期场景三条件
高频（每周有人问）、只读（不直接改钱改库存）、可验收（四周能看时长或差错）。查单状态、报表摘要、异常提醒通常符合；自动改价、自动下单通常不符合首期。
何时才考虑重做
核心系统无法安全暴露接口、厂商停服、合规强制迁移，且业务能承受双轨成本。否则「为了 AI 而重做」往往把 AI 项目做成了换系统项目。麦肯锡数字化研究强调端到端能力与运营改造，并不等价于先换一套芯。
用四周试点数据回应「不够彻底」的质疑：查单时长、摘要可用率、异常发现数。有数字，比有口号更能挡住推倒重来的冲动。
延伸阅读
- Martin Fowler《Strangler Fig Application》绞杀者模式
- Thoughtworks《Technology Radar》技术雷达
- 麦肯锡《Rewired》数字化转型研究观点
政治阻力怎么拆
「封装不够彻底」常来自两处：一是供应商希望卖实施大单，二是内部希望借 AI 立项完成换系统宿愿。拆法是把目标写成可测场景，而不是写成架构形容词。场景达标，路线就成立；场景不达标，换模型或换接口，不必先换心脏。
封装也不是永远停留在只读。路线图可以预留写路径，但写路径的准入条件写死：审计完备、拒写题集通过、业务主人就位、回滚演练完成。条件不齐，写路径不开。这样既安抚「未来会更深」，又守住「现在不安全就不上」。
成本复盘按场景而不是按平台：每个场景的开发、提示词维护、值班与模型调用费用进同一张表。平台摊销算法很容易把失败场景养肥。场景级账本，才能支持「继续 / 停掉 / 加深」的冷静决策。
最低成本不是最便宜的模型账单，而是最少的不可逆动作。封装可逆，重建难逆。先可逆地证明价值，再谈不可逆的替换，顺序本身就是风控。
封装路径也要防「接口腐烂」：旧系统接口无文档、无兼容承诺。对策是契约测试与消费者驱动校验——助手依赖的字段集写成测试，旧系统一改就红灯。红灯比生产静默错答便宜。重建拥护者常说旧系统无可救药；先问是否做过契约测试。没测过，就还没有资格宣判死刑。
让数据说话：四周场景指标达标，封装就继续；连续两次不达标且根因在业务任务选错，换场景；根因在系统无法安全暴露，再评估重建。决策树写进立项材料，避免每次都从信仰辩论重来。
