契约段：两到三周
产出接口清单、字段映射与错误码表，完成双方技术确认。此段结束的标志是契约签字，不是文档写完；没签字就进联调，后面必然反复改字段，联调等于白做，后续的联调工作只能靠反复试错推进，评审也难通过。
联调段：两到三周
按用例逐条验证，含异常路径。联调常因上游环境未就绪而空转，建议先要到可用的测试环境与测试账号，再约定联调窗口，避免每天开会等环境，白做还要重排，联调窗口也就更难约得上了，只能等。
灰度段：约两周
影子运行或小批量放量，逐日比对数据一致性。灰度期要设观察指标与停止条件，出现偏差立即回退，而不是边修边放量，否则问题会被平均值掩盖，时间都耗在等环境上，回退也要预留出时间，回退也更从容。
全量与移交：一两周
全量切换后进入稳定观察，完成监控交接、值班安排与运维培训。移交完成的标志是客户方能独立处置常见告警，而不是文档签收完毕，两件事差别很大，回退要能在当天完成，培训也要留时间，交接也更顺利。
缓冲放在上游
把时间缓冲加在接口改造与账号审批上，而不是压缩测试。压缩测试省下的时间，通常会在上线后以故障形式还回来，还会影响业务方对项目的评价，培训也要排进计划，也给业务方留出预期，预算也更好批。
适用与不适用
适合谁
- 跨多个厂商、接口改造量大的集成项目
- 有明确上线窗口、需要倒排计划的企业
- 上线后不能停机、必须平滑切换的业务系统
不适合谁
- 单接口、单系统的小型集成，无需多方协调
- 允许长时间停机、无窗口约束的内部系统
典型场景
某集团的合同系统集成排了九周：契约三周、联调三周、灰度两周、移交一周。因上游接口改造延期一周，项目组动用预留在上游的缓冲，仍未推迟原定上线日，灰度期按日比对数据一致性，并复盘了这一次的延期主要原因，结论也站得住。
可执行步骤
- 按五段拆解工期，标注每段的完成标志与签字人，写进一页计划，并存一份
- 识别关键路径，确认上游改造与账号审批排期，标出最长等待项，并留书面记录
- 把缓冲预留在上游，不压缩测试与灰度时间，也不占移交时间，并写明上限
- 为灰度设观察指标、停止条件与回退触发线，并指定决策人，并写入计划，并留副本
- 移交前做一次客户方独立处置告警的演练，记录处置耗时，并留存记录，并抄送甲方
常见坑
- 契约未签字就联调，字段反复变更，测试用例全部重写，联调窗口被迫延长，测试覆盖明显不足，测试也不充分。
- 把缓冲加在开发侧，上游一延期就全线崩，只能砍测试，质量风险随之上升，上线后的故障变多，质量难以保证。
- 灰度期边修边放量，问题被稀释后集中爆发，回退更麻烦，影响范围更大，团队处理起来也很被动，客户也会抱怨。
- 移交只交文档，客户方遇告警仍不会处理，故障响应还得靠原班人马，值班形同虚设，客户体验受损。
自检与验收清单
- 五段是否各有完成标志与签字人，并留档，且有版本
- 关键路径与上游排期是否确认，有书面记录，且有记录
- 上游缓冲是否预留并写入计划，比例合理，且有额度
- 灰度停止条件与回退线是否明确，有人决策，且有回退
- 客户方能否独立处置常见告警，已演练，且有时点
常见问题
能不能压缩到四周？
接口标准化、单系统、数据量小时可以。但需砍掉灰度观察期或改为影子运行，并在上线后加强监控，风险相应上升，需要业务方书面确认，风险也需要书面确认清楚才行，也更稳妥。
联调环境一直不就绪怎么办？
先用模拟服务或契约桩推进开发，同时由客户方推动上游排期。把等待时间记为风险项纳入周报，避免到期才发现，也能为后续变更谈判留下依据，也便于后续界定责任，也更从容。
上线窗口怎么选？
避开月结、关账、大促与年度审计期。窗口确定后倒排灰度与联调时间，并把变更禁令写入项目计划，避免上线前一周才被通知禁止操作，也便于向业务方交代清楚原因，也更省心。