GUI 的演化与三条流程——能力成长、实现路径与三种起点

一句话

过程与流程的区别（07-工程控制/02-过程与流程）在 GUI 上的展开：GUI 的演化过程固定（窗口→控件→交互→操作→状态→数据→功能→用户流程→完整应用），实现流程不唯一（Win32+MVC、Win32+MVVM、Qt+MVVM、ImGui+自定义、WebView+前端）；而「做一款 GUI」有三种起点——演化（从空程序长能力）、复刻（从已有程序还原）、原创（从想法创造）。

一、GUI 的演化过程：能力逐渐形成

演化过程描述的是：GUI 从一个「能显示窗口的程序」，逐渐获得成为「可用软件」的能力。

1
2
3

空白程序 → 可启动窗口 → 可显示内容 → 可接受输入 → 可执行操作
→ 可显示状态 → 可管理数据 → 可组织多个功能 → 可处理完整用户流程
→ 可配置 → 可恢复 → 可处理异常 → 完整 GUI 应用

十个阶段逐一看：

1. 运行环境

main() → 创建窗口 → 消息循环。此时程序只有存在性（能启动，还不能完成什么）。

2. 显示能力

加入 Label/Button/TextBox/Menu/Toolbar/List/Tree，程序获得信息呈现能力。

3. 输入能力

Mouse → Button → Event
Keyboard → TextBox → Text
Menu → Command
用户 → GUI → 事件

程序获得用户交互能力。

4. 操作能力

不能只是「点击按钮 → 弹 MessageBox」，而应真正执行任务：

1 2	用户 → 点击「打开」→ 文件选择 → 读取文件 → 解析 → 显示（文本编辑器：打开文件 → 读取 → 解析 → Document → TextView）

GUI 成为应用程序的操作入口。

5. 状态

1
2
3

文件状态：Clean → Modified → Saving → Saved
窗口状态：Normal / Maximized / Minimized
操作状态：Idle / Loading / Processing / Success / Error

GUI 从「控件 + 点击事件」变成「状态 → 用户操作 → 状态变化 → 界面变化」（即状态流转）。

6. 数据

1 2	GUI → Application → Domain/Data （编辑器：TextBox → Document → Paragraph → File）

GUI 开始拥有对领域对象的操作能力。

7. 功能系统

一个真正的软件不会只有一个按钮。文件管理器出现「文件/编辑/查看/设置」等功能体系，GUI 也需要 Navigation/Command/Service/Domain/Infrastructure。

8. 用户流程

功能多了以后，单独的功能不够：

1	创建项目 → 填写名称 → 选择路径 → 创建 → 加载 → 编辑 → 保存

它解决「用户怎样使用多个功能完成一个目标」。

9. 复杂状态

1	打开文件 → 加载中 → 加载成功 → 用户修改 → 未保存 → 关闭 → 提示保存（保存/不保存/取消）

GUI 出现大量状态、状态转换、异常、异步操作、对话框、确认、回滚——从「控件集合」演化成「状态机 + 用户流程 + 领域操作的可视化系统」。

10. 完整应用

GUI Application
├── View（Controls）
├── State（ViewModel → Domain）
└── Command（Service → Infrastructure → Data）

压缩后的演化链

1 2	空程序 → 窗口 → 控件 → 输入 → 命令 → 操作 → 状态 → 数据 → 功能 → 用户流程 → 领域系统 → 异常/恢复 → 配置/持久化 → 完整应用

更抽象：

1	存在 → 显示 → 交互 → 操作 → 状态 → 数据 → 功能 → 流程 → 系统 → 产品

为什么 GUI 会自然出现 MVVM 分层

当 GUI 从「窗口 + 控件」继续演化成「完整应用」时，界面、状态、业务、数据、外部系统的复杂度必然逐渐分离，于是架构层次就自然产生了。

所以 MVVM 不是 GUI 的起点，而更像是 GUI 演化到一定复杂度之后，对「界面—状态—数据—操作」关系进行组织的一种结构（与 04-系统角色/08 第七节呼应）。

GUI 与游戏的演化对比

1
2

游戏核心演化：渲染 → 输入 → 运动 → 物理 → 实体 → 世界 → 规则 → 玩法
GUI 核心演化：渲染 → 输入 → 命令 → 操作 → 状态 → 数据 → 功能 → 用户流程

         软件演化
   ┌────────┴────────┐
   ↓                 ↓
  游戏               GUI
世界/实体          数据/功能
物理/规则          状态/命令
  玩法             用户流程
   └────────┬────────┘
            ↓
         完整产品

二、GUI 的演化实现流程：从演化过程中选一条路径

演化过程回答「能力怎么成长」，实现流程回答「按什么步骤让这些能力出现」——过程是必经的阶段，流程不唯一（实现可以是 Win32+MVC、Win32+MVVM、Qt+MVVM、ImGui+自定义架构、WebView+前端架构等）。

总流程

需求 → 需求分析 → 用户流程设计 → 功能分解 → 领域模型设计 → GUI 信息架构
→ 界面结构设计 → 交互设计 → 状态设计 → 技术架构设计 → 工程建立
→ 基础设施实现 → 领域/算法实现 → 应用服务实现 → GUI 框架实现
→ View 实现 → ViewModel/Controller 实现 → 命令与事件连接 → 功能集成
→ 异常处理 → 持久化/配置 → 测试 → 体验调整 → 性能优化 → 打包发布

以「Windows 图片查看器」为例的要点：

从想法进入需求：用户是谁、要完成什么、核心任务、有哪些功能 → 功能清单（打开/查看/上一张/下一张/缩放/旋转/删除/设置）。
建立用户流程（User Flow）：启动→选择图片→加载→显示→操作→退出。
功能分解：用户流程 → 系统功能（文件/查看/导航）→ 拆到「Open → FileDialog → FilePath → ImageLoader → Image → ImageView」。
设计数据和领域对象：Image/ImageFile/ImageCollection/ImageMetadata/ViewState（如 Image 含 width/height/format/pixels）。
设计 GUI 信息结构：MainWindow → MenuBar/ToolBar/ImageView/StatusBar/SidePanel（GUI 信息架构）。
设计交互：定义「点击 Open → 文件对话框 → 选择 → 加载 → 显示」及异常（加载失败→显示错误→保持当前图片），建立交互规则 + 状态转换。
设计状态机：ViewerState（Empty→Loading→Displaying→Error），按钮状态由状态决定（Empty 时 Next/Zoom disabled）。
技术架构设计：Application → View/ViewModel/Service/Domain/Algorithm/Infrastructure/Utils。
建立工程：src/ 下 main.cpp + view/viewmodel/service/domain/algorithm/infrastructure/utils + tests/assets/docs。
基础设施先行：FileSystem、ImageDecoder 先做接口（openFile/readFile/decodeImage）并独立验证——这部分甚至可以不依赖 GUI 测试。
Domain / Algorithm：Image→Scale→Rotate→Crop（ImageTransform），单独测试「输入图片→算法→输出图片」。
Application / Service：ImageService（open/next/previous/rotate/delete），得到没有 GUI 也能运行的业务能力。
GUI 框架和 View：MainWindow/MenuBar/ToolBar/ImageView/StatusBar，只解决页面结构、控件、布局、绘制、样式。
ViewModel / Controller：View ↕ ViewModel ↕ Service，串起「用户操作→应用行为→状态→UI」。
建立命令和事件：把 Open/Next/Previous/ZoomIn/ZoomOut/Rotate/Delete 统一成 Command，让 Menu/Toolbar/Keyboard/ContextMenu 都调用同一命令（避免菜单/按钮/快捷键三套逻辑不一致）。
功能集成（纵向切片）：按功能逐个贯通 Open/Zoom/Next，比「先写完所有 View 再写所有 Service」更容易验证。
异常、状态、恢复：补齐文件不存在/格式错误/权限不足/加载失败/没有下一张，定义 Loading/Success/Error/Empty 与 Retry/Cancel/Close。
持久化和配置：窗口大小/位置/主题/最近文件/缩放方式，建立 Settings→Serializer→Config File。
测试：Domain Test/Algorithm Test/Service Test/ViewModel Test/Integration Test/UI Test/E2E Test。
GUI 体验调整：布局/间距/字体/图标/颜色/动画/快捷键/鼠标行为/反馈/错误提示（与游戏「手感调整」类似）。

压缩后的实现流程

想法 → 需求 → 用户目标 → 用户流程 → 功能分解 → 领域对象 → 状态模型
→ GUI 信息架构 → 界面设计 → 交互设计 → 技术架构 → 工程建立
→ 基础设施 → Domain/Algorithm → Service → View → ViewModel/Controller
→ Command/Event → 功能纵向集成 → 异常与恢复 → 持久化 → 测试
→ 体验调整 → 性能优化 → 打包 → 发布

团队版本不是一条直线

技术设计之后进入「总流程 + 子流程」：

项目总流程
├── 设计子流程（用户流程/状态模型/功能规格）
├── 程序子流程（Domain/Service/ViewModel/View）
└── 美术/UI子流程（页面/控件/样式/图标）
        ↓ 集成 → 测试 → 反馈 → 修改

核心结论：GUI 的实现流程本质上是一个工程控制结构——先把目标变成规格，再把规格变成结构，再把结构变成子流程，再让子流程产生可集成的产物，最后通过验证把结果反馈回设计（与 07-工程控制/01 的反馈闭环一致）。

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

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

演化流程：GUI 从空程序逐渐获得能力（本文第一节）。
复刻流程：已有 GUI → 观察 → 分析 → 还原 → 实现 → 对比（完整展开见 07-工程控制/04-复刻软件·七：GUI 复刻从黑盒观察到复刻规格）。
原创流程：只有想法/需求 → 设计出不存在的 GUI → 实现 → 验证 → 成品。与复刻最大的区别：复刻有「原程序」作为答案，原创没有——所以原创流程中间会多出大量「设计 → 判断 → 原型 → 验证 → 修改」。

原创 GUI 的完整流程

想法 → 目标定义 → 用户/业务分析 → 需求分析 → 功能设计 → 用户流程设计
→ 信息架构 → 领域模型 → 状态模型 → 交互设计 → 界面设计 → 技术方案
→ 系统架构 → 工程建立 → 原型验证 → 核心功能实现 → GUI 实现
→ 功能集成 → 测试 → 体验调整 → 性能/稳定性 → 发布

以「原创一个 Windows 图片管理器」为例的要点：

想法：为什么做、解决什么问题、谁用、什么时候用、现有软件哪里不好 → 产品概念。
目标定义：模糊想法 → 目标用户/核心问题/核心目标（Product Goal）。
用户/业务分析：研究用户任务与现有问题，发现产品功能候选。
需求分析：问题 → 需求（项目管理/文件浏览/编辑）+ 非功能需求（启动速度/稳定性/平台/权限）→ Requirements Specification。
功能设计：需求 → 功能 → 输入/处理/输出（如 Search：Input→SearchService→SearchResult→ResultView）。
用户流程设计：用户如何使用功能完成目标 → 页面/导航结构。
信息架构：信息放在哪里（页面→区域→组件→控件）。
领域模型：从 UI 往下看，软件操作什么对象（Project/Folder/File/SearchQuery/EditorDocument）。GUI 是领域对象的可视化操作界面。
状态设计：项目（NoProject→Loading→ProjectOpened→NoProject）、文件（Closed→Opened→Modified→Saving→Saved）、搜索（Idle→Searching→Results）。
交互设计：把「用户→界面→命令→状态」连接起来，定义 Hover/Pressed/Disabled/Loading/Success/Error/Empty。
视觉设计：布局/尺寸/间距/字体/颜色/图标/组件样式/动画（原创问「什么界面最适合任务」，复刻问「原来按钮什么样」）。
技术设计：语言/GUI 框架/构建系统/数据库/文件格式/网络库/图形库/测试框架（如 C++/Qt/CMake/SQLite/GoogleTest）。
建立工程：src/（view/viewmodel/service/domain/algorithm/infrastructure/utils）+ tests/resources/docs/tools，建立编译/运行/测试/打包。
原型（关键）：不做完整软件，先做「最小 UI + 最核心用户流程」（启动→选项目→显示→打开→查看），验证用户看得懂、操作顺、页面合理、信息正确，发现问题就修改设计重新原型。
核心功能实现：FileSystem→ProjectService→Project→ProjectViewModel→ProjectView 等。
纵向功能切片：每完成一个功能（项目打开/文件搜索/文件编辑）就有一个可运行的垂直切片。
并行子流程：设计/程序/美术三线并行，由「需求→功能→用户流程→系统设计」产生任务。
集成：View+ViewModel+Service+Domain+Infrastructure+Resources → 完整功能 → 完整用户流程（应用层闭环）。
验证：原创没有原程序作标准，验证标准来自「需求+设计+用户目标」（功能/用户流程/状态/UI/交互/性能）。
反馈和迭代：设计→原型→实现→使用→反馈→发现问题→修改设计→重新实现（不是线性，而是迭代闭环）。

四、三个层次的最终对比

GUI 演化过程：窗口 → 控件 → 交互 → 操作 → 状态 → 数据 → 功能 → 用户流程 → 完整应用
GUI 复刻流程：已有程序 → 观察 → 分析 → 规格还原 → 系统设计 → 实现 → 对比 → 修正
GUI 原创流程：想法 → 目标 → 需求 → 功能 → 用户流程 → 信息架构 → 领域模型 → 状态
           → 交互 → 视觉 → 技术设计 → 原型 → 实现 → 集成 → 测试 → 反馈 → 迭代 → 发布

演化流程解决「能力怎么逐渐形成」；复刻流程解决「已有东西怎么被还原」；原创流程解决「一个不存在的东西怎么从想法逐渐被定义、设计、验证、实现并最终成为产品」。

而一旦进入团队，三种流程都可以进一步展开成：

1	总流程 → 阶段 → 子流程 → 任务 → 产物 → 依赖 → 并行 → 集成 → 验证 → 反馈

这基本就是软件工程全过程的结构骨架。

与其他线的关系

与过程与流程（07-工程控制/02）：本文是「过程 vs 流程、演化/复刻/原创三种起点」在 GUI 上的完整展开；游戏侧的展开见 12-游戏/02-游戏类型演化
与复刻软件（07-工程控制/04）：GUI 复刻流程的完整细节（黑盒观察→复刻规格→功能切片→四维对比验证）在 04-复刻软件·七，本文只保留三起点的定位
与 GUI 的 MVVM（04-系统角色/08）：演化过程第十阶段的「界面—状态—数据—操作」分离，正是 MVVM 自然出现的原因
与桌面端架构（10-桌面端架构/02、03）：实现流程中的 View/ViewModel/Service/Domain/Infrastructure 落点即各框架的七层架构；从纯 UI 开始的演化即本线演化过程在 Qt/Win32 上的实例
与领域模型（业务分析/08）：原创流程第 8 步「领域模型：GUI 是领域对象的可视化操作界面」与业务分析线互相印证