5秒結論
真正快的AI，不是最快回覆的AI，而是讓整個專案更少返工、更早完成的AI。
一套內容生產系統在幾天到約一週的集中改造中，從「讓AI寫文章並存檔」升級成具備監控、復原、併發控制、checkpoint、壞工作隔離、品質閘門與證據管理的小型自治工廠。
大型架構改造時，除了讓GPT-5.6 Sol進行深度推理，還使用能協調多個agent平行工作流的ultra。單次執行比較重，但可以減少「先做→發現結構錯誤→重做→重測→再發現競態條件」這種返工地獄。
用製造業的話說：單次節拍可能較慢，但返工率下降，所以總交付時間反而更短。
先說清楚：Level 6和Level 7不是業界通用標準
本文的Level 6與Level 7是這套系統用來說明成熟度的內部標籤，不是ISO等級。
思想背景接近IBM長期研究的autonomic computing，也就是系統能自我設定、自我修復、自我最佳化、自我保護。
本文把自動回到已定義正確狀態的階段叫Level 6，把在硬性安全與品質限制內主動尋找更好運轉策略的階段叫Level 7。
一開始只是「叫AI寫文章」，結果部落格長出了fencing
簡單自動化通常就是排程、AI生成、存檔、推送，失敗再由人處理。
但加入多語言、品質稽核、內部連結、更新、發布判定後，真正的問題變成：兩個worker同時改同一篇怎麼辦？中途掛掉從哪裡恢復？壞資料會不會永遠重試？舊稽核會不會冒充新證據？AI會不會捏造「人工已審核」？外部服務掛掉後，本地安全生產能不能繼續？
這時候它已經不是單純的部落格工具，而是以內容為原料的小型生產系統。
Level 6：壞掉後，自己回到已知正確狀態
Level 6的核心是：目標狀態已定義，系統持續比較現在與目標，發現偏差就修復。
主要機制包括desired state、reconciliation loop、lease/fencing、正式checkpoint、CAS、transactional outbox、有限retry、quarantine、安全發布閘門、failure injection與observability。
某次運轉快照中，Level 6的21項實作要求全部PASS，控制實作分數為100；但包含外部量測、人工證據與長期健康度的assurance只有約69%，發布仍HOLD，Level 7也還是OFF。
這代表：程式實作100分，不等於長期無人看守也有100分把握。
深度Sol與Ultra：一位高手長考，和多位高手平行作業
OpenAI把GPT-5.6 Sol的max描述為更深的推理設定，而ultra用來協調多個agent的平行工作流處理複雜任務。
深度Sol像是把整個repo和需求交給一位很強的工程師，給他足夠時間思考。
Ultra則像架構師、實作者、測試者、批判者，以及專門負責「把它弄壞看看」的人同時工作，最後整合結果。
不是單純智力翻倍，而是不同方向的盲點可以同時被攻擊。
OpenAI公開的Terminal-Bench 2.1結果中，Sol為88.8%，Sol Ultra為91.9%。看失敗側是11.2%與8.1%，在該評測上約少28%的失敗。這不代表任何專案都能少28%的bug，但能說明多agent平行工作對複雜、可拆分任務的價值。
為什麼更重的Ultra反而可能更快
比較實際的公式是：
總交付時間 = 首次實作 + 返工 + 重測 + 故障復原 + 需求誤解修正
只看首次實作，30分鐘當然比2小時快。但如果2小時版本省掉後面6小時重構，它才是真正更快。
這就是品質工程。高速生產一堆不良品，再在終檢丟掉，不叫真正的高效率。
這次「Ultra一拳」後的工作，大多是在加強證據與可觀測性，而不是推翻核心架構。例如證明每個worker真的處理過資料、禁止舊稽核歷史冒充新進度、區分AI審核與人工審核、沒有外部證據就標UNKNOWN、正確NOOP不能當失敗。
比較像是QC團隊進入已蓋好的工廠，把每個儀表重新校正。
為什麼第一拳撐得住
不是一拳完美，而是一開始就把併發衝突、中途死亡、舊worker延遲寫入、外部API故障、無限重試、檢查器本身壞掉、假成功等問題放入設計，所以後續修正沒有變成全面重做。
Chaos Engineering也強調：先定義可量測的穩態，再故意注入真實世界的故障，看系統是否還能保持穩定。
白話版就是：先讓測試哭，不要先讓正式環境哭。
放到現實世界，大概在哪裡
它明顯比普通AI文章生成、線性Zapier/n8n自動化成熟，因為已處理併發、復原、狀態一致性、證據與故障隔離。
和認真做的個人SaaS後端、小公司內部自動化平台相比，很多設計議題已經在同一個層次。
但和有專職SRE、安全團隊的成熟商業服務相比，仍缺長期運轉歷史、獨立安全驗證、大規模負載證據與真實使用者影響量測。
至於Google或Amazon級基礎設施，規模完全不同，不必硬比。
個人專案真正少見的地方，不是AI會寫文章，而是為了「失敗時怎麼辦」長出了這麼多工程結構。
Level 7：工廠經理開始做受控實驗
Level 7會同時量品質、速度、成本、延遲、積壓時間與失敗率；安全規則不能被optimizer修改；新的prompt或工作順序先在shadow測試；表現更好才用canary逐步擴大；品質下降就自動rollback；可靠性不好時只暫停實驗，已驗證的正常生產繼續；每次實驗都留下假設、基準、結果與回滾點。
它和IBM的self-optimization、Google SRE的error budget、canary/rollback實務很接近。
但現在不必急著開完整Level 7。Level 6還在累積長期實績。如果一邊驗證穩定性，一邊又讓optimizer自動改策略，故障會更難追。
目前更有價值的是：把所有worker的真實執行證明整合到一張操作台帳。
把付費月份當成「設備投資月」
Ultra不需要拿來做每天的小修改。固定worker、重複稽核、小patch，普通Sol或深度推理往往就夠。
Ultra最適合系統重設計、大規模重構、worker拓撲調整、復原設計、安全邊界、shadow實驗框架、大量故障注入這類「開頭做錯，後面返工很貴」的工作。
平常穩定生產，把高槓桿改造項目存起來，在能使用最強模式時集中做一次設備投資，反而更合理。
約一週最大的收穫
實務AI能力不只是答對率。初始架構品質、自我反駁、平行作業、真實執行證據、故障復原都非常重要。
好的自治工廠不是永遠不失敗。
它應該預期失敗、不製造假成功、讓安全工作繼續，並能回到已驗證狀態。
結論：速度是到終點的時間
約一週的大幅進化，關鍵不是AI單純寫程式很快，而是把強推理與平行能力集中在最昂貴的初始設計決策，日常生產再回到較便宜穩定的模式。
Ultra比較像提前花成本消滅未來返工，不是魔法正解按鈕。
單次比較慢，但整個專案更早完成，那才是真正的快。
參考資料
- OpenAI GPT-5.6: https://openai.com/index/gpt-5-6/
- IBM Research Autonomic Computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- Google SRE Error Budget: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS Canary Deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
