## 抽象：用 visual-spec-flows 统一表达审批类流程

`visual-spec-flows.svg` 的目的不是描述某一个具体业务，而是提供一套“可复用的抽象骨架”，把任何审批/流转类流程统一到同一个框架里，便于评审、拆分、估算与落地实现。

![visual-spec flows](../../assets/zh-CN/visual-spec-flows.svg)

这里展示的是“审批/流转类流程”的一种抽象示例，但在实际业务中还存在很多其他类型的抽象（例如资源调度、计费结算、风控准入、库存与履约、对账与资金流、事件驱动协作等），本文不逐一列举。

关键步骤是：先抽象，再开发提示词。抽象把要覆盖的维度与边界固定下来，提示词只是把这些维度变成稳定可重复的输出格式；如果没有方法论支撑、只靠“随便分析”的提示词，很难稳定地产出同样完整、可落地、可验证的分析效果。

### 1）为什么要抽象成统一的 flows

审批类流程的共性远大于差异：几乎都包含“提交 → 审批 → 执行 → 归档/后置”，差异主要体现在：

- 审批链条的层级与规则（多人、会签、或签、条件分支）
- 执行阶段的约束（校验、额度、库存、合规、并发与幂等）
- 变更与应急处理（取消/拒绝、紧急停止、紧急变更、冲突解决）

把这些共性提炼为统一的图形结构，可以让后续分析聚焦在“差异点需要补齐什么信息”，而不是每次从零画流程。

### 2）把任意审批流程映射到 flows（映射步骤）

建议按以下步骤做映射：

1. 定位主链路：把流程最稳定的推进路径映射到 1~5（前置/申请/审批/执行/后置）
2. 提取审批变化：把“谁能取消/谁能拒绝/何时允许撤回”放到顶部控制路径
3. 提取执行约束：把“必须校验哪些条件/约束如何定义/失败如何处理”放到底部约束路径
4. 提取应急与冲突：把“执行阶段如何紧急停止/如何紧急变更/如何解决冲突”归入 4 号节点扩展
5. 产物对齐：把每个节点对应的产物落点对齐到 specs（例如状态、字段、权限、日志与用例）

### 抽象后的共性（基于 thinking-modes）

抽象的核心不是把流程画得更复杂，而是用一套稳定的思维方式把“差异点”系统化地暴露出来。建议结合 [thinking-modes.md](file:///Users/stephenwang/Documents/trae_projects/my_skills/docs/zh-CN/theory/thinking-modes.md) 来做补全：

- 边界思维：明确目标/非目标、角色边界、权限边界、时间边界与数据边界，避免只覆盖“看起来合理”的主路径。
- 对称思维：从正向流程推导逆向与补偿流程（撤销/回滚/重复提交/幂等），让控制路径完整可验证。
- 约束思维：把隐性约束显性化（校验、状态机、审计、合规、并发），让执行路径与失败策略可落地。
- 多样性思维：从多角色、多场景、多渠道出发覆盖差异，避免实现与验收阶段出现“遗漏的角色/遗漏的场景”。

在这个抽象框架下，绝大多数审批/流转类流程都会呈现相同特征：稳定主链路 + 可枚举的控制路径 + 可清单化的约束路径。

另外，图中“审批”和“执行”并不要求是单步；在复杂业务里它们可以是多步子流程，只要把这些子步骤对齐到同一套维度（控制/约束/产物）即可。
