先说我踩的坑：日历满不等于产出高
2024年3月我接了个后台重构，需求方三个，代码库八年历史。前两周我的 Google Calendar 从 9:30 到 18:00 基本是 30 分钟一格的会，中间塞 15 分钟空隙。晚上 9 点再写代码到 11 点半。用 Toggl 记了一周：每天深度工作 2 小时 17 分，会议 3 小时 42 分，Slack/飞书切换 74 次。最要命的是，我自以为在“多线程”，其实每个任务都留了尾巴，第二天重新加载上下文。Gloria Mark 有个被引用很多的研究说，人被打断后回到原任务平均要 23 分钟左右；微软 2023 工作趋势指数里也有 68% 的人说自己没有足够的 uninterrupted focus time。这个数字不一定套到每个人，但和我那周状态很像。
对比：响应式工作和创造式工作，根本不是一套日程
Paul Graham 在 2009 年写过《Maker's Schedule, Manager's Schedule》。管理者日程是 30 分钟一格，开会、回消息、再开会；制造者日程是至少半天一块。写代码、写方案、做设计，属于后者。你让一个制造者按管理者日程活，他表面在工位上，实际一直在“加载-被打断-重加载”。我后来的独立观点是：大多数时间管理失败，不是自律问题，是你把自己做成了公共 API，任何人任何时间都能调用，还没有限流。要改的不是意志力，是接口：什么时候可调用、多久返回、什么算紧急、什么走异步队列。这个比喻有点土，但比“你要专注”有用。
我用的三步：会议预算、90 分钟深度块、异步窗口
第一步，会议预算。我给自己定每天会议最多 90 分钟，每周不超过 4.5 小时。每个会必须有议程、决策点、owner，缺一个我就问能不能异步。周会从 60 分钟改 25 分钟，站会改到 Slack 每天 10:30 文字同步。第二周我被拉回两个临时会，预算爆了，但至少知道是谁在超支。第二步，深度块。每天两个 90 分钟：9:00-10:30、14:00-15:30。Google Calendar 上设专注时间，Slack 状态写“深度工作中，11:30/16:30 回复”，手机放抽屉，不是静音，是物理隔离。第三步，异步窗口。消息批量处理，11:30 和 16:30 各 25 分钟。紧急定义只留三个：线上故障、客户 P0、老板明确 deadline。其他进 Jira 或 Notion，状态更新，不追着人问“在吗”。WIP 限制 3，任务尽量切成 45 或 90 分钟能交付的小块。
3 周后的数字，以及我不建议你照抄的地方
实验 3 周，中间有 4 天破功。Toggl 周报从深度工作 2 小时 17 分/天，到 5 小时 40 分/天；会议从 3 小时 42 分/天，到 1 小时 20 分/天；Slack 响应没有变慢，因为我固定了两个窗口，反而少了很多“在吗”式追问。但这不是万能药。客服、运维值班、销售、项目救火岗，本来就要响应式工作，硬套深度块会出事。还有，如果老板文化是“秒回”，你单方面改接口会被当成失联。我的做法是先拿一周数据找直属领导对齐：不是我不回，是我把回复放进可预测窗口。最后一句，别一上来搭完美系统，先改一个接口：把明天 9:00-10:30 设成专注块，然后看谁会真的炸。通常不会。