Back to Details

meetings

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Meetings

会议管理

Before Starting

准备阶段

Check for EM context first. If 
.agents/em-context.md
exists, read it.
If 
.agents/em-context.md
does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and 
.agents/reports/[name].md
does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update 
.agents/em-context.md
or 
.agents/reports/[name].md
automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先检查是否有工程经理（EM）相关背景信息。如果存在
.agents/em-context.md
文件，请读取该文件。
如果
.agents/em-context.md
文件不存在，请先询问并保存一份最简经理档案，之后再给出详细建议：职位/头衔、团队规模、团队使命或负责领域，以及当前面临的挑战或优先事项。
如果对话核心涉及特定人员，且
.agents/reports/[name].md
文件不存在，请先询问并保存该人员的最简档案，之后再给出详细建议：职位/级别、任职时长、优势，以及当前面临的挑战或成长方向。

若后续对话中出现可长期留存的新信息，请自动更新
.agents/em-context.md
或
.agents/reports/[name].md
文件。仅保存稳定的事实和模式，不保存猜测内容、暂时的情绪或未明确的解读。

Response Style

回复风格

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
  • State the likely diagnosis or recommendation first
  • Ask at most 2-3 targeted questions only if the missing context changes the advice
  • Give the next concrete action and, when useful, exact wording the manager can use
  • Mention the relevant framework briefly, but do not explain every part of it
  • Offer a deeper version only after the direct answer
首次回答需简洁实用。除非用户要求深入讲解，否则不要全盘输出整个框架。
默认遵循以下原则：
  • 首先说明可能的诊断结果或建议
  • 仅在缺失信息会影响建议时，提出最多2-3个针对性问题
  • 给出具体的下一步行动，必要时提供经理可直接使用的精准措辞
  • 简要提及相关框架，但无需解释框架的每个部分
  • 仅在直接回答后，再提供深入版本的内容

How to Use This Skill

本技能使用场景

  • Wondering if something should be a meeting → Is This a Meeting?
  • Running a specific meeting: who to invite, how to prep, how to facilitate → Running a Good Meeting
  • Too many meetings, team can't focus, calendar fragmented → Reducing Meetings
  • A recurring meeting nobody can explain → Killing Meetings That Have Outlived Their Purpose
  • User shares a transcript or describes how a meeting went → Reviewing a Meeting
  • Engineers always distracted, can never get into flow → Why Meetings Are Expensive (then Reducing Meetings)
  • 不确定是否需要安排会议 → 判断是否需要会议
  • 主持特定会议：确定参会人员、准备工作、主持方式 → 高效开展会议
  • 会议过多，团队无法专注，日程碎片化 → 减少会议数量
  • 存在无人能说明意义的重复会议 → 取消失去存在意义的会议
  • 用户分享会议记录或描述会议过程 → 评估会议效果
  • 工程师总是分心，无法进入深度工作状态 → 会议的隐性成本（之后参考减少会议数量部分）

Default Response Shape

默认回复结构

When helping with meetings, produce a decision and operating plan:
  1. Meeting decision: keep, kill, shorten, async, split, or redesign.
  2. Purpose: decision, problem-solving, alignment, relationship, or information sharing.
  3. Agenda / async alternative: concrete structure or written replacement.
  4. Participants: who must attend and who can be informed afterward.
  5. Follow-up mechanism: owner, decisions, notes, and review date.
For transcripts or past meetings, diagnose what failed and give a revised version.
在提供会议相关帮助时，需给出决策和执行方案：
  1. 会议决策：保留、取消、缩短时长、转为异步、拆分或重新设计。
  2. 会议目的：决策制定、问题解决、对齐共识、关系维护或信息传递。
  3. 议程/异步替代方案：具体结构或书面替代方式。
  4. 参会人员：必须出席的人员以及可事后告知的人员。
  5. 跟进机制：负责人、决策内容、会议记录以及复盘日期。
针对会议记录或已结束的会议，需诊断问题所在并给出改进版本。

Why Meetings Are Expensive

会议的隐性成本

Your engineers are on a maker's schedule — meaningful work needs half-day blocks, not one-hour slots. A meeting at 11am doesn't cost an hour; it costs the morning, because the block before it is too short to get deep work done. When you schedule a meeting, it's routine for you and expensive for them.
Research on 600K+ pull requests shows engineers are truly productive during two windows: 9–11am and 2–4pm. Scheduling a meeting inside those windows — even a short one — kills the productive block. Put meetings at 8:30, 11:30, 1:00, or 4:00+. The difference is not marginal.
你的工程师采用的是“创造者日程”——有意义的工作需要半天的整块时间，而非一小时的碎片化时段。上午11点的一场会议并非只花费一小时，而是浪费了整个上午，因为会议前的时段太短，无法开展深度工作。对你而言，安排会议是常规操作，但对工程师来说，这代价高昂。
针对60万+ pull requests的研究表明，工程师真正高效的时段是9–11点和2–4点。在这些时段内安排会议——即使是短会——也会毁掉整个高效时段。应将会议安排在8:30、11:30、1:00或4:00之后。这种差异并非微不足道。

Is This a Meeting?

判断是否需要会议

Before scheduling, identify what type of meeting this is:
  • Problem-solving — the group needs to work through a problem together
  • Decision-making — a decision needs to be made and requires the right people present
  • Getting buy-in — you've already decided; you need alignment and commitment
  • Information sharing — you're communicating something
Information sharing almost never needs a meeting. Record a Loom, send a doc, post in Slack. Reserve synchronous time for things that require real back-and-forth.
Does the decision-maker need to be there? If they can't attend, reschedule. A meeting without the decision-maker that was supposed to produce a decision produces nothing.
More than 7 people in a decision meeting is almost always too many. Every extra person adds social complexity, slows discussion, and often derails focus. People who need to be "in the loop" can get a summary.
安排会议前，先明确会议类型：
  • 问题解决型 —— 需要团队协作解决问题
  • 决策制定型 —— 需要做出决策，且相关决策者必须到场
  • 争取共识型 —— 你已做出决策，需要获得团队的对齐与承诺
  • 信息传递型 —— 你需要向团队传达信息
信息传递几乎不需要会议。录制Loom视频、发送文档或在Slack中发布即可。同步会议应仅用于需要实时互动的场景。
决策者是否需要到场？ 如果无法参会，应重新安排时间。本应做出决策但决策者缺席的会议毫无成果。
决策会议的参会人数超过7人几乎总是过多。 每增加一人都会增加社交复杂度、拖慢讨论节奏，且往往会偏离主题。只需了解情况的人员可事后获取会议摘要。

Running a Good Meeting

高效开展会议

Prepare. Every meeting needs a written agenda sent in advance — not "catch up," but a specific list of what will be covered and what outcome is expected. For complex topics, send reading material 24–48 hours ahead and ask people to arrive with a position. Meetings where everyone reads the material in the room are preparation failures.
Run it. Start on time — always. Assign a facilitator and a note-taker. When the conversation drifts, name it: "That's important — let's park it and come back." A parking lot keeps the meeting on track without dismissing valid concerns.
Drive to decisions, not discussions. A meeting that ends with "we should think more about this" has failed. End with: a decision made, a next step assigned, or an explicit statement of what information is needed and who will get it.
If you reach the goal in 20 of 60 minutes, end it.
Follow through. Send a written summary within 24 hours: decisions made, action items with owners and deadlines, open questions. Even if the meeting felt obvious, people remember it differently. The written record is the truth.
做好准备 每场会议都需要提前发送书面议程——不能是“闲聊”，而应是具体的讨论内容列表及预期成果。对于复杂议题，需提前24–48小时发送阅读材料，并要求参会人员提前准备立场。参会人员在会议现场才阅读材料的情况属于准备失误。
主持会议 务必准时开始。指定一名主持人和一名记录员。当讨论偏离主题时，明确指出：“这很重要——我们先搁置，之后再讨论。”“待办事项清单”既能保证会议按计划进行，又不会忽视合理的关注点。
推动决策而非仅进行讨论。以“我们应该再考虑一下”结束的会议是失败的。会议结束时应达成：做出决策、分配下一步行动，或明确说明所需信息及负责获取信息的人员。
如果在60分钟的会议中，20分钟就达成了目标，可提前结束会议。
跟进落实 24小时内发送书面摘要：已做出的决策、明确负责人和截止日期的行动项、未解决的问题。即使会议内容看似明确，不同人的记忆也会存在差异。书面记录才是事实依据。

Reducing Meetings

减少会议数量

Your calendar is the model for your team's calendar. If you're in back-to-back meetings all day, you're signaling that's normal.
  • Protect proactive time. Aim for at least 30% of your work week in uninterrupted blocks. When it drops below 20%, you're in reactive mode.
  • Batch meetings. Cluster them into fixed windows — mornings, or specific days — to preserve deep work blocks.
  • Shorten by default. Use 25 and 50 minutes instead of 30 and 60. The shorter slot forces efficiency; meetings expand to fill their scheduled time.
  • Delegate attendance. Some meetings don't need you personally — a report can go and brief you afterward.
  • You're allowed to decline. If you're not a decision-maker and not a required input-provider, decline and ask to be looped in via summary.
你的日程是团队日程的标杆。 如果你全天都在参加背靠背的会议，就是在向团队传递“这种状态是正常的”信号。
  • 保护主动工作时间。 每周至少保留30%的不间断工作时段。当该比例低于20%时，你就处于被动应对状态。
  • 批量安排会议。 将会议集中安排在固定时段——比如上午或特定几天——以保留深度工作时段。
  • 默认缩短会议时长。 使用25分钟和50分钟的时段，而非30分钟和60分钟。更短的时段会倒逼效率；会议往往会填满预定的时长。
  • 委派参会人员。 有些会议不需要你亲自参加——可安排下属参会，之后向你汇报。
  • 你有权拒绝会议。 如果你既不是决策者，也不是必要的信息提供者，可拒绝参会并要求事后获取会议摘要。

Killing Meetings That Have Outlived Their Purpose

取消失去存在意义的会议

Every team has recurring meetings nobody can explain. A standup that adds no value. A sync that's been on the calendar for two years.
Ask regularly: "Why are we still doing this?" If the answer is "because we always have" — that's inertia, not a reason. Processes inherited from a previous manager, a different team size, or a different stage often outlive their usefulness.
A simple habit: once a quarter, list your team's regular rituals and ask for each: what problem does this solve? If nobody can answer, try removing it for one month. Most people will feel relieved.
每个团队都存在无人能说明意义的重复会议。比如毫无价值的站会，或者已经在日程上存在两年的同步会议。
定期询问：“我们为什么还要开这个会？” 如果答案是“因为我们一直都开”——这只是惯性，而非合理理由。从前任经理、不同团队规模或不同阶段继承的流程往往会失去其存在的价值。
一个简单的习惯：每季度列出团队的常规会议，针对每个会议询问：它解决了什么问题？如果没人能回答，尝试取消该会议一个月。大多数人会感到如释重负。

Reviewing a Meeting

评估会议效果

When the user shares a transcript or describes how a meeting went, evaluate it across five dimensions:
1. Purpose — Was the goal clear before the meeting started? Was it achieved? If the meeting ended without a decision, a commitment, or a clear next step — it failed.
2. Attendance — Were the right people there? Was the decision-maker present? Were there people in the room who only needed a summary?
3. Preparation — Was there an agenda? Did people arrive having read relevant material, or were they reading it in the meeting?
4. Facilitation — Did the conversation stay on track? Were tangents named and parked? Did one person dominate? Did quieter people get airtime?
5. Follow-through — Were decisions recorded? Were action items captured with owners and deadlines — or did the meeting end with vague commitments?
For each dimension, note what happened and one concrete thing to do differently next time. The goal isn't a perfect score — it's identifying the one or two changes that would make the next meeting meaningfully better.
当用户分享会议记录或描述会议过程时，从五个维度进行评估：
1. 目的 —— 会议开始前目标是否明确？是否达成了目标？如果会议结束时未做出决策、未达成承诺或未明确下一步行动——则会议失败。
2. 参会人员 —— 参会人员是否合适？决策者是否到场？是否存在只需了解情况的人员？
3. 准备工作 —— 是否有议程？参会人员是否提前阅读了相关材料，还是在会议现场才阅读？
4. 主持情况 —— 讨论是否紧扣主题？是否明确指出并搁置了偏离主题的内容？是否有一人主导讨论？是否给沉默的人员发言机会？
5. 跟进落实 —— 是否记录了决策内容？是否明确了行动项的负责人和截止日期——还是会议结束时只有模糊的承诺？
针对每个维度，记录实际情况以及下次会议可做出的一项具体改进。目标并非追求完美得分——而是找出一两项能让下次会议显著改善的改变。

Dive Deeper

深入了解

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read 
references/sources.md
 for the full list of source articles (with links) and books.
如果用户询问框架的来源、想要阅读原文或了解本技能中任何主题的更多背景信息——请查看
references/sources.md
获取完整的来源文章（含链接）和书籍列表。

Related Skills

相关技能

  • managing-urgency
    — Urgency culture is a common driver of unnecessary meetings and chronic interruptions
  • delegation
    — EMs who don't delegate become a common source of interruptions themselves
  • team-health
    — Meeting cadence and quality show up in team health and engagement
  • 1on1s
    — 1:1s are a specific meeting type with their own format
  • managing-urgency
    —— 紧迫感文化是不必要会议和频繁干扰的常见诱因
  • delegation
    —— 不善于委派任务的工程经理本身就是干扰的常见来源
  • team-health
    —— 会议频率和质量会影响团队健康度和参与度
  • 1on1s
    —— 一对一会议是一种特殊的会议类型，有其专属格式