meeting-synthesizer

会议综合整理技能

将原始会议记录和转录内容转化为可执行的情报。此技能可从非结构化会议数据中提取关键信息，并将其整理为结构化格式，以推动后续跟进并明确责任。

概述

会议综合整理技能会处理会议记录或转录内容，并生成：

• 行动项：明确的任务，包含负责人、截止日期和背景信息
• 已做出的决定：关键决定及其理由和影响
• 讨论要点：重要主题、辩论和达成共识的领域
• 后续任务：按优先级排列的任务列表及后续步骤
• 关键洞察：规律、顾虑和新兴主题

何时使用此技能

• 在团队会议、每日站会或规划会议之后
• 将转录内容/记录整理为结构化行动项时
• 需要快速提取决定并明确责任时
• 为未能参加会议的利益相关者整理会议记录时
• 根据会议讨论创建任务列表时

如何使用此技能

基本工作流

1. 提供会议内容

   • 分享会议记录（键入或粘贴）
   • 分享转录内容（来自 Zoom、Teams 或其他平台）
   • 分享语音转文字内容

2. 请求处理

   • 请此技能综合整理会议内容
   • 可选：指定重点关注的内容
   • 可选：提供格式偏好（markdown、JSON 等）

3. 检查并采取行动

   • 检查提取的信息
   • 指定负责人和截止日期
   • 创建工单或日历事项
   • 与团队分享结果

提示词示例

综合整理

Synthesize this meeting:
[paste meeting notes/transcript]

Extract all action items, decisions, and key points.
Organize by priority and due date.

重点整理行动项

Extract action items from this meeting:
[paste meeting notes]

For each action item, provide:
- Task description
- Owner/responsible person
- Due date (if mentioned)
- Context/why it matters
- Dependencies

提取决定

What decisions were made in this meeting?
[paste meeting notes]

For each decision, provide:
- What was decided
- Why (reasoning/justification)
- Who made the decision
- Who is affected
- Any dissent or concerns

按优先级排序

Synthesize this meeting with priority ordering:
[paste meeting notes]

Order action items by urgency and impact.
Identify any blocking items or critical path items.
Flag any decisions that need follow-up or clarification.

处理说明

1. 解析会议内容

识别输入：

• 检测格式：结构化记录、转录内容、项目符号列表、自由文本
• 识别参与者：谁参加了会议、谁发了言、各自的角色
• 提取时间戳：讨论发生的时间（如有）
• 识别背景信息：会议类型、议程、目标

规范化：

• 清理格式不一致之处
• 尽可能展开缩写
• 澄清含糊的指代
• 将相关事项归类

2. 提取行动项

识别：

• 查找明确分配的任务：“Alice 会……”“我们需要……”
• 识别隐含任务：需要落实的决定
• 查找有时限的事项：“周五前”“下个迭代”“尽快”
• 识别依赖关系：“等 X 完成后”

构建结构：

Action Item:
  Description: [Clear, specific task]
  Owner: [Person responsible]
  Due: [Date/timeline]
  Context: [Why it matters]
  Dependencies: [What must happen first]
  Priority: [High/Medium/Low]

3. 识别决定

检测：

• 明确的决定：“我们决定……”“我们将……”
• 达成共识的时刻：“大家都同意……”“共识是……”
• 做出的选择：“我们选择 X 而不是 Y”
• 方向调整：“我们正在从 X 转向 Y”

记录：

Decision:
  What: [The decision]
  Why: [Reasoning/justification]
  Decided By: [Who decided]
  Affected: [Who is impacted]
  Dissent: [Any concerns/opposition]
  Implementation: [How will it work]

4. 记录讨论要点

提取：

• 讨论的主要主题
• 辩论或不同观点
• 未解决的问题或不确定事项
• 达成一致的原则或方法

整理：

Discussion Point:
  Topic: [What was discussed]
  Viewpoints: [Different perspectives]
  Consensus: [What was agreed]
  Open Issues: [Unresolved items]

5. 生成后续任务

识别：

• 需要澄清：“我们应该向 X 确认”
• 收集信息：“研究 Y 的可选方案”
• 安排日程：“安排与 Z 的同步会议”
• 沟通：“向利益相关者通报决定”

确定优先级：

• 紧急：阻碍其他工作，影响重大
• 高：重要且需要尽快完成
• 中：应该完成，但不急
• 低：有则更好，优先级较低

输出格式

选项 1：Markdown（默认）

# Meeting Synthesis: [Meeting Title/Date]

## Participants

- Alice (Product Lead)
- Bob (Engineering)
- Carol (Design)

## Decisions Made

### Decision 1

- **What**: Adopt Vue 3 for new frontend
- **Why**: Better TypeScript support, smaller bundle size
- **Decided**: By consensus
- **Impact**: Requires training for team members using Vue 2

### Decision 2

- **What**: Delay launch by 2 weeks
- **Why**: Need more time for security review
- **Decided**: Product + Security alignment
- **Impact**: Affects Q4 roadmap planning

## Action Items

### High Priority

- [ ] Complete security audit (Bob, Due: Friday)
- [ ] Prepare Vue 3 migration plan (Carol, Due: Monday)

### Medium Priority

- [ ] Schedule team Vue 3 training (Alice, Due: Next week)

### Low Priority

- [ ] Document decision rationale (Bob, Due: End of sprint)

## Key Discussion Points

- Concerns about timeline slippage
- Team enthusiasm for Vue 3 adoption
- Need for better documentation

## Follow-up Required

- Confirm security audit scope with CTO
- Get client approval for 2-week delay
- Check team training capacity

选项 2：JSON 结构

{
  "meeting": {
    "title": "Q4 Planning",
    "date": "2024-11-08",
    "participants": ["Alice", "Bob", "Carol"]
  },
  "decisions": [
    {
      "id": "D1",
      "description": "Adopt Vue 3",
      "rationale": "Better TS support",
      "decider": "Consensus",
      "impact": "Requires team training"
    }
  ],
  "actionItems": [
    {
      "id": "A1",
      "task": "Complete security audit",
      "owner": "Bob",
      "dueDate": "2024-11-10",
      "priority": "HIGH",
      "context": "Required before launch"
    }
  ],
  "followUp": ["Confirm security audit scope", "Get client approval"]
}

示例

示例 1：产品规划会议

会议记录输入：

Meeting: Product Planning - Q1 2025
Attendees: Sarah (PM), Mike (Lead Dev), Lisa (Designer)

Topics:
1. User feedback analysis - lots of requests for dark mode
2. Performance issues reported in production
3. Q1 roadmap planning

Decisions:
- Will implement dark mode as primary feature
- Will address performance issues first (performance is blocking)
- Delaying mobile app until Q2

Action items:
Sarah will brief the team on user feedback by tomorrow
Mike will create performance improvement plan by Friday
Lisa will start dark mode design exploration next week
Need to schedule meeting with exec team for roadmap approval

Issues:
- Performance work might delay features
- Team capacity might be tight with both performance + dark mode
- Mobile app delay will disappoint some users

输出：

# Q1 2025 Product Planning Synthesis

## Decisions

1. **Implement dark mode as primary Q1 feature**
   - Why: High user demand from feedback analysis
   - Impact: Becomes focus of design/feature work

2. **Prioritize performance issues before new features**
   - Why: Blocking production users
   - Impact: Requires dedicated engineering time first

3. **Delay mobile app to Q2**
   - Why: Capacity and roadmap constraints
   - Impact: Will disappoint some users, needs communication

## Action Items

### Critical Path

- [ ] Performance improvement plan (Mike, Due: Friday)
  - Context: Blocking roadmap
  - Unblocks: Dark mode feature work

### High Priority

- [ ] Team briefing on user feedback (Sarah, Due: Tomorrow)
- [ ] Dark mode design exploration (Lisa, Due: Next week)

### Follow-up Required

- [ ] Executive team meeting on Q1 roadmap
- [ ] Communication plan for mobile app delay
- [ ] Capacity planning for parallel work streams

## Key Concerns

- Tight team capacity with performance + dark mode
- Mobile app delay needs stakeholder management
- Performance work timeline might slip

示例 2：工程每日站会

转录内容输入：

Sarah: OK team, quick standup. Mike, how's the API work?

Mike: Good progress. Got the authentication endpoints done.
Got the rate limiting working. Should be done by EOW.

Sarah: Great. Any blockers?

Mike: Need DB schema review from Carol. That's blocking
the user service implementation.

Carol: Oh, I can look at that this afternoon. Will send feedback.

Sarah: Perfect. Lisa, how's the frontend?

Lisa: Integrated the new modal component. Ran into a
responsive design issue on mobile that I'm debugging.
Should have fixed by tomorrow.

Sarah: OK, don't spend too much time on that if it's complex.
We can handle edge cases later.

Mike: Also, we should probably do a load test before shipping.

Sarah: Agreed. Let's add that to the list. Carol, can you
help set that up?

Carol: Sure, I can coordinate with DevOps.

Sarah: Good. Let's reconvene Thursday to check in.

输出：

# Engineering Standup - 2024-11-08

## Current Status

- **Mike**: API auth endpoints complete, rate limiting working
  - On track: EOW completion
  - Blocker: Waiting on DB schema review

- **Lisa**: Modal component integrated, debugging responsive issue
  - On track: Mobile fix by tomorrow
  - Note: Don't over-engineer edge cases

- **Carol**: Available for schema review, coordinating load testing

## Action Items

### High Priority

- [ ] DB schema review (Carol, Due: Today afternoon)
  - Unblocks: Mike's user service implementation

- [ ] Mobile responsive debugging (Lisa, Due: Tomorrow)
  - Context: Modal component issue

### Medium Priority

- [ ] Coordinate load testing setup (Carol + DevOps, Due: This week)
  - Context: Required before shipping

## Decisions

- Load testing is required before deployment
- Don't over-engineer mobile edge cases yet

## Next Check-in

- Thursday team standup for progress review

处理技巧

处理歧义

• 如果负责人不明确：注明“TBD”，并标记以待澄清
• 如果时间安排不明确：使用“尽快”“本周”或“时间安排不明确”等表述
• 如果决策不明确：将其列为“讨论事项”，而非“决策”

识别隐含事项

• “我们应该……”通常意味着有人需要采取行动
• “需要有人……”表示存在隐含的待办事项
• “我们需要验证……”表示有一项后续任务
• “你能不能……”表示被询问的人有一项待办事项

有效确定优先级

• 关键：会阻碍其他工作
• 高：有时效性或很重要
• 中：应尽快完成
• 低：有了更好

风险信号

• 负责人含糊不清（“我们会想办法”）
• 未提及时间安排
• 决策相互冲突
• 问题尚未解决
• 后续步骤不明确

最佳实践

输入质量

• 细节越多越好（完整转录稿优于含糊的摘要）
• 如果有发言人姓名，请一并提供
• 保留不同意见和顾虑
• 标注有时效性的事项

输出质量

• 明确具体：“审查代码”不够清楚，“审查 API 端点身份验证代码”则清楚明确
• 补充背景：说明为何重要，而不仅是要做什么
• 标记依赖项：说明必须先完成什么
• 突出紧迫性：标出关键路径事项

跟进执行

• 将结果分享给分配了任务的团队成员
• 为待办事项创建工单或日历事项
• 为未解决事项安排后续跟进
• 向利益相关者同步决策

常见模式

模式 1：决策及其引发的一系列待办事项

Decision: Use PostgreSQL instead of MongoDB
  ↓
Action Items:
- Migrate existing data (Owner: DB team)
- Update ORM code (Owner: Backend team)
- Update schema documentation (Owner: Docs)
- Train team on SQL (Owner: Tech lead)

模式 2：阻塞性依赖项

Task A: Complete security audit (BLOCKING)
  ↓
Task B: Deploy to production (BLOCKED)
  ↓
Task C: Start Q2 roadmap planning (BLOCKED)

模式 3：决策撤回或需要澄清

Stated: "We'll use Vue"
But earlier: "React is better"
Follow-up: Clarify decision rationale and communicate to team

质量检查清单

整理会议内容后，请确认：

• 所有待办事项都有明确的负责人
• 所有决策都记录了依据
• 已标记关键事项并确定优先级
• 已识别阻塞性依赖项
• 后续任务明确
• 已记录任何顾虑或异议
• 已标记含糊事项以待澄清
• 结果已准备好与团队分享

集成点

与任务管理集成

• 将待办事项导出到 Jira、GitHub Issues、Asana
• 为截止日期创建日历事项
• 为负责人设置提醒

与沟通集成

• 与团队分享整理结果
• 发送给无法参会的利益相关者
• 创建会议摘要邮件

与路线图规划集成

• 决策会影响路线图和时间安排
• 待办事项会影响产能规划
• 后续任务可能成为下次会议的议程

局限与注意事项

• 无法识别非语言交流（语气、肢体语言）
• 可能遗漏只有参会者才了解的隐含背景
• 需要清晰且可解读的笔记或转录稿
• 含糊的会议笔记会导致输出含糊
• 无法跟进未明确提出的决策

另请参阅

• 待办事项跟踪与管理
• 决策日志与决策历史
• 会议议程模板
• 会后沟通模板