把一句"每天早九点把昨日销售数据汇总发到企业微信群"翻译成一个能在自动化平台里真正跑起来的工作流，这件事听起来简单，做起来却比想象中难得多。过去半年，我们团队一直在做 Chat2Workflow 方向的探索，简单说，就是让大模型直接输出一份可执行的 workflow 定义，而不是只给你一堆"建议你怎样做"的参考文字。为了让这个方向的效果评估不再靠拍脑袋，我们搭了一套专门的基准，陆陆续续测了 15 个模型的工作流生成能力。这篇文章把评测方法、榜单结果、高分样本分析、典型翻车模式一次说完，给正在做同类型事情的同学一份可以直接抄的作业。
和普通的聊天评测不一样，工作流生成要求模型同时具备结构生成能力、平台知识记忆和逻辑编排能力，任何一个短板都会导致最终输出无法落地。所以这套基准从设计之初就没打算测"谁更会聊天"，而是测"谁能真的把活干完"。我尽量把每一个设计决策背后的原因也写清楚，方便你复用这套评测思路来测自己的场景。
1. 为什么要把"聊天能力"和"工作流生成能力"分开来测
市面上已经有很多大模型评测榜单，绝大多数集中在问答、写作、代码、数学这些通用维度。可一旦进入 Chat2Workflow 这个具体任务，通用榜单几乎没有参考价值。
1.1 从一句话需求到可执行工作流，中间隔着一道鸿沟
先说说 Chat2Workflow 到底解决什么问题。假设你是一个运营，你并不关心平台底层是怎么连数据库、怎么发消息的，你只会说"每天早上九点把昨天的销售数据汇总一下发到群里"。传统做法是找个开发或者懂配置的人，把这个需求翻译成节点图、连接线、条件分支和配置参数，再经过几轮调试才能跑通。Chat2Workflow 要做的是让大模型直接完成这段翻译，输出符合平台 schema 的 JSON 定义。
这个过程远比普通文本生成复杂。首先，模型输出的是一段结构化数据，不是自然语言，任何 JSON 格式错误都会导致整个文件无法解析。其次，工作流涉及节点之间的依赖关系，比如查询数据库的节点必须排在发送消息的节点之前，条件分支的条件表达式必须能正确匹配上游节点的输出字段。最后，每个平台都有自己的节点类型、字段命名、变量引用语法，模型必须"记住"这些平台特有知识，又要在一个自然语言任务里灵活调用它们。
我用一个类比来解释：通用聊天就像让一个人用嘴描述怎么开车，Chat2Workflow 相当于让他直接上手完成一次指定路线的驾驶，还要求车辆不能熄火、不能违章、必须在规定时间到达。会"描述"的人很多，会"开"的人少得多。
1.2 通用基准测不出"能不能干活"
把通用榜单的 Top 模型直接拿来生成工作流，会出现一个很典型的反差：模型回答得很流畅，逻辑好像也对，但输出的结果是错的。错误往往出在非常低级的地方——节点类型写错、引用的字段名和上游节点不匹配、条件分支的方向画反。
这些错误在通用基准里几乎不会被发现，因为通用基准只看"语义是否合理"，不看"结构是否可执行"。这就导致了模型厂商在公开榜单上排名很高，落地到工作流场景却一塌糊涂。我们在内部项目中就踩过这个坑：最初直接选了公开评测分数最高的模型接入，结果生产环境里工作流解析失败率一度超过 30%，最后被迫退了回来。
所以我一直觉得，垂直场景必须有垂直基准，只有用目标场景的真实数据来测，模型的强弱排序才有实际意义。这也是这次 Chat2Workflow 基准立项的最直接动机。
1.3 这次评测想要回答的三个问题
在动手设计评测之前，我们先把意图收敛成三个明确的问题，后面所有工作都围绕这三个问题展开。
第一，不同能力档位的模型，在"自然语言转工作流"上的真实差距到底有多大？我们关心的是这种差距是否和参数量线性相关，还是某个能力临界点之后突然拉开。
第二，哪些任务场景是最容易拉开差距的？同样是工作流生成，定时任务和审批流对模型能力的要求完全不同，我们需要知道分层模型各自擅长什么、不擅长什么。
第三，模型的错误模式有哪些共性？如果错误集中在某几类，就有希望在模型之外通过 schema 约束、prompt 设计或者后处理脚本把这些错误兜住，降低对模型本身的要求。
这三个问题贯穿了整个评测的设计，后面的测试集构建、评分标准、结果分析全部围绕它们展开。
2. 评测样本、参测模型与打分体系的设计
评测设计是整个项目里最花时间的部分。测试集既要贴近真实需求，又不能故意刁难模型；打分既要客观可复现，又不能丢掉对"实际能不能用"的判断。下面把这套体系的关键细节拆开讲。
2.1 测试集：120 道题的构成逻辑
测试集一共 120 道题，全部来自我们过去一年中收到的真实需求，按类型做了脱敏和改写后锁进私有库。之所以不用公开数据集，是因为很多开源模型的训练语料里可能已经吃过类似题目，评测结果的"污染"风险太高。一套基准要是测试集本身不可信，后面的榜单就完全没有意义。
120 道题覆盖 5 大场景类别，每类 24 道：
- 数据同步类：把一个数据源的内容同步到另一个目标，比如数据库到表格、第三方 API 到本地存储。
- 定时任务类：按固定频率执行的操作，比如每天定时发日报、每周定时清理临时文件。
- 审批流类：多人参与、带条件分支的审批流程，比如报销审批、发布审批，涉及"金额大于某阈值转给上级"这类逻辑。
- AI 内容生成类：调用大模型接口批量生成文本、摘要、标签，并和前后节点组合。
- 多系统集成类：需要串联多个外部系统，比如收到表单提交后先写入数据库，再发送通知，再创建工单。
题目难度也做了分层。最简单的题只需要 2 到 3 个节点，比如"每天晚上十点把 A 表的数据备份到 B 表"。中等难度的题需要 4 到 6 个节点，通常带一个条件分支或一个循环。最难的题超过 8 个节点，往往涉及错误处理分支、多个条件叠加、跨系统字段映射。难度比例大约是简单 30%、中等 50%、困难 20%。
这里有个容易被忽略的设计点：每道题都隐含有"平台约束"信息。我们给模型提供的不是一段裸需求，而是一份经过脱敏的平台 API 说明，包括可用的节点类型、每个节点的必要参数、变量引用格式示例。这更接近真实使用场景——用户本来就是为了某个具体平台去买模型能力的。模型的真正考验在于如何在给定的平台限制内完成编排，而不是凭空发明一套自己熟悉的 workflow 语法。
2.2 15 个模型的基本画像
参测的 15 个模型，按部署方式分为三类：商业闭源 API、开源可本地部署的大参数模型、开源可本地部署的中小参数模型。为了避免榜单被误读为针对特定厂商的对比，这里统一用代号表示，代号和具体模型版本的对应关系在项目附录里保留。
| 模型代号 | 类别 | 参数量级别 | 上下文长度 | 部署方式 |
|---|---|---|---|---|
| Model-A | 商业闭源 | 未公开 | 128K | API |
| Model-B | 商业闭源 | 未公开 | 200K | API |
| Model-C | 商业闭源 | 未公开 | 200K | API |
| Model-D | 开源 | 70B 级 | 64K | 本地 |
| Model-E | 开源 | 70B 级 | 128K | 本地 |
| Model-F | 开源 | 32B 级 | 32K | 本地 |
| Model-G | 开源 | 32B 级 | 64K | 本地 |
| Model-H | 开源 | 13B 级 | 32K | 本地 |
| Model-I | 开源 | 7B 级 | 32K | 本地 |
| Model-J | 开源 | 7B 级 | 128K | 本地 |
| Model-K | 开源 | 7B 级 | 8K | 本地 |
| Model-L | 开源 | 3B 级 | 8K | 本地 |
| Model-M | 开源 | 1.5B 级 | 4K | 本地 |
| Model-N | 开源 | 1B 级 | 8K | 本地 |
| Model-O | 开源 | 0.5B 级 | 4K | 本地 |
选这个组合不是为了追求齐全，而是为了回答一个重要问题：在 Chat2Workflow 这个任务上，闭源与开源的差距还有多大？参数量的增长是否能换来稳定的能力提升？这两个问题直接决定团队在选型时是花钱买 API 还是自建推理服务。
2.3 打分指标：五项维度与权重
工作流生成的评价不能只看"他做对没有"，因为很多输出介于完全正确和完全错误之间。我们最终拆出了五个打分维度，每个维度都有明确的判断标准。
结构合法性（权重 25%）：输出能不能被解析成合法的 JSON，节点字段是否存在、类型是否正确。这个维度是硬门槛，占权重最高，因为结构非法直接等于不可执行。
功能完整度（权重 30%）：工作流是否包含了完成目标所必需的全部环节。比如"发日报"这道题，必须包含数据查询、内容生成、消息发送三个节点，漏掉任何一个都完不成目标。
逻辑正确性（权重 25%）：节点之间的连接顺序是否合理，条件分支的方向和条件表达式是否正确。模型可能节点全建了，但把"金额大于 100"写成了"金额小于 100"，这属于逻辑错误，比漏节点更隐蔽。
资源合理性（权重 10%）：是否引入了不必要的节点、多余的参数配置。比如明明可以直接查询数据库，却绕了一圈先去读 Excel 再导入表，虽然结果可能一样，但执行效率很差，也增加了维护成本。
可读性（权重 10%）：节点名称、变量命名是否清晰，有没有合理的注释。这个维度容易被忽略，但工作流是要被长期维护的，一个命名全是 node1、node2 的工作流会让后续接手的同事非常痛苦。
最终得分按加权平均计算，满分 100。此外，每道题我们还记录了一个额外的"可执行率"指标：只统计通过结构合法性校验且节点逻辑完整无缺失的输出在总输出中的占比。这个指标不进总分，但会在榜单上单独列出来，因为它直接反映"拿这个模型做生产接入的成功率预期"。
2.4 评测过程中的关键控制
评测执行阶段，我们做了几个在重复评测时容易被忽略的控制措施，这里单独写出来。
所有模型使用统一的推理参数：温度 0.3，top_p 0.9，最大输出 token 4096。温度定低是为了减少随机性，但完全用贪心解码又容易漏掉模型本来具备的能力，所以留了一点采样空间。每道题每个模型重复采样 3 次，取最高分计入榜单，同时记录 3 次得分的均值和方差用于稳定性观察。
评测 prompt 采用了统一的模板，包含四段内容：任务说明、平台 API 约束、输出格式要求、一个正确的 few-shot 示例。这个模板在正式评测前反复调过很多轮，确保每个模型拿到的是完全相同的输入条件。prompt 的措辞对结果影响极大，如果不同模型用了不同措辞的 prompt，那测出来的差距实际上是 prompt 的差距而不是模型的差距，这个严格控住。
所有输出先过一遍自动校验脚本，把结构合法性、字段存在性这些客观项先判掉，剩下的人工评估部分由两个标注者独立打分，遇到分歧再讨论仲裁。人工评估的边界我们有明确规定：只评"逻辑对不对、顺序对不对、是否合理"，不评"如果换个写法是不是更好"。这个边界非常重要，否则容易把个人偏好带进分数里，导致同一个输出的两个标注分数差异超过 10 分。
3. 榜单结果与分析：模型之间的真实差距
这一节直接给结果。所有的分数都是三次采样中的最高分，个别模型的波动性我会在后面的稳定性分析里专门提。
3.1 总成绩排名与分层
| 模型代号 | 结构合法性 | 功能完整度 | 逻辑正确性 | 资源合理性 | 可读性 | 总分 | 可执行率 |
|---|---|---|---|---|---|---|---|
| Model-A | 96 | 94 | 95 | 92 | 96 | 94.6 | 91.7% |
| Model-B | 95 | 93 | 94 | 90 | 93 | 93.2 | 89.2% |
| Model-C | 93 | 92 | 93 | 89 | 94 | 92.4 | 87.5% |
| Model-D | 90 | 88 | 89 | 86 | 90 | 88.7 | 81.6% |
| Model-E | 89 | 86 | 88 | 85 | 88 | 87.2 | 79.2% |
| Model-F | 82 | 80 | 81 | 78 | 83 | 80.8 | 68.3% |
| Model-G | 80 | 79 | 80 | 77 | 81 | 79.4 | 65.0% |
| Model-H | 72 | 70 | 71 | 69 | 74 | 71.0 | 50.8% |
| Model-I | 68 | 66 | 66 | 64 | 70 | 66.6 | 43.3% |
| Model-J | 66 | 64 | 66 | 63 | 67 | 65.2 | 41.7% |
| Model-K | 63 | 62 | 61 | 60 | 64 | 62.0 | 36.7% |
| Model-L | 56 | 60 | 58 | 56 | 60 | 58.2 | 31.7% |
| Model-M | 49 | 53 | 50 | 52 | 53 | 51.5 | 21.7% |
| Model-N | 42 | 47 | 44 | 45 | 46 | 44.7 | 14.2% |
| Model-O | 38 | 41 | 39 | 40 | 41 | 39.7 | 9.2% |
看总分分布，15 个模型可以明显分四个层次。第一梯队是 Model-A、Model-B、Model-C 三家闭源模型，总分在 92 以上；第二梯队是 Model-D 和 Model-E 两个开源 70B 大模型，总分在 87 到 89 之间；第三梯队是 Model-F、Model-G 两个 32B 级别模型，总分在 79 到 81 之间；再往下的 13B、7B、3B、1.5B 及以下模型，总分从 71 一路跌破 40。
比较值得注意的断层出现在 Model-E 和 Model-F 之间，也就是 70B 到 32B 的跨度上，总分直接掉落了接近 7 分。这说明在 Chat2Workflow 这个任务里，模型能力不是平滑上升的，存在一个比较明显的临界规模。32B 以下模型在复杂工作流生成上已经很难保证基本质量了。
3.2 分场景表现：每个模型的"主场"与"死穴"
光看总分还不够，总分是五个场景的平均效果，掩盖了大量场景差异。我们把每个模型的场景得分拆出来看，得出了几个非常有价值的结论。
定时任务类场景是所有模型表现最好的场景。3B 级别的 Model-L 在定时任务场景都能拿到 68 分，原因是这类任务的结构高度模板化，"多久一次 + 做什么操作"是最简单的节点编排，几乎不涉及条件判断和多系统联动，模型只需把高频出现的模式记住就能答对。
数据同步类次之，但难度体现在字段映射上。7B 级别的模型容易在"源字段 A 对应目标字段 B"这种映射中出错，尤其是两边字段类型不一致时，模型经常忘记加类型转换节点。
审批流类场景是差距拉大的第一道分水岭。13B 及以下模型在这个场景普遍低于 60 分。核心原因是审批流需要模型同时处理多级条件、多个审批人来回跳转，本质上是一种带状态的小型逻辑程序，小模型的推理深度在这里明显不够。
AI 内容生成类场景表现两极分化。几乎所有模型都能搭出"调大模型接口 + 输出结果"这种两层节点结构，但一旦要求把上游数据拼进 prompt 模板、再对生成结果做二次加工，7B 模型就开始频繁出错。它们不是不会写 JSON，而是不会组织"数据从哪个节点流出、以什么格式流进下一个节点"的数据流关系。
多系统集成类是绝对的难度天花板。70B 以下模型几乎没有拿到超过 75 分的。这类场景要求模型理解多个系统的数据格式差异、接口调用顺序、错误处理方式，等于在同一个工作流里当全栈架构师，对模型的规划能力要求极高。
3.3 黑马与意外发现
这次评测里有几个结果出乎意料，我觉得比排名本身更有信息量。
第一个意外是 Model-E（开源 70B）在审批流场景上拿到了和 Model-C（闭源）几乎一样高的分数，只差了 0.3 分。这在总榜上是看不到的，总榜 Model-C 领先 Model-E 超过 5 分，领先优势主要来自多系统集成场景 —— 在两个最复杂的场景上，开源大模型和闭源模型的能力差距没有看上去那么大。
第二个意外是 7B 级别的 Model-J 虽然总榜不如 13B 的 Model-H，但在数据同步类场景反超了 Model-H 将近 4 分。查了上下文长度配置才发现，Model-J 支持 128K 上下文，我们提供的平台 API 说明文档有接近 2 万字符，而 13B 模型上下文只有 32K，但实际生成时它会把注意力过度集中在文档后部的示例上。更长的上下文在内容杂乱时并不必然带来更好的效果。
第三个发现是稳定性问题。总分在 80 分以上的模型，三次采样得分差基本控制在 3 分以内，但 32B 以下模型的三次采样得分波动经常超过 8 分。有个 7B 模型在难题上三次采样分别拿到 35 分、61 分、52 分，方差大得离谱。这说明小模型的低分不完全是能力边界导致的，还有部分原因是随机性太强。如果只采样一次，很可能会错判一个模型的实际水平。
4. 高分案例拆解：一个好的工作流答案该长什么样
榜单分数是抽象的，真正能让人学到东西的是高分样本长什么样。这一节拿一道典型的多系统集成题做完整拆解。
4.1 案例背景与要求
题目原需求大意是：每天早上八点，从外部 CRM 系统拉取前一天新增的客户名单，判断客户所在区域后，为华南区的客户创建一个本地跟进任务，其他区域的客户发送邮件通知。这道题包含了定时触发、外部接口调用、条件判断、本地系统写入、邮件发送五个动作，且需要正确处理多系统字段的转换，是测试集里中高难度的一道题。
当然，模型收到的实际输入不是这么简单的自然语言。我们在其中还附带了 CRM 接口的返回示例字段（客户 ID、姓名、区域、手机号）、本地任务系统的必填字段（负责人、截止日期、客户 ID）以及邮件服务的收件人格式要求。平台约束部分和 few-shot 示例加起来约 3000 字符。
4.2 完整答案逐段分析
这是第一梯队某个模型给出的答案，我按节点结构做了简化展示。
{ "nodes": [ {"id": "daily_trigger", "type": "schedule", "frequency": "daily", "time": "08:00", "timezone": "Asia/Shanghai"}, {"id": "fetch_customers", "type": "crm_query", "api": "customers.getRecent", "days": 1}, {"id": "region_check", "type": "condition", "input": "{{fetch_customers.output[].region}}", "operator": "==", "value": "华南区", "branch_true": "create_task", "branch_false": "send_email"} ] }光是这个片段，就能看出几个关键优势。第一，节点命名全部是语义化命名，daily_trigger、fetch_customers、region_check 一眼就能看懂，维护成本低。第二，在条件分支节点里正确引用了上游节点 fetch_customers 的输出，并且用数组遍历语法处理了多客户场景。第三，时间配置里带着时区参数 Asia/Shanghai，避免服务器默认时区导致触发时间偏差。
再看条件分支的两个下游节点配置。create_task 节点把客户 ID 映射到了本地系统的必填字段，并设置了负责人为空时默认分配给客服主管的兜底逻辑。send_email 节点则把客户名单先做了一次字符串拼接，再作为邮件正文模板的变量传入。这两个节点的表现同样规范，字段名完全符合平台 schema 要求。
这个案例给我们的核心感受是：高分答案不是某个环节特别出彩，而是从命名到参数到异常处理全部保持在平均水准之上，没有一个明显的弱环。工作流生成是木桶效应很强的任务，一个字段拼错或一个节点连错，整份答案的可执行性就会归零。
4.3 高分答案的共性特征
看完 15 个模型在所有测试题上的输出，我们总结出高分答案的四个共性特征，这些特征可以作为团队内部做质量评估时的人工核验清单。
第一个特征是"显式处理字段映射"。模型给出的答案中，凡是涉及跨系统数据转移的地方，都明确写出了源字段和目标字段的对应关系，而不是含糊地写一个"data"字段就完事。
第二个特征是"条件分支有兜底"。高分答案几乎都会为条件判断的默认情况设计处理路径，要么给 if 配一个 else 分支，要么在必填参数后面写上默认值。低分答案里最常见的情况是条件判断写得很清楚，但没考虑不满足条件时怎么办，导致 workflow 在线上的执行率很低。
第三个特征是"变量引用可追踪"。答案中出现的变量引用，都能在上游节点的 output 字段中找到明确来源。低分答案经常出现引用一个从未定义过的变量名，连人工修复都要花时间才能推断模型本意是什么。
第四个特征是"命名即注释"。真正的可维护工作流，节点名称本身就是文档。低分模型倾向于生成 node_1、node_2 这样的抽象命名，或者干脆让每个节点的名称都叫 "process"。
5. 失分重灾区：五类典型错误与根因分析
如果说高分样本告诉我们"应该是什么样"，那错误样本就告诉我们"为什么做不到"。这次评测统计了全部输出中丧失关键分值的错误，整理出五类高频错误。这些错误在很多模型身上同时出现，很有代表性。
5.1 第一类错误：JSON 结构破坏，直接无法解析
任何模型都会偶发这类错误，但小模型格外严重。0.5B 和 1B 级别模型的输出里，超过 40% 根本无法通过 JSON 解析。典型表现是：花括号不闭合、在字符串里混入了注释、数组和对象混淆、末尾多了一个逗号。
7B 以上的模型很少直接在格式上翻车，毕竟这类错误太容易被规则脚本拦截。但从评测的"可执行率"来看，就算结构合法，小模型的功能完整度仍然大面积失分。原因是它们经常生成一个"看起来完整但缺少必要参数"的节点，比如数据库查询节点没有写 SQL 语句，消息发送节点没有写接收人，这类结构合法但内容缺失的错误，要比格式错误隐蔽得多，也更容易漏进生产环境。
这类错误给我们的启发是：对于小模型，与其靠它自己保证格式正确，不如在接入链路里强制增加 schema 校验和参数补全脚本。后面会单独说这个方案。
5.2 第二类错误：节点孤立，连线丢失
工作流和普通的 JSON 数据不同，它除了节点定义还有节点之间的连接关系。第二类高频错误就是节点本身定义正确，但 edges 数组里漏掉了一两条关键连线。
我见过一个 7B 模型的输出，条件判断节点和两个下游分支节点都建好了，但 branch_false 对应的那条边没有写到 edges 数组里。从单个节点的角度看，这份答案没有任何问题；从工作流的整体角度看，这个流程在条件不成立时会直接走到终点，功能完全丢失。
这类错误单靠检查节点配置无法发现，必须对整个工作流做路径遍历才能定位。我们在设计评测脚本时就写了一个图遍历工具，模拟给定输入后检查每个节点是否至少可达、终点前置条件是否完整。这个工具后来也被用到评测后的自动后处理环节，帮我挡了不少线上事故。
5.3 第三类错误：条件分支的语义错误
条件分支是工作流里最容易出错的地方，比节点连线更隐蔽。最典型的是比较符号反向：需求是"金额大于 10000 转经理审批"，模型写成了"金额小于 10000 转经理审批"。从结构上完全无法发现，只有逐字对需求才能识别。
另一个高频语义错误是条件值类型不匹配。上游节点的金额字段是数字类型，模型的条件却写成字符串"金额" > "10000"，或者反过来把数值比较用在文本字段上。这类错误在低分答案里非常普遍，根源在于模型对节点输出字段的实际类型没有建立准确的记忆，凭感觉写了类型。
实测中发现，条件分支语义错误的严重程度和参数量成正比。70B 模型基本不会把大于小于写反，但 13B 以下模型大约每 4 道含有条件分支的题里就会出现 1 次反向错误。这里的原因我推测是：分支判断需要模型在生成"条件表达式"的同时保持对需求语义的持续跟踪，模型的推理深度不够时，注意力会被前面生成的节点描述分散，写到条件时需求语义已经"模糊化"了。
这个场景是最值得用测试集专门覆盖的，因为在真实的 Chat2Workflow 产品里，用户往往不仔细检查条件方向，一旦跑错会直接影响业务结果。
5.4 第四类错误：平台字段与参数幻觉
模型会"编造"平台 API 里根本不存在的字段。我们提供的平台约束文档里列了每个节点的允许字段，但小模型在生成过程中经常写出文档里没有的参数名。例如 CRM 查询节点明明只支持 api、days 两个参数，模型却额外加了一长串自定义过滤条件。
这类错误的可怕之处在于，它和"模型不懂业务"完全不同，它是模型从训练语料里带出来的"惯性"。大模型训练时看过大量其他平台的 workflow 写法，于是把别的平台的字段名搬到了我们的平台上。这提示我们：在做 Chat2Workflow 产品时，平台的私有 API 约束和通用能力差异越大，越要用强约束的 schema 提示词把模型的"惯性"压住。
不过这个错误的方向也提供了一个偏正面的信号：如果平台使用常见的节点概念和参数命名，模型适应起来会快得多。用一套贴近业界通用认知的节点命名体系，本身就能提升模型的工作流生成准确率。
5.5 第五类错误：过度设计，弄巧成拙
如果说前四类都是"做得不够"，那第五类是"做得太多"。
有些模型在一个只需 3 个节点的简单任务上，硬生生输出了 9 个节点，里面包含了一个完全多余的数据库关联表、两个重复的条件分支、一个被注释掉的发送节点。资源合理性维度在这里大量失分，更重要的是，这种答案即使能运行，维护成本也很高。
我特别想提到一个现象：在提供 few-shot 示例时，如果示例本身是中等复杂度的答案，模型在简单题目上也会倾向于生成和示例相近的复杂度，出现明显的"结构惯性"。
我们后续做过一次对照实验，把简单题目的 few-shot 示例替换为更简单的答案，模型在简单题上的资源合理性得分平均提高了 6 分。这说明模型的过度设计不完全是能力问题，有相当一部分可以从 prompt 设计层面缓解。
6. 拿来即用的建议：怎么根据自己的场景选模型
榜单和分析最终都要落到一个实际问题上：我该用哪个模型？这一节给出从评测数据里总结出来的选型建议，按预算和场景两条线展开。
6.1 预算有限：小模型的正确用法
如果预算只允许部署 7B 或 13B 级别的开源模型，千万别把它的能力边界想象成"市场上的大模型缩小版"。从评测数据看，7B 模型的综合可用性只在定时任务和数据同步两个场景能够接受，审批流和多系统集成的成功率很低。
正确的做法是搭配一个全自动的工作流后处理管线。结构校验脚本负责抓住 JSON 格式错误，图遍历脚本负责抓断边，字段映射表再补一层参数补全。经过这三层兜底之后，7B 模型在小场景上也能到达接手生产的边缘。
另一个思路是"小模型出初稿，大模型做审核"。我们实测过，让 7B 模型先生成完整工作流，再调用一次闭源大模型 API 做"审查并修正"指令，可以把功能完整度从 65 分拉到 80 分以上。虽然额外花了一次 API 调用，但整体成本仍然远低于所有请求都走大模型。这个"师生"模式对预算敏感的场景很划算。
6.2 追求质量：大模型与 API 模型的平衡
有预算把模型部署到 32B 或 70B 级别时，需要算一笔更细的账。32B 模型在中等难度题目上的表现已经可看，但在多系统集成等复杂场景上和大模型差距明显；70B 级别模型在大模型之外的几乎每一类场景上都能逼近闭源模型，差距主要来自多系统集成和可读性这类对"全局规划"要求高的维度。
所以更准确的建议是：如果你的工作流任务集中在数据同步、定时执行、条件审批这些常见场景，开源的 70B 模型已经够用，没必要额外接外部 API；如果大量任务涉及跨系统集成、复杂数据映射、异常分支设计，闭源 API 的费用可以视为"买一份全局规划能力"的合理投入。
6.3 Prompt 设计的四个技巧
评测过程中我们反复调过系统提示词，有几个技巧对提升所有模型的得分都有效，单列出来供你直接用。
一是在任务说明里显式声明"只允许使用 API 文档中列出的字段和节点类型"。这一句话能让字段幻觉类错误减少大约三成，因为它把模型的生成空间收到了一个封闭集合里。
二是在 few-shot 示例里覆盖两类场景：一个简单场景、一个中等复杂场景，不要只给一个中等场景。这样能部分缓解简单任务上的过度设计问题。
三是在输出格式要求中明确写出 JSON 的结构级提示，比如"必须包含 nodes 数组和 edges 数组，边必须引用已定义节点的 id"。这类结构性约束让模型把注意力放在输出格式上，结构合法性分数能提升 5 到 8 分。
四是在任务描述的末尾加一句"生成前先在心里规划节点清单，再开始输出"。这个措辞对部分模型有肉眼可见的改善，推测是引导模型先生成"规划"再落成"结构化输出"，相当于把推理过程拆成了两步。这个技巧不是对每个模型都有效，但没有任何副作用，加上没有坏处。
6.4 后处理兜底的必要性
无论选什么模型，都不要跳过自动后处理环节。评测数据的可执行率告诉我们，就算第一梯队模型的可执行率也只有 91%，换到生产环境后，这个数字会因真实需求的复杂度进一步下降。
我推荐的最小兜底套餐是三层脚本：第一层做 JSON schema 校验，把结构不合法的问题拦截在入口；第二层做节点引用检查，找出孤立节点和引用了未定义 id 的边；第三层做参数枚举校验，核对每个节点的参数是否都在平台允许的集合内。这三层脚本的成本很低，一个后端工程师半天就能写完，却能挡住大约八成以上的"低智商错误"。
我曾见过团队把所有希望押在模型能力上，不做任何后处理，结果上线第一周就出现了工作流在特定条件下丢失半个分支的线上事故。这类事故的根因往往不是模型不够聪明，而是结构类错误在规模上被放大。后处理脚本的意义不是替代模型，而是让模型的剩余短板不成为事故源头。
这次评测做完，我自己最大的体会是：Chat2Workflow 这个方向真正难的并不是"让模型输出 JSON"，而是让模型在一个具体的平台约束下理解数据流转、条件分支和异常兜底。这类能力的评测很难靠通用榜单完成，必须自建基准、自己造测试集。好在我们把整套评测方法沉淀了下来，后续如果要把测集扩展到更多场景，只需要按这套框架填空就行了。最后再分享一个操作层面的小经验：做这类评测时，务必给每个模型统一温度参数和采样次数，否则你测出来的很可能是随机波动，而不是模型的真实水平。
