AI 開始可以幫我處理越來越多事情之後，問題已經不只是 prompt 要怎麼寫。
AI 可以整理目標、篩選職缺、準備申請、寫文章、研究資料，也可以進入程式碼庫或 Webflow，直接修改一個真實專案。但當這些工作同時出現時，新的問題是：每件事應該放在哪一個 Task？哪些上下文要一起保留？一個 Task 做完之後，結果要怎麼回到整體規劃裡？
這些問題如果沒有處理好，多開幾個 AI 對話不一定會讓事情更順利。它也可能只是把原本集中在一個地方的混亂，分散到更多地方。
一個主對話曾經很方便
以前主要使用 Obsidian 裡的 Claudian，很多事情都在同一個長對話中進行。這其實有一個很大的好處：不太需要切換上下文。AI 已經知道我最近在做什麼、知識庫怎麼運作，也大概知道不同專案之間的關係。只要自動壓縮對話後還能繼續，我就傾向留在原本的對話裡。
邊界非常清楚的專案偶爾還是會另外開一個 Task。但那些還很模糊、會跨越不同領域的事情，並沒有被很有系統地分配。因為一旦拆出去，新的問題就會出現：之後誰來整合？另一個對話裡做出的決定，主對話知道嗎？是不是又要重新解釋一次？
現在大部分的工作移到 Codex app 裡，旁邊甚至有一隻可愛的 pet 陪我跑 Task。Obsidian 和原本的 PKM 架構仍然在，只是我不一定每天打開來操作。很多時候，工作直接在 Codex 裡進行；需要閱讀、判斷或重新看全局時，才回到 Obsidian。
真正的改變不是開了更多對話，而是慢慢把不同工作分成三種責任：Main Task、長期 Task，以及一次性 Task。
Task 不是主題分類，而是一個工作房間
現在不會只因為「這個主題很重要」，就替它建立一個永久的 Task。一個 Task 值得長期存在，通常是因為它有清楚的責任、會跨越多個工作階段持續推進，而且知道完成一輪後要留下什麼。
一個 Task 至少應該回答幾件事：它要完成什麼成果？什麼事情歸它負責，什麼不歸它？它會反覆經過哪些步驟？哪裡需要人判斷？做到什麼程度算完成？結果最後要寫回哪裡？
如果這些問題沒有答案，Task 很容易又變成另一個什麼都可以談的聊天視窗。
目前使用的三種 Task，大概是這樣。
Main Task：保留全局觀，但不包辦所有執行
Main Task 會讀取 Goals、Current Focus、不同 Project 的狀態，以及其他長期 Task 最近發生的事情。它比較像一個控制室，負責跨領域比較、規劃與狀態對齊。
例如，它可以巡視目前已釘選的 Tasks 對話，再更新 Current Actions 和 Outcomes。如果每段對話都太長，也可以要求其他 Task 先提供交接摘要；如果某個進展還沒有寫回 Project note，則協助補上可信任的最新狀態。
Main Task 也可以替其他 Task 規劃新的工作流程，但目前仍由我主動觸發，先保留「這件事現在要不要開始、要交給誰」的決定權。等某個流程真的反覆成功、責任與驗收都穩定之後，再考慮把更多派發或排程自動化。
這表示 Main Task 不是只能分流。它可以做跨專案判斷、整理狀態，也可以完成一些小型修改。但當一件工作開始需要自己的專屬上下文、連續操作與驗證證據，就應該回到負責那件事的 Task，而不是繼續把所有細節塞進 Main Task。
長期 Task：讓同一種工作可以持續累積
長期 Task 適合兩種情況。一種是會反覆執行的工作流程，例如職缺搜尋與篩選、內容編輯與發布；另一種是會持續一段時間的 Project，例如一個客戶網站、一個產品，或一個有自己程式碼庫的專案。
它們不一定已經完全標準化，但需要有穩定的責任邊界與唯一狀態來源。每次回到這個 Task，它不只是延續聊天，也是在同一個工作迴圈裡繼續累積偏好、決策、證據和未結事項。
不過，長期存在不代表它現在正在進行。一個 Job Screening Task 可以一直留著，但如果這週沒有在找工作，它就應該進入休眠，而不是因為被釘選，就自動變成 Current Focus。
這個區分很重要。Task 是可被再次使用的工作入口；當前承諾才是我現在真的要投入的事情。
一次性 Task：完成一個有限成果，然後回去
不是每一件重要的事都需要長期 Task。有些工作很複雜，也可能花很多時間，但它的目標仍然很有限：完成一次申請、準備一場面試、做一份研究、處理一次資料移轉，或產出一篇需要大量資料的文章。
這類工作適合使用一次性 Task。它應該有清楚的完成條件，完成後把結果、證據與尚未解決的事項寫回原本的 Project，然後就可以結束。
尋找適合合作的客戶與事業機會，很容易看出三種 Task 的差別。
Main Task 管理的是整體方向：目前想發展什麼？哪些客戶、合作或產品機會值得投入？這週的 Current Focus 是什麼？
機會篩選可以是一個長期 Task。每一批可能的客戶或合作機會，都經過相近的流程：讀取來源、判斷適配度、做 Go／Hold／Skip、保留證據，再決定是否值得深入。
當其中一個機會值得深入時，準備提案、研究對方、整理相關作品或準備會議，就可以進入一個範圍明確的一次性 Task。完成之後，合作狀態和重要證據回到對應的 Project note，不需要讓每個機會永久佔據篩選 Task 的上下文。
同一個做法也能轉移到內容創作。Editorial Loop 是長期 Task；單篇需要大量研究或修改網站時，可以另外開一次性 Task；Main Task 則判斷內容目前是否真的比其他目標更值得投入。
上下文可以分散，但狀態要能被重新理解
把工作拆到不同 Task 之後，另一個問題自然會出現：上下文到底放在哪裡？
目前不只依賴其中一種記憶。Task 對話與自動壓縮保存實際工作中的細節、近期推理和偏好；Obsidian 裡的 Project note 則保存跨 Task 需要信任的狀態。
有些方法會把 goal.md、plan.md、worklog.md 分成三個檔案。在這套系統裡，它們代表三種上下文，而不是三個必須照抄的檔名。Project note 通常會同時包含：要達成的成果與成功標準、目前的 Next 和 Waiting，以及已完成的證據與重要未結事項。
詳細操作不需要全部寫回。完整對話可以留在 Task，程式變更有 Git，工具也有自己的紀錄。只有未來真的會依賴的改變，才需要寫回 Project note：方向改了、優先順序改了、接受了一個重要決策、完成了一項成果、取得新的證據，或出現新的 Next／Waiting。
PKM 根目錄也有一份 AGENTS.md，保存所有 AI 不知道就會持續犯錯的共同規則。比較完整的理由和例子則放在 Collaboration Protocol，需要時再讀。Task 本身只保存和自己責任相關的局部規則。這些規則不是一開始就設計好的，而是從一次次實際協作、發現摩擦、再修正的過程中慢慢累積出來的。
因此，Obsidian 對我來說比較像一個可信任的長期狀態層，而不一定是每天工作的主要介面。讀者也不需要先建立一套完整 PKM 才能開始。一份清楚的 Goals、Projects 和 Current Focus 文件，就已經比讓所有狀態散落在聊天裡更可靠。
人應該出現在真正需要判斷的地方
Task 分工的目的，不是讓我退出所有工作，也不是讓我逐步確認 AI 的每一個操作。
如果需求與完成條件已經清楚、成果容易驗收、修改可逆，可以讓 AI 完成整段工作後再一起 review。但如果需求仍會變動、涉及品味或重要取捨，或後面的實作高度依賴前面的決定，就先完成一個可以 review 的段落，等我調整方向後再繼續。
這和 Grill Me 的想法很接近：不要把所有判斷都壓在第一次 prompt，也不要為了控制而停在每一個小步驟。在真正會改變方向的地方，刻意保留人可以介入的機會。
理想的審閱介面可以分成三種：哪些事情需要我決定、哪些已經被工具或證據驗證、哪些已經可以直接使用。這樣需要 review 的就不是整段工作過程，而是目前真正需要我負責的部分。
可以從很小的版本開始
要開始使用這套分工，不需要先設計一個很複雜的 AI 組織。
先建立一個 Main Task，讓它知道你的 Goals、Projects 和 Current Focus。再找出一個真的會反覆發生、值得累積上下文的工作，替它建立長期 Task。其他事情先用一次性 Task，完成後寫回原本的 Project 或成果文件。
使用幾輪之後，你會逐漸發現哪些上下文每次都要重新解釋、哪些判斷一定需要自己保留，以及哪些步驟已經穩定到可以變成 skill、自動化或更完整的工作流程。
真正重要的不是開了多少個 Task，而是每一件工作都知道自己為什麼存在、要做到哪裡，以及完成後該回到哪裡。
這套系統的目的，不是讓 AI 自己接管更多工作，而是讓我在保留全局判斷的同時，能把不同的工作放心交給它持續推進。前提是，我也必須給它足夠的上下文，理解這些工作最後要服務什麼。
如果工作本身仍然模糊，可以先讀〈不要只問 AI，也讓 AI 反過來問你〉。
如果想看長期狀態如何幫助 AI 跨領域找到需要注意的事情，可以接著讀〈我如何重新設計 PKM 的 status 系統〉。