先定编号与归档
两套系统各自生成编号，是衔接失败的头号原因。先定一套编号规则，明确问题号、决议号与整改号的格式与生成方，再定归档路径与文件命名。规则定不下来，接口做得再多，数据仍然对不上，最后还得人工合并。编号怎么定是衔接的前提。
三条路径的代价
一是文件导入导出，改造成本最低，适合先跑通；二是单向接口，把巡检 App 的数据同步到记录系统，适合点位固定的项目；三是双向打通，效果最好但联调周期长、责任界面复杂，建议字段稳定后再考虑。三条路径怎么选看现状。
只做单向同步
会议纪要与巡检记录应以一方为主数据源，另一方只读。双向写回容易出现同一条问题在两处被改，最后谁是真的说不清。需要回写的只限状态字段，例如已整改、已复查，且必须带操作人与时间。边界是只写状态不改正文。
复核节点要一致
系统衔接后，签认与复核节点必须对齐，否则会出现 OA 里已批、记录系统里还挂着未确认。做法是把签认动作集中在一个系统完成，另一个系统只展示结果，避免同一个人在两处签两次、责任却说不清。怎么集中签认要一次定好。
适用与不适用
适合谁
- 已上 OA 或安全巡检 App 的施工企业
- 多项目并行、需要统一记录口径的集团
- 有信息部门可配合接口联调的单位
不适合谁
- 尚无任何电子系统、全靠纸质台账的项目
- 希望一次改造把所有系统替换掉的单位
典型场景
某总包已有 OA 会议模块与安全巡检 App。项目先统一问题编号与归档路径，把巡检 App 的数据按固定格式导出，再导入记录系统生成纪要附件；OA 只保留审批与签认，不再重复维护问题台账。三个月后，同一问题在两处对不上的情况基本消失。
可执行步骤
- 逐一盘点现有系统里与会议、巡检相关的模块，列出各自的数据出口与字段
- 统一问题号、决议号与整改号的编码规则，并指定唯一的系统作为编号生成方
- 先用文件导入导出的方式把字段跑通，再评估是否值得为同步开发接口联调
- 同步只写已整改、已复查等状态字段，并同时记录操作人、来源与操作时间
- 把签认动作集中在主系统中完成，另一个系统只负责只读展示与结果查询
常见坑
- 两套系统各自生成编号，同一个问题出现两个版本，越同步越混乱，最后只能靠人工逐条合并。
- 一开始就追求双向打通，联调拖了半年仍未稳定，业务侧早已回到手工台账，项目实质停摆。
- 签认在两个系统里各做一次，责任人对哪一次有效说不清楚，出了事互相推诿，留痕形同虚设。
- 接口只同步字段不同步附件，照片在另一边打不开，复查时还要回到原系统里翻找，效率很低。
自检与验收清单
- 问题、决议与整改编号是否共用同一套编码规则
- 是否指定唯一的系统作为编号生成方，并留存记录
- 同步范围是否限于状态字段，不覆盖正文与附件
- 签认动作是否只在一个系统内完成，并在该系统留痕
- 附件与照片是否随记录一并同步，且可正常打开
常见问题
已有巡检 App 还要不要新建系统？
不必。若现有 App 能导出结构化数据，可先以它为主数据源，记录系统只做汇总与纪要生成。新建系统的前提是现有 App 无法满足编号、权限或复查要求，否则只是增加一套要维护的系统。
OA 审批流能不能直接复用？
多数可以。把签认节点映射到 OA 已有流程，减少一套账号与权限体系。需要注意的是 OA 通常不承载照片与检查项，这类内容应留在记录系统，OA 只记录审批结论与时间。
接口开发要多久？
取决于字段数量与对方系统开放程度。只同步状态字段的单向接口，通常几周可完成；涉及附件、权限与历史数据迁移的双向接口，往往需要数月。建议先用文件方式验证字段，再决定是否投入。