从会议纪要到 Playbook，中间还差什么？

记录的价值是什么？

我的工作性质决定了，我每天都要和各种各样的人打交道，开会、对谈是家常便饭。我个人又有一个努力保持的习惯：只要一段交流有价值、有信息增量，我就很想把它记下来。

如果不及时整理，总觉得手上还有件事没做完。以及我一直很相信一句话：持续不断记录，意义自然浮现。

很多信息刚出现的时候，只是一个片段。一场客户沟通里没有被展开的一句话，一次朋友聊天中突然冒出来的判断，一次分享后别人追问的问题，当下都不一定能看出它最后会走向哪里。

所以，我愿意先把它们留下来，不是因为每一个片段都要立刻变成文章，而是因为它们可能在半年以后、下一次客户交流里，突然和另一条信息碰到一起。

以及，我也一直相信，一个组织的成功，不在于个体有多强，而在于经验能不能慢慢变成大家的共识和能力。

所以我现在关心的，已经不只是“这场会有没有被记下来”，而是“这场会以后还能不能继续工作”，这场会议结束之后，它到底为这件事情本身，对于我们观察这类事物或是组织的上下文，创造了哪些有益的增量信息？

复杂事情简单做，简单事情重复做

“从客户现场到 Playbook”听起来像一套很复杂的系统。但我这几个月真正反复做的，其实都是一些很笨、也很基础的动作。

只要条件允许，每一场会议都会有录音。先把现场接住，再把它放回对应的人和项目里。记下一条真正影响后续动作的判断。下一次遇到相似的问题，再把上一次的记录翻出来。

说到底就是一句话：

“复杂事情简单做，简单事情重复做。”

这些动作单独看都不难，难的是一直做。但当它们重复几个月以后，我确实感觉到了一些变化。当然，这也是不断感慨这就是当下sota模型+harness工程的能力吗？🫢🫡

以前遇到一个问题，我可能要从头回忆背景；现在，过去的记录会重新回到眼前，不同项目里的相似信号也开始彼此连接。

例如我一直在关注「AI组织转型」这个话题，我前几天随手把晚点的一篇文章直接发给了我的codex，没有什么多余的prompt/skill，这篇文章会和我的观察库直接关联和归档，并自动综合分析：

在我实际参与、也有权限接触的范围里，无论是个人工作和生活，还是组织里的项目与协作，我都慢慢积累起了一层可以被重新调用的上下文。当下一个任务/观察进来时，不需要完全依赖自己的记忆，AI会自动找出对应的上下文来进行下一步的操作。

纪要有了，然后呢？

现在的会议工具已经很强了。录音、转写、说话人识别、摘要、待办，甚至所谓的“洞察”，会后很快就能生成，生成一个格式精美的会议纪要。

我过去也会很在意，一份纪要能不能做到“95 分”：既保留关键信息和生动细节，又足够简洁，稍微改改就能直接发出去。

这个要求今天依然重要。但现在拿到一份纪要以后，我会继续问几个很实际的问题：

• 这场会为什么偏偏在这个时间发生？
• 它和上一次沟通、项目历史有什么关系？
• 谁只是表达了一个观点，谁真的有权做决定、承担结果？
• 这次交流之后，对方内部到底发生了什么变化？
• 下一步是谁做什么？这次判断以后还会不会再被用到？

这些问题并不需要全部塞进一份越来越长的纪要里。纪要先负责把“说了什么”留住，后面的工作，是把它重新放回这件事发生的背景里。

比如，在一场销售会议里，“客户要了报价”只是一个事实。如果只看纪要，很容易顺手写成：“客户意向较强，后续发送报价并继续跟进。”

但真实情况可能完全不同。客户也许只是要完成一轮供应商比价，真正使用产品的人还没有出现，预算从哪里来也不清楚。

反过来，有些客户没有立刻要报价，却主动把业务 Owner、IT 或安全同事拉进下一轮，也愿意告诉你内部的时间表和验证条件。这样的变化，可能比“发了方案”“做了 Demo”更接近真实进展。

这也是我做销售之后越来越在意的一件事：

“不要只记录我们做了什么，要判断对方内部发生了什么变化。”

会议纪要能把现场留下来，但“什么变化值得相信”，还是要回到人物、历史、责任和后来的结果里判断。

Plaud + Codex + obsidian/notion

我之前写《我的 Plaud 用户体验：Context In 之后，Intelligence Out 了吗？》时，提过自己对它最大的一个“不满”：它活在我的工作流之外。

一份纪要如果只是躺在某个 App 里，哪怕当时写得再漂亮，过几天也很容易被忘掉。人还是懒的，但凡多增加一个步骤，很多事情就不会继续发生。

所以我现在真正想解决的，不是再找一个更会写纪要的工具，而是让纪要回到工作真正发生的地方。

在取得同意、边界允许的情况下，录音工具先把现场接住。重要的内容，我会保留原始转写，不让后面的 AI 总结把来源盖掉。

自从Plaud 开放cli和mcp之后，便利度大幅提升！

把材料放回具体项目里，让 Codex 去读过去的记录、参与者关系、项目阶段和我之前做过的判断。很多时候我不会先让它“给答案”，而是先让它帮我比较：什么延续了，什么变了，哪里出现了冲突，还有哪些信息其实不够。

本地 Markdown 是我现在的第一事实源，Obsidian 用来重新阅读和整理，Notion 更适合日常回看。听起来工具不少，但我并不是把同一份东西复制三遍（其实也都是写了一个规则，让Codex自动同步，防丢失），它们只是各自承担不同的工作。

一场会议进来以后，也不只会得到一种产出。它可能要回到项目里，变成下一步动作；可能需要给团队共享，留下风险和待确认项；也可能只进入我自己的复盘。至于公开文章，则是另一条路，必须重新检查来源、权限和脱敏边界。

模型越强，越需要把注意力放在构建自己的上下文上

这套实践，也慢慢改变了我看 AI 工具的方式。

随着模型能力继续提升，我越来越觉得：那些只是在通用模型外面包一层界面、帮人完成一次总结或生成的工具，空间会越来越小。

当然，这并不是说所有垂直工具都会消失。真正有独特数据、扎进真实流程、承接组织权限和责任，或者能够把结果跑出来的工具，还是很有价值。容易被模型升级吞掉的，是那些没有自己的上下文、也没有真正进入工作过程的单点能力。所以，比反复研究一句 Prompt 怎么写更值得长期投入的，是构建自己的上下文。

这可能也是为什么，模型正在和 IM、文档、协作平台靠得越来越近。钉钉官网把千问办公描述为与钉钉深度融合，飞书官方也把豆包企业版定义为能够在授权范围内使用企业知识和组织工具的工作产品。

与其笼统地说它们“合并”，更准确的说法可能是：模型正在进入那些拥有真实工作上下文的入口。

因为 IM 里不只有聊天记录，还有人、文档、会议、日历、任务、权限，以及一件事情为什么会走到今天的痕迹。

对一个人来说，真正值得长期积累的，可能也不是对某一个工具的熟练度，而是自己的材料、判断、关系与项目历史，以及一套能让它们继续进入行动的工作方式。

Playbook 不是一场会总结出来的

我以前也很容易在一次会议结束后，就让 AI 帮我“提炼一套方法论”。

现在我会更谨慎。一次会议最多先形成一个观察、一条假设，或者一个下一步动作。它还不是 Playbook。

真正的 Playbook，大概要经历这样一条路：

客观记录 → 放回上下文 → 形成判断 → 推进行动 → 看结果 → 下次继续用

所谓“看结果”，说得简单一点，就是下一次遇到相似的问题时，真的把上一次的判断拿出来，然后看看它到底有没有用。

如果一条经验从来没有在下一次现场里被调用，它更像一份写得很好的总结，还不能算 Playbook。

这也让我重新理解了“内容复利”。

真正的复利，不是把同一份录音拆成公众号、小红书、PPT 和课程。它应该是：一次现场改变了我的判断，这个判断又在下一次行动中被验证，最后才慢慢变成可以交给别人使用的内容和方法。

当然，不是每一场会议都值得这样处理。如果只是同步一个明确进度，Owner、行动和截止时间都很清楚，一份合格的纪要已经足够。

更值得继续往下走的，是那些会反复发生、决策代价比较高、涉及很多人，或者未来很可能再次遇到的问题。

一些可以直接参考的propmt/skill

我回头看了一遍自己和 Codex 的对话，真正反复出现的，其实不是多么复杂的 Prompt。很多时候，我只是不断提醒它三件事。

第一，先找旧材料，不要每次都从零开始：

先在当前目录和可以访问的历史任务里，找出与【项目 / 人物 / 主题】有关的材料。告诉我以前已经做过什么、最新主档在哪里，以及哪些是确认事实、当前判断和待确认事项。优先更新已有文件，不要从零重做。

第二，先把现场复原完整，不要急着总结：

读取【录音 / 转写 / 会议纪要】，先不要写观点摘要。按照现场实际发生的顺序，复原背景、参与角色、主要讨论、Q&A、转折和未解决的问题。区分已确认事实、对方直接表达、我的判断、AI 推断和待确认事项；材料里没有的信息不要补。

第三，不要只记录我们做了什么，要判断发生了什么变化：

同时读取本次材料和【项目历史 / 旧记录】。比较哪些信息只是延续，哪些是新增或冲突，哪个旧判断被支持、削弱或推翻。不要只列出我们的动作，请判断对方内部发生了什么变化，并为每条判断写明证据、竞争解释、下一步、Owner 和完成证据。

这些话我用了很多次以后，才慢慢把它们整理成模板和 Skill。对我来说，Skill 也不是一条更长、更复杂的 Prompt。它真正固定下来的，是一类任务什么时候触发、要读取哪些材料、应该产出什么、哪里必须停下来问我，以及做完以后写回哪里。

完整的 Prompt、Obsidian 模板和 Skill，我放在了文末的「阅读原文」里。有兴趣的话，可以直接下载，再按自己的工作习惯修改。

会议结束，经验才刚刚开始

如果你也想尝试，不需要先搭一个复杂的知识库。找一种最近经常重复发生的会议，先做一次最小尝试：

1. 把原始录音、转写或可靠笔记留下来。
2. 把它放回项目目标、历史记录和参与者关系里。
3. 写下一条真正影响后续动作的判断。
4. 下一次遇到相似问题时，把它翻出来，再根据结果修改。

这几步都不复杂。难的是简单的事情一直重复做。

会议纪要生成之后，真正的工作才刚刚开始。当然，我也很想好奇：你现在的会议纪要，通常会停在哪里？

JOTO 企业落地观察

• 对企业部署意味着，会议纪要工具不应止步于单点生成，而需嵌入项目管理、CRM或IM等具备真实组织上下文的系统中，否则生成内容易沦为一次性信息孤岛。
• 这类系统的取舍在于：是否支持将原始录音、转写文本与历史判断、项目阶段、人员权限等结构化元数据绑定，从而支撑后续的上下文感知推理与行动触发。
• 对RAG知识工程而言，会议内容的真正价值不在全文索引，而在能否建立‘判断-证据-验证’的闭环链路；缺乏验证反馈机制的知识注入，难以沉淀为可复用的Playbook。
• AI安全治理需关注会议数据流转中的权限边界——当录音、转写、判断被跨工具同步时，必须确保每一步操作均符合组织内关于客户信息、商业判断与决策责任的合规要求。