过程与流程——变化、步骤、方法与实现的层次

一句话

过程回答「系统要经历什么变化」；流程回答「我们按什么步骤让它发生」；方法回答「每一步采用什么技术」；实现则是最终的代码。

一、过程 vs 流程

  • 过程（Process）：描述「事情是怎样发生和变化的」——对象状态的变化。
  • 流程（Flow / Workflow）：描述「步骤按什么顺序执行」——人为设计的控制结构。

从例子理解（做饭）

过程：

1
2
买菜 → 洗菜 → 切菜 → 炒菜 → 装盘        （事情的发展过程）
食材状态：生菜 → 洗净 → 切块 → 加热 → 熟菜（对象状态的变化）

流程：

1
2
3
开始 → 选择菜单 → 买菜 → 做菜 → 吃饭 → 结束
有菜？├─ 是 → 做饭
      └─ 否 → 买菜

核心区别对照表

方面 过程 流程
关注点 变化 顺序
研究对象 状态演化 步骤组织
问题 发生了什么变化 先做什么后做什么
表达 状态、阶段 节点、连线
强调 因果 控制

软件中的区别

例子 属于 关注点
程序执行流程 if/else 流程（控制流） 判断、分支、顺序
图片处理 原图→解码→缩放→滤镜→编码→输出 处理过程 数据如何变化
用户使用软件 打开→登录→选择文件→处理→导出 用户流程 用户操作顺序
软件开发 需求→设计→编码→测试→发布 开发流程 步骤组织
软件形成 想法→需求→方案→代码→软件诞生 软件形成过程 状态变化

过程 = 时间上的变化；流程 = 人为设计的控制结构。

二、过程 / 流程 / 方法 / 实现的层次

以「横版平台游戏」为例：

层次 内容
目标 制作一个横版平台游戏
过程 运行环境→图形→输入→运动→角色→场景→碰撞→游戏规则→完整游戏
流程 Canvas→方块→键盘→重力→图片→Tile→Camera→Enemy→Level
方法 Canvas 2D / requestAnimationFrame / Image / KeyboardEvent / AABB Collision / Camera Offset
具体实现 player.x += player.vx; player.y += player.vy;

关键区分

过程具有阶段性和演化关系；流程具有实现选择性。

「实现角色移动」这个过程阶段可以保持不变，但流程可以是：

1
2
3
流程 A：直接修改坐标      按键 → 修改 x → 重新绘制
流程 B：速度模型          按键 → 改变 velocity → 物理更新 → 改变 position → 绘制
流程 C：物理引擎          输入 → CharacterController → Physics → Transform → Renderer

过程阶段相同，流程不同。

不过「必经」也不能绝对化——一个游戏完全可以没有砖块、没有敌人。更准确：

过程描述目标系统从一种状态到另一种状态的演化阶段；流程是实现这种演化所采用的具体步骤和组织方式。

演化链：每一步在前一状态上增加新能力

1
2
3
4
5
6
7
8
9
空窗口
    + 绘制 → 方块
    + 输入 → 移动方块
    + 物理 → 跳跃方块
    + 资源 → 角色
    + 碰撞 → 平台游戏
    + 场景 → 关卡
    + AI   → 敌人
    + 游戏规则 → 完整游戏

这接近：软件不是直接从「需求」跳到「完整程序」，而是通过一系列可运行的中间状态逐渐演化出来。

「空窗口 → 方块 → 可移动方块 → 会跳的方块 → 角色 → 地面 → 关卡 → 敌人 → 完整游戏」应称为：「从零到完整游戏的能力演化链」，而不是简单的「游戏开发流程」。

三、三种起点：演化 / 复刻 / 原创

类型 起点 核心问题
演化过程 空程序 软件需要逐渐获得什么能力？
复刻流程 已有软件 怎样通过观察把已有东西还原出来？
原创流程 想法 怎样把不存在的东西设计并制造出来？

① 演化流程

「空窗口 → 方块 → 角色 → 关卡 → 完整游戏」最有价值的地方，就是它天然适合作为软件从零开始的最小可运行演化过程：每个节点都应是「已经能运行、能验证、再继续增加能力」的版本，而不是堆完代码才第一次运行。

一条完整的细分流程 = 在每一个演化阶段，明确「输入 → 操作 → 产物 → 验证」，并不断在上一阶段的可运行成果上增加能力。

（游戏的实现 21 阶段见 12-游戏/01-游戏系统论·一·B：显示 → 输入 → 时间 → 资源 → 动画 → 地图 → 摄像机 → 碰撞 → 渲染排序 → 对象系统 → 组件化 → 物理 → AI → 规则 → UI → 音频 → 存档 → 脚本 → 编辑器 → 网络 → 引擎）

② 复刻流程

复刻时已经不该从「先创建 Canvas，再画一个方块」开始（那是演化流程），而应从「我要复刻什么？」开始（复刻起点的完整展开见 04-复刻软件：八个阶段/探索空间收敛/复制层级/护城河/复刻规格）：

1
目标分析 → 成品规格 → 系统分解 → 总流程 → 阶段 → 并行子流程 → 集成 → 测试 → 发布

关键：复刻有「原程序」作为答案，所以每个阶段都可以对比验证。复刻的是行为，不需要复刻原程序内部结构——原程序 Win32+C++，你可以 Qt+C++ 甚至 HTML+CSS+JS。

并行子流程：

1
2
3
4
5
6
7
              核心原型
    ┌─────────────┼─────────────┐
    ↓             ↓             ↓
程序子流程      美术子流程      音频子流程
    └─────────────┼─────────────┘
                  ↓
                 集成 → 可玩版本

「并行不是把总流程打乱，而是在总流程的某个阶段产生多个相互独立的子流程。」子流程之间通过产物进行衔接。工程中的「并行」本质是：把总任务分解成具有依赖关系的子任务，然后让没有依赖关系的子任务并行执行。

最终层级：

1
目标 → 过程 → 总流程 → 阶段 → 子流程 → 任务 → 操作 → 产物 → 验证

③ 原创流程

原创要回答：「这个东西原本不存在，我们怎样从一个模糊想法，创造出目标、规则、系统、内容，最后创造出成品？」

1
2
3
① 创意 → ② 概念 → ③ 产品定义 → ④ 游戏设计 → ⑤ 技术设计 → ⑥ 原型验证
→ ⑦ 项目立项 → ⑧ 生产规划 → ⑨ 核心系统开发 → ⑩ 内容生产 → ⑪ 集成
→ ⑫ Alpha → ⑬ Beta → ⑭ 打磨 → ⑮ 发布 → ⑯ 运营/更新

与复刻最大的区别：复刻有「原程序」作为答案，原创没有——所以原创流程中间会多出大量「设计 → 判断 → 原型 → 验证 → 修改」。

关键概念：

  • 概念验证：不要马上进入正式生产，先问「这个想法真的好玩吗」——核心想法 → 抽象核心机制 → 制作最小原型 → 试玩 → 观察 → 调整。只做「一个房间 + 一个方块 + 一个角色 + 一个按钮」，甚至不要美术。目标是验证核心乐趣。
  • Alpha：核心玩法/主要系统/基本关卡/游戏流程完整跑通——「游戏完整地跑通了吗」（启动→主菜单→开始→选关→游戏→死亡→重来→通关→结束）
  • Beta：功能完整后关注体验完整（Bug/性能/平衡/难度/手感/UI/音效/动画/关卡节奏）
  • 依赖关系决定并行：设计产物是程序和美术的输入——角色设计 → 角色状态定义 → 程序状态机 / 美术动画

四、理论与实践的层次

一个重要的修正

理论不是「忽略细节」，而是「有选择地忽略不影响当前决策的细节」；实践则是在具体执行中不断处理那些理论阶段尚未展开的细节。

理论设计：建立「问题空间的压缩模型」

1
2
总体目标 → 系统边界 → 主要对象 → 主要关系 → 阶段划分
→ 总体流程 → 职责划分 → 规范 → 方向 → 约束

这个阶段不需要知道「按钮距离左边 17px 还是 18px」——这个细节不会改变总体架构。理论分析建立的是一个低分辨率、低成本、可推演的系统模型。

实践设计：把模型展开成可执行对象

1
2
具体做什么？→ 由谁做？→ 使用什么接口？→ 怎么实现？→ 输入/输出？
→ 异常怎么办？→ 实际效果怎么样？

理论上的「图片查看器 → ImageService → ImageView」，实践中会变成：文件是否存在？什么格式？哪个 Decoder？内存怎么分配？失败返回什么？Loading 怎么表示？UI 怎么刷新？大图片会不会卡？实践把理论模型展开成大量具体知识。

实践最重要的是「反馈」

1
2
理论：设计 → 预测 → 方案
实践：设计 → 实现 → 运行 → 观察 → 反馈 → 修改

不是「理论 → 实践 → 结束」，而是一个闭环：理论 → 指导实践 → 实践产生反馈 → 修正理论 → 更好的实践 → 新的反馈。

与大模型的类比

软件工程 大模型
理论知识 预训练获得的通用知识
理论分析 根据已有知识建立问题模型
总体设计 形成解决方案/计划
规范与约束 Prompt、规则、上下文约束
实践 实际执行任务
实践反馈 编译错误、测试结果、运行结果
修正 根据反馈重新规划

一个「会干活的智能体」：预训练 → 通用知识模型 → 理论分析/规划 → 实践执行 → 环境反馈 → 重新分析 → 再次实践 ↺

五、完整认知框架

1
2
3
4
5
6
7
8
9
10
11
12
13
过程 vs 流程（变化 vs 顺序）
    ↓
过程 → 流程 → 方法 → 实现（层次）
    ↓
演化 / 复刻 / 原创（三种起点）
    ↓
游戏：演化细分流程 / 复刻总流程+子流程 / 原创团队流程
    ↓
GUI：演化过程 / 演化实现流程 / 复刻流程 / 原创流程
    ↓
理论（压缩复杂度）vs 实践（展开复杂度 + 反馈）
    ↓
反馈闭环
概念 回答的问题
过程 系统要经历什么变化
流程 按什么步骤让变化发生
方法 每一步采用什么技术
实现 最终代码
演化 能力如何逐渐形成
复刻 已有东西如何被还原
原创 不存在的东西如何被创造
理论 较高抽象层确定方向和结构（压缩复杂度）
实践 把结构展开成具体行动（展开复杂度）
反馈 把现实结果重新输入系统，修正理论和实践

与其他线的关系

  • 与工程控制线：过程与流程是「被控制的对象」，工程控制是「控制的手段」——反馈闭环作用在流程上
  • 与游戏系统论：游戏的演化细分流程是过程与流程在游戏领域的具体展开
  • 与从指令到系统主线：主线三篇本身就是「演化过程」（能力逐渐形成）；过程与流程线讲这套演化过程的方法论
  • 与建模与逆向主题：演化 ≈ 正向建模（具体→抽象→模型），复刻 ≈ 逆向应用（模型→解构→具体）
  • 与 GUI-MVVM（04-系统角色/08）：GUI 的演化过程（窗口→控件→交互→状态→数据→功能→用户流程→完整应用）是过程与流程在 GUI 上的实例