Cascade 心智模型
解釋 Cascade 如何結合上下文、計劃、工具、終端和 checkpoint 推進任務，避免把它當普通聊天機器人使用。
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 的職責邊界是什麼？