🎯
先定使用场景
是给用户看还是给内部看，决定了字段颗粒度和更新频次。面向用户通常要更快的刷新和更友好的展示字段，面向内部则更看重完整性和可追溯，两者对同一份数据的要求可能完全不同，先分清能省掉大量返工。
启动前最常被忽略的准备工作
以下每一条都来自实际对接中反复出现的问题，建议在安排后续沟通前逐条对照。
🧑💼
预留人力维护
接入不是一次性的，字段会随业务调整，内容需要日常巡查。建议指定一位对接人负责口径确认与问题反馈，避免上线后无人跟进导致数据慢慢失真，也让问题出现时能第一时间找到责任方。
✅
约定验收口径
在联调阶段就把字段含义、异常处理和延迟上限写进验收清单，双方按同一份清单核对，后续出现分歧时有据可依，也便于排查问题出在哪一环，而不是等到上线后才发现标准不一致。
📝
需求描述要具体
把“想要实时数据”换成明确的场景描述，例如哪个页面、给谁看、多久刷新一次、异常时展示什么。描述越具体，对方越容易给出可落地的方案，也能减少来回确认的次数。
🔗
字段含义先对齐
同一个字段在不同团队里可能有不同理解，建议在开工前把每个字段的定义、取值范围和缺失时的处理方式写下来，双方确认后再进入开发，避免联调时才发现理解偏差。
🚦
异常处理要提前谈
数据延迟、来源中断、格式异常都会发生，提前约定每种情况下的降级表现和通知方式，比事后临时补救更省事，也能让使用方在异常时心里有数，不至于影响正常判断。