今天早上的企業內訓裡，我特別提醒了一個風險判斷的小框架。
當你在問「我可以讓 AI 自動做這件事嗎？」的時候，可以先用兩個維度判斷：
- 可逆 / 不可逆
- 隔離環境 / 生產環境
為什麼是這兩個維度
可逆性決定了出錯後的代價。寫錯一行程式可以改回來，發出去的信收不回來。資料庫加一筆可以刪，刪一筆可以再加，但 DROP TABLE 之後復原代價巨大。
環境隔離決定了影響範圍。在 Docker 裡跑奇怪的腳本，最壞就是 container 重建。在生產資料庫上跑，最壞是公司停擺。
把兩個維度交叉，就是 4 個象限：
| 隔離環境 | 生產環境 | |
|---|---|---|
| 可逆 | 隨便玩，出錯沒事 | 要小心，但可以回滾 |
| 不可逆 | 仍要謹慎，但只影響自己 | 紅線中的紅線 |
紅線中的紅線
舉個現實的例子：
發信出去 = 不可逆 發信給外部人士 = 直接進生產環境
兩個都中——這就是紅線中的紅線。
正確的做法應該是：進草稿夾 ➡️ 人工確認 ➡️ 才寄出。
我自己的 hook 設定就是這樣：所有對外發送（Gmail / Slack / LINE Bot / 第三方）一律先擬草稿給我看，我確認才寄。沒有例外。
怎麼用這個框架
下次你打算讓 AI 「自動處理某件事」的時候，問自己：
- 這件事如果做錯了，能不能在 5 分鐘內回到原本的狀態？
- 這件事影響的範圍，是只在我電腦裡？還是會碰到外部的人或系統？
兩題都回答「可逆 + 隔離」，可以放手讓 AI 跑。
只要有任何一題踩到「不可逆」或「生產」，就要插入人工確認步驟——草稿、預覽、dry-run，怎麼擋都行，但不能讓 AI 一路跑到底。
這比任何 prompt 工程都更能避免事故。