研发平台插件接入前，评估工作要落到三份可签字的产物：权限清单、维护责任矩阵、接入评审记录。本文按“定边界—评权限—分责任—做评审—看示例—过检查”的顺序，说明每份产物填什么、由谁确认，以及什么条件下可以放行。
要点总览（TL;DR）
- 接入前先写一页插件边界说明，列清调用场景、数据对象与接口清单，再据此展开权限、数据、兼容、维护四板块评估清单。
- 权限清单按“对象—动作—身份—范围—有效期—回收方式”逐条接口填写，敏感数据与跨项目访问单独审批，授权到期前重新评审。
- 维护责任矩阵用 RACI 明确每类动作的唯一最终责任人，并约定版本兼容、缺陷修复、安全补丁的响应时限与升级路径。
- 评审记录写明结论、遗留风险、复核时点与签字人；上线首月复核一次，接口变更、权限扩大或责任方变更时触发重新评估。
- 放行前逐项核对检查表，权限范围不明、动作无责任人、授权无回收路径、评审缺签字均属阻断项。
接入前先定插件边界与评估清单
评估的起点是写清楚插件做什么、碰哪些数据、在哪些环节被调用。边界不清，后面的权限和责任都会失焦：一个“同步需求状态”的插件和一个“读取全部项目数据做报表”的插件，授权范围和维护投入完全不同。建议在接入申请阶段先产出一页边界说明，由插件提出方撰写，平台管理员确认。
边界说明应包含四项内容：插件解决的具体业务问题；调用场景，即在哪些页面、流程节点或定时任务中触发；涉及的数据对象及读写方向，例如读取需求单、写入任务状态、同步附件；以及插件运行所依赖的平台接口清单。接口清单不必写到参数级，但要覆盖全部调用入口，后续权限表以此为底稿逐项展开。
在边界说明基础上，形成四板块评估清单，作为整个接入评估的目录：
| 板块 | 要回答的问题 | 主要产物 | 提出方 | 确认方 |
|---|---|---|---|---|
| 权限 | 插件以什么身份、读写哪些对象、授权多久、如何回收 | 权限清单 | 插件提供方 | 平台管理员 |
| 数据 | 涉及哪些数据对象，是否含敏感信息，是否跨项目 | 数据范围说明 | 插件提供方 | 数据或安全负责人 |
| 兼容 | 依赖哪些接口版本，平台升级时如何跟进 | 兼容性说明 | 插件提供方 | 平台管理员 |
| 维护 | 故障谁修、补丁谁打、何时下线 | 维护责任矩阵 | 插件提供方与业务使用方共同拟定 | 平台负责人 |
清单的提出方通常是插件提供方（内部团队或外部供应商），确认方是平台侧对应角色。四板块全部有结论后，才进入评审环节；任一板块空白，视为评估未完成。
权限评估：从身份、范围到回收
权限评估的目标是填出一张可核对的权限表，核心字段为：对象、动作、身份、范围、有效期、回收方式。逐条接口调用填写，而不是按插件整体给一个笼统授权。
身份是第一个判断点。插件调用接口通常有三种方式：以操作用户身份调用，权限随用户走，适合需要体现“谁操作谁负责”的场景；以服务账号调用，权限固定且独立于个人，适合定时同步等后台任务；以应用凭证调用，由平台签发凭证并限定可访问的资源。选择哪种身份，取决于插件是否需要区分用户、是否在无人值守时运行。服务账号和应用凭证的权限往往比个人账号更宽，更需要限定范围。
范围划分遵循最小权限：只读的接口不申请写权限；只涉及单个项目的插件，授权限定在该项目而非全空间；需要写状态的，明确可写哪些字段、哪些状态流转。对敏感数据（如人员信息、附件内容、审批记录）和跨项目访问，单独列出并说明必要性，由数据负责人逐项确认，不能夹在普通读写权限中一并通过。
有效期与回收路径要在接入时就写定。建议为插件授权设置明确期限，到期前由平台管理员发起续期评审，续期时重新核对范围是否仍然必要。回收路径包括：插件下线时撤销凭证、服务账号停用、授权范围收回；插件提供方变更时，原凭证作废并由新责任方重新申请。权限变更（扩大范围、新增数据对象、更换身份类型）应触发通知与再评审，通知对象至少包括平台管理员和业务使用方。
| 对象 | 动作 | 身份 | 范围 | 有效期 | 回收方式 |
|---|---|---|---|---|---|
| 需求单 | 读取 | 服务账号 | 指定项目 | 12个月 | 下线时停用账号 |
| 任务状态 | 写入 | 服务账号 | 指定项目、限定状态字段 | 12个月 | 撤销写权限 |
| 附件 | 读取 | 应用凭证 | 按需申请，单独审批 | 6个月 | 凭证作废 |
表中每一行都应有对应的接口调用依据，评审时能回答“这个权限被哪段逻辑使用”。无法说明用途的权限项直接删除，这是控制授权膨胀最有效的一步。
维护责任矩阵：角色、动作与时限
权限解决“能做什么”，维护责任解决“出问题谁处理、多久处理”。插件生命周期内的维护动作至少包括：版本兼容跟进、缺陷修复、安全补丁、文档更新、下线执行。每类动作需要唯一责任人，避免出现“双方都以为对方负责”的空档。
角色通常分三类：插件提供方，负责插件本身的代码、配置与文档；平台管理员，负责平台接口的稳定性、变更通知与接入规范；业务使用方，负责提出需求、验收效果并承担使用层面的配合。用 RACI 形式填写时，每类动作只有一个 A（最终负责），R 为执行者，C 为需咨询方，I 为需知会方。
| 维护动作 | 插件提供方 | 平台管理员 | 业务使用方 | 响应时限 |
|---|---|---|---|---|
| 版本兼容跟进 | A/R | C（提供变更说明） | I | 平台发布变更说明后10个工作日内完成适配评估 |
| 缺陷修复 | A/R | C | I | 影响主流程的缺陷2个工作日内响应，一般缺陷按约定排期 |
| 安全补丁 | A/R | C（通报风险） | I | 高危漏洞24小时内响应并给出处置方案 |
| 文档更新 | A/R | I | C | 功能变更随版本同步更新 |
| 下线执行 | R | A（决策与执行平台侧回收） | C | 决策后按约定窗口完成 |
平台接口变更时的通知与适配责任要单独写明：平台方在变更前发出通知并说明影响范围，插件提供方在约定时限内完成适配评估与改造，业务使用方知会受影响范围。争议与故障升级路径同样要落到人：一线由插件提供方值班响应，超时未处理升级至平台负责人，涉及数据安全的问题直接升级至安全负责人。时限数值应结合团队实际约定，上表为可参照的填写结构。
接入评审与上线后的复核机制
评审会的作用是把前几节的评估结果变成一个有签字、有结论的决定。参与角色至少包括平台管理员、插件提供方负责人、业务使用方代表；涉及敏感数据时增加数据或安全负责人。准入条件是：边界说明、权限清单、维护责任矩阵三份材料齐全，且四板块清单无空白项。
评审记录应包含：插件名称与版本、评估材料清单及版本、结论（通过、有条件通过、不通过）、遗留风险及对应缓解措施、复核时点、签字人与日期。“有条件通过”必须写清条件内容和完成期限，例如“附件读取权限在三个月内改为按需申请，否则收回”。
上线后设置观察期，建议首月内完成一次复核，核对实际调用是否与权限清单一致、是否出现未申报的接口调用、故障响应是否达到时限。此后按固定周期（如每半年）复核一次。触发重新评估的条件包括：平台接口发生不兼容变更、插件申请扩大权限或新增数据对象、插件提供方或维护责任人变更、发生安全事件。下线与回退的决策人应事先指定，通常为平台负责人，回退方案需在接入时一并确认。
评估结论的流转可以借助研发平台自身承载：把权限清单、责任矩阵和评审记录作为工作项附件或文档归档，评审结论以任务状态推进，复核时点设为到期提醒。ONES 提供 API 接口用于与企业系统集成，并支持基于开放性做功能拓展，插件接入涉及的接口调用与评审记录可以在同一平台内留痕，便于后续复核时追溯。
示例：一个需求同步插件的评估过程
以下为演示情景，用于说明四步评估如何填写，不代表任何真实项目。
场景与边界。某团队开发一个需求同步插件，把研发平台中的需求单同步到内部项目管理系统，每小时执行一次，单向读取需求标题、描述、负责人和状态，不写回研发平台。涉及数据为指定项目的需求单，不含附件与评论。
权限清单填写。对象为需求单，动作为读取，身份为服务账号（后台定时任务，无需区分用户），范围为两个指定项目，有效期为12个月，回收方式为插件下线时停用服务账号。因不涉及写操作和敏感字段，未申请附件与人员信息权限。
责任矩阵填写。版本兼容跟进由插件提供方负责，平台接口变更后10个工作日内完成适配评估；缺陷修复由插件提供方响应，影响同步中断的问题2个工作日内处理；文档更新随版本同步；下线由平台管理员决策，插件提供方执行停用与数据清理。业务使用方负责验收同步结果的准确性。
评审结论与复核。评审结论为通过，遗留风险为“同步延迟可能超过一小时”，缓解措施为在内部系统标注数据更新时间。复核安排为上线后一个月首次复核，此后每半年一次；触发条件为平台需求接口变更或同步范围扩大至新项目。
完成检查：接入前必须确认的事项
放行前逐项核对以下条目，全部为“是”才允许接入：
- 权限清单覆盖边界说明中列出的全部接口调用，无未申报调用；
- 每一项权限都能说明对应功能用途，敏感数据与跨项目访问已单独审批；
- 授权有效期与续期方式已写明，回收路径可执行；
- 维护责任矩阵中每类动作都有唯一最终责任人，响应时限已约定；
- 平台接口变更的通知与适配责任已写入矩阵；
- 评审记录已签字留存，遗留风险有缓解措施和完成期限；
- 复核时点与重新评估的触发条件已写入评审记录；
- 下线与回退的决策人已指定，回退方案已确认。
出现以下任一情况应阻断接入：权限范围无法说明或存在未申报调用；任一维护动作找不到责任人；授权没有回收路径；评审记录缺失签字。阻断项解决后重新提交评审，不在接入后补办。
常见问题
插件只读取数据、不写回平台，权限评估可以简化吗？
读取同样需要评估，只是字段重点不同。只读插件仍要写清读取哪些对象、哪些字段、覆盖哪些项目，以及是否包含附件、人员信息、审批记录等敏感内容。只读权限的风险集中在数据外流和范围过大，建议把授权限定在必要项目，敏感字段单独申请并说明用途，有效期照常设定。示例中的需求同步插件就是只读场景，仍完整填写了对象、身份、范围、有效期和回收方式。
插件提供方是外部供应商时，维护责任矩阵要怎么调整？
角色名称不变，但要把合同或服务协议中的条款对应到矩阵里。版本兼容跟进、缺陷修复、安全补丁通常仍由插件提供方承担最终责任，响应时限应与其服务承诺一致；平台管理员负责接口变更通知和接入规范；业务使用方负责验收与使用配合。供应商更换时，原凭证作废、责任方重新登记，并触发一次再评审。矩阵中每个动作只保留一个最终责任人，避免平台方与供应商互相等待。
平台接口升级导致插件暂时不可用，责任和时限怎么约定？
接入时就在矩阵中写明：平台方在变更前发出通知并说明影响范围，插件提供方在约定时限内完成适配评估与改造，业务使用方知会受影响范围。若升级造成主流程中断，按缺陷修复的时限响应，并走升级路径——一线由插件提供方值班处理，超时升级至平台负责人。适配期间是否暂停插件调用、是否回退到人工流程，由事先指定的下线与回退决策人判断。
评审结论为“有条件通过”时，条件没按期完成怎么办？
“有条件通过”必须在评审记录中写清条件内容、完成期限和验证方式，例如“附件读取权限三个月内改为按需申请”。到期由平台管理员核对，未完成的按约定处置，常见做法是收回相关权限或暂停插件调用，而不是继续默认放行。条件完成情况记入复核记录，作为下一次续期评审的依据。
评估材料放在哪里，复核时怎么追溯？
关键是让材料有版本、有归属、有到期提醒。可以把边界说明、权限清单、责任矩阵和评审记录作为工作项附件或文档归档，评审结论用任务状态推进，复核时点设为到期提醒。ONES 提供 API 接口用于与企业系统集成，并支持基于开放性做功能拓展，插件接入涉及的接口调用与评审记录可以在同一平台内留痕，便于后续复核时追溯。具体授权模型与接口变更策略，建议在评审时向平台方确认。
