← LeaderboardThe Skill Leaderboard

meeting-notes

按产品经理的最佳实践整理会议纪要。当被要求写会议纪要、整理讨论记录、记录待办事项或记录任何类型会议的决定时使用。产出结构化纪要：决定、待办事项（负责人加截止日期）、待解决问题和下一步。

Published by mohitagw15856 ↗mohitagw15856/pm-claude-skills

Try your first task

meeting-notes

Start a fresh conversation. Replace the highlighted placeholders.

Use meeting-notes to organize a structured meeting summary for [meeting name and date, attendees with roles, raw notes or transcript, and meeting type], producing a final document that includes decisions (with background and owners), actionable to-do items with single assignees and deadlines, key discussion points by topic, unresolved issues, and next steps.

Required inputs

[meeting name and date, attendees with roles, raw notes or transcript, and meeting type]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

name: meeting-noteslanguage: zhdescription: "按产品经理的最佳实践整理会议纪要。当被要求写会议纪要、整理讨论记录、记录待办事项或记录任何类型会议的决定时使用。产出结构化纪要：决定、待办事项（负责人加截止日期）、待解决问题和下一步。"

meeting-notes 的简体中文翻译，英文版本为规范版本。

会议纪要

这个技能整理会议纪要，让它发挥最大价值，并确保事情落地。

所需输入

如未提供，请向用户询问：

会议名称和日期
参会人（姓名和角色）
原始笔记或文字记录（粘贴讨论笔记、文字记录，或描述讨论了什么）
会议类型（一对一 / 迭代规划 / 产品评审 / 干系人同步 / 其他），决定使用哪个模板

从大脑读取 / 写入大脑

如果存在 professional-brain（brain/），纪要就在这里变成长期记忆：

先读： 相关的 stakeholders/ 文件（这样你进会议时就知道每位参会人未解决的请求和顾虑），以及会议要重新讨论的 decisions/。
之后写： 把每个决定（附理由和 reopen-when）追加到 decisions/，把新的请求或顾虑加入对应的 stakeholders/ 文件，把任何新的假设记入 hypotheses/。给每条记录的事实标注来源：大多数会议发言在被独立确认之前都是 [verbal]。把原始笔记保存到 source/。

标准会议纪要模板

会议抬头

会议：[会议名称] 日期：[日期] 参会人：[姓名 / 角色] 记录人：[姓名] 时长：[实际时长]

议程

议题 1
议题 2
议题 3

（讨论过的勾选）

已做出的决定

清楚记录决定：

决定：[决定了什么] 背景：[为什么这样决定] 负责人：[谁负责执行] 截止日期：[如适用]

每个决定都用这个格式。

待办事项

所有待办事项应写成：

[待办事项] - @负责人 - 截止：[日期]
[待办事项] - @负责人 - 截止：[日期]

格式要求：

清楚、具体的行动
单一负责人（不能是"团队"）
明确的截止日期
用勾选框跟踪

讨论要点

按议题整理讨论的关键点：

议题 1：[名称]

关键观点或讨论重点
提出的重要背景或顾虑
分享的数据或信息

议题 2：[名称]

关键讨论点
达成的决定或结论

待解决问题 / 跟进

没能回答的问题：

问题：[我们需要知道什么]
负责人：[谁去查清楚]
截止：[日期]

下一步

清楚总结接下来会发生什么：

[紧接着的行动]
[如需要，跟进会议]
[需要启动的更大流程]

最佳实践

会议中：

关注决定和待办，而不是对话本身
记录具体的承诺，而不是泛泛的讨论
重要决定上记录反对意见
对含糊的承诺要求说清楚（"我去看看" → "我会分析数据，周五前分享结论"）

会议后：

趁记忆新鲜，2 小时内发出纪要
@ 待办事项的负责人
附上相关文档链接
跟进逾期的待办

要记录什么： ✅ 已做出的决定 ✅ 有负责人和截止日期的待办 ✅ 讨论的关键点 ✅ 待解决问题 ✅ 下一步

不要记录什么： ❌ 逐字记录 ❌ 跑题的内容 ❌ 做决定之前的初步讨论 ❌ 重复的信息

会议类型与调整

一对一会议

关注：

职业发展讨论
反馈（双向）
当前的挑战
双方的待办

模板补充：

近期成绩：进展顺利的事
挑战：不顺利的事
职业讨论：发展话题
反馈：给双方

迭代规划

关注：

故事的验收标准
估算决定
识别依赖
迭代承诺

模板补充：

迭代目标：我们承诺什么
故事点：容量和估算
依赖：外部阻碍
完成定义：验收标准

产品评审

关注：

设计决定
讨论的用户反馈
提出的修改
上线准备度评估

模板补充：

设计决定：批准或否决了什么
用户反馈：讨论的关键洞察
待定的设计问题：需要迭代的地方
上线标准：剩余的要求

干系人同步

关注：

汇报的进展
提出的顾虑
给出的批准
需要升级的事项

模板补充：

进展概览：整体进度
已获批准：拿到的签字确认
升级事项：提给干系人的问题
下次同步：时间和内容

会议纪要示例

# 产品路线图评审：2026 年第一季度
**日期**：2026 年 1 月 20 日
**参会人**：Sarah（CPO）、Mike（技术负责人）、Jennifer（设计）、Tom（产品经理）
**记录人**：Tom
**时长**：45 分钟

## 议程
- [x] 评审第一季度计划的功能
- [x] 讨论资源限制
- [x] 优先级讨论
- [x] 时间线对齐

## 已做出的决定

**决定**：多渠道工作台移到第二季度，第一季度优先改进移动端 App
**背景**：客户反馈显示移动端体验严重影响留存（65% 的用户主要使用移动端）。工程团队本季度只能承担一个重大项目。
**负责人**：Tom（产品经理）负责向干系人沟通
**截止日期**：1 月 22 日

**决定**：拿出 20% 的工程时间处理技术债
**背景**：累积的技术债正在拖慢功能开发。上季度团队速率下降 30%。
**负责人**：Mike（技术负责人）建立技术债待办列表
**截止日期**：1 月 27 日

**决定**：全量上线前先对 100 名用户做移动端内测
**背景**：需要在不同设备上验证改进效果
**负责人**：Jennifer（设计）与测试团队协调
**截止日期**：2 月 10 日

## 待办事项
- [ ] **按新优先级更新第一季度路线图** - @Tom - 截止：1 月 22 日
- [ ] **与客服团队约会议，沟通工作台延期** - @Tom - 截止：1 月 24 日
- [ ] **制定技术债优先级评分标准** - @Mike - 截止：1 月 27 日
- [ ] **对移动端设计做用户测试** - @Jennifer - 截止：2 月 3 日
- [ ] **为高管写清决策理由** - @Sarah - 截止：1 月 23 日
- [ ] **找到 100 名移动端内测用户** - @Tom - 截止：2 月 1 日

## 讨论要点

**第一季度功能优先级**
- 客户留存是本季度公司的第一优先级
- 移动端 App 的 NPS 为 6.2（网页端为 8.1）
- 移动端占日活用户的 65%
- 多渠道工作台需要 8 个工程周
- 移动端改进估计需要 6 个工程周，回报更高
- 销售有 3 个企业客户订单在等工作台功能

**资源限制**
- 目前有 4 名工程师可用（上季度为 6 名，因人员流失减少）
- 设计团队可以同时支持两个项目，但产能下降
- 测试团队需要 2 周对移动端做完整测试
- 一名工程师借调到安全团队直到 2 月

**风险讨论**
- 推迟工作台可能影响企业销售（3 个订单在等）
- Sarah 指出："我们可以把移动端改进定位为企业功能的基础"
- Mike 对移动端技术栈的稳定性表示担忧，已通过技术债时间分配解决
- 需要就时间线变化与销售清楚沟通

**移动端实施计划**
- 第 1 到 2 周：根据用户反馈细化设计
- 第 3 到 4 周：工程实现
- 第 5 周：内部测试
- 第 6 周：100 名用户内测
- 第 7 周：全量上线

## 待解决问题
- **问题**：推迟工作台对企业销售管道有什么影响？
  **负责人**：Sarah 向销售负责人确认
  **截止**：1 月 23 日

- **问题**：能否为企业客户做工作台的有限内测？
  **负责人**：Tom 与 Mike 探讨 MVP 范围
  **截止**：1 月 25 日

- **问题**：如果移动端改进没有达到目标指标，我们的计划是什么？
  **负责人**：Tom 制定应急方案
  **截止**：1 月 27 日

## 下一步
1. Tom 在周三（1 月 22 日）下班前把更新后的路线图发给领导层
2. 团队下周一（1 月 27 日）开始移动端改进的迭代规划
3. 2 月 1 日开跟进会，检查进展并验证优先级
4. Sarah 在 1 月 24 日向高管团队汇报决策理由

---

**下次会议**：2026 年 2 月 1 日，进展检查
**纪要发出时间**：2026 年 1 月 20 日 17:30

延伸材料

这个技能附带支持文件，可用时请使用：

references/decisions-vs-discussion.md：区分决定与讨论。在产出时应用它；它包含上面方法摘要压缩掉的校准和判断。
templates/notes-skeleton.md：可填写的成果模板，质量关卡写在里面。当用户想自己完成文档而不是生成时提供。

评分量表（0 到 40）

交付前给这个技能的任何产出打分；32 分以上才算可以交付。

维度	0	5	10
待办问责	待办分给"团队"或没人负责，没有日期	有负责人，但截止时间含糊（"下周"、"尽快"）或多人共担	每个待办都有且只有一个负责人和明确日期；共同的工作拆成分别负责的事项
决定可追溯	决定埋在讨论里，或记录了却没有理由	列出决定和负责人，但理由单薄；分歧看不到	每个决定都有背景、负责人和截止日期；反对意见记录在决定中并附重新讨论的条件，而不是被抹平
提炼而非记录	按顺序逐字记录谁说了什么	按议题整理的精简记录，但仍是对话而不是提炼	讨论被提炼为承重的要点；只有在影响决定时才引用原话
闭环	待解决问题、推迟的议题和升级被悄悄丢掉	列出了待办，但没有负责人或日期；推迟的事从下一步中消失	每个待解决问题都有负责人和截止时间；推迟的事带日期出现在下一步中；纪要在 2 小时内发出

质量检查

每个待办都有一个具名负责人（不是"团队"）
每个待办都有明确截止日期
决定包含背景（为什么这样决定）
待解决问题有负责人和截止时间
没有逐字记录，只有提炼

反模式

不要把待办分给"团队"或"大家"：每个待办必须有且只有一个具名负责人，否则不会完成
不要逐字记录对话：会议纪要记录的是决定和承诺，而不是达成它们的完整对话过程
不要省略决定的背景：六个月后有人问"我们为什么这么做"时，没有理由的决定毫无用处
不要让待解决问题没有负责人和截止日期：没人跟进的问题就是被卡住的决定
不要在会后超过 2 小时才发纪要：第二天才发，负责人就错过了趁热行动的窗口

纪要分发

邮件标题格式："[会议类型] 纪要 - [日期] - [关键议题]"

示例："产品路线图评审纪要 - 1 月 20 日 - 第一季度优先级"

收件人：

所有参会人
待办中提到的任何人
任何要求收到纪要的人

跟进：

在待办截止前 3 天发提醒
每周汇总所有未完成的待办
把完成的待办标记出来并同步进展

执行

供已连接 MCP 服务（Notion、Linear / Jira、Slack）的工具型智能体使用。没有工具权限的运行环境忽略这一部分，只交付文档。参见 SKILLSPEC.md §5 和 connectors/mcp-pairings.md。

前提条件

上面的结构化纪要已经展示给用户并得到明确批准，包括目的地（哪个 Notion 数据库或页面、哪个任务跟踪项目）。
MCP 服务已在智能体的环境中连接并完成认证。
每个待办都有具名负责人：没有负责人的事项先与用户确认，绝不凭猜测分配。

允许的操作

在批准的 Notion 数据库（或同类文档工具）中创建一个页面，内容为批准的纪要原文。
在批准的项目中为每个批准的待办创建一个任务（标题、负责人、截止日期来自纪要）。
如果用户指定了频道，把页面链接（只有链接和一句摘要）发到该频道。
其他一律不做：不编辑已有页面或任务，不邀请或通知指定频道之外的人，不写入日历。

验证

读取创建的页面和每个创建的任务；确认标题、负责人和日期与批准的纪要一致。
把所有创建的链接用一个列表报告给用户。

回滚

撤销 = 只在用户明确指示时，归档或删除刚创建的页面和任务。
遇到以下情况，停下来问用户：找不到目标数据库或项目、任务创建中途失败（报告已经创建了什么）、待办负责人在任务系统中不存在。

示例触发语

“帮我整理会议纪要。”
“把讨论笔记整理一下。”
“列出待办事项。”
“记录这次会议的决定。”