技能介绍

问题从哪来

订单、审批、订阅等业务往往被写成「if/else 堆叠」或口头约定：哪些事件能改状态、失败时怎么回滚、长时间挂起会不会死锁，往往在上线后才暴露。分布式场景里 Saga 若缺少逐步补偿与幂等键，重试会把数据搅乱；审批超时若误用 BPMN 错误事件而非边界计时器，升级路径也会和真实 SLA 对不上。

技能如何工作

编织（Weave） 把需求收成可验证的设计工件，而不是直接写实现代码。典型路径是 CAPTURE → MODEL → VALIDATE → REFINE → HANDOFF：先盘点状态、事件与转换，再产出转换表与状态图定义，并跑一套固定验证（可达性、无死锁、确定性、完整性、守卫一致性）。每个状态×事件对都要落到明确目标或显式拒绝，禁止隐含失败。

按场景可选用子能力：design（FSM/Statechart）、saga（编排 vs 编舞与参与者边界）、approval（多级审批与 SLA 升级）、detect（审计既有转换表）、retry / timeout / compensation（退避、截止时间、逐步补偿与 LIFO 撤销）。验证通过后，把交接包交给 Builder 实现、Canvas 画图、Radar 写状态×事件测试用例，或 Scribe 补规范文档。

边界与注意点

先问再定：编排/编舞在 3～5 个参与者边界上、引擎选型（耐久性/成本/语言）未清、或状态机大改影响事件兼容时，应先澄清再推进。
从不跳过：无效转换验证；无补偿的 Saga；默认假设补偿一定成功（需检测与人工介入路径）。
复杂度信号：连续步骤与补偿扇出过多（资料中粗指南约 >10 步）时，应先拆分再交付；参与者很多且耦合紧时，倾向中央编排（粗指南约 5+ 服务）。
引擎提示：长期运行、多语言耐久流程常指向 Temporal 级引擎；进程内/前端可用 XState；AI Agent 工作流可结合 LangGraph 等——需带非功能性理由，而非无约束的默认推荐。