最近用 Cursor 写代码时，我越来越明显感觉到一个问题。

AI 写代码已经不慢了，慢的是我描述需求。

很多时候，需求其实已经在脑子里了，比如这个页面要怎么改、接口字段哪里不对、组件能不能复用、哪些文件不能碰。但真要把这些内容敲成 Prompt，就会变成一件很烦的事。

于是经常出现两种情况。

一种是 Prompt 写得太短。

比如“帮我加一个搜索功能”

结果 Cursor 按自己的理解写了一套，能跑，但不一定符合项目现有结构。

另一种是 Prompt 写得很完整，但输入成本太高。写完 Prompt 的时间，感觉都够自己改一部分代码了。

所以我最近在尝试一个组合，SaySo + Cursor。

SaySo 负责语音输入，把自然语言转成文本；Cursor 负责读代码、改代码、解释逻辑和辅助调试。搭在一起之后，整个 Vibe Coding 的体验会顺很多。

为什么要加 SaySo？

Cursor 本身已经可以理解自然语言，但前提是你得把话说清楚。

比如同样是做搜索功能，下面这段 Prompt 明显更容易得到可控结果。

我想在当前列表页增加搜索功能，先不要接后端，只做前端假数据筛选。
输入时加 300ms debounce。
空状态复用项目里已有的 Empty 组件，loading 状态用现有 Skeleton。
你先看一下当前列表页和已有组件实现，给我一个最小改动方案，确认后再写代码。

这段内容不复杂，但如果每次都手打，确实麻烦。

用 SaySo 的好处是，你可以像跟同事沟通一样，把需求直接说出来。尤其是一些边界条件，平时打字很容易省略，但语音说出来很自然。

比如：

不要引入新依赖。
不要重构全局组件。
这次只改当前页面。
如果发现现有结构不适合，先告诉我，不要直接大改。

这些话看起来不起眼，但对 Cursor 很重要。

AI 编程里很多问题，不是模型不会写，而是它写得太积极了。一个小需求，它可能顺手抽象、顺手重构、顺手改掉一堆无关文件。提前说清楚边界，可以少很多返工。

我现在常用的流程

我现在比较习惯把一次 Cursor 任务拆成几个步骤。

语音描述需求
让 Cursor 先读相关代码
让 Cursor 输出改动方案
确认方案
再让 Cursor 写代码
检查 diff
运行项目或测试
继续补充修改

重点是，不要一上来就让 Cursor 改代码。

我之前经常这么用：

帮我实现 xxx

它确实会很快写完，但后面 Review 的时候经常发现方向偏了。后来我改成先让它读代码。

你先不要写代码。
先阅读这个页面、相关组件和调用链。
告诉我当前逻辑是怎么跑的，以及你准备怎么改。
我确认后你再动手。

这个习惯很有用。

Cursor 先复述一遍自己的理解，你就能提前发现它有没有看错文件、有没有误解业务逻辑、有没有准备动不该动的地方。

这一步花不了多久，但能省掉后面很多清理成本。

Prompt 不要只写功能，要写约束

很多人用 Cursor 的时候，只写「我要什么」，很少写「我不要什么」。

但在实际项目里，后者经常更重要。

比如下面这种 Prompt：

帮我把登录页加上邮箱验证码登录。

Cursor 可能会直接改表单、改状态、改接口调用，甚至把原来的密码登录逻辑一起调整掉。

更稳一点的写法是：

我想在登录页增加邮箱验证码登录。
保留现有密码登录，不要影响原来的登录流程。
先阅读 auth 相关代码，梳理当前状态流转。
这次只做最小改动，不要重构登录模块。
先给方案，确认后再写代码。

这类 Prompt 用键盘打会有点烦，用语音就刚好。

你把脑子里的顾虑直接说出来，SaySo 转成文本，再丢给 Cursor。Cursor 拿到的信息更完整，生成结果也会更接近你的预期。

调试时也适合用语音

SaySo + Cursor 不只适合写新功能，调 bug 的时候也很好用。

比如你遇到一个保存失败的问题，不要只贴错误信息，可以把观察到的现象一起说进去。

现在点击保存按钮后，控制台报字段 undefined。
但是接口返回是 200。
我怀疑不是接口问题，可能是前端处理 response 的字段和新接口不一致。
你沿着保存按钮的调用链查一下。
先不要改代码，先列出最可能的三个原因。

这类描述里有几个信息：

触发动作
报错现象
接口状态
初步判断
排查边界

这些上下文越完整，Cursor 越容易直接定位问题。

以前我们和同事排查问题，也是这么沟通的。现在只是把这个过程搬到了 Cursor 里。

几个我常用的语音 Prompt

新功能开发：

我想实现一个功能，目标是【具体目标】。
请先阅读【相关页面或文件】。
尽量复用现有组件和样式。
不要引入新依赖，不要重构无关代码。
先给我最小改动方案，确认后再写代码。

Bug 排查：

现在出现一个问题，【具体现象】。
我观察到【补充现象】。
我怀疑和【相关模块】有关。
请沿着调用链排查。
先不要改代码，先列出可能原因和优先检查的位置。

代码重构：

我想优化这段代码，但不要改变现有行为。
请先找出重复逻辑和复杂度高的地方。
给我一个小步重构方案。
不要一次性大改。

UI 调整：

我想调整这个页面的 UI。
目标是【具体效果】。
先看项目里已有组件和样式写法。
尽量复用现有 class、变量和组件。
注意移动端不要挤压或换行异常。

代码 Review：

请帮我 Review 当前改动。
重点看逻辑错误、边界条件、潜在回归和可维护性。
不要只总结改了什么，优先指出可能有问题的地方。

使用时要注意的问题

SaySo 用起来很顺，但也有一个问题，容易说太多。

一次 Prompt 里如果塞了太多目标，Cursor 也会乱。

比如：

帮我改登录，加搜索，顺便优化首页，再看一下接口封装有没有问题。

这种就不太适合。

更建议一次只处理一个任务。

这次只处理登录功能。
搜索和首页先不动。

还有一点，Cursor 改完以后一定要看 diff。

不要因为它写得快，就直接接受所有改动。至少要检查几件事：

有没有改无关文件
有没有引入新依赖
有没有影响旧逻辑
有没有破坏项目原有风格
有没有遗漏边界状态

AI 可以加速编码，但不能替你承担最终责任。

尤其是业务项目，很多问题不是代码能不能跑，而是这个改动放进现有系统里是否合适。

最后

SaySo + Cursor 这套组合，对我来说最大的价值不是「语音转文字」本身，而是降低了给 Cursor 补充上下文的成本。

以前我可能只愿意写一句：帮我改一下这个功能

现在我更愿意多说几句：

为什么要改
当前有什么限制
哪些文件不能碰
希望先分析还是直接实现

这些信息补上之后，Cursor 的输出质量会稳定很多。

所以我的建议是，如果你已经在用 Cursor，可以试试加一层语音输入。

不用一开始就设计复杂流程。

先从一个习惯开始，每次让 Cursor 写代码前，先用语音把需求完整说一遍，让它先读代码、给方案，再动手。

很多时候，效率提升不是因为少敲了几个字，而是因为你更愿意把上下文讲完整了。

SaySo 官网：https://sayso.cn/

我的邀请码：LW8J528A

真心希望对大家有帮助！