AI 時代下的另類多工與心流 ：碎片化工作中的「動態專注」法則

TL;DR 摘要

AI讓工作更快，也讓任務更密集、更碎片化。集英信誠敏捷顧問 Ruddy 老師提出，真正該問的不是AI能提高多少效率，而是如何重新設計工作。人仍然一次只能專注一件事；面對多個並行任務，關鍵是用動態專注管理切換、用脈絡卡保存思考，並以分層理解承擔AI產出的責任。

• 先重組工作，再談效率：拆清需求、成果、邊界與未知，讓人與AI透過小增量、多迭代及即時回饋協作。
• 多脈絡不等於同時分心：先排優先順序，專注時不任意切換，必要離開前保存脈絡，回來後從明確的下一步接續。
• 工程師的重要產出轉向理解：不只確認測試通過，更要知道改了什麼、結構如何、哪裡可能失敗、證據在哪裡，以及修改後會如何運作。

先重組工作，讓人與AI真正協作

在人力未補、需求未減，資訊串流又持續加速的工作環境中，AI帶來的挑戰不只是如何做得更快，而是如何重新安排工作。Ruddy 老師將問題從「工程師效能可以提升多少」轉向「如何重新組合工作，讓AI發揮最大的功能」。agent化的重點不是把原有流程全部交給AI，而是重新設計人與AI各自做什麼、如何交接，以及如何確認成果。

human in the loop不只是等AI產出後按下確認，而是實作者主動設計自己的工作，持續參與判斷。開始之前，先看清楚要完成的成果、需求邊界、採用的假設，以及仍然未知的事情。講者提醒，AI擅長迅速收斂，但若尚未釐清問題就接受它的方向，也可能讓人的思考範圍過早受限。因此，人要先打開邊界，確認還有哪些事情沒有注意到，再決定如何交付AI處理。

拆解時，需求與工作必須分開處理。需求拆分關注商業問題與真正的價值，可以由PO或團隊進行；工作拆分則關注如何實作，應由實作者另外安排。需求已經拆好、可以開始工作，不代表實作方式也已經決定，更不是把需求直接改寫成task就完成拆解。

• 先拆需求：釐清要解決什麼問題、帶來什麼價值，以及成果的邊界。
• 再拆工作：由實作者依實作方式與自己能掌握的範圍，安排可交給AI處理、也能驗證的增量。
• 保留人的理解：協作不是只讓AI做完，而是人要跟得上產出，知道它做了什麼，才能承擔判斷與驗證的責任。

小增量的標準不是固定的程式碼行數，而是自己能否理解並掌握input與output。無論一個功能是30行還是100行 code，關鍵都在於能不能確認它的輸入、輸出與結果。若範圍大到無法判斷，就應繼續拆小；每次取得產出後立即驗證，再把驗證得到的feedback交回AI，形成小增量、多迭代、尋求回饋的協作循環。

「注意，always不是AI做，是你跟他在協作。」
— Ruddy 老師

這個循環中，人類feedback是最重要的投入。只是反覆要求AI生成，卻沒有提供有效資訊或驗證結果，容易浪費Token，也無助於釐清哪個方案適合。SOP同樣需要隨驗證持續調整，而不是訂好後就固定不變。講者也提到一篇文章對反覆生成可能使結果劣化的提醒；這是他用來提示節制與判斷的說法，不能據此認定所有AI都會隨生成次數增加而變差。

將PPT與註解合併成手機長捲軸的例子，則呈現了agentic思維的另一個轉向。原先的想法是寫一支程式，自動擷取投影片與註解、合併排版，讓註解像黃色螢光筆標示一樣，方便在手機上滑動閱讀。既有的閱讀方式是透過WPS開啟PPT，將註解顯示在投影片下方；長捲軸則進一步把內容整合成連續閱讀的形式。

當AI回應可以直接接收素材並產出成果時，工作目標就不必再綁定於「先寫一支程式」。真正要完成的是適合手機閱讀的投影片與註解整合成果，程式只是可能的手段。這也說明，重新組合工作時，人要先理解成果與限制，再選擇完成任務的方式，而不是沿用原本的實作路徑。

AI並行帶來多工，但人的注意力仍是單工

AI可以平行執行多個任務，人的注意力卻不會因此變成平行處理。把工作交給AI agent後，等待期間往往會啟動另一件事，再加上臨時問題，多工便自然形成。這不只是個人缺乏自律，而是AI協作情境讓同時進行的工作增加了。

• Task A：交給AI修改程式，等待AI agent執行。
• Task B：利用等待時間，開始分析另一項工作的架構問題。
• Task C：Production突然出現Bug，轉而分析Log、追查問題。

表面上是multi tasking，實際上仍是在A、B、C之間輪流Single Task。AI持續執行，不代表人也能同時深入理解程式修改、架構與Bug；每次轉向另一件事，都要付出切換成本。因此，重點不是讓自己看起來同時做更多事，而是承認注意力的限制，把切換做好。

「人類的工作一定是Single Task」
— Ruddy 老師

Ruddy 老師引用Dave Crenshaw對多任務的討論，指出多工可能讓收工所需的處理時間增加20%到40%。約20%的損耗值得警覺，但這裡談的是處理時間成本，不能直接解讀成精確測得的「專注力減少20%」。其提醒是：頻繁切換可能讓忙碌增加，卻沒有帶來等比例的產出。

演講中的AI效能提升圖，據講者說明來自中國科技研究院；他以圖中開發效能提升約40%的例子，並提到測試的提升高於開發，對照多工增加的時間成本。這個對照用來提醒：導入AI之後，仍要檢視人的工作方式，否則效率紅利可能被切換抵銷。不過，兩組百分比的衡量對象不同，不能直接相減，也不能據此斷言所有團隊使用AI與未使用AI的結果都一樣。

並非所有交替活動都只有負面效果。講者也提出有益多工的經驗，但關鍵在於活動的性質與切換後的效果，而不是無限制地增加同時進行的任務。

• 擔任mentor：工程師暫時放下自己的工作，回答受指導者的問題。講者觀察到，這段交流可能讓工程師回到原工作時更專注、更謹慎，甚至帶著新的觀點處理問題；這是可能有益的切換，不代表所有中斷都有幫助。
• 機械性動作搭配音樂：講者將這類組合視為自然且有益的multi task，與同時處理兩項需要高度思考的工作不同，不能混為一談。

動態專注：先排程，專心時不要任意切換

Dynamic Focus是「多脈絡單一專注」：可以保留多個任務，但當下只投入一件事，不因其他工作仍在執行就持續分心。重點不是頻繁切換，而是先安排工作，再依專注狀態決定何時離開、何時回來，讓每次投入都有清楚的方向。

安排工作可以像排功課表。Ruddy 老師分享的做法，是由實作者在前一晚自行排定隔日Task與優先順序，隔天依安排開始工作，再由Personal AI協助提醒、追蹤與調整。人決定要做什麼、先做什麼，AI協助維持排程，而不是每次都靠臨時反應決定注意力要放在哪裡。

功課表提供秩序，但不必成為打斷專注的硬性規則。若正投入工作、進入心流，而且沒有必要中斷，就不要任意switch task；若已疲倦、開始分心，或注意力不再集中，再評估是否切換。講者提到超過二十四分鐘專注的情況，應理解為觀察自身狀態的提醒，而不是人人都必須遵守的固定時限。

「沒有必要，不要switch task」
— Ruddy 老師

Personal AI在這套構想中扮演提醒與協調的角色，而非替人強制決定。時間到了，可以提醒目前應該做什麼；若人判斷當前工作正上手，也可以選擇繼續，再讓後續安排順延。這是講者提出的協作方式，不代表所有工具都已具備完整的提醒與排程調整能力。

專注仍需要時間邊界。Ruddy 老師曾因晚上改code太投入，錯過倒垃圾時間，又碰上隔天停收，只能把垃圾多放兩天。這個生活例子提醒：沉浸工作雖然值得保護，卻也可能讓人忽略不能任意延後的事情。提醒的作用，是讓人有機會重新判斷，而不是等錯過之後才發現。

真正需要切換時，不要直接丟下工作。先壓縮當下的脈絡並交給AI保存，再轉往另一個任務；回來時先讀取先前留下的脈絡，恢復理解後再做下一步。把保存與恢復納入固定流程，才能讓切換不只是換一個畫面，而是有準備地離開、有依據地重新投入。

• 先學會專注：當下只處理一件事，不因其他任務仍在進行就不斷查看或切換。
• 再學會離開：確定需要切換時，先保存當前脈絡，再停止投入。
• 接著學會回來：重新進入任務前，讀取保存的脈絡，恢復理解後再開始。
• 最後才進入動態多工：結合排程、專注狀態與保存／恢復習慣，在多個任務之間有秩序地移動。

這四個階段需要練習，而不是一開始就追求同時管理更多工作。講者認為，透過一定的規範把專注、保存與恢復養成習慣，切換會更順暢，也更容易重新進入心流。動態專注的目的，是保護每次投入的品質，而非增加切換次數。

脈絡卡：保存的不只是進度，而是思考

脈絡卡保存的不只是工作進度，而是離開當下的思考狀態。Context compression與摘要的差別，在於摘要交代「發生了什麼」，脈絡保存還必須回答「我為什麼這麼想」。留下判斷的依據，回來時才有機會恢復原本的理解，而不只是知道工作停在哪裡。

「摘要只是發生了什麼而已」
— Ruddy 老師

一張可用的脈絡卡，需要把進度、假設與後續行動一起記下來。重點不是重寫完整工作歷史，而是留下足以重新接手的線索：

• 目前位置與進度：正在處理哪件事、做到哪裡，以及已完成什麼。
• 當下的思考：正在想什麼、目前朝哪個方向思考，以及為什麼這樣想。
• 假設與驗證：做過哪些假設，哪些尚未驗證，哪些已有驗證結果。
• 下一步：回來後先做什麼，讓重新開始有明確落點。
• 風險與未完成處：有哪些風險、哪些地方因匆忙而沒有處理完整，以及哪些內容需要重新驗證。

操作上，在switch task以前，先把當下情境壓縮成卡片，交給AI保存；返回時，先讀取上一次留下的脈絡，再從記錄的下一步開始。若卡片標出了未驗證的假設或處理不完整之處，就重新驗證，不必先從頭重建整段工作歷史。

初期可以用簡短問答協助紀錄，例如「現在做到什麼情況？」「接下來要做什麼？」「遇到什麼問題？」「應該怎麼思考這個情境？」讓AI協助保存回答，供下次切回時讀取。恢復不一定能百分之百回到離開前的狀態；但隔一段時間再看，也可能發現當時沒有看到的新角度。

若打字增加了紀錄負擔，可以嘗試語音輸入。不過，語音仍可能遇到咬字與辨識問題；講者也以自己的發音經驗提醒，輸入方便與否，仍要看實際使用情況，不能假設語音一定更順暢。

脈絡卡不只適用於刻意安排的多工。即使一次只處理一件事，電話或臨時中斷也會打斷思路；持續用記憶卡追蹤Task，就能在返回時找到接續工作的線索。它的用途是降低遺漏與重新摸索的負擔，而不是保證每次都能在幾秒內完整恢復。

工程師從工作協調走向設計，心流也跟著轉移

AI與Vibe Coding改變了工程師的實作配置，也讓心流的來源逐漸轉移：從親手寫Code、解決技術挑戰，走向協調工作，再進一步設計工作與掌握架構。衡量工程師的價值，不能只看產出多少Code，更要看他對任務與系統理解到什麼程度。

Ruddy 老師描述的心流，是專注做一件事、感覺時間過得很快、效率很高，卻不覺得疲倦，並伴隨愉悅感。傳統的心流情境，往往出現在實作技能與挑戰難度接近時；但能力與難度匹配之外，也需要明確的目標，才容易持續投入。

• debug：當問題的技術挑戰接近自己的實作能力，工程師容易專注於排除問題，進入心流。
• 熟悉路況的開車：講者以交通難度與熟悉情境相近為例，說明人可能投入其中，抵達目的地才發現時間已經過去，許多途中細節沒有留下鮮明印象。這是講者用來描述心流感受的生活例子。

當實作交由AI協助，工程師不再只能以「寫了一噸Code」證明自己的產出。講者用「不看Code」與無限regenerate的玩笑，點出面對大量生成程式碼的困境；這不是免除審查的主張，而是提醒：不斷重新生成，並不等於建立理解。即使測試已通過，工程師仍不能只靠相信生成結果來掌握工作。

「現在的工程師產出是理解」
— Ruddy 老師

這種角色轉變也改變了成就感與心流的來源。資淺工程師可能先從把工作交給AI、協調任務開始，獲得成就感與短暫心流；隨著經驗與理解累積，成長方向則是深入工作本身，知道架構如何安排、各部分如何發揮功能，逐漸成為工作設計者，而不只是任務調度者。

• 工作協調：安排AI執行工作，從任務推進中獲得成就感，是資淺工程師可能的起點。
• 工作設計：理解架構與工作之間的關係，設計整體安排，讓各部分發揮功能，是逐步深入的方向。
• 新的心流條件：當理解能力與問題複雜度接近，規劃、分析與設計也能成為高度投入的工作，而不必只在親手實作時尋找心流。

走向工作設計並非一開始就順利。講者強調，學會新事物帶來的快樂，是值得追求的經驗；但學會之前，常會焦慮、懷疑自己的動作，接著觀察別人、模仿與反覆練習，才逐漸建立信心。初期的不熟練不必被視為能力的終點，也不應因此把工作協調當成成長的終點。

「你學到一個東西的時候那種快樂的感覺勝過心流」
— Ruddy 老師

當工程師同時面對許多Task，真正重要的不是手上有多少任務，而是對每項任務理解得多深。AI改變了Code的產出方式，工程師仍需要透過理解掌握工作；心流也因此從「我完成了多少實作」，逐漸移向「我能理解並設計多複雜的問題」。

「現在的工程師產出是理解」
— Ruddy 老師

Code Review五層理解：從看見修改到預測行為

Code Review的核心是理解，而不只是確認測試通過或檢查Code格式。面對AI產生的修改，審查者必須知道變更內容、解釋運作結構、辨識風險、找到失敗證據，並能預測修改後的行為。這五層理解，才是有依據的品質審查與責任判斷。

「如果你不知道AI改了什麼,那你等於閉著眼睛在 approve」
— Ruddy 老師

• 第一層：我知道AI改了什麼嗎？先確認實際變更內容，不能把測試通過當成已經理解修改。講者提醒，趕進度時，審查容易從第一次仔細review，逐漸變成跳過部分內容，最後以「等一下再看」放行；審查標準不應隨催促而鬆動。
• 第二層：我可以解釋運作的結構嗎？理解軟體或問題由哪些部分組成，以及彼此如何關聯，而不是只認得個別程式片段。熟悉自己設計的結構，是講者提出的一個例子；重點仍是能清楚解釋它如何運作。
• 第三層：我知道哪裡可能fail嗎？預先辨識容易出問題的位置，並在需要的地方埋點，讓程式實際如何執行可以被觀測。看得見行為，才能支撐對系統的掌握與控制。講者使用「埋 code」的說法，但未將其限定為log；是否指log，仍需釐清。
• 第四層：失敗時，我知道去哪裡找證據與資料嗎？除了知道風險在哪裡，也要知道出事後從何處開始trace、到哪裡取得資訊，以及從哪裡著手處理。第三層著重預先辨識風險，第四層則著重失敗後的問題定位。
• 第五層：我可以預測修改後的行為嗎？面對不同input，能說明可能產生什麼output，以及系統接下來會如何運作。理解不能停在「看過修改」，還要能據此判斷變更帶來的行為。

這五個問題可以成為每次審查的自問清單：我是否清楚修改、能解釋結構、知道風險、找得到證據，並能預測行為？不能以盲目信任或反覆生成取代判斷。即使Code由AI撰寫，最終責任仍在人；是否approve，應以自己能否掌握變更及其影響為依據。

「到時候是你負責,不是AI負責的」
— Ruddy 老師

先看見全貌，用分層提問建立認知模型

投入工作前，先後退一步看見全貌。若立刻埋首於某個局部，很容易把正在處理的那一段誤認為整個問題。Ruddy 老師提出的做法是提問：不只問直接參與工作的人，也可以向不直接相關的人提問。看似沒有關聯的問題，有時反而能讓人回到基本原理，重新辨認真正要解決的問題。

「你一開始要先後退一下」
— Ruddy 老師

向 AI 提問也需要層次。沒有分層的 prompt，往往只能靠反覆來回逐漸弄清楚；依理解層次組織問題，則能取得不同層次的結果。講者以布魯姆提問說明這條路徑：從記憶開始，逐步走向理解、應用、分析、評估與創造。記憶不是可以略過的起點，而是後續理解的基礎；提問的目的也不只是取得答案，而是逐步建立能分析與判斷的知識。

理解系統時，講者提出五種 model，讓人從不同角度看見全貌，也讓 AI 認識人的脈絡。這些模型是組織理解的視角，不宜與 Code Review 的五層檢核逐項畫上等號。

• 需求 model：從需求的角度理解要完成的事情。
• 結構 model：從組成與關係的角度理解系統。
• 行為 model：理解系統在做什麼，以及如何運作。
• 失敗 model：把失敗時的情況納入理解，而不只看正常運作。
• real world model：將理解連回真實情境，不停留在抽象描述。

不逐行看 Code，仍可能透過這些模型理解系統在做什麼、看見全貌。但這個說法的前提是確實建立理解，能解釋系統並滿足審查要求，而不是以模型名稱代替證據。它不代表可以跳過必要的驗證，也不代表程式碼由 AI 產生後，人就能免除判斷與責任。

工程師的成長因此不能只停留在調度工具。從記憶、理解到分析、評估與創造，累積的是能組織知識、分析問題並支撐設計的認知模型。AI 可以協助呈現與回應，但認知負荷仍在人身上；工程師必須形成自己的理解，才有基礎走向創造。

「注意，always不是AI做，是你跟他在協作」
— Ruddy 老師

重點回顧

這場演講把AI協作、多工與心流串成同一個工作設計問題：AI可以平行處理任務，人卻仍需要單一專注。動態專注不是切換得更頻繁，而是有意識地決定何時投入、何時離開，以及如何帶著原本的思考回來。工程師則要從執行與協調，逐步走向能理解、驗證並設計工作的角色。

• 安排工作時，先確認需求與工作是否分別拆清，再決定人與AI各自如何參與。
• 開始任務時，先訂明確目標；專注仍佳時不隨意切換，需要離開時先保存脈絡。
• 保存脈絡時，留下進度、假設、驗證、思考理由、風險與下一步，不只留下事件摘要。
• 審查產出時，逐層確認修改、結構、失敗風險、證據位置與可預測行為，讓理解成為承擔責任的基礎。
• 仍待釐清的是埋code在具體實務中包含哪些紀錄方式；演講強調可觀測性與追查證據，未將其定義為只寫log。

Dynamic Focus多脈絡單一專注心流Personal AIContext compression脈絡卡工作重組human in the loopagenticVibe Coding小增量、多迭代、尋求回饋Code Review五層理解可觀測性布魯姆提問認知模型