用决策点代替日历
每个阶段结束必须回答一个是非问题：值不值得做、能不能做到、集成量多大、能不能上线。回答不了说明阶段没完成，排期表上的日期只是参考值，不能当作进度已完成的证据，更不能据此向管理层报喜。
诊断期不能省
诊断阶段产出场景清单、数据盘点与可行性判断，通常需要两到四周。省掉它直接进开发，等于把最贵的不确定性留到后面，一旦返工，整个排期与预算都要重排，业务方也很难再给第二次机会，团队信心同样受损。
原型期按问题数计
原型不是固定周期，而取决于要验证几个问题。验证一个问题通常一周左右，问题越多周期越长；把原型写成两周包干，往往验证不充分就被推进到开发，风险原样保留，只是往后挪了一个阶段并放大数倍。
开发期由集成数量决定
业务逻辑本身的工作量有限，真正决定工期的是要对接几个系统、每个系统的鉴权与联调窗口。按系统数量而非功能点估算工期，更接近真实情况，也便于向管理层解释为什么不能简单按功能数量压时间。
试运行要有退出条件
试运行阶段要预设观察指标与退出条件：达到什么标准转全量、出现什么情况回退。没有退出条件的试运行会被无限延长，最后变成既不上线也不下线的悬置状态，团队成员被逐步抽走，项目自然停摆。
适用与不适用
适合谁
- 需要向管理层承诺上线时间的项目
- 多方参与、需要对接多个系统的交付项目
- 首次做 AI 项目、缺少排期经验的团队，需要外部支持
不适合谁
- 希望用固定总价包干全部不确定性的采购
- 业务方无法在项目期内安排联调与验收的项目
典型场景
某能源企业的设备台账问答项目计划十周上线。诊断两周后判定可行，原型三周验证了台账抽取的准确率，开发阶段因需对接两个老系统延长到五周。项目组把试运行从两周压到十天，但保留退出条件与回退方案，最终按期上线，未出现大面积错答。
可执行步骤
- 按四个决策点拆分阶段，逐段写明要回答的问题、判定标准与责任人，作为阶段评审依据
- 诊断阶段完成场景排序与数据盘点，形成一页结论提交决策会拍板，作为下一阶段输入
- 原型阶段限定要验证的问题数量，逐个结案后再决定是否进入开发，不再整体推进
- 开发阶段按对接系统数量估算工期，并提前锁定每个系统的联调窗口，避免反复等待
- 试运行前设定转全量标准、观察窗口与回退条件，书面同步给业务方，避免口径反复变动
常见坑
- 用总工期倒推各阶段，诊断被压成三天，问题在开发阶段集中爆发，返工代价成倍上升，预算很快见底。
- 原型没有结论就进入开发，做到一半发现数据不足，只能边补数据边改方案，越改越乱，工期彻底失控。
- 低估鉴权审批与联调窗口，把两周的等待算作零工期，实际进度与计划严重脱节，管理层逐渐失去耐心。
- 试运行不设退出条件，验收会一拖再拖，团队被抽调去做别的项目，项目最终烂尾，责任也说不清；后续也没人复盘。
自检与验收清单
- 每个阶段是否写明要回答的问题与判定标准，并指定判定人
- 诊断是否产出场景排序、数据盘点与可行性结论
- 原型阶段要验证的问题是否已列全并逐个结案
- 工期估算是否按对接系统数量拆分并留出缓冲
- 试运行是否有转全量标准、观察窗口与回退条件
常见问题
能不能三个月全量上线？
单场景、单系统对接、数据条件较好的项目有可能，但需要诊断与原型并行且业务方随时配合。多系统对接或数据需整理的场景，压到三个月通常以牺牲验收为代价，后续补救周期更长，也更容易反复。
里程碑付款怎么设？
建议按诊断、原型、开发、试运行四个节点设置交付物与付款比例，试运行节点保留较高比例，用于约束上线后的稳定性与交接质量，避免交付方在系统可用之前就提前退场，后续无人响应。
延期了怎么处理？
先区分原因：需求变更走变更单并调整排期，供应商原因按合同约定处理。无论哪种，都建议保持每周一次的进度同步，避免到节点当天才发现偏差，那时可调整的空间已经很小，双方也容易情绪化。