---
title: "Cascade 心智模型"
description: "解释 Cascade 如何结合上下文、计划、工具、终端和 checkpoint 推进任务，避免把它当普通聊天机器人使用。"
verifiedAt: "2026-05-09"
---

Cascade 的正确心智模型是“带项目上下文和工具权限的协作者”。它会读文件、引用终端、调用工具、生成计划、修改代码，并用 checkpoint/revert 管理过程。你给它的不是一句问题，而是一条任务轨迹。

> [!TIP]
> **本篇目标**：建立一套可控的 Cascade 任务循环，让它先找上下文、再计划、再受控执行，而不是凭一句泛泛提示自由发挥。

## 1. Cascade 的任务循环

一个健康的 Cascade 任务循环是：

```mermaid
flowchart LR
    Goal["目标"] --> Context["找上下文"]
    Context --> Mode["选择 Ask / Plan / Code"]
    Mode --> Plan["列计划 / Todo"]
    Plan --> Action["受控工具调用"]
    Action --> Diff["产出 diff / 结果"]
    Diff --> Verify["运行验证"]
    Verify --> Decision["继续 / 回滚 / 提交"]

    style Mode fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Action fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style Decision fill:#dcfce7,stroke:#16a34a,stroke-width:2px
```

你的工作不是看它最后一句总结，而是控制每个环节的边界。

## 2. 先选模式

官方最新模式分为 Ask、Plan、Code：

| 模式 | 该怎么用 | 不该怎么用 |
| --- | --- | --- |
| Ask | 只读解释、定位、比较方案 | 让它偷偷改文件 |
| Plan | 复杂功能、迁移、重构前先产出计划 | 小修小补也强行走长计划 |
| Code | 明确要修改时实施 | 范围不明时直接开写 |

一个任务如果你说不清目标文件和验证方式，先用 Ask 或 Plan。只有范围清楚后再进 Code。

## 3. 上下文不是越多越好

Cascade 可以利用当前文件、打开文件、项目索引、终端选区、Problems panel、previous conversations、web/docs search 和 MCP。上下文越多，不代表判断越准；无关上下文会污染计划，也会增加 quota 消耗。

更好的提示词：

```text
只关注 src/server/auth 目录和这个报错。
不要展开前端目录。
先判断可能根因，再告诉我需要读哪些文件。
```

不好的提示词：

```text
你看看这个项目哪里有问题。
```

后者会让 Cascade 自己猜边界，浪费上下文，也更容易动错文件。

## 4. Plan 是刹车，不是仪式

多文件任务先要 plan。Plan 的作用不是显得流程正规，而是在它写代码前暴露错误假设。

一个可用 plan 应该包含：

- 目标文件。
- 每个文件为什么要改。
- 不会改哪些东西。
- 是否需要命令、MCP、网络或外部服务。
- 验证命令。
- 回滚方式。

如果 plan 里出现你没授权的范围，先纠正，不要让它继续。

## 5. 工具调用要分级

Cascade 的工具调用可以带来速度，也会带来风险。按风险分三类：

| 风险 | 例子 | 控制方式 |
| --- | --- | --- |
| 低风险 | 读文件、搜索、解释、列计划 | 可以放宽，但要求引用证据 |
| 中风险 | 写文件、格式化、运行 lint/test/build | 限定文件和命令，审 diff |
| 高风险 | 删除、迁移、部署、SSH、生产 API、付款、权限变更 | 必须人工确认，最好进 deny list |

官方说明 Cascade 每个 prompt 最多 20 次 **tool calls**（工具调用——Cascade 每读一个文件、跑一条命令、查一次代码索引、调一个 MCP 接口，都算一次）。任务过大时要切分，不要让它靠 continue 一路跑到底。

## 6. Terminal 是验证工具，也是风险入口

终端让 Cascade 能运行 lint、test、build、诊断命令，这是 IDE 内闭环的关键。但终端也能执行危险操作。

推荐边界：

- 默认让 Cascade 先列命令，不直接运行。
- allow list 只放低风险命令，例如 `git status`、`git diff`、lint、test、build。
- deny list 覆盖 `rm`、`git push`、`git reset`、部署、SSH、基础设施和外联命令。
- 终端输出发给 Cascade 前先脱敏。

如果你没配置命令边界，就不要开启高自动化级别。

## 7. Checkpoint 与 git 的关系

Windsurf 支持 checkpoint 和 revert，但商业项目仍以 git 为最终审计面。

建议顺序：

1. 任务前 `git status --short`。
2. 任务中使用 checkpoint。
3. 任务后 `git diff --stat` 和 `git diff`。
4. 需要保留再 commit。

Checkpoint 适合在一次 Cascade 任务内回退；git 适合跨会话、跨人员、跨分支审计。并行 agent 修改同一仓库时尤其要看 git。

## 8. 好提示词模板

```text
你现在是这个项目的协作者。
先只读分析，不要修改文件，不要执行命令。

任务目标：修复用户保存设置后页面不刷新的问题。
范围：src/settings 和 src/api/settings。

输出：
1. 你要读哪些文件
2. 可能根因
3. 最小修改方案
4. 验证命令
5. 风险和不改范围

等我确认后再改。
```

这个模板把目标、范围、动作权限和输出格式都说清楚，Cascade 才容易稳定。

## 官方来源

- [Cascade Overview](https://docs.windsurf.com/windsurf/cascade/cascade) —— 官方 Cascade、tool calling、Todo、checkpoint、revert、Problems 和多会话说明。
- [Cascade Modes](https://docs.windsurf.com/windsurf/cascade/modes) —— 官方 Ask / Plan / Code 模式说明。
- [Terminal](https://docs.windsurf.com/windsurf/terminal) —— 官方终端 auto-execution 和 command lists。
- [Context Awareness Overview](https://docs.windsurf.com/context-awareness/overview) —— 官方上下文检索和 pinning 建议。

## 本篇自检

读完后，你应该能回答：

1. Ask、Plan、Code 分别适合什么任务？
2. 为什么上下文不是越多越好？
3. 一个可用 plan 必须包含哪些内容？
4. 哪些 tool calls 必须人工确认？
5. checkpoint 和 git 的职责边界是什么？

## 接下来去哪

<Cards>
  <Card title="第一次项目闭环" href="/docs/windsurf/understanding/02-first-project-loop" description="把心智模型对齐回真实跑通的任务" />
  <Card title="上下文 / Rules / AGENTS.md" href="/docs/windsurf/understanding/04-context-rules-agents-md" description="搞清 Cascade 看什么 / 不看什么" />
  <Card title="MCP / Skills / Workflows" href="/docs/windsurf/understanding/05-mcp-skills-workflows" description="把工具调用扩展到外部系统时的边界" />
  <Card title="终端命令安全" href="/docs/windsurf/understanding/06-terminal-command-safety" description="Cascade 跑命令前先压住范围" />
  <Card title="Understanding 总览" href="/docs/windsurf/understanding" description="回到学习路径地图" />
</Cards>
