来源信息

  • 文档类型：阅读笔记 · 整理日期 2026-10-07
  • 原文：《Spending your effort》 · 作者 Thariq Shihipar · 发布于 claude.dev · 发布日期 2026-09-25
  • 原文地址：https://claude.dev/blog/spending-your-effort/
  • 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。

核心理解

思考档位的选择不是越高越好，而是按任务难度、验证需求和用户参与程度，分配推演与检查投入。用户逐轮审阅时，先得到可讨论的起点往往更有用；要求模型独立完成时，则需要更多自主判断与验证。

低档能较快给出草图，让人反馈后继续迭代。方向尚未确定时，高档可能提前替用户作出许多假设，把时间花在尚未认可的方案上。这解释的是协作效率，并没有证明 low 的创意更好。

档位怎么选

  • low：用户持续参与的脑暴、草图、小改动与快速探索；重点是尽快获得可审阅的起点。
  • medium：范围明确的常规工程，例如普通功能实现，在速度、成本和能力之间取平衡。
  • high：验证重要或边界较多的修 bug、debug、性能优化与测试；要求复现问题、检查异常路径并验证结果。
  • max：希望模型自主完成困难任务，承担端到端推演、实现与验证；收益可能递减，应先用实际任务评估。

这些是选档起点，不是固定规则。同一任务也可分阶段调整，不能用提高档位代替澄清需求。

机制与适用限制

官方文档将 effort 定义为行为信号：它影响推理、回答及工具调用的投入，不是严格的 token 上限。低档遇到难题仍可能思考；高档也不保证正确。

同名等级按不同模型分别校准，并不代表相同的底层投入，不能直接套用到 Codex。原文的构建示例主要使用 Opus 5.5，基准分析还涉及 Fable 等其他 Claude 模型；少量示例与特定基准的经验不能当作普遍定律。当前文档还列有 xhigh，具体可用档位与建议应以所用模型文档为准。

应用建议：游戏开发流程

以下是据此提出的流程建议，并非原文实验或已经实施的成果。

  1. 用低档发散 3 至 5 个玩法方案，比较体验与实现成本。
  2. 人来选方向，补充资源、状态、规模和验收约束。
  3. 常规实现使用适中档位，审阅结果后继续迭代。
  4. 复杂验证提高档位，集中处理边界、性能与测试。

例如要塞 NPC 系统，先讨论巡逻、生产、战斗等玩法备选；选定后再实现。验证阶段重点检查资源争用、任务打断与恢复、状态冲突，以及对应测试，避免过早细化未选中的设计。

小结

需要快速反馈时先降低投入，需要独立完成和可靠验证时再提高；先确认方向，再把算力花在风险与边界上。

参考来源

相关笔记