读：把会议当系统来设计

会议有多贵

几组数据：

工程师看到这些数字会怎么想？如果系统存在 70% 不必要的调用，你会重新设计架构；如果一半的 CPU 在空跑，你会立即着手优化。但在组织里，这种程度的低效却被当成理所应当的。

但会议本身是必要的。任何非平凡的系统都需要机制来共享上下文、对齐决策、消除歧义、协调执行。分布式系统用协议和共识机制，组织用会议。什么时候会议不可或缺：决策需要多方视角、异步沟通消除不了的不确定性、团队需要共同承诺一个方向。

会议是一个协调原语（coordination primitive），没法绕开。真正的问题在于，大多数人根本没想过要"设计"一场会议。

Santana 的做法是把会议拆成三个阶段：输入设计（会前）、执行控制（会中）、输出持久化（会后）。

会前就像给 API 签契约：输入不对，后面全白搭。

没有目标的会议等同于没有契约的 API。开会之前先回答三个问题：这次会议的目的是什么？期望什么决策或产出？成功长什么样？答不上来就别开，开了也是制造噪音。

明确的目标本身就能解决一半的问题。比如"架构讨论"就让人不明所以，"决定支付模块用事件驱动还是同步调用"就很好。

讨论应该在开会之前就已经开始了。先分享文档、PR 或架构决策记录，鼓励评论和讨论，让大家提前提出想法。等到真正开会时，各方已经了解背景、形成初步观点，这样在会上对话质量自然更高。

常见的反模式是"我们在会上一起看这份文档"。这不是会议，是同步阅读，完全是浪费时间。如果会议依赖先前知识（架构决策记录、PR、设计提案），至少提前 24 小时分享，会议描述里链接文档、标出关键问题。开会就是为了做决策，不是现场读材料。

上述做法背后的原则是：会议应该是讨论的收敛点，不是起点。观点和论据先在异步渠道里铺开，真正需要同步的对齐和决策才放到会上。把会议当作"从零开始讨论"的场合，是巨大的时间浪费。

材料到位了，会议开始。这个阶段的核心是控制资源消耗。

Parkinson 定律说工作会膨胀到填满所有可用时间，会议完全遵循这个定律。安排一小时，人们就会不自觉地撑满一小时，即使 20 分钟就已经产生了实际价值。

做法：默认安排 15-25 分钟的短会，只在确实必要时才用更长的时间。时间盒会逼迫你聚焦重点。

Triviality 定律（也叫 bikeshedding）说，团队花在琐碎问题上的时间比复杂问题多。你可能见过这种情况：架构问题讨论 2 分钟，命名问题讨论 20 分钟。这不是偶然，是人的天性。

作为会议主持，你除了提供技术输入，还得维持讨论焦点：偏了就拉回来，无关话题先搁置。Santana 的类比是，这就像防止线程饥饿，别让核心议题拿不到执行时间。

会议结束不是终点。没有产出的会议只是一次昂贵的聊天。会后要做两件事：写下来，分出去。

写下来：每次会议结束时明确决定了什么、需要什么行动、谁负责、下一步是什么。否则同一个话题来来回回，催生一次又一次会议。Santana 把这叫做"会议债"（meeting debt）的累积。

分出去：写一份文档，异步分享，让每个人按自己的节奏消化。从系统视角看，会议是运行时依赖（runtime dependency），文档是可复用的缓存产物（cached artifact）。有了好文档，下次开会时人们已经了解背景，讨论更深入。没有文档，每次开会都在重复给新人补课，同一场对话反复发生。

如果目的只是传达信息，发个邮件就行了，不是所有事情都需要实时同步。

文章最后提到，AI 工具（自动转录、总结决策、提取行动项）可以放大好的会议实践，但工具不能修复烂会议。先把会议设计对了，工具才有用武之地。