我怎麼做事

AI 出錯的時候，還撐得住的規則。

讓 AI agent 做出一次好結果不難，難的是第二十次還一樣、換一台機器還一樣、半夜三點還一樣、模型在你腳下換掉了還一樣。下面五條是我實際在執行的規則，每一條都是因為少了它出過事，才補上去的。

  1. 01

    先有操作規範，再談自主

    這條防的是什麼
    一個很能做事但沒有邊界的 agent，會沒問就 merge、會在 demo 到一半重啟共用服務、會跑去改沒人叫它改的檔案，還會留下幾週後才爆出來的捷徑。
    實際怎麼執行
    Agent 是在明確且會被檢查的規則下跑的：沒核准不合併、不先講不重啟共用基礎設施、不動範圍外的東西、不留 AI 製造的技術債、不拿過期記憶當現況。這些是執行階段會被擋下來的，不是寫在提示詞裡祈禱它遵守。
    在哪裡看得到
    那張清單上的每一條，都是它不存在的時候讓我付過代價，才被加上去的。

  2. 02

    用證據驗收，不收口頭回報

    這條防的是什麼
    AI 只要程式碼「看起來合理」就會回報完成 —— 沒跑過、沒開過頁面、沒真的打過 API。工作看起來做完了，債藏著，等到 demo 當天才爆。
    實際怎麼執行
    寫完不等於做完。build 過、lint 過、檢查過，而且實際看過部署結果，才叫做完。「push 了」不等於「上線了」，沒附輸出的宣稱不算結果。
    在哪裡看得到
    這就是為什麼一個模糊的想法可以壓縮到當天出 demo：沒有任何一步把沒驗證的東西往下一步帶。

  3. 03

    先診斷，再決定要不要重建

    這條防的是什麼
    Agent 的黑箱故障從外面看全都長一樣 —— 不回話、provider 接錯、plugin 認證過期、session 狀態飄掉、tool call 打架。這時候最想做的事就是整套框架換掉再說。
    實際怎麼執行
    每個故障都要先收斂到一個講得出名字的根因。重建是診斷之後的決定，不是拿來代替診斷的。
    在哪裡看得到
    大部分「agent 壞掉了」最後都會收斂到那幾個已知原因，而且每一個都有寫下來的排查 SOP。

  4. 04

    用持久的脈絡，取代提示詞技巧

    這條防的是什麼
    靠一段寫得很漂亮的提示詞撐起來的穩定度，換個工具、重開一次 session、換台機器就沒了。每換一次就要從頭把專案再解釋一遍。
    實際怎麼執行
    連續性是架構問題，不是措辭問題。記憶跟狀態從設計上就要能撐過換工具、重開 session、換機器。
    在哪裡看得到
    新的 session 不用重新簡報就能接手進行中的工作 —— 記憶層存在的意義就是這個。

  5. 05

    交接算在交付範圍內

    這條防的是什麼
    一套只有做的人能操作的系統不叫完成，叫依賴。而且別人 demo 不了，這會悄悄限制住它能走多遠。
    實際怎麼執行
    SOP、操作手冊、就緒檢查跟東西本身一起交付。同事光看文件跑不起來，就是還沒做完。
    在哪裡看得到
    把 demo 流程標準化，才讓原本很容易壞的一次性土砲，變成我不在現場團隊也能操作的東西。

延伸問題

關於這些規則的問題。

「用證據驗收」實際上是什麼意思？
寫完不等於做完。build 過、lint 過、檢查過，而且實際看過部署結果，才叫做完。「push 了」不等於「上線了」，沒附輸出的宣稱不算結果。
什麼是 agent 操作規範（operating contracts）？
不是寫在提示詞裡請 agent 遵守，而是在執行階段會被擋下來的明確規則：沒核准不合併、不先講不重啟共用基礎設施、不動範圍外的東西、不留 AI 製造的技術債、不拿過期記憶當現況。
他怎麼讓 AI agent 的記憶跨工具、跨 session 不斷掉？
把連續性當成架構問題處理，而不是措辭問題。記憶跟狀態從設計上就要撐過換工具、重開 session、換機器，所以新的 session 不用重新簡報就能接手進行中的工作。
AI agent 在正式環境壞掉時他怎麼處理？
先收斂到一個講得出名字的根因，再決定要不要重建。大部分黑箱故障最後都會收斂到那幾個已知原因——provider 接錯、plugin 認證過期、session 狀態飄掉、tool call 打架——而且每一個都有寫下來的排查 SOP。

這些東西在哪裡看得到。

這些都不是抽象的偏好，每一條在案例頁裡都找得到對應：agent 作業系統是操作規範被實際執行的地方；角色直播 runtime 是「先診斷再重建」用昂貴代價學會的地方；產品演示那條線則是「用證據驗收」把自己的成本賺回來的地方。

去看案例