步骤工程化与审查——从文字流程到可执行的步骤图

前面几篇把工程变成「过程 → 流程 → 步骤」。这一篇解决最后一个问题：步骤本身怎么定义，才能让流程被人工、程序、AI Agent 一致地执行和审查？ 答案是两步：① 步骤 = 一个有明确输入、目标、约束、操作、输出、验证的原子任务；审查 = 对某一个明确对象的某一个明确属性进行验证——每个步骤只做一件事，每个审查只检查一件事；② 用 STEP/REVIEW 关键字把步骤组织成带状态和分支的控制流，让整个工程从「文字描述的流程」变成可执行、可自动审查的步骤图。

一、核心定义

步骤 = 一个有明确输入、目标、约束、动作、输出的原子任务。

审查 = 对某一个明确对象的某一个明确属性进行验证。

把依赖关系加入审查步骤，整个流程就不只是线性 checklist，而是一个带依赖关系和反馈回路的工程系统。

二、一个标准步骤的结构

1
2
3
4
5
6
7
8
步骤
├── 输入
├── 前置条件
├── 目标
├── 约束
├── 操作
├── 输出
└── 验证

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
步骤：确定系统边界

输入：
- 需求点
- 功能点

目标：
- 明确系统负责什么、不负责什么

约束：
- 不增加需求
- 不改变已确定需求
- 每项功能必须有归属

操作：
- 将功能点分配到系统
- 标记系统边界

输出：
- 系统边界表
- 系统职责表

审查也是小件

审查不是「审查系统设计」，而是拆成小件：

1
2
3
4
审查：系统职责是否覆盖全部功能点
输入：系统职责表、功能点表
目标：发现遗漏
输出：遗漏项
1
2
3
4
审查：系统之间是否存在反向依赖
输入：系统依赖关系
目标：发现非法依赖
输出：依赖问题

每个审查只做一件小事。

三、「一个步骤只做一件事」——原子化原则

不要写「设计通信系统」，而应拆成：

1
2
3
4
5
6
7
8
9
10
11
12
确定通信系统职责
确定通信系统边界
确定通信组件
确定组件职责
确定组件关系
确定通信协议
确定协议消息
确定消息格式
确定组件接口
确定组件生命周期
确定启动流程
确定运行流程

每个动作还可以继续拆。例如「确定通信组件」拆成：

1
2
3
4
5
6
识别网络组件
识别连接组件
识别会话组件
识别协议组件
识别编解码组件
识别调度组件

四、审查是流程中的「一等公民」

不是「设计、设计、设计、完成」，而是「设计 → 审查 → 设计 → 审查 …」：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
确定系统划分
 ↓
审查：所有功能点是否都有系统归属
 ↓
审查：是否存在重复系统职责
 ↓
审查：系统职责是否互相越界
 ↓
确定模块划分
 ↓
审查：模块是否覆盖系统职责
 ↓
审查：模块之间是否存在职责重叠
 ↓
……

审查不是最后的 QA，而是设计过程本身的一部分。

五、依赖关系决定步骤顺序

1
需求点 → 功能点 → 系统 → 模块 → 组件 → 接口 → 实现

后面的东西依赖前面的东西。每个步骤建立：

1
2
3
前置依赖：S12、S17
输出：O23
后继步骤：S31、S32

整个工程就变成一个 DAG（有向无环依赖图），而不是一条流水线。

审查本身也有依赖

「审查接口是否正确」依赖「接口设计完成」；但「审查接口是否覆盖功能」还依赖「功能点 + 接口 + 功能—接口映射」：

1
2
3
4
5
6
7
A：功能点设计
 ↓
B：接口设计
 ↓
C：建立功能点—接口映射
 ↓
D：审查接口是否覆盖全部功能点

而不是让审查凭「感觉」进行。

六、每个步骤的小闭环

1
2
3
输入 → 做 → 输出 → 审查 → 通过？
 ├── 是 → 后继步骤
 └── 否 → 返回修改

整个工程不是「流程」，而是「步骤图」：

1
2
3
4
5
6
需求分析 → 需求点 → 业务流程 → 功能设计 → 功能点 → 系统设计
→ 系统职责审查 → 系统划分 → 系统依赖审查
→ 分叉：业务系统（模块设计/模块审查/接口设计/接口审查）
       通信系统（组件设计/组件审查/协议设计/协议审查）
       GUI系统（信息设计/页面设计/交互设计/UI审查）
→ 详细设计 → 工程设计 → 实现 → 测试/验证

系统设计决定后面走哪条路线——它是一个分流节点。

七、统一描述所有步骤：STEP / REVIEW 结构

STEP 结构

1
2
3
4
5
6
7
8
9
10
11
STEP
├── ID
├── NAME
├── INPUT
├── PRECONDITION
├── OBJECTIVE
├── CONSTRAINT
├── ACTION
├── OUTPUT
├── STATE
└── NEXT

各字段规则：

  • INPUT：只能读取声明的输入，不能隐式依赖未声明产物
  • PRECONDITION：不满足时 → BLOCK
  • OBJECTIVE：只描述一件事。正确例「确定通信系统边界」；错误例「设计通信系统并设计协议并设计组件」
  • CONSTRAINT：规定不能违反的条件（如 no_new_requirement、single_responsibility）
  • ACTION：描述真正执行的工作，不负责其他步骤
  • OUTPUT：没有可验证的输出，就不应作为独立步骤
  • STATE：每个步骤必须有明确状态

步骤状态

1
PENDING → READY → RUNNING → COMPLETED
1
2
3
4
5
6
7
8
9
10
PENDING       等待
READY         就绪（依赖满足）
RUNNING       执行中
WAITING       等待
BLOCKED       阻塞（前置条件不满足）
FAILED        执行失败
PASSED        审查通过
REJECTED      审查不通过
SKIPPED       条件性跳过
COMPLETED     完成

发生问题：RUNNING → FAILED、RUNNING → BLOCKED；需要审查：COMPLETED → REVIEW → PASSED / REJECTED。

REVIEW 结构

1
2
3
4
5
6
7
8
9
REVIEW
├── ID
├── TARGET
├── INPUT
├── OBJECTIVE
├── RULE
├── OUTPUT
├── STATE
└── NEXT

例如：

1
2
3
4
5
REVIEW R001
TARGET: system_boundary
OBJECTIVE: 检查所有功能点是否具有系统归属
RULE: every function_point has one system
OUTPUT: review_result

不能写成「审查系统设计是否合理」，应拆成：检查功能覆盖 / 检查职责重复 / 检查职责越界 / 检查系统依赖 / 检查依赖方向。

八、控制流程关键字

1
2
3
4
5
START   STEP    REVIEW
INPUT   OUTPUT  CHECK
STATE   IF      THEN    ELSE
GOTO    RETURN  WAIT    BLOCK
PASS    REJECT  FAIL    SKIP    END

含义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
STEP    = 做一件事
REVIEW  = 检查一件事
CHECK   = 获取判断条件
IF/ELSE = 判断
GOTO    = 向后继步骤跳转
RETURN  = 返回修正
STATE   = 当前执行状态
WAIT    = 等待条件
BLOCK   = 暂停且不能继续
PASS    = 审查通过
REJECT  = 审查不通过
FAIL    = 执行失败
SKIP    = 条件性跳过
END     = 流程结束

标准步骤控制流

1
2
3
4
START → CHECK → STEP → OUTPUT → REVIEW
→ IF PASS → NEXT
→ IF REJECT → RETURN
→ IF FAIL → BLOCK/FAIL

状态控制流

正常执行：

1
PENDING → CHECK → READY → RUNNING → OUTPUT → COMPLETED → REVIEW → PASSED

前置条件不满足：

1
PENDING → CHECK → BLOCKED → WAIT → CHECK

执行失败：

1
RUNNING → FAILED → ANALYZE → RETURN

审查失败：

1
COMPLETED → REVIEW → REJECTED → RETURN → RUNNING

条件分支（按系统类型分流）

1
2
3
4
IF system_type == BUSINESS      GOTO MODULE_DESIGN
IF system_type == COMMUNICATION GOTO COMPONENT_DESIGN
IF system_type == GUI           GOTO GUI_DESIGN
IF system_type == CLI           GOTO CLI_DESIGN

各子系统控制流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
业务系统：S100 MODULE_DESIGN → R100 REVIEW_MODULE_COVERAGE
          → PASS → S101 MODULE_DEPENDENCY_DESIGN → R101
          → PASS → S102 INTERFACE_DESIGN → R102 → NEXT

通信系统：S200 COMPONENT_DESIGN → R200
          → S201 COMPONENT_INTERFACE_DESIGN → R201
          → S202 PROTOCOL_DESIGN → R202
          → S203 FRAMEWORK_DESIGN → R203 REVIEW_LIFECYCLE → NEXT

GUI：S300 INFORMATION_DESIGN → R300 → S301 PAGE_DESIGN → R301
     → S302 REGION_DESIGN → R302 → S303 COMPONENT_DESIGN → R303
     → S304 INTERACTION_DESIGN → R304 → S305 USER_FLOW_DESIGN → R305
     → S306 VISUAL_DESIGN → R306 → S307 UI_SPECIFICATION → R307 → NEXT

CLI：S400 COMMAND_DESIGN → R400 → S401 PARAMETER_DESIGN → R401
     → S402 PARSE_DESIGN → R402 → S403 DISPATCH_DESIGN → R403
     → S404 CALL_DESIGN → R404 → S405 OUTPUT_DESIGN → R405 → NEXT

九、核心原则

1
2
3
4
一、一个 STEP 只做一件事
二、一个 REVIEW 只检查一件事
三、每个 STEP 都有明确 INPUT / OUTPUT
四、所有分支、返回、等待、阻塞都显式表示

这样工程流程就从「文字描述的流程」变成可被人执行、程序执行、Agent 编排和自动审查的控制流程：

1
2
读取当前产物 → 找到满足条件的下一步骤 → 执行一个步骤 → 产生一个产物
→ 执行对应审查 → 通过后解锁后继步骤

这也就是「分析 → 编排 → 执行 → 反馈 → 修正」落成的工程结构。

与其他线的关系

  • 与 07-工程控制/01：工程控制讲反馈闭环（目标→实际→偏差→检查→修正→再验证）；本篇把「检查→修正」落成可执行的 STEP/REVIEW 结构——是反馈闭环的工程化实现
  • 与 07-工程控制/02：过程与流程讲步骤组织的概念；本篇给出每个步骤的原子定义与状态机
  • 与 06-设计/07：CLI 流程的「API 缺口→阻塞→回跳静态库」就是 STEP 状态机（BLOCKED → RETURN）在 CLI 上的实例
  • 与 06-设计/06-七个分析维度：七个维度（结构/调用链/启动链/生命周期/数据流/业务流/状态变化）是步骤图里各步骤的审查对象
  • 与 03-建模与逆向/04：模型转为流程（依赖→拓扑排序→步骤）产生步骤图；本篇定义步骤的原子结构与状态机

收束

1
2
3
4
5
6
7
8
9
步骤 = 输入 + 前置条件 + 目标 + 约束 + 操作 + 输出 + 验证
审查 = 对明确对象的明确属性做验证

原子化：一个 STEP 只做一件事，一个 REVIEW 只检查一件事
依赖图：前置依赖 + 输出 + 后继步骤 = DAG（不是流水线）
小闭环：输入 → 做 → 输出 → 审查 → 通过→后继 / 不通过→返回

STEP/REVIEW 关键字 + 状态（PENDING/READY/RUNNING/BLOCKED/FAILED/PASSED/REJECTED）
= 可被人工、程序、Agent 一致执行和审查的控制流程

工程流程从「文字描述」变成「可执行步骤图」的关键，不是更多概念，而是每个步骤的原子定义和每个审查的明确对象。