Cascade Guide
很多人第一次用 Cascade，会本能地把它当成一个更强的 chat panel。这样也能用，但通常用两天就会觉得“好像还行，可也没有神到哪里去”。真正把它用顺手的人，脑子里的模型不一样: 他们把 Cascade 当成一个会协助推进任务的接口，而不是一个负责聊天的窗口。
官方文档现在把它定义得也很直接。它不只是在编辑器里回答问题，还会结合 Code / Chat 模式、terminal、preview、MCP、search、checkpoints、reverts 这些能力继续往下做事。说得更白一点，它擅长的不是“讲明白”，而是“边讲边往前推”。
它到底在什么场景下最值钱
如果你只是问知识点，比如某个框架概念、某个语法细节，其实不一定非要用 Cascade。它真正值钱的场景，通常带一点工程动作感。
比如你刚接手一个项目，想先知道认证流程怎么串起来，再顺手修一个相关 bug；或者你已经有 build error、runtime error，想让它先定位，再给出最小修复路线；又或者你明确知道要加一个页面、补一个 loading state、接一个 API，只是懒得自己从头把文件关系捋一遍。这些任务有一个共同点: 目标是清楚的，改动可以审，做完也能验。
我更建议的使用姿势
如果任务稍微复杂一点，不要第一句就说“帮我做掉”。先逼它暴露理解。
我更常用的顺序是：
- 先让它解释 current state
- 再让它列 plan
- 再让它说会碰哪些文件
- 最后才允许它动手
这听起来像多了一步，实际上是在省后面的 review 时间。很多人觉得 AI IDE “前面快，后面累”，问题往往就出在第一步没让它先把理解摊出来。
一个典型例子
如果你直接说：
Add a billing settings page.
它大概率也会开始干活，但你无法判断它到底准备怎么接现有 API、会不会顺手改 public props、会不会把文件结构搞乱。
我更偏向这样说：
Add a billing settings page.
First explain the current settings flow.
Then list the files you plan to change.
Do not edit until I can review the plan.
同样是一个需求，后者的结果通常更稳。不是因为 prompt 更“高级”，而是因为边界更像真实工程。
@ 上下文什么时候真有用
Cascade 会自动抓上下文，但它不是神谕。你知道关键文件时，就直接给 @Files；你只想让它围绕某个函数或类工作，就给 @Code；手上有最新报错或测试输出，就把 @Terminal 丢进去。这样做的价值不是喂更多信息，而是减少它把注意力分散到不相关地方。
这件事在大仓库里特别明显。上下文一旦太散，它回答时会像懂了，真正改起来却总是差半步。
什么时候我不会直接交给它
有几类任务我一般不会让 Cascade 第一时间接手。比如需求本身还没定义清楚，比如安全、基础设施这种高风险改动，比如“全面优化一下这个项目”这种根本没法验收的说法。不是它不能碰，而是你连“什么叫做完”都没说清楚，最后一定会变成大范围低质量改动。
真实使用里的分水岭
Cascade 好不好用，分水岭其实不是模型本身，而是你会不会拆任务。会拆任务的人，用它会越来越快；不会拆任务的人，用久了只会觉得它越来越吵。
所以我对它的结论很简单：它确实值得学，但不是因为它会自动做很多事，而是因为它会逼你把任务定义得更像工程任务。一旦你开始这么用，它才会从“还不错的聊天工具”变成“真正省时间的协作层”。
