这个季度要还技术债，还是要继续交新功能？
团队评估显示当前结构已拖慢迭代，但业务方本季度的功能承诺已经对外公布，两条路线需要同一批人力。
- 01结构问题已拖慢迭代
- 02功能承诺已对外公布
- 03两条路线共用同一批人力
- 04技术债影响稳定性与排期
你会选择哪一种决策？
先做选择，再展开每条路径的判断。键盘按 1–4 作答。
查看这条路径的判断
推荐路径
让还债跟着功能一起走，而不是等一个专门窗口。代价是每个功能都会慢一点，但稳定性改善持续发生，也不会挤掉已承诺的交付。
🎯 评审反诘 · 项目立项评审委员会「该推荐路径在保证业务确定性的同时，把大模型用在了最具杠杆价值的核心环节。如何量化并向管理层证明 ROI？」
PM 论据：以最小的工程研发复杂度锁定 90%+ 的核心诉求，风险完全隔绝在可控沙箱内，交付确定性最高。
查看这条路径的判断
有条件成立
结构改善最彻底，但把已公布的功能承诺推迟，外部信任受损，代价由业务方与客户关系承担。
⚖️ 评审反诘 · 业务运维 Leader「这套方案只在特定理想条件下成立。如果前置依赖（如网络质量、向量切片准确度或并发负载）发生波动，降级预案是什么？」
PM 审视：不可把假设当成事实。必须在前置方案中明确定量成立指标，并随附故障回退 Runbook。
查看这条路径的判断
有条件成立
交付承诺不违约，但结构问题继续累积，后续每次迭代更慢，把成本以更高的排期压力转嫁给未来团队。
⚖️ 评审反诘 · 业务运维 Leader「这套方案只在特定理想条件下成立。如果前置依赖（如网络质量、向量切片准确度或并发负载）发生波动，降级预案是什么？」
PM 审视：不可把假设当成事实。必须在前置方案中明确定量成立指标，并随附故障回退 Runbook。
查看这条路径的判断
高风险路径
两个目标都没守住：人力被排满后还债最先被牺牲，功能也只能勉强交付，最后两边都欠着。
⚡ 评审反诘 · 技术架构师 / 风控评审人「该方案明显引入了不可控的不确定性、调用延迟与接口成本。一旦长尾样本发生幻觉或服务超时，由谁对业务资损与客诉担责？」
PM 审视：切忌盲目“为 AI 而 AI”，确定性问题坚持规则优先，高风险链路必须设置安全熔断阀。
该选项在实际业务中存在盲区或隐性风险。已为你自动归集，随时可前往攻坚专区专项消灭。
不只记答案，记住判断方法
答完后展开
技术债与交付冲突时，把还债切成随迭代持续发生的小项，代价是每期速度略降，换取结构不再恶化。
- 01还债能否拆成小项
- 02每期分配多少人力
- 03不还债的后果多久显现
PM 落地
如果你是产品经理，下一步做什么
把还债拆成可验收的小项并入迭代计划，写明每期人力占比、结构改善指标与迭代验收方式。
想在真实业务场景中看本题的落地推演？
在《智能客服知识库与回答辅助》案例中，完整推演该阶段的事实依据、盲区核验、方案三选一与决策影响天平。