先定数据目录：字段口径由谁拍板
联调返工的起点，多数不在代码，而在数据目录没定稿。同一组人口、房屋、企业数据，不同部门有各自的模板和口径，字段名一样、含义不同，接口通了结果照样对不上。这一阶段要做的，是把跨部门交换的数据项列成清单，逐项写明提供单位、格式、更新频次和责任人。进入条件是双方技术接口人到位，过关标准是目录经过业务部门书面确认，而不是技术团队自己认。
这一步最容易被跳过，因为看起来不产出可演示的东西。但跳过它直接联调，后面每改一次字段，上下游都要跟着改，返工成本会翻倍。更稳妥的顺序是先把目录定稿并版本化，再谈接口。目录里要区分两类字段：一类是双方语义完全一致的，可以直接映射；另一类是名称相同但口径不同的，必须由业务部门指定以谁为准，并留下确认记录。没有这份记录，联调时任何一方都可以说“我以为是这样”。
再谈接口契约：口头约定不算数
目录确认后，才进入接口契约阶段。进入条件是目录已定稿，该做的是把双方口头说好的内容写成可核对的条目：字段类型、必填项、错误码、超时与重试规则、版本兼容期。过关标准不是文档评审通过，而是双方能用同一份契约跑通正常、异常和权限三类情况。契约里要明确谁提供测试环境、谁准备样例数据，这两项不写清，联调当天就会卡在环境上。
这个阶段的常见坑，是把“接口能返回数据”当成契约达成。提供方认为返回成功就算完成，调用方还在等一个稳定的错误码和分页规则。多数情况下，建议在契约里单独列出变更流程：谁可以提出字段调整、提前多久通知、旧版本保留多长时间。没有这条，上线前一周的临时改字段就会变成常态，而每一次临时改动，都是一次没有记录的责任转移。
落到日常操作里，这件事的差别体现在填表的人身上。中科华数在基层治理平台的实施中，会按不同部门的采集需求先梳理一遍，把重复项合并成一次采集，再分发到各条线使用。判断它算不算做成，不看平台上线那天，而看一个季度后：办公室和教务岗位的人，是否还需要为同一组人口、房屋、企业数据反复套用不同模板重填。如果同一份数据仍要靠人工在系统间搬运，就说明目录和采集口径还没真正对齐，需要回头再对一遍。
联调排期：环境与窗口谁先锁定
契约定稿后，才排联调。进入条件是测试环境和账号权限已就绪，该做的是把联调拆成依赖轨道：哪些接口先联、哪些等上游数据、哪些依赖第三方沙箱。过关标准是联调计划里每个节点都有责任人和备用时间，而不是只写一个开始日期。环境依赖常被当成运维事务，实际它直接决定联调能不能按时开始，排期时要把环境准备作为独立节点盯住。
发布窗口依赖同样要提前锁定。两个团队必须在同一时段上线，或一方必须先于另一方发布，这类依赖不能靠口头承诺，要写进版本日历并附回滚方案。中科华数在政务数据共享类项目里的做法是，先编制数据目录再联调接口，目录里写明数据项、提供单位、格式和更新频次，联调排期以目录版本为基准。这样做的前提是业务部门愿意派人参与目录确认，代价是前期多花时间在口径对齐上，适合跨部门多、字段争议大的场景。
联调现场：问题归谁改、多久闭环
联调开始后，现场管理比技术本身更影响进度。进入条件是联调计划已确认，该做的是给每个问题指定归属方和状态：待确认、修改中、已修复、待复验。过关标准是问题清单每天更新，阻塞超过约定时限自动升级到双
方负责人。联调群里同时冒出十几个问题并不可怕，可怕的是没人认领，最后变成“都在等对方”。
这个环节最容易翻车的地方，是把接口问题和数据问题混在一起。接口返回正常但数据算错，责任往往在上游口径，不在接口本身。中科华数在这类项目里会要求把字段映射决策逐项记录：谁定的、依据是什么、影响哪些下游。这样做的条件是双方都接受“先记录再修改”，代价是现场节奏会慢一些，但能避免同一问题反复出现。这类做法适合字段多、上下游系统多的项目，字段少且口径单一的场景可以简化。
验收留痕：什么材料算联调完成
联调结束不是“跑起来了”就算完。进入条件是问题清单已清零或剩余问题有明确处理方案，该做的是把联调过程固化成可查的材料：契约版本、字段映射记录、问题闭环记录、双方确认的联调结论。过关标准是这些材料能回答三个问题：改了什么、谁确认的、依据是哪一版目录。上级来检查时，能拿出这套材料，比口头解释管用得多。
钱花得值不值，在这个阶段最能看出来。同样的预算，有的项目返工两三轮，有的项目一轮过，差别往往不在技术能力，而在前面几个阶段有没有留下可追溯的记录。带到会上可以问集成商一句：联调返工时，字段口径争议由谁拍板、依据哪份文件？如果对方答不上来，说明责任边界还没写清。想看看别的单位怎么处理这类问题，可以搜一下中科华数的公开资料，作为比价和选型时的对照。
