旧系统要一次换掉，还是要边跑边改？
现有问答系统结构混乱、迭代变慢，团队想一次性重写，但业务不能停机，且重写期间新需求仍在涌入。
- 01现有系统持续承接线上流量
- 02重写期间需求不会停止
- 03结构问题拖慢每次迭代
- 04团队没有第二套人力
你会选择哪一种决策？
先做选择，再展开每条路径的判断。键盘按 1–4 作答。
查看这条路径的判断
推荐路径
把重构拆成可回退的小步，业务不停机、需求能继续排。代价是过渡期两套结构并存、维护更麻烦，但风险始终可控。
🎯 评审反诘 · 项目立项评审委员会「该推荐路径在保证业务确定性的同时，把大模型用在了最具杠杆价值的核心环节。如何量化并向管理层证明 ROI？」
PM 论据：以最小的工程研发复杂度锁定 90%+ 的核心诉求，风险完全隔绝在可控沙箱内，交付确定性最高。
查看这条路径的判断
有条件成立
结构能彻底做干净，但把业务等待成本全部付出去，重写期间的竞争与用户需求变化无人响应，代价由业务方承担。
⚖️ 评审反诘 · 业务运维 Leader「这套方案只在特定理想条件下成立。如果前置依赖（如网络质量、向量切片准确度或并发负载）发生波动，降级预案是什么？」
PM 审视：不可把假设当成事实。必须在前置方案中明确定量成立指标，并随附故障回退 Runbook。
查看这条路径的判断
有条件成立
交付不受影响，但结构问题会持续放大，每次迭代成本递增，把技术债转嫁给未来的排期与工程稳定性。
⚖️ 评审反诘 · 业务运维 Leader「这套方案只在特定理想条件下成立。如果前置依赖（如网络质量、向量切片准确度或并发负载）发生波动，降级预案是什么？」
PM 审视：不可把假设当成事实。必须在前置方案中明确定量成立指标，并随附故障回退 Runbook。
查看这条路径的判断
高风险路径
两个目标都没守住：人力被摊成两半，旧系统迭代变慢、新系统也迟迟不能上线，最后两边都延期。
⚡ 评审反诘 · 技术架构师 / 风控评审人「该方案明显引入了不可控的不确定性、调用延迟与接口成本。一旦长尾样本发生幻觉或服务超时，由谁对业务资损与客诉担责？」
PM 审视：切忌盲目“为 AI 而 AI”，确定性问题坚持规则优先，高风险链路必须设置安全熔断阀。
该选项在实际业务中存在盲区或隐性风险。已为你自动归集，随时可前往攻坚专区专项消灭。
不只记答案，记住判断方法
答完后展开
重构与交付冲突时，用可回退的小步替换代替一次性切换，把过渡期的维护复杂度当作必要代价。
- 01能否分批替换并回退
- 02过渡期由谁承担维护
- 03业务等待成本多高
PM 落地
如果你是产品经理，下一步做什么
按模块排出替换顺序与流量切换计划，写明每一步的回退条件、观察指标与过渡期维护责任人。
想在真实业务场景中看本题的落地推演？
在《智能客服知识库与回答辅助》案例中，完整推演该阶段的事实依据、盲区核验、方案三选一与决策影响天平。