把一套自動化決策系統的核心演算法整個重做一次，前後跑了一個月。
以前的做法很像丟飛鏢：把需求丟給模型，等它吐出一堆檔案，看個大概，跑起來沒問題就往前推，真的出事再回頭補。結果最後補東補西，很多 bug 修起來並不難，真正昂貴的是根本不該在那個方向上寫兩週。
這次團隊拆得很明確：人類負責判斷方向、寫 spec、做取捨；快速模型專心寫 code；強推理模型專門 challenge；另一個模型家族只做 review；外部模型（Web AI）負責 deep research。整條流程慢很多，前後拉了一個月，過程明顯從「用 AI 補手速」切換到「帶一個小團隊做開發」。
Phase 0：假設先行，不急著寫 code
手上原本有一個系統在跑，表面上看不差，所以人很容易被現況騙住。每天看著它，會把很多前提默默當成常識。
第一步是先停下來，把那些前提一條一條拆出來，整理成四份問題包，丟給四個外部模型做 deep research。這一步不到一天。回來的報告風格差很多，有的像研究助理，有的像吹毛求疵的審稿人，有的甚至會主動補反例。但它們打到的是同一個洞：原本最被相信的那個設計，藏著結構性風險，靠修小參數解不掉。
方向不確定的題目，先做 deep research 比直接開始寫 code 還是划算太多。寫 code 有產出感，研究沒有，問題是產出感很會騙人。
一天的外部研究，可能擋掉三週的精雕細修。
這裡有個明確偏好：同一個問題寧可看四份彼此獨立的報告，也不要看一份寫得很漂亮的單一結論。要交叉印證，別被流暢敘事說服。外部模型最大的價值剛好在這裡，它們沒有人類已經投入的時間，沒那麼想替原本設計找台階下。
Phase 1：Spec + Challenge Loop
方向翻掉之後，才回來寫 v1 spec。
這次的 spec 沒有追求文筆，結構寫得很硬，不容變更。目標、接受度、資料完整性、邊界條件，全部先寫死。這裡如果寫的不清不楚含糊，後面每個模型都會各自腦補，到頭來還是得收拾殘局。
真正有感的是 challenge prompt。不再叫模型「幫忙 review 一下」，那種 prompt 太溫柔了。改成直接要求它找出會讓這份 spec 失敗的地方，最好附上能驗證的情境和反例。第一輪 challenge 進來，就會知道這次有機會走得比較穩。第一輪下來就抓了十幾個問題，裡面有幾個很深，甚至把狀態機缺的 transition 和可能卡死的位置一起翻出來。
這幾輪修 spec 的過程很像被人拿手電筒照著走路。v1 還在補大洞，v2 開始收緊條件，到了 v3 之後，問題才慢慢從整塊邏輯缺失，縮到邊界案例沒綁緊。前後大概跑了五到六輪，challenge 數量才穩定下來。Spec 上多花的一小時，常常會在後面省掉兩小時 debug。
值得提醒的一條：challenge 太少，不一定是 spec 寫得好。有時候只是 prompt 太弱，或者 reviewer 太客氣。模型會討好使用者，這件事在開發裡很危險。問題問得太鬆，它就會順著講，像個很有禮貌但沒什麼幫助的同事。
Phase 2-3：實作 + 跨家族審查
Spec 收斂到一定程度後，才開始 dispatch 實作。
整體拆成幾個 task，先畫 dependency graph，再決定哪些可以平行。這一步其實是在保護自己的上下文。分工邊界沒切乾淨，後面 merge 的時候，前面省下來的時間會整筆吐回去。
整輪做下來，改了不少檔案。新邏輯其實沒有最麻煩，最麻煩的是它怎麼碰到舊路徑。這也是直接跳過 self-review 的原因。寫 code 的模型剛把新東西接起來，注意力通常都還黏在自己那條線上，很容易漏看相鄰模組被連帶影響的地方。換另一個模型家族進來 review，錯誤分布和視角真的不同。
這一招很快就驗證了。第一輪 cross-family review 馬上抓到幾個 critical issue，而且全都不在新功能本身，而是在舊路徑。少了這層，整段會帶著一種「看起來都通了」的假信心往前走，等到驗證階段再慢慢發現邊角開始掉。
平行開發也踩過很典型的坑。兩個 task 同時碰到相鄰函式，邏輯上都沒錯，合起來卻互相覆蓋。那次 merge 沒有炸得很大，卻足夠提醒：平行 dispatch 不能只靠感覺。哪些檔案會碰到、哪些接口會共享，前面都要先畫出來。
Phase 4-5：驗證 + 監控
寫完還不算結束。
完整驗證跑下去之後才發現，核心邏輯其實沒有大問題，真正拖後腿的是另一個分類元件。它的誤判率偏高，把本來應該保留的情境提早排掉，結果讓主邏輯一直以為自己要再修。沒有把驗證做完整，很可能會在錯的地方多繞一週。
這也是為什麼 canary 那一層需要重視：先小規模上線、監控指標先設好、kill criteria 先寫好、跌破門檻就自動降級。流程先到位，人比較不會在壓力下亂改。系統狀態也刻意分成 Active、Bench、Retired 三桶，讓「先退下來觀察」變成正常動作。
回頭看，時間其實花在別的地方
如果硬拆比例，這一個月大概是這樣：假設驗證 15%、Spec + Challenge 25%、實作 20%、Review + Fix 15%、驗證 + 部署 25%。
這個分配跟以前差很多。以前大概七成時間都卡在 code 和 debug，會誤以為工程本來就該這麼累。現在 review code 本身只佔一成，反而覺得合理。真正花時間的地方，變成確認該不該做、怎麼做、做完怎麼證明它真的可用。
最值得的一筆投資，還是 Phase 0 的外部 deeep research。一天而已，卻直接擋掉了一條錯方向。最意外的收穫，則是第一輪 challenge 噴回來的那十幾個問題。它們如果晚到 production 才爆，修復成本很可能翻十倍。
這套方法不輕。簡單腳本、低風險修補，真的沒必要把流程拉這麼長。但只要題目碰到真資料、真成本、真風險，慢一點常常更便宜。
仍在試的另一條線：Phase 0 只花 15% 的時間就擋掉一次方向錯誤，照理講應該值得多投；可研究一旦做上癮，人也很容易卡進 analysis paralysis。那個停手點怎麼抓，目前還沒有完全滿意的答案。
延伸閱讀
GitHub: https://github.com/p3nchan/orchestration-playbook
本文僅供研究與討論，非投資建議。DYOR + NFA。
小企鵝的經驗
OpenClaw 上 Opus / Sonnet / Codex 三 agent 真的是這樣跑下來的。最有感的兩件事：Phase 0 一天的外部 DR 直接救掉一週實作；challenge prompt 從「幫我 review」改成「找出讓這份 spec 失敗的地方並附反例」之後，第一輪就抓到十幾個 valid issue。Spec 多花的一小時通常會在後面省掉兩小時 debug，這條規律對自己的工作流穩定成立。推薦給大家。
常見問題
Q: 一個人用 AI 團隊真的能開發演算法嗎？
可以，但需要明確的分工和流程。實戰做法：自己負責策略決策和規格撰寫，快速模型負責寫 code，強推理模型負責 review，外部模型負責盲點搜索。關鍵是每個角色只做自己擅長的事。
Q: AI 開發的 Challenge Loop 實際跑起來是什麼樣子？
一份演算法 spec 大概跑 4-6 輪 challenge。第一輪通常抓到好幾個真正的問題，後面幾輪逐漸收斂。重點是每個 challenge 都要附可測試的證據，否則會退化成空轉。
Q: 外部模型 Deep Research 在開發流程中扮演什麼角色？
兩個時間點最值得用外部 DR：開始前驗證假設方向，和收斂後做盲點搜索。一般的 code 開發不需要 DR。
整理：Penna｜小企鵝 Penchan