当时我在公司内部做了一个决定：我不再开会了，所有的时间都在跟我的 Agent 开会
我越来越相信一件事。
很多公司不是被竞争对手打败的。
是被自己每天的会议打败的。
不是因为会议“浪费时间”。
而是因为会议的产出形态，跟 Agent 时代的软件生产形态不匹配。
“不再开会”不是情绪，是组织结构的切换
人类开会，本质上是在做两件事：
同步上下文。
制造约束。
你把人凑到一间屋子里，让大家听同一段话、对同一件事表态，然后把承诺写进纪要。
这是一台很昂贵的机器。
昂贵的不是会议室。
是你把一群高带宽的人，降维成了同一个音频通道。
而 Agent 不在乎这个。
Agent 只在乎输入是不是“可用的上下文”。
你以为你在开会，其实你在给系统喂 Context
会议里最常见的句子是：
“我补充一下背景。”
“我们先对齐一下。”
“这个事情先这样，后面再说。”
这些话对人有用。
对 Agent 基本没用。
因为它们不形成可复用的结构。
它们只存在于那 30 分钟的声波里。
你一关掉会议，Context 就蒸发了。
于是下一次又要“补充背景”。
然后公司就进入了一种很怪的循环：
人类不断重复讲背景。
系统不断从零开始。
Agent 会议的形态：SPEC 取代讨论
我见过一种工作方式很有效。
不是“让 Agent 进会议”。
而是把会议拆掉，把它的功能迁移到三样东西上：
- Goal：我们到底要交付什么结果
- Context：系统需要哪些事实、代码、约束条件
- Constraints：哪些边界不能碰，如何验收
你会发现，这三样东西凑齐后，所谓“会议纪要”就变成了 SPEC。
而 SPEC 是可以复用、可以版本化、可以 Debug 的。
这件事非常关键。
会议不可 Debug。
SPEC 可以。
黑盒跑不起来，人必须“点拨”
很多人对 Agent 的幻想是：
“我把任务丢给它，它自己讨论、自己拆分、自己交付。”
这个幻想早晚会被现实教育。
不是因为模型不够聪明。
而是因为工程是长程任务。
长程任务里最怕的不是错误。
是方向漂移。
人类最应该做的工作，反而不是写代码。
是写得足够好的 SPEC。
写到什么程度？
写到你可以把它交给十个不同的 Agent，它们能给出彼此可对照的实现。
真正的瓶颈不是 Agent，是你自己
很多人用 Agent 的方式是：
开一个窗口。
丢一个需求。
等它干完。
然后验收。
这看起来很舒服。
但它把你变成了最大的瓶颈。
你的产出速度，等于你睡醒的速度。
更糟的是，你很难知道它给的方案是不是最优。
更像是在“收快递”。
一种更激进但更有效的方式是：
同一个需求，让很多个 Agent 反复重写、互相挑错、互相辩论。
大部分输出都没用。
但只要出现那 1% 的“灵光一闪”，整体质量会跃迁。
这时候你会重新理解一句话：
省 Token 不是美德。
省会议才是。
结尾：把会议当作技术债清理
如果你仍然每天被会议撕碎。
你可以从一个小动作开始：
把每次会议要解决的问题，改写成一段 SPEC。
写清楚 Goal。
贴出 Context。
列出 Constraints。
然后把它交给 Agent 跑一遍。
你会发现很多会议，其实不需要开。
你需要的不是“更多讨论”。
是更可执行的上下文。
参考
- 参考演讲实录（微信公号）：https://mp.weixin.qq.com/s/soCPGe-eZeMd3YS4wTJHIg