只要会议转写能通过 MCP 读到，有价值的问题就不再是“怎么接上”，而是 “到底该问什么”。多数人用上一周之后得到的答案是：别问“帮我总结上一次会议” ——那个应用本身就能给。值得为之设置的提示词，是那些跨越多场会议的，或者把会上 说过的话与您手头别的事情连起来的。
要写好提示词，机制很重要。助手不会读完整个归档。它先搜索，拿回一份带简短预览 的列表，挑出看起来相关的，再把这几份完整读一遍——所以当提示词给了搜索可以收窄 的条件（一段时间、一个话题、一个标签），并说明答案应该是什么形态时，效果更好。
下面是按用途分组的二十条提示词，随后是那些会失效的提问及其原因。它们是为 Speak-Y 的 MCP 服务器写的，但其中没有任何专属之处：任何能搜索并阅读转写的 助手，都能应付同样的写法。
有五条命令直接读取您的库，无论应用是否打开都能用：列出录音、全文搜索、读取 某一份转写、取回最近一条录音、列出标签。列表和搜索接受同样的过滤条件——日期 范围、标签、只看会议、只看收藏——所以“我上周的会议”是一条廉价的指令，而 “我说过的所有关于新人上手的内容”是一条昂贵的。
一份转写有四种读法，而这个选择对答案的影响比多数人预想的要大：纯文本、按说话 人区分的段落、带待办事项的 AI 摘要，或者一次全要。要回答“我们决定了什么”， 摘要就够了，而且只占一小部分上下文。要回答“谁承诺了什么”，您需要按说话人区分 的段落——摘要会把归属抹平，有时还会弄错。
1. 把我过去两周的会议过一遍，列出我本人做出的每一项承诺，并注明出自 哪场会议。
2. 我这个月的会议里，哪些待办事项在之后的会议中再没被提起过？ —— 这是“悄悄不了了之”的一个不错的近似。
3. 对比最近三次规划会上我们对第三季度路线图的说法。有什么变化，有人说过 为什么吗？
4. 读一下我这个季度的一对一，告诉我哪些话题在不止一个人那里反复出现。
5. 我要写一份进展汇报。从我这周的会议里挑出决定和阻塞点，写成五条要点。
第 3 条是管理者会一直留着的。一个改过三次的决定，在最新的摘要里看上去稳如 磐石；只有跨会议的对比才能看出它动过，而理由只在转写里留了下来。
6. 找出我与 Northwind 的通话，按顺序给我一条他们提出过什么要求的 时间线。
7. 我最近五次销售通话里出现了哪些异议，我又是怎么回应每一条的？
8. 在我与这个客户通话之前：上次我们答应了什么，哪些还没兑现？
9. 读一下我这个月的需求挖掘通话，告诉我哪些问题我总是忘了问。
10. 根据昨天与客户的通话起草一封跟进邮件——只写他们真正提到的点， 不要编造。
第 9 条让人不舒服，但值得每月跑一次。您自己漏问的规律在当下看不见，摊开十份 转写就一目了然。第 10 条里“不要编造”这句是真在干活：没有它，模型会好心地用 一些没人许诺过、却听着合理的承诺，把跟进邮件补圆。
11. 关于重试逻辑我们同意改成什么？在同意之前提出过哪些反对意见？
12. 从这周的会议里找出我们承诺要修的 bug，然后看看其中有没有已经在仓库里 修好的。
13. 把周二通话里的 API 决定写成一份可以放进 README 的简短规范。
14. 在我提这个 PR 之前：这个方案我们当时是同意了，还是通话里被否掉的 那一版？
这些在编辑器里才真正回本，因为助手可以在同一个会话里既读转写又读代码—— Cursor 的设置专门讲了这一点。 第 14 条挡住的是一个确实昂贵的错误：被否掉的设计过一周又会显得合理，因为当初 否掉它的理由留在了没人写下来的对话里。
15. 把过去六个月与这个客户讨论过的所有内容做个梳理，按主题而不是按日期 分组。
16. 客户批准了什么，又只是嘴上说喜欢什么？ —— 决定范围之争的正是 这个区分。
17. 从启动会里抽出约束和需求，跟我们最后做出来的东西对一遍。
第 15 条是让保留这份归档变得值得的那一条。六个月的通话按主题梳理出来，是一份 没人腾得出时间写的文档，而材料本来就已经在那里。
18. 给最近三条录音打上 api-redesign 标签。
19. 把昨天会议里的 Speaker 2 改名为 Marta，然后重读一遍，告诉我她对什么 提出了反对。
20. 把周二的面试归到我们的招聘频道里。
这些是会改动东西的命令，行为也不一样：它们需要 Speak-Y 应用处于运行状态，
并且被声明给您的 MCP 客户端为会改动数据，所以除非您给了长期授权，客户端会在
运行前先问您。MCP 规范明确写着，客户端“SHOULD”（应当）让人留在流程里，并在
敏感操作上请求确认。第 20 条会离开您的机器，在对话里也撤不回来，所以那条确认
值得读一遍，而不是顺手点过去。如果您宁愿某个客户端根本做不了这些，就在那个
客户端的配置里用 --read-only 启动服务器，改动类命令根本不会提供给它。
指望某个确切的措辞。 搜索是对转写正文、标题、摘要和待办事项做的不区分 大小写的子串匹配，不是语义搜索。“找到我们讨论供应商整合的那场会议”会一无 所获，如果当时会上说的是“要不我们就只用一家供应商吧”。描述时间范围，让助手 去读摘要，别去赌您的措辞和他们的说法正好一致。
问一场还没同步过来的会议。 录音留在录制它的那台设备上，再从您的其他设备 同步过来。每次读取都会报告数据有多新；如果某件您很确定的事没出现，先让助手 同步一次。否则“它不存在”和“它在我笔记本上”看起来一模一样。
让它删东西。 没有任何工具能删除录音、频道或工作区。删除是有意留在 应用里的。
以为它能看到整个公司。 助手读的是您的库，不是同事的。同事发布到共享 团队频道的会议可以用同样的工具读到；他们录下的其他内容则不行。
问一个转写回答不了的问题。 “客户当时是不是不高兴？”换来的是根据用词 做出的、语气笃定的猜测。语气不在文字里，而模型不会主动告诉您它在猜，除非您 要求它说明。
上面这些提示词有一个共同的形状，而且可以照搬：
范围 —— 一段时间、一个标签、一个客户名，或者“只看会议”。搜索按它来过滤， 不给的话，助手只能自己猜该读多少。
来源 —— 找到之后读什么：要决定就读摘要，要归属就读按说话人区分的段落， 措辞要准就读全文。
输出 —— 要点、表格、邮件草稿、规范文档。把它说出来，才能让一份总结变成 不用再改就能用的东西。
范围、来源、输出。“读我上个月与 Acme 的会议（范围），找出承诺了什么、由谁 承诺（来源），给我一张未兑现承诺的表格（输出）”——这比任何一句精巧的话都更 好用。
这里的每一条提示词，跑的都是您本人参加过的会议，而这正是真正的天花板：一个 决定背后的大部分理由，发生在您没有参加的通话里。发布到 团队工作区的会议，把同样的提示词扩展到同事有意共享的内容上，并保持 端到端加密——于是“我们当初为什么要这么做？”不再取决于当时谁在场。
如果您还没接上任何东西， 设置指南讲了从 设置 → 集成一键安装的做法，MCP 文档则有分 客户端的参考。这个服务器在所有套餐上都免费，包括 Free。
凡是它能读到的转写里回答得了的都可以：决定了什么、您承诺了什么、客户的异议在几次通话之间怎么变化、哪些待办事项还没了结。助手会搜索您的录音，读取看起来相关的那几份，并依据内容作答，而不是凭记忆。
不需要，而且通常不点名效果更好。描述时间和话题——比如“我这周关于定价的会议”——让助手按日期筛选并读取摘要。点名某个文件只在您已经确切知道要哪一条时才有用。
常见原因有三个。录音在另一台设备上，还没同步过来，让助手同步一次再试。搜索匹配的是字面文本，而您的措辞从未在转写里出现过。或者库里确实没有它——助手看到的和您在应用里看到的完全一致，不会更多。
它可以给录音打标签、重命名、为会议里的说话人命名、重新运行转写，以及发布到团队频道——但都需要 Speak-Y 应用处于运行状态，而且这些命令会被声明给您的 MCP 客户端为会改动数据，所以它会在执行前先问您。读取则不需要任何东西在运行。没有任何工具会删除录音。
只有被有意共享的部分。您自己的库是您录下的内容；同事发布到共享团队频道的会议，可以通过同样的工具读到，并保持端到端加密，而他们没有共享的一切都仍然不可见。