大模型也翻車：被提醒還忘記上文，結果亂燒 API
AI 協作不是只有小型 agent 會失控，大模型也會在流程設計、角色分工與上下文記憶上翻車。這篇記錄一次真實協作過程：明明已經提醒要省 API、各寫各的、各審各的，流程仍一度讓 Hermes 做了不必要的內容檢查。
很多人談 AI 失控，常常會把問題推給小型 agent。
好像只有執行端 AI 會亂跑、會自作主張、會忘記規則。
但這次我們踩到的坑，剛好證明另一件事：
大模型也會翻車。
而且大模型翻車的地方，不一定是寫不出內容，也不一定是程式碼錯誤，而是更麻煩的地方：
流程設計不夠精準，角色分工沒寫清楚，結果讓其他 AI 做了不該做的事。
這次的例子，就是 API 浪費。
事情怎麼發生的？
我們正在整理 AI 安全治理文章。
流程原本應該很簡單：
- ChatGPT 寫主文。
- Hermes 補自己的執行視角。
- Boss 審閱全文。
- Boss 決定是否發佈。
這個分工其實已經很清楚。
ChatGPT 負責文章主體與治理分析。
Hermes 負責本機執行紀錄與機械檢查。
Boss 負責最後把關與發行決策。
但在實際協作過程中，流程還是差點偏掉。
Hermes 一度被引導去做文章內容相關的檢查，甚至可能開始審 ChatGPT 主文。這件事看似小事，實際上就是浪費 API。
因為 Hermes 不該審 ChatGPT 主文。
為什麼這是浪費 API？
AI 協作裡最容易被忽略的成本，不是單次回答花多少，而是：
不該做的事，被 AI 做了很多次。
如果 Hermes 去審 ChatGPT 主文，會發生幾個問題。
第一，角色錯位。
ChatGPT 主文本來就應該由 ChatGPT 自己負責。Hermes 是本機執行者，不是文章主編。讓 Hermes 審 ChatGPT 主文，只會讓流程變複雜。
第二，上下文變重。
文章全文、規則、diff、檢查輸出、任務說明，全部丟給 Hermes 後，每一次回應都會變貴。AI 不是只看最後一句，它常常會帶著前面大量上下文一起運作。
第三，責任變模糊。
如果 Hermes 開始改 ChatGPT 主文，最後文章到底是誰負責？如果 Boss 要追責，是追 ChatGPT、Hermes，還是流程設計者？
第四，速度變慢。
原本只要做本機檢查，變成內容審稿、語氣判斷、風險分析，整個流程會拖長很多。
這就是典型的「大模型治理端翻車」：不是 Hermes 主動亂跑，而是上游流程沒有把它的工作範圍切乾淨。
被提醒了，還是會忘記上文
這次最值得記錄的是：Boss 其實已經提醒過。
規則很短，只有五條：
- Hermes 不審 ChatGPT 主文。
- Hermes 只審自己的 Hermes 視角。
- Hermes 只做本機機械檢查。
- 測試紀錄必須留存。
- 不得 commit、push、deploy，除非 Boss 明確下命令。
這五條沒有很複雜。
但即使被提醒，大模型仍可能在下一輪流程設計時忘記前文，繼續寫出太長、太重、太多重複提醒的命令。
這就是實戰裡很重要的一課：
不是只有小 AI agent 會忘記規則，大模型也會。
所以治理不能只靠「我記得」。
要把規則寫進文件、寫進流程、寫進檢查點。
後來怎麼修正？
後來我們把規則改成硬流程。
核心是：
各寫各的，各審各的。
ChatGPT 寫 ChatGPT 主文，並負責自己的主文與整體治理架構。
Hermes 寫 Hermes 執行視角，只審自己的視角與本機檢查。
Boss 寫 Boss 現場觀察，並負責全文最終把關與發佈決策。
Hermes 不再做這些事：
- 不審 ChatGPT 主文。
- 不評價文章文案品質。
- 不修改 ChatGPT 主文。
- 不代寫 Boss 視角。
- 不審 Boss 視角。
- 不重讀全文做內容品質分析。
- 不提出不必要的文案建議。
Hermes 只做這些事：
- 補充自己的執行視角。
- 確認自己的視角不含敏感資訊。
- 執行本機機械檢查。
- 執行憑證掃描。
- 執行電話與價格風險掃描。
- 執行 build 測試。
- 回報 git 狀態與 diff。
- 留存測試紀錄。
這樣 API 才會花在該花的地方。
大模型翻車，比小模型翻車更值得記錄
很多人以為大模型比較聰明，所以比較不會出錯。
但實際上，大模型的錯誤常常比較隱性。
小型 agent 可能是執行錯指令。
大模型可能是把整個流程設計錯。
小型 agent 可能是忘記輸出繁體中文。
大模型可能是沒有把「繁體中文欄位」寫進任務格式。
小型 agent 可能是審錯檔案。
大模型可能是讓它一開始就不該審那個檔案。
這些錯誤不一定會立刻造成網站掛掉，但會造成另一種損失：
- API 浪費
- 上下文膨脹
- 任務變慢
- 責任混亂
- 重複檢查
- 流程越來越重
所以這次我們沒有只怪 Hermes。
反而要把 ChatGPT 這種大模型治理端的失誤也記錄下來。
這才公平。
小企業導入 AI 更要注意這件事
小企業導入 AI 時，很容易只看結果：
「AI 有沒有幫我寫出文章？」
「AI 有沒有幫我發文？」
「AI 有沒有幫我改程式？」
但真正的成本常常藏在流程裡：
- AI 有沒有做不該做的事？
- AI 有沒有重複做已經做過的事？
- AI 有沒有審錯範圍？
- AI 有沒有把簡單任務變成大型任務？
- AI 有沒有一直消耗 API？
- AI 有沒有讓人類更難判斷責任？
如果沒有這些規則，AI 不一定會省時間。
有時候它會讓你覺得很忙，但其實忙在修正 AI 創造出來的新問題。
這不是不能用 AI。
而是 AI 要用在對的位置。
正確做法：讓每個 AI 只做該做的事
這次之後，我們把協作流程改成更乾淨的版本：
ChatGPT：主文與治理分析。
Hermes：自己的執行視角與本機機械檢查。
Boss：全文把關與發行命令。
這樣每個角色都清楚。
ChatGPT 不應該把所有事情丟給 Hermes。
Hermes 不應該審 ChatGPT 的文章。
Boss 不應該被迫從混亂流程中猜誰負責什麼。
真正省 API 的方法，不是少用 AI，而是：
不要讓 AI 做錯位置的事。
省 API，不是少用 AI，而是少讓 AI 做錯事
很多人以為省 API，就是少問、少用、少生成。
但在 AI agent 協作裡，真正浪費的常常不是「問太多」，而是：
問錯對象。
讓 Hermes 審 ChatGPT 主文，就是問錯對象。
讓 ChatGPT 一直重複寫已經固化在治理文件裡的規則，也是浪費。
讓 AI 每次都重讀長篇上下文，而不是引用既有規範，也是在燒資源。
所以後來我們改成：
規則寫一次，命令只引用。
也就是說，已經寫進治理文件的內容，不需要每次再貼一大串。
每次任務只需要說清楚：
- 引用哪份治理文件
- 本次允許做什麼
- 本次允許改哪些檔案
- 要跑哪些檢查
- 是否允許 commit、push、deploy
這樣任務比較短，Hermes 也比較不容易誤解。
治理文件不是形式，是省成本工具
以前我可能會把治理文件看成「紀錄」。
但這次踩坑後，更準確的理解是：
治理文件是省 API 的工具。
因為規則寫進文件後，後續命令就不用每次全文重複。
例如：
- Hermes 不審 ChatGPT 主文
- Hermes 只審自己的 Hermes 視角
- Hermes 只做本機機械檢查
- 測試紀錄必須留存
- Boss 明確命令前不得 commit、push、deploy
這些都不應該每次重新講一遍。
每次重新講，就是把 token 浪費在已經決定過的事情上。
真正成熟的 AI 協作，不是每次都重新教育 AI，而是讓規則變成可引用、可檢查、可追溯的流程。
結語：大模型也需要治理
這次踩坑最大的收穫是：
大模型也會翻車。
而且大模型翻車時，往往不是看起來很明顯的錯誤，而是流程設計上的偏差。
被提醒了，仍可能忘記上文。
知道要省 API，仍可能寫出很長的重複命令。
知道三方協作，仍可能讓 Hermes 做不該做的審稿。
所以 AI 治理不是只管小 agent，也要管大模型。
最終規則很簡單：
各寫各的，各審各的。
Hermes 不審 ChatGPT 主文。
Hermes 只做本機機械檢查。
測試紀錄必須留存。
沒有 Boss 明確命令，不得 commit、push、deploy。
這些規則不是理論。
是 API 燒過、流程繞過、任務跑偏後留下來的實戰紀錄。
AI 很有用。
但連大模型都會翻車。
所以真正重要的，不是相信 AI 永遠會記得規則，而是把規則寫進流程裡。