然后我发现一个问题，很多朋友一个任务就盯着一个模型用到底，刚好WorkBuddy更新了版本，现在可以看到每个模型的积分系数了，索性再写一篇更加深入的模型选择方法供大家参考。
我愿称之为多模型协同，因为每个任务至少都可以分为分析、执行、审查三个阶段，每个阶段对模型能力的需也不尽相同，因此我们可以在不同的阶段选择不同的模型，来共同完成一个任务。
多模型协同主要思想就是将任务拆解成多个步骤，在每个步骤调用不同的模型，以充分发挥每个模型的优势，这样不仅可以让任务完成质量更高，更重要的是可以帮你节约大量积分。
内置模型基本情况
从积分系数可以发现，之前的判断并没有充分考虑到积分消耗，所以结合积分系数，我们先回顾一下 WorkBuddy 内置模型的简介：
| 模型 | 积分系数 | 核心长板 | 适用阶段 |
|---|---|---|---|
| 0.04x | |||
| 0.13x | |||
| 0.25x | |||
| 0.26x | |||
| 0.29x | |||
| 0.45x | |||
| 0.59x | |||
| 0.95x | |||
| 0.95x | |||
| 1.06x |
积分消耗=模型消耗量×积分系数。意思就是，同一个任务，使用GLM-5.1消耗的积分是使用Hy3 preview消耗积分的26倍。之前我还说高贵的Kimi，现在看来，GLM高贵多了...
从这张表可以看出，如果用 GLM-5.1 去干 Hy3 就能搞定的推理分析的话，相当于花 26 倍的钱在做同样的事。
可能很多人都和我之前一样，盯着GLM-5.1去完成所有任务，这就是你积分消耗快的原因，这也是我强调需要多模型协同的重要原因之一，核心逻辑就是按任务阶段匹配对应能力层级的模型。
单模态多模型协同
适用场景：需要深度思考 + 稳定执行的复杂任务，比如技术方案设计、数据分析报告、法律文书起草。
举例：从一份产品需求文档到完整技术方案
假设你手头有一份 50 页的产品 PRD，需要产出完整技术方案。
第一步：理解与分析（模型：Hy3 preview｜0.04x）
把 PRD 丢给 Hy3。我建议大部分推理任务都可以先试试Hy3，毕竟它的推理能力还是很强的，而且现在做活动，积分系数才0.04，性价比绝对是【夯】。
输出的需求分析报告如果不满意，可以返工，毕竟是抽卡，而且要记得，积分系数极低，要舍得！
提示词：「阅读这份 PRD，提取所有功能需求，按优先级分类，识别技术难点和潜在风险，输出结构化的需求分析报告。」
第二步：方案执行（模型：GLM-5.1｜1.06x）
GLM-5.1贵自然有贵的道理，所以执行层面我们忍痛选择它，毕竟第一步已经给我们省了许多。
拿到满意的结构化需求后，你可以直接切换到 GLM-5.1对话，也可以新建对话，上传需求分析报告，模型选择 GLM-5.1，从目前使用来看，直接切换有时候会切不过去，所以个人推荐后者，更稳定一些。
提示词：「基于该需求分析报告，输出完整技术方案：架构设计、数据库设计、接口定义、技术选型理由、开发排期。」
第三步：质量审查（模型：Kimi-K2.6｜0.59x）
之前我介绍过，Kimi-K2.6 的看家本领是超长上下文，所以这里我们可以把前两步输出的文档都交给它来审查，这里同样建议新开对话，后面都这么操作，我就不再啰嗦了。
提示词：「审查以上需求分析报告和技术方案，逐项检查需求覆盖度、架构合理性、风险遗漏、接口完整性，输出审查意见。」
效果对比
| 方式 | 积分消耗 | 方案质量 | 返工风险 |
|---|---|---|---|
综合来看，我们多模型协同既控制了积分消耗，又降低了返工风险，同时还达到了较高的方案质量，何乐而不为呢？
多模态多模型协同
适用场景：需要用到图像处理，如截图转前端页面、设计稿转实现等。
举例：把一张App截图变成前端页面
第一步：视觉理解（模型：GLM-5v-Turbo｜0.95x）
还记得吗？GLM-5v-Turbo的强项就是视觉编程，所以让它把截图的布局、组件、颜色、间距等等数据转为结构化描述再合适不过了。
提示词：「分析这张截图，输出页面布局结构、组件类型和位置、配色方案、字体层级、交互逻辑推断报告。」
第二步：代码实现（模型：Kimi-K2.6 ｜0.59x）
拿到结构化描述报告后，我们用K2.6来编写代码，从编程能力来讲K2.6和GLM-5.1不相上下，但它长文本能力更强，而且积分更省，毕竟这一步消耗积分会比较多。
提示词：「基于该截图和分析报告，帮我编写代码，实现像素级还原完整前端页面的效果。」
第三步：代码调优（模型：GLM-5.1 ｜1.06x）
拿到代码之后，我们可以单独把代码文件保存，然后喂给GLM-5.1来帮我们检查、调优。
提示词：「请深度分析并优化这段代码，给出改进后的代码及优化说明。」
核心逻辑其实也一样，在不浪费积分的情况下，充分发挥每个模型的长处，让视觉模型专注看，让编程模型专注读、写。
批量处理
适用场景：批量文件处理、批量数据清洗、批量代码审查。
举例：HR简历筛选
第一步：标准制定、分类（模型：Hy3 preview｜0.04x）
你可以把所有简历下载至一个文件夹，当然，你也可以给出权限让WorkBuddy直接访问你的邮箱去下载，这里以文件夹举例。
提示词：「帮我将简历分成两个文件夹，包含图表（人像照片除外）的和不包含图表的；然后根据岗位需求帮我定制一个简历评分标准模版，模板需包含：必会技能、加分项、年限匹配度、项目含金量等。」
第二步：批量执行（模型：MiniMax-M2.7 + Deepseek-V4-Flash）
之前我们已经生成了评分模板，这一步对分析推理能力要求就没那么高了，而涉及图表的简历需要用到多模态，因此我们选择MiniMax-M2.7（0.26x），剩余的则选择成本更低的Deepseek-V4-Flash（0.13x）来完成。
提示词：「请严格按照评分标准模板，提取该文件夹中简历关键信息并打分（0-10分），输出每份简历的结构化评分表。输出格式必须包含：姓名、联系方式、技能匹配分、近3家公司名、职位、在职时长、项目经验、评分、一句话亮点等。如果简历中有明显的错别字或排版混乱，请在备注里标注。」
第三步：汇总分析（模型：Deepseek-V4-Pro｜0.25x）
汇总分析我们使用DeepSeek-V4-Pro，这是DeepSeek最新的推理模型，做深度分析和质量把控，成本远低于GLM和Kimi。
提示词：「汇总分析所有简历的结构化评分表，按综合匹配度给前10名排序，简历存在项目描述空洞或跳槽过于频繁的情形需注明，并给每人撰写50字以内的推荐语，同时列出前3名的核心差异点，最终生成一份可以直接转发给业务部门的《简历初筛简报》。」
针对批量处理的特殊情形，我们同样采取三步走的方式进行，同时考虑模态，又进行了细分，以达到到成本最优、效果最佳的效果。
切勿迷信多模态
以上是我亲测或设想的三种情形，底层逻辑其实都是一致的，这里再提醒一句，不要认为多模态就是万能的，每个模型都有自己所擅长的领域，非必要其实完全不用考虑多模态。
多模态的本质是解读把图像、版面、截图等非文本信号，而代价则是单模态能力被稀释、输出稳定性降低。还有一个重要原因就是，多模态通常默认需要解析非文本，因此会消耗更多积分。
之前我说简单任务无脑选Auto，这里由于Hy3的活动，需要更正一下，当前阶段简单任务无脑选Hy3，Auto在活动期间完全可以不用了。
如无特别需求，尽量多用Hy3，涉及到非文本的情况下，再考虑多模态，还是要遵循尽量选择成本收益最高的模型为原则，因此在使用过程中，需要自己摸索每个模型的特性，找出每个模型最擅长的部分去充分利用。
更新速查表
针对任务阶段和模型特性，我制作了一份任务核心需求和模型推荐表，并且每个模型都附上了积分系数，供你参考：
| 任务阶段 | 核心需求 | 推荐模型 | 备用模型 |
|---|---|---|---|
写在最后
使用WorkBuddy还是建议以使用内置模型为主，因为内置模型基本都是二次封装的，更适合在WorkBuddy中调用。
当然，自定义模型也不是不能用，这就需要你根据模型的特性，参照我上面所说的多模型协同来按需调用，比如你购买了Qwen模型，完全可以和内置的Hy3或者某个多模态模型一起来配合使用，效果极有可能比单纯使用Qwen效果更好。
