先写出一条能验收的数据流
“把两个系统打通”无法直接开发。改成一条具体规则：客户系统新增有效客户后，将客户编号、简称和联系人同步到订单登记工具；订单工具的内部备注保留；停用客户不删除历史订单。这个示例只做单向同步，解决重复录入客户资料的问题。
再指定触发方式：由操作员点击同步、每天定时运行，还是源系统变化后通知。三种方式对及时性和排错记录的要求不同，应选满足业务需要的一种，不把“实时”写成没有期限和异常策略的口号。
字段对应表要写到空值和覆盖条件
| 源字段→目标字段 | 转换规则 | 空值或冲突处理 |
|---|---|---|
| 客户编号→外部客户编号 | 按文本原样保存，用作匹配键 | 缺失时不新建；重复时待核对 |
| 客户简称→显示名称 | 去除首尾多余空格 | 源值为空不覆盖，列入异常 |
| 联系人→联系人 | 源系统负责维护 | 清空须有明确的清空动作，不能靠缺少字段推断 |
| 有效状态→可选客户状态 | 有效可用于新订单；停用不再新增选择 | 未知状态不按有效处理 |
| 无→内部备注 | 目标系统独立维护 | 同步不修改 |
客户C001已经存在时，用外部客户编号找到记录，不按简称匹配。若目标已有两条C001，先解决重复记录；不能选第一条继续覆盖。字段名只是示例，实际应同时提供接口字段名与业务名称。
接口材料不只有一个地址和账号
请提供接口文档、测试环境、可调用的操作范围、脱敏请求与响应样本、认证有效期及接口联系人。由系统所有者确认读取和写入权限；凭据通过约定的安全渠道配置，不塞进需求文档、截图或日志。
列表接口还要说明翻页方式、排序、筛选条件和调用限制。Microsoft的API设计文档介绍了分页返回机制，因此“一次请求成功”不等于“取到了全部客户”。例如测试数据有三页，要证明末页也被读取，并记录本批次采用的数据截止点，避免运行中不断变化的数据被误当作固定全集。
把“没收到成功响应”留作独立状态
写入请求超时，可能是对方没有收到，也可能是对方已保存但响应丢失。不要立即标成失败并反复新增。先根据业务编号或请求编号查目标结果；接口支持请求去重时，按其文档使用相同请求标识重试。
Microsoft文档指出，POST和PATCH不保证重复调用无额外副作用。实际项目应查看目标接口的具体约定，约定不清就把记录列入“结果待确认”，由操作员核查。重试次数再多也不能替代重复规则。
用六个样本决定是否可以进入开发
- 全新C001：新建一次，能回查源编号与目标编号。
- 同一C001再次同步：不新增第二条，只执行允许的更新。
- 源联系人清空：按事先写定的清空规则处理。
- 目标出现两个C001：停止该条，输出冲突原因。
- 数据跨三页：每页纳入一次，总数能与来源核对。
- 写入后模拟响应中断：核查既有结果，避免重复创建。
业务负责人能给出这些样本的预期结果，技术人员能取得对应权限和接口响应，才具备开始实施的基础。缺少其中一项，应补齐具体材料或缩小第一期范围，例如先做可核对的导出导入。