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 的职责边界是什么？