📍 真實場景
林雅婷，32 歲，新創公司的後端工程師，團隊只有三個人，每月 AI 預算很有限
她正在做一個「自動修 bug」的小工具：丟一個題目進去，希望 AI 自己寫程式、自己跑測試、自己修到通過。
😖 卡住的地方：她試過每次都呼叫一個最貴的大模型，結果同一題有時對、有時錯，很不穩定，帳單也很嚇人。她聽說有人用五個小模型組隊就能贏過單次呼叫大模型，卻不知道這是真的，還是只是行銷話術。
💡 這堂課會拆開 Memdoor 的團隊解題流程：誰負責什麼、怎麼只靠檔案溝通、成績表怎麼讀才不會被騙，最後你還能在瀏覽器裡親手跑一次迷你版。
🧭 這到底是什麼（白話版）
Memdoor 的 team-solve 範例，是把「解一道高難度程式題」這件事，交給五種角色的小模型（小模型參數量比較小、跑起來比較便宜的 AI 模型，這裡用的是 Qwen3.8-27B）輪流處理：一個規劃者、兩個發想者、一個解題者、一個管理者，再加一個修復者。每個角色每次出場都是「全新的腦袋」，不記得前面聊過什麼，只能讀硬碟上的檔案，再把自己的成果寫回檔案。
怎麼知道解對了？不是讓 AI 自己宣布，而是由一支腳本一小段會自動執行的程式，照固定規則做事，不會被說服去跑題目附的範例測資（測資一組固定的輸入和預期輸出，用來檢查程式答案對不對）。腳本說過才算過，AI 的自我感覺良好不算數。整個流程由 8 個 YAML 設定檔（YAML一種用縮排寫設定的文字格式，像是給人讀的清單）描述，不需要寫任何程式碼，也沒有指定要用哪個模型。
實測成績：在作者論文那份 LiveCodeBench Hard 清單的前 10 題上，每題跑 5 次，這套流程平均 9.8 題過關；原作者自己的框架（Harness包住模型的外殼程式，負責給提示、跑迴圈、收結果）是 9.6；Fable 5 單次呼叫則是 8.0。重點不是「小模型比大模型強」，而是「把工作拆開、加上驗證迴圈，小模型可以追上單次呼叫的大模型」。
作者也很誠實地列出限制：只測了 10 題（原作者測 100 題）、題目是 2025 年春季的比賽、模型可能看過、Fable 5 的數字是引用原作者檔案而不是在這個框架裡重跑。所以它宣稱的是「和原作者框架打平」，不是「全面超越」。每次執行成本中位數約 40 分鐘、0.39 美元，50 次共 35.79 美元。注意：原文安裝指令是 Linux/Mac 寫法的 curl 加 bash，Windows 11 沒有 WSL 的話不能直接照貼，需要先確認相容做法。
🎯 為什麼值得你花時間
便宜的零件也能組出可靠的系統每次執行約 0.39 美元，就能在高難度題目上追平原作者框架。這告訴你：與其每題都砸錢呼叫最強模型，不如把流程設計好，讓便宜模型分工並反覆驗證。
「由腳本判決」比「由 AI 自評」可靠成功與否由跑範例的腳本決定。這是工程上很重要的習慣：能用確定性的程式檢查的事，就不要交給會被話術影響的模型來判斷。
學會讀成績表，不被數字騙同一份數據裡，作者自己就列出樣本太小、可能污染、Fable 5 沒在同框架重跑等限制。學會看這些但書，比記住 9.8 這個數字更值錢。
⚙️ 它是怎麼運作的
1
規劃者先拆題規劃者讀題目檔 task.md，寫出一份計畫檔，說明題目的重點與可能的陷阱，然後就離場。
▼
2
兩個發想者各提一種解法兩位發想者各自從全新狀態出發，只讀題目和計畫，各寫一份想法檔。兩個人互相看不到，所以比較不會想出同一種做法。
▼
3
解題者寫出程式解題者讀計畫與兩份想法，寫出 solution.py（從標準輸入讀資料、輸出答案）。
▼
4
腳本跑範例測資一支腳本拿 tests 資料夾裡成對的輸入輸出檔（1.in 對 1.out 等）去跑程式、比對答案，把結果寫成檔案。全部通過就結束（結束碼 0）。
▼
5
管理者讀結果並下指示管理者讀測試結果，判斷哪裡錯、要怎麼修。如果它判斷錯誤（例如編造了不存在的反例），後面的修復就會被帶偏。
▼
6
修復者改程式，回到測試修復者讀程式、結果與管理者意見後改寫 solution.py，再回到腳本測試，直到通過或用完回合。
前 10 題、每題 5 次的過關題數（總分 10）
| 回合 | 本框架（5 個 Qwen3.8-27B） | 原作者框架 | Fable 5 單次呼叫 |
|---|
| 第 1 次 | 10 | 9 | 7 |
| 第 2 次 | 10 | 10 | 8 |
| 第 3 次 | 10 | 10 | 10 |
| 第 4 次 | 10 | 9 | 8 |
| 第 5 次 | 9 | 10 | 7 |
| 平均 | 9.8 | 9.6 | 8.0 |
🛠️ 動手做：迷你版團隊解題：看「只靠檔案溝通」與「腳本判決」如何運作
- 按「下一步」一次，觀察右邊的『虛擬硬碟』多出哪個檔案、下方日誌寫了哪個角色讀了什麼。
- 一路按到完成。你會看到第一版程式有 off-by-one（少算最後一個數）的錯誤，被腳本抓到後由修復者修好。
- 按「重來」，這次勾選「讓管理者捏造錯誤反例」，再一路按到完成。觀察：程式明明已通過，管理者卻編了一個錯的反例，修復者照辦而把對的程式改壞，之後才又被腳本抓出來修回。這就是原文提到的『管理者編造反例』弱點。
- 想一想：如果真正的評分用的是隱藏測資，而流程停在『改壞的那一版』，會發生什麼事？
👇 下面是活的，直接操作
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 為什麼每個角色要用「全新腦袋」、只靠檔案溝通？
資深工程師會把這看成「降低耦合」。如果所有角色共用一長串對話，早期的錯誤想法會一路污染後面的判斷，上下文也越塞越長、越貴越亂。改成每個角色只讀必要的檔案，等於每一步都有清楚的輸入與輸出，出錯時能直接打開檔案檢查是哪一步寫壞的，也能單獨替換某個角色。代價是資訊要靠檔案傳遞，寫不清楚的資訊就會遺失，所以檔案內容的品質變成系統的關鍵。
🔭 為什麼把「成功與否」交給腳本，而不是交給管理者模型？
這是『把不確定的東西關在確定的盒子外面』。模型會被看起來合理的話術說服，腳本只看輸出對不對。原文的失敗案例正好示範了反面：管理者編造了錯誤反例，團隊就把正確程式改壞。這顯示迴圈裡仍有一個『由模型判斷』的缺口。取捨是：腳本只能檢查公開範例，而最終分數看的是隱藏測資，所以範例通過不等於真的正確，這個落差是設計上無法完全消除的。
🔭 9.8 比 9.6 高，能說這個框架比較強嗎？
不能。作者自己寫明兩者在雜訊範圍內，宣稱的只是『與原作者框架打平』。樣本只有 10 題、每題 5 次；模型可能看過這些 2025 年春季的題目；Fable 5 的數字是引用原作者檔案，並非在同一框架重跑；在原作者完整 100 題上，兩個數字也拉近到 92.4 與 90.4。工程思維是：先問『這個差距比量測誤差大嗎』，再問『比較的條件公平嗎』。另外還有一個容易忽略的點：跑在 OpenRouter 這類雲端服務上，結果也不等於本機模型的表現。
📝 隨堂考（點選答案，立即回饋）
Q1. 在 Memdoor team-solve 中，誰最終決定「這題算不算解出來」？
✅ 成功與否由腳本執行範例測資後決定（全過則結束碼 0），不靠任何模型自評。
Q2. 各角色之間是怎麼傳遞資訊的？
✅ 每個角色從全新狀態出發，只靠讀寫硬碟上的檔案溝通。
Q3. 下列哪一項是作者自己承認的限制？
✅ 作者列出樣本小（10 題對 100 題）與可能的資料污染，且跑在 OpenRouter 而非本機。
Q4. 原文中失去的那一題，問題出在哪裡？
✅ 管理者捏造了錯誤反例，團隊據此改寫了原本正確的程式；作者說這是原框架迴圈的缺口，並刻意保留未修。
Q5. 這份成績最正確的解讀是？
✅ 9.8 與 9.6 在雜訊範圍內，宣稱的是與原作者框架打平；Fable 5 一欄是引用原作者檔案、不是在同框架重跑，也沒有任何關於成本倍數的比較。
🃏 翻牌記憶卡（先想答案，再點開對答）
team-solve 的五種（共六位）角色點我翻面
規劃者、兩位發想者、解題者、管理者、修復者；每位都從全新上下文出發，只靠檔案溝通。
誰判定成功？點我翻面
跑範例測資的腳本，全部通過才算過，不由 AI 自評。
9.8 vs 9.6 能說誰比較強嗎？點我翻面
不能。差距在雜訊範圍內，只能說與原作者框架打平。
團隊唯一失敗的那題學到什麼？點我翻面
管理者可能編造錯誤反例，帶偏修復者，把正確程式改壞；迴圈需要保護『已通過的版本』。
每次執行的成本與時間點我翻面
中位數約 40 分鐘、0.39 美元；50 次共 35.79 美元。
為什麼成績要附但書？點我翻面
樣本小、可能資料污染、對照組沒在同框架重跑、迴圈只看公開範例而評分用隱藏測資。