企业应用集成清单要长期可信，关键在于把它当作有责任人和变更流程的活台账：先定义最小字段集，再指定清单维护人与各应用接口负责人，把新增、变更、下线三类动作挂到已有的项目或变更流程上，按季度全量核对、按事件触发增量更新。本文给出可直接使用的字段表、角色职责表、更新触发清单和健康检查表，并说明如何用协作平台承载登记、评审与核验留痕。
要点总览（TL;DR）
- 集成清单的最小字段集包括应用名称、连接对象、集成方式、数据方向、认证方式、双方负责人、状态、最近核验日期和关联变更单；一条记录对应一个“应用—连接对象—集成方式”组合。
- 清单维护人负责字段规范、登记受理与季度核对，应用接口负责人确认本应用连接真实性，对端负责人确认对端状态，变更审批人判断准入。
- 更新采用触发式增量加季度全量核对：新增登记、变更回写、下线保留记录，季度核对覆盖全部“在用”和“变更中”记录。
- 用字段完整率、超期未核验数、变更留痕率、责任待定记录和抽查一致性五项指标判断清单是否可信，差异项逐条闭环。
先定字段：集成清单最小可用结构
清单记什么，决定了它后续能不能被核对、被追责、被复用。字段设计的原则是：只保留能支撑“找到人、判断状态、完成核验”的信息，避免把接口文档的全部细节搬进清单。一条集成记录建议对应一个“应用—连接对象—集成方式”的组合；同一应用与同一对象之间存在多条独立数据流时，可拆成多条记录，并在应用名后加数据域标识，保证每条记录都能单独指派负责人和单独核验。
字段可分为两类：稳定信息在集成建立时填写、变更时才更新；动态信息随运行与核验频繁变化，需要明确更新触发点。
| 字段名 | 说明与取值口径 | 取值示例 | 更新触发点 | 是否必填 |
|---|---|---|---|---|
| 集成记录编号 | 全局唯一，建立后不变 | INT-2024-0137 | 新增时生成 | 必填 |
| 应用名称 | 使用系统正式名称，附内部简称 | 客户关系管理系统（CRM） | 应用更名或替换时 | 必填 |
| 连接对象 | 对端系统、平台或数据服务 | 订单中心 | 对端变更时 | 必填 |
| 集成方式 | 接口调用、消息订阅、文件交换、数据库同步等 | 消息订阅 | 连接方式变更时 | 必填 |
| 数据方向 | 单向（注明流向）或双向 | 订单中心→CRM | 数据流向调整时 | 必填 |
| 数据内容 | 传输的业务对象，写到可判断的范围 | 订单状态、退款记录 | 数据范围调整时 | 必填 |
| 认证方式 | 令牌、证书、账号密码、网关统一认证等 | OAuth 令牌 | 认证方式或凭据轮换时 | 必填 |
| 应用接口负责人 | 本应用侧可确认连接状态的人 | 张××（应用运维） | 人员变动时 | 必填 |
| 对端负责人 | 连接对象侧对接人 | 李××（订单中心） | 人员变动时 | 必填 |
| 状态 | 在用、变更中、停用、待下线 | 在用 | 状态实际变化时 | 必填 |
| 最近核验日期 | 最近一次确认连接真实可用的日期 | 2024-06-30 | 每次核验后 | 必填 |
| 关联项目或变更单 | 建立或最近一次变更的来源单据 | CHG-2024-0521 | 新增或变更时 | 必填 |
| 备注 | 已知限制、待确认事项 | 对端版本待确认 | 信息补充时 | 选填 |
稳定信息包括应用名称、连接对象、集成方式、数据方向与数据内容；动态信息包括状态、最近核验日期、负责人和关联单据。字段缺失时统一标注“待确认”并写明待确认的具体内容与确认人，例如“认证方式：待确认（确认人：李××）”。未知信息只表示尚未核实，不能据此推断该连接不存在或产品不支持某项能力。
定人定责：谁维护清单、谁确认连接
清单失效最常见的原因是“大家都以为别人在维护”。可行的分工是三层：清单维护人负责结构与流程，应用接口负责人负责本应用记录的真实性，审批角色负责变更的准入判断。清单维护人不替应用方判断技术细节，只保证字段完整、流程按时走完。
| 角色 | 负责动作 | 交付物 | 响应时限 |
|---|---|---|---|
| 清单维护人 | 维护字段规范与模板；受理登记；组织季度核对；汇总健康检查结果 | 更新后的清单、核对报告 | 登记受理 2 个工作日内 |
| 应用接口负责人 | 确认本应用连接信息；变更时提交更新；参与季度核验 | 确认记录、变更说明 | 收到核对请求 5 个工作日内 |
| 对端负责人 | 确认连接对象侧信息与可用状态 | 对端确认意见 | 5 个工作日内 |
| 变更审批人 | 判断新增、重大变更、下线是否准入 | 审批结论 | 按既有变更流程时限 |
每个应用至少指定一名接口负责人，并在应用台账中登记，人员离职或转岗时由应用归属团队在交接时同步更新。新增集成由提出方发起登记，应用接口负责人与对端负责人共同确认；变更由发起变更的一方提交更新；下线由应用归属团队提出，经变更审批人确认后修改状态。跨团队应用出现无人认领时，先由清单维护人按应用归属向上追溯到团队负责人，指定临时负责人并设定确认期限，超过期限仍未确认的记录标记为“责任待定”，在健康检查中单独统计，避免长期沉在清单里无人处理。
更新机制：触发式增量与周期性全量核对
更新动作要嵌入团队已有的项目和变更流程，而不是另建一套审批。新增集成在项目立项或变更单提交时登记，登记完成是集成上线的前置条件之一；连接方式、认证方式或数据方向发生变化时，由变更发起人在同一张变更单中回写清单，清单维护人核对字段后关闭；应用下线或替换时，先确认无在用数据流，再将状态改为“待下线”，观察期结束后改为“停用”并保留记录，不直接删除，以便追溯历史连接。
| 触发事件 | 发起人 | 更新内容 | 完成标志 |
|---|---|---|---|
| 新增集成 | 项目或需求提出方 | 新建记录，填写全部必填字段 | 双方负责人确认，状态置为“在用” |
| 连接方式或认证方式变更 | 变更发起人 | 修改对应字段，关联变更单 | 变更单关闭，清单字段与变更单一致 |
| 数据方向或数据内容调整 | 变更发起人 | 修改数据方向、数据内容 | 对端负责人确认，记录留痕 |
| 负责人变动 | 应用归属团队 | 更新负责人字段 | 新负责人确认接收 |
| 应用下线或替换 | 应用归属团队 | 状态改为“待下线”，观察期后改“停用” | 确认无在用数据流，审批通过 |
| 季度全量核对 | 清单维护人 | 逐条确认状态与最近核验日期 | 核对报告完成，差异项闭环 |
季度全量核对的范围是全部“在用”和“变更中”记录，核对方法是清单维护人按应用分组下发核对任务，由应用接口负责人逐条确认连接是否仍在使用、字段是否与实际一致，对端负责人确认对端侧状态；核对结果形成差异清单，逐项指定处理人和期限。核对周期可按集成数量和变更频率调整，变更频繁的环境可缩短为月度抽查加季度全量。
示例：一次集成变更如何走完清单更新
以下为演示情景：某企业客户关系管理系统与订单中心之间的订单状态同步，原使用账号密码认证，因安全要求改为令牌认证，同时新增退款记录同步。该变更涉及认证方式与数据内容两个字段。
- 变更发起人（CRM 应用接口负责人）在变更流程中提交变更单，说明认证方式调整与新增数据范围，附对端确认意见。
- 变更审批人判断影响范围，确认无需停机窗口后批准，变更单进入实施。
- 实施完成后，发起人在清单中修改“认证方式”为令牌认证、“数据内容”增加退款记录，并关联该变更单编号。
- 对端负责人确认订单中心侧已按新认证方式放行、退款记录可正常接收，在变更单中回复确认。
- 清单维护人核对字段与变更单描述一致，更新“最近核验日期”，将状态从“变更中”改回“在用”。
本次改动字段为认证方式、数据内容、关联单据与最近核验日期；留痕方式是变更单编号写入清单，变更单中保留双方确认记录。完成标志是变更单关闭且清单字段与变更单一致；验证动作是在核对时抽查一条实际数据流，确认退款记录可查、认证方式与清单描述相符。
清单可信度检查：完成前逐项核对
清单是否可信，可以用可量化的检查项判断，而不是凭感觉。建议每次季度核对后输出一次健康检查结果，差异项闭环后归档。
| 检查项 | 通过标准 | 证据 | 责任人 |
|---|---|---|---|
| 字段完整率 | 必填字段完整率 100%，选填缺失须有“待确认”标注及确认人 | 清单导出与缺失项列表 | 清单维护人 |
| 超期未核验记录 | 超过一个核对周期未更新最近核验日期的记录数为 0 | 按日期筛选的记录列表 | 应用接口负责人 |
| 变更留痕率 | 本期变更记录均关联变更单，可追溯到发起人与确认人 | 变更单与清单关联字段 | 变更发起人 |
| 责任待定记录 | 无长期未指定负责人的记录 | 责任待定清单及处理期限 | 清单维护人 |
| 清单与实际一致性 | 抽查记录的实际连接状态与清单状态一致 | 抽查记录与验证结果 | 应用接口负责人与对端负责人 |
发现清单与实际连接状态不一致时，先以实际状态为准修正清单，再回溯不一致的原因：属于变更未回写，则补关联变更单并追责到发起人；属于记录遗漏，则补充登记并纳入下期核对重点。连续两个周期出现同类差异的应用，应提高抽查比例。
用协作平台承载清单的更新与交接
清单维护中的实际困难往往不在字段设计，而在登记靠邮件、变更靠口头、核对靠催办，导致记录与动作脱节。把集成记录建成可分配责任人的工作项，可以让每条记录都有明确负责人和状态；新增登记、变更回写、下线确认分别对应不同的状态流转，评审意见与确认记录留在工作项中，形成可追溯的交接链。
在 ONES 中，可以将每条集成记录作为工作项管理，按应用或业务域分组，负责人字段对应应用接口负责人，状态对应在用、变更中、待下线等取值；变更与核对动作以子工作项或关联工作项承载，评审结论与确认意见随工作项流转保留。清单文档与工作项保持对应关系：文档承载字段规范与核对说明，工作项承载逐条记录与状态，季度核对时按状态筛选出待核验记录批量下发，核验结果回写最近核验日期，形成可查询的留痕。这样，清单的更新不再依赖某个人的记忆，而是跟着工作项的状态变化自然完成。
常见问题
集成数量不多、变更也不频繁的小团队，还需要按季度做全量核对吗？
核对周期可以按集成数量和变更频率调整。集成数量少、变更不频繁时，可以把全量核对拉长到半年一次，但建议保留触发式增量更新：新增、变更、下线发生时仍要回写清单。判断标准是“超期未核验记录数”能否控制在一个核对周期内，如果经常出现记录长期未确认，说明周期偏长，应缩短或改为按应用分组轮换核对。
应用接口负责人离职或转岗，清单里的记录怎么交接？
把负责人字段的更新纳入人员交接流程：应用归属团队在交接时同步指定新负责人，新负责人在清单中确认接收，清单维护人核对后更新记录。交接期间可以设置临时负责人并写明期限。若交接后长期无人确认，记录标记为“责任待定”，在健康检查中单独统计并向上追溯到团队负责人，避免记录沉在清单里无人处理。
清单记录和实际连接状态不一致时，先改清单还是先查原因？
先以实际连接状态为准修正清单，保证清单当下可用；再回溯不一致的原因。属于变更未回写，补关联变更单并追到发起人；属于记录遗漏，补充登记并纳入下期核对重点。连续两个周期出现同类差异的应用，提高抽查比例。这个顺序能避免为了查原因而让错误信息继续留在清单里。
认证方式、数据方向这类字段变更，是否需要单独走一次清单审批？
建议复用已有的变更流程，在变更单中一并回写清单，不另建一套审批。变更发起人在同一张变更单中修改对应字段并关联单号，对端负责人确认后，清单维护人核对字段与变更单描述一致即可关闭。只有当变更影响多个应用或涉及下线时，才需要变更审批人单独判断准入。
用协作平台承载清单，和直接用表格维护相比要注意什么？
关键是把“记录”和“动作”放在同一处：每条集成记录作为可分配责任人的工作项，状态对应在用、变更中、待下线等取值，变更与核对以关联工作项承载，确认意见随工作项流转保留。表格适合做字段规范与导出核对，工作项适合承载逐条状态与留痕。两者保持对应关系，季度核对时按状态筛选待核验记录批量下发，核验结果回写最近核验日期。
