1. 先搞清楚Claude Code的分层模型到底解决什么问题如果你用过Claude Code特别是尝试过Fable 5这样的高端模型第一反应往往是太贵了。单次任务动辄消耗数千甚至数万token长期使用成本确实让人头疼。但很多人没注意到Claude Code真正实用的不是让你全程用最强模型而是提供了几种分层使用方式Advisor、Workflow、OpenSpec。这些功能的核心思路很明确——让合适的模型在合适的环节工作而不是所有任务都上顶级配置。我实测下来合理搭配后能在保持输出质量的同时节省30%-50%的token消耗。特别是对于代码重构、复杂调试、架构设计这类需要深度思考但大部分操作是常规工作的场景分层用法效果最明显。下面我会按实际落地顺序拆解这三种用法。无论你是个人开发者还是团队技术决策者关注的重点都应该是什么情况下该用什么模型以及如何判断分层策略是否真的省token。2. Advisor模式让强模型只在关键时刻介入2.1 Advisor到底是什么工作逻辑Advisor不是另一个聊天窗口而是Claude Code内置的专家咨询机制。当你启用Advisor后主模型比如Sonnet会在遇到关键决策点时自动向更强的模型比如Opus或Fable 5寻求指导。关键决策点包括确定整体解决方案架构前同一个错误反复出现时任务完成前的最终检查阶段Advisor能看到完整的对话历史包括所有工具调用和结果然后给出具体建议。主模型会根据建议继续工作但如果实际执行发现建议有问题也会灵活调整而不是盲目跟随。2.2 如何配置Advisor才最划算配置Advisor有三种方式我建议按这个优先级选择会话中临时设置适合尝鲜/advisor opus这种方式只影响当前会话退出后不保存设置。通过启动参数设置适合特定任务claude --advisor opus适合你知道某个任务特别复杂需要强模型指导的场景。写入配置文件适合长期使用{ advisorModel: opus }在settings.json中设置后所有兼容的会话都会默认启用Advisor。模型配对有个重要规则Advisor模型必须至少和主模型一样强。常见的省钱组合主模型Advisor模型适用场景成本对比Haiku 4.5Opus日常编码关键决策比全程Opus省60-70%Sonnet 4.6Opus复杂重构架构评审比全程Opus省40-50%Sonnet 4.6Fable 5需要Fable能力但控制成本比全程Fable省50-60%2.3 实际使用时如何判断Advisor是否在省钱启用Advisor后会话中会出现Advising提示行。按CtrlO可以查看Advisor的具体建议。但省钱的关键不是看Advisor有没有工作而是看它被调用的频率是否合理。我的一般判断标准正常情况一个中等复杂任务比如重构一个模块Advisor调用1-3次调用过少可能主模型过于自信需要在提示中明确要求遇到不确定时咨询Advisor调用过多可能任务本身就需要强模型全程参与不如直接切换主模型通过/usage命令查看token消耗时Advisor的消耗会单独计算。如果发现Advisor消耗接近甚至超过主模型说明这个任务可能更适合直接使用强模型。3. Workflow工作流按阶段分配模型资源3.1 Workflow与Advisor的核心区别很多人容易混淆Workflow和Advisor其实它们解决的是不同层面的问题Advisor主模型在单个任务中动态咨询强模型Workflow你明确将任务拆分成多个阶段每个阶段使用最适合的模型Workflow更适合有清晰步骤的任务比如需求分析 → 使用强模型确保理解准确代码实现 → 使用快速模型处理常规编码测试验证 → 使用强模型进行边界 case 分析文档编写 → 使用中等模型整理输出3.2 构建高效Workflow的实操要点阶段划分要明确不要简单按时间划分而要按任务类型划分。我常用的划分逻辑分析阶段: - 模型: opus - 任务: 理解需求、确定架构、识别风险 实现阶段: - 模型: sonnet - 任务: 具体编码、工具调用、简单调试 验证阶段: - 模型: opus - 任务: 代码审查、边界测试、性能分析模型切换时机要合理切换模型会有上下文传递的成本所以不要切换过于频繁。一般规则单个阶段至少完成一个完整子任务上下文信息要完整传递给下一阶段复杂的中间结果要用文件或注释固化成本监控要实时Workflow的优势是成本可预测但需要实时监控每个阶段的token消耗。如果发现某个阶段消耗异常要及时调整模型分配策略。3.3 Workflow的边界在哪里Workflow不是万能的在以下场景效果有限任务依赖强连续性频繁切换模型会丢失上下文任务本身很简单拆分成多个阶段反而增加复杂度团队成员对模型特性不熟悉无法合理分配任务我建议先从明确的、阶段清晰的任务开始尝试Workflow比如新功能开发、代码迁移、系统集成等。4. OpenSpec开放规范统一接口降低切换成本4.1 OpenSpec解决了什么实际问题如果你在不同模型间频繁切换会发现每个模型都有自己的输入输出习惯、工具调用方式、错误处理逻辑。这种不一致性会导致提示词要针对不同模型调整工具调用逻辑要重新适配错误处理要分别考虑OpenSpec提供了一套统一的接口规范让不同模型都能以一致的方式工作。这意味着你可以用相同的提示词和工具配置在不同模型间无缝切换。4.2 OpenSpec配置的核心参数OpenSpec配置主要关注几个关键方面工具调用标准化{ tools: { execute_command: { description: 执行系统命令, parameters: { command: {type: string, description: 要执行的命令} } } } }输出格式约束{ output: { format: markdown, sections: [summary, code, explanation] } }错误处理统一{ error_handling: { retry_count: 3, fallback_model: sonnet } }4.3 OpenSpec如何实际节省tokenOpenSpec的省token机制比较间接但很重要减少提示词调整统一的接口意味着提示词可以复用不需要为每个模型准备特定版本。长期来看这减少了提示词开发和测试的token消耗。降低切换成本当发现某个模型不适合当前任务时可以快速切换到另一个模型而不需要重新设计整个交互流程。提高工具使用效率标准化工具调用减少了解析错误和重试的次数间接节省了token。5. 分层策略的实际落地检查清单5.1 什么情况下该用哪种分层方式优先使用Advisor when任务大部分是常规操作但有几个关键决策点你对主模型的能力有基本信任只需要关键点把关成本敏感但质量要求高优先使用Workflow when任务有清晰的阶段划分不同阶段对模型能力要求差异明显需要精确控制每个阶段的成本优先使用OpenSpec when需要在多个模型间频繁切换有标准化的工具调用需求团队协作需要统一的交互规范5.2 成本监控和优化时机分层用法的省钱效果需要持续监控我一般关注这些指标单次任务成本对比纯强模型成本作为基准线分层策略成本实际消耗节省比例基准-实际/基准质量影响评估任务完成度是否达到预期目标代码质量是否需要额外修改时间消耗是否在可接受范围优化触发条件当出现以下情况时需要重新评估分层策略节省比例低于20%质量明显下降任务时间显著延长5.3 常见问题排查顺序如果发现分层用法效果不理想按这个顺序排查检查模型兼容性Advisor配对是否符合要求Workflow阶段模型是否支持所需工具OpenSpec配置是否被所有模型支持分析任务特性任务是否真的适合分层处理阶段划分是否合理关键决策点是否被正确识别审查提示词质量给Advisor的咨询指令是否明确Workflow阶段转换提示是否清晰OpenSpec约束是否被正确理解验证环境配置Claude Code版本是否支持所需功能API权限和配额是否充足网络和依赖环境是否稳定6. 从单次测试到长期使用的经验建议6.1 新手如何开始尝试分层用法如果你刚接触Claude Code的分层功能我建议按这个顺序上手第一周熟悉Advisor主模型用SonnetAdvisor配Opus处理中等复杂度的编码任务重点关注Advisor的调用时机和建议质量第二周尝试Workflow选择阶段清晰的任务如代码重构手动划分阶段并分配模型记录每个阶段的token消耗和时间第三周引入OpenSpec从工具调用标准化开始逐步统一输出格式测试在不同模型间的切换效果6.2 团队使用的配置管理建议如果团队要推广分层用法这几个管理要点很关键建立配置标准统一的settings.json模板标准的OpenSpec规范共享的提示词库设置成本预警单个任务token消耗上限日均消耗预警阈值异常使用监控机制积累最佳实践记录成功的分层案例分析失败的原因和改进方案定期分享经验教训6.3 长期优化的方向分层用法不是一劳永逸的需要持续优化模型特性理解跟踪模型更新和能力变化测试新模型在分层策略中的表现调整模型配对策略任务模式识别分析团队常见任务类型建立任务与分层策略的映射关系开发自动化的策略推荐工具生态建设开发成本监控工具构建提示词优化平台建立质量评估体系分层用法的核心思想很明确不要用大炮打蚊子也不要用小刀砍大树。关键是找到任务需求与模型能力的最佳匹配点在质量、成本和效率之间找到平衡。