第一段：基线
先跑单角色或人工流程，记录成功率、平均耗时与接管率。这段常被跳过，但没有基线，后面所有对比都无从谈起，也无法向管理层解释投入产出。基线样本要与后续评测使用同一批，否则结论不可比。
第二段：角色与协议
定角色边界、字段写入方与消息格式，产出可被编排直接引用的配置。准出条件是配置能跑通一条完整链路，且每个字段只有一处写入。协议未定就开发编排，改一次结构就要重写整条链路。
第三段：编排与评测
接入编排、加上限与仲裁，用基线样本复跑。准出条件是成功率不低于基线、轮次与接管率在可接受区间、冲突能按规则升级。这一段通常需要两到三轮调整，不宜按一次性交付来排期。
第四段：灰度与回退
从低风险环节开始灰度，保留一键回到原流程的开关，并监控轮次、超时与接管率。准出条件是灰度期无严重故障、回退演练成功、运维手册交付。跳过回退演练，出问题时往往只能停服。
适用与不适用
适合谁
- 需要向管理层说明多角色投入产出的负责人
- 已有单角色试点、准备进阶的团队
不适合谁
- 尚无基线、也没有评测样本的项目
- 要求一次性全量切换、不留回退路径的场景
典型场景
某团队原计划六周上线多角色流程。按四段拆解后，基线阶段用了两周，发现单角色在长合同上漏项；角色与协议阶段又用两周固定字段写入方；编排与评测三轮后成功率追平基线，灰度只开放短合同，回退演练通过后才扩围。
可执行步骤
- 用同一批样本跑出基线，并记录成功率、平均耗时与接管率
- 定角色边界、字段写入方与消息格式，写成可被直接引用的配置
- 接入编排，加上限与仲裁规则，再用同一批基线样本复跑对比
- 从低风险环节开始灰度，并完整演练一次一键回到原流程
- 灰度稳定后再逐步扩围，同时交付运维手册与回退操作说明
常见坑
- 跳过基线直接开发多角色，上线后无法证明更好，预算审批时也拿不出一致依据。
- 协议未定就先写编排，改一次字段就要重写全部链路，返工量随角色数量放大。
- 不做回退演练，灰度出问题时只能停服，影响面超出预期，恢复时间也被拉长。
自检与验收清单
- 是否已跑出基线的成功率、耗时与接管率
- 每个字段是否只有一个写入方并写进配置
- 冲突升级是否按既定规则触发并可复现
- 一键回退是否演练过，结果是否记录
常见问题
多角色一定更慢吗？
通常更慢，因为多了协调与通信。是否值得取决于质量提升是否明显，以及人工接管率是否下降。若只是把单角色能做的事拆开，耗时会增加而质量不变，这时应回到单角色。
灰度要多久？
取决于业务风险与流量，通常两到四周，覆盖至少一个完整业务周期。灰度期要盯轮次、超时与接管率三条曲线，任一异常上升就暂停扩围，先查是角色边界还是上限设置的问题。
能和其他系统改造并行吗？
可以，但不要让编排依赖未定的接口。可行做法是先冻结工具清单与字段契约，编排只对接已确认的部分，其余用占位与降级。依赖未定接口的编排，改一次就要重测全链路。