最開始，我真的沒有想那麼多。
文章寫好了，接下來還要建草稿、放圖片、補替代文字、檢查連結、設定 SEO、預覽桌機與手機、按下發布，最後再把正式版本收回 Obsidian 和 Notion。這些事情單獨看都不難，但每發一篇就要再走一次。
所以我最早的問題很簡單：
這些重複工作，可不可以讓 AI 幫我？
我原本以為，只要把內容交給 AI，叫它放進 WordPress，事情就結束了。真正操作後才發現，最難的根本不是「按下發布」。
真正困難的是：誰判斷文章已經可以發？AI 說完成了，要拿什麼證明？做錯可以修幾次？碰到圖片、SEO、版本或權限衝突時，誰有權決定繼續還是停止？發布之後，又由誰把正式版本與紀錄收回來？
我想自動化的原本只是一個動作，最後浮出來的卻是一整條責任鏈。
在我現在的網站流程裡，它其實長這樣：
Lukas 核准文章 → ChatGPT Work 完成 WordPress 發布與檢查 → 專責 ChatGPT Work 回收正式版本 → 結果回到原承辦 → Lukas 收到完整結案
這裡的 ChatGPT Work，可以先把它理解成「長期固定責任的 AI 工作區」；正本則是「目前被承認的正式版本或紀錄」。我不是先讀完理論才畫出這條流程，而是先把它跑出來，後來才找到描述它的語言。
我是在 2026 年 7 月 10 日開始使用 ChatGPT Work。最初只是請它幫忙處理網站，接著一路長出發布、驗證、跨 ChatGPT Work 派工、正式版本回收與例外處理。這些規則不是第一天就畫好的，而是在每一次真的做事、真的出錯、真的交接之後，不斷進化出來的。
一篇談 Loop 的文章，讓我看懂自己正在做什麼
前幾天，我先看到一篇談 Loop 的社群文章。它用一句很有煽動力的話開場：發明 Claude Code 的人，已經不再花力氣寫提示詞，而是在寫會驅動 AI 工作的迴圈。那是這次討論的起點，但不是我查證事實的終點。
先更正一個容易混淆的地方：Boris Cherny 是 Claude Code 的創造者與負責人，不是 Claude 或 Anthropic 的創辦人。Anthropic 在官方活動紀錄中也以「Claude Code 的創造者」介紹他。Anthropic：Code w/ Claude SF 2026
但那篇社群文抓到的方向確實存在。Boris 在 Meta @Scale 談到，工作方式正從「人寫程式」，走向「Agent 寫程式」，再走向「Agent 提示其他 Agent 完成工作」。Meta @Scale 原始活動影片、TechCrunch 訪談報導
Addy Osmani 也在 2026 年 6 月的文章中，用 Loop Engineering 描述這類工作方式：人不必逐輪餵指令，而是設計一個會發現任務、分派、檢查、記錄狀態並決定下一步的系統。Addy Osmani：Loop Engineering
我看到這裡，突然有一種「喔，原來我們最近一直在做的是這個」的感覺。
不是因為我讀完文章，才照著它打造一套流程。剛好相反：我是先在真實工作裡一路踩坑、加規則、拆責任，後來才從別人的論述裡，找到可以描述它的語言。
提示詞沒有死，只是不再獨自扛起整個系統
那篇社群文章還提到，Anthropic 曾大幅縮短 Claude Code 的 system prompt，也就是產品預先給 AI 的底層工作指引。官方資料支持這件事，但範圍很明確：針對 Opus 5、Fable 5 等新一代模型，Claude Code 移除了超過 80% 的 system prompt，在 Anthropic 的內部程式評測中沒有測得退步。Anthropic：The new rules of context engineering for Claude 5 generation models
它不能直接被翻譯成「每個人刪掉 80% 提示詞，都會省下 80% Token」，更不代表提示詞已經沒用。
提示詞仍然負責表達這次要做什麼。但當工作開始碰到工具、資料、版本、驗證、重試、權限與正式發布時，品質不可能只靠一句寫得很漂亮的指令支撐。
比較準確的說法是：提示詞從唯一主角，回到整套工作系統裡的一個零件。真正的槓桿開始往完成條件、工具、證據、停止規則與責任邊界移動。
AI 內迴圈：讓機器在邊界內反覆施工
Claude Code 官方文件把 Agent Loop 說得很清楚：模型讀取目前狀態、呼叫工具採取行動、接收工具回傳的結果，再根據新狀態決定下一步，如此反覆，直到交付結果或觸發限制。Claude Code 文件：How the agent loop works
套回網站發文，大概會變成：
讀取核准內容 → 建立或更新草稿 → 檢查頁面 → 補齊必要欄位 → 執行驗證 → 依結果修正 → 達標或停止
這就是我現在所理解的 AI 內迴圈。
它的價值不是 AI 能夠一直重做，而是它可以在清楚範圍裡，把原本需要人逐步盯著的執行工作接起來。
但 Loop 並不等於「做到看起來差不多為止」。如果沒有完成條件、驗證證據與停止規則，那不叫可靠的迴圈，只是比較昂貴的重複。
因此，我們後來替發布流程補上幾個必要零件。以下規則已經核准，會從下一篇真實案例開始一致套用；它們還不是經過大量案例證明的成效結論：
- 有一張最小發布證據卡，不能只回答「完成了」。
- 每篇都做最低技術驗證；只有圖片、表格、SEO 或版型改動時，才增加相應檢查。
- 是否需要第二個 AI 獨立複核，依任務風險決定，不是每件小事都開大會。
- 修正與重試有上限；超過上限就停止，交還人類裁決。
- Yoast 的燈號可以提供線索，但不能為了變綠就改壞已定稿的文章。
- 簡單任務使用較輕量的資源，只有高風險或複雜問題才升級。
這些規則的共同目的只有一個：
AI 不能只說自己做完了，還要留下足以讓別人判斷的證據。
人類外迴圈：目的、核准與例外不能一起自動化
內迴圈可以處理很多工作，卻回答不了幾個最重要的問題。
這篇文章為什麼現在要發？照片是否適合公開？某個技術錯誤值不值得延後發布？工具提出的 SEO 建議，會不會破壞原本語氣？遇到例外時，是縮小範圍、退回修改，還是整件事停下來？
這些不是再多跑幾輪工具，就會自然得到的答案。
Addy Osmani 把它稱為「擁有外迴圈」：Agent 可以在裡面調查、施工、驗證與重做，但證據必須跨過一道邊界，由掌管正式系統的人決定成果能不能進去。Addy Osmani：Own the Outer Loop
這和我現在的做法非常接近：
AI 在內迴圈裡執行、檢查與有限次修正；我在外迴圈決定目的、劃定邊界、核准公開、處理例外並承擔最後結果。
人類核准不是「自動化做得不夠完整，才勉強留下一顆按鈕」。它本來就是責任設計的一部分。
內迴圈追求速度與一致性；外迴圈守住目的、風險與責任。
AI 可以派工，但不能自己替我簽驗收單
我後來發現，一個 AI 完成任務，不等於整件工作已經結案。
文章發布後，還要驗證前台、保存正式版本、更新狀態與回收這次遇到的問題。低風險例行工作可以由同一個 ChatGPT Work 執行並完成最低驗證；不能接受的是只留下一句「完成了」。高風險工作才增加獨立複核。
所以我們把工作拆成不同責任區。用一般語言說，就是發布端完成文章與前台檢查，保存端收回定稿和紀錄；只有異常或高風險情況，才交給中央裁決。
套回目前的工具，負責網站發布的 ChatGPT Work 會把文章識別、網址與完成證據交給知識正本 ChatGPT Work；後者只負責保存 Obsidian 快照和更新 Notion 狀態，不反過來修改網站。WordPress 仍是網站現行正本，Obsidian 保存批准快照，Notion 只管理狀態與索引。
說穿了，這些不是幾種完全不同的 AI。它們就是同一套 AI，在不同 ChatGPT Work 裡套用不同屬性、規則、權限與責任。差別不在誰比較神，而在誰被允許做什麼、完成後要把結果交給誰。
這裡真正重要的不是我替幾個 ChatGPT Work 取了什麼名字，而是三件事：
- 每一段工作都有主責。
- 下一棒知道自己收到什麼，也知道完成後要回報給誰。
- 主責承辦不能把工作派出去後就消失，必須等下游結果回來才能結案。
它很像一支施工大隊。
師傅可以發現牆面不平後，自己補土、打磨、重漆；但他不能因此自行決定拆牆，也不能完工後替屋主簽下驗收單。
AI 可以是很能幹、甚至會自己找人協作的承辦，但人仍然決定要蓋什麼、哪裡不能碰，以及最後能不能交屋。
寫這篇文章時，臨時編輯小組真的出現了
更有趣的是，這篇文章本身又讓我看到一次現場示範。
子代理可以理解成只為一道問題臨時成立、交付後就解編的小組。當我問「這篇應該放粉專、主站還是實驗室」時，主腦沒有直接拍腦袋回答，而是臨時叫進一個名為 Editorial route 的子代理 Mill，讓它獨立評估內容歸屬。接著又分別叫來源查證與讀者視角的角色進場，再把結果收回來整合。
我甚至可以在畫面上看到這個臨時任務小組正在工作。
但 Mill 沒有權力替我發文，來源查證者也不能因為找到證據就自行上線。它們提供的是能力與證據；正式公開的裁決仍然留在我這裡。
這一刻，我才更清楚地看到兩種組織同時存在：
- ChatGPT Work 像常設部門，長期掌管網站、實驗室或知識正本。
- 子代理像臨時任務編組，針對一次需要快速補位的問題進場，交付後解編。
它們都可以替我工作，但都不會因此自動取得我的裁決權。
到今天，哪些真的完成，哪些還沒有
寫到這裡，我得踩一下煞車。
目前已經形成並核准使用的，是發布證據、最低與條件式驗證、風險分級、修正上限、資源分級，以及「發布完成後直接保存定稿，異常才升級」的工作規則。
目前被我們依同一套欄位逐階段完整盤點的，只有第一篇文章案例（內部識別為 WP-197）；過去雖然也完成過發布與正式版本回收，但沒有每次都留下相同格式的證據。接下來幾篇正式文章，才會繼續檢查這套流程能不能穩定重複。
至於 API、Token、腳本、排程與自動發布，方向雖然已經核准，但尚未施工。現在跑得動的是工作方法與責任路由，不是一條無人值守的發文工廠。
這個差別不能含糊。
我不想先蓋出一套看起來很厲害的自動化，再逼真實工作遷就它。比較合理的順序是，先讓幾篇真正要發布的文章走過這條路，看看哪些檢查有用、哪些步驟太重、例外是否能被正確接住，再決定哪些部分值得寫成程式。
如果流程站不住，就改流程；不是為了證明自己有一套系統，硬把每次重工解釋成成功。
你不需要先建立一個 AI 部門
這套做法看起來很大，但一般人不需要先建立一排 ChatGPT Work，也不必替 AI 編軍階。
下一次要把重要任務交給 AI 前，只要先寫清楚六件事：
- 目的：我要得到什麼結果？
- 主責：誰負責把整件事收回來結案？
- 邊界：AI 可以碰什麼，不能碰什麼？
- 證據：它要拿什麼證明完成？
- 停止：最多修幾次，遇到什麼必須停？
- 裁決與正本：哪一步一定等我批准，最後正式版本放哪裡？
例如，請 AI 整理一場會議，不必先蓋出一套龐大系統，也可以這樣填：
- 目的：整理成一頁會議紀錄。
- 主責：我負責最後確認。
- 邊界：不得補寫會議中沒有出現的決議。
- 證據：重要事項要能連回錄音或逐字稿的時間點。
- 停止：聽不清楚就標記，不准猜。
- 裁決與正本：我核准後才能寄出，正式版存入指定資料夾。
發想、聊天、取標題這些可拋棄的任務，不必為了顯得專業而跑完整套制度。真正值得建立閉環的，是正式發布、資料寫入、對外聯繫、金錢、權限，以及會影響別人的工作。
制度不是越重越安全。它應該讓普通工作走得更短，讓例外與高風險工作知道何時停下來。
本篇實驗狀態
- 方法與責任路由：已形成並核准套用。
- 第一個完整盤點案例：WP-197，已完成。
- 多篇文章連續驗證：待下一篇正式案例開始。
- 核准式自動發布產線：方向已核准，尚未施工。
- 本文狀態：已由 Lukas 核准公開，並納入實驗室正式紀錄。
我想自動化的，從來不是責任
回頭看很荒謬。
我一開始只是想少做幾次複製貼上，結果一路聊、一路玩、一路踩坑，最後開始設計責任路由、驗證方式與停止條件。
但真正值得留下來的，可能不是我建立了幾個 ChatGPT Work，也不是哪一個模型幫我按下發布。
而是我逐漸看清楚：
AI 可以自己反覆施工，但不能自己決定什麼值得交付，更不能替人簽下驗收單。
好的自動化不是讓人消失，而是讓人只出現在真正需要判斷與承擔責任的地方。
這套閉環現在有規則、有路由，也開始有案例；但它還不是一條完工的產線。下一步不是急著讓所有東西全自動，而是讓真正要發布的文章一篇一篇走過去，看看它到底站不站得住。
答案會改變，工具也會替換。
但最後那張驗收單，仍然要有人願意簽名。