蔓延从哪里来
联调中发现源系统缺陷、业务方临时加报表、安全评审要求补权限体系、厂商要求顺带升级版本。这些都会被说成一起做了，工作量却成倍增加，工期也随之失控，客户也会对整个集成失去信心，也更省事。
接口清单封版
第一版接口清单签字后封版，新增接口走变更评审，评估工作量与对里程碑的影响。没有封版，联调范围会随每次会议扩大，最后没人说得清交付边界，结算时也说不清，最后验收时也缺少凭据，也好交差。
源系统改造归客户方
源系统缺陷修复、字段新增、版本升级属于其厂商责任，应写入客户方工作项并由客户方推动。集成方可以做适配，但不承担原厂商的产品责任，这条要提前说明，实施方也不敢再承诺交付进度，也更省心。
口头承诺要回签
会上答应的临时方案，当天写进纪要并请对方确认。几周后无人记得细节时，纪要是唯一凭据，也是结算与验收时最有力的一份材料，否则边界会一再后退，双方团队也会逐渐失去耐心与彼此的信任。
范围与验收绑定
验收清单只覆盖封版范围，超出部分另立变更单。把范围与付款节点绑定，扩张才有真实成本，团队也才有理由对新增说不，比口头解释更有效，也更容易追责，团队在评审会上也更有底气说不，也更从容。
适用与不适用
适合谁
- 多厂商协作、责任界面复杂的集成项目
- 联调中不断被加需求的团队，需要硬边界
- 上线窗口固定、不能延期的系统改造
不适合谁
- 单接口、范围天然有限的轻量集成，需硬边界
- 客户方已明确接受开放式范围的情形
典型场景
某项目在联调中被要求顺带把源系统的一个历史缺陷修掉。集成方评估后出具变更单：修复需原厂商介入，工期增加两周。客户方选择先上线主流程，缺陷另立工单，上线未延期，双方在纪要上逐条确认，作为后续结算与争议处理的依据。
可执行步骤
- 首版接口清单签字后封版，并留存版本号，同步给所有厂商，并留版本记录
- 新增需求走变更评审，评估工作量与工期影响，由双方签字，并抄送客户，并登记
- 把源系统改造列入客户方工作项并指定推动人，写明时限，并写进合同，并公示
- 所有口头方案当天进纪要，并请对方回签，抄送项目经理，并在当周回签，并存档
- 验收只覆盖封版范围，超出部分另立变更单，单独计价，避免默认包含，并留底稿
常见坑
- 碍于情面答应顺手改，工期被拖长一个月，成本无人承担，预算与信任双输，后续再谈变更也更难，团队士气也受影响。
- 变更只在群里说，结算时无法举证，只能吃哑巴亏，团队也很被动，客户同样不满意，后续协作也更难推进。
- 替源系统厂商修缺陷，责任边界彻底模糊，后续问题都会找上集成方，运维成本随之上升，团队也会疲于应付。
- 验收时把新增内容也算进去，双方对完成标准各执一词，付款卡住，项目迟迟无法收尾，双方信任受损。
自检与验收清单
- 接口清单是否已封版并留存版本，可追溯，且可追溯
- 每次变更是否都有书面评估与签字，且有时限，且有留档
- 源系统改造是否单列并指定推动人，且有推动人
- 会议纪要是否回签留档，可检索与归档，且可检索
- 验收范围是否与合同一致，逐条对照，且有附件，且可核对
常见问题
客户要求免费加接口怎么办？
先评估工作量与影响，再给出两个选项：延期或另立变更单。把选择权交给对方，比直接拒绝更容易推进，也能让范围扩张变得可见，后续也有据可依，也能减少后续反复沟通成本。
安全评审提出的整改算范围外吗？
通常属于必要整改，应纳入范围但需评估工期。建议在合同里预留安全整改的工时比例，避免临时压价或压缩测试，给上线留下隐患，避免事后扯皮，评审时也更从容一些，也更省心。
厂商不配合改接口谁负责？
由客户方按合同向其厂商主张。集成方可提供技术证据与替代方案，但不承担对第三方的管理责任，这一点应在项目启动会上说清，减少误解与返工，也能减少无效返工，也更顺。