最近最常見的「忙」，其實不是工作量大，而是工作被切得太碎。

你大概也遇過這種一天：上午寫一段需要深思的邏輯，中間被 Slack @ 了幾次、臨時被拉進一個會、回完訊息又想起信箱還有十封未讀。到下班時，感覺整天都在動，產出卻不成比例。

這篇 Threads 用一個工程師很熟的比喻講得很直白：在需要深度專注的狀態下，大腦更像單核處理器，所謂「多工」常常只是在任務之間輪流切換（concurrency/time-slicing），並不等於同時並行（parallelism）。

我覺得這個比喻的價值不在於「大腦到底是不是單核」（當然不是），而在於它把成本講清楚了：切換會吃掉你的吞吐量。

1) Context Switching：看不見的時間都被吃掉

在市場與產品的工作裡，我常看到兩種人：一種人看起來忙到爆，另一種人行事很安靜但交付很穩。差別往往不是能力，而是「上下文切換」的頻率。

每次從 Task A 轉到 Task B，你都要做兩件事：

• 保存現場：你原本的推理走到哪裡、下一步要驗證什麼、有哪些假設尚未確認
• 載入新情境：對方的需求、背景、限制、你要給出的答案要精準到什麼程度

這個成本很難被工時系統捕捉，卻會直接反映在「一天下來的有效輸出」上。

如果你長期處在高頻切換，會出現一種很典型的症狀：你開始依賴「立刻回」來減少焦慮，反而把自己鎖進更密集的切換迴圈。

2) 「L1 快取失效」：被打斷後的冷啟動

Threads 提到一個很好懂的比喻：深度工作時，重要的變數、背景、決策脈絡像是暫存在 L1 cache。突然被打斷，cache 直接失效；回來要再把上下文從長期記憶慢慢載入。

所以你才會有這種體感：

• 只被問一句話，回來卻要花十幾分鐘才能重新進入狀態
• 明明只是「回個訊息」，結果把整個上午的節奏打散

很多研究與實務分享都提過類似量級的恢復成本（常見說法是 15–20 分鐘左右，實際會依任務難度與個人狀態波動）。我自己的經驗是：任務越需要推理、寫作、設計，冷啟動就越痛。

3) 「過熱降頻」：疲勞感和產出脫鉤

最折磨人的不是忙，而是「忙到看不到成果」。

當你一整天都在切換，能量被耗在切換開銷上。你會覺得很累，卻難以指出今天到底完成了什麼。這種疲勞很像機器長時間在高負載與頻繁切換之下產生的熱耗。

有個留言提到 ADHD 的體感：高頻切換在當下甚至可能「很享受」。我認為這也提醒了另一件事：是否痛苦，和是否高效，是兩條不同的軸。有人在切換裡感到刺激，但交付品質仍可能被稀釋；也有人需要儀式感把外界噪音隔離，才做得出高難度的輸出。

真正可操作的解法：把工作變成批次處理

Threads 的主張很務實：不要追求自己同時跑很多執行緒；把工作改成批次處理（batch processing）。這裡我補三個在職場比較落地的做法：

1. 替深度工作預留「不可打斷」的窗

   • 例如每天固定兩段 60–90 分鐘，直接開勿擾
   • 讓團隊知道你在哪些時段才會快速回覆

2. 把回訊息變成一個「工作項」

   • 信箱、Slack、訊息集中在固定時段處理
   • 回覆的目標是清空與交代，不是陪聊

3. 切換前先寫下「回來要做什麼」

   • 兩行就好：目前狀態 + 下一步
   • 這是給未來的自己留一個重新進入的入口

最後，用工程師的語言講一句：你想要的是吞吐量（throughput）與可預期的延遲（predictable latency），不是看起來很忙的 CPU 使用率。

原文連結：Threads 貼文

深度工作 #專注力 #職場生產力 #ContextSwitching #工程師思維 #時間管理