迁移能力等价性评审要回答的是：源平台上的工作流、状态、字段、权限、插件与接口，在目标平台能否产生同样的业务结果。评审以行为结果而非功能名称判定等价，把每项能力拆到可单独验证的颗粒度，逐项写明源端行为、目标端承载方式、判定标准、结论和证据，由业务、平台、测试三方共同确认。本文给出判定口径、拆解方法、操作步骤、角色分工、填写示例与收口检查，记录数据的搬运与字段映射不在讨论范围内。
要点总览（TL;DR）
- 等价性按行为结果判定：同一输入和操作下，两端产生的业务结果是否一致，差异是否被业务方接受，功能同名不能作为等价依据。
- 能力项按工作流、状态语义、字段规则、权限、插件与接口六类拆解，颗粒度以能对应至少一条可观察的验证动作为准。
- 评审按能力盘点、逐项映射、编写验证用例、评审会、签字与遗留项登记五步推进，每步都有输入、输出和完成标志。
- 结论归入完全等价、差异可接受、需要改造、暂不支持四类，每类绑定对应证据，差异可接受项需业务方书面确认。
- 收口以清单无空白结论为前提，关键流程或核心权限存在未确认差异时作为阻断项，不进入迁移实施。
先定评审口径：等价性按什么标准判定
等价性评审最容易出现的偏差，是把“目标平台也有同名功能”当成等价。功能名称相同，触发条件、流转结果或权限效果可能不同。判定口径应统一为：在给定输入和操作下，源端与目标端产生的业务结果是否一致，以及差异是否被业务方接受。评审开始前先把这条口径写进评审说明，后续所有能力项都按同一标尺判定。
每项能力的结论归入四类，避免出现“基本可以”“大致相同”这类无法跟踪的表述：
| 结论 | 含义 | 必要证据 |
|---|---|---|
| 完全等价 | 源端行为在目标端可完整复现，业务结果一致 | 验证用例执行通过记录 |
| 差异可接受 | 存在行为差异，但不影响业务规则或已有替代操作方式 | 业务方书面确认差异内容 |
| 需要改造 | 目标端当前无法承载，需配置调整或二次开发 | 改造方案、责任人与计划完成时间 |
| 暂不支持 | 目标端暂无对应能力，需替代方案或接受遗留风险 | 替代方案说明或风险登记记录 |
能力项清单建议固定以下字段，保证不同人填写的记录可以横向比对：能力项编号与名称、所属类别、源端行为描述、目标端承载方式、判定标准、结论、证据位置、责任人、备注。字段一旦确定，评审过程中只补充内容，不临时增删字段，否则汇总时会出现口径不一。
评审范围限定在行为与能力是否等价承载。记录数据的搬运、字段值映射、历史数据清洗属于另一条工作线，由数据迁移映射流程处理；目标平台上线后的日常配置与治理也另立流程。把这两块混进等价性评审，会让清单膨胀且结论难以收口。
拆解能力项：工作流、状态、字段、权限、插件与接口
拆解的颗粒度以“可单独判定等价”为准：一条能力项应能对应至少一条可观察的验证动作。拆得过粗，结论只能写成笼统的“流程可用”；拆得过细，评审成本会迅速上升。实际操作中，可以先按六类能力各列一层，再把其中影响业务规则的部分展开为独立条目。
工作流
逐条记录节点构成、流转条件、分支判断、并行会签、回退与撤回规则。重点在条件表达式和边界情况：某类工单金额超过阈值时走哪条分支，并行节点是否要求全部通过，驳回后回到上一节点还是发起节点，已提交未审批时能否撤回。这些行为在两端往往表现不同，需要单独成项。
状态语义
状态名称相同不代表语义相同。每条状态要写清准入条件、准出条件、由谁触发、触发后产生什么动作。例如“已解决”在源端可能要求填写解决方案字段才能进入，在目标端可能只是普通状态值。状态语义项应与工作流项交叉核对，避免流程等价但状态规则缺失。
字段规则
除字段本身是否存在，还要记录必填条件、默认值来源、字段间联动、校验规则和计算公式。联动和公式是差异高发区：某字段选择特定值后才显示另一字段，或工时、金额由多个字段计算得出，这类规则需要逐条验证计算结果与显示逻辑。
权限
按角色、可见范围、操作权限、审批权四个维度拆解。需要确认的是：某角色能看到哪些工作项、能执行哪些操作、能否审批特定环节。权限项常与工作流节点绑定，拆解时注明关联节点，评审时一并验证。
插件与接口
先梳理源平台实际在用的插件和集成，再逐项记录扩展点、触发时机、调用方式和数据方向。接口类能力项要写明是目标端主动推送还是接收回调、触发条件是什么、失败后如何处理。定制化插件场景需要单独评估，不能假设存在一一对应的替代。
操作步骤：从能力盘点走到评审签字
评审按五步推进，每步都有明确输入、动作、输出和完成标志，避免评审会开成漫谈。
第一步：能力盘点
输入为源平台配置导出（工作流定义、字段配置、权限方案、插件清单）和业务访谈记录。动作是逐类整理能力项初稿，标注每项的业务用途和使用频率。输出为能力项初稿清单。完成标志是六类能力均有覆盖，且每项都能对应到具体业务场景。
第二步：逐项映射
输入为能力项初稿和目标平台的配置能力说明。动作是为每项填写目标端承载方式，能确认的直接写明，无法确认的标注“待验证”并注明需要验证的点。输出为带映射结果的能力项清单。完成标志是所有条目都有承载方式描述，待验证项已列出清单。
第三步：编写验证用例
输入为映射后的能力项清单。动作是为每项至少设计一条可观察的验证动作，写明前置数据、操作步骤和预期结果。例如验证驳回回退，需要构造一条处于审批中的工单，执行驳回，观察其落回节点与通知对象。输出为验证用例集。完成标志是每个能力项都有对应用例，待验证项优先安排执行。
第四步：评审会
输入为能力项清单和验证用例执行结果。动作是业务、平台、测试三方按条目逐项过结论，当场确认或标记争议项，争议项指定补充验证的负责人。输出为带初步结论的评审记录。完成标志是所有条目均有结论或明确的补充验证安排，不遗留无归属的争议。
第五步：签字与遗留项登记
输入为评审记录。动作是差异可接受项由业务方签字确认，需要改造项登记责任人与期限，暂不支持项登记替代方案或风险。输出为签字版能力等价性清单和遗留项台账。完成标志是清单无空白结论，遗留项均有跟踪人。
在这套流程中，能力项清单、验证用例和评审记录需要被持续维护并保持版本一致。ONES 的项目工作项可以按能力项建立条目并分配责任人，评审记录与验证证据可沉淀在 ONES Wiki 文档中，使清单状态与评审结论在同一处更新，减少会前会后多份表格对不上的情况。
角色分工与交付物
评审会变成泛泛讨论，通常是因为角色职责没有落到交付物上。以下分工按能力项清单的填写与确认环节划分。
| 角色 | 主要职责 | 交付物 | 签字责任 |
|---|---|---|---|
| 业务负责人 | 确认状态语义、流程规则和权限设置是否符合实际业务 | 业务规则确认意见、差异可接受项的书面确认 | 对差异可接受结论签字 |
| 平台配置负责人 | 填写目标端承载方式，评估改造工作量与可行性 | 承载方式说明、改造项工作量与计划 | 对需要改造项的方案签字 |
| 测试或质量角色 | 设计并执行验证用例，提供可复核的证据 | 验证用例集、执行记录与证据 | 对完全等价结论的证据有效性签字 |
| 迁移项目负责人 | 组织评审、汇总结论、跟踪遗留项与阻断项 | 签字版清单、遗留项台账、评审纪要 | 对清单完整性和收口结论签字 |
角色可以兼任，但签字责任不宜合并到同一人。业务确认与平台评估由同一人完成时，差异可接受结论缺少独立复核，后续出现业务争议时难以追溯。测试角色的证据应指向具体用例和执行记录，而不是口头说明“已验证”。
示例：一条审批流能力的等价性评审记录
以下为演示情景，用于说明清单填写方式，不指向任何具体产品的实际迁移结果。
| 字段 | 填写内容 |
|---|---|
| 能力项 | 工单多级审批与驳回后回退 |
| 源端行为 | 工单提交后依次经过直属主管、部门负责人两级审批；任一级驳回后回到提交人，修改后重新从第一级开始；审批中提交人可撤回 |
| 目标端承载方式 | 以两级审批节点配置流转；驳回动作设置为回到发起节点；撤回通过发起人操作权限控制 |
| 判定标准 | 驳回后落回节点正确、重新提交后审批顺序正确、撤回后状态与通知符合预期 |
| 验证用例 | 用例1：构造审批中工单，部门负责人驳回，检查落回节点与通知对象；用例2：修改后重新提交，检查是否从直属主管重新开始；用例3：审批中执行撤回，检查状态与审批人待办是否清除 |
| 结论 | 差异可接受：驳回回退与重新提交行为一致；撤回后源端会保留撤回记录，目标端以操作日志体现，业务方确认可接受 |
| 证据 | 三条用例执行记录及截图，存放于评审文档对应条目下 |
| 责任人 | 平台配置负责人填写承载方式，测试角色提供执行记录，业务负责人确认差异 |
这条记录的关键在于把“审批流可用”拆成了驳回、重新提交、撤回三个可观察行为，结论才有依据。若验证发现重新提交后从第二级继续审批，则该条应改判为需要改造，并登记改造责任人与期限。
完成检查：评审可以收口的条件
评审收口以清单完整和风险可控为前提，逐项核对以下检查项：
- 所有能力项均有四类结论之一，不存在空白或“待定”条目；
- 需要改造项已登记责任人、改造方案和计划完成时间；
- 差异可接受项均有业务方书面确认，确认内容写明差异点；
- 验证用例已执行并留存证据，未执行的已列入执行计划并注明时间；
- 暂不支持项已登记替代方案或遗留风险，并指定跟踪人；
- 遗留风险清单已汇总，包含风险描述、影响范围、跟踪人和复查时间。
存在阻断项时不得收口：关键业务流程存在未确认的行为差异，或核心权限的可见范围与操作权限尚未验证，应继续补充验证，不进入迁移实施阶段。阻断项解除后，由迁移项目负责人更新清单状态并重新确认收口结论。评审收口意味着能力等价性已有可追溯的结论，后续实施中的配置调整仍应回到清单中更新对应条目，保持结论与实际情况一致。
常见问题
源平台和目标平台功能名称相同，还需要单独做等价性评审吗？
需要。功能名称相同只说明两端都有这类能力，触发条件、流转结果和权限效果仍可能不同。评审时按行为结果判定：给定输入和操作，两端产生的业务结果是否一致。例如两端都有“驳回”动作，源端驳回后回到发起人，目标端回到上一节点，这就是需要记录并判定的差异。名称相同的能力项同样要写清源端行为、目标端承载方式和验证用例，不能因为名称一致就跳过。
评审中发现某项能力目标端暂时无法承载，应该怎么处理？
先把该项结论标为“暂不支持”，登记替代方案或遗留风险，并指定跟踪人。如果这项能力涉及关键业务流程或核心权限，应作为阻断项，暂不收口，继续补充验证或等待改造方案明确。替代方案要写明业务上如何绕行、影响哪些角色、持续多久；遗留风险要写明影响范围和复查时间。结论和证据一并留在清单中，后续目标端能力补齐时回到对应条目更新状态。
验证用例由谁编写，业务方需要参与执行吗？
验证用例通常由测试或质量角色编写和执行，平台配置负责人提供目标端配置说明，业务负责人确认预期结果是否符合业务规则。业务方不必逐条执行用例，但应参与预期结果的确认，尤其是状态语义、审批顺序和权限可见范围这类与业务规则直接相关的条目。执行记录和证据由测试角色留存，作为“完全等价”结论的依据。
评审收口后，实施阶段又发现行为差异怎么办？
回到能力项清单更新对应条目，重新判定结论并补充证据。若差异影响关键流程或核心权限，需要重新组织相关角色确认，必要时暂停相关配置上线。清单是持续维护的记录，收口结论对应的是评审时点的验证结果，实施中的配置调整应同步反映到条目状态，避免清单结论与实际配置脱节。
插件和接口类能力项在评审中容易漏掉什么？
常见遗漏是只记录了插件名称，没有写清扩展点、触发时机、调用方式和数据方向。接口类能力项要区分目标端主动推送还是接收回调，失败后如何处理。定制化插件需要单独评估，不能假设存在一一对应的替代。评审前先梳理源平台实际在用的插件和集成清单，再逐项拆解，避免按插件市场列表笼统盘点。
