你给 Composer 抛一个有分量的任务：重构 auth 流、把一个类型变更传播到 30 个文件、设计一份迁移方案。模型选择器开着 Auto，回来的却是只改了两个文件、漏掉其它、还自信宣告”完成”的浅改动。手动切到 Sonnet 4.6 或 Opus 4.7，同一份 prompt 给出一份扎实的跨文件 patch。
最快修复： 凡是 “refactor / design / migrate / plan” 这类任务，点聊天输入框底部的模型名，选 Sonnet 4.6（架构或全新设计就选 Opus 4.7）。Auto 适合做 typo、单文件改动、“解释一下这段函数”，不适合跨文件工作。
为什么会这样：Auto 是在 intelligence、cost、reliability 三者之间做权衡，它只能用看得见的信号（prompt 长度、附带文件、关键词、服务器健康度）。它看不见你的意图；而且按官方文档，Auto 走的是一个独立、更便宜的用量池，所以请求”看起来小”时它就偏向小模型。修这件事需要三方面：配置、提示卫生、知道什么时候根本不该用 Auto。
Auto 实际怎么路由（2026 年 6 月）
旧的 “Fast Requests” 心智模型有两点是错的：
- Auto 逐请求挑模型，且取自便宜池。 Cursor 文档写明 Auto 会”在 intelligence、cost-efficiency、reliability 之间挑最合适的模型”。它从一个专门的 Auto 用量池计费（截至 2026 年 6 月约
$1.25/M输入、$6/M输出），远比直接调前沿模型便宜。便宜池 + “看起来很简单”的信号，正好让难任务落到小模型上。 - 计费是用量额度，不是 Fast Requests 了。 Cursor 已在 2025 年年中废弃了固定的 “fast premium requests” 计数。付费套餐（截至 2026 年 6 月，Pro
$20、Pro+$60、Ultra$200每月）改成给一个按美元计的用量池。关键在于：付费套餐里 Auto 用量基本是无限的，且不消耗这个用量池——这恰恰是路由器乐于走 Auto 的原因。
所以”Auto 坏了”多半是误判。Auto 是为小任务校准的，它在尽职；问题在于你拿它去路由它从没被调过的工作。
常见原因
按 Auto 路由偏弱的发生频率排序。
1. Prompt 太短，体量远超字面长度
Auto 把 prompt 长度当复杂度代理。Refactor auth to use JWT 才 24 个字符，路由看到的是一个小请求、自然挑快速模型——尽管这几个字背后是巨量工作。
如何判断：你的 prompt 只有一行，任务却跨多文件，结果浅尝辄止。长、明确的 prompt 能稳定得多地触发更强的模型。
2. 聊天没附任何上下文
@-上下文为空时，Auto 默认这是泛泛的问题，路由到小模型。哪怕 prompt 很长但没上下文，也会被读成”大概率是问答轮”。
如何判断：输入框上方的上下文小标签里，attached files / folders / docs 是空的。
3. 任务类型不匹配 Auto 的启发式
Auto 的路由针对常见形态调过：小段 inline edit、单文件 Q&A、简单补全。“写迁移”、“设计接口”、“规划架构”不在它的形态里，结果就被低估。Cursor 官方与社区测试者都把 Auto 形容成一堆”various cheap models”的混合，“unless you’re doing anything novel”（除非你做全新的东西）才会出问题。
如何判断：任务是设计为主、或跨文件的，但表述像随手一问。输出听起来合理但不深。
4. 聊天历史污染了路由
Auto 会把当前会话作为信号之一。如果前几轮都是琐事（“加一行 log”、“重命名变量”），下一轮哪怕是大任务，也带着”这是个小任务会话”的先验。
如何判断：开一个新 chat、用完全相同的 prompt，答案明显更好。
5. 代码库索引没建完
索引在进行中或过期时，@codebase 上下文很薄。Auto 看到的有效上下文就小，路由就低。参考 Cursor 索引迟迟跑不完。
如何判断：状态栏显示还在索引；或者 @codebase 对已知关键词命中很少。
6. Cursor 悄悄回退到了 Auto
有一个反复出现的 bug：Cursor 会把你手动选的模型偷偷换回 Auto，尤其在某个模型性能下降之后、或 Auto 路由出事故期间（Cursor 状态页在 2026 年 6 月 16 日记录过一次 Auto 路由降级）。你以为在用 Opus 4.7，回复下方的标签却写着 Auto。
如何判断：看真正那条 assistant 回复下方的模型标签，而不是看选择器。如果你明明选了别的、它却显示 Auto，就是这一类。
我是哪一类？
| 症状 | 最可能的原因 | 跳到 |
|---|---|---|
| 一行 prompt、多文件任务、结果浅 | Prompt 太短（1） | 第 2 步 |
没附任何 @files / @folders | 上下文为空（2） | 第 2 步 |
| ”design / migrate / plan” 任务却随手一问 | 启发式不匹配（3） | 第 1、5 步 |
| 同样 prompt 在新 chat 里更好 | 历史污染（4） | 第 3 步 |
@codebase 命中很少、状态栏在索引 | 索引过期（5） | 索引指南 |
| 你选了模型，标签却显示 Auto | 悄悄回退（6） | 第 1 步 |
开始之前
- 记下 Auto 实际挑了什么模型：把鼠标悬在回复上，或看 assistant 回复下方的模型标签（不是看选择器）。
- 确认索引已建完、当前打开的工作区是你以为的那个。
- 把 prompt 文本存下来——你要换成显式选模型再跑一次。
- 瞄一眼 Cursor 状态页，排除正在发生的 Auto 路由事故。
分步修复
按从快到彻底排序。
第 1 步：难任务直接把模型选择器切到非 Auto
最小成本修复。点聊天输入框底部的模型名（或 Cmd+K inline edit 弹窗左上角的下拉）：
聊天输入框 -> 模型名 -> Sonnet 4.6（设计/规划用 Opus 4.7）Auto 是 “修个 typo”、“解释一下这段函数” 的好默认；对 “refactor”、“design”、“migrate”、“plan” 或任何跨文件任务都不是。养成习惯：prompt 里出现重型动词，就手动选模型。如果选完模型后回复下方的标签仍写着 Auto，说明你撞上了悄悄回退的 bug（原因 6）——重新选一次再发。
第 2 步：把 prompt 写长，显式附上下文
模糊 prompt + 空上下文 = 路由降档。重写：
Refactor src/auth/* from session cookies to JWT.
@src/auth @src/middleware @docs/auth-design.md
Constraints:
- Keep the public API (login, logout, refresh) unchanged
- Update tests in src/auth/__tests__/
- Use jose for signing, not jsonwebtoken
- Migration plan for existing session DB rows
Produce a step-by-step plan first, then execute.长度 + 附目录 + 结构化约束，三个一起把 Auto 往强模型推。即使继续用 Auto，路由也常常对了。
第 3 步：重要任务都开新 chat
长会话带历史偏置。任何认真的工作，开一个干净的 Composer chat（Cmd+N / Cmd+L），把大 prompt 粘进去。路由就只针对它本身打分，不再被会话里的小任务历史拖低。
第 4 步：给工程仓库钉一个默认模型
Cursor 基于 VS Code，所以按项目的设置放在仓库里提交的 .vscode/settings.json。聊天默认这一项是可靠的：
{
"cursor.chat.defaultModel": "claude-sonnet-4.6"
}这样 auth 重构的仓库默认开在 Sonnet，写文档的仓库可以保留 Auto。Composer 专用的那个键在不同 Cursor 版本间改过——如果 cursor.composer.defaultModel 这行不生效，就改去 Settings -> Models 设默认、再逐个 chat 选模型。改完 workspace 设置后重启 Cursor 让它重新加载。
第 5 步：两阶段——强模型出计划，Auto 执行
想让长执行省钱，就用强模型先写一份详细计划，再交给 Auto 执行：
Pass 1（Opus 4.7）：
Produce a detailed step-by-step plan for the JWT migration. List every file to
touch and the diff intent for each. Do not execute yet.
Pass 2（Auto）：
Execute the plan from the previous message exactly. Do not reorder steps.
For each step, edit the named file and report back.显式的计划文字本身，就替代了 Auto 推断不出来的那部分路由信号。
第 6 步：路由依然错，提交反馈
Cursor 会用汇总反馈来调 Auto。糟糕的路由决定之后，给那条回复点踩（thumbs-down），并在评论里说明 Auto 把一个复杂任务路由弱了。没有按账号”强制走强模型”的开关，所以这是一根慢杠杆——真正能修好当下这次会话的，是第 1 步和第 4 步。
如何确认已修复
- 同样的 prompt 强制改成 Sonnet 4.6：输出深度明显高于之前 Auto 的版本，且回复下方的模型标签写的是
claude-sonnet-4.6而不是auto。 - 一个明显琐碎的 prompt（
rename foo to bar in this file）用 Auto 跑：挑了快速模型且结果正确。Auto 并没坏，它就是为小任务校准的。 - 跨文件重构 + 显式上下文 + workspace 钉好的默认模型，现在能稳定地一次就调用强模型。
长期预防
- 工程仓库里 Composer 默认走手动选模型；Auto 留给闲聊式 Q&A。
- 哪怕”自己心里清楚”，也要把 prompt 写得更长、更具体——路由器不懂你。
- 跨文件任务一律附
@folder或@codebase。 - 大迁移走 plan-then-execute 两阶段。
- 留意每月用量额度，别让快见底的用量池变成隐藏变量（Settings -> Usage）。
- 准备一个可复用的 “hard task template” 片段，已预填好结构和约束。
常见误区
- 以为 “Auto 等于可用的最强模型”。Auto 是”路由器觉得够用的最便宜模型”，目标不同。
- 同样的 prompt 重跑期待结果不一样：输入一样，路由也一样。
- 只把默认模型设在 user 设置：会泄漏到所有项目。优先用按项目的
.vscode/settings.json。 - 同一会话里既塞琐事又塞重活：琐事会把重活的路由拉低。
- 忘了索引深度也影响路由。索引过期 = 上下文薄 = 路由弱。
- 把 Opus 4.7 用量烧在 Sonnet 4.6 同样能搞定的任务上，到真正需要时用量见底。
常见问题
Q：能强制 Auto 总挑强模型吗？
不能——Auto 就是路由器本身，也没有按账号的覆盖开关。但把 cursor.chat.defaultModel 钉好（或逐个 chat 选模型），对真正要紧的工作等效于绕过它。
Q：同样的 prompt 在不同日子路由不一样，为什么？
Cursor 文档说 Auto 会把当前服务器可靠性也算进去，遇到宕机或限速会临时切换模型，再叠加逐请求的复杂度打分。它不是确定性的；一次 Auto 路由事故（比如 2026 年 6 月 16 日那次）可能让行为变样好几个小时。
Q：prompt 越长路由越好吗？
长度是其中一个信号。具体性、附上下文、出现 “design / refactor / plan” 这类动词更重要。500 字的模糊 prompt，路由不如一个带 @folder 上下文的 200 字精准 prompt。
Q：我是不是干脆永远用 Opus 4.7？
不要——Opus 烧用量额度最快。模型要匹配任务：Sonnet 4.6 是跨文件改动的主力，Opus 4.7 留给真正需要深推理的全新设计。
Q：我选了模型，回复却显示 Auto，为什么？
那是已知的悄悄回退 bug（原因 6）。某个模型性能下降时、或路由事故期间，Cursor 有时会退回 Auto。重新选你的模型再发一次，并看一眼状态页。