今天周六还在干活，把前几场会沉淀出来的一套东西，正式写成了一篇 SOP，叫《会议闭环_从0到企微发送.md》。写它的冲动很简单：一场会开 3 小时，散了就归零。人脑记不住，群里聊一半就淹了，下周回头找决策，谁都说不清。我做咨询陪跑最怕这个——老板拍了板，回去没人落实，等于白开。

过去靠人记。会后我让助理出纪要，慢、漏、还带个人理解偏差。现在不一样，WorkBuddy 接上了 tmeet，会一散，自动把腾讯会议的转写拉回来，我再让 AI 总结改写，按角色拆成不同版本，最后用”腾总”走个人微信自动发到对应的人。

但这里有个认知必须先掰清楚：tmeet 不是你本地装的一个 MCP 客户端。它是 WorkBuddy 托管的本地 MCP Server，走 SSE 协议，再用 OAuth 桥接腾讯会议云端。说人话就是——它在你机器上跑服务，但身份是腾讯会议云端认可的，所以能正经拉到转写和成员。这个认知不理清，后面配置全错方向。

然后说”腾总”。它发消息走的是个人微信桌面版，不是企业微信。这一点太关键了：企微发群有 10 人限制，个人微信没有。我们就是靠这个绕开限制，才能把纪要稳稳发到该发的群。

我这套闭环，用 MECE 拆成四层，互不重叠：

第一层，会议事实层。管”发生了什么”——时间、主题、参会人、原始转写。纯事实，不加判断。

第二层，管理判断层。管”决定了什么”——决策、行动项、责任人、截止时间。这是从事实里提炼出来的管理信号。

第三层，分流层。管”发给谁”——老板收决策摘要，负责人收自己的行动项，团队收完整纪要。一份会议，三种版本，各取所需。

第四层，安全发送层。管”发之前”。先展示草稿给人确认，点确认了才真正发出去。绝不悄咪咪自动飞。

四层之间，事实→判断→分流→发送，像流水线一样，前一层是后一层的输入，不重复、不遗漏。

写这篇 SOP 的时候，我顺手把两个真坑记了进去，都是实战踩出来的：

坑一，企微机器人报 850004。一开始以为配置错了，折腾半天。后来搞清楚——那是”非 API 模式”的提示，不是你配错，是路径不对。别在错误方向上死磕。

坑二，更阴。模板匹配打满分，max_val=1.00，看着稳得一批，结果消息发错群了。满分不等于发对地方。所以我现在只用”路径A”：视觉确认聊天列表再点进去发，不靠模板匹配、也不靠搜索下拉框。稳。

这篇 SOP 现在是固化资产了，以后开会散场，照着跑就行。

给你一个能照搬的动作：你下周开会，别再散了就散了。先用工具把转写拉回来，按”事实—判断—分流—发送”四层写一份纪要模板，发出去之前让人确认一眼。哪怕不用 WorkBuddy，这个四层结构你手抄都值。会议不归零，团队才转得动。