桌面开发的核心命题是什么？不是 UI 框架的选择，不是编程语言的优劣，而是交互范式的演进。从架构的视角审视，无论终端设备是 PC、手机、手表还是 IoT 设备，无论开发方式是 Native、Web 还是小程序，它们的本质都是同一件事：通过交互设备接收用户输入，通过计算处理业务逻辑，通过输出设备呈现结果。
许式伟指出，桌面操作系统与服务端操作系统的演进方向截然不同——服务端追求简约与稳定，而桌面操作系统的演进方向是交互范式的迭代，向着越来越自然、越来越智能的交互前进。理解这一宏观趋势，是架构师做出正确技术决策的前提。
一个桌面程序完整的架构体系可以统一表示为：
这个统一模型的关键洞察在于：不同交互范式的桌面程序，差异集中在输入输出设备的组合方式和操作系统交互子系统的接口设计上，而应用层的业务逻辑架构是相对稳定的。
交互范式的演进，本质上是输入输出抽象粒度不断细化的过程：
| 交互范式 | 输入抽象 | 输出抽象 | 输入设备 | 输出设备 |
|---|---|---|---|---|
| 命令行 | 以回车结尾的文本行 | 文本流（stdout/stderr） | 键盘 | 显示器 |
| 字符界面 | 键盘按键事件 | M×N字符网格 | 键盘 | 显示器 |
| 图形界面 | 键盘事件+鼠标事件 | M×N像素网格 | 键盘+鼠标 | 显示器+音箱 |
| 触摸界面 | 触摸事件+键盘事件 | 像素网格 | 触摸屏 | 内置扬声器 |
| 智能交互 | 语音+视觉+触摸 | 像素+语音 | 麦克风+摄像头+触摸屏 | 屏幕+扬声器 |
选择命令行、图形界面还是智能交互，决定了程序的整体架构骨架。不同范式之间的迁移成本极高——例如从命令行迁移到图形界面，不只是换了输出方式，而是引入了窗口系统、事件驱动循环、GDI 绘制等一整套全新的编程模型。
Trade-off 分析：
| 维度 | 命令行 | 字符界面 | 图形界面 | 智能交互 |
|---|---|---|---|---|
| 开发复杂度 | 低 | 中 | 高 | 极高 |
| 用户学习成本 | 高 | 中 | 低 | 最低 |
| 可自动化程度 | 最高 | 高 | 低 | 最低 |
| 表达能力 | 有限 | 中等 | 强 | 最强 |
| 操作系统依赖 | 最低 | 低 | 高 | 极高 |
图形界面程序的核心编程模型是事件驱动。操作系统通过事件队列将硬件中断转化为结构化事件，应用程序在事件分派循环中响应事件、更新状态、重绘界面。
这意味着：桌面程序的控制流不再由业务代码主导，而是由操作系统的界面框架主导。业务代码成为框架的"插件"，被框架调用而非主动调用框架。这对架构设计有深远影响——参见第21讲：图形界面程序的框架。
语音交互目前与图形界面交互无法良好融合，原因有二：
这揭示了一个架构规律：当两个框架都试图主控程序生命周期时，融合的难度将指数级增长。 这与微服务中"一个服务只能有一个 BFF 层"的道理一致。
从字符网格到像素网格，输出精度提升了数个数量级。这一跃迁直接导致了：
命令行交互时代，编辑器是最典型的"反人类"需求场景。在文本行输入模式下，如何实现光标移动、文本选择、复制粘贴？Vim 的模式切换（Normal/Insert/Visual）是一种精巧的妥协——用组合键模拟了图形界面的交互能力，但学习曲线陡峭。
这个案例说明：当交互需求超越了当前交互范式的能力边界时，要么升级交互范式，要么用复杂的约定来弥补——后者往往是技术债的源头。
在 IoT 项目中，常见错误是为语音交互设备设计图形界面式的架构——引入完整的窗口系统和 GDI 渲染管线，只为在 2 英寸屏幕上显示几行文字。正确的做法是根据交互设备选择最小够用的交互范式，避免架构过度设计。
许式伟预判，未来智能交互不会止步于语音，而是视频交互（兼顾视觉和听觉）与触摸屏的完美融合。交互设备将是触摸屏+摄像头+麦克风+内置扬声器的组合。这意味着未来的桌面程序架构需要同时处理触摸事件流、语音输入流、视觉输入流，并在统一的事件驱动框架中进行融合与响应。
交叉引用：本章讨论的交互范式演进，直接决定了第21讲中图形界面框架的设计，也影响着第22讲中 MVC 架构的分层策略，以及第23讲中浏览器对窗口系统的颠覆。