打字还是口述？比较完整的 AI 请求输入流程

比较打字和口述时，要看产出一条同样有用的 AI 请求需要多少工作。读任务、组织内容、修正文字和核对目标都应算进去；每分钟输入多少字，只能覆盖其中一部分。

用下面的空白表记录自己的尝试，再按任务选择输入方式。

先约定在哪里结束

第一次比较，可以把终点设为请求已经可发送：意思正确，精确引用齐全，也已核对目标位置。只比较草稿即可，无需为了测量输入而提交任务。

如果送达也是选择时的重要因素，就为每种方式都增加一个独立的送达阶段，用相同方式检查目标。不要拿一个工具的“草稿已准备好”，与另一个工具的“消息已确认送达”比较，也不要把编程代理执行任务的时间算成输入时间。

可以在记录表中使用下面这套定义：

开始：
开始阅读任务卡、准备组织这条请求时。

结束：
草稿已经完成、检查完毕，可以发往目标位置时。

包含：
阅读与构思、打字或录音、处理等待、手工修正、
补充精确引用，以及核对目标。

可选的独立阶段：
发送与核对送达；如果比较，就对每种方式一致记录。

不要只试一种任务。下面三张虚构任务卡可作为起点，也可以换成日常工作中不含敏感内容的同类任务。

任务卡	必须保留的意思	为什么适合用来比较
简短修正	保留标题；只把最后一段改成下一步行动	小请求可能不需要太多构思
缺陷说明	在虚构设置面板的阈值（Threshold）中填入 0，保存并重新打开。说明字段变空、预期应显示 0，并请求调查	口述背景与精确录入文字可能有不同的使用感受
精确技术请求	为 `parse_item` 和 `parse_items` 请求一份测试计划；保留两个名称的准确拼写，并要求不编辑文件	精确名称与行动边界都很重要

尝试任一方式之前，先确定必须保留的意思。两份产出不必逐字相同，但都要包含同样的任务、事实和限制。更短的请求如果漏掉约束，就不是等价产出。

也可以把混合输入作为一种独立方式：先口述解释，再输入标识符。比较包含口述，并不意味着要把标点密集的代码也强行念出来。

第一次可以先选一张熟悉的任务卡，用两种方式表达同样的请求，只记录到可发送为止的总时长和关键修正。需要时再使用详细表格；形成更广泛的偏好前，再加入其他类型任务。

日期：
任务类型：
任务卡或引用：
必须保留的意思与精确术语：
结束点：

输入方式：
应用、版本与模式：
设备或麦克风（如相关）：
语言：
环境：
本轮尝试各种方式的顺序：
近期练习情况或设置变化：

结果：
[已准备好 / 未完成 / 被打断；请说明。]

记录那些会影响再次比较的条件。新麦克风、不同语言或不熟悉的快捷键，都可能改变体验。如果比较日常重复使用，就把一次性的初始设置时间单列；如果关心的正是初次设置，就把它作为另一项单独任务记录。

使用连续衔接的阶段，让总时长对应一次完整尝试：

如果边说或边打字时就在修正，把这部分工作留在输入阶段。如果工具的录入与处理存在重叠，就记录连续的总时长并说明重叠情况，不要把同一段时间估算两次再相加。记录精度应符合实际观察；简单的总时长可能比分阶段猜测更可靠。

没有记录的结果就留空。如果某种方式失败，保留失败尝试和恢复过程，不要只给后面成功的一次计时。

标点问题与指令变化，不应都被压进一个“错误总数”。按实际修正情况记录：

例如，把“编辑文件”改成“不要编辑文件”，修复的是行动边界。即使其余文字读起来很顺，这个修正也很重要。记录修正是为了描述自己的工作，而不是据此宣称一个产品对所有用户都达到某种准确率。

重复同一条请求，会让你越来越熟悉它。不要总是先打字、后口述。可以在同类任务卡之间轮换顺序，同时尽量保持必须表达的意思与难度相近。

小规模的个人比较可以帮助你决定下一次在哪类任务中继续尝试，不能据此认定一种方式普遍胜出。既要包含常见任务，也要包含不顺手的任务，不要只挑适合自己偏好方式的例子。如果某次尝试因中断而难以比较，就保留说明，之后再试一张同类任务卡。

任务类型	方式	到可发送为止的总时长	关键修正（类型或次数）	恢复负担	在这个环境下是否舒适？	继续用于……
简短修正	打字	—	—	—	—	—
简短修正	口述	—	—	—	—	—
缺陷说明	打字	—	—	—	—	—
缺陷说明	口述	—	—	—	—	—
精确技术请求	打字	—	—	—	—	—
精确技术请求	口述或混合输入	—	—	—	—	—

在这一列记录名称与引用、事实、意思或目标的修正；可读性整理另行记录。

按任务和环境选择方式。短标识符可能适合打字，长解释可能适合口述，两者兼有的请求可以混合输入。如果所在环境不适合说话，就保留文字输入路线，无需把一种输入偏好变成所有工作的要求。

如需按 CueSpec 工作流比较，可阅读评估语音输入工作流与比较原始稿和整理稿。无论在哪里尝试，都沿用同一个结束点和必须表达的意思。