你给 Composer 抛一个有分量的任务：重构 auth 流、把一个类型变更传播到 30 个文件里、设计一份迁移方案。模型选择器开着 “Auto”，回来的却是只修了两个文件、漏掉其它、还自信地宣告”完成”的浅改动。手动切到 Sonnet 4.6 或 Opus 4.7，同一份 prompt 给出一份扎实的跨文件 patch。Auto 是在用它能看到的信号（prompt 长度、文件数、关键词）做成本-延迟权衡，看不见你的意图。修这件事需要三方面：配置、提示卫生、知道什么时候根本不应该用 Auto。
常见原因
按 Auto 路由偏弱的发生频率排序。
1. Prompt 太短，体量远超字面长度
Auto 把 prompt 长度当复杂度代理。“Refactor auth to use JWT” 才 30 多个字符，路由看到的是一个小请求、自然挑快速模型——尽管这 30 个字符背后是巨量工作。
如何判断：你的 prompt 只有一行，任务却跨多文件，结果浅尝辄止。长、明确的 prompt 能稳定触发更强的模型。
2. 聊天没附任何上下文
@-上下文为空时，Auto 默认这是泛泛的问题，路由到小模型。哪怕你的 prompt 写得很长，“无上下文”就等于”大概率是问答轮”。
如何判断：聊天侧栏里 attached files / folders / docs 是空的。Composer 的 “Working with” 行也是空的。
3. Fast Requests 配额充足，倾向小模型
Fast Request 配额还很高时（账单周期早期），Auto 倾向用便宜快的模型——因为还撑得起。配额消耗后，有时反而会升档。直觉之外的现象：到月底反而路由更好。
如何判断：同一 prompt 在月初和月底给出明显不同质量的回复，且你并没有手动 Cursor: Reset Fast Requests。
4. 任务类型不匹配 Auto 的路由启发式
Auto 的启发式针对常见模式：小段 inline edit、单文件 Q&A、简单补全。“写迁移”、“设计接口”、“规划架构”这种不在它的模式里，结果就被低估。
如何判断：任务是设计为主、或跨文件的，但表述像随手一问。输出听起来合理但不深。
5. 聊天历史污染了路由
Auto 会把聊天历史作为信号之一。如果你前 5 轮都是琐事（“加一行 log”、“重命名变量”），下一轮哪怕是大任务，也带着”这是个小任务会话”的先验。
如何判断：开一个新 chat、用完全相同的 prompt，答案明显更好。
6. 代码库索引没建完
索引在进行中或过期时，@codebase 上下文很薄。Auto 看到的有效上下文就小，路由就低。参考Cursor 索引迟迟跑不完。
如何判断：状态栏显示还在索引；或者 @codebase 对已知关键词的命中很少。
开始之前
- 记下 Auto 实际挑了什么模型——把鼠标悬在回复上，或看 assistant 消息下的模型标签。
- 记下当前 Fast Request 余额（Settings -> General -> Usage）。
- 确认索引已建完、当前工作区是你以为的那个。
- 把 prompt 文本存下来——你要换成显式选模型再跑一次。
需要收集的信息
- prompt 原文。
- 作为上下文附上的 files / folders / docs。
- Auto 实际选中的模型（assistant 消息下方显示）。
- 这是新 chat 还是长会话的延续。
- 你的订阅档次（Free、Pro、Business）——路由池不同。
- 距离账单重置的时间。
分步修复
按从快到彻底排序。
第 1 步：难任务直接把模型选择器切到非 Auto
最小成本修复：
Composer 模型下拉 -> Sonnet 4.6（或对设计/规划用 Opus 4.7）Auto 是 “修个 typo”、“解释一下这段函数” 的好默认；对 “refactor”、“design”、“migrate”、“plan” 或任何跨文件任务都不是。养成习惯：prompt 里出现重型动词，就手动选模型。
第 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
长会话带历史偏置。任何认真的工作：
Cmd+N（或 Cmd+L）-> 新 Composer chat把大 prompt 粘到干净上下文里。路由就只针对它本身打分。
第 4 步：在 workspace 级设默认模型
在 .cursor/settings.json 或 workspace 设置里：
{
"cursor.composer.defaultModel": "claude-sonnet-4.6",
"cursor.chat.defaultModel": "claude-sonnet-4.6"
}按项目固定。Auth 重构的仓库默认 Sonnet，写文档的仓库可以保留 Auto。
第 5 步：两阶段——强模型出计划，Auto 执行
想让长执行省钱，就用强模型先写一份详细计划，再交给 Auto 执行：
阶段 1（Opus 4.7）：
为 JWT 迁移产出一份分步计划。列出每个要改的文件以及差异意图，先不动手。
阶段 2（Auto）：
完全按上一条消息中的计划执行。不要重排序步骤。每一步针对指定文件做修改并汇报。计划文字本身就替代了 Auto 推断不出来的那部分路由信号。
第 6 步：路由依然错，提交反馈
Cursor 的 Auto 路由会用会话遥测改进。糟糕的路由决定之后：
Composer 消息 -> "..." 菜单 -> "This was the wrong model"这个反馈会对你账号里类似的未来 prompt 调路由。
验证
- 同样的 prompt 强制改成 Sonnet 4.6——输出深度明显高于之前 Auto 的版本。
- 一个明显琐碎的 prompt（“把这文件里的 foo 改成 bar”）用 Auto 跑，挑了快速模型且结果正确。Auto 并没坏，它就是为小任务校准的。
- 跨文件重构 + 显式上下文 + workspace 默认模型，现在能稳定调用强模型。
长期预防
- 工程仓库里 Composer 默认走手动选模型；Auto 留给闲聊式 Q&A。
- 哪怕”自己心里清楚”，也要把 prompt 写得更长、更具体——路由器不懂你。
- 跨文件任务一律附
@folder或@codebase。 - 大迁移走 plan-then-execute 两阶段。
- 每月检查一次 Fast Request 使用，避免配额状态变成隐藏路由变量。
- 准备一个 “hard task template” 片段，已经预填好结构和约束。
常见误区
- 以为 “Auto 等于最强模型”。Auto 是”路由器觉得够用的最便宜模型”，目标不同。
- 同样的 prompt 重跑期待结果不一样：输入一样，路由也一样。
- 把
cursor.composer.defaultModel设在 user 设置而不是 workspace：会泄漏到所有项目。 - 同一会话里既塞琐事又塞重活：琐事会把重活的路由拉低。
- 忘了索引深度也影响路由。索引过期 = 上下文薄 = 路由弱。
- 把 Opus 4.7 用在 Sonnet 4.6 同样能搞定的任务上，到真正需要的时候没配额了。
常见问题
Q：能强制 Auto 总挑强模型吗？
不能直接强制——Auto 就是路由器本身。但把 cursor.composer.defaultModel 钉到你想要的强模型，等效于绕过它。
Q：同样的 prompt 在不同日子里路由不一样，为什么？
配额状态、模型可用性、整体路由遥测每天都在变。Auto 不是确定性的。
Q：prompt 越长路由越好吗？
长度是其中一个信号。具体性、附上下文、出现 “design / refactor / plan” 这类动词更重要。500 字模糊 prompt 路由不如 200 字精准 prompt。
Q：我是不是干脆永远用 Opus 4.7？
不要——Opus 有限速，烧 Fast Requests 很快。模型要匹配任务：Sonnet 4.6 是跨文件改动的主力，Opus 4.7 留给真正需要深推理的设计场景。