---
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="/docs/windsurf/understanding/05-mcp-skills-workflows" description="命令边界压住后，再扩展工具与流程" />
  <Card title="模型与用量策略" href="/docs/windsurf/understanding/07-model-usage-strategy" description="把命令风险与模型选择联动起来" />
  <Card title="工具对比" href="/docs/windsurf/understanding/08-windsurf-vs-cursor-claude-code-codex" description="不同工具的命令边界差异" />
  <Card title="官方终端控制" href="/docs/windsurf/official/03-terminal-command-control" description="对照官方 Command / auto-execution / lists 文档" />
  <Card title="官方团队治理" href="/docs/windsurf/official/07-teams-troubleshooting" description="团队级别的命令策略与排障" />
  <Card title="Understanding 总览" href="/docs/windsurf/understanding" description="回到学习路径地图" />
</Cards>
