SpeakIn 的体验很大程度上取决于那条隐藏在背后的 AI 提示词。内置的预设能覆盖大多数通用场景，但当你有非常个人化的需求——比如把口述整理成播客选题、Notion 条目或者是特定格式的代码提交记录，就需要自己动手写了。
给 SpeakIn 写提示词和我们平时跟 AI 聊天不太一样。因为它处理的是你碎片化的口述，且结果会直接粘贴到你的工作窗口里。这意味着这根提示词必须做两件事：清理口水话还原书面表达，同时保持绝对干净的输出——不能有一句废话，不能加戏，也不能擅自总结你没说过的内容。
其实你不需要自己从头研究怎么写这种提示词。直接把下面这段“元提示词”复制给 Claude 或 ChatGPT，告诉它你的需求，让它来帮你写。
Markdown
你是一个提示词工程师，专门为 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 提交的提示词”，而是告诉它“把口述整理成 Conventional Commits 格式，只用 feat/fix/refactor，描述不超过 50 字”。
拿到生成的提示词后，拿几段自己真实的口语试一下。重点观察它会不会偷偷补充没说过的话，或者顺手扩写。一个好用的 SpeakIn 提示词往往是非常克制的，它的价值是把你脑子里的想法准确翻译到屏幕上，而不是替你发明观点。
如果你觉得生成的提示词效果还不够好，或者想要深入了解如何精准控制大模型，可以看看 Claude 官方的 Prompting best practices。
文档很长，但核心逻辑其实就这几点：
- 把 AI 当作一个聪明但毫无背景的新员工，你的指令越清晰直接，它的表现越好。
- 给出具体的示例，这是控制语气和格式最稳妥的办法。
- 告诉它“要做什么”而不是“不要做什么”。
- 当提示词变得复杂时，用
<example>这样的 XML 标签把指令、背景和数据隔开，能大幅度降低 AI 的理解偏差。
掌握这几点，足够应付绝大多数日常场景了。
另外，如果你不想自己从头折腾，也可以直接去看看本站整理的 提示词库，里面收集了一些好用的现成 Prompt，可以直接复制拿去用。