在任务开始前判断该用哪档模型能力与多少推理努力时…

当工作显得过强或过弱、成本高、歧义大或高风险，或需要判断模型类别与思考量是否足够时，用一次风险与复杂度评估推荐 capability tier 和 reasoning effort。

适用场景

解决思路

1. 明确要 sizing 的精确工作单元：task、artifact、review、rerun 或 plan。
2. 只做一次风险与复杂度评分，并让这一次读取同时服务两个坐标。
3. 在评分中检查：是否跨文件、模块或 ownership 边界。
4. 在评分中检查：可逆性与 blast radius。
5. 在评分中检查：安全、安保、隐私、发布或数据丢失风险。
6. 在评分中检查：新颖性、歧义与长上下文综合负载。
7. 在评分中检查：是否需要外部研究、对抗式审查或谨慎的发布排序。
8. 在评分中检查：错误答案的代价。
9. 读出 capability tier：选择其能力上限能覆盖该工作判断与风险的最便宜类别。
10. capability tier 为 fast：用于本地、机械、可逆、且验证便宜且完整的工作。
11. capability tier 为 standard：用于普通 repo-grounded 推理、多步草拟、正常编码以及常规文档或 skill 工作。
12. capability tier 为 frontier：用于架构、高歧义、安全/安保/隐私/数据丢失风险、发布关键审查、跨领域范围，或一个错误假设会浪费大量运行的工作。
13. 读出 reasoning effort：默认让其跟随 tier，fast→glance、standard→measured、frontier→thorough，并把 exhaustive 保留给最难、最高风险的工作。
14. 当 deliberation-hunger 与 capability-need 分离时偏离默认 effort：对歧义、长多步推理，或在原本便宜的任务上做对抗式自检时提高 effort；对强模型下的有界任务降低 effort。
15. reasoning effort 为 glance：最小 deliberation；走直接路径；解析为模型下限。
16. reasoning effort 为 measured：普通、日常 deliberation；解析为模型默认值，或无默认值时梯子中间。
17. reasoning effort 为 thorough：额外 deliberate；处理备选方案并检查假设；高于日常设置但低于顶部。
18. reasoning effort 为 exhaustive：最大 deliberation；穷尽搜索并重新检查工作；解析为模型上限。
19. 把两个轴视为正交：有界但繁琐的任务可为 fast + thorough；快速专家判断可为 frontier + glance；大多数工作二者同向移动，仅在便宜任务需要重思考或强模型只需要快速判断时分开。
20. 记住 effort 买的是 deliberation，绝不是 capability；更多 effort 并不等于更正确。
21. 报告两个坐标、一个共享 rationale、每个旋钮的 move_up_if 与 move_down_if 触发条件，以及 proof surface（无论 tier 或 effort 如何，该工作仍需要的验证）。
22. 报告后停止。
23. 只 sizing 该运行的 cognitive spend，不 sizing 其他；两个旋钮是 which mind（capability tier）与 how hard it thinks（reasoning effort）。
24. 把编排旋钮——context budget、fan-out width、tool-permission scope——排除在外；即使共享同一次风险读取，也不要拉进来。
25. 只用中立语言：tier 为 fast/standard/frontier；effort 为 glance/measured/thorough/exhaustive；每个 effort 是由在 active model 梯子上的位置定义 intent——floor、default、above-default、ceiling——绝不用具名 vendor level。
26. 当解析时，effort 绑定到位置而非 level：缺少中间 level 的模型会将 rung 折叠到它提供的最接近项，因此 intent 总映射到真实设置且不会解析出范围。
27. 默认选择最便宜且足够的 tier 与满足该工作的 effort，而不是两者中最强者。
28. effort 是 deliberation budget，不是 capability，也不是答案长度；绝不要通过提高它来购买 capability——那是 tier 的职责。
29. 没有 routing authority；此 skill 推荐两个坐标，用户、harness 或 executor 决定什么运行并设置实际 level。
30. 在持久机制文本中不要命名具体模型产品、vendor 或版本。
31. 风险优先于规模：一个文件的高风险变更可要求 frontier；当验证完整时，大范围机械重命名可保持 fast + thorough。
32. 验证是分开的：更强 tier 或更高 effort 绝不替代 tests、review、command output、manual QA 或其他 proof surface。
33. 不要执行被 sizing 的任务、改变配置、调用另一个模型或修改 provider settings。
34. 不要覆盖用户明确的 tier 或 effort 选择；如果可见不匹配就报告。
35. 按如下 Output 格式报告：recommended_tier: fast|standard|frontier；recommended_effort: glance|measured|thorough|exhaustive；rationale: 一句话覆盖两个旋钮；move_up_if: 能证明需要更强 tier 或更高 effort 的信号；move_down_if: 能证明需要更便宜 tier 或更低 effort 的信号；proof_surface: 仍需要的验证，独立于 tier 和 effort。
36. 完成前确认报告恰好命名一个 tier（fast/standard/frontier）与一个 effort（glance/measured/thorough/exhaustive）。
37. 完成前确认报告陈述的是最便宜且足够的 tier 与满足该工作的 effort，而不是两者中最强者。
38. 完成前确认报告给出覆盖两个旋钮的 move-up 与 move-down triggers。
39. 完成前确认报告命名 proof surface。
40. 完成前确认报告不作出 routing、switching、provider、vendor、product、version 或具体 level 声明，也不命名两个 cognitive-spend 之外的任何 orchestration dial。

适用边界 · 注意事项

• 不适用于需要实际执行被 sizing 的任务、路由或切换模型、修改配置或提供商设置时。
• 不适用于用户已明确指定 tier 或 effort 时；此时不覆盖，只报告可见的不匹配。
• 不适用于需要设置编排旋钮（context budget、fan-out width、tool-permission scope）或选择具体模型产品/版本时。