數百個 AI 同時工作：分波、抽審與收件

假設你要替四百家合作店家各寫一段介紹。每一段都不難，難的是數量。一個人一天寫二十段，要做將近一個月；一個 AI 一段接一段寫，也要好幾天，而且寫到後面，前面的規則早就被擠出上下文。

直覺的做法是「開很多個 AI 同時寫」。這確實會快，但也會帶來新的問題：誰寫了哪一段？兩個 AI 會不會改到同一個檔案？寫完的東西誰來檢查？四百份草稿全部丟給一個人看，人會先被淹沒。

這篇文章說明我們怎麼讓數百個 AI 同時工作，而人仍然只需要看一張卡。重點不在於 AI 有多聰明，而在於把哪些事交給 AI、哪些事堅持交給程式。

AI 只做「一件」

整套設計最重要的一條規則是：每個 AI 只負責一件工作。拆單、排隊、檢查、彙整、記帳，這些都不需要判斷，全部交給程式。程式每次跑出來的結果都一樣，也不耗用 AI 的額度。

這樣分工有兩個理由。第一，需要判斷的部分越小，AI 越不容易出錯；寫一段介紹，比「管理四百段介紹的進度」容易得多。第二，可以重複的步驟交給程式，出問題時才查得出原因。如果連排隊和計數都交給 AI，每次跑的結果可能都不一樣，錯了也不知道錯在哪。

我們也不是一開始就上數百個。只有同類工作累積到一定數量，例如數十件以上，才值得開這條流水線；件數少的時候，一個 AI 依序做完反而簡單。

工作單：寫好就不改

流程的起點是兩份由人確認的東西：一份規格，寫清楚每段要長什麼樣子；一份目標清單，列出要做的每一家。程式把它們組合起來，為每一件產生一張工作單。

工作單一旦產生就不能改。執行者不能因為「覺得這樣比較好」就自行調整題目或範圍。如果規格真的有問題，正確的做法是停下來、修規格、重新產生工作單，而不是讓四百個 AI 各自做出不同的詮釋。

每張工作單也指定一個專屬的輸出資料夾。執行者只能在自己的資料夾裡建立或修改檔案，不能碰別人的，也不能執行任何版本控制指令。一件一格、一格一個寫入者，從根本上避免兩個 AI 改到同一份東西。

切成數波，一次只放一波

四百張工作單不會一次全部放出去，而是切成數波，例如每波一百件。調度器一次只處理一波，而且有同時執行的上限，例如同一時間只跑六個，其餘排隊等候。上限依機器的能力和額度來定。

分波有三個好處。第一，錯誤會在第一波就暴露。如果規格有漏洞，最多浪費一波，不會浪費全部。第二，人有喘息的節奏：每一波結束，人看一次結果、拍一次板，再放下一波。第三，成本可控。正式開跑前，我們會先試跑大約十件，算出每件大概花多少時間與額度，再乘上總數，確認負擔得起才放第一波。

舉個例子。第一波跑完，彙整發現有十幾件都卡在同一個地方：規格要求寫出店家的營業時間，但有一類店家只在節日營業，根本沒有固定時間。這不是執行者的錯，而是規格沒想到這種情況。人看到這張卡，補一句規格說明，重新產生剩下幾波的工作單，後面三百件就不會再踩到同一個坑。如果當初四百件一起放，這十幾件會變成五六十件。

調度器本身不做版本提交，也不改任何狀態。它只負責把工作單交給執行者、收回結果、記下誰交件、誰卡住、誰失敗、誰沒有回應。提交和狀態更新留到彙整之後，由總控的工作階段在人拍板後一次處理。

自我回報不算證據

執行者交件前，會先自己跑一次檢查程式，確認產出的檔案存在、字數在範圍內、必要欄位齊全、引用來源足夠、沒有留下「待補」之類的佔位字、沒有多出不該有的檔案。然後它會回報：「我檢查過了，全部通過。」

這句話我們不採信。不是因為 AI 會說謊，而是因為模型的自我描述本來就不是可靠的證據：它可能檢查了錯的檔案、可能誤讀結果，也可能根本沒跑完。所以彙整時，程式會用同一支檢查程式，把每一件重新驗一遍。只有重驗的結果才算數。

檢查程式本身也要能被信任。它是普通的程式，會被放進版本控制、有測試，而且修改它要經過人確認。執行者沒有權限改它，也就不可能為了讓自己過關而放寬標準。

用同一支程式很關鍵。如果執行者用一套標準、彙整用另一套，兩邊的結論就可能不一樣，然後誰也說不清哪個對。標準只有一份，執行者自檢是為了讓它早點發現問題，彙整重驗則是為了讓人可以相信結果。

「我檢查過了」是一句話，不是一個證據。證據是任何人重跑都會得到同樣結果的那一次檢查。

抽審：只找錯，不改稿

機械檢查只能確認格式，確認不了內容對不對。一段介紹格式完美，卻把店家的營業時間寫錯，檢查程式是看不出來的。這時需要第二雙眼睛，但四百件都請人看又太多。

我們的做法是按固定比例抽審，例如每二十件抽一件，交給另一個專門擔任審查的 AI。審查者的任務很窄：從這份產出裡挑幾條事實，試著找出反證。它不負責潤稿，也不能改動原稿，只能另外寫下審查意見。

審查者和作者一定是不同的 AI，而且審查者看不到作者的自我回報，只看產出本身和原始來源。這是刻意的安排：如果審查者先讀到「我檢查過了，全部正確」，它很容易被這句話帶著走，順著作者的思路去讀，而不是獨立去找問題。讓它從零開始讀，才有機會看到作者沒看到的地方。

為什麼不讓審查者直接改？因為一旦改了，就分不清最後的版本是誰的判斷，出了錯也追不回去。意見另存，作者重做時讀得到；原稿保持原樣，紀錄才完整。

抽審的結果也是一個訊號。如果被抽到的件大多數都沒問題，可以比較放心地收下整波；如果抽審退件的比例偏高，代表問題可能不在個別幾件，而在規格或工作單本身。這時整波暫停，交給人判斷，而不是讓 AI 繼續重做下去。

四種狀態，由程式算出來

每一件工作在任何時刻只會處於四種狀態之一：未跑、重做中、通過、待裁決。這些狀態不由執行者自己宣告，而是由彙整程式讀取產出和檢查結果後算出來，再寫成一筆只追加的事件。

判定規則很直接。檢查全過，而且被抽到時審查也通過，就是通過。檢查沒過，而且還沒重做過，就進入重做清單。重做一次之後仍然不過，或者那一波的抽審退件率偏高，就標成待裁決。還沒輪到的件，就是未跑。

重做只有一次。沒過的件會帶著失敗原因回到調度器，例如「引用來源只有兩條」或「營業時間與來源不符」，讓新的執行者知道上一次錯在哪。如果第二次仍然不過，再讓 AI 試第三次通常也沒用，這時該由人來看。

每一筆事件都寫明是哪一件、由哪個執行者或哪支程式寫入、在什麼時間、判定成什麼狀態、根據哪一份檢查結果。事件只追加、不修改；如果某一筆判定後來發現有誤，就再追加一筆更正，而不是回頭改掉原來那一筆。這樣，任何一件的完整經歷都可以從頭到尾讀一遍：何時被放進哪一波、第一次為什麼沒過、重做後由誰抽審、最後由人在哪一張卡上收下。

因為狀態全寫在只追加的帳上，給人看的進度樹與裁決卡都由程式從帳產生，不手寫。人看到的「三百八十件通過、十二件待裁決」，背後每一個數字都能追回到具體的事件。

隔離區與整波收下

就算全部通過檢查，產出也不會直接進到正式資料。它們先進入一個隔離區。隔離區只有一個特性：任何人與 AI 都只能把東西放進去，不能從這裡直接改到正本。

人在這裡看的是一張卡，不是四百份草稿。卡上通常只有三到七項：這一波通過了多少、哪些件待裁決、抽審發現了什麼樣的問題、建議怎麼處理。人用一行字回覆，例如「1 可、2 暫緩」，系統依此把通過的件整波寫進正本，把暫緩的件留在隔離區。

被暫緩或退回的件不會消失。它們留在隔離區，附上退回的原因，可以修改後在下一波重新送審，也可以由人決定放棄。無論哪一種，處理結果都會寫成事件，之後查得到。

這個設計來自一個很實際的觀察：大量工作的瓶頸往往不在 AI，而在人的核准。若每一件都要人逐筆按同意，待核准的清單會越積越長，最後一筆都沒有通過。改成「通過機械檢查的整批收下，人只看例外」，人的注意力才花在真正需要判斷的地方。

那麼，人在這條流程裡到底做什麼？回頭看整條流程，人只出現在三個地方：一開始確認規格與目標清單；每一波之間看一張卡、回一行字；碰到待裁決的件時做最後的判斷。其他時間，人不需要盯著。

這也代表，人做的每一個決定都有份量。規格是人確認的，所以四百個 AI 的方向一致；每一波是人收下的，所以正本裡的每一段都有人負責。AI 處理的是數量，人處理的是判斷。

最後要誠實說明界線。這條流水線的每一支程式都可以用少量範例測試，但真正跑滿數百件，才會遇到某些只在規模上出現的問題，例如額度提早用完、某一類店家的資料特別難找。所以我們把第一波當作試驗，看完結果再決定要不要放下一波，而不是一次放完。

重點回顧

• AI 只做一件；拆單、排隊、檢查、彙整都交給程式，結果每次一樣。
• 工作單寫好不改，每件一個專屬資料夾、一個寫入者，從根本避免互相覆蓋。
• 切成數波、有同時上限，先試跑少量再乘上總數，錯誤在第一波就暴露。
• 自我回報不算證據：同一支檢查重驗每一件，抽審只找錯、不改稿。
• 成果先進隔離區，人只看一張列出例外的卡，整波收下或退回。