图纸类：架构与映射
架构图要标出系统边界与调用方向，字段映射表要写清源字段、目标字段、转换规则与责任人。缺映射表，后期口径争议无从对证，补做时又要重新梳理一遍数据，后续复核时也无从下手逐项核对，也便于交接。
契约类：接口与错误码
接口清单含版本、协议、频率与配额；错误码表含含义、处理建议与重试策略。没有错误码体系，联调只能靠猜，排障时间会随系统数量线性增长，协作成本很高，新人上手所要花费的时间也要更久，交接更省力。
控制类：权限与灰度
权限矩阵写清账号、角色与可访问范围；灰度方案写清批次、观察指标与回滚触发条件。这两份文件是上线评审的必备材料，缺一份评审通常不会通过，新人上手也更慢，事后补做的代价也会更高，评审也更顺。
证据类：联调与压测
联调记录要含用例、输入、输出与结论；压测记录要含并发、时延与瓶颈。只写联调通过不算证据，出问题时也无法还原当时的条件，复盘只能靠回忆，事后补做代价更高，出了问题责任也就难以界定，复盘也更实。
运维类：监控与手册
监控要覆盖接口失败率、时延、重试堆积与数据一致性偏差；手册要写清值班、升级路径与常见故障处置。没有手册，上线后第一个故障就会打给开发，责任也无法界定，运维交接其实也不算完成，交接也更实。
适用与不适用
适合谁
- 需要向信息中心与业务方共同交付的集成项目
- 多厂商协作、责任界面需要书证的场合
- 上线后需自行运维的企业，且有运维值班安排
不适合谁
- 一次性数据迁移、无长期运行要求的任务
- 内部试验性质、不进入生产环境的集成
典型场景
某集团 OA 与合同系统的集成验收，信息中心按清单逐项核对，发现缺少错误码表与回滚脚本，暂缓验收。补齐后做了一次回滚演练，确认十分钟内可恢复，才通过并进入运维交接，验收结论也已归档，并把清单同步给运维团队。
可执行步骤
- 按九类清单核对交付物的完整性、版本与签收人，逐项打勾，并留签收单，并复制一份
- 抽查字段映射表与接口契约，确认两者完全一致，并记录差异，形成书面记录
- 验证权限矩阵，做纵向与横向的越权访问测试，留存测试记录，并留档备查
- 执行一次回滚演练，记录耗时与失败点，并复盘改进，形成记录，记录回滚耗时
- 确认监控告警可以触发后，完成运维交接，明确值班人，并做交接，并留值班表
常见坑
- 只交代码不交文档，运维阶段没人敢动，故障只能等原班人马回来处理，响应时间不可控，故障响应很被动。
- 接口文档与实现不一致，联调靠口头解释，每次变更都要重新问人，知识无法沉淀，换人就要重学，知识也留不住。
- 压测只测正常请求，限流与超时场景未覆盖，高峰期直接雪崩，事后也找不到瓶颈，容量规划也缺依据。
- 监控配了但没设告警阈值，故障发生几小时后才被用户发现，排查窗口已经错过，用户信任也受损。
自检与验收清单
- 九类交付物是否齐全、版本一致并有人签收，且有签收单
- 映射表与接口契约是否一致并有版本号，且有版本号
- 越权测试是否覆盖检索、导出与直连接口，且有记录
- 回滚演练是否完成并记录耗时与失败点，且有结论
- 告警是否实测触发并有人接收，处置有记录，且可复查
常见问题
接口文档用什么格式？
常见用 OpenAPI 描述同步接口，异步消息写清主题、结构与消费约定。格式次要，关键是版本可追溯、与实现同步更新，并有明确的维护人，格式本身并不重要，能对上实现就可以，也便于接手。
验收要不要做压力测试？
涉及峰值业务时要。至少测试目标并发下的时延与失败率，并观察上游系统承压情况，避免集成把源系统拖垮，也能提前发现配额与连接数不足，避免上线后触发限流，也更稳。
上线后出问题谁负责？
按责任界面划分：集成链路问题由集成方处理，源系统自身缺陷由原厂商处理。责任矩阵应在验收前确认，避免故障时互相推诿，也便于快速定位到责任方，减少相互推诿，也更省事。