一張 LINE 對話截圖,背後有五個 AI 在接力

我把 LINE 對話製造機那條產線拆開做成一頁,五個角色各自跑了幾秒、被退件幾次、呼叫了哪些工具,全部是真的錄下來的。過程中量出一件難堪的事:把規則寫進 prompt,不代表規則會被執行。

AI 劇組實驗室:一次真實跑程的五個角色與耗時

先講結論:那顆「幫我生一段對話」的按鈕,按下去之後有五個 AI 排隊工作,而它們用不同的模型、有不同的權限,還會互相退件。

AI 劇組實驗室 就是把這條產線拆開的一頁。它是純靜態的,沒有金鑰、沒有即時 API 呼叫,手機看得完。上面每一個數字、每一段劇本、每一次工具呼叫、每一張評分表,都是真的跑過一次錄下來的。

這頁是寫給想自己組多個 AI 的人看的。如果你正打算把一個任務丟給一個模型從頭做到尾,這頁想讓你看到拆開之後長什麼樣,以及每一個分工都是被什麼問題逼出來的。

五個角色,一次跑程

角色 模型 那一次花的時間
編劇 glm-5.2 57.7 秒,寫出 1726 字劇本
評審 openai/gpt-oss-120b 3.2 秒,七項評分,通過 62
執行 openai/gpt-oss-120b 25.0 秒,7 步工具呼叫
美術指導 openai/gpt-oss-120b 為每個待補圖格寫繪圖 prompt
生圖 codex-image 一次生一張格盤,切格交給程式

最右邊那欄是重點:模型不一樣。編劇用貴的、慢的,評審跟執行用便宜快的。

這是整條線的設計主軸,創意跟執行分開。創意要膽子大、要會發明細節,那種模型貴而且慢;執行只要忠實、不出錯、不自作主張,便宜的模型反而更適合。它笨一點是優點,因為你不希望它改劇情。

上游的規則是下游決定的

編劇被限制在 40 則訊息以內。這個數字是下游逼出來的:執行 AI 每批只能填 8 則,劇本太長它就會做到一半停住。

這種事只有把整條線攤開才看得到。一個模型從頭做到尾的時候,這個限制根本不存在,它會安靜地在某個長度以後開始出錯,而你只會覺得「這個模型不太行」。

同樣的邏輯還有一條:一句描述變成一張圖,中間有八步,只有兩步是 AI。編劇寫下「[圖片:…]」,執行把它放進 imgDesc,程式收集待補圖清單,planGrid 決定盤面要 2×2 還是 3×3,美術指導寫每格的繪圖 prompt,程式串成一道格盤指令,生圖一次,程式切格去背回填。能寫死的絕不交給模型。

切格那一步直接引用 LINE 對話製造機 自己的 pure.js,每邊內縮 8% 讓開白色分隔線。去背則是看類型不看顏色:貼圖是綠幕所以去背,照片不去背。理由很實際,照片背景剛好是公園草地的時候,四個角落一樣是綠的,去背會把整片草挖掉。

評審回的是 JSON,不是感想

七項各 0 到 10:劇情弧、角色聲音、形式運用、節奏、真實感、情境合理、傳播力。通過條件寫死在程式裡,total>=56 而且每一項都要 >=6,滿分 70。

「我覺得還不錯」沒有辦法讓程式決定要不要重跑。要能自動迴圈,判斷就必須是結構化的。

那第七項「情境合理」是後來加的,加的過程才是這篇最有用的部分。

加一條標準之前,先量它值不值得

有人指出一份已經通過的劇本裡,兩個人明明坐在同一張桌子,卻互相傳自己盤子的照片。原本六項裡沒有一項在問「這件事說不說得通」。

直覺反應是馬上加一項。我先量了。

同一份劇本、同一個評審跑六次,現行版只抓到三次。所以問題不只是少一項,是判決本身會飄。接著 A/B 各跑六次,另外拿一份在舊六項制下拿 54/60 的好劇本當對照組,看新規則會不會誤殺好稿:

版本 抓到問題 誤殺好稿
原本六項 3/6 0/6
加第七項「情境合理」 5/6 2/6
再加一句「沒硬傷就給 8 以上」 6/6 4/6

第三版很有意思。那句話字面上是要它放寬,實際效果是讓它更用力去找問題,抓到率衝到滿分,代價是四成好稿被退。

最後採用中間那一版。這件事的教訓不在於哪一版比較好,在於「加一條評分標準」這種聽起來零成本的動作,其實有代價,而代價量得出來

把規則寫進 prompt,不代表規則會被執行

評審的 prompt 裡寫死了一條:草稿寫成對方的台詞,real 不得超過 3 而且 pass=false

我餵它一份故意踩這個陷阱的劇本。它在意見欄裡把問題講得一清二楚,知道哪裡錯、也知道該怎麼改。然後分數給了 real=6,通過。

它看得懂規則,就是沒有執行。真正該擋的東西要用程式碼擋,不要指望模型自律。

還有一次更難看。評審回的東西 JSON.parse 失敗,程式印出「採用目前劇本」就放行了。fallback 本身是對的,總不能因為裁判壞掉就交不出東西,但那一次等於完全沒有評審。這是拿語言模型當裁判的固有成本,得先想好它壞掉的那次怎麼辦。頁面上「評審壞掉時」那個範例,就是這一次。

資料是怎麼錄的

錄製的做法是在頁面腳本執行前包住 window.fetch,把每一次對代理的請求跟回應原樣存下來。沒有改 LINE 對話製造機一行程式碼。

評審那支基準測試的 system prompt 也直接從線上的 ai.js 抽出來,沒有手抄。人家哪天改了,這邊跟著變,不會出現「文件寫的跟實際跑的不一樣」。

頁面上那支可以捲、可以逐則播放的手機,用的是這個工具自己的「嵌入 HTML」功能,不是截圖。純文字那幾次只有 13 到 19 KB,比長截圖的 200 到 300 KB 還小。

順帶一提,做這個 repo 的時候撞出 LINE 對話製造機一個 bug:工具 schema 沒有宣告 imgDesc,所以劇本裡的圖片描述在交接的時候掉了,美術指導只好自己編。已經修掉了,錄製檔還留在 record/ 裡可以對照修好前後。

分工線

點子、要拆成幾個角色、每一條評分標準要不要加、什麼叫做「量過了」,是我定的。頁面、錄製腳本、基準測試、那些測試,是 AI 寫的。A/B 那組數字是真的跑出來的,不是估的。

想看的話,AI 劇組實驗室 打開就是,手機也讀得完。原始碼跟錄製檔在 https://github.com/yazelin/ai-crew-lab。想先看它拆的是什麼東西,工具本身在 https://yazelin.github.io/line-chat-maker/,那顆按鈕怎麼教出來的寫在這裡:教一個 AI 小劇組寫出「值得截圖」的對話