终端命令安全
给 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 是否覆盖删除、推送、部署、远程访问和外联命令？
- 高风险命令是否有固定确认模板？
- 发布动作是否拆成验证、审查、提交、推送几个阶段？