扩展能力重建要解决的是旧平台上的插件、脚本、自动化规则、自定义字段和审批流在新平台上如何继续发挥作用。做法可以归纳为五步：盘清旧扩展、按价值与依赖排序、逐条确定承接方式、在测试环境重建并对照验证、灰度切换后收尾。本文聚焦扩展行为与能力的重建过程，记录数据本身的搬运属于数据迁移范畴，上线后的日常配置维护与权限治理属于平台配置治理范畴，不在本文展开。
要点总览（TL;DR）
- 扩展能力重建分五步：盘清旧扩展、按价值与依赖排序、逐条确定承接方式、测试环境重建并对照验证、灰度切换后收尾。
- 盘点要覆盖插件、脚本、自动化规则、自定义字段、审批流、Webhook 和定时任务，每条登记触发条件、执行动作、影响对象、调用方、负责人与使用频率。
- 排序先重建被多个流程依赖的基础规则，再处理末端自动化；功能重叠的合并，价值低的取消并留记录。
- 承接方式分原生工作流与自动化、低代码或脚本扩展、外部系统集成三类，无法直接承接的先设计降级方案与人工兜底。
- 验证用同一组输入分别跑旧规则与新规则，比对触发、动作、通知与异常处理；切换按批次灰度，设定回退条件，旧规则归档后才算完成。
先盘清旧平台里到底有哪些扩展在跑
重建的第一步是拿到一份可核对的旧扩展台账。盘点范围要覆盖七类对象：插件、脚本、自动化规则、自定义字段、审批流、Webhook 和定时任务。插件和脚本往往由个别成员私下维护，最容易在盘点中漏掉，建议同时查一遍平台管理后台的启用列表、服务器或任务计划中的脚本、以及各项目管理员手中的配置记录，三处交叉核对。
每条扩展至少登记以下字段，缺一项都会给后续映射留下盲区：
| 字段 | 记录内容 | 用途 |
|---|---|---|
| 名称 | 扩展的正式名称与所在项目 | 唯一标识，避免同名混淆 |
| 触发条件 | 什么事件或时间点触发，如“缺陷创建时”“每周一 9 点” | 判断新平台能否用原生触发器承接 |
| 执行动作 | 触发后具体做了什么，如改字段、发通知、调用接口 | 映射到新平台的动作类型 |
| 影响对象 | 涉及的工作项类型、字段、人员或外部系统 | 评估影响面与验证范围 |
| 调用方 | 哪些流程、人员或其他扩展依赖它 | 识别基础规则与末端自动化 |
| 负责人 | 当前维护人或业务归属人 | 确认价值、签字验收 |
| 使用频率 | 近三个月触发次数或人工使用次数 | 排序依据之一 |
登记完成后，把每条扩展标为三类状态之一：仍在用、已废弃、无人认领。已废弃的直接进入下线清单，不参与重建；无人认领的需要业务负责人确认归属，确认不了价值的同样列入取消候选。盘点的输出物是扩展台账和一张依赖关系简图，简图只需画出“哪个扩展调用了哪个扩展、哪个流程依赖哪个字段或审批流”，用来支撑下一步排序。
按价值与依赖排出重建顺序
全量同时重建会让问题和责任混在一起，分批推进更可控。排序用四个维度打分：业务影响面（影响多少团队和流程）、使用频率、被其他扩展依赖的程度、替代难度。前两项决定“值不值得先做”，后两项决定“能不能先做”。
实际操作中有一条基本顺序：先重建被多个流程依赖的基础规则，例如统一的状态流转、必填字段校验、权限相关的自动化，再处理挂在末端的通知、报表汇总和单点自动化。基础规则没稳定之前，末端自动化即使重建完成也无法验证，因为它的输入还依赖旧逻辑。
排序过程中同步做两件清理：把功能重叠的扩展合并成一条规则，例如三个脚本都在做类似的字段同步，可以合并为一个自动化；把价值低、频率低、无人认领的扩展直接取消，不进入重建清单。取消的决定要由业务负责人确认并留记录，避免上线后被追问“原来那个功能去哪了”。排序结果形成分批重建计划，每批包含扩展清单、负责人、计划完成时间和验证方式。
逐条做规则映射：原生配置、低代码还是外部集成
映射阶段要回答的是：这条旧扩展在新平台上由什么承接。承接方式分三类，判断依据集中在触发条件复杂度、动作是否跨系统、数据量与时延要求三点。
| 承接方式 | 适用情形 | 注意事项 |
|---|---|---|
| 平台原生工作流与自动化 | 触发条件为标准事件（创建、状态变更、字段修改、定时），动作在平台内部完成 | 优先选择，维护成本最低；需核对原生触发器和动作类型是否覆盖旧规则 |
| 低代码或脚本扩展 | 触发条件带复杂条件组合，或动作需要计算、批量处理平台原生动作覆盖不了 | 确认平台的脚本运行环境与权限模型；脚本要纳入版本管理和负责人制度 |
| 外部系统集成 | 动作需要调用外部系统，或数据需要跨系统同步 | 通过 API、Webhook 等开放能力承接；接口范围、调用频率与鉴权方式以官方文档为准 |
遇到新平台无法直接承接的扩展，先设计降级方案再决定是否重建。常见降级有三种：把自动动作改为定时批量处理，牺牲实时性换取可行性；把系统自动执行改为人工触发加检查清单，由流程 owner 在固定节点执行；把跨系统实时同步改为按批次导出导入。降级方案要写清人工兜底的责任人和执行时点，不能只写“暂由人工处理”。
映射结果写入规则映射表，每条记录包含旧扩展名称、承接方式、新平台实现要点、责任人、验证方式和备注。映射表不允许留空项，暂时判断不了的标注“待确认”并指定确认人和期限。以 ONES 为例，其迁移方案建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，并明确企业已有的定制场景需要逐项评估，不能假设所有插件都能一一对应；API 与 Webhook 可作为外部集成承接的手段之一，具体接口能力以官方文档为准。
在测试环境重建并做对照验证
重建在测试环境进行，验证方法是同一组输入分别跑旧规则和新规则，比对输出。输入样例要覆盖正常路径和边界情况：典型触发、刚好不满足触发条件的输入、字段为空、涉及多人审批、跨项目调用等。
每条规则至少验证四项：触发是否命中，包括该触发时触发、不该触发时不触发；动作是否完整执行，字段值、状态、关联关系是否与旧规则一致；通知对象是否正确，收件人、渠道、内容模板是否匹配；异常是否被捕获，输入不合法或外部接口失败时是否有记录和兜底。验证结果记入对照验证记录，出现差异时先判断性质：配置写错了属于配置问题，修正后重测；旧规则依赖的能力新平台确实没有，属于能力缺口，回到映射表调整承接方式或启用降级方案。
验证通过的标准是：该批全部规则在约定样例集上输出一致，或差异已被记录并接受。达到标准后才允许进入灰度，未通过的规则留在测试环境继续处理，不带问题上生产。
角色分工与各阶段交付物
重建涉及业务、平台、研发和测试四类角色，职责按阶段划分，交接时点要明确到具体交付物。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 业务负责人 | 确认扩展的业务价值、优先级，决定取消与合并 | 台账状态确认、分批计划签字 | 盘点结束、排序完成时 |
| 平台管理员 | 执行原生配置重建、权限设置、灰度发布 | 规则映射表、配置记录 | 映射完成、验证通过时 |
| 研发或集成人员 | 承接脚本类扩展与外部系统集成 | 脚本与接口配置、运行说明 | 重建完成、进入验证前 |
| 测试或流程 owner | 设计验证样例、执行对照验证、签字确认 | 对照验证记录与差异清单 | 验证通过、进入灰度前 |
职责悬空最常见的情形是“无人认领”的扩展和跨团队共用的脚本。前者在盘点阶段就要落到具体业务负责人，后者指定一名技术归属人统一维护。每个阶段的交付物都要有明确的接收人，接收人确认后才算完成交接。
一个完整示例：缺陷自动分派规则的重建
以下为演示情景，用于说明方法如何落地，不对应特定企业的真实配置。
旧规则描述：缺陷创建后，系统按所属模块和严重程度自动分派给对应负责人，并向负责人发送通知；严重程度为“致命”时同时通知测试负责人。这条规则在旧平台上由一个自动化插件加一段脚本实现。
映射判断：触发条件是标准的“工作项创建”事件，动作是修改负责人字段和发送站内消息，均在平台内部完成，判断用原生工作流承接，通知走站内消息，不需要外部集成。脚本中“致命级别额外通知”的逻辑，若原生条件分支可以表达，则并入同一条工作流；若不能，则拆为第二条规则。
重建步骤与配置要点：先建立模块与负责人的对应关系表，作为分派依据；再配置触发条件为缺陷创建；然后按模块匹配负责人写入负责人字段；接着配置严重程度判断分支，致命级别追加通知测试负责人；最后检查通知模板中的字段引用是否正确。
对照验证的输入样例：一条普通模块、严重程度为“一般”的缺陷，预期分派给该模块负责人且仅通知本人；一条核心模块、严重程度为“致命”的缺陷，预期分派给模块负责人并同时通知测试负责人；一条模块字段为空的缺陷，预期进入默认负责人或触发异常记录，与旧规则行为一致。
切换安排：新规则上线后与旧规则并行观察一段时间，观察期内比对两边分派结果，确认无差异后再停用旧规则。并行时长根据缺陷创建频率确定，频率低的项目适当延长，确保覆盖到各类严重程度和模块组合。
切换、回退与完成检查
切换按批次灰度，先在一个项目或一个团队启用新规则，观察期内由流程 owner 每日核对分派结果和通知记录。观察期长度按规则的触发频率设定，触发频繁的规则几天即可覆盖主要场景，触发稀疏的规则需要更长周期。
回退触发条件要事先写清，例如：出现分派错误且影响生产工作项、通知漏发导致责任人未收到、异常记录数量超过约定阈值。回退操作步骤同样要预先演练：停用新规则、恢复旧规则、核对回退期间产生的工作项是否需要人工补处理。旧扩展下线的前置条件是：对应新规则已通过验证并在灰度中稳定运行、观察期内无未解决的差异、业务负责人确认。
全部批次完成后，用以下清单逐项核对：
- 台账全覆盖：盘点范围内的七类扩展均已登记，无遗漏项
- 映射表无空缺：每条在用扩展都有承接方式、责任人和验证方式，“待确认”项已全部关闭
- 验证记录齐全：每条规则都有对照验证记录，差异已处理或已接受
- 负责人确认：业务负责人对取消、合并和重建结果逐项签字
- 旧规则已归档：旧扩展的配置、脚本和说明文档归档保存，注明停用日期和替代规则
清单全部勾选后，扩展能力重建才算完成。归档的旧规则说明在后续排查问题时仍有参考价值，建议与规则映射表放在同一处管理。
常见问题
盘点时怎么发现成员私下维护的脚本和插件？
三处交叉核对：平台管理后台的启用列表、服务器或任务计划中的脚本、各项目管理员手中的配置记录。三者对不上的条目单独列出，找对应项目负责人确认归属。盘点阶段就把无人认领的扩展落到具体业务负责人，避免进入映射阶段后职责悬空。
旧扩展在新平台上找不到对应能力，是否必须重建？
不一定。先判断这条扩展的业务价值和使用频率，价值低、频率低且无人认领的可以直接取消，由业务负责人确认并留记录。确有价值的，再设计降级方案：改为定时批量处理、改为人工触发加检查清单、或改为按批次导出导入。降级方案要写清人工兜底的责任人和执行时点。
对照验证时新旧规则输出不一致，怎么判断是配置问题还是能力缺口？
先看差异是否由配置写错导致，例如条件写反、字段引用错误、通知模板漏字段，这类修正后重测即可。若旧规则依赖的触发方式或动作类型在新平台上确实没有对应实现，属于能力缺口，回到规则映射表调整承接方式或启用降级方案。两类差异都要记入对照验证记录，不能只口头确认。
灰度观察期要多久，触发频率低的规则怎么办？
观察期按规则的触发频率设定，触发频繁的规则几天即可覆盖主要场景；触发稀疏的规则需要更长周期，确保覆盖到各类输入组合。频率极低的规则可以主动构造测试输入在灰度环境跑一遍，再结合一段时间的实际运行结果判断。观察期内由流程 owner 每日核对执行结果和通知记录。
旧规则下线后还需要保留哪些材料？
旧扩展的配置、脚本和说明文档归档保存，注明停用日期和替代规则，与规则映射表放在同一处管理。后续排查问题时，旧规则的原始逻辑仍有参考价值。归档完成是完成检查清单的一项，与台账全覆盖、映射表无空缺、验证记录齐全、负责人确认并列。
