自 COVID-19 疫情以来，工作文化发生了许多积极变化，但也出现了一些负面趋势——其中最突出的，是每位员工的会议数量平均增加了 13.5%。
问题在于：管理者与工程师对“会议”的理解存在巨大差异。
Paul Graham 曾在著名的《创作者时间表与管理者时间表》中写道：
“当你按创作者的时间表工作时，会议就是灾难。一场会议就能毁掉整个下午，把它分成两个过小的时间段，让你难以完成任何需要深度思考的任务。”
如今，即使 AI 编码工具广泛应用，这一问题依然存在，甚至愈发严重。许多管理者以为工程师现在可以利用更碎片化的时间进行产出。
过去两年间，有研究对数百个工程团队进行了观察，试图找出表现最出色的团队所采取的不同策略。本文将分享他们的经验和可立即实施的做法。
什么是“深度工作”？
“深度工作（Deep Work）”这一术语由 Cal Newport 在其著作《深度工作：如何在分心的世界中取得成功》中提出。
深度工作，指的是需要大量脑力、能创造独特价值的工作。它无法在分心状态下完成。一个简单的测试是：如果某项任务可以在 Zoom 会议中完成，那它就不是深度工作。
与之相对的是“浅层工作（Shallow Work）”——例如回复 Slack 消息、查看邮件、审阅文档等，不需要动用全部注意力的任务。
软件工程曾被视为热爱深度工作的人的理想职业。至今仍有人认为工程师戴着耳机，独自在地下室敲代码。
但如今，要找到真正的“深度工作”时间变得越来越困难。而这种时间，在与 AI 协作的时代，变得更为重要。
深度工作为何如此关键？
唯有进入“深度工作”状态，工程师才能真正进入所谓的“心流（Flow）”状态，也就是大家常说的“进入状态”。
深度工作能带来以下好处：
- 减少错误：保持集中能更少犯错。
- 提升效率：工作完成得更快，从而获得更多休息时间，支持更好的工作与生活平衡。
- 技能成长：在深度思考的时刻，工程师能够解决最难的问题，也往往是提升技能最快的时候。
许多管理者犯的最大错误是认为：既然有了 AI 编码工具，深度工作就不再必要了。工程师应当习惯于频繁切换任务，反正每次生成代码都要等待几分钟，“那多做点别的也无妨”。
但现实情况是：这种频繁切换导致思维质量下降、提示词粗糙、AI 反馈变差，反而陷入不断求助 AI 修复问题的恶性循环。
如果能维持专注、沉浸于问题之中，所需的迭代次数将大幅减少——虽然没有具体数据支持，但长期的经验表明确实如此。
深度工作的障碍
远程办公本该是解药，但现实并非如此。
虽然通勤时间没了，但打扰却更多。自2020年以来，除了总会议量增长13.5%，远程会议的数量也激增了60%。更糟糕的是，92% 的人承认自己在远程会议中会“多任务处理”——而对于软件工程师来说，这个比例几乎可以说是 100%。
这种现象带来两大严重后果：
1. 原本需要“深度”的工作，变成了“浅层”
还记得前文提到的测试方法吗？能在 Zoom 会议中完成的任务，就不是深度工作。
代码审查（PR Review）是一个典型例子。
日程排满会议时，工程师会选择在会议中“顺手”看 PR。但代码审查应是深度任务。同样的还有 bug 修复、技术设计文档撰写等工作。
当这些任务在会议中完成时，会产生一个恶性循环：
- 工作质量变差 → 更多问题出现 → 安排更多会议来解决
- 会议期间注意力不集中 → 决策质量低下 → 再安排更多会议……
最终，这不是工程师的错，而是公司会议文化的问题。
2. 工程师难以进入“心流”状态
研究显示，从开始进入工作状态需要 15 分钟，而只有到 第45分钟左右，人才能真正进入高效的心流状态。
每一次干扰，都会让这段“倒计时”重新开始。Meta 的一项研究显示，工程师每周只能获得 两个小时长的专注时段。而讽刺的是，在统计中连三分钟都被视作“专注时间”。
不仅仅是会议占据了时间，更大的损耗在于每次干扰后的重启成本。一个普通的工作日中，即便没有会议，真正的“有效时间”也只有 1~2 小时。
有人在 Reddit 上用一个形象的比喻来描述这个过程：
开发者就像矿工。我们的工作就是“挖掘”。
每次开会，意味着我们得打包工具、走到矿口去开会。
会议结束后，还要“走回矿井深处”，还要想清楚之前是在干什么。
如果希望工程师“挖到钻石”，就必须让他们安静地工作。
工程师每天至少需要 4~5 小时不被打扰的时间，而管理者的职责，就是要为他们创造这样的环境。
如何创造深度工作时间？
改善会议文化
这并非难事，前提是所有管理者能共同遵守以下基本规则：
- 会议必须高效：听起来理所当然，现实却很少做到。会议应有明确议程和成果目标。
- 固定会议时间：设定统一的会议时间段，其余时间避免安排会议。可以选择“无会议日”或“无会议时段”，视公司情况而定。
- 只邀请必要人员：远程工作的一大弊端是，邀请人太容易。很多人想：“最多他们一边开会一边处理其他事情，需要时再叫他们发言。”
但这种心态恰恰毁掉了专注状态。
最理想的做法？砍掉尽可能多的会议。
过去两年的研究中，Pylon 的工程团队给人留下深刻印象。
当查看一位高级工程师一周的日程安排时，居然是空的：没有每日站会、没有冲刺计划会、也没有任何周期性会议。
他们依然高度协作，只是不会以固定会议的形式强制执行。这在他们全天到办公室工作的情况下可能更容易实现，但即使在远程环境中，也完全可以去掉部分会议。
如果无法完全取消会议，至少应设立公司范围的“深度工作时间块”。Weave 对 60 万个 PR 的数据分析显示，大多数工程师在以下时段产出最活跃：
- 09:00 – 11:00
- 14:00 – 16:00
虽然这只是提交代码的时间，背后还有准备与午餐时间等因素，但仍说明了：高产时间存在明显聚集，不应被会议打碎。
重新思考 PR 流程
更进一步的问题是：是否真的需要所有这些 PR？
Pylon 团队另一个让人惊讶的做法是：几乎没有强制的代码审查流程。
工程师可以自行合并代码，只有在以下情况下才请求审查：
- 需要反馈
- 变更具有高风险
- 仍在新员工入职阶段
代码审查常常打断双方的思路：
收到 PR 的人想尽快完成以免阻碍他人，发出 PR 的人则在收到评论时忍不住立刻处理。这种循环极易破坏专注状态。
虽然这种做法有悖传统代码质量控制思维，但其逻辑很简单：如果你雇佣的是靠谱的工程师，那就应该信任他们，而不是用繁杂流程限制他们。
以身作则
在会议文化改善后，才有可能解决其他干扰。
最有效的文化建设方式是：领导者自己珍惜深度工作时间，并让团队尊重它。
作者坦言，自己也仍在努力践行：虽然日程中预留了“专注时间”，也戴上了耳机，但有时还是会查看 Slack 并被打断。
这种行为会向团队传递错误示范。深度工作时间应被视为“神圣不可侵犯”的，让大家知道——在这段时间内不在线，是完全被接受的。
在 AI 时代，深度工作愈加重要
随着人们对 AI 的依赖日益增强，深度工作的必要性也水涨船高。
模型的反应速度会越来越快，未来能否“进入与 AI 的心流协作状态”，将成为企业与个人之间拉开差距的关键。
那些善于保持专注、与 AI 携手深度工作的工程团队，将远远领先于其他人。