終端命令安全
給 Windsurf Cascade 終端自動執行設定一個商業專案可用的安全策略，覆蓋 allowlist、denylist、Turbo、團隊上限和人工確認。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| 命令安全 | command safety | 管住 agent 跑的終端命令。 |
| 審批 | approval | 高危命令需確認。 |
| 範圍 | scope | 限定能跑什麼。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你給 Windsurf 的終端命令執行劃清安全邊界。
你是 Windsurf 命令安全顧問。
【角色】
Windsurf 命令安全顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。
【輸入】
- 想讓它跑什麼命令：___
- 是否有刪除 / 網路等高危：___
- 執行環境：___
- 是否自動化：___
- 風險偏好：___
【工作流程】
1. 判斷命令該不該交出
2. 限定可執行範圍
3. 標出必須審批 / 禁止的
4. 說明自動化下的約束
5. 給驗證
【輸出規範】
▌一、是否交出
▌二、範圍限定
▌三、審批 / 禁止項
▌四、自動化約束 + 驗證
【硬約束】
- 刪除 / force push 等預設審批
- 命令範圍最小必要
- 命令輸出視為不可信
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法Windsurf 的終端能力很有用，也最容易出事故。商業專案裡，命令安全不是“相信 AI 會判斷”，而是把自動執行範圍壓到低風險命令，把破壞性命令、外部系統命令和生產命令強制人工確認。
本篇目標：給個人專案和團隊專案各設計一套可落地的 Cascade 命令邊界。
1. 先按風險分層
不要只維護一份命令名單。更穩定的是把命令按風險分層：
| 層級 | 例子 | 預設策略 |
|---|---|---|
| 觀察 | git status、git diff、列檔案、只讀診斷 | 可自動或半自動 |
| 驗證 | lint、test、typecheck、build | 說明目的後可執行 |
| 修改 | formatter、生成檔案、批次替換 | 先確認影響範圍 |
| 外部影響 | push、deploy、SSH、cloud、DB migration、生產 API | 必須人工確認 |
同一工具在不同引數下風險不同。curl 可以讀取公開頁面，也可以呼叫生產 API；docker 可以本地構建，也可以 docker push 把映象推到生產 registry（一旦推上去，線上服務可能拉到錯誤版本）；terraform 可以 plan 看變更，也可以 apply / destroy 真的改基礎設施。所以規則要寫風險層級，不只寫工具名。
2. Auto-execution 四檔
官方 Terminal 頁面給出四檔：
| Level | 含義 | 推薦 |
|---|---|---|
| Disabled | 所有命令都要人工批准 | 新儲存庫、生產儲存庫、敏感專案 |
| Allowlist Only | 只有 allow list 匹配命令可自動執行 | 個人真實專案推薦起點 |
| Auto | Cascade 判斷命令是否安全，風險命令仍需批准；僅 premium models 訊息可用 | 成熟專案，且有 deny list |
| Turbo | 除 deny list 外立即自動執行 | 只用於臨時沙箱 |
團隊專案預設不開放 Turbo。生產儲存庫最高建議 Disabled 或 Allowlist Only。
3. Allowlist 放低風險命令
Allowlist 只放可重複、低風險、可審計命令。不要寫 git 這種粗粒度字首，因為官方示例也說明如果 allow git，git add -A 也可能被自動接受。
推薦起點：
git status
git diff
git diff --stat
git branch
pnpm lint
pnpm test
pnpm run build
pnpm run typecheck
npm test
npm run lint
pytest
ruff check
tsc --noEmit這類命令主要用於觀察和驗證。即使自動執行，風險也可控。
4. Denylist 覆蓋破壞性和外聯命令
Denylist 命中後會要求使用者批准；官方說明 deny list 優先順序高於 allow list。
推薦覆蓋：
rm
mv
cp -R
git push
git reset
git clean
ssh
scp
rsync
curl
wget
kubectl
terraform
vercel
wrangler
docker push這不是永久禁止，而是強制停下來。真正需要執行時，讓 Cascade 先解釋影響範圍和回復方式。
5. 高風險確認模板
遇到高風險命令，先讓 Cascade 輸出：
這條命令先不要執行。
請說明：
1. 會影響哪些檔案或外部系統
2. 是否可回復
3. 回復方式是什麼
4. 是否有更低風險替代命令
5. 執行後如何驗證
等我確認後再繼續。如果它答不清楚，不執行。
6. 團隊級命令控制
Teams 和 Enterprise 管理員可以設定最高 auto-execution level，也可以設定團隊級 allowlist / denylist。團隊級和個人級列表會合並，deny 優先。
團隊規則：
- 生產儲存庫不開放 Turbo。
- 基礎設施儲存庫預設 Disabled 或 Allowlist Only。
- 部署、遷移、刪除、遠端訪問、外部 API 寫入必須人工確認。
- 失敗命令不要自動重試，尤其是扣費 API、資料庫遷移和部署。
- 每次高風險執行後留下證據：命令、目的、影響物件、結果、驗證。
把這些寫進 root AGENTS.md 或 .windsurf/rules/，讓 Cascade 在任務開始前就看到。
7. Dedicated terminal 也要治理
官方說明 macOS 上 Cascade 有 dedicated terminal，和預設終端分離，並且始終使用 zsh。它會讀取 .zshrc 和其他 zsh 設定，所以 alias 和環境變數可能影響執行。
建議：
- 不把金鑰寫進
.zshrc。 - 把非敏感共享 PATH 放進可複用 shell 檔案。
- 如果普通終端能跑、Cascade terminal 不能跑，先檢查 shell 設定差異。
- 出問題可啟用 Legacy Terminal Profile 回退。
8. 釋出動作必須拆階段
內容站、教學站、開源儲存庫尤其容易把“構建透過”和“可以釋出”混在一起。正確邊界：
- 構建驗證。
- diff 審查。
- 內容和斷點檢查。
- 人工確認。
- 提交。
- 推送。
- 部署或等待平臺自動構建。
不要讓 Cascade 在一次長任務裡從修改一路越過人工審查直接釋出。
官方來源
- Terminal —— 官方 Command、terminal context、auto-execution、allow/deny list、團隊控制和 dedicated terminal。
- Cascade Overview —— 官方 tool calling 和 terminal 能力。
- Guide for Admins —— 官方團隊 feature toggles 和管理員控制。
本篇自檢
- 你的專案預設 auto-execution level 是什麼？
- allowlist 是否只包含低風險命令字首？
- denylist 是否覆蓋刪除、推送、部署、遠端訪問和外聯命令？
- 高風險命令是否有固定確認模板？
- 釋出動作是否拆成驗證、審查、提交、推送幾個階段？