一張 LINE 對話截圖，背後其實有五個 AI 接力：編劇、評審、執行、美術指導、生圖。 這頁把那條產線拆開，用真的錄下來的跑程逐步重播：每個角色說了什麼、花了幾秒、被退件幾次、工具呼叫了幾次，都是實際發生過的。 不需要金鑰，手機也看得完。
拆的是 LINE 對話製造機，一個做 LINE 風格對話截圖的網頁工具。 你在上面打一句「深夜曖昧」，按兩個按鈕，它就生出一整段有起承轉合的對話畫面。
那兩個按鈕背後有五個 AI。它們用不同的模型、被賦予不同的權限，彼此還會互相退件。 這頁講的是為什麼要拆成五個，以及每一個分工都是被什麼問題逼出來的。
同系列還有 隱形浮水印實驗室，拆的是同一個工具的另一半：它怎麼在每張匯出的圖上烙隱形標記。
下面五次都是真的跑過的。每一次都是為了看到某件事，不只是換個主題：
看那張表最右邊一欄：模型不一樣。編劇用貴的、慢的（GLM-5.2，十幾秒），評審和執行用便宜快的（gpt-oss-120b，一兩秒）。
這是整條產線的設計主軸：創意跟執行分開，省錢只是順帶。 創意要膽子大、要會發明細節，那種模型貴而且慢；執行只要忠實、不出錯、不自作主張，便宜的模型反而更適合。 它笨一點是優點，因為你不希望它改劇情。
它拿到的只有一句主題，人物、起因、轉折、結局都要自己發明。
最值得學的一條規則，長得像美學偏好，其實不是。編劇的 prompt 裡寫著：
總長 40 則訊息以內，甜蜜點是 20 到 30 則。這不是美學偏好：執行 AI 每批只能填 8 則、每批要花掉數輪迴圈，劇本超過 40 則就會做到一半停住，使用者只看得到半成品。
上游的創作規則，是被下游的執行能力決定的。這是多 agent 系統最反直覺、也最實用的一課： 你不能只設計每個 agent 自己，你要設計它們之間的交接介面，而介面的規格往往由最弱的那一環決定。
另外一條同樣有意思：劇本裡不准有旁白、內心獨白、鏡頭描寫。因為觀眾最後只會看到一張截圖， 截圖上出現不了的東西，寫了就是浪費。「劇情裡有人傳了一張圖」→ 那張圖本身要變成一則訊息，不能只用文字說「那張圖」。
編劇寫完不會直接送出去，要先過評審。評審回傳的是機器讀得懂的 JSON：六項分數、通過與否、以及具體的修改意見。所以這個迴圈是程式在跑的，不用人看。
七項標準，各 0–10：劇情弧（arc）、角色聲音（voice）、形式運用（form）、節奏（pacing）、真實感（real）、情境合理（logic）、傳播力（share）。
通過條件：總分 ≥ 56 而且 每一項 ≥ 6。單項不能被其他項救回來，這是刻意的： 一份「劇情很讚但完全沒用到貼圖」的劇本不該過。
不通過就把 feedback 丟回編劇改寫，最多三輪；三輪都沒過就採用分數最高的那一份。那個 fallback 本身就是設計決策：寧可交出一份不夠好的，也不要交不出東西。
「情境合理」是後來才加的第七項，因為原本六項沒有一項在問「這件事說不說得通」，real 查的是「像不像真人打字」。加它的過程寫在下面。
「一般情況」那一次跑在加上它之後，分數是 x/70、有「合理」那一欄；另外兩次錄得比較早，是 x/60。
下面四份劇本，其中兩份踩到了評審 prompt 裡寫死的陷阱。你先打分，再看真評審給了多少。
劇本定稿之後，交給執行 AI。它的工作只有一件：把劇本忠實填進腳本 JSON，不准改劇情。
它拿到四個工具（apply_script、append_messages、get_script、gen_image），畫面隨著它每一次工具呼叫即時更新。
下面是真的那一次的每一步。按「下一步」看它怎麼把腳本一批一批填出來，注意左邊那個 tool_choice 標籤。
那個 required／auto 的交替，是三個反偷懶機制在運作。語言模型很愛回你「好的，我將會：1. 先設定人物…」然後什麼也沒做。
tool_choice: required）：這一步不准講話，只能動手。auto）：每動過腳本，就要求它回頭檢查自己剛才改了什麼。這一步允許它講話，因為這一步的產出就是判斷。所以 required 和 auto 交替出現不是隨機的：required 是「做」，auto 是「檢查」。
劇本裡的 ［圖片：海邊夕陽］ ［貼圖：抱抱的熊］ 到這一步才變成真的圖。
這裡有兩個角色：美術指導（文字模型）決定每一格要畫什麼，生圖模型負責畫。
| 誰做的 | 做什麼 | |
|---|---|---|
| 1 | 編劇 | 在劇本裡寫 ［圖片：一盤擺盤精緻但份量極少的松露野菌燉飯］，描述要具體到畫得出來 |
| 2 | 執行 | 轉成腳本 JSON 時，描述放進該則訊息的 imgDesc 欄位，img 先留空 |
| 3 | 程式 | 掃一遍腳本，把「有 imgDesc 但還沒有圖」的訊息收集成待補圖清單；沒有頭像的人物也一起排進去 |
| 4 | 程式 | planGrid 依格數決定盤面：4 格以內 2×2、9 格以內 3×3、再多 3×4 |
| 5 | 美術指導 | 為每一格寫繪圖 prompt，限 80 字，還要維持人物在不同格之間長得一樣 |
| 6 | 程式 | 把每格 prompt 串成一份格盤指令：「一張 N×N 等分網格圖，格與格之間用粗白色分隔線…」 |
| 7 | 生圖 | 只呼叫一次，回來一張格盤圖 |
| 8 | 程式 | cellRect 切格（每邊內縮 8% 讓開分隔線）→ 貼圖用 chromaKeyData 去背 → 依清單順序回填 |
八個步驟裡，只有兩步是 AI。其餘六步全是程式：收集清單、決定盤面、串指令、切格、去背、回填。 這條產線的設計邏輯很清楚：能寫死的絕不交給模型。
為什麼要湊成一張格盤，而不是叫六次？省掉五次呼叫是其一，更重要的是一致性： 同一次生成裡，那位女生在三張照片裡是同一個人；分六次叫，你會拿到六個不同的人。
為什麼切格要內縮 8%？格盤指令特地要求「格與格之間用明顯的粗白色分隔線」，那條線是畫給模型看的邊界，本身不是內容。
cellRect 每邊各退 8% 把它讓開。少了這一步，每一格都會帶著白邊。
為什麼只有貼圖去背？貼圖的 prompt 都指定「純綠背景」，那是綠幕；chromaKeyData 從四角取綠的中位數、
算色距、羽化邊緣、再壓一次邊緣綠溢。但這件事不能靠顏色自動判斷：照片的背景剛好是公園草地時，四角也是一片綠，
去背會把整片草挖掉。所以要不要去背，是看這一格當初被派的是什麼類型，不是看它長什麼顏色。
切格與去背的程式碼是直接引用 LINE 對話製造機的 pure.js（vendor/lcm-pure.js），不是重寫一份。
合成一個「什麼都做」的 AI 不行嗎？把這些分工一個一個拿掉，看會發生什麼事：
| 如果不這樣分 | 會發生什麼 |
|---|---|
| 編劇與執行不分 | 要嘛你用貴模型做資料輸入（燒錢），要嘛你用便宜模型寫劇本（乾）。更糟的是，同一個模型邊填邊改劇情，你會拿到一份跟定稿不一樣的東西。 |
| 沒有評審 | 第一版就出貨。下面那個 19/60 的例子就是第一版長什麼樣：寒暄問答、沒有起伏、沒人想截圖。 |
| 評審不回 JSON | 「我覺得還不錯，可以再生動一點」，程式沒辦法拿這句話決定要不要重跑。要能自動迴圈，判斷就必須是結構化的。 |
| 沒有強制工具 | 模型回一份漂亮的計畫，畫面一動也不動。使用者看到的是「AI 說做好了但什麼都沒發生」。 |
| 美術指導與生圖不分 | 生圖模型不懂劇情脈絡；文字模型不會畫。中間需要一個把「劇情需要什麼圖」翻成「畫面該長怎樣」的角色。 |
每一個分工，都對應一個真的踩過的坑。這些分工是出過事之後才補上的，一開始並沒有架構圖。
評審沒有執行自己 prompt 裡寫死的規則。評審的 prompt 白紙黑字寫著：草稿（draft）寫成對方的台詞而不是「自己」的，real 不得超過 3 且 pass=false。
我特地寫了一份踩這個陷阱的劇本餵給它。結果：它在意見裡把問題講得一清二楚（「應該是阿凱自己在手機上輸入的文字，觀眾不會看到對方的打字畫面」）， 但分數給了 real = 6，不是規則要求的 ≤3。
把規則寫進 prompt ≠ 規則會被執行。它讀懂了，也講對了，就是沒照著算分。這次它靠總分還是把劇本擋下來了，但那是運氣不是機制。 如果其他五項夠高，這份劇本會過關。真正該擋的，要用程式碼擋，不要指望模型自律。
評審的回覆偶爾解析不出來。六次跑程裡有一次，評審回的東西 JSON.parse 失敗，程式印出「評審回覆無法解析，採用目前劇本」就放行了。
那個 fallback 是對的，不能因為評審壞掉就讓使用者拿不到東西。但也要誠實：那一次等於沒有評審。 這就是「用語言模型當裁判」的固有成本，你必須為它壞掉的那次先想好要怎麼辦。
加一項標準之前，先量它值不值得。有人指出一份通過的劇本裡，兩個人明明坐同一桌，卻在互傳自己盤子的照片。 評審放行了，因為原本六項沒有一項在問「這件事說不說得通」。
但直接加一項之前先量：同一份劇本、同一個評審、同一個模型跑六次，現行版抓到三次。 所以問題不只是少一項，是判決本身會飄。A／B（各六次，另拿一份 54/60 的好劇本當對照組）：
| 評審版本 | 抓到該退的 | 誤殺好的 | 回覆解析失敗 |
|---|---|---|---|
| 原本六項 | 3/6 | 0/6 | 3 次 |
| 加第七項「情境合理」 | 5/6 | 2/6 | 0 次 |
| 再加一句「沒硬傷就給 8 以上」 | 6/6 | 4/6 | 0 次 |
第三版是反直覺的地方：我以為叫它「沒問題就給高分」可以壓低誤殺，結果相反：那句話沒讓它變寬鬆， 是讓它更用力去找問題，誤殺翻倍。最後採用中間那版：誤判只是多跑一輪重寫，漏判是直接出貨一份有邏輯洞的劇本。
這頁的數字全部來自真實跑程，錄製方式是攔截 fetch、把每一次對代理的請求與回應原樣存下來，
沒有改 LINE 對話製造機一行程式碼。所以你看到的就是使用者真的會遇到的東西，包含它出錯的樣子。
這裡沒有一塊是新發明的，都是這兩年被反覆驗證的做法。列出來是因為你可以直接去讀：
| 這條產線用的 | 它的通用名字 |
|---|---|
| 編劇寫、評審打分、不過就改寫 | LLM-as-a-judge 與 generator–critic 迴圈。用一個模型評另一個模型的輸出，是目前最常見的自動品管做法，也早就有人量過它的偏誤（會偏好長的、偏好自己寫的）。 |
| 執行端只能透過工具改東西 | tool calling / function calling。模型不直接吐結果，而是呼叫你定義好的函式；能不能改到東西由你的程式決定，不是模型說了算。 |
| 強制工具、只回文字就踹回去、改完自審 | agent 迴圈的常見補丁，不是誰的專利。語言模型很愛回「好的，我將會…」然後什麼也沒做， 所以幾乎每個做 agent 的人最後都會做出同一組東西：強制它呼叫工具、只回文字就退回去重來、 設一個輪數天花板、動過資料就要求它回頭自審。 |
| 一次生一張格盤再切開 | 把確定的部分交給程式、不確定的部分才交給模型。同一個哲學在隱形浮水印實驗室裡也出現過。 |
這條產線自己的部分是取捨：哪個角色配哪個模型、40 則的上限、通過門檻定在 48、三輪不過取最高分、迴圈上限 30。 這些數字沒有一個是理論推導出來的，都是撞出來的。