说话可能更容易解释任务为什么重要，也会补充短文字消息里省略的细节。挑战是将解释变成指令，同时避免编辑步骤编造你尚未做出的决策。
区分三种输出#
| 输出 | 请求内容 |
|---|---|
| 转写 | 以文字表示说过的话 |
| 清理后草稿 | 去掉多余犹豫与重复的易读措辞 |
| 解释后的指令 | 从想法推断出结构化任务 |
第三步可能有价值，但引入了含义判断。还在权衡时，草稿不应悄悄把“也许”变成“照做”。
自然口语可改写得更清楚，但应评估最终意图是否保留，不能假设流畅证明准确。
使用简洁口述结构#
录音前确定任务与边界。一个虚构例子：
“我们需要更清晰的办公使用解释。给共享工位用户写草稿。硬件声明保留为设计目标。不要发布。”
任务是起草，读者是共享工位用户，声明边界明确，最后一句控制输出是否留作草稿。
无需僵硬模板，但明确这些要素，之后就有可核对对象。说话中改主意时，清楚说明最终选择，检查它是否替换前项。
检查带来后果的词#
发送前关注：
- **名称：**人、产品、项目和文件标识符。
- **数字：**日期、数量、版本和金额。
- 否定：“不要”“不含”“除了”等限制。
- **范围：**改哪部分、保留哪部分。
- **动作：**研究、起草、发送、修改或发布。
比较含义，不只比较标点。“只改标题”与“改标题”可能导致不同工作。识别错“保留选项二”的数字，不能靠句子更流畅修复。
准确代码、路径或罕见名词，方便时用键盘。语音解释可与精确键盘编辑结合。
主动处理专业词汇#
重复项目术语，检查原始草稿准确拼写。CueSpec 有词汇设计工作，但已审核版本未确立通用自动学习。键入或粘贴准确术语仍是有用后备。
在普通句子里测试术语并检查输出。词典词条可能改善拼写，却未验证整个请求。不要因名称可识别而忽略缺失限制或改变的日期。
按节省的编辑工作评估清理#
用三条典型请求：短指令、口述解释、带更正请求。比较原始或最接近原始的转写与清理草稿。
统计仍需的修正，尤其含义改变。考虑录音后等待、恢复失败草稿的成本和发送动作。快速说话演示没有衡量完整任务。
CueSpec 的语音到提示词路径#
当前 Mac 辅助应用在 Codex 流程提供口述草稿、编辑与主动发送。本地原始转写和可选配置文本整理是独立步骤；整理需配置服务并登录，已审核快照中完整真实服务验收仍待完成。
SPECS 01 正开发可穿戴输入和控制。本指南不保证当前眼镜集成能自动提取所有意图，或在所有应用清理语音。检查仍属于工作流。
常见问题#
AI 应移除每个“嗯”“啊”吗？#
去掉多余赘词有助阅读，但保留任务、不确定性与约束，比去掉每次犹豫更重要。
能直接口述代码吗？#
可以尝试，但准确语法和标识符需单独检查。口述解释与约束，可能比读大量标点代码更方便。
录完应自动发送吗？#
按任务与控制偏好选择。涉及姓名、数字或执行指令时，检查特别有用。参阅多个 AI 对话中的语音输入。
轻声说话漏词怎么办？#
先修复采集，不要让清理去重建请求。用耳语测试定位问题。
当前产品信息请看 CueSpec 产品事实。