meetings

会议

开始之前

先检查是否有 EM 背景信息。如果 .agents/em-context.md 存在，请先阅读。

如果 .agents/em-context.md 不存在，请先询问并保存一份精简的经理人档案，再给出详细建议：职位／头衔、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果某位特定人员是对话的核心对象，且 .agents/reports/[name].md 不存在，请先询问并保存该人员的精简档案，再给出详细建议：职位／级别、任职时间、优势，以及当前挑战或成长方向。

如果之后的对话中出现了可长期参考的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、短暂的挫败情绪或尚未解决的解读。

回复风格

第一条回复应简洁实用。除非用户要求深入讨论，否则不要一次性倾倒整套框架。

默认做法：

• 先说明可能的诊断或建议
• 只有当缺失的背景信息会影响建议时，才提出最多 2～3 个有针对性的问题
• 给出下一步的具体行动，并在有帮助时提供经理人可以直接使用的准确措辞
• 简要提及相关框架，但不要解释每个部分
• 先直接回答，再提供深入版本

---

如何使用此技能

• 想知道某件事是否应该开会讨论 → 这算是一次会议吗？
• 要主持一场特定会议：邀请谁、如何准备、如何引导 → 如何开好一场会议
• 会议太多，团队无法专注，日历支离破碎 → 减少会议
• 没人能说清某个定期会议的意义 → 结束已失去意义的会议
• 用户分享会议记录或描述会议经过 → 复盘会议
• 工程师总是被打断，无法进入心流状态 → 为什么会议代价高昂（然后阅读减少会议）

---

默认回复结构

协助处理会议问题时，给出决策和执行计划：

1. 会议决策： 保留、取消、缩短、改为异步、拆分或重新设计。
2. 目的： 决策、解决问题、达成共识、建立关系或共享信息。
3. 议程／异步替代方案： 提供具体的结构或书面替代方案。
4. 参与者： 谁必须参加，谁可以在会后获知信息。
5. 后续机制： 负责人、决策、记录和复查日期。

对于会议记录或已结束的会议，诊断问题所在并给出修订方案。

---

为什么会议代价高昂

工程师遵循的是创作者日程——有意义的工作需要半天时间的连续时段，而不是一小时的空档。上午 11 点开会，代价不只是一小时；它会占掉整个上午，因为会议前的时间太短，无法投入深度工作。对你来说，安排会议是日常事务；对他们来说，代价却很高。

对 60 万多条拉取请求的研究表明，工程师真正高效的时段有两个：上午 9～11 点和下午 2～4 点。在这些时段内安排会议——哪怕很短——都会毁掉高效工作时段。把会议安排在上午 8:30、11:30、下午 1:00 或 4:00 之后。两者的差异不容小觑。

---

这是一次会议吗？

安排会议之前，先确定这是什么类型的会议：

• 解决问题 — 团队需要共同解决一个问题
• 做出决策 — 需要做出决策，并且相关人员必须到场
• 争取认同 — 你已经做出了决定，需要达成共识并获得承诺
• 分享信息 — 你需要传达一些内容

分享信息几乎从来不需要开会。录制一段 Loom，发送文档，或在 Slack 上发布。把同步沟通时间留给真正需要来回讨论的事情。

决策者需要到场吗？ 如果他们无法参加，就改期。原本应当做出决策、却没有决策者参加的会议，什么也不会产出。

决策会议超过 7 人，几乎总是太多了。 每增加一个人，社交互动就会更复杂，讨论速度会变慢，注意力也常常会被带偏。只需要了解情况的人，可以看会议摘要。

---

如何开好会议

做好准备。 每次会议都需要提前发送书面议程——不能只是“叙叙旧”，而应列出具体要讨论的事项和预期结果。对于复杂议题，提前 24–48 小时发送阅读材料，并请大家带着自己的立场参会。让所有人到了会议室才读材料，说明准备工作没有做好。

主持会议。 始终准时开始。指定一位主持人和一位记录员。讨论偏离主题时，明确指出：“这件事很重要——我们先记下来，之后再讨论。”待议事项清单能让会议保持正轨，也不会忽视合理的关切。

推动会议做出决策，而不是止于讨论。以“我们应该再多想想”收尾的会议，就是失败的。结束时应当有：已做出的决策、已分配的下一步行动，或对所需信息及负责获取这些信息的人作出明确说明。

如果你在 60 分钟的会议中 20 分钟就达成了目标，那就结束会议。

做好后续跟进。 在 24 小时内发送书面摘要：已做出的决策、注明负责人和截止日期的行动事项，以及待解决的问题。即使会议内容看起来显而易见，大家的记忆也会有所不同。书面记录才是准绳。

---

减少会议

你的日历就是团队日历的榜样。 如果你整天都在参加一个接一个的会议，你传递的信息就是这很正常。

• 保护主动工作时间。 尽量保证至少 30% 的工作周时间安排为不受打扰的时段。如果降到 20% 以下，你就进入了被动应对模式。
• 集中安排会议。 将会议集中安排在固定时段——比如上午或特定日期——以保留深度工作时段。
• 默认缩短会议时长。 用 25 分钟和 50 分钟代替 30 分钟和 60 分钟。较短的时段能促使大家提高效率；会议总会占满预留的时间。
• 委派参会。 有些会议不需要你亲自参加——可以让同事代为出席，之后向你汇报。
• 你可以拒绝参会。 如果你不是决策者，也不需要提供必要意见，就拒绝参加，并要求通过摘要了解情况。

---

取消已失去意义的会议

每个团队都有一些没人说得清为何还要开的定期会议。毫无价值的每日站会。已经在日历上存在两年的同步会。

定期问问：“我们为什么还要开这个会？”如果答案是“因为我们一直都这么做”——这只是惯性，不是理由。从前任经理、不同规模的团队或不同发展阶段沿袭下来的流程，往往会在失去作用后继续存在。

一个简单的习惯：每季度列出团队的定期活动，并逐一询问：它解决了什么问题？如果没人答得上来，就试着停办一个月。大多数人都会如释重负。

---

复盘会议

当用户分享会议记录或描述会议情况时，请从以下五个维度进行评估：

1. 目的 — 会议开始前，目标是否明确？目标是否达成？如果会议结束时没有作出决定、达成承诺或明确下一步行动，那么这场会议就失败了。

2. 参会人员 — 相关人员是否都到场了？决策者是否在场？是否有人只需要一份会议摘要，却也参加了会议？

3. 准备情况 — 是否有议程？参会人员是否提前阅读了相关材料，还是在会议期间才阅读？

4. 引导情况 — 讨论是否紧扣主题？是否指出并暂缓了离题内容？是否有人占据了主导？较为安静的参会人员是否也有发言机会？

5. 后续跟进 — 是否记录了决定？是否记录了行动事项及负责人和截止日期，还是会议以含糊的承诺收尾？

针对每个维度，说明具体情况，并指出下次可以改进的一件具体事项。目标不是拿到完美评分，而是找出一到两项能让下一次会议有明显改善的改变。

---

深入了解

如果用户询问某个框架的出处、想阅读原文，或想了解此技能中任一主题的更多背景，请阅读 references/sources.md，查看完整的来源文章（含链接）和书籍列表。

---

相关技能

• managing-urgency — 紧急文化是导致不必要会议和频繁打断的常见原因
• delegation — 不懂得授权的 EM 往往也会成为频繁打断他人的源头
• team-health — 会议频率和质量会影响团队健康状况和参与度
• 1on1s — 1:1 是一种有专属形式的特定会议类型