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