每周团队例会
使用场景: 团队负责人主持 15 分钟周一同步会
日期：周一 09:00 | 参会：全团队（6 人）
每人汇报：上周完成 / 本周计划 / 阻塞问题
阻塞项：API 速率限制阻碍移动端团队
行动项：后端负责人 — 周三前提升速率上限
下次例会：下周一 09:00
这样组织的原因: 以阻塞问题为核心记录例会，而不是状态汇报，让会议记录在周五依然有价值——你可以检查阻塞是否解除，而不是重读大家在做什么。
真实案例
客户项目启动会
使用场景: 客户经理或顾问启动新合作项目
客户：Acme Corp | 日期：1 月 14 日 | 参会：客户 4 人、代理商 3 人
项目目标：Q2 前重新上线电商网站
决策：代理商主导 UX，客户审批所有文案
行动项：客户 — 1 月 21 日前提供品牌资产
行动项：代理商 — 1 月 28 日前交付网站结构草稿
待确认：客户 1 月 18 日前确认付费媒体预算
这样组织的原因: 把决策和待解决事项白纸黑字写下来，能防止最常见的项目失败——双方带着不同假设离开会议室，对各自该做什么没有共识。
一对一管理谈话
使用场景: 管理者与直属下属进行月度职业发展沟通
日期：2 月 3 日 | 管理者：Alex | 下属：Jordan
Jordan 本月亮点：上线了认证系统改版，带新了两位新同学
Alex 的反馈：需要更早主动沟通阻塞问题
Jordan 下月目标：主导 API 迁移方案设计
行动项：Alex — 2 月 10 日前为 Jordan 对接高级架构师
行动项：Jordan — 2 月 17 日前完成迁移提案初稿
这样组织的原因: 把反馈和目标写在同一份记录里，双方可以随时回顾——避免了管理者和下属对同一次谈话各有不同记忆的常见情况。
产品迭代规划会
使用场景: 产品经理和研发负责人规划两周 Sprint
Sprint 14 | 时间：2 月 17–28 日 | 容量：32 个故事点
本次承诺：用户通知（8）、搜索筛选（5）、Bug 修复（6）
决策：数据分析看板推迟到 Sprint 15
行动项：PM — 2 月 18 日前完成通知功能验收标准
行动项：研发负责人 — 2 月 18 日前拆分搜索筛选子任务
风险：通知功能设计稿尚未定稿
这样组织的原因: 在记录中注明容量和延期原因，方便后续解释优先级决策——「我们推迟分析看板是因为容量是 32 点，不是 40 点」是清晰的答案。
Sprint 复盘会
使用场景: Scrum Master 主持 45 分钟迭代末复盘
Sprint 13 | 团队：平台组（5 人）
进展顺利：CI 流水线提速，PR 审查周期缩短
待改善：需求不清晰导致两次返工
行动项：PM — 任何故事进入 Sprint 前必须写完成定义
行动项：团队 — 每周五留一小时做异步代码 Review
下次复盘检查：完成定义流程是否减少了返工？
这样组织的原因: 复盘记录只有在下次复盘时被检查才有价值。为每个行动项写一行「下次检查」，让问责机制自动生效——主持人在下次复盘开始时直接读出来。
高管战略复盘
使用场景: CEO 或 COO 主持季度业务回顾
Q1 复盘 | 参会：CEO、CFO、CPO、CTO、销售 VP
决策：Q2 追加 4 个研发 HC
决策：暂缓亚太市场拓展至 Q3
行动项：CFO — 1 月 31 日前修订 Q2 预算模型
行动项：销售 VP — 3 月季度复盘呈交亚太准备情况报告
保密：请勿在领导层以外传阅
这样组织的原因: 高管会议记录需要简洁、以决策为核心。冗长的讨论摘要很少有人看；决策和负责人清单则会在每次后续高管会前被回顾。
使用技巧
- 行动项写法：'负责人 — 任务内容 — 截止日期'，不要只写'后续再讨论 X'——模糊的行动项永远不会被执行。
- 24 小时内发出会议纪要；时间越长记忆越模糊，需要核实的细节也越多。
- 把未解决问题单独列一节，不要混在决策或行动项里。
- 如果某项决策有争议，简要记录为什么否定了备选方案——这能防止三个月后同样的问题被反复讨论。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=meeting-notes
使用这个模板