★ FEATURED ARTICLE 把一句每天早九点把昨日销售数据汇总发到企业微信群翻译成一个能在自动化平台里真正跑起来的工作流这件事听起来简单做起来却比想象中难得多。过去半年我们团队一直在做 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商业闭源未公开128KAPIModel-B商业闭源未公开200KAPIModel-C商业闭源未公开200KAPIModel-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.3top_p 0.9最大输出 token 4096。温度定低是为了减少随机性但完全用贪心解码又容易漏掉模型本来具备的能力所以留了一点采样空间。每道题每个模型重复采样 3 次取最高分计入榜单同时记录 3 次得分的均值和方差用于稳定性观察。评测 prompt 采用了统一的模板包含四段内容任务说明、平台 API 约束、输出格式要求、一个正确的 few-shot 示例。这个模板在正式评测前反复调过很多轮确保每个模型拿到的是完全相同的输入条件。prompt 的措辞对结果影响极大如果不同模型用了不同措辞的 prompt那测出来的差距实际上是 prompt 的差距而不是模型的差距这个严格控住。所有输出先过一遍自动校验脚本把结构合法性、字段存在性这些客观项先判掉剩下的人工评估部分由两个标注者独立打分遇到分歧再讨论仲裁。人工评估的边界我们有明确规定只评逻辑对不对、顺序对不对、是否合理不评如果换个写法是不是更好。这个边界非常重要否则容易把个人偏好带进分数里导致同一个输出的两个标注分数差异超过 10 分。3. 榜单结果与分析模型之间的真实差距这一节直接给结果。所有的分数都是三次采样中的最高分个别模型的波动性我会在后面的稳定性分析里专门提。3.1 总成绩排名与分层模型代号结构合法性功能完整度逻辑正确性资源合理性可读性总分可执行率Model-A969495929694.691.7%Model-B959394909393.289.2%Model-C939293899492.487.5%Model-D908889869088.781.6%Model-E898688858887.279.2%Model-F828081788380.868.3%Model-G807980778179.465.0%Model-H727071697471.050.8%Model-I686666647066.643.3%Model-J666466636765.241.7%Model-K636261606462.036.7%Model-L566058566058.231.7%Model-M495350525351.521.7%Model-N424744454644.714.2%Model-O384139404139.79.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而是让模型在一个具体的平台约束下理解数据流转、条件分支和异常兜底。这类能力的评测很难靠通用榜单完成必须自建基准、自己造测试集。好在我们把整套评测方法沉淀了下来后续如果要把测集扩展到更多场景只需要按这套框架填空就行了。最后再分享一个操作层面的小经验做这类评测时务必给每个模型统一温度参数和采样次数否则你测出来的很可能是随机波动而不是模型的真实水平。
阅读完成 · 觉得有帮助？
