插件替代能力清单要回答一个具体问题：原插件承担的工作，在目标平台由什么能力承接、怎样确认承接得住。清单以“插件识别—能力拆解—替代映射—验证结论”为主线，逐项记录插件用途、触发对象与时机、输入输出、字段与状态映射、权限范围、接口方式、替代方案和验证结论。下面给出一张可直接粘贴到表格工具的空白模板，并说明每列口径、必填取舍、完整示例与后续维护方法。
要点总览（TL;DR）
- 插件替代能力清单按“插件识别—能力拆解—替代映射—验证结论”四组列组织，核心是逐项记录原插件做了什么、目标平台用什么承接、凭什么判断承接成立。
- 插件名称、插件用途、触发对象、替代方案、验证结论五项为必填，缺失任一项该行不能作为替代依据；其余字段按插件类型和推进阶段补充。
- 填写时一行只描述一个“插件—场景”组合，字段名和状态值与源系统保持一致，未确认的能力统一标注“待查证”。
- 清单随验证进度更新状态与结论，按版本存档；数据搬运归研发数据迁移与映射清单，平台日常配置归配置与治理文档。
可复制空白清单模板
将下表表头复制到 Excel、在线表格或文档表格中，每个插件占一行；同一插件涉及多个触发场景时拆成多行，用“插件名称+场景编号”区分。列顺序按四组排列：前四列识别插件，中间五列拆解能力，随后四列做替代映射，最后三列记录验证与备注。
| 序号 | 插件名称 | 插件用途 | 使用团队/场景 | 触发对象 | 触发时机 | 输入 | 输出 | 涉及字段与状态 | 权限范围 | 接口/集成方式 | 替代方案 | 替代类型 | 差异与待补项 | 验证方法 | 验证结论 | 负责人 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
填写时保持一行只描述一个“插件—场景”组合。若一个插件同时服务于需求评审和发布检查两个场景，应写成两行，分别记录触发时机与验证结论，避免把不同场景的替代判断混在一起。
字段说明：每一列记录什么
字段口径的核心是区分三类信息：原插件做了什么、目标平台用什么承接、凭什么判断承接成立。三类信息分列记录，后续复核时才能看出差异出在能力缺失还是配置未完成。
插件识别类字段
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 序号 | 行编号 | 按插件清单顺序编号，便于跨表引用 |
| 插件名称 | 插件在市场或内部系统中的正式名称 | 写全称，同名插件注明来源或版本区间 |
| 插件用途 | 插件解决的具体问题 | 用一句话写“谁在什么环节用它完成什么”，不写功能罗列 |
| 使用团队/场景 | 实际使用范围和业务场景 | 写团队名称或场景名，用于判断替代优先级 |
能力拆解类字段
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 触发对象 | 插件作用的工作项类型、页面或文档 | 写具体对象，如“缺陷工作项”“需求文档页”，不写“所有内容” |
| 触发时机 | 插件在哪个流程节点生效 | 写事件或状态，如“状态变更为已解决时”“页面保存后” |
| 输入 | 插件运行所需的数据或人工操作 | 列出关键输入项，字段名与源系统一致 |
| 输出 | 插件产生的结果 | 写结果形态：写入字段、生成记录、发送通知、返回校验结果等 |
| 涉及字段与状态 | 插件读写或依赖的字段、状态值 | 逐项列出字段名和状态值，作为后续映射的依据 |
| 权限范围 | 插件运行所需的角色与数据权限 | 写清谁可触发、可读写哪些数据，是否跨项目 |
| 接口/集成方式 | 插件与外部系统的连接方式 | 写 API、Webhook、页面嵌入或纯配置，注明对接系统 |
替代映射与验证类字段
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 替代方案 | 目标平台承接该能力的方式 | 写具体能力或接口名称，并说明配置要点；一项能力不足以承接时分行列出组合方案 |
| 替代类型 | 替代的等价程度 | 从“原生等价、组合实现、接口自建、暂无法承接”中选一项 |
| 差异与待补项 | 替代后仍存在的差距 | 写清差异点和补足方式，未确认的内容标注“待查证” |
| 验证方法 | 确认替代成立的操作 | 写可执行的验证动作，如“在测试项目复现触发条件，核对输出字段值” |
| 验证结论 | 验证后的判定 | 写“通过、有条件通过、未通过、待验证”，有条件通过需在备注写明条件 |
| 负责人 | 该行替代评估的责任人 | 写姓名或角色，便于推进和复核 |
| 状态 | 该行在替代推进中的阶段 | 从“待评估、评估中、待验证、已验证、已上线”中选一项 |
| 备注 | 补充信息 | 记录待查证事项、临时方案和关联工单编号 |
必填与选填的划分
必填字段的判断标准是：缺少它，清单就无法支撑替代决策或无法复核。插件名称、插件用途、触发对象、替代方案、验证结论五项缺失时，这一行不能作为替代依据使用，应视为未完成。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 插件名称 | 必填 | 清单的检索主键，缺失则无法与插件使用记录对应 |
| 插件用途 | 必填 | 决定替代方案是否对准真实需求，防止按功能名误判 |
| 触发对象 | 必填 | 界定替代能力的适用范围，缺失则无法验证 |
| 替代方案 | 必填 | 清单的核心结论，缺失则该行没有决策价值 |
| 验证结论 | 必填 | 区分“计划替代”和“确认可替代”，缺失则结论不可信 |
| 触发时机 | 选填 | 事件型插件必填；纯展示型插件可写“不适用” |
| 输入、输出 | 选填 | 涉及数据写入或校验的插件建议填写，纯界面增强类可简写 |
| 涉及字段与状态 | 选填 | 涉及字段读写、状态流转时必填；仅做展示时可省略 |
| 权限范围 | 选填 | 跨项目或涉及敏感数据的插件必填 |
| 接口/集成方式 | 选填 | 对接外部系统的插件必填，纯配置类可省略 |
| 替代类型、差异与待补项 | 选填 | 建议填写，用于排序替代优先级和识别风险 |
| 验证方法 | 选填 | 结论为“通过”时建议补写，便于他人复核 |
| 负责人、状态、备注 | 选填 | 进入推进阶段后建议补齐，用于跟踪进度 |
最低通过线可以定为：每一行五项必填字段齐全，且验证结论不为空；进入开发或配置阶段的行，还需补齐触发时机、涉及字段与状态、替代类型三项。整张清单的完成度按“必填齐全行数÷总行数”计算，低于全部齐全时不进入替代实施排期。
填写示例：一条插件的完整记录
以下示例为演示情景，用于说明字段之间的对应关系，不代表任何具体插件的实际兼容结论。
| 字段 | 填写内容 |
|---|---|
| 序号 | 07 |
| 插件名称 | 缺陷关联用例检查插件（示例名称） |
| 插件用途 | 测试人员在缺陷关闭前，检查该缺陷是否已关联至少一条测试用例，未关联则阻止关闭 |
| 使用团队/场景 | 质量团队，版本发布前的缺陷收尾环节 |
| 触发对象 | 缺陷工作项 |
| 触发时机 | 缺陷状态由“修复中”变更为“已关闭”时 |
| 输入 | 当前缺陷的关联用例列表、操作人角色 |
| 输出 | 校验通过则允许状态变更；不通过则阻断并提示“请先关联测试用例” |
| 涉及字段与状态 | 字段：关联用例；状态：修复中→已关闭 |
| 权限范围 | 测试角色可触发校验，开发角色只读关联结果 |
| 接口/集成方式 | 插件内调用用例库接口读取关联关系 |
| 替代方案 | 用目标平台的流程自动化配置状态流转校验，配合测试管理模块的用例关联字段；校验规则在流程配置中实现 |
| 替代类型 | 组合实现 |
| 差异与待补项 | 原插件的提示文案为自定义，替代后使用平台默认提示；阻断条件是否支持“至少一条”的数量判断，待查证 |
| 验证方法 | 在测试项目创建缺陷，不关联用例直接关闭，观察是否阻断；关联一条用例后再次关闭，观察是否放行 |
| 验证结论 | 有条件通过 |
| 负责人 | 质量团队接口人 |
| 状态 | 待验证 |
| 备注 | 数量判断条件待查证，查证后更新“差异与待补项”和“验证结论” |
示例中“待查证”的处理方式是：在差异列写明不确定点，在验证结论中给出“有条件通过”，并在备注记录查证动作。这样清单不会把未确认的能力写成确定结论，后续复核也有明确入口。
清单的调整与维护方法
清单在替代推进中会持续变化，维护的重点是让每一行的状态和结论始终反映最新验证结果，避免用旧结论安排新工作。
按团队与插件规模裁剪列
插件数量少于十项、且均为纯配置类时，可以合并“输入”“输出”为一列，省略“接口/集成方式”。涉及外部系统对接、跨项目权限或字段级校验的插件，保留全部列。裁剪只减少选填列，五项必填字段始终保留。团队分工较细时，可增加“评估人”“复核人”两列，替代单一的“负责人”列。
状态更新与版本维护
建议按以下节奏维护：
- 每次验证后当天更新该行的“验证结论”和“状态”，并在备注写明验证日期和验证环境。
- 替代方案发生调整时，保留原方案描述并追加新方案，注明调整原因，便于回溯判断依据。
- 每周按“状态”列汇总一次，把“待验证”行分配给具体负责人，避免长期停留在评估中。
- 整张清单按版本存档，文件名或表头注明版本号和更新日期，替代上线后冻结对应版本。
当替代评估涉及多个团队协作时，可以把清单中的每一行作为一项工作任务纳入项目管理工具跟踪。以 ONES 为例，其方案支持先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配，并提示对企业已有定制场景逐项评估，避免直接假设所有插件都能一一对应。落到清单维护上，可以把每行插件记录建成工作项，用状态字段对应“待评估、评估中、待验证、已验证”，把验证记录沉淀在 Wiki 文档中，使清单结论与推进状态保持同步。
与其他清单的边界划分
本清单只记录插件行为与能力的承接关系。记录数据的搬运与字段级映射，归入研发数据迁移与映射清单；目标平台的日常配置规范与治理规则，归入平台配置与治理文档。三类清单通过“序号”和插件名称互相引用，不把数据迁移细节或配置规范写进本清单，避免一张表承担过多职责而难以维护。
常见问题
一个插件同时服务多个流程节点，清单里应该写一行还是多行？
按“插件—场景”组合拆行。同一插件在需求评审和发布检查两个节点生效时，写成两行，分别记录触发时机、输入输出和验证结论。这样每行的替代判断独立成立，复核时能定位差异出在哪个节点。若两个节点的替代方案完全相同，也建议保留分行，用“插件名称+场景编号”关联，避免后续一处调整牵动整行结论。
替代方案暂时无法确定时，这一行怎么处理？
先把已确认的信息填齐：插件名称、用途、触发对象照常填写，替代方案列写明候选方向或“待评估”，验证结论填“待验证”，并在备注记录需要查证的问题和计划动作。这类行不计入必填齐全行数，不进入替代实施排期。等候选方案明确后再补替代方案与验证方法，避免用推测结论占位。
验证结论写“有条件通过”时，条件应该记在哪里？
条件写在“差异与待补项”列，写清差异点和补足方式；备注列记录条件的确认人和确认时间。例如数量判断规则尚未确认，就在差异列写明该判断待查证，备注记录查证计划。条件消除后，同步更新差异列和验证结论，保留原记录并注明变更日期，便于回溯判断依据。
清单里的字段与状态映射，和数据迁移清单有什么区别？
本清单记录的是插件行为依赖哪些字段和状态值，用于判断目标平台能否在相同节点触发等价校验或动作，属于能力承接判断。历史记录如何搬运、字段值如何逐条转换，归研发数据迁移与映射清单。两张表通过序号和插件名称互相引用：本清单给出“需要承接什么”，迁移清单给出“数据怎么搬过去”。
替代上线后，清单还需要继续维护吗？
上线后冻结对应版本作为存档，不再改动结论列。后续若目标平台调整流程配置或接口，另起新版本记录变更，注明触发变更的原因和影响行。日常只需保留检索入口，供新成员了解原插件的承接关系。这样既保留历史判断依据，也避免旧结论被误用于新的评估。
