S19-B03 · 语音输入：把需求说出来

适用读者：嫌"写长需求太累"的人；以及把语音当成"万能加速器"的人。
前置：S19-B01。
口径：功能细节随产品版本变化，本文只讲成本结构与适用边界，具体开关位置标「以你的客户端为准」。
覆盖旧文：A-259（Voice 语音模式，182 点）。
覆盖扩展：E-S19-006（语音输入的成本结构）。
上一篇：S19-B02 · 提示词模板与占位符
下一篇：S19-B04 · 学习方法。

1. 一句话结论

语音输入省的是"从想法到文字"的这段时间，不是"思考"的时间。所以它对"需求描述长、结构松散"的任务收益最大，对"要精确标点/代码/公式"的任务收益最小。

任务类型	语音合适吗	原因
口述需求背景、约束、期望	✅	说比打快得多
让模型解释/总结/头脑风暴	✅	输入长、容错高
写代码、写 SQL	❌	标点与符号口述易错
精确的格式要求（JSON schema）	❌	一个符号错就跑偏
安静环境缺失（开放办公/会议）	❌	隐私与噪音

2. 语音模式的三段链路

麦克风采集 → 上传服务端转写 → 文本进入提示词输入框
   ↑ 本地            ↑ 网络（隐私边界）        ↑ 之后与打字同流程

关键认知：语音不是"模型直接听懂你"，而是"先把语音转成文字"。所以：

影响	说明
断句与同音词	转写错误会原样进入 Prompt
网络与延迟	转写依赖服务端（离线场景不可用）
隐私	音频会上传（企业环境要确认策略）
口音/中英混说	转写质量决定上限

3. 成本结构（E-S19-006）

环节	成本	何时成为瓶颈
思考	不变	语音不减少思考时间
口述	低于打字（长文本显著）	短文本没优势
转写	网络往返	弱网/远程环境
校对	语音会引入错字，需回读	高精度任务反而更慢

判据公式（经验口径）：

收益 ≈ (打字时间 − 口述时间) − 校对时间

结论：当"校对成本"超过"打字节省"时，语音就是负收益——这正是代码/配置类任务不适合的原因。

4. 口述需求 → 结构化 Prompt 的四步

语音输入的原始文本通常是"流水账"，需要整理成 B01 的六单元。一个可执行的做法：

步	动作	例子（口述原文 → 结构化）
① 先说要什么	Directive	"帮我把这段话改成对外的公告"
② 再给背景	Context	"面向客户，不要说内部系统名"
③ 说格式	Format	"分三段：是什么/影响/怎么办，每段不超过两句"
④ 强调禁止项	Style/约束	"不要出现'紧急''尽快'这类词"

技巧：口述时用**"分点说"**（"第一…第二…"），转写后的文本天然有结构，省掉整理成本。

5. 五个误区

误区	真相
"语音能提高思考速度"	只提高输入速度
"语音转写一定准"	同音词、专有名词、中英混说都会错
"语音更适合写代码"	符号与标点口述错误率高
"语音是本地处理"	多数实现要上传服务端（隐私）
"买了语音就不用打字"	高精度任务仍需键盘

6. 自检

语音省的是哪段时间？不省哪段？
什么时候语音是负收益？给出判据。
为什么代码类任务不适合语音？
口述结构化 Prompt 的四步是什么？
企业环境使用语音前要确认什么？

7. 下一篇

S19-B04 · 学习方法：开源项目与新技术怎么入门

输入方式讲完，回到"怎么学"。下一篇处理两张旧文空壳卡（开源项目怎么学 / 安卓怎么学），补写成通用的"三问法"。

本篇属于系列《S19 · AI 素养与学习方法》。旧文来源：A-259；扩展点 E-S19-006。功能细节随客户端版本变化，正文只讲成本结构与边界。