流程推演（源码级走查验证业务闭环）

技能文档

---
name: flow-simulation
description: 流程推演——不调接口、不产数据，以操作者视角沿业务链路逐层走查源码，验证功能端到端能否跑通。当用户在功能实施完成后、联调或上线前说「走一遍流程」「推演一下」「能不能跑通」「串起来看」「不用真实跑，直接看代码发现问题」，或大功能交付需要链路级自查时触发。
title: 流程推演（源码级走查验证业务闭环）
category: 开发工具
---

# 流程推演（源码级走查验证业务闭环）

不调接口、不产生数据，纯读源码，以「用户怎么操作」为主线沿前端 → 接口 → 服务层 → 数据层逐层推演，验证一个业务功能端到端能否跑通，在真实运行前发现链路断点（事务缺失、状态卡死、推送遗漏、跨端字段错位等）。方法论与语言/框架无关；配套断点模式库提炼自一次 Java/Spring 微服务项目的实战走查（一次推演发现 5 处确定性断点，其中 2 处会卡死流程），案例仅作示意。

## 技能工作流（分析流程）

调用 `todo_write` 工具创建待办任务：

链路盘点 → 逐段推演 → 断点修复 → 走查报告

### 步骤 1：链路盘点（推演前）

1. 读需求/方案文档，列出端到端主链路的**每一步用户动作**（UI 操作 → 接口 → 状态变化），多个业务分支（同一功能的不同策略/模式，如两种拣货策略、两种支付方式）各自列一条独立链路。
2. 盘点链路涉及的端：前端/Web 应用、后端服务、移动端/客户端、定时任务/批处理、消息与事件监听、外部依赖——按项目实际形态取舍，每个端找到入口文件。
3. 列出链路上的**状态机**（订单/单据状态、任务/作业状态、履约状态等）和每步的前置状态门禁——状态机是推演的主轴。
4. 用 `todo_write` 把每条链路记为一项待办，逐条推演逐条勾。

### 步骤 2：逐段推演（核心）

按用户操作顺序走链路，**每一步核对五件事**，全部通过才进入下一步：

1. **参数衔接**：上一步产出的参数，与下一步函数签名的参数个数、顺序、含义逐位对齐（长参数列表逐一数；前端传参与接口入参的 DTO/查询参数/函数签名字段名逐一比对）。
2. **数据可见性**：下一步读的数据，在上一步是否已落库且事务可见（同步事件监听与写库的先后、同事务/跨事务、缓存 vs DB）。典型坑：A 步发布事件同步回写、B 步按回写字段反查——成立；若回写是异步执行则 B 步读不到。
3. **状态门禁**：本步操作的目标状态，是否满足下一步的前置条件；有没有旁路操作（用户点了另一个按钮）把状态推向下一步不认的值。
4. **失败路径**：本步单笔失败/部分失败/超时，会不会留下中间态；重试入口是否存在且可达（后端有重试接口、前端按钮条件是否覆盖该失败形态）。
5. **跨层口径**：同一业务口径（状态值集合、标签、明细分摊）在链路各端的枚举/常量/编码是否一致（前端硬编码 vs 后端枚举）。

推演中每个「这步依赖的数据从哪来」的疑问都必须打开源码核实，禁止凭命名猜测——例如 Mapper 注释「null 按置空处理」、`BeanUtils.copyProperties` 透传、`fromEntity` 手工逐字段赋值，结论完全不同。

**前端段专项**：链路走到前端（管理端/移动端/PDA）时，五件事之外逐项核对交互推演清单——入口可见性、补救入口覆盖、交互参数链、状态与时序、页面衔接、渲染数据依赖、多端对齐，详见 [references/frontend-checklist.md](references/frontend-checklist.md)。高频断点：用户动作的入口在目标场景下点不到（渲染条件漏分支）、补救按钮显示条件不覆盖整单失败形态、打印/展示模板引用后端从不填的字段。

### 步骤 3：断点修复

1. 按严重度分级：**阻断级**（流程卡死/数据不一致，如事务缺失中间态、推送遗漏）→ **流程卡点级**（旁路操作导致卡死、入口缺失）→ **提示级**（口径偏差、UX 缺失）。
2. 阻断级与流程卡点级当场小步修复（每处只改断点本身），修一条验证一条；提示级列入报告由用户决策。
3. 修复后运行受影响模块的既有测试回归；测试桩随实现变化会失效（如 Mockito 严格模式报 UnnecessaryStubbing、其他 mock 框架的等价报错），同步清理。
4. 断点模式与修复手法沉淀到走查报告，对照 [references/breakpoint-patterns.md](references/breakpoint-patterns.md) 的模式库判断是否新模式。

### 步骤 4：走查报告

输出结构固定的报告（中文）：

1. **结论先行**：能否跑通；发现几处断点、几处已修。
2. **逐段推演**：每条链路按用户操作分节，写清每步「谁 → 谁 → 依据源码的哪个事实成立」；断点所在步用 ⚠️ 标出，写清推演出的后果与修法。
3. **残留风险**：按方案口径接受、无需改码的点（操作规程约定、上游契约），单独列出提请注意。
4. **验证结果**：修复后编译与测试回归结果表格。

## 断点模式速查

推演时优先对照以下高频断点（完整定义与实战案例见 [references/breakpoint-patterns.md](references/breakpoint-patterns.md)）：

| # | 模式 | 一句话识别 |
|---|------|-----------|
| 1 | 新旧入口事务不对齐 | 新入口缺 `@Transactional`，失败留下半提交中间态且被幂等校验挡死重试 |
| 2 | 状态门禁挡住后续推送 | 首条推送后状态已流转，条件分支 return 使其余条目永不推送 |
| 3 | 旁路操作破坏状态机 | 用户走了另一个按钮，状态到达完结检查不认的值，流程卡死 |
| 4 | 跨端字段断供 | 后端不填某字段、前端模板/断言依赖它 |
| 5 | 存量数据不满足新契约 | 行为变更后旧数据/旧 fixture 命不中新过滤条件 |

## 适用域

- **最适用**：多端协作、含状态机或事件链路的业务系统（订单/仓配/支付/审批/工单等）——推演主线与断点模式全部命中。
- **可用**：单后端 API 服务（链路=调用链+数据流，跳过「旁路操作」核对）、前端应用为主的项目（链路=组件流+状态流，以 [references/frontend-checklist.md](references/frontend-checklist.md) 的交互核对项为主轴）。
- **弱适用**：纯算法库、工具函数、配置脚本——无业务链路可走，常规 code review 即可，不要强行套用本技能（本技能与 code review 的分工：review 看局部代码质量，流程推演看端到端业务闭环）。

## 使用说明

```text
# 触发示例
「B2C 方案实施完了，你模拟用户把边拣边分和相同货品两条流程串起来走一遍，
  不调接口不产数据，只看源码，分析能否跑通」

# 或在实施收尾时主动触发
功能涉及 ≥3 个端或含状态机/事件链路时，交付前主动执行本技能并附走查报告。
```

## 错误处理（推演受阻场景）

- **文件过大无法一次读完**：按链路涉及的方法逐段读（先读入口 Controller 定位方法名，再按行号区间读 ServiceImpl 对应段落），不做全文件通读。
- **某步依赖无法静态确认**（外部接口行为、异步时序不确定）：在报告中标记为「待运行验证」并写明验证动作，不臆断为成立或断裂。
- **发现与需求无关的存量问题**：只记录不修复，列入报告「残留风险」，由用户决策。
- **修复引入测试失败**：先判断是 stub 随实现失效（同步清理 stub）还是行为回归（回退修复重新推演），禁止为过测试改断言。

## 约束

全程只读源码 + 本地编译/单测验证，禁止调用业务接口、禁止写数据库；修复限于走查发现的断点，禁止顺手重构。

使用说明

# 流程推演（flow-simulation）

不调接口、不产数据，以源码为载体推演业务流程端到端闭环——在真实运行前发现会卡死流程的断点。

## 使用

```text
「这个功能实施完了，你模拟用户把 XX 和 YY 两条流程串起来走一遍，
  不调接口不产生数据，只看源码，分析能否跑通」
```

也可在涉及多端协作或状态机的功能交付前主动触发，交付物为结构化走查报告。

## 工作原理

以「用户怎么操作」为主线，沿 前端 → 接口 → 服务层 → 数据层 逐段推演，每步核对五件事：参数衔接、数据可见性、状态门禁、失败路径、跨层口径。多个业务分支（如两种拣货策略）各走一条独立链路，发现的断点按严重度当场小步修复并回归测试，最后输出逐段推演报告。

## 支持场景

- 大功能（多端/多分支/状态机/事件链路）实施完成后的链路级自查
- 联调或上线前的风险预演：事务边界、状态卡死、推送遗漏、跨端字段错位、存量数据不满足新契约
- 配套断点模式库 `references/breakpoint-patterns.md`：8 类高频断点的诊断/识别/修复/实战案例，可独立查阅

如何安装此技能？

访问技能市场，点击「安装」按钮，按提示将技能包放入 AI 编程助手的 skills 目录即可。