更换研发管理平台时，旧系统里靠自定义字段、工作流规则、自动化触发、脚本和集成搭起来的扩展逻辑，需要按业务目的重新梳理并在新平台重建，这就是扩展能力重建。它关注的是行为与规则的迁移，历史数据的搬运和字段映射不在本文范围。下文按盘点、分层重建、角色分工、示例和验收五步展开，并说明ONES在工作流与自动化配置上的承载方式。
要点总览（TL;DR）
- 先产出带处置结论的旧扩展清单：按业务目的归类，逐条给出保留、简化、放弃、替换判定，并由业务方确认。
- 重建按三层推进：标准字段与工作流优先，自动化规则承接触发与通知，脚本、Webhook 与外部集成单独排期联调。
- 角色分工要落到交付物：平台管理员负责清单与配置，业务负责人确认用途，研发或集成负责人承接接口，验收人按场景回归。
- 验收以业务场景回归为准，保留项能触发并产生预期结果，脚本与集成有联调记录，遗留项与降级方案写明责任人和补位方式。
先盘清旧平台扩展清单：哪些要重建、哪些可以放弃
扩展能力重建的第一步是产出一份带处置结论的旧扩展清单。清单的价值在于把“旧平台里有什么”转换成“新平台需要什么”，避免把旧配置原样照搬。盘点时按业务目的归类，例如“缺陷关闭后通知测试负责人”属于通知类需求，“需求评审通过才能进入开发”属于状态流转约束，实现方式只是满足目的的手段。
清单建议包含以下字段，逐条填写：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 名称 | 旧平台中的规则、字段、脚本或集成的实际名称 | 定位与检索 |
| 触发条件 | 什么事件或状态变化会激活它 | 判断重建后的触发方式 |
| 作用对象 | 涉及的工作项类型、字段、人员或外部系统 | 确定新平台的承载对象 |
| 业务用途 | 用一句话说明它解决了什么业务问题 | 决定保留还是放弃 |
| 使用频率 | 近三个月触发次数或使用人数 | 判断优先级 |
| 负责人 | 旧规则的维护人或主要使用方 | 后续确认与验收 |
每条扩展给出四类处置结论之一：保留，业务目的仍然成立且需要在新平台实现；简化，目的成立但旧实现过度复杂，可用更少的字段或规则满足；放弃，业务场景已消失或使用频率极低；替换，目的成立但新平台有更合适的标准能力或不同实现路径。处置结论要写明理由，便于业务方复核。
盘点的输入来自两方：旧平台管理员提供配置层面的完整清单，业务使用方确认每条扩展的实际用途和使用频率。只靠管理员盘点容易把废弃规则也列入重建范围，只靠业务方则容易遗漏后台脚本和集成。两方对照后再定处置结论，清单才算可执行。
重建顺序：标准配置、自动化、脚本与集成的分层落地
重建按三层推进，优先级从高到低。先看新平台的标准字段、状态与工作流能覆盖多少旧自定义，再用自动化规则承接触发与通知类逻辑，最后把脚本、Webhook 和外部集成单独排期。这个顺序的依据是：标准配置最稳定、维护成本最低，自动化规则次之，脚本与集成依赖接口和外部系统，变更成本最高。
| 层级 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一层：标准配置 | 处置为保留或简化的字段、状态、流转类扩展 | 在新平台建立工作项类型、字段、状态机与流转条件 | 配置说明与字段对照 | 业务方确认字段与流转覆盖原业务目的 |
| 第二层：自动化规则 | 触发与通知类扩展，含触发条件、动作和接收人 | 配置自动化规则的触发条件与执行动作 | 规则清单与触发记录 | 测试场景下规则按预期触发并通知到正确对象 |
| 第三层：脚本与集成 | 处置为替换或无法用前两层实现的扩展 | 开发脚本、配置 Webhook、对接外部系统并联调 | 接口说明、联调记录 | 联调通过，异常情况有处理方案 |
第一层的判断标准是“业务目的能否用标准能力表达”。例如旧平台用自定义字段加脚本计算优先级，如果新平台的标准字段和流转规则能直接表达优先级判定，就归入第一层；如果判定逻辑依赖外部数据，则下沉到第三层。第二层适合“当某字段变为某值时通知某人”这类规则，配置完成后用测试数据验证触发对象和通知对象是否正确。
无法等价实现时，先记录替代方案再决定降级方式。常见处理有三种：用相近的标准能力部分满足，把差异点写入操作规范由人工补位；把复杂脚本拆成自动化规则加定期人工检查；保留外部系统处理，通过接口把结果回写为新平台字段。每种降级都要写明影响范围和责任人，避免上线后才发现缺口。
在承载方式上，ONES 提供工作项、工作流与流程自动化配置，并具备 API / Webhook 开放能力，可分别对应上述三层中的标准配置、自动化规则和集成类扩展。对于原来依赖插件实现的场景，ONES 的迁移方案建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配；企业已有的定制场景仍需逐项评估，不能假设所有插件都能一一对应。
角色与交付物：谁盘点、谁重建、谁验收
扩展能力重建涉及配置、业务判断和接口开发三类工作，全部压给平台管理员会导致业务用途判断失真、脚本类扩展排期失控。建议按以下分工推进，每个角色都有明确交付物和交接节点。
| 角色 | 职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 平台管理员 | 整理旧扩展清单，执行标准配置与自动化规则实现 | 旧扩展清单、配置说明、规则清单 | 清单交业务负责人确认；配置完成后交验收人测试 |
| 业务负责人 | 确认每条扩展的业务用途，给出保留、简化、放弃、替换判定 | 带处置结论的确认清单 | 确认后交平台管理员排期 |
| 研发或集成负责人 | 承接脚本、Webhook 与外部接口类扩展的开发和联调 | 接口说明、联调记录、异常处理方案 | 联调通过后交验收人回归 |
| 验收人 | 按真实业务场景回归，确认重建结果可用 | 回归记录与验收结论 | 验收通过后关闭对应清单条目 |
交接的关键在于清单状态同步。每条扩展在清单上标注当前状态：待确认、待配置、待联调、待验收、已完成。业务负责人确认后状态变为待配置，平台管理员完成后变为待验收，验收人通过后关闭。状态流转让遗留项自然暴露，也避免同一规则被重复实现或遗漏。
一个示例：缺陷流转自动化规则的重建过程
以下为演示情景，用于说明方法，不代表真实项目案例。旧平台中有一条规则：当缺陷工作项的状态从“修复中”变为“待验证”时，自动把“验证人”字段设置为该缺陷所属模块的负责人，并向其发送通知。规则还附带一个条件：严重程度为“致命”的缺陷同时通知测试经理。
业务目的还原：缺陷修复完成后需要由对应模块负责人验证，人工指定验证人容易遗漏或指错人；致命缺陷需要测试经理同步知晓。这个目的在新平台仍然成立，处置结论为保留，但实现方式可以简化。
重建步骤：
- 在新平台的标准工作流中确认“修复中”到“待验证”的流转存在，流转动作中配置“验证人”字段按模块负责人自动赋值。这一步用标准配置完成，不依赖脚本。
- 配置自动化规则：触发条件为状态变更为“待验证”，执行动作为通知验证人；增加一条条件规则，当严重程度为“致命”时额外通知测试经理。
- 用测试缺陷数据验证：分别构造普通缺陷和致命缺陷各一条，执行状态流转，检查验证人字段是否正确赋值、通知是否送达正确对象、致命缺陷是否额外通知测试经理。
回归验证的通过标准：字段赋值与旧规则结果一致；通知对象无遗漏、无多发；致命缺陷的附加通知按条件触发；非致命缺陷不触发附加通知。测试通过后，在清单上把该条目标记为已完成。
这个示例的可迁移规律是：先还原业务目的，再判断能否用标准配置承接主体逻辑，自动化规则只负责触发和通知，最后用覆盖条件分支的测试数据验证。旧规则中的条件判断越多，测试场景越要覆盖边界情况。
完成检查：扩展能力重建的验收清单
验收以清单和业务场景回归为准，逐项判断通过与否，不依赖主观感受。以下检查项可逐条核对：
- 旧扩展清单完整，每条扩展都有处置结论（保留、简化、放弃、替换）和负责人。
- 处置为保留和简化的条目，在新平台已配置完成并有配置说明。
- 保留项在新平台可触发，产生的结果与业务目的相符，通知对象和字段赋值正确。
- 自动化规则覆盖了旧规则中的条件分支，边界场景有测试记录。
- 脚本与集成类扩展有联调记录，包含正常流程和异常处理。
- 业务方按真实业务场景完成回归，回归记录可查。
- 放弃项有放弃理由和确认人，避免后续争议。
- 遗留项与降级方案有明确记录，写明影响范围、责任人和补位方式。
全部检查项通过后，扩展能力重建才算完成。遗留项不阻塞整体验收，但要在上线后按约定时间复核，确认降级方案在实际使用中可接受。上线后的日常配置治理和权限维护属于另一项工作，不在本次重建范围内。
常见问题
旧平台里使用频率很低的自动化规则，应该直接放弃还是先保留？
先看业务目的是否仍然成立。如果对应场景已经消失，或者近三个月几乎没有触发且没有业务方认领，可以判为放弃，并在清单上写明放弃理由和确认人。如果场景偶发但后果较重，例如季度结算时的提醒，建议判为保留但降低实现成本，用更简单的规则或人工检查替代。使用频率只是判断依据之一，不能单独决定处置结论。
新平台的标准工作流无法完全表达旧规则的条件逻辑，怎么处理？
先拆解条件逻辑：能用标准字段和流转条件表达的部分放在第一层，触发和通知部分交给自动化规则，依赖外部数据或复杂计算的部分下沉到脚本与集成层。拆完后如果仍有差异，记录替代方案，例如用相近标准能力部分满足、把差异点写入操作规范由人工补位，或保留外部系统处理并回写结果。每种方案都要写明影响范围和责任人。
扩展能力重建和研发数据迁移是什么关系，能否合并推进？
两者对象不同。数据迁移处理历史记录、字段映射和附件评论的搬运；扩展能力重建处理规则、触发、脚本和集成在新平台如何重新实现。可以并行排期，但清单和验收标准要分开：数据迁移看记录完整性和映射准确性，扩展重建看业务场景下规则能否按预期触发并产生正确结果。合并推进时注意先确认新平台的字段与状态结构，否则重建的规则可能建在错误的字段上。
脚本和集成类扩展在验收时，除了正常流程还要测什么？
至少覆盖三类情况：接口返回异常或超时时的处理，外部系统不可用时的降级路径，以及重复触发时是否会产生重复数据或重复通知。联调记录里写清测试输入、预期结果和实际结果，异常处理方案要指明由谁在什么条件下介入。只验证正常流程，上线后遇到网络波动或外部系统变更时容易暴露问题。
重建完成后，旧平台的扩展配置什么时候可以停用？
建议在新平台对应条目通过验收、且业务方完成一段时间的实际使用确认后再停用旧配置。停用前核对清单状态，确认没有仍依赖旧规则的业务场景，并保留旧配置的导出或截图作为追溯依据。停用顺序上先停通知类规则，再停流转约束类配置，最后处理脚本与集成，避免业务操作中途失去校验或提醒。
