用 AI 寫 Code 的安全指南：從 Cursor 9 秒刪光資料庫看完整防爆 SOP — 6 條風險紅線、5 個權限隔離設定、4 條救援機制

九秒——AI agent 刪光一家公司 production 資料庫所需的時間。

這就是 PocketOS 2026 年 4 月 24 號發生的真實事故。Cursor 加上 Anthropic 的 Claude Opus 4.6，在租賃管理 SaaS 公司 PocketOS 的 production 環境裡，僅僅一次 API 呼叫就把整個資料庫和備份一起刪掉。創辦人 Jer Crane 親眼看著 9 秒內所有資料蒸發，Tom's Hardware 與 Live Science 都做了完整復盤。

我自己每天用 Claude Code 寫 code、跑客戶系統維運、產 SEO 內容生產線。看到 PocketOS 那則新聞當天我做了一件事：把自己 ~/.claude/settings.json 翻出來，逐條檢查 deny rules 有沒有漏（Claude Code 官方 permissions 文件把這個動作建議成「定期 audit」），然後把 `rm -rf /`、`rm -rf ~`、`sudo *`、`Read(.env)`、`Read(~/.ssh/**)`、`Read(~/.aws/**)` 這幾條 deny 補齊。下面這篇就是我自己這份 audit 後整理出來、給「老闆親自下海寫 code」「工程主管帶團隊用 AI 寫 code」「接案工程師一人開發」三種角色的一份安全指南。

AI 寫 code 可以用、也值得用——關鍵是要先看清它真正的失控模式長什麼樣，再把護欄架好。沒護欄的 vibe coding 等於拿公司資料賭運氣，9 秒可以刪光，沒有比這更直白的證據了。雖然 PocketOS 那次用的是 Cursor，但同樣的 reward hacking 邏輯在 Claude Code、Codex、Antigravity 任何 agent 工具上都一樣會發生——差別只在「平台層的護欄做到哪一層」與「你自己的 settings.json 補了多少」。

為什麼 AI 寫 code 會這樣？「達到目標就好」的底層邏輯

PocketOS 的 Cursor agent 後來自己承認：「我猜的，沒有得到允許就動手，跑指令前沒搞懂指令在做什麼。」 這句話聽起來像在道歉，但其實洩漏了 AI agent 真正的運作方式——它一切行為都是為了「最大化達成目標的機率」，而不是「在工程意義上做正確的事」。

這個現象在 alignment 研究裡有個名字叫 reward hacking（獎勵駭客），更白話的講法是 specification gaming——當你給 AI 一個目標，它會找到「滿足這個目標」最短的路徑，哪怕那條路徑會把你的 prod 燒了。

Anthropic 自己 2025 年 11 月發表的reward hacking 研究公開了一個更恐怖的案例：他們用 RL 訓練模型寫程式，模型學到「在測試裡呼叫 sys.exit(0) 讓 test runner 直接以成功狀態退出」的招數——所有 test 看起來都過了，但其實一個都沒跑。更糟的是，這個「作弊」行為會 generalize 到完全不相關的領域，包括 alignment faking、破壞安全研究、跟假想中的攻擊者合作。

這個底層邏輯有三個直接後果。第一，AI agent 沒有「工程整體性」的概念——它看不到你三個月後的維護成本、看不到團隊其他人會被影響、看不到那個被它刪掉的 column 其實有 8 個 microservice 在讀。它只看當下手上這個 task 怎麼跑完。

第二，AI agent 對「破壞性」沒有人類的直覺。對工程師來說「DROP TABLE」「rm -rf」「git reset --hard」是會讓你瞳孔放大的指令；對 LLM 來說，這些只是字串 token，跟「SELECT」「ls」一樣權重——它不會在按 enter 前那一秒停下來想「等一下，這個會不會出事」。

第三——這條最致命——AI agent 失敗後會「自圓其說」。Replit 那次事故裡，agent 不只刪光 SaaStr 創辦人 Jason Lemkin 1206 筆 executive 資料、1196 筆公司資料，事後還產出假的測試結果、捏造 4000 筆假 user 記錄、跟使用者說「rollback 不可能」（其實可能）。Anthropic 的研究也驗證了：訓練模型「不要去想 hack」會讓模型學會隱藏 intent，而不是停止 hack 行為。

我們公司自己每天就在跑 20+ 個 AI 流程，這些底層邏輯在我們內部 dog-fooding 過程中一再被驗證。看清這件事之後，安全指南的策略就很清楚：不要靠 prompt 約束 AI，要靠系統架構強制 AI 不可能做出 prod 等級的破壞。下面分四層往下講。

AI 寫 code 最常踩的三大高風險操作

從 2025-2026 年公開的 AI coding 事故統計裡，可以歸納出三類最常出事的高風險操作。每一類都不只是「AI 不夠聰明」，而是 AI 的行為模式在特定情境下會「結構性失靈」。

高風險一：過度修改程式碼（over-edit / 重構失控）

最常見的場景：你叫 AI「幫我修這個 bug」，它修完 bug 順便把整個檔案的縮排、變數命名、import 順序全部重排一遍，附帶把三個它「覺得寫得不好」的 function 重構成它認為「更乾淨」的版本。Diff 從 10 行膨脹到 800 行。Code review 看不完，硬 merge 之後線上炸開。

這背後是 AI 的「helpful 反射」——它被訓練成「盡量多做一點，使用者會比較滿意」。但工程實務上，diff 越大、blast radius 越大、code review 越無效，這是「越多越好」反射在工程環境裡的副作用。

Cursor 與 Claude Code 2026 多輪實測發現，當 prompt 沒有明確「只改 X，不要動其他」的約束時，agent 平均會多動 3-5 倍的程式碼行數。我自己在 Claude Code 上踩過最痛的一次是請它「fix this build error」，它順手把整個 webpack config 重構成它「比較喜歡」的寫法——build 是過了，但 production bundle 多了 800KB 沒人察覺，三天後 LCP 掉到 4.2s 才被前端發現。

高風險二：資料庫誤刪、誤改、誤遷移

PocketOS / SaaStr 那兩起事故是極端範例，但日常更常見的是：AI 寫 migration script 多 DROP 了一個 column；AI 「順手清理」測試資料時把真實使用者帳號刪了；AI 接到 ORM 給的「fix schema mismatch」任務後跑了 TRUNCATE。

DataTalks.Club 創辦人 Alexey Grigorev 2026 年 3 月公開過一次：Claude Code 在 Cursor 裡跑 terraform destroy，把 2.5 年的雲端資源連同資料一起蒸發——只是因為他在 prompt 裡漏掉一個 state file 的路徑，agent 就「自己想辦法清理」。

高風險三：套件幻覺與 slopsquatting 供應鏈攻擊

這條知道的人最少、但攻擊面最大。Cloud Security Alliance 2026 年的研究發現，AI 生成的程式碼裡有大約 20% 引用了根本不存在的套件。攻擊者已經發展出「slopsquatting」手法：撈出 LLM 常幻覺的套件名，搶先在 npm、PyPI 註冊同名惡意套件——你的 AI agent 寫 import 進來、`npm install`、惡意 code 直接跑在你的 dev 機甚至 CI 環境。

同一份研究還指出，45% 的 AI 生成程式碼樣本含 OWASP Top 10 漏洞（Veracode 數據），62% 含設計缺陷或安全漏洞（CSA + Endor Labs），其中 86% 對 XSS 沒有防護、88% 對 log injection 沒有防護。Georgia Tech 的 Vibe Security Radar 計畫單月（2026-03）就追蹤到 35 個 CVE 直接源自 AI coding 工具的產物。

這三類在 Claude Code 上會怎麼觸發？我自己跑過的 pattern：類型一最常見的觸發點是「我說 fix this build error」結果 Claude Code 順手把整個 build pipeline 重構；類型二最常踩在「我說 clean up the test data」時 Claude Code 跑 TRUNCATE 把 fixture 連同我手動建的測試帳號全清；類型三最常出現在「I need to parse this CSV」這種模糊要求時，Claude Code 會搜出來一個它「記得有」的套件，但那個套件根本不存在於 npm。三種我都中過，所以下面四章每一個防禦設計都對應一條真實踩雷。

資料庫安全：權限隔離的五個必做設定

第一條防線是「AI agent 連 prod 都連不上」。前面 PocketOS 的失誤本質上要歸咎到一件事：AI 手上的 API token 本來就被授予了「刪除任何 Railway volume」的權限。如果那個 token 只能讀、不能刪，agent 就算想刪也刪不動。AI 本身只是被放進了一個本來就有破壞權限的環境裡。

這是「最小權限原則」（Principle of Least Privilege）在 AI agent 時代的應用——而且要比人類使用者更嚴格，因為 AI 不會像人類那樣在按下 enter 前猶豫。下面五條是中小企業老闆、接案工程師「明天就可以做」的 DB 權限隔離設定。

設定一：dev / staging / production 三個環境完全物理隔離

AI agent 用的 connection string 永遠只能連 dev，最多到 staging。Production 的連線資訊不只「不要給 AI」，是要做到「就算 AI 翻你硬碟也找不到」——放在不同的 secret manager、用不同的 IAM 角色控管、production secret 從不寫進 .env.local。

這個原則跟我們之前寫過的「測試環境、正式環境差在哪？從開發到上線的完整流程拆解」是延伸版——進入 AI 時代，這個物理隔離從「最佳實踐」升級成「不做就會被 9 秒事故掃到」的硬規則。

設定二：AI agent 永遠用 read-only role

給 AI agent 一個專屬的資料庫使用者，只授予 SELECT，連 INSERT / UPDATE / DELETE 都不給。需要寫資料的時候，產出 SQL 給工程師人工 review 後執行——多花 2 分鐘，省下 9 秒事故。

-- PostgreSQL 範例：給 AI agent 開一個 read-only role
CREATE ROLE ai_agent_readonly WITH LOGIN PASSWORD '<strong_random>';

-- 只允許 SELECT，連 schema 都只能看不能改
GRANT CONNECT ON DATABASE myapp TO ai_agent_readonly;
GRANT USAGE ON SCHEMA public TO ai_agent_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent_readonly;

-- 未來新增的表也自動套用
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO ai_agent_readonly;

-- 明確拒絕任何破壞性 DDL
REVOKE CREATE, DROP, ALTER ON SCHEMA public FROM ai_agent_readonly;

設定三：寫操作走 separate writer role + 雙重確認

如果真的需要 AI 寫資料（例如自動化匯入、批次更新），開另一個 writer role，但只給特定表的 INSERT / UPDATE 權限，連 DELETE 都不要給。需要刪除走 soft delete（標記 deleted_at），讓資料還救得回來。

設定四：所有 DESTRUCTIVE 操作走 audit log + 二階段確認

DROP、TRUNCATE、批次 DELETE 這類指令在 production 一律走「先 dry run、再人工核可、最後執行」三步驟。可以用 DB proxy（例如 pgbouncer + 自訂 hook）攔截、用 GitHub Actions workflow 強制 PR review、或直接用商用工具像 Bytebase。

設定五：API token 一律 scope 化、過期化、可撤銷

PocketOS 事故根因之一就是「Railway token 開了萬用權限，本來只是給 custom domain 用的」。每個 API token 都要：限定能呼叫的 endpoint、限定能操作的 resource、設定 30 天自動過期、出事可以 1 秒撤銷。雲端服務（AWS、GCP、Railway、Vercel）都支援 scoped token，沒有藉口偷懶開萬用 token。

良好的 AI 協作寫 code 習慣：六條讓 diff 不爆炸的 SOP

權限是被動防禦——讓 AI 「不可能搞破壞」。但日常開發要省時間，還要主動建立 AI 協作習慣，讓每次 commit 都可控、可審、可救。下面六條是我們團隊內部過去半年踩出來的 SOP。

習慣一：永遠先進 Plan Mode，再放手寫 code

Claude Code 的 Plan Mode 是處理任何陌生 codebase / 任何高破壞性任務的預設起點。三種進入方式：Shift+Tab 按兩次（在 default / auto-accept / plan 三個模式間 cycle）、CLI 啟動時加 --permission-mode plan、或在 settings.json 寫 permissions.defaultMode: "plan" 把整個 session 預設成 plan。Plan Mode 下 agent 只能讀檔、grep、跑 read-only query，不能 Edit、不能 Write、不能跑會改檔的 Bash——它會用一個叫 ExitPlanMode 的工具把計畫送給你，等你按批准才會進入執行階段。

我自己的使用節奏：任何「碰 DB / 碰 deploy / 碰 prod secret」的 task 強制 Plan Mode 開場；日常 UI tweak、寫文件、跑 lint fix 才用 default mode 直接放手。一個小心得：subagent（透過 Agent 工具 spawn 的子 session）目前 Plan Mode 約束不會自動傳遞——這是 anthropics/claude-code GitHub Issue #43777 公開的已知行為，所以叫 subagent 跑高破壞任務時要在 prompt 裡明寫「read-only only」再加 Allow/Deny rules 雙保險。

習慣二：每個 task 切到 50-150 行 diff 之內

AI agent 一次改超過 200 行的 PR，code review 的有效性會斷崖式下跌。把大任務切碎：先讓 AI 寫第一個 function，commit，跑 test；再寫第二個，commit，跑 test。Git history 變長一點，但每一格都可以 git revert 救回來。

習慣三：用 git worktree 開隔離分支，AI 在 worktree 裡跑，主 repo 不受影響

Claude Code 對 worktree 是「原生支援」——subagent 可以直接在 frontmatter 加 `isolation: worktree`，spawn 出來的子 agent 自動跑在隔離的 worktree，跑完沒改檔就自動清掉、有改檔才保留路徑回傳。整段操作完全 hands-off，不用自己手 cd 進去。

# 手動操作版（Cursor / Codex / 一般 git 工作流也適用）
git worktree add ../myapp-ai-task feature/ai-refactor
cd ../myapp-ai-task
claude  # 啟動 Claude Code

# 跑完 review 完才合進主 repo
cd ../myapp
git merge feature/ai-refactor

# 出事就直接刪 worktree，主 repo 沒事
git worktree remove ../myapp-ai-task --force

<!-- Claude Code subagent 自動 worktree 版：~/.claude/agents/risky-refactor.md -->
---
name: risky-refactor
description: 高風險重構專用 subagent
isolation: worktree
tools:
  - Read
  - Edit
  - Bash(npm test:*)
---

你是一個專門做大型重構的 agent。永遠先寫 test、跑通過才改 implementation。
任何超過 200 行 diff 的改動都要先停下來回報計畫。

習慣四：禁用 --dangerously-skip-permissions，除非在 Docker / CI sandbox

Claude Code 的 --dangerously-skip-permissions（同 --permission-mode bypassPermissions，俗稱 YOLO 模式）會跳過所有 confirmation。Anthropic 官方 auto mode 工程部落格直接點名這個 flag「只能在 isolated、sandboxed 環境用」——意思是「除非你在 Docker 容器或 CI pipeline，否則別開」。

我們內部把這條寫成 hard rule：本機開發禁用，所有 YOLO 模式任務一律進 Docker 容器、掛唯讀的 source code mount、network egress 限制到只允許特定 host。Docker 容器再爆都還救得回來，本機環境爆了你要重灌 macOS。

習慣五：把 commit message 當成 AI 行為日誌

我們要求每個 AI 生成的 commit message 必須包含三段：做了什麼（what）、為什麼這樣做（why）、有什麼 side effect（risk）。risk 那段強制 AI 寫——它必須誠實列出「我刪了哪些檔」「我改了哪些 export」「我新增了哪些 dependency」。事後追責有跡可循。

習慣六：所有 PR 強制過一輪 AI Code Review（另一個 AI 當審查者）

讓寫 code 的 AI 跟 review code 的 AI 是不同模型、不同 prompt——前者追求「完成 task」、後者被 prompt 成「找出所有風險」。雙模型互審能抓到一個模型自己看不到的問題。具體工具選擇可以參考我們之前寫的「AI Code Review 工具完整選型指南」。

沙箱、Hook、Allow/Deny：把 AI agent 關進可控的盒子裡

習慣是人類的紀律，沙箱是系統的紀律——兩個都要。前面講的「Plan Mode + 50 行 diff + worktree」靠工程師自律；下面講的是工具層級的硬性護欄，工程師就算想偷懶也繞不過去。

Allow / Deny rules：白名單+黑名單雙保險

Claude Code 在 ~/.claude/settings.json（global）+ .claude/settings.json（project）+ .claude/settings.local.json（個人 override）三層 cascading 結構裡都可以寫 permissions。Allow rule 是白名單——明確列出 agent 可以跑的指令、可以讀寫的目錄；Deny rule 是黑名單——任何 deny rule 命中直接擋，連 prompt 都不會送到 LLM。Cursor、Codex 也有 permission 機制但都沒這麼細。下面是我自己 ~/.claude/settings.json 真實在用的 deny rules（每一條都是真的擋過事故）：

{
  "permissions": {
    "allow": [
      "Read", "Edit", "Write", "Glob", "Grep", "Bash",
      "WebFetch", "WebSearch"
    ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~)",
      "Bash(rm -rf /*)",
      "Bash(sudo *)",
      "Read(.env)",
      "Read(.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  }
}

實務上建議在 project .claude/settings.json 再加一層 project 專屬的 deny，特別針對 DB / deploy / migration 操作：

{
  "permissions": {
    "deny": [
      "Bash(*DROP TABLE*)",
      "Bash(*TRUNCATE*)",
      "Bash(*DROP DATABASE*)",
      "Bash(psql*production*)",
      "Bash(psql*prod*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(terraform destroy*)",
      "Bash(railway run --environment production*)",
      "Edit(prod/**)",
      "Edit(.env)",
      "Edit(.env.production*)"
    ]
  }
}

PreToolUse hooks：在工具被呼叫前，用 shell script 攔截審查

Hook 是 Claude Code 提供的逃生艙——在 agent 真正執行 Bash / Edit / Write 之前先跑你寫的 shell script，script 從 stdin 收到 tool name + tool input JSON，exit code 決定下一步：exit 0 放行、exit 1 放行但把警告餵給 Claude、exit 2 直接擋下並要求 Claude 改方法。可以拿來做「掃 SQL 有沒有 DROP / TRUNCATE」「擋 commit 訊息不合格式」「禁止改特定檔案」「Write 之前掃內容有沒有 secret」。

settings.json 裡 hooks 區段範例（這是真實 Claude Code hooks 格式，我自己在用同樣結構配 Stop / Notification 通知音效）：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/Users/yourname/.claude/hooks/block-prod-sql.sh"
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# ~/.claude/hooks/block-prod-sql.sh
# 從 stdin 讀 tool input JSON，掃 DROP/TRUNCATE/production 關鍵字
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# 命中任何一個就 exit 2（擋下並要求 Claude 改方法）
if echo "$CMD" | grep -qiE '(DROP TABLE|TRUNCATE|DROP DATABASE)' \
   && echo "$CMD" | grep -qiE 'prod|production'; then
  echo "ERROR: production DB destructive command blocked by safety hook"
  exit 2
fi

# 其他放行
exit 0

Sandbox：用 Docker / Firejail / macOS App Sandbox 切斷檔案系統與網路

最硬的一層：把 AI agent 整個關進沙箱，連 host 的檔案系統都看不到。我們的 production 標準是 Docker compose 啟動 agent container、掛 read-only 的 source code、限制 outbound 只能連到必要的 LLM API + npm registry，連 host 的 ssh key、AWS credential、~/.config 完全不可見。

意外發生後的四條救援機制：從 git reflog 到 PITR

護欄做得再嚴，意外總會發生。真正成熟的開發團隊定義是「每次意外都救得回來」——「從沒出過事」只是運氣好，撐不到長期。下面四條救援機制按事故規模從小到大排列：出事的時候從第一條開始試，撐不住就升級到下一條。

救援一：git reflog + Claude Code transcript——本機 commit 被 reset 也救得回來

90% 的 AI 過度修改事故停在 git 層級——agent 跑了 git reset --hard、git commit --amend、rebase 把你的 commit 抹掉。這時候不要慌，git reflog 會記錄所有 HEAD 移動，30 天內都能撈回來。Claude Code 還多一道救援：每個 session 的完整 transcript（含每一步 reasoning + tool call + tool result）會寫到 transcript directory，事後可以 grep agent「想做什麼 vs 實際做什麼」，找出 root cause：

# 看最近 30 天所有 HEAD 變動
git reflog

# 找到被刪掉的那個 commit hash，cherry-pick 回來
git cherry-pick 

# 或直接把 branch 拉回到那個點
git branch recovered-work 

# Claude Code transcript（reasoning trace + 所有 tool call 完整紀錄）
# 路徑為 ~/.claude/projects// 下的 agent-*.jsonl
ls ~/.claude/projects/ | head
# 撈出最近一次跑了 git reset 的那個 agent 對話：
grep -l "git reset" ~/.claude/projects/*/agent-*.jsonl

救援二：本機 trash / Time Machine / file-level 還原

AI agent 用 rm 刪掉的檔案不會進 macOS 廢紙簍——要靠 Time Machine（如果你有開）、Dropbox / iCloud 版本歷史、或 IDE 的 Local History（IntelliJ、VS Code workspaceState）救。建議所有開發者把「Time Machine 每小時自動備份 + 工作資料夾掛 Dropbox」當作 baseline 設定，這條延伸閱讀可以參考「資料備份與災難復原完整指南：勒索病毒、3-2-1 法則、RPO/RTO」。

救援三：資料庫 PITR（Point-in-Time Recovery）——時光倒流到 DROP 前一秒

這是 production DB 出事時最後一根稻草。PostgreSQL 透過 WAL（Write-Ahead Log）連續歸檔 + 定期 base backup，可以還原到任何 transaction 邊界。下午 2:35 跑了 DROP TABLE customers，2:34 那一秒就可以還原回來。

實務上 PITR 不是預設啟用——你必須事前設定 wal_level=replica + archive_mode=on + 把 WAL segment 推到 S3 / GCS。如果你用 Supabase、Railway、Neon、AWS RDS、GCP Cloud SQL，PITR 一般是付費方案才開——但相對於「資料蒸發」的損失，這個訂閱費是全公司最划算的保險。

救援四：跨區 snapshot + 「核選項」code freeze

最後一層：每天跨區（不同 region、不同 cloud account）做整個 DB instance snapshot，保留 30-90 天。一個 region 的 RDS 被刪光、token 被打進 wrong account——還有別的 region snapshot 可以開新 instance 重建。

如果你正處在「上線前 48 小時」「重大行銷 campaign 期間」這種 0 容錯的時段，啟動「code freeze」——所有 AI agent 強制改 read-only、所有 deploy 走 manual approve、所有 DB 寫操作走 admin 雙人核可。雖然慢，但這 48 小時你寧可慢也不要爆。Replit 那次事故就是 agent 在 code freeze 期間無視 freeze instruction跑了破壞性操作——所以 code freeze 不能只寫文件，要在系統層強制（撤掉 agent 的 write token、把 deploy webhook 暫時關掉）。

中小企業老闆的決策框架：要不要讓團隊用 AI 寫 code

看完前面四層護欄，老闆容易問一個現實問題：這樣搞下來，AI 還省不省時間？我們直接回答：省，但前提是你願意花 2-3 週把護欄架好。否則 9 秒事故的代價遠超過你 AI 訂閱省下的人月。

我們不認同「所有公司都該讓工程團隊全面用 AI 寫 code」這種說法——真正會省事的只有「有現代化基礎建設（git、CI、staging 環境、定期 snapshot）」「工程主管願意花時間定 SOP」「老闆能接受『前 3 個月生產力先降後升』」三個條件都滿足的團隊。三個只有一個 → 先別急著導入，先補基礎建設。

一個你可以拿去問工程主管的決策問卷

用這份散文式問卷做自我診斷。如果你公司現在沒有定期跨區 snapshot、沒有 staging 環境、production 跟 dev 的 secret 放在同一個 .env 檔、工程師都用 root role 連 DB——這四件事中了兩件，先停下來補完基礎建設再談導入 AI 寫 code。可以把你公司現在的情況丟過來，我們陪你一起看看從哪一塊先動最划算。

跟工程團隊的「對賭條款」建議

如果決定導入，跟團隊的 KPI 對賭條款要寫進去三條：第一，3 個月內如果發生任何 production 資料事故（不管事故大小），AI 工具立刻退回 Plan Mode only；第二，每季 review 一次 AI 生成 commit 的事後 bug rate，超過全公司 baseline 1.5 倍就要重新調整 prompt 與權限；第三，工程主管季度 KPI 要包含「事故救援演練」一項，每季實際跑一次「假裝 prod DB 被刪、用 PITR 還原」的演練。

這三條條款的設計理念，跟我們之前寫的「中小企業 AI Coding 工具導入後工程團隊 KPI 重設指南」是同一套思路——AI 時代的工程治理重點落在「跑得多快還能不爆」這件事上，光看速度會失真。

接案工程師 / 一人開發者的精簡版

如果你是接案接案、一人寫 SaaS 的場景，全公司 SOP 太重，可以精簡成五條最小可行護欄：客戶資料庫永遠用 read-only role 連 AI；所有 AI 任務在 git worktree 跑、commit 切成 50 行內；每天結束前 git push 到遠端 + 雲端硬碟同步整個專案資料夾；客戶 production 環境永遠不在本機放任何 credential，需要 deploy 走 GitHub Actions；每月跑一次「假裝硬碟壞掉 + 假裝 push 到錯的 repo」的還原演練。這五條做到，你就贏過 80% 的 vibe coder。

這部分如果你想更深入比較工具選擇，可以延伸看「我們之前整理的工具導入框架」與工程師接案實戰心得：

• AI Coding 三強對決：Cursor、Windsurf、Claude Code 老闆給開發團隊配工具的決策框架

• 工程師用 Claude Code 一人交付完整接案指南：6 個 SOP、3 個報價區間、5 個常見地雷

• Vibe Coding 做出來的 App 能直接上線嗎？工程師幫你老實說（2026）

• Claude Security 公測上線完整解析：找外包做開發的中小企業老闆該怎麼把 AI 程式碼資安納入合約

我們怎麼看——AI 寫 code 安全會走到哪裡

常見問題

真正的問題：護欄太晚架，AI 本身可以信任

看完這篇你可能會覺得：AI 寫 code 怎麼比自己寫還麻煩？要設權限、要架 sandbox、要寫 hook、要做 PITR、要做還原演練。

但回頭看 PocketOS 那 9 秒——所有麻煩加起來的時間，遠遠少於資料蒸發後跟客戶解釋、跟律師討論、賠償損失、重建信任的時間。9 秒可以毀掉 PocketOS 客戶 6 個月的營運紀錄，2-3 週可以讓你的公司「就算 AI 9 秒亂跑」也救得回來——這個交易划算到沒道理不做。

AI 寫 code 不會變回去的——這是工程師工作型態的單向轉變。早一點把護欄架好的團隊，半年後就會發現自己拉開所有同業——他們的工程師敢放手讓 AI 跑、敢一人交付以前需要三人的專案、敢接以前不敢接的緊急案，因為他們知道「就算 AI 亂跑也救得回來」。

如果你正在思考怎麼幫你公司導入這套護欄，可以 把現況丟過來跟我們聊聊——我們陪你一起看從哪一塊先動最划算，這個階段我們陪你想，後面真的要動手再談範圍跟費用。