外部协作接口清单用来把“谁和谁对接、交付什么、什么时候交、出了问题找谁”逐项写清楚。这份模板按基本信息、责任与沟通、交付与时间、权限与数据、变更与验收五组组织约20个字段，其中接口名称、双方组织与责任人、协作事项、交付物、计划时间、验收标准、升级路径为必填。清单可以复制到表格工具中使用，也可以落到ONES的工作项与文档中承载，便于后续更新和交接。
要点总览（TL;DR）
- 清单按“一个接口一行”组织，字段分为基本信息、责任与沟通、交付与时间、权限与数据、变更与验收五组，共23项。
- 接口编号、接口名称、双方组织与责任人、协作事项、交付物、计划交付时间、验收标准、升级路径为必填，缺失时标记“待补”再补齐。
- 责任人对结果负责，接口人负责日常对接；升级路径写到具体角色并注明触发条件与时限。
- 交付物写明名称、形式与提交渠道，验收标准写成可判定的条件，时间写到具体日期。
- 按协作类型裁剪必填项：交付型强化交付与验收，咨询型强化沟通频率，驻场与联合开发型强化权限与数据边界；清单按周核对、双周评审，变更留痕并随项目归档。
可复制空白模板：外部协作接口清单表
下表是完整的空白清单，一个外部协作接口占一行。复制到电子表格后，第一行作为表头，第二行开始逐条登记。字段按五组排列，组内顺序与后文说明、示例保持一致，便于对照填写。
| 字段分组 | 字段名称 | 填写内容 |
|---|---|---|
| 基本信息 | 接口编号 | |
| 基本信息 | 接口名称 | |
| 基本信息 | 所属项目/事项 | |
| 基本信息 | 协作类型 | |
| 基本信息 | 我方组织 | |
| 基本信息 | 对方组织 | |
| 责任与沟通 | 我方责任人 | |
| 责任与沟通 | 对方责任人 | |
| 责任与沟通 | 我方接口人 | |
| 责任与沟通 | 对方接口人 | |
| 责任与沟通 | 沟通方式与频率 | |
| 责任与沟通 | 升级路径 | |
| 交付与时间 | 协作事项 | |
| 交付与时间 | 交付物 | |
| 交付与时间 | 计划开始时间 | |
| 交付与时间 | 计划交付时间 | |
| 交付与时间 | 验收标准 | |
| 权限与数据 | 协作工具与访问权限 | |
| 权限与数据 | 数据边界与保密要求 | |
| 变更与验收 | 变更处理方式 | |
| 变更与验收 | 验收方式与确认人 | |
| 变更与验收 | 状态 | |
| 变更与验收 | 备注 |
表格共23个字段，其中“状态”用于标记待启动、进行中、待验收、已关闭等阶段，“备注”记录临时约定或例外情况。字段较多时，可以在表格工具中冻结前两列，按接口编号排序，方便查找。
字段说明：每一项填什么、怎么填
字段说明解决“知道要填，但不知道填到什么程度”的问题。以下逐项给出含义与填写口径，重点是让不同人填出来的记录可以互相比较、可以直接用于交接。
| 字段名称 | 含义 | 填写口径 |
|---|---|---|
| 接口编号 | 接口在清单中的唯一标识 | 采用“项目代号-接口序号”，如PRJ01-003；编号一经使用不再复用 |
| 接口名称 | 用一句话概括这个接口做什么 | 写“动作+对象”，如“结构件图纸交付与确认”，避免只写“对接供应商” |
| 所属项目/事项 | 接口归属的项目或业务事项 | 写项目全称或立项名称，跨项目接口注明主责项目 |
| 协作类型 | 接口的协作性质 | 从交付型、咨询型、驻场型、联合开发型中选择，用于后续裁剪字段 |
| 我方组织 | 承担接口的内部部门或团队 | 写到部门或团队层级，不写个人 |
| 对方组织 | 外部伙伴或供应商的法人或团队名称 | 写合同或协议中的正式名称，可附常用简称 |
| 我方责任人 | 对我方结果负责的人 | 写姓名与岗位，一人一岗，负责结果确认与资源协调 |
| 对方责任人 | 对对方结果负责的人 | 写姓名与岗位，需具备对交付物签字确认的权限 |
| 我方接口人 | 日常对接的固定联系人 | 写姓名与联系方式；接口人可以与责任人相同，但职责要分开理解 |
| 对方接口人 | 对方日常对接的固定联系人 | 写姓名与联系方式，变更时及时更新并通知双方 |
| 沟通方式与频率 | 双方约定的沟通机制 | 写例会周期、临时沟通渠道与响应时限，如“每周二例会，工作群2小时内响应” |
| 升级路径 | 问题无法在接口层解决时的上报路线 | 按层级写“接口人→双方责任人→项目决策人”，并注明触发条件与时限 |
| 协作事项 | 这个接口具体协作的范围 | 用条目写清做什么、不做什么，避免范围歧义 |
| 交付物 | 对方或我方需要提交的成果 | 写名称、形式与提交方式，如“结构件图纸PDF及源文件，通过指定文档库提交” |
| 计划开始时间 | 协作启动时间 | 写到日，与项目计划保持一致 |
| 计划交付时间 | 交付物应完成的时间 | 写到日；分批交付时在交付物中分别标注时间 |
| 验收标准 | 判断交付是否合格的具体条件 | 写可判定的条件，如“图纸版本与评审记录一致，尺寸标注完整率100%” |
| 协作工具与访问权限 | 双方共同使用的工具及权限范围 | 写工具名称、账号类型与可访问范围，如“文档库只读，任务看板可编辑” |
| 数据边界与保密要求 | 可共享与不可共享的数据范围 | 写数据类别、脱敏要求和保密协议编号，涉及敏感数据时注明审批人 |
| 变更处理方式 | 范围、时间或交付物变化时的处理规则 | 写提出方式、评估人、确认人和生效条件，如“书面提出，双方责任人确认后生效” |
| 验收方式与确认人 | 验收的组织方式与最终确认人 | 写评审会、书面确认或系统确认，并写明确认人姓名与岗位 |
| 状态 | 接口当前所处阶段 | 从待启动、进行中、待验收、已关闭中选择，关闭时注明关闭日期 |
| 备注 | 其他需要说明的信息 | 记录临时约定、例外情况和关联编号，保持简短 |
填写时有两个容易混淆的点需要单独说明。责任人与接口人的区别在于：责任人对结果负责，出现交付偏差时由他组织纠正；接口人负责日常信息传递和进度同步，遇到问题先由接口人沟通，沟通不畅再沿升级路径上报。升级路径要写到具体角色而不是笼统写“上级”，并给出触发条件，例如“交付延迟超过3个工作日或范围争议无法在接口层解决时，升级至双方责任人，5个工作日内未闭环再升级至项目决策人”。
必填与选填：哪些字段不能空
必填项决定这条接口记录是否具备执行条件。以下字段缺失时，清单中的该条记录应标记为“待补”，不进入执行状态。
| 类别 | 字段 | 缺失时的处理 |
|---|---|---|
| 必填 | 接口编号、接口名称、所属项目/事项 | 无法唯一识别接口，不得登记为有效记录 |
| 必填 | 我方组织、对方组织 | 无法确定对接主体，需补齐后再启动 |
| 必填 | 我方责任人、对方责任人 | 结果无人负责，不得进入执行 |
| 必填 | 协作事项、交付物 | 范围与成果不清，需先明确再登记 |
| 必填 | 计划交付时间、验收标准 | 无法判断是否按期、是否合格，需补齐 |
| 必填 | 升级路径 | 问题无上报通道，需补齐后再执行 |
| 选填 | 协作类型 | 可按默认类型处理，后续补填 |
| 选填 | 我方接口人、对方接口人 | 责任人可暂兼接口人，需在备注注明 |
| 选填 | 沟通方式与频率 | 按项目常规沟通机制执行 |
| 选填 | 计划开始时间 | 以计划交付时间倒推，可后补 |
| 选填 | 协作工具与访问权限、数据边界与保密要求 | 涉及数据共享时必须补填，纯咨询类可暂缺 |
| 选填 | 变更处理方式、验收方式与确认人 | 可按项目统一规则执行，在备注引用规则 |
| 选填 | 状态、备注 | 状态默认为待启动，备注可空 |
必填项缺失时的处理规则是：先在清单中保留该行并标记“待补”，写明补齐责任人与补齐期限，补齐后由接口人复核再改为“待启动”。这样既不会因为信息不全而丢掉接口，也能避免带着缺口进入执行。
按协作类型可以调整必填范围。交付型协作把交付物、计划交付时间、验收标准视为硬性必填；咨询型协作可以把沟通方式与频率、响应时限提升为必填，交付物可写为“咨询意见记录”；驻场型或联合开发型协作应把协作工具与访问权限、数据边界与保密要求列为必填，因为双方共享的信息范围更大。调整后的必填项应在清单说明中注明，保持全项目口径一致。
填写示例：一条完整的外部协作接口记录
以下示例为演示情景，用于说明各字段如何配合填写，不代表任何真实企业或项目。示例覆盖全部必填字段，并给出选填字段的填写方式。
| 字段名称 | 示例内容 |
|---|---|
| 接口编号 | PRJ01-003 |
| 接口名称 | 结构件图纸交付与确认 |
| 所属项目/事项 | 某设备结构开发项目 |
| 协作类型 | 交付型 |
| 我方组织 | 结构设计部 |
| 对方组织 | 某精密制造有限公司 |
| 我方责任人 | 张工，结构设计部负责人 |
| 对方责任人 | 李工，供应商项目经理 |
| 我方接口人 | 王工，结构设计工程师 |
| 对方接口人 | 赵工，供应商对接工程师 |
| 沟通方式与频率 | 每周二上午例会，工作群2小时内响应 |
| 升级路径 | 接口人→双方责任人（延迟超3个工作日触发）→项目决策人（5个工作日未闭环触发） |
| 协作事项 | 我方提供结构件图纸并组织评审；对方完成可制造性反馈并确认版本 |
| 交付物 | 结构件图纸PDF及源文件，通过项目文档库提交；可制造性反馈意见一份 |
| 计划开始时间 | 2025-03-03 |
| 计划交付时间 | 2025-03-14 |
| 验收标准 | 图纸版本与评审记录一致，尺寸标注完整率100%，对方反馈意见逐条回复并闭环 |
| 协作工具与访问权限 | 项目文档库只读，任务看板可编辑 |
| 数据边界与保密要求 | 仅共享本项目结构件图纸，不得外传；保密协议编号NDA-2025-017 |
| 变更处理方式 | 书面提出，双方责任人确认后生效，变更记录附在接口行备注 |
| 验收方式与确认人 | 评审会确认，确认人为张工 |
| 状态 | 进行中 |
| 备注 | 图纸分两批提交，第二批时间以变更记录为准 |
这条示例中，时间写到具体日期，交付物写明了名称、形式与提交渠道，验收标准给出了可判定的条件，升级路径写到了角色和触发条件。示例的适用边界是：它适用于交付型协作，且双方已签署保密协议；如果协作类型改为咨询型，交付物和验收标准需要相应改写，沟通频率与响应时限则应提升为必填。
当接口数量增多、参与方涉及多个团队时，清单本身也需要一个稳定的承载位置。ONES 方案支持打通整车、控制器、软件、测试及供应商等多角色协作过程，让需求分解、任务执行、测试反馈和变更处理在同一平台推进；接口记录可以作为工作项登记，交付物与验收记录放在关联文档中，状态变化直接反映在清单上。ONES Wiki 的页面组可关联项目，需求与文档互相对应，文档支持嵌入任务进度和各类报表，适合把接口清单与项目文档放在一起维护。对于需要长期复用的清单格式，ONES 可将标准流程、评审节点、交付物模板和过程数据沉淀为可复用资产，ONES Wiki 也支持通过模板库一键创建文档，减少每次新建清单时的重复整理。
调整与维护方法：按协作类型裁剪并定期更新
清单的价值在于持续可用，而不是填完一次就归档。字段裁剪和维护规则应在项目启动时确定，并在执行过程中按固定节奏检查。
按协作类型增减字段时，可以遵循以下规则：
- 交付型协作：保留全部交付与时间字段，强化交付物、计划交付时间、验收标准；沟通频率可简化为固定例会。
- 咨询型协作：把沟通方式与频率、响应时限设为必填，交付物改写为咨询记录或意见文档，验收标准侧重意见是否被采纳或回复。
- 驻场型协作：把协作工具与访问权限、数据边界与保密要求设为必填，并增加人员进出场时间的备注。
- 联合开发型协作：在交付型基础上增加变更处理方式和双方评审节点，验收方式写明联合评审的组织方。
更新频率与责任人方面，建议由接口人每周核对一次自己负责的接口状态和时间节点，项目负责人每两周评审一次整张清单，重点看临近交付、状态停滞和必填项待补的记录。接口人变更时，由原接口人在清单中更新联系人并通知对方，避免信息断档。
变更记录方式上，接口的范围、时间或交付物发生变化时，不在原字段上直接覆盖，而是在备注中写明变更内容、提出人、确认人和生效日期，必要时保留变更前的版本。这样在验收和复盘时可以追溯每一次调整的原因。
归档与交接方面，项目结束或接口关闭时，把状态改为“已关闭”并注明关闭日期，清单随项目文档一并归档。交接给后续团队时，重点移交仍在执行的接口、待补字段和未闭环的变更记录，确保接手人能够直接继续推进。清单的字段口径和必填规则也应随归档说明一起保存，供下一个项目复用。
常见问题
外部协作接口清单和项目计划、合同附件是什么关系？
接口清单关注外部工作协同本身：谁对接、交付什么、何时交、如何验收、出问题找谁。项目计划负责整体排期与里程碑，接口清单中的计划时间应与项目计划保持一致，但不承担排期管理职能。合同附件中的交付条款、保密协议编号可以作为清单的填写依据，清单本身不替代合同文本，也不处理采购招标与法律条款审查。
外部伙伴或供应商更换接口人时，清单怎么处理？
由原接口人在清单中更新联系人字段，并在备注中写明变更日期与接替人，同时通知对方责任人和我方责任人。如果更换发生在交付关键期，建议在当周的例会上同步一次，确认新接口人已了解协作事项、交付物和验收标准。历史记录保留在备注中，便于后续追溯。
接口数量很多时，一张清单放不下怎么办？
可以按项目或协作类型拆成多张清单，用接口编号中的项目代号区分，保持编号规则统一。拆分后需要指定一名清单汇总人，定期合并状态和待补项，避免同一接口在多张表中重复登记。字段口径和必填规则应在拆分前统一，否则不同清单之间难以对比。
清单里的验收标准和验收方式有什么区别？
验收标准回答“交付物达到什么条件算合格”，写成可判定的条件，例如图纸版本与评审记录一致、尺寸标注完整率100%。验收方式回答“由谁、以什么形式确认”，例如评审会确认、书面确认或系统确认，并写明确认人姓名与岗位。两者配合使用，前者判断结果，后者确定流程。
把接口清单放到协作平台里维护，需要注意什么？
先确认平台能承载接口记录、关联文档和状态变化三件事。以ONES为例，接口记录可以作为工作项登记，交付物与验收记录放在关联文档中，状态变化反映在清单上；ONES Wiki的页面组可关联项目，文档支持嵌入任务进度和报表，适合把清单与项目文档放在一起维护。上线前需要明确字段口径、必填规则和更新责任人，否则平台只是换了一个存放位置。
