這次整理我的作品集，我同時開了幾個 AI Session。一邊改首頁與設計系統，一邊寫中英文章、補圖片，另外安排任務檢查導覽與翻譯。我不想每件事都排隊等同一個對話做完，但也很快發現，只說『你們自己合作，不要重疊』還不夠。
我以 UIUX Lead 的角度整理這次實際調整過的流程：怎麼分工、哪些規則要先寫、何時需要 skills，以及如何讓 review 有結束條件。實例來自這個作品集的多 Session 協作。Codex 與 Claude Code 的功能比較，則依照 2026 年 8 月 27 日查核的官方文件，不把兩套工具都實測過當成前提。
我在什麼情況下拆成多個 Session
我的分法不是一個負責 React、一個負責 CSS。首頁版面和文章內容可以各自推進，但如果兩個任務都要修改同一個共用元件，就要先協調。值得拆開的是能交付獨立結果的工作，例如一篇文章的繁中翻譯、一組已確認來源的圖片，或一次只讀的返回導覽檢查。
如果只是改一句文案，開更多 Session 反而增加說明和交接。我的建議是先用一個實作任務，加一個範圍明確的 reviewer。只有真的存在獨立工作，才增加其他任務。
我說的 loop engineering 是什麼
這裡的 loop engineering 是我對工作方法的描述，不是 Codex 或 Claude Code 某個功能的正式名稱。我關心的是每一輪修改怎麼接到下一輪：輸入是什麼、誰判斷、回饋交給誰，以及什麼時候停止。它也不是讓 AI 無限互相 review。
- 定義說清楚讀者的問題，以及怎樣才算完成。
- 分工每個任務都有負責人、檔案範圍與修改權限。
- 實作只修改約定範圍，遇到新依賴先記錄。
- Review對照需求檢查行為，不只看 diff 大小。
- 驗證針對準備整合的版本，執行相關檢查。
- 交付凍結、整合，取得授權後發布並記錄結果。
分配檔案與決策權，不只是分配職稱
一開始，協作訊息裡曾出現不同的整合負責人安排。如果每個 Session 都覺得自己可以做最後 commit，光是『不要改到別人』就不夠。我後來固定一個整合負責人，其他任務回報可交付的檔案與檢查結果，不各自 push。
| 任務 | 負責範圍 | 不能自行修改 |
|---|---|---|
| 首頁與整合 | 首頁版面、共用設計 token、最後 commit 與 push | 還在整理的文章內文與媒體 |
| 文章與媒體 | 中英文章、章節導覽與對應圖片 | 首頁版面，以及別的任務尚未完成的檔案 |
| 獨立 Review | 指定行為、重現步驟與具體問題 | 沒有明確移交修改權的實作檔案 |
| 共用紀錄 | 同一位負責人整合回報，更新 PLAN.md 與 HANDOFF.md | 好幾個 Session 同時重寫同一段進度 |
這張表是責任分工，不是檔案鎖。若要跨範圍修改，就先說明具體檔案，取得原負責人的移交。新的任務也先讀目前分工，不能只靠較早的對話猜誰還在寫。
共用介面先講好，再各自實作
四張相關閱讀就是一個實例。我希望文章與作品頁都能推薦內容，也能回到相關分類。這不是讓兩個 Session 各做一套卡片。共用元件的負責人先確認 currentKey、entries、locale 與分類連結等輸入，文章任務接 Blog route，首頁任務接 Work route。
我的 UIUX 決策是推薦內容要相關、不能推薦自己、文案跟目前語言一致，而且主要返回入口與返回分類不能混淆。資料怎麼傳、元件怎麼拆，則在同一份約定裡交給實作負責人確認。這樣每個人知道自己接的是同一個行為。
AGENTS.md 與 CLAUDE.md 要有共同規則來源
Codex 會讀取 AGENTS.md 作為專案指引。Claude Code 使用 CLAUDE.md，官方也提供匯入既有 AGENTS.md 的方式。我建議共用規則只維護一份，再加入各工具真正不同的設定。這是我會用在下一個專案的整理方式，不代表這個作品集已經裝好兩套設定。 Codex 專案指引 · Claude Code 匯入規則
例如在 CLAUDE.md 引用 @AGENTS.md。下面是共用規則應該交代的內容，不是新增另一份會互相矛盾的長篇指令。
- 開始前必讀的規則、架構、design system 與目前任務紀錄。
- 允許修改的檔案、共用元件責任，以及跨範圍變更的確認方式。
- 分支與 Local 環境、預覽位置、建置產物，以及誰能啟動或重建它。
- 驗收條件、必要 QA、發布權限與停止條件。
- 機密資料不得進入對話、紀錄或公開素材。ignore 規則不等於權限控制，也不會移除已追蹤的機密。
哪些流程值得整理成 skill
我已經把一些反覆提醒的 UIUX 檢查整理成自用 skills，例如優先使用既有 component 與 variable，檢查顏色、radius、spacing 是否綁定 token。個人版本不直接放進公司 Git。團隊要共用時，再整理成經過確認的專案版本。
多 Session 的部分，我會優先整理成『領任務前確認範圍』、『回報可重現的 review 問題』與『交付前整理檔案和 QA』三種流程。每個 skill 都要有適用時機、輸入、步驟、輸出與遇到阻擋時的處理方式。這些是下一步可以重用的流程，不是這次已經全部製作完成的工具。
兩套工具都有 skills，但 skill 本身是指引，不是互斥鎖，也不保證測試通過。需要強制執行的限制，還要依環境搭配權限、hooks 或 CI。這篇不會替你停用安全確認。 Codex skills · Claude Code skills 與 hooks
Codex 與 Claude Code 已經提供什麼
以下是官方功能現況，不是我的效能比較，也不代表每個帳號、版本或操作介面都相同。
- Codex：目前版本提供 subagents，可明確要求把獨立任務交出去，再收回結果。專案指引或 skill 也可以要求分工。 官方 subagents 說明
- Claude Code：提供 subagents，也有共享任務與訊息協調的 agent teams。Agent teams 目前仍屬實驗功能，預設關閉，需依官方方式啟用。 官方 agent teams 說明
- Worktrees：兩套工具都有相關支援，用分開的 checkout 隔離檔案修改。但它們不會替我決定元件責任，也不會自動解決最後的語意衝突。 Codex worktrees · Claude Code worktrees
所以不必先做一個大型多 agent 系統，才能開始分工。先使用手上工具已有的能力，再補上專案的工作約定。如果 Codex 和 Claude Code 都參與，我也不會假設它們自動共享對話或狀態，仍以同一份交接紀錄與明確版本為準。
Review 改變的行為，再驗證確切版本
文章目錄有一次很具體的問題：桌機上兩個交付方案的標題並排同高，目錄高亮卻總是偏到後面的標題。Reviewer 指出原因與可重現條件後，才交回文章負責人修正。這種回報比『再檢查一次 UX』有用，因為下一個人知道要驗哪個行為。
加入文末推薦後，原本掃描整個 article 標題的檢查也需要更新。推薦區自己的標題，不應被當成內文目錄項目。這次用正文範圍標記讓檢查只讀該讀的內容，而不是為了讓測試通過，把正確的語意標題拿掉。
我要求的『只驗證一次』，是不要讓每個 Session 反覆跑同一套已完成的檢查。它不是修完 bug 也不重驗。本次修改先做必要的 scoped QA，整合者再檢查準備發布的版本。失敗後有修正，就只重跑受影響的檢查。
Build 通過也不等於 UI 正確。這個作品集曾需要修正圖片與專案的對應，還有返回首頁和返回分類的差別。這些都需要我從內容與操作意圖判斷。工具無法執行的瀏覽器檢查，就寫未驗證，不能用型別檢查替代。
完成的批次先凍結，由同一個人整合
Brand Center 的圖片、作品頁的補圖與繁中翻譯，是不同批次。我不希望完成的翻譯一直等下一組圖片，所以每批都列出精確檔案與 QA 結果。回報 READY 後先停止修改，讓整合者固定 snapshot。新的要求保留，但移到下一批，不悄悄塞進已驗證版本。
在共用 Local 資料夾時，這個約定尤其重要。分支名稱不同，並不會讓同一份檔案自動分身。我們也限制誰能重建 .next、操作 git index 或啟動預覽，避免檢查到別人的半成品。正式團隊專案仍應走既有 branch、PR 與 code review 流程。我的個人作品集這次授權推 main，不是一般公司專案的預設做法。
下一個專案可以這樣開始
下面是依這次經驗整理的起始 brief。把目標、路徑和驗收換成自己的專案。它是溝通範本，不是會自動設定權限或開啟 agent teams 的指令。
目標：讓文章與作品頁都有四個相關閱讀推薦。
先讀專案規則、現有實作與尚未提交的 diff。
修改前先提出真正能獨立進行的分工。
每個任務列出負責人、允許檔案、禁止檔案與驗收項目。
先確認共用推薦元件的輸入，再分別修改兩種頁面。
共用 registry、PLAN.md、HANDOFF.md 與最後整合，都只設一位負責人。
檔案範圍無法安全分開時，使用各自的 worktree。
Review 必須附上重現步驟與檢查版本。
只跑本次修改需要的檢查，再做一次整合檢查。
檢查失敗就修原因，重跑受影響的項目。
缺權限、工具受阻或決策未定時直接回報，不自行猜測。
完成後回傳精確檔案、QA 結果與限制，再凍結這些檔案。
不要 stage 別的任務的修改，也不要在未約定授權前 push。
達到驗收條件就停止。新需求排到下一批。我的交接檢查清單
- 任務寫清楚使用者問題、驗收條件，以及這次不做什麼。
- 每個修改檔都有負責人。共用介面的資料格式先確認，再修改使用它的頁面。
- 交接包含分支或基準版本、精確路徑，以及凍結的 snapshot 或檔案雜湊。
- 適合重用的既有元件、token 與多語文案已優先使用。
- Review 寫出發生什麼、怎麼重現，以及檢查的是哪個版本。
- 相關桌機、手機、鍵盤與內容語言檢查，都記錄通過、失敗或未執行。
- Build 或型別檢查不會被寫成畫面驗收。工具受阻就記錄，不繞過限制。
- 圖片真的對應該專案。發布授權與必要遮蔽，要和程式品質分開確認。
- 只有整合負責人 stage 已確認的批次。無關及未完成修改都保留原樣。
- 最後的紀錄分清楚 Local 完成、commit 已推送，以及正式網站已確認部署。
常見問題
需要先安裝多 Session skill 嗎？
不需要先安裝某個特定 skill 才能開始。先確認工具已有的分工能力，寫清楚範圍。當同一套交接或 UIUX 檢查反覆使用，再整理成 skill。Skill 不會代替檔案隔離或發布權限。
可以在同一個 Local 資料夾工作嗎？
可以，但要明確分配檔案、共用建置與 Git 操作責任。這是我們這次使用過的方式，不代表風險消失。若多個任務需要改同一區，優先改用獨立 worktree，再由整合者合併與驗證。
什麼時候應該停止迴圈？
驗收條件達成、必要檢查完成並交接後就停止。相同失敗反覆出現、缺權限或必須由人決定時，也要停下來回報。我會先約定最多幾輪或可用時間，不讓『再看一次』變成沒有終點的工作。
接下來我會怎麼調整
這次我完成的是把同時進行的工作整理成能接續、能檢查、也能分批交付的流程。我還沒有測量它節省了多少工時。下次可以記錄等待整合的時間、重新打開的問題與重複驗證次數，再決定哪些步驟值得自動化。
如果想看這套規則怎麼從單一任務開始，我另外寫了 如何把 AI 指令整理成交付流程。想看實際設計如何落地，可以接著看 Ogloba 官網的 ReactJS 工作流程。這篇補的是它們之間的協作方式，不是再多一套需要維護的規則。