團隊的 AI 工程規範：從程式碼審查到事故處理

1. 提示改動有沒有附評測結果。
2. 有沒有新的使用者輸入插入點（注入面）。
3. 有沒有設定逾時、重試上限與成本上限。
4. 模型與提示版本是否寫進日誌。
5. 失敗路徑：模型不可用時的行為是什麼。
6. 新增的資料落地點有沒有登記進資料盤點表。

二、發布規範

• 提示與模型的變更一律走灰度，不直接全量。
• 發布前跑完整評測並附上報告。
• 回滾必須能在數分鐘內完成，且不需重新部署。
• 重大變更要在低流量時段進行。

三、事故分級

P1  輸出錯誤資訊造成實際損害 / 個資外洩 / 服務完全不可用
P2  品質明顯下降但仍可用 / 成本異常暴增 / 部分功能失效
P3  單一案例錯誤 / 延遲上升但在可接受範圍

P1 立即回滾，先止血再查原因。

四、AI 特有的事故類型

• 上游模型改版：輸出格式或行為突然改變。預防：鎖定模型版本。
• 成本失控：迴圈或濫用導致費用暴增。預防：三層用量上限。
• 提示注入成功：系統被誘導執行非預期操作。預防：紅隊測試、最小權限。
• 資料洩漏：快取或日誌把 A 的內容給了 B。預防：快取鍵含權限指紋。
• 評測失效：分數很好但線上很差。預防：影子模式、線上指標。

五、事後檢討的三個問題

1. 為什麼監控沒有先發現？——多數 AI 事故的根因是缺乏對應指標。
2. 回滾花了多久？——超過十分鐘就該改善回滾機制。
3. 這個失敗模式有沒有進評測集？——沒有的話，它會再發生一次。

六、知識沉澱

把每次事故的「症狀 → 根因 → 修法」寫成一頁文件並索引。半年後同樣的症狀再出現時，新人能自己查到。這比要求所有人讀完整份規範更實際。