Cascade 心智模型
解釋 Cascade 如何結合上下文、計劃、工具、終端和 checkpoint 推進任務，避免把它當普通聊天機器人使用。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Cascade | 級聯 | Windsurf 的核心 agent。 |
| 上下文感知 | aware | 自動理解專案狀態。 |
| plan-act | 迴圈 | 規劃執行檢查。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你建立 Windsurf Cascade 的心智模型，知道它怎麼工作。
你是 Windsurf Cascade 心智模型顧問。
【角色】
Windsurf Cascade 心智模型顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。
【輸入】
- 我想讓 Cascade 做什麼：___
- 對它執行過程的疑慮：___
- 專案結構：___
- 可用的驗證手段：___
- 經驗水平：___
【工作流程】
1. 講清 Cascade 工作機制
2. 說明它怎麼感知上下文
3. 針對我的任務說明流程
4. 標出把關點
5. 給驗證
【輸出規範】
▌一、工作機制
▌二、上下文感知
▌三、針對我任務的流程
▌四、把關 + 驗證
【硬約束】
- 理解機制再放手
- 關鍵步驟人工確認
- 結果自己核驗
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法Cascade 的正確心智模型是“帶專案上下文和工具許可權的協作者”。它會讀檔案、引用終端、呼叫工具、生成計劃、修改程式碼，並用 checkpoint/revert 管理過程。你給它的不是一句問題，而是一條任務軌跡。
本篇目標：建立一套可控的 Cascade 任務迴圈，讓它先找上下文、再計劃、再受控執行，而不是憑一句泛泛提示自由發揮。
1. Cascade 的任務迴圈
一個健康的 Cascade 任務迴圈是：
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 消耗。
更好的提示詞：
只關注 src/server/auth 目錄和這個報錯。
不要展開前端目錄。
先判斷可能根因，再告訴我需要讀哪些檔案。不好的提示詞：
你看看這個專案哪裡有問題。後者會讓 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 為最終審計面。
建議順序：
- 任務前
git status --short。 - 任務中使用 checkpoint。
- 任務後
git diff --stat和git diff。 - 需要保留再 commit。
Checkpoint 適合在一次 Cascade 任務內回退；git 適合跨會話、跨人員、跨分支審計。並行 agent 修改同一儲存庫時尤其要看 git。
8. 好提示詞模板
你現在是這個專案的協作者。
先只讀分析，不要修改檔案，不要執行命令。
任務目標：修復使用者儲存設定後頁面不重新整理的問題。
範圍：src/settings 和 src/api/settings。
輸出：
1. 你要讀哪些檔案
2. 可能根因
3. 最小修改方案
4. 驗證命令
5. 風險和不改範圍
等我確認後再改。這個模板把目標、範圍、動作許可權和輸出格式都說清楚，Cascade 才容易穩定。
官方來源
- Cascade Overview —— 官方 Cascade、tool calling、Todo、checkpoint、revert、Problems 和多會話說明。
- Cascade Modes —— 官方 Ask / Plan / Code 模式說明。
- Terminal —— 官方終端 auto-execution 和 command lists。
- Context Awareness Overview —— 官方上下文檢索和 pinning 建議。
本篇自檢
讀完後，你應該能回答：
- Ask、Plan、Code 分別適合什麼任務？
- 為什麼上下文不是越多越好？
- 一個可用 plan 必須包含哪些內容？
- 哪些 tool calls 必須人工確認？
- checkpoint 和 git 的職責邊界是什麼？