果酱味1. 为什么要聊多模态输入：AI 代码助手的输入瓶颈
这几年 AI 代码助手的发展速度，大家有目共睹。从最早只能补全几行代码的插件，到后来能理解整个仓库上下文、能自动改 bug、能跨文件重构，模型能力本身进步非常快。但我自己用下来一个很深的感受是：很多时候模型不是不够聪明，而是我们根本没把问题说清楚。
为什么说不清楚？因为传统的代码助手交互窗口就是一个输入框，你只能打字。打字这个动作天然有信息损耗——你看到屏幕上有个样式错位，可能要花三四行文字去描述“按钮颜色偏了、间距不对、在暗色模式下特别明显”；你看到控制台报了一长串错误，为了把堆栈信息喂给助手，得手动复制粘贴，有时候日志太长还得截断；你脑子里有一个架构草图，想把思路告诉助手，只能一段一段文字描述，对方能不能理解全靠缘分。
这就是多模态输入要解决的核心问题：把视觉信息、语音信息直接变成助手的上下文，而不是强迫人类把所有问题都翻译成文字。
“打字不如说话，说话不如截图”这句话，其实是我自己实践了大半年多模态输入之后最直观的体会。语音输入能把描述成本降一个量级，截图输入则能把表达成本再降一个量级。这篇文章我来拆解一下这套实践背后的思路、具体怎么搭、以及实际用下来有哪些坑值得注意。
如果你是 AI 代码助手的深度用户，或者你正在做相关工具的产品设计，这篇内容应该能给你一些参考。里面提到的操作方式和工作流，都是我自己日常在用的真实方案。
1.1 “打字不如说话”到底解决了什么问题
先说说语音输入。很多人第一反应是：写代码的时候用语音？那不是更慢吗？
确实，如果目标是“让 AI 直接按你的语音写代码”，现在的语音识别精度和代码语境理解还没到那个程度。我自己试过直接对着助手说“帮我写一个函数，输入订单列表，按创建时间排序，返回前十条”，效果能到七八十分，但涉及复杂逻辑时，口语描述和精确代码意图之间的鸿沟还是明显。
但语音输入真正擅长的场景，不是“口述代码”，而是“口述上下文”。
举个实际例子：你正在排查一个线上问题，脑子里刚理清思路——某个服务调用超时，可能是连接池配置问题，也可能是下游服务响应变慢。这时候如果你的双手正在敲键盘查找日志，或者一只手端着咖啡，打字描述这个排查思路就特别别扭。但用语音输入，你只需要按住快捷键随口说：“我在排查 order-service 的超时问题，怀疑是连接池配置或下游响应慢，帮我看一下这两个方向”，20 秒就能把上下文完整丢给助手，它会基于你当前打开的代码文件去分析。
再比如开会开一半，临时需要助手帮你准备一段代码评审意见。你人在会议室，不方便打一堆字，语音“说”一下需求，结果直接同步到电脑上的助手对话窗口里，回去就能用。
语音的最大价值在于把“想法转成文字”这个环节从打字变成了说话。人说话的速度大约是每分钟 150 到 180 个汉字，打字通常只有 40 到 80 个，遇到要描述复杂逻辑时差距更大。本质上，语音输入是在压缩“描述”这个动作的时间成本。
当然，要注意的是，我这里说的语音输入，不是系统自带的语音转文字，而是在 AI 代码助手对话界面里集成了语音转文字能力，或者通过输入法、系统级的语音转写把语音先变成文字，再送入助手。这两种方式的体验差别很大，后面我会详细讲。
1.2 “说话不如截图”背后的底层逻辑
那为什么很多时候，说话也不如截图？
因为语言是线性的，而视觉信息是二维的、甚至三维的。当你试图用语言描述一个视觉问题时，信息损失特别严重。
举个例子，我调一个前端页面，发现侧边栏在 1440px 宽度下没问题，但缩到 1024px 时，侧边栏和主内容区之间出现了一条多余的空白间隙。用文字描述：“侧边栏和主内容之间在中等屏幕宽度下有空隙”，助手可能给你好几个版本的猜测：是 flex 布局的 gap 问题？是 margin 负值导致？还是媒体查询断点没覆盖？每个方向它都可能给出一段修改建议，但大多数都是瞎猜。
这时候如果你直接截一张图丢给助手，说“看这个间距”，它能看到整个页面布局，看到侧边栏宽度、主内容区宽度、还有那条间隙具体长什么样。如果助手本身支持视觉理解，它甚至能判断出你用的是哪种布局方式——是从 CSS Grid 的列间距，还是 flexbox 的 just 分配逻辑。准确率完全不在一个量级。
同样的道理适用于报错排查。终端里滚了一屏报错，文字复制粘贴难免丢行，截图则能把完整的错误信息、堆栈调用链、甚至终端上下文都一次性交给助手。