---
title: "終端命令安全"
description: "給 Windsurf Cascade 終端自動執行設定一個商業專案可用的安全策略，覆蓋 allowlist、denylist、Turbo、團隊上限和人工確認。"
verifiedAt: "2026-05-09"
---

Windsurf 的終端能力很有用，也最容易出事故。商業專案裡，命令安全不是“相信 AI 會判斷”，而是把自動執行範圍壓到低風險命令，把破壞性命令、外部系統命令和生產命令強制人工確認。

> [!TIP]
> **本篇目標**：給個人專案和團隊專案各設計一套可落地的 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` 也可能被自動接受。

推薦起點：

```text
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。

推薦覆蓋：

```text
rm
mv
cp -R
git push
git reset
git clean
ssh
scp
rsync
curl
wget
kubectl
terraform
vercel
wrangler
docker push
```

這不是永久禁止，而是強制停下來。真正需要執行時，讓 Cascade 先解釋影響範圍和回復方式。

## 5. 高風險確認模板

遇到高風險命令，先讓 Cascade 輸出：

```text
这条命令先不要执行。
请说明：
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. 釋出動作必須拆階段

內容站、教程站、開源儲存庫尤其容易把“構建透過”和“可以釋出”混在一起。正確邊界：

1. 構建驗證。
2. diff 審查。
3. 內容和斷點檢查。
4. 人工確認。
5. 提交。
6. 推送。
7. 部署或等待平臺自動構建。

不要讓 Cascade 在一次長任務裡從修改一路越過人工審查直接釋出。

## 官方來源

- [Terminal](https://docs.windsurf.com/windsurf/terminal) —— 官方 Command、terminal context、auto-execution、allow/deny list、團隊控制和 dedicated terminal。
- [Cascade Overview](https://docs.windsurf.com/windsurf/cascade/cascade) —— 官方 tool calling 和 terminal 能力。
- [Guide for Admins](https://docs.windsurf.com/windsurf/guide-for-admins) —— 官方團隊 feature toggles 和管理員控制。

## 本篇自檢

1. 你的專案預設 auto-execution level 是什麼？
2. allowlist 是否只包含低風險命令字首？
3. denylist 是否覆蓋刪除、推送、部署、遠端訪問和外聯命令？
4. 高風險命令是否有固定確認模板？
5. 釋出動作是否拆成驗證、審查、提交、推送幾個階段？

## 接下來去哪

<Cards>
  <Card title="MCP / Skills / Workflows" href="/zh-Hant/docs/windsurf/understanding/05-mcp-skills-workflows" description="命令邊界壓住後，再擴充套件工具與流程" />
  <Card title="模型與用量策略" href="/zh-Hant/docs/windsurf/understanding/07-model-usage-strategy" description="把命令風險與模型選擇聯動起來" />
  <Card title="工具對比" href="/zh-Hant/docs/windsurf/understanding/08-windsurf-vs-cursor-claude-code-codex" description="不同工具的命令邊界差異" />
  <Card title="官方終端控制" href="/zh-Hant/docs/windsurf/official/03-terminal-command-control" description="對照官方 Command / auto-execution / lists 文件" />
  <Card title="官方團隊治理" href="/zh-Hant/docs/windsurf/official/07-teams-troubleshooting" description="團隊級別的命令策略與排障" />
  <Card title="Understanding 總覽" href="/zh-Hant/docs/windsurf/understanding" description="回到學習路徑地圖" />
</Cards>
