怎么给 SpeakIn 写一条 AI 优化提示词

SpeakIn 的流程很简单：按热键说话，语音转成文字，文字经过你选的 AI 提示词处理，再自动粘贴到当前窗口。

前后两步是固定的，决定结果好不好用的，是中间那条提示词。

SpeakIn 内置了二十多条预设，润色、翻译、Git commit、社交媒体帖子、工作邮件都有，对很多人来说够用了。但总有些更个人的需求覆盖不到——比如专门写小红书文案的，专门整理播客选题的，或者把口述想法整理成 Notion 数据库条目的。

这篇文章就讲怎么给自己写这样一条。

先想清楚这条提示词要做什么

SpeakIn 的提示词和你平时写给 Claude、ChatGPT 的不太一样，有几个很硬的约束，动手前最好先想清楚。

1. 它处理的是一段话，不是一篇文档

你每次输入的只是一段口述内容，不是一封完整邮件，也不是一篇文章或报告。

提示词的任务不是帮你写一篇东西，而是把你刚刚说的这一段处理好。

不要让 AI 生成标题、大纲、目录、称呼、落款、问候语这些文档外壳。处理结果会直接贴到当前窗口，这些东西只会增加你手动删除的成本。

2. 输出必须能直接粘贴

这是 SpeakIn 和聊天场景最大的区别之一。

处理完的文字会直接出现在你正在输入的位置，所以输出里不能出现：

• "好的，这是整理后的内容："
• "以下是优化结果："
• "希望这对你有帮助"

这些在聊天里很自然，在 SpeakIn 里全是干扰。

理想输出只有一件事——纯内容本身。没有开场白，没有解释，没有结尾客套。

这一点要在提示词里反复强调，因为模型很容易忍不住多说两句。

3. 输入是口语，输出是书面表达

语音转写出来的原文不会很干净。会带"嗯""就是""然后""那个"这类口语痕迹，会有重复、停顿、逻辑跳跃，也可能夹杂同音字识别错误。

写提示词时不能假设输入已经是整理好的文本。要明确告诉 AI：它面对的是一段口语转写，要负责清理这些痕迹，把它变成自然、清楚、可用的书面表达。

4. 只改表达，不改内容

这条最重要。

说话人说了什么，就处理什么；没说的，不要补。

不要总结，不要引申，不要擅自补背景，也不要替用户把意思说完整。模型天然有一种倾向——觉得自己应该把内容补得更圆满。在 SpeakIn 的很多场景里，这种好心反而会出问题。

尤其是需求描述、Bug 报告、工作同步这些场景，多出来的上下文、结论或解释，很可能根本不是用户想表达的。

提示词里要明确压住这种倾向——改的是"怎么说"，不是"说了什么"。

获取提示词的两条路

如果只是想快速找一条能用的，去 afengblog.com/prompts 看看。我整理了一些常见场景的提示词，复制过来稍微改一下就能用。

翻完没找到完全贴合的也没关系，可以直接让 AI 帮你生成一条新的。

想更系统地了解提示词怎么写，可以参考 Anthropic 的 Prompting best practices，里面的几条原则对写 SpeakIn 提示词也有用：

• 用清楚的结构组织提示词
• 用示例约束风格
• 明确告诉模型要做什么
• 对关键限制反复强调

最省事的办法还是让 AI 帮你写。

让 AI 帮你写：复制下面这段就行

下面这条可以理解成一个生成 SpeakIn 提示词的元提示词。

完整复制给任意一个大模型都可以，Claude、ChatGPT、豆包、Kimi 都行。只改里面的 <user_requirement> 部分，用一两句话写清楚你想要的场景和效果。

AI 返回给你的，就是一条可以直接放进 SpeakIn 的提示词。

你是一个提示词工程师，专门为 SpeakIn（一款语音输入工具）编写 AI 后处理提示词。

<context>
SpeakIn 的流程是：用户按热键说话 → 语音被转写成文字 → 文字经过 AI 提示词处理 → 处理结果直接粘贴到用户当前的焦点窗口（可能是 Claude 对话框、Gmail、飞书、VSCode 等任何应用）。你要写的就是第三步的提示词。
</context>

<principles>
写 SpeakIn 提示词必须守住这几条：

1. 段落级别，不是文档级别。用户每次输入只是一段话，提示词处理的是当前这一段，绝不生成标题、大纲、目录、称呼、落款、问候语等文档壳子。

2. 粘贴即可用。输出会直接进入焦点窗口，所以只能有处理后的纯内容，不能有任何前缀（"好的，这是处理结果："）、后缀（"希望对你有帮助"）、解释、标签或代码块标记。

3. 输入是口语，输出是书面。输入是语音识别的原始转写，带赘词（"嗯""就是""然后"）、重复、逻辑跳跃、同音字错误。提示词要明确告诉 AI 怎么处理这些口语特征。

4. 不加原文没有的东西。不总结、不补充、不引申。改变的是"怎么说"，不是"说了什么"。

5. 输出语言与输入语言一致（翻译类除外）。

6. 幂等性。同一段输入多次处理结果应基本一致，不要每次加不一样的装饰。

推荐用 XML 标签组织提示词内容，常用的有 `<core_principle>`、`<processing_rules>`、`<style_guide>`、`<prohibited_operations>`、`<input_output>`、`<reminder>`。根据需求取舍，不必全用。提示词末尾要说明输入在用户消息的 `<input>` 标签内，并强调直接输出纯文本、不要任何标签或解释。
</principles>

<user_requirement>
在这里用一两句话描述你想要的场景和效果。
</user_requirement>

<output_format>
直接输出写好的提示词正文，用 Markdown 代码块包裹。不要任何开场白、说明或结尾寒暄。提示词正文用中文编写。
</output_format>

用的时候只改 <user_requirement> 这一段。

不要只写：

我要一条写 Git commit message 的提示词

这种描述太泛，模型不知道你要什么格式、什么风格、什么约束。

更好的写法：

我要一条把口述的代码改动整理成 Conventional Commits 格式的提示词，类型只用 feat、fix、refactor、docs、chore 这五种，描述部分用中文，不超过 50 个字符

信息越具体，生成出来的提示词越稳。

几个容易踩的坑

提示词写完别直接相信它没问题，拿几段口语真的测一下。很多问题一试就能看出来。

1. AI 忍不住加开场白

最常见的一个。

你明明想让它直接输出内容，它时不时来一句：

• "好的，这是优化后的版本："
• "以下是整理后的结果："

这是模型的默认行为。解决办法不是只说一遍"不要加说明"，而是要在提示词里重复强调，最好在结尾的提醒部分再写一次：

直接输出内容本身，不要有任何前缀、说明或结尾

这种重复有用。

2. AI 偷偷补充内容

你说了三句话，它整理成五句——多出来的两句看着挺像那么回事，但不是你说的。

正式场景里这件事尤其危险。描述问题、同步进展、解释需求时，模型补出来的内容很可能让原意偏掉。

办法很直接——在提示词里明确禁止添加原文中不存在的信息、观点、结论或推断。必要的话加一个反例，让边界更清楚。

3. 风格漂移

你想要轻快、有网感的表达，结果给你写成公众号腔；想要专业一点，结果写得太口语。

不是模型不听话，是你对风格的约束不够具体。

比起抽象地说"更自然一点""更年轻一点"，更有效的做法是给边界：

• 像这样 ✅
• 不要这样 ❌
• 也不要这样 ❌

对比式约束比一句形容词管用得多。

4. 输出比输入长太多

口语输入一百字，处理完三百字——这不是"整理"，是"扩写"。

不希望它扩写就明确写出来——输出长度应与输入信息量匹配，不要为了显得完整而主动扩展内容。

不然模型很容易把"帮你整理一下"理解成"帮你写得更丰满一点"。

最后

写一条好用的 SpeakIn 提示词不难，难的是克制。

克制让 AI 多做一点的冲动，克制"顺手帮你补全"的倾向，克制那种看起来更完整、实际上更偏离原意的优化。

SpeakIn 不是在中间替你重新组织思想，更不是替你发明你没说过的话。它真正有用的地方，是把你脑子里那段还带着口语痕迹的内容，准确、自然、快速地送到屏幕上。

想清楚这个前提，剩下的就简单了——不断测试、微调，让提示词越来越贴合你自己的表达习惯。