第一步不是寫程式，
而是確認要解決什麼。
人：26 決定需求與取捨 ／ 對話入口：GPT-6 Astra ／ 框架主控：GPT-6 Sol
「幫我做一個報名功能」可以有很多種答案。先寫下來，才能分辨 AI 做的是你要的功能，還是它自己想像的功能。
在這套方法裡，主控負責把自然語言整理成可交辦的要求：要做什麼、不做什麼、依據哪些資料，以及怎樣算完成。有歧義就追問；需要人決定的取捨，留給 26，不讓模型偷偷代選。
以「不要重複報名」為例
- 要達成什麼？
- 同一個人對同一場活動，只能有一筆有效報名。
- 怎樣算做對？
- 連按按鈕、重新整理或再次送出，都不能多建立一筆。
- 還不能自己猜什麼？
- 取消後能不能重報？額滿後怎麼辦？這些要先確認。
原文的四行工作卡，也是在做這件事。軟體開發會再加上可改動的範圍與禁止事項，例如「先在測試環境完成，不碰真實報名資料」。
不是每件工作，
都值得動員整支隊伍。
主控配置：GPT-6 Sol ／ 小型工作配置：GLM 5.3 Flash、GPT-5.3 Codex Spark
主控先判斷：這件事難在寫出答案，還是難在檢查？做錯了能不能安全重做？會不會直接改動資料、權限或正式服務？
簡單而可驗證的工作可以走短路線。需要跨模組理解的開發，才加上獨立審查。真正涉及高風險行為時，則要提高施工前後的檢查強度。
看的是這次要做的動作，而不只是整個專案的名字。 在隔離環境測試一段報名邏輯，不等於現在就把它放上正式服務；反過來，只改一行權限設定，也不能因為「只有一行」就算低風險。
想多懂一點：短流程是否代表省略品質？
不是。Fast Path 指低風險、可逆、可測的工作採較輕的處理方式；Hard Path 處理需要更嚴格治理的工作。證據不足則先阻擋。這個風險判斷與上方的角色路線有關，但不是同一份分類表，也不是用「Fast」取代原本明定的驗收要求。
施工者要交出程式，
也要交出檢查它的方法。
主要施工配置：Kimi K3 ／ 額度耗盡轉 Sol：已同意方向，尚未接入自動備援
動工前，一般開發、複雜與高風險路線還有 Opus 5.5 的規劃建議旁路。這次先聽設計建議，不能取代完工後的獨立審查。
施工者（Builder）負責寫程式、整合功能與修正問題。但交付不能只是一句「我寫好了」；還要讓下一位接手者能看見改動、跑得動測試，並知道有哪些限制。
測試可以理解成讓電腦反覆檢查的題目。以重複報名為例，題目不是「這段程式看起來合理嗎」，而是「把同一份報名送兩次，最後是否仍只有一筆」。
測試先行的做法，是先讓這道題目在功能尚未完成時失敗，再補上程式，直到它通過。這能幫助確認測試真的碰到問題，而不是永遠都亮綠燈。
想多懂一點：為什麼還要保留修改版本？
假設審查者看的是昨天的程式，但施工者今天又改了一段，昨天的通過就不能直接套用。保留版本，是為了讓「哪份程式被哪次檢查確認過」對得起來，不是為了多留一份漂亮報告。
能讓電腦直接核對的，
就不要只靠 AI 點頭。
這一站不是模型：由測試與固定程式執行
檔案存在嗎？資料格式正確嗎？測試有沒有真的跑完？送出的版本是否和被檢查的版本一致？這類條件能用程式核對，就先讓程式處理。
這些檢查的優點不是「永遠不會錯」，而是規則明確、可以重跑，也容易知道卡在哪裡。它們幫忙擋掉明顯問題，讓後面的審查者把注意力放在需要理解的部分。
測試通過仍有邊界。 只測過正常點一次按鈕，不能證明兩個請求同時抵達也安全；測試題目沒涵蓋的情況，不會因為畫面全綠就自動得到保證。
另一位接手者，
要有理由說「這裡還不行」。
複雜／高風險路線的審查配置：Claude Opus 5.5
審查者（Reviewer）重新對照需求、程式與證據，不是把施工者的說明換句話說。它要問：做的真是要求的功能嗎？測試漏了什麼？失敗時會留下不一致的資料嗎？
延續報名的例子，兩次請求可能同時查到「尚未報名」，然後各寫一筆。程式有「先查再新增」，不代表一定防得住重複。這是需要理解整段行為的問題。
高風險路線另有兩種分工：施工前挑戰方案，先問設計是否有根本盲點；施工後找破口，特別檢查異常情境與安全假設。它們不是讓每件工作多排兩道隊，而是用在指定路線。
展開角色名冊：誰負責什麼，誰不能批准什麼？
以下來自本次核對的角色契約。這是分工配置，不是每條路線都已實跑的證明，也不表示每次工作都會叫齊這些模型。
- 對話入口
GPT-6 Astra - 協助26釐清需求、確認方向與授權；不是框架契約中每次必跑的正式角色節點。
- 主控
GPT-6 Sol - 界定範圍、選路線、整理證據與裁決；不能以自己的判斷取代需要 26 的上線授權。
- 小型工作
GLM 5.3 Flash - 處理小範圍、低風險且可明確檢查的工作。
- 快速工作
GPT-5.3 Codex Spark - 處理規格清楚、容易驗證的快速工作。
- 主要施工
Kimi K3 - 撰寫與整合程式；自己的完工宣告不是獨立審查。
- 施工前規劃建議
Claude Opus 5.5 - Standard／Complex／Critical 的建議旁路配置。唯讀、沒有正式審查票權；不能拿規劃建議當成完工程式已通過。
- 條件式第二意見
Claude Fable 5.1 - 重大架構、歧義、發布規則、Opus 不可用或意見分歧時明確升級的建議旁路；無正式審查票權。不是每次都必跑。
- 獨立審查
Claude Opus 5.5 - 審查程式是否合格。CODE_VOTE 表示程式審查意見，不是發布或部署許可。
- 前置挑戰
Claude Fable 5.1 - 高風險路線在施工前必經。NO_VOTE 表示沒有正式審查投票權，但重大問題仍會阻擋施工。
- 找破口
DeepSeek V4 Pro 0813 - 高風險路線檢查致命破口、看似安全的假設與證據缺口；不是上線批准者。
- 最後授權
26 - 在需要人工決策或真實副作用的邊界，確認是否允許執行。這不是替所有技術檢查背書。
不同模型有機會提供不同視角，但不是換個品牌就保證不會一起犯錯。若大家拿到的需求本來就錯，分工再整齊，也可能一起把錯誤做得很完整。
「通過了」之後，
還有幾件事不能混在一起。
主控整合證據 ／ 26 確認需要人工決定的部分
各段程式都測過，不表示串起來一定能用。最後還需要按使用者真正會走的方式確認：按鈕是否觸發正確行為、資料是否確實寫入、重做是否產生重複，以及失敗時能不能知道發生什麼事。
- 功能通過檢查表示某個版本在已檢查的範圍內符合要求，不代表所有情況都已排除。
- 獲准放上正式服務表示 26 同意指定操作；不是拿任何一份舊批准，就能執行後來改過的版本。
- 正式服務確實在使用需要確認實際執行狀態，不能只看檔案已複製過去。
- 文件與使用說明完成接手者要知道現在怎麼操作、哪些限制仍在。程式完成與文件收尾是兩件要分別確認的事。
這也是 26 的流水線比一般批次資料整理更在意的邊界：「做對了」和「可以真的執行」不是同一張許可。
如果執行結果不明，為什麼不能直接重試？
畫面沒有回應，不等於後端沒做事。若第一次報名其實已成功，直接重送可能再做一次。需要先查紀錄、讀回狀態，或使用可避免重複的機制，再決定怎麼續接。不是所有錯誤都適合盲目再按一次。
有很多關卡，
不等於整條線就很順。
介紹方法，也必須介紹它的代價。這不是一條已經證明最省錢、最快、全自動的流水線。
說明書可能落後於配置。
準備這篇文章時，直接比對就發現：不同說明文件對角色分工的寫法不一致。這不直接證明執行出錯，卻會讓接手者先花時間找正本。26 已要求統一說明；本文不把「已交辦」寫成「已全部修好」。
準備審查，也可能變成負擔。
把版本、測試和交接材料整理清楚，本來是為了減少錯誤。但如果每次都要模型手工重做固定格式，準備工作就可能擠壓真正施工。流程是否值得，要看它幫忙完成了什麼，不能只看材料有多齊。
還不能只憑感覺說「比較划算」。
要知道多一層審查值不值得，得看它多抓到了什麼、減少多少返工，以及一份合格成果的總投入。目前這篇沒有提供足以比較不同路線的完整實測資料，因此不作節省成本或提高成功率的數字宣稱。
工程限制：角色分開，還不等於所有證據都已接好。
目前讀到的流程文件也明列：契約能把施工者與審查者指定為不同角色／模型，但現有證據鏈尚未把實際施工輸出的紀錄完整接到審查對象，不能因此宣稱產物作者身分已獲完整證明。
這個差別很重要。「規則要求分開」與「每次執行都能機械證明分開」是兩個層次。本文介紹前者與其檢查要求，不把尚未封閉的證據缺口藏起來。
共同的方向，
不是讓更多 AI 上場。
原文強調把工作說清楚、讓錯誤能定位、能局部修正，最後再看成果與投入。26 的開發方法沿著相近的方向，再加上軟體版本、實際副作用與人為授權的邊界。
但軟體功能會互相牽動。改好一個檔案，不代表只需要測那一個檔案。因此，「局部重做」放到這裡，應該理解成：只改必要範圍，但檢查必須涵蓋受到影響的行為。
而是讓成果真的往前走，
也讓人知道何時必須停下。
這份分享想留給原作者的交流問題是：當工作不再是彼此獨立的資料，而是互相牽動的程式時，怎麼保留有用的檢查，又不讓交接成本吞掉分工的好處？
這也是 26 這套流程仍要用實際交付回答的問題。
哪些是來源，哪些是示意？
- 交流起點：〈不用最貴的模型，也能把大型 AI 任務做好嗎？〉。其商品案例為教學重製情境，並非受控效能實驗。
- 本文分工：來自本次核對的 26 正式角色契約、主線模板、規劃旁路模板與近期變更決策。主線、建議旁路及待完成項目分開呈現。私人原始文件不隨本文提供；本文不是公開可重現的效能研究。
- 實際觀察：說明文件與配置存在分工版本差異。統一修正是否完成，不在本文宣稱範圍。
- 教學示意：重複報名情境用來解釋需求、測試與審查，不代表某項功能已經完成、通過或上線。
- 製作方式：依 26 訪談確認的方向，由 AI 協助查核、撰寫與製作 HTML；經 26 授權於微光官網刊登。
模型名稱是內部分工標籤，不是能力排名、產品推薦或供應商認證。配置可能改動；單次執行仍須另看實際證據。