---

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

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

会议纪要

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

所需输入

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

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

从大脑读取 / 写入大脑

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

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

标准会议纪要模板

会议抬头

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

议程

• 议题 1
• 议题 2
• 议题 3

（讨论过的勾选）

已做出的决定

清楚记录决定：

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

每个决定都用这个格式。

待办事项

所有待办事项应写成：

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

格式要求：

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

讨论要点

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

议题 1：[名称]

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

议题 2：[名称]

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

待解决问题 / 跟进

没能回答的问题：

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

下一步

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

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

最佳实践

会议中：

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

会议后：

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

验证

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

回滚

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

示例触发语

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