你开完会，录音转成文字，丢给 AI，出来一段流畅的总结。然后呢？没人看，没人跟进，下周又开同样的会重复同样的讨论。会议纪要最大的痛点从来不是写不出来，而是写出来之后就死在文档里。
Smithery 上的 github/meeting-minutes 这个 Skill，瞄准的正是这个断层。它不把自己定位成“会议总结生成器”，而是“可执行的会议纪要在内部短会中的标准化生产流程”。这个定位差别，决定了它后面整套设计的走向。换句话说，它关心的是讨论结束之后事情能不能真的往前走，而不是那场会本身被描述得多清楚。
从文档来看，它只服务 60 分钟以内的内部会议，典型覆盖范围其实很窄：
-
同步会与每日站会 -
设计评审与故障分诊 -
规划会和临时碰头
超过这个时长或对外客户会，它明确不在射程内。先把边界划清，是它第一个让我觉得克制的地方。
我一开始以为这又是个套了层 Prompt 壳的“总结工具”，翻了翻 SKILL.md 才发现，它真正花力气的不是“总结”，而是把讨论结果翻译成带 owner、due date、acceptance criteria 的行动项。这部分才是它和随手丢给 ChatGPT 的本质区别。
多说一句为什么这件事值得专门做个 Skill。会议纪要沉淀的是团队的共同记忆，但大多数工具只负责把话记下来，不负责让记下来的东西能流动。差这一层，会议纪要就只是归档，不是协作。
架构解析
整个 Skill 的骨架是一套叫 Strict Minutes Schema 的东西，12 个区块，强制输出。我把它按职责拆成四层，方便理解它把“记录”拆成了哪几类信息：
-
基础事实层：Metadata 与 Attendance -
过程记录层：Agenda、Summary、Notes by Agenda Item -
决策与行动层：Decisions Made 与 Action Items -
治理收尾层：Parking Lot 到 Version Log
最底层是 Metadata 和 Attendance，记录参与人、时间、地点与缺席情况。这层没什么技术含量，却是后面所有可追溯性的地基。没有组织者和分发列表，这份纪要连该发给谁都不知道。
中间两层负责还原现场。Agenda 和 Summary 给全局脉络，Notes by Agenda Item 才是细节主战场，它要求按每个议程项记要点、可带时间戳、标出未决问题。这一层决定纪要是不是能用，而不只是好看。很多团队事后翻纪要，找的就是某一议题当时到底议了什么，这层正是为这个检索需求服务的。
真正的价值在决策与行动层。Decisions Made 每条决策都要交代三件事：
-
谁拍的板 -
为什么这么定 -
什么时候生效
Action Items 更狠，每个行动项强制带 owner、due date 和 acceptance criteria，还能挂 ticket 链接。从文档推断，这两块才是它“易于转成任务追踪器”承诺的兑现点。
最上层是治理收尾层：Parking Lot 收未决议题，Risks/Blockers 记风险，再加 Next Meeting、Attachments、Version Log。很多人写纪要会漏掉哪些事没定，它用固定区块把这种不确定性显式留了下来。
工作流分析
光有 Schema 还不够，它配了一条四阶段 Operational Workflow 来喂数据，名字依次是：
-
Intake：收集元信息 -
Capture：采集现场 -
Drafting：套模板生成 -
Review & Publish：复核发布
这条链路有意思的地方在于，它在最前面就装了一道“防垃圾”闸门。
这道闸门看起来多此一举，其实是它和通用总结工具的分水岭。通用工具拿到半截信息也会硬写，产出一片看似合理的废话；它宁可先打断你问三句，也要保证后面的 Schema 填的是真东西。代价是多一轮往返，收益是纪要从源头可信。
Phase 1 Intake 阶段，标题、日期、组织者这类基本信息缺失时，或者拿不到议程与录音时，它必须主动提最多 3 个澄清问题，而不是直接编。从设计上看，这是在用一次交互成本换产出可信度，比那些拿到半截信息就开写的工具稳。
Phase 2 Capture 是真正的采集环节：记出席和缺席，逐议程抓要点，标注决策与理由，再提取潜在行动项。这阶段和转录工具的关系是互补而非替代，它吃的是已经整理过的素材，不是从零听录音。
Phase 3 Drafting 把素材套进 Schema，重点是把行动项补全成“负责人、截止时间、验收标准”的完整形态。文档特别强调，信息不确定的地方标 TBD 并说明去哪补，而不是用模型自己编的圆话糊弄过去。
Phase 4 Review & Publish 要求尽量在 24 小时内发给组织者或指定复核人快速确认，再发布到约定渠道，可选地在任务系统里建工单。注意是可选地，这里埋着一个我后面要讲的局限。
使用场景
落到真实场景，假设你跑一个 45 分钟的 Platform Weekly Sync，手头既有议程也有录音转写。你把会议的标题、日期和时长，连同组织者一起丢给它，它先问你有没有需要指定的复核人，然后吐出一份带 12 个区块的纪要。
行动项这块最见功力。比如一条“起草 Feature X 部署 runbook”，它不会只写半句，而是补全成下面这样，贴进 Jira 或 GitHub Issues 几乎不用二次加工：
[A1] 起草 Feature X 部署 runbook
- Owner: Alex（工程）
- Due: 2026-02-05
- Acceptance: 含回滚步骤、健康检查、监控链接
- Ticket: github.com/owner/repo/issues/123
这种产出对研发团队尤其友好。周会散场后，原本要有人花半小时把讨论整理成工单，现在这份纪要直接就是工单草稿。省掉的不是写字的功夫，而是从讨论到执行之间那段最容易断的衔接。
但边界也要说清楚。它明确只吃短会，超过 60 分钟或客户对外会议不在设计范围。两小时的 workshops 硬套进去，Notes by Agenda Item 会膨胀到不可读，Schema 被撑变形。文档对长会该怎么处理没有给方案，我判断真要套，得先拆成多场短会分别跑。
还有个隐藏前提：它假定你手头已经有议程、录音或笔记。纯靠脑子回忆开完会再让它写，Capture 阶段没有素材可抓，效果会退化成普通总结。输入质量直接决定输出质量，这个常识它没替你绕过。
洞察与反思
拆完之后，我最想说的一点：它和把录音丢给 ChatGPT 的差距，不在模型能力，在结构约束。同一段会议，朴素摘要给你一段读着舒服但没法跟的话；它给你一张能直接建工单的表。
左列那种自由散文式产出，最大问题是行动项没有 owner 和 due，两周后没人记得谁该干啥。右列的 12 段式把责任、时限和验收标准焊死在结构里，纪要从记录变成了执行起点。这就是 Schema 存在的意义。
不过得泼盆冷水。它叫 Skill，本质是 Prompt，不是 Agent。文档里“可选地在追踪器里建任务”那句，意思是它产出的是适合建工单的格式，并不真的帮你调 GitHub 或 Jira API。从易于转换到自动转换，中间还差一个集成层，它没填。
另一个我存疑的点是僵化。12 段式对大多数团队是好事，但对一些偏好轻量纪要的组织，强制产出 Version Log、Parking Lot 反而显得重。好在它通过信息缺失标 TBD 留了弹性，不会逼你硬填，这点设计上是懂行的。
还有个容易被忽略的收益：ISO 8601 的日期和固定的区块顺序，让纪要是机器可读的。哪天你想把所有会议行动项聚合成一张大看板，结构化输出比散文摘要好抽取得多。很多团队要到真要做时才发现这点价值。
顺带提一句它的验收标准。文档给了一份生成的纪要是否合格的清单：必须有元信息、出席、决策和行动项四块，每个行动项有负责人和时限，重大决策带理由，附件要么列出要么标无。这条线画得很实在，没达标的产出它自己都建议打回。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery 技能页 | https://smithery.ai/skills/github/meeting-minutes |
总结
meeting-minutes 是个边界清晰、设计克制的 Skill。它不追求万能，只把 60 分钟内内部会议这件事做到位：用四阶段工作流保证输入可信，用 12 段式 Schema 把讨论压成可追踪的行动项。它没有试图覆盖所有会议形态，反而把火力集中在最容易被遗漏、也最影响执行的行动项上。
它适合已经用 GitHub Issues 或 Jira 做任务管理的团队，尤其那些被开会热火朝天、散会没人跟进困扰的。不适合需要自动建工单集成的团队，也不适合长会或对外会议，那不是它的活。
往后看，这类结构化纪要最自然的演进是把 Phase 4 的可选建工单做成真集成。一旦 Schema 的输出能直接落到 Issue 系统，它才算真正闭环。在那之前，把它当一个高质量的工单草稿生成器来用，已经值回票价。