$ man context-wiki/model-selection

不是所有 AI 模型都一样。有些速度更快、价格更低。有些更聪明、价格更高。用错了模型做任务，要么浪费钱，要么产出质量差。用强力模型做简单的格式转换任务，就像请一个高级建筑师去刷墙。用快速模型做复杂的架构任务，就像让一个实习生去设计大楼。把模型和任务匹配起来，这就是全部策略。

模式

快速模型（Sonnet 级别）适合：格式转换、文件模式扫描、简单代码修改、复制粘贴式的改编任务、以及直接的数据转换。这些任务输入明确、输出明确、歧义性低。 强力模型（Opus 级别）适合：架构决策、复杂调试、深度研究综合分析、需要微妙语气的创意内容、以及每一步都依赖前一步的多步推理。这些任务具有歧义性、需要权衡取舍和判断力。 日报追踪器记录我的模型使用情况，让我看到哪里在超支。如果我看到 Opus 级别的会话在做 Sonnet 就能处理的任务，我就调整。如果 Sonnet 级别的会话产出了垃圾结果，那就说明需要更强的模型。

专业技巧

当我启动并行代理时，我会按任务分配模型。协调代理（负责协调一切的那个）使用默认的强力模型，因为它需要推理依赖关系和上下文。做简单工作的子代理（构建一个跟现有页面一样的页面、更新配置文件、运行构建检查）使用快速模型。做重量级创意工作的子代理（比如用我的风格写 17 篇维基文章、设计新功能架构）使用强力模型。 这不是为了省钱，而是为了提高效率。快速模型在简单任务上 30 秒完成，比强力模型在同样任务上花 2 分钟要好。当你同时运行 5 个代理时，速度很重要。

公式

强力模型的会话成本大约是快速模型的 3-5 倍。一整天的构建下来，这个差距会累积。日报追踪器会计算我的模型使用情况并标记异常值。公式很简单：对每个任务问两个问题。（1）这个任务需要推理或判断吗？如果是，用强力模型。（2）这个任务是机械性的还是基于模式的？如果是，用快速模型。如果不确定，先用快速模型。如果产出不行，再升级到强力模型。先试便宜的再升级，好过什么都默认用贵的。