如何在 Cursor 中使用语音输入，写出更好的编程提示词

对于复杂的代码修改来说，最短的提示词往往并不是最快的完成路径。

你可能非常清楚需要做什么，却只在 Cursor 中输入一句“更新设置表单”。这句话几秒钟就能打完，但它也留下了几个没有说明的关键决定：具体要改变什么行为？哪些内容必须保持不变？需要考虑哪些边缘情况？怎样才算真正完成？

对于小幅修改，这样的提示词也许已经足够。但当一项修改涉及多个状态或限制条件时，遗漏的上下文往往会以不必要的追问、额外的返工，或者“代码在技术上没有错，却解决了错误的问题”等形式再次出现。

语音输入在这里有用，原因很简单：它能让你更轻松地完成一份信息更完整的初稿。你可以顺着思路自然说出任务要求，然后放慢速度，检查那些必须保持精确的细节。

这并不是要用语音编写代码，也不是要让每一条提示词都变得更长。它是一种向 Cursor 提供真正会影响实现方式的信息的方法，同时又不必把“写提示词”本身变成一项独立工程。

语音输入在 Cursor 工作流中的位置

Cursor 可以检查代码库、编辑文件、运行命令，并围绕一项任务持续迭代。但 Agent 仍然需要一份清楚、有用的需求说明。Cursor 官方关于如何与编程 Agent 协作的指南建议：面对复杂任务时先制定计划，并向 Agent 提供明确的目标。

有些上下文可以放在项目规则、文档或代码本身之中，但当前任务仍然需要说明它自己的关键决定：你想要什么行为、这次修改的边界在哪里，以及用什么证据判断结果是否可以接受。

语音尤其适合处理这项工作中以自然语言为主的部分：

• 解释当前行为
• 描述期望的用户体验
• 说明限制条件和明确不做的内容
• 列出边缘情况
• 定义需要测试的内容

键盘仍然更适合输入精确的语法、路径、标识符、小范围修改，以及任何不适合公开说出来的内容。一套实用的工作流会同时使用语音和键盘。

口述 Cursor 提示词时，可以采用的四部分结构

开始说话之前，可以先把任务归纳为四个部分：

1. 问题： 现在发生了什么？为什么这是一个问题？
2. 目标结果： 应该改成什么样？
3. 限制条件： 哪些内容必须保持不变？
4. 完成标准： 出现哪些可观察的行为，或者通过哪些测试，才能证明任务已经完成？

这不是一个必须严格照填的提示词公式，而是一种快速提醒，帮助开发者避免把最容易被默认省略的关键决定留在脑子里。

假设一个设置页面中的通知开关会在点击后立即保存。真正需要的修改并不只是“添加 Save 和 Cancel 按钮”。Agent 还需要知道：未保存状态应该如何处理、什么时候需要禁用控件、保存过程中会发生什么，以及刷新页面后应该保留什么。

下面是同一项任务更完整、可以直接执行的表达方式：

在 app.js 中，电子邮件通知开关目前会在用户点击后立即保存。请修改这一行为，让新的选项先保持为未保存状态，直到用户点击 Save changes。添加一个 Cancel 按钮，用于恢复上一次保存的设置。没有任何修改时，Save 按钮应保持禁用。保存过程中，禁用开关和两个按钮，并显示 Saving 状态。保存完成后，显示 Changes saved。根据需要更新 HTML 和样式，但保留现有的 updatePreferences 函数和当前视觉风格。不要添加新的程序库，也不要修改页面的其他部分。当 Save 能保存新设置、Cancel 能恢复之前的设置，并且刷新页面后仍然保留上一次保存的选项时，这项任务才算完成。

这条提示词之所以有用，并不是因为它更长。它明确说明了当前行为，描述了每一个重要状态，保护了不应改变的现有决定，并用可以验证的结果收尾。真正产生价值的是具体，而不是篇幅。

如何在 Cursor 中口述一条详细的提示词

1. 开口之前，先检查任务

先打开相关文件，或者复现当前行为。准备好可能需要提到的标识信息，例如文件名、函数名、组件名、错误信息和测试命令。

这一步不需要花太多时间，却可以避免口述内容变成一连串猜测。如果你并不确定某个技术细节，就描述自己实际观察到的现象，而不是编造一种实现方式。

2. 把光标放在 Agent 输入框中

将文本光标放到希望提示词出现的位置。使用你配置好的快捷键启动 Typeoff，然后用完整的思路进行口述。

你不需要像念稿一样说话。可以在问题、目标结果、限制条件和完成标准之间稍作停顿。这些自然的分界会让生成的初稿更容易检查。

Typeoff 是一款 AI 语音输入工具，可以把处理后的文本插入光标所在位置。在这套工作流中，它负责把口头说明转化为 Cursor 中一份可读的初稿。它不会替你判断修改要求是否正确，也不能取代开发者对内容和代码的审核。

3. 检查语音输入无法安全推断的内容

文本出现后，不要立即发送。按照一份简短而明确的清单检查一遍：

• 标识符： 文件名、函数名、组件名和命令是否完全准确？
• 否定条件： “不要”“绝不”或“不得修改”等含义是否被正确保留？
• 数字和状态： 限制数值、超时时间、状态文字和预期状态变化是否准确？
• 范围： Cursor 可以修改什么、应该保留什么，是否表达清楚？
• 验收标准： 每一项条件是否都可以被观察或测试？

用键盘修正小错误。语音负责捕捉思路的完整轮廓，键盘负责保持技术语言的精确度。

4. 让 Cursor 先制定计划，再检查实现结果

对于包含多个步骤的修改，可以先让 Cursor 检查相关代码并提出计划，然后再开始编辑。这样会形成一个很有价值的检查点：在错误假设扩散到多个文件之前，你就有机会发现它。

实现完成后，检查代码差异并运行相关验证。测试提示词中写明的各种状态，而不只是最顺利的正常流程。对于文章中的设置页面示例，这意味着要确认 Save、Cancel、没有修改时的状态、保存中的状态，以及刷新后的持久化结果。

一条信息更完整的提示词并不能保证代码一定正确，但它能给 Agent 一个更清晰的目标，也能为你的后续审核提供更明确的依据。

什么时候适合使用语音输入，什么时候不适合

当一项任务包含多个相互关联的决定时，语音输入通常更能发挥价值。例如：

• 包含复现步骤和预期行为的错误报告
• 必须保留某个 API 或交互方式的重构任务
• 同时涉及加载、空白、错误和成功状态的界面修改
• 需要解释修改原因和测试情况的 Pull Request 描述
• 需要说明技术权衡的代码审查回复

如果只是修改一行内容、输入一段精确的代码，或者执行一条终端命令，语音通常没有太大优势。在共享空间中，或者任务涉及密码、客户数据、访问凭据、未发布信息，以及其他不应该被公开说出的内容时，也不适合使用语音输入。

目标不是用语音取代打字，而是为工作中的不同部分选择阻力更小的输入方式。

一份可以重复使用的语音提示词模板

下一次处理一项不那么简单的 Cursor 任务时，可以使用下面这份轻量结构：

问题： 在 [文件或功能区域] 中，当 [触发条件] 出现时，会发生 [当前行为]。
目标结果： 将其改为 [期望行为]。
限制条件： 保留 [现有行为/API/风格]。不要 [明确不做的内容]。
完成标准： 当 [可以观察的检查结果或测试] 成立时，任务才算完成。

不要机械地填满每一个字段。只添加那些会影响实现方式或审核结果的信息。如果某些背景需要在每次任务中重复使用，更适合放进项目文档或 Cursor Rules，而不是每次都重新口述。

真正有用的不是更长的提示词

一条好的 Cursor 提示词不需要面面俱到，但它需要让重要决定变得可见。

面对复杂修改时，语音输入可以降低完整解释问题所需要的输入成本。真正的严谨发生在口述之后：核对技术术语、守住修改边界，并根据自己事先定义的完成标准检查代码。

下一次遇到一项详细到不想手打的任务时，可以先试着说清四件事：问题、目标结果、限制条件和完成标准。先口述初稿，检查无误后再发送。