大船突然转向的时候，小船不跟着调整航向，唯一的结果就是被浪掀翻。今天下午，OpenAI 在开发者大会上扔了个核弹，GPT-4o 的实时语音和视觉 API 全面开放，价格还打骨折。我盯着直播，手心里全是汗，不是兴奋，是恐慌。我那个基于旧版 Whisper 和 DALL·E 接口封装的教育工具，交互逻辑在一瞬间变成了上个时代的古董。
用户不会再忍受“上传图片-等待分析-生成文字-再生成图片”这种断裂的流程了。GPT-4o 的 multimodal 是实时的、流式的，是“边看边说边改”。我之前的交互设计，是基于“任务链”的思维，一个接一个的模态切换。现在，这个基础被炸没了。我必须立刻把“链式”改成“池式”，让所有交互元素（语音输入、视觉输入、文本输出、图像生成）能在一个界面里并行、实时地流动起来。
第一个要动刀子的，就是那个该死的“上传”按钮。它必须消失。取而代之的是系统级的拖拽和实时摄像头调用。我花了三个小时，把 Electron 应用的前端框架从静态文件上传，改成了直接调用系统的 `getUserMedia` API 和 `ondrop` 事件。难点不在于代码，而在于权限处理的脏活。macOS 的沙盒、Windows 的摄像头隐私提示、浏览器的安全策略，每一层都得用 `try-catch` 包起来，失败后给出清晰的引导路径，而不是一个冷冰冰的“错误代码 1001”。用户粘性第一道关，就是别在第一步就把人卡死。
然后是“等待”状态的可视化。以前转个圈圈就行了，现在不行。流式响应意味着反馈也必须是流式的。我把语音识别的中间结果，用淡入淡出的方式实时显示在输入框下方；图片生成的过程，不再是一个进度条，而是用 Canvas 逐块渲染出从噪点到清晰图像的演变过程。这里用了 `requestAnimationFrame` 去模拟渐进加载，虽然本质上还是等 API 返回完整数据，但心理感知速度提升了不止一倍。用户需要“感觉”到机器在为他实时工作，而不是在“等待”一个黑箱结果。
最深的感触是，系统原生能力成了救命稻草。为了降低延迟，我彻底放弃了以前自己写的 websocket 重连逻辑，换成了更底层的 `EventSource` 配合 HTTP/2 服务端推送，就为了能吃上一点流式响应的红利。UI 框架里那些花里胡哨的动画库全删了，直接用 CSS `@keyframes` 和 `transform` 做最轻量的微交互。性能每优化掉 100 毫秒，用户在“对话流”中被打断的概率就降低一分。粘性就是这么一点一点抠出来的。
深夜两点，跑通了第一个完整流程。对着摄像头说一句话，屏幕上的虚拟形象（还是张静态图）旁边实时冒出文字，同时根据指令开始修改旁边加载的草图。虽然背后还是多个 API 调用拼接的，但前台看起来是“一体”的。我靠在椅子上，感觉不是兴奋，是累。这种追赶太被动了。大船调一次头，我就得把甲板上的所有绳索重绑一遍。但没办法，这就是现在的生存方式。我的价值，可能就在于能用最快的速度，把航母甲板上的新武器，改装到我这艘小艇上，让它还能在浪里有点用处。明天，还得继续抠那个语音中断和上下文保持的细节，那又是另一个深坑。
