夜雨聆风Cursor 7 月 22 日推出 Router。表面上看，这是一次模型路由和成本优化；放到真实工作流里看，它提醒的是另一件事：AI 工具正在替你分配任务，而不只是替你回答问题。
Cursor 官方说，Router 会根据查询、上下文、任务复杂度和领域，把请求路由到更合适的模型。简单任务交给性价比更高的模型，复杂长周期问题交给更强的推理模型。抢先体验里，一些企业客户在 Auto 路由请求上的成本，相比全部走高价模型，节省了 30% 到 50%。
这些当然是好事。问题不在 Router 本身，也不在自动模式本身。真正需要警惕的是：当工具越来越会“判断任务该怎么做”，使用者很容易忘记先判断“这个任务到底该不该继续扩大”。
一句话：自动模式不是不能用，危险在于它会把“局部修复”，顺手推成“交付面变更”。
图1：第一轮看起来总是很顺，真正出问题的，往往是第二轮开始的范围扩散。
最典型的坑，是从一个按钮开始的
你本来只想改一个“导出报表”按钮：位置从右上角挪到底部，文案从“导出”改成“下载数据”。这一步很小，AI 通常也能很快改完。
但你接着说：“顺手把移动端间距也调一下。”它就开始碰布局容器。你再说：“这个按钮另外两个页面也复用。”它会给公共组件加参数。再往后，类型定义、hook、测试、埋点、接口字段、权限判断，都可能被带进去。
最后你以为自己只是改了一个按钮，实际已经动到前端组件、状态逻辑、接口校验和测试链路。问题也就在这里：每一步单独看都有理由，合起来却未必可验收。
按钮要对齐、组件要复用、类型要收敛、测试要通过，这些都没错。错的是你没有在第一轮之前定义边界，也没有在第二轮开始时重新确认范围。
自动模式最擅长让人放松。第一轮它很顺，第二轮你觉得“再修一点也行”，第三轮它已经把上下文带到另一个任务里，你却还在用原来的验收标准看它。
图2：一旦从页面改动扩到组件、状态、接口和测试，自动模式就不再是“省事”，而是在放大变更面。
Router 优化的是任务分配，不是需求边界
Cursor Router 这次真正值得看的地方，不只是“换哪个模型更省钱”，而是“工具开始先判断任务类型，再决定由谁来做”。这意味着 AI 工具正在从生成器变成分发器。
分发器的价值很明确：简单任务不用占最强模型，复杂任务也能交给更合适的能力，速度和成本都能被压下来。
但它解决的是“怎么分配任务”，不是“这个任务该不该扩大”。如果你没有先说清楚边界，工具越聪明，越容易把错误的范围也优化得很顺手。
真实项目里，最贵的从来不是第一轮改动，而是后面几轮连锁反应：公共组件改了，权限逻辑动了，接口字段变了，测试失败了，回滚链路也不清楚。到这一步，已经不是“AI 帮你省时间”，而是你要花时间证明它没有把事情弄大。
所以判断标准不要再停在“它改对了吗”，而要升级成三个问题：有没有扩大范围、有没有跨越边界、还可不可以验收。
开自动模式前，先写一张边界卡
我现在更愿意把自动模式当成“局部执行器”，而不是“需求负责人”。它可以执行，但不应该替你决定范围。
开之前，至少写清楚六件事：这次只解决什么问题；允许改哪些文件；禁止碰哪些层；最多改几个文件；怎么验证成功；失败以后怎么回退。
如果你原本只想改页面按钮，就把边界写死：只改这个页面和按钮样式，不改公共组件，不改接口，不改权限，不新增埋点，不重写测试。
如果它一开始就说要改很多文件，或者提出要碰接口、权限、数据结构、支付、部署脚本，那就不要直接放行。先让它解释为什么必须跨层，再决定是否拆成新任务。
图3：出现这些信号时，不要继续追着修，先把 diff 和需求边界收回来。
这6个信号一出现，就先停
1. 修改文件从 1 个变成 5 个：任务开始从单点改动变成系统性变更，先看 diff，再决定要不要继续。
2. 开始碰接口、权限、数据结构：风险已经从页面层升级到系统层，必须人工确认。
3. 测试失败后还在继续自动修：它很可能进入返工循环，应该回到需求，重新拆任务。
4. 新问题开始覆盖旧问题：上下文已经被扩散带偏，最好回到上一个稳定点。
5. 解释不清改了什么：当前修改已经不可验收，先写变更说明，再谈提交。
6. 连回滚方案都说不出来：说明它已经不是修复，而是在赌结果，先补回滚，再谈合并。
自动化真正有价值的前提，是边界还在
我不是反对自动模式。相反，边界清楚、验证简单、影响面小的任务，自动模式确实能节省大量重复劳动。
但它不适合替你定义需求，不适合替你承担交付责任，也不适合在测试失败后无限追着补洞。
以后使用自动模式，可以先记住一句话：让 AI 自动执行，但不要让 AI 自动扩大任务。
你用 Cursor、Codex、Claude Code 或其他 AI 工具时，最怕它哪一种“自动扩大范围”？是改文件太多、碰接口权限，还是测试失败后一直自修？欢迎留言说一个真实场景。