AI 编程工具的瓶颈在哪里
早期 AI 编程助手的工作方式是：你打开一个文件，它根据这个文件的内容给你建议。这在写独立函数时很好用，但真实开发不是这样——改一个接口，要动调用方、类型定义、测试、文档，涉及七八个文件。
这时你会发现自己在做一件荒谬的事：手动找出所有相关文件，一个个贴给 AI，然后它给的建议还得你自己合并回去。工具号称提效，实际上你成了它的上下文搬运工。
Cascade 的核心改进就是消除这个搬运环节：它自己去找相关代码，自己规划改动顺序，改完给你一个完整的变更清单。
第一步：安装与初始配置
下载安装后首次启动需要登录。完成后建议先做三件事：
- 导入已有编辑器的配置和快捷键，减少适应成本
- 打开项目根目录，等待索引建立完成（状态栏会有提示）
- 检查模型设置，选择合适的模型档位
第二点很重要。索引没建完就用，Cascade 的检索会不完整，容易漏掉相关文件，导致改了一部分。首次打开大项目时耐心等几分钟。
第二步：把项目规则写进配置文件
这一步能显著提升生成代码的可用性。在项目根目录创建规则文件，写明项目约定：
项目背景：这是一个电商后台，前端用 React，后端用 Node.js
代码规范：使用 TypeScript 严格模式，禁止 any
命名约定：组件用大驼峰，工具函数用小驼峰
状态管理：统一使用 Zustand，不要引入 Redux
测试：新增业务逻辑必须写单测，放在同目录的 __tests__ 下
写这些规则花十分钟，但能省掉每次对话都要重复的说明。而且规则是持久的，团队成员共享同一个文件，AI 给所有人的建议风格一致。
最有用的是禁止项。告诉 AI 不要做什么，比告诉它要做什么更能减少返工。
第三步：用 Cascade 做跨文件改动
这是主场景。操作方式是直接描述目标，不要指定文件：
推荐说法：把用户信息的手机号字段改为支持国际区号的格式，需要改数据库模型、接口校验、前端表单和对应的测试。
不推荐说法：帮我改一下 user.ts 这个文件。
区别在于，前者让 Cascade 自己去检索全部相关位置，后者把它限制在单个文件里，你就享受不到它最强的能力了。
提交后它会先给出一个计划：要改哪些文件、每个文件改什么。这个计划一定要看。如果它漏掉了某个调用点，此时指出来成本最低。
第四步：审阅变更，别直接全盘接受
Cascade 执行完会列出所有改动，逐文件显示差异。审阅要点：
- 看改动范围：有没有动了不该动的文件。范围异常扩大通常是检索跑偏了，应该让它撤销重来
- 看删除的内容：AI 最容易犯的错是重写时丢掉原有逻辑分支。重点核对被删掉的行
- 看边界处理：空值、异常、并发这些地方，AI 生成的代码常常过于乐观
- 看依赖变更：如果它擅自加了新依赖，要评估是否值得引入
经验法则：改动超过 5 个文件或 200 行，就分批处理。一次性改太多，审阅质量会急剧下降，而审阅恰恰是不能省的步骤。
第五步：终端命令的审批
Cascade 可以执行终端命令，例如运行测试、安装依赖。涉及写操作或不可逆操作时务必逐条确认。
需要特别警惕的命令类型：删除文件、强制推送、数据库迁移、批量覆盖。这些命令一旦执行，撤销成本极高。
建议在项目规则里明确写：禁止执行删除类命令和强制推送，需要执行时先告知我具体命令内容。
第六步：用对话历史做增量迭代
Cascade 保留了任务上下文，改完一轮后可以直接追加要求：刚才的改动里，前端表单的错误提示不够友好，优化一下。它知道刚才指的是什么，不需要你重新描述背景。
但上下文过长后质量会下降。一个任务聊了十几轮还在打补丁，说明最初的计划有问题，不如回滚重新规划。
第七步：什么时候不该用
诚实讲，有些场景它帮不上忙，甚至添乱：
- 需要深度领域知识的业务逻辑，它写的往往是看起来对但实际错的通用实现
- 性能敏感的代码，它倾向于写可读性优先但效率一般的实现
- 涉及复杂并发和状态同步的场景，出错率高
- 你不熟悉的技术栈——因为你无法判断它对不对
最后一条最关键。AI 编程工具放大的是你的判断力，不是替代它。在你无法判断对错的领域使用，等于把风险后置。
常见问题与误区
- 问：为什么它找不到某个文件？检查索引是否完成，以及该文件是否被忽略规则排除。索引配置里可能需要手动加入。
- 误区：让它一口气重构整个模块。大范围重构要拆成多个小任务逐步推进，每步验证通过再继续。
- 问：生成的代码跑不起来？把完整报错信息贴给它，不要只描述现象。错误信息是它定位问题最有效的输入。
- 误区：不写项目规则靠它猜。没有规则约束时，它会按最常见的社区写法生成，与你的项目风格可能格格不入。
- 问：改动出问题怎么回退？把改动纳入版本控制，每次让 AI 改动前先提交一次。这是唯一可靠的后悔药。
效率数据与实测结论
以一个跨 6 个文件的接口字段调整为例：手工方式约 45 分钟，包括查找调用点、逐个修改、跑测试；使用 Cascade 约 15 分钟，其中 8 分钟用于审阅变更。整体提速约 3 倍。
但要注意，提速幅度高度依赖任务类型。样板代码、结构调整这类任务能提效 3 到 5 倍；复杂业务逻辑几乎没有提升，有时因为要反复纠正反而更慢。认清边界，才能把它用在真正划算的地方。