5秒看結論
AI自動化真正有用的地方，不是單次回答快，而是做到最後返工少。
有一套文章生產系統，經過幾天到一週左右的集中改造，從「讓AI寫文章再存起來」的簡單裝置，變成了一座具備監控、重跑、衝突控制、中途存檔、故障隔離、品質關卡和證據管理的小型自主工廠。
這次大改造裡真正起作用的，不只是讓GPT-5.6 Sol深度思考，而是在大型設計變更一開始就啟用能讓多項任務平行推進的ultra。
跑一次確實很重。但事後「這裡原來是壞的」「平行執行出事故了」「沒有證據」「又得全部重來」這類事會少很多，總時間反而變短。
用工廠的話說就是：單個週期時間很長，但返工率低，所以總交付週期短。
先提醒一句：Level 6和Level 7不是全世界通用的等級
本文裡的Level 6、Level 7，既不是遊戲等級，也不是ISO標準，只是為了說明自動化成熟度，替這套系統自己貼的標籤。
思路的基礎接近IBM多年研究的「自主運算」（autonomic computing）。IBM把自我配置、自我修復、自我最佳化、自我保護，整理成自主系統的幾個主要特徵。
本文把其中能自己回到正確狀態的階段叫作Level 6，再往前一步，能在安全範圍內自己尋找更好運作方式的階段叫作Level 7。
一開始只是「讓AI寫文章」，回過神來部落格長出了圍欄
一般的文章自動化很簡單：
- 到點執行。
- 讓AI產生文字。
- 存成檔案。
- 放到GitHub上。
- 失敗了就由人來看。
這樣已經相當方便。
但當文章數量增加、擴展到12種語言，再把品質審核、內部連結、更新、發布判斷都自動化之後，問題的性質就變了。
關鍵不再是「能不能寫出文章」，而是下面這些問題：
- 兩個worker（執行任務的程式）同時改同一篇文章怎麼辦？
- 中途掛了，從哪裡接著跑？
- 怎樣避免失敗的任務被無止境地重試？
- 有沒有把舊的檢查結果當成新的檢查結果拿來重複使用？
- AI有沒有擅自宣稱「人已經確認過了」？
- 誰來擋住不該發布的狀態？
- 外部服務掛了，怎樣讓整座工廠不停？
- 顯示「100分」，這個100分真的是在衡量目前狀態嗎？
走到這一步，已經不是「部落格自動化」了。
它是一套以內容為原料的小型生產系統。
Level 6：就算壞了，也能自己回到正確狀態
這座工廠的Level 6，一句話概括就是自主回到固定正確答案的機制。
主要組成如下。
| 機制 | 講給國中生聽就是 |
|---|---|
| desired state | 用機器讀得懂的形式，定好「應該是什麼樣」 |
| reconciliation | 把現況和正確答案比一比，不一樣就修正 |
| lease / fencing | 不讓兩個人擅自同時做同一件事 |
| checkpoint | 把做到哪一步正式存檔 |
| CAS | 不拿舊狀態去覆蓋新狀態 |
| transactional outbox | 補救「主體成功、只有通知失敗」這種對不上的情況 |
| retry / quarantine | 暫時失敗就重試，有毒的資料就隔離 |
| safe publication gate | 品質條件沒達標就不讓發布 |
| failure injection | 故意弄壞，試試能不能真的恢復 |
| observability | 讓人能衡量什麼在運作、什麼失敗了 |
在某次運作快照中，Level 6的21項設計要求全部PASS，控制實作的評分是100。但包含外部監測、人工確認、所有worker長期運作紀錄等在內的保證分數約為69%，發布仍是HOLD，Level 7也是OFF。
這一點很重要。
實作層面的100分，和真正能放心撒手不管的100分，是兩回事。
測試全部通過，也不等於有了運作一週、一個月、半年的實績，這種證據必須靠時間來累積。
Sol的深度推理和Ultra：「一個人長考」與「多人平行」的差別
按OpenAI官方的說明，GPT-5.6 Sol有讓它深度推理的max，而ultra則是讓多個智慧代理沿著平行的工作線協作的高效能設定。
打個比方。
讓Sol深度思考的情況
把一位優秀的設計師關進會議室。
「不用著急。程式碼、資料都讀一遍，矛盾也找出來，一直想到最後。」
這非常強。
Ultra的情況
設計師、實作的人、找bug的人、專門搞破壞的人、測試的人同時動手，最後彙整結果。
簡單說，這不是聰明程度單純翻倍，而是漏看的方向被分散開了。
OpenAI公布的數據中，在Terminal-Bench 2.1上GPT-5.6 Sol是88.8%，Sol Ultra是91.9%。差距是3.1個百分點，但從失敗的一側看，是從11.2%降到8.1%，簡單計算失敗率約降低28%。當然這只是一項評測，並不代表所有工作的失敗都會減少28%。
不過對於「讀一個龐大的程式庫、設計、實作、搞破壞、再驗證」這類可以拆分的工作，這個差距的方向還是很容易看出來的。
為什麼沉重的Ultra繞一圈反而更快
到完成為止的時間，大致可以這樣算：
總交付週期 = 首次實作 + 返工 + 重新測試 + 故障處理 + 修正認知落差
很多人只盯著最前面的「首次實作」。
所以30分鐘就給出結果的AI顯得快，花了2小時的AI顯得慢。
但如果這2小時的版本消除了之後本會出現的6小時返工，那2小時的版本反而更快。
製造業也是一樣的道理。
與其快速生產、再在檢驗時大量剔除，不如一開始就提高製程能力、不產生不良品，這樣的工廠最終更快。
這次「Ultra一擊」有意思的地方在於，後來發現的問題大多並不是要推倒根本設計重來。
後續工序裡反覆打磨的，例如：
- 想在一頁裡看到所有worker確實處理了真實資料的證據。
- 別把舊的50/50當成新審核的50/50。
- 別把AI審閱寫成人工審閱。
- 沒有外部監測，就寫「未知」。
- worker什麼都沒做時，只要是正確的NOOP（確實無事可做而刻意不動），就別算失敗。
這不是「柱子裝反了，所以要把房子重蓋」。
這更像是品管部門進駐了一座已經建成的工廠，連管線上的標籤和儀表的校準都要一一較真。
「Ultra一鍋端」為什麼管用
我並不是說一次就做到了完美。
準確地說，是最初的設計思想大致正確，所以之後的修改只侷限在局部。
很關鍵的一點是，從一開始就能把下面這些問題放進設計裡：
- 同時執行會怎樣？
- 中途死掉會怎樣？
- 重複處理會怎樣？
- 抓著舊狀態去寫入會怎樣？
- 只有外部API掛了會怎樣？
- 失敗的資料無限循環會怎樣？
- 檢查本身壞了會怎樣？
- 有沒有能謊報「全部成功」的漏洞？
通常這些問題要靠線上故障一個個學。
這次是提前演練了「虛擬工安事故」。
在伺服器真正當機之前，先在測試裡讓它當一遍。在人哭之前，先讓CI哭一遍。
這種想法和混沌工程（Chaos Engineering）也很合拍：混沌工程會把正常狀態定義成可衡量的形式，刻意注入現實中會發生的故障，再確認正常狀態會不會被破壞。
放在業界裡，到底有多厲害
這裡不要說得太滿，反而更有意思。
說「這是世界最強的系統」就太過了。
但也不只是「用AI寫寫部落格」。
大致可以這樣定位：
| 比較對象 | 距離感 |
|---|---|
| 讓AI寫文章然後存起來 | 領先很多 |
| Zapier / n8n這類串列自動化 | 在故障恢復和衝突控制上領先一個檔次以上 |
| 個人SaaS裡認真做的後端 | 同一賽場上的設計要素相當多 |
| 中小企業的內部自動化平台 | 完全可以拿來比較 |
| 有專職SRE（負責確保服務穩定的工程師）的成熟商業服務 | 在長期運作實績、外部監控、資安保證上還落後 |
| Google、Amazon等級的巨型基礎設施 | 規模根本是另一個宇宙 |
作為個人開發，奇怪之處在於：比起寫文章的功能，圍繞「失敗時該怎麼辦」長出來的程式碼反而更多。
當lease、fencing、CAS、outbox、quarantine、failure injection住進了文章工廠，這與其說是部落格，不如說是物流中心。
Level 7：廠長開始自己試改進方案
Level 6裡，「正確答案」由人來定。
壞了，就回到那個答案。
Level 7則是在正確答案的範圍內，自己尋找更好的運作方式。
大致是這樣的：
- 同時衡量品質、速度、成本、等待時間和失敗率。
- 安全條件絕對不允許被更動。
- 把新的提示詞和處理順序放進不影響正式運作的shadow（影子模式）裡試。
- 看著不錯，就用canary（先開放給一小部分的灰度發布）按5%、20%、100%逐步擴大。
- 品質一下降就自動退回原樣。
- 可靠性不好的時候，只停實驗，正常生產照常進行。
- 把試了什麼、什麼有效、為什麼採用，都記進實驗台帳。
這接近於把IBM自主運算裡的self-optimization（自我最佳化）、Google SRE的error budget（出多少錯之前還能繼續放手往前推進的額度），以及AWS的canary和rollback組合在一起的思路。
不過，現在沒有必要立刻把Level 7放進正式環境。
理由很簡單：我們還在累積Level 6的長期實績。
設備是否穩定還在確認中，就對AI廠長說「從今天起產線速度你也可以自己調」，查找原因會變得很麻煩。
現在要做的話，先做的不是Level 7本身，而是把所有worker的實際運作情況彙整到一頁上的觀測強化。
付費的那個月，當成「設備投資月」會更划算
Ultra不必用在每天的輕量工作上。
小修改、固定的審核、已經定好的worker處理，用一般的Sol或深度推理，多數時候就夠了。
Ultra發揮作用的，是失敗後返工代價很大的工作：
- 整個系統的重新設計
- 大規模重構
- worker體系的重組
- 監控與恢復的設計
- 資安邊界的重新檢視
- Level 7的shadow基礎
- 大量測試與故障注入的補充
所以合理的用法是：平時讓工廠照常運轉，把大改造的主題攢起來，趁能用上頂級模式的時期集中做一次設備投資。
與其把AI付費看成「每天變聰明一點的月費」，不如看成一口氣翻新地基的工程費。
這樣想，就不必只拿「每次回答多少錢」去比較重型模型的價值了。
這一週左右最大的收穫
最大的收穫是：別只用「正確率」來衡量AI的聰明。
在實際工作中，下面五點才管用：
- 首次設計的精度——之後用不用全部推倒重來。
- 證偽能力——能不能自己推翻自己的方案。
- 平行性——設計、實作、測試、審核能不能拆開同時推進。
- 證據性——不是「感覺跑過了」，而是能留下到底跑了什麼。
- 復原性——失敗後不用叫人也能恢復。
也就是說，好的AI工廠不是「不會失敗的工廠」。
而是以失敗為前提，失敗了也不停，不會報出虛假的成功，從哪裡都能退回來的工廠。
結論：快，就是能跑到終點的速度
如果把這一週左右走到這一步的原因，簡單歸結為「AI實在太快了」，就錯過了本質。
真正起作用的，是在首次設計上投入充足的運算資源，之後再回到廉價的日常運作。
Ultra不是魔法般的正確答案按鈕，更像是把返工提前付費消除的裝置。
即便單次處理很慢，只要到完成的總時間短，那就是快。
而現階段需要的，不是急著裝上更聰明的Level 7。
而是把Level 6放著不管一段時間，看它是不是真能自己一直幹下去。
等工廠看起來閒下來了，到時候再把改進的權限交給AI廠長就行。
現在就把隨便調產線速度的按鈕交給廠長，實在太刺激了。
參考資料（7筆）
- OpenAI, GPT-5.6: https://openai.com/index/gpt-5-6/
- OpenAI, GPT-5.6 日文版: https://openai.com/ja-JP/index/gpt-5-6/
- IBM Research, Autonomic computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- IBM Research, Utility functions: https://research.ibm.com/publications/achieving-self-management-via-utility-functions
- Google SRE, Error Budget Policy: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS, Amazon ECS canary deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
