---
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="/zh-Hant/docs/windsurf/understanding/02-first-project-loop" description="把心智模型對齊回真實跑通的任務" />
  <Card title="上下文 / Rules / AGENTS.md" href="/zh-Hant/docs/windsurf/understanding/04-context-rules-agents-md" description="搞清 Cascade 看什麼 / 不看什麼" />
  <Card title="MCP / Skills / Workflows" href="/zh-Hant/docs/windsurf/understanding/05-mcp-skills-workflows" description="把工具呼叫擴充套件到外部系統時的邊界" />
  <Card title="終端命令安全" href="/zh-Hant/docs/windsurf/understanding/06-terminal-command-safety" description="Cascade 跑命令前先壓住範圍" />
  <Card title="Understanding 總覽" href="/zh-Hant/docs/windsurf/understanding" description="回到學習路徑地圖" />
</Cards>
