本篇要回答的问题：桌面程序最核心的话题是交互。从命令行到字符界面、图形界面、再到智能交互，交互范式经历了哪几次迭代？ 每一次变化的根源是什么？
第一章"基础平台篇"收官后，本讲开启第二章"桌面软件开发"。这里的"桌面程序"是广义的——无论 PC、手机、手表，无论 Native、Web 还是小程序，统称桌面程序。其最核心话题是交互，而交互范式恰恰是桌面操作系统中最不稳定、迭代最频繁的部分。
补：先建立画面（原文缺的一层）
原文按时间顺序罗列了四种交互范式，但没说这四段历史是被什么推着走的，也没说这跟"我今天写代码"有什么关系。补一层画面，2026-08-29 在本机实测。
一句话：这讲不是交互史，是"最小单位决定骨架"
输入输出的最小单位每换一次，程序的骨架就得重写一次。 四个时代就是四次换单位：
| 时代 | 输入的最小单位 | 输出的最小单位 | 程序骨架长什么样 |
|---|---|---|---|
| 命令行 | 一整行文本（按回车才算数） | 一行文本，只能往后追加 | 一根直线：读→算→写→退出 |
| 字符界面 | 一次按键（按下/抬起各算一次） | 一个字符格子，任意位置可改写 | 一个循环：等按键 → 改屏幕 |
| 图形界面 | 一次点击/移动/触摸（带坐标） | 一个像素 | 一个死循环 + 一堆回调 |
| 智能交互 | 一句话 / 一段视频（带上下文） | （还没定型） | 又一个死循环，跟上面那个抢主人位 |
为什么"输出粒度"是分水岭：每代的杀手应用，都是被上一代粒度卡住的那个
- 命令行只能往下追加，回不了头改中间的字 → 所以做不出编辑器。原文说"最典型的就是编辑器"，指的就是这个物理限制。
- 字符界面给了你能随机寻址的屏幕（M×N 个格子，指哪改哪）→ 编辑器立刻成立，vi 就是这么来的。
- 字符格子太粗 → 做不了游戏。像素一来，游戏立刻成立。
关键判断：不是"人们想要更好看"，是上一代的输出粒度物理上卡死了某类需求，卡到疼了才换代。
全章最该带走的一条：控制反转，谁调用谁
命令行程序 图形界面程序
main() { main() {
读输入 ← 你是主人 建窗口
算 RunLoop() ← 这行永不返回，主人是操作系统
写输出 }
} ← 程序会结束 onClick() { ... } ← 你的代码碎成一堆回调
onPaint() { ... } 被那个循环喊起来干活
一句话：命令行是你调用操作系统，图形界面是操作系统调用你。
这条直接解开原文结尾最费解的那句——“框架侵入性强、彼此难融合，所以语音交互自成体系”：
一个进程只能有一个主循环。 图形界面框架要占着这个位置，语音框架也要占着，谁都不肯当被调用的那一方 → 融不了。不是技术不够，是主人的位置只有一个。
（现代的解法是：谁都别当主人，大家一起往同一个 event loop 上挂回调——这正是 JS 和 asyncio 走的路。）
想真正搞懂"图形界面程序为什么长这样"，去看 21 讲笔记的第一部分——那里从一个三行的加法器脚本出发，一步步把整套框架长出来（收件箱、循环、窗口、焦点、onPaint、GDI 全是被逼出来的）。这一讲只需要记住：输入输出的最小单位变了，骨架就得重写。
实验一：命令行的输出为什么"肉眼分不出来源"
python3 -c "import sys; print('我是 stdout'); print('我是 stderr', file=sys.stderr)"
# 直接看屏幕：不但分不出来源，连顺序都乱了（stderr 不缓冲，抢在前面）
我是 stderr
我是 stdout
# 分开重定向：立刻泾渭分明
$ ... 1>o.txt 2>e.txt
o.txt => 我是 stdout
e.txt => 我是 stderr
# 管道只搬运 stdout，stderr 直接漏到屏幕上
$ ... | sed 's/^/[管道收到] /'
我是 stderr ← 没进管道
[管道收到] 我是 stdout
stdout 和 stderr 本来就是两根独立的管子，只是屏幕默认把它们并到一起了。这就是原文说"重定向/管道"时真正在说的事。
实验二：一行 vs 一次按键——"输入的最小单位"是真的会变
终端有两种模式：cooked（行模式，命令行程序默认） 攒够一行才交货；raw（裸模式，字符界面用） 按一下就交货。
import os, pty, tty, select, time
def probe(raw):
m, s = pty.openpty()
if raw: tty.setraw(s) # 切到裸模式
os.write(m, b"abc") # 模拟敲了 a b c，但【没按回车】
time.sleep(0.1)
ready, _, _ = select.select([s], [], [], 0.2)
return repr(os.read(s, 100)) if ready else "(什么都没拿到，还在等回车)"
print("行模式 cooked ->", probe(False))
print("裸模式 raw ->", probe(True))
行模式 cooked(命令行程序默认) 敲 abc 不回车 -> (什么都没拿到，还在等回车)
裸模式 raw (字符/图形界面) 敲 abc 不回车 -> b'abc'
再看特殊键在终端里到底发了什么字节（curses.tigetstr 本机实测）：
| 你按的键 | 终端实际发出的字节 |
|---|---|
| 普通字母 a | b'a' |
| Ctrl-A | b'\x01' |
| 方向键 ↑ | b'\x1bOA'（三个字节的转义序列） |
| Home | b'\x1bOH' |
| F1 | b'\x1bOP' |
关键洞见：终端只有一条字节流，没有"按键事件"这种东西。方向键、功能键只能靠
ESC开头的转义序列混在文本里传——这就是原文说"字符界面靠扩展键/组合键输命令"的物理真相。你现在用的 vim、htop、Claude Code 本身都是字符界面程序，都把终端切到了 raw 模式，自己解析这些序列。
跟我现在做的东西对得上的地方
| 我在做的 | 属于哪一代 | 意味着 |
|---|---|---|
| CLI 版 Agent（读参数、打日志） | 命令行程序 | 直线骨架，程序会结束 |
| 想做 TUI（像 Claude Code 那样） | 字符界面程序 | 得自己切 raw 模式、解析转义序列 |
| Web 前端 / Electron / 手机 App | 图形界面程序 | 骨架就是第 21 讲那个死循环 |
| 语音 Agent | 智能交互 | 它自带"听—想—说"的循环，天然跟界面的循环抢主人位——原文 2019 年下的判断，今天依然成立 |
交互范式的四次演进
| 范式 | 交互设备 | 输入 | 输出 | 致命局限 |
|---|---|---|---|---|
| 命令行 | 键盘+显示器 | 以回车结束的文本（命令行/stdin） | 文本（stdout/stderr） | 反人类，编辑器场景头疼 |
| 字符界面 | 键盘+显示器 | 键盘按键事件（KeyDown/KeyUp） | 改写 M×N 格子里的字符 | 游戏类场景能力有限 |
| 图形界面 | 键盘+鼠标+显示器+音箱 | 键鼠/触摸事件 | 像素（更高精度 M×N 格子） | —— |
| 智能交互 | 触摸屏+麦克风+摄像头+扬声器 | 语音/视频 | —— | 与图形界面框架不相容 |
命令行交互
输入被抽象为以回车结束的（通常单行）文本，方式有二：命令行、标准输入（stdin）；输出可能是 stdout 或 stderr（肉眼不可区分）。
关键特征：命令行程序的输入输出可被重定向——输出可写入文件，也可通过管道重定向为另一程序的输入。
字符界面
输入变为键盘按键事件，输出变为可修改屏幕任意位置的字符。键盘功用分化为两个：输入文本、输入命令（扩展键/组合键）；输入文本需要光标 Caret。
关键概念：TDI（字符设备接口，Text Device Interface）——一组向屏幕绘制文本的方法集合，如
ClearScreen()、DrawText(x, y, text)。
图形界面
关键判断：与字符界面相比，图形界面变化的根源是输出的变化——从字符变成像素。这是划时代的变化。
由此引发的连锁变化：
| 变化 | 原因 |
|---|---|
| 出现鼠标 | 屏幕精度太高，键盘方向键移动既笨拙又不自然 |
| 出现音箱 | 声音设备演进的自然结果（字符时代主板已有喇叭） |
| 多窗口 | 窗口（View）是独立可复用的界面元素，可切分子窗口降复杂度 |
关键洞见：一旦有了窗口的父子/兄弟关系，就有了窗口系统，交互变复杂（如键鼠事件的目标窗口判定）。为降低负担，窗口系统往往接管主逻辑，提供基于事件驱动的编程框架，业务代码由界面框架驱动。
关键概念：GDI（图形设备接口，Graphic Device Interface）——一组向指定窗口（注意不是屏幕）绘制图形/图像/文本的方法集合。
移动时代的变化：交互设备变为触摸屏+麦克风+内置扬声器，键鼠显示器能力融合到触摸屏。但从架构看没有实质性变化——只是鼠标事件变成了触摸事件。
智能交互
麦克风带来语音输入，有三种典型用法：① 录制为媒体消息或识别为文本；② 语音输入法；③ Siri 式语音助手。
关键判断：语音交互自成体系，与图形界面框架不相容，原因有二：① 语音交互上下文很强，业务代码由语音框架驱动，而框架侵入性强、彼此难融合；② 语音交互尚不成熟，独立发展更简单，成熟后可重写框架与触摸屏结合。
未来交互可能不止于语音，而是视频（兼顾视觉听觉）+ 触摸屏完美融合：
总结
桌面程序最核心的话题是交互，交互范式经历命令行→字符界面→图形界面→智能交互四次剧烈演进。每次变化都有明确根源：命令行→字符是输入从文本变按键事件，字符→图形是输出从字符变像素（连带催生鼠标、音箱、多窗口），图形→智能是新增语音/视频维度。交互体验越来越自然，但没有操作系统支持则实现难度越来越高。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 重定向/管道 | 命令行程序输出可写文件或接入另一程序输入 |
| TDI | 向屏幕绘制文本的方法集合 |
| GDI | 向指定窗口绘制图形的方法集合 |
| 窗口系统 | 窗口有父子/兄弟关系后形成、并接管主逻辑的事件驱动框架 |
| 智能交互 | 语音/视频驱动、自成体系、暂与图形界面不相容 |
一句话速记
命令行→字符是"输入变按键"，字符→图形是"输出变像素"催生鼠标多窗口，图形→智能是"新增语音视频"自成体系——交互越自然，越离不开操作系统。
几条值得记住的判断
- 图形界面的根源是输出从字符变像素，鼠标/音箱/多窗口都是连锁结果。
- 窗口系统接管主逻辑，业务代码被事件驱动框架反向驱动。
- 框架侵入性强、彼此难融合，这正是语音交互暂时自成体系的原因。
思考题
桌面操作系统的演进方向是交互范式迭代，而服务端操作系统几乎不演进交互（命令行就够）。回到你做的产品：当一种更自然的交互范式（如语音、视频）成熟时，你现有的事件驱动框架是能平滑融合它，还是注定要被"重写框架"？提前想清楚这一点，会影响你今天的抽象选择。
