企业官网建设流程全解析

过去三个月我做了一件挺拧巴的事：把“AI能不能根据一句人话直接生成可用工作流”这个问题做成了一套基准题，然后拿 15 个模型逐一去考。Chat2Workflow 基准就这么来的——一套面向工作流生成场景的模型评测方案，重点只有一个：模型能否把用户需求翻译成结构正确、逻辑完整、能落地的可视化工作流配置。

做这件事的起因很现实。现在 Coze、n8n、ComfyUI 这类工具已经把人从"拖节点"里解放出来了一半，另一半卡在"怎么把想法变成节点结构"上。用户开始习惯直接给模型提需求，比如"帮我做一个每天早上抓取行业新闻并推送到飞书的流程"，模型需要输出一整套节点定义、连线关系、参数配置。而到底哪个模型擅长干这个，几乎没有现成的答案。拿通用榜单去套，根本套不住。

所以这篇文章不是来介绍某个新框架的，而是把我自己的评测方法、任务设计、评分体系、实测结果和踩过的坑完整摆出来。想给自己的 AI 工作流接入大模型能力的人、做 Agent 产品的工程师、以及研究大模型落地评估的同学，都能从里面拿到可直接复用的思路。

1. 为什么要把"模型生成工作流"单独拎出来做评测

1.1 工作流生成，本质上是另一种形态的代码生成

把一个自然语言需求转换成工作流，看起来像是"格式化输出"，实际上难度一点不比写代码低。工作流有自己的一套"语法"，节点类型是关键词，连接线是控制流，参数配置是对象字面量。比如在 n8n 里生成一个 HTTP Request 节点，要指定 method、url、headers、body，在 Coze 里定义一个大模型节点，又要写 model、prompt、temperature。模型如果对这些平台的 schema 不熟悉，产出的东西就是"形似而神不似"。

更麻烦的是，工作流还讲究"拓扑结构"——条件分支、循环、异常处理都是通过节点之间的连线实现的。模型不仅要选对节点，还要把上下游关系理清楚，顺序错一个节点，整个流程就跑不通。这比代码生成的函数调用链更强调全局规划，因为工作流里没有编译器帮你在运行前做类型检查，很多错误只有真正执行才会暴露。

1.2 现有评测解决不了工作流场景的问题

市面上主流的模型排行榜，大多考数学推理、代码题、通用知识问答。代码题能间接反映模型的结构化输出能力，但和工作流生成还是有明显区别：代码有明确的语法规范和测试用例，而工作流生成的"正确答案"往往是开放的，同一个需求可以有多种合理的节点组合。再加上不同平台的 schema 差异极大，评测要覆盖 Coze、n8n、ComfyUI 就得分别构造数据集和校验逻辑。

还有一个现实阻碍是人工成本。代码生成评测可以靠判题机自动跑测试，工作流生成却需要有人去逐个检查连线和参数。这也是我一开始考虑过用 Deepeval 这类现成评测框架去自动化，"AI 评测落地实操"听起来很美好，但真正落到工作流场景会发现，现有的通用评测框架根本不理解"节点 A 的输出必须接到节点 B 的输入"这种领域约束。最后还是回到了"人工标注 + 半自动校验 + 场景化打分"的组合路线。

1.3 我给自己定了三个评测目标

第一个目标很直接：给模型选型提供一份决策依据。团队要开发一个 AI 工作流生成功能，选 GPT 系、Claude 系还是国产开源模型，不能凭感觉，得看它们在统一任务集上的实际表现。

第二个目标是想看清能力天花板。固定提示模板、给足上下文的情况下，模型能生成多复杂的工作流？节点多了以后会不会崩？这些数据可以帮助产品经理判断，什么类型的需求可以放心交给模型，什么类型的必须做模板兜底。

第三个目标更细一点：建立一套"失效模式库"。工作流生成最常见的错误是节点名称幻觉、连线方向搞反、参数类型不匹配。把这些失效模式分类统计出来，可以在做产品时针对性地加校验和后处理，把模型犯的错拦在用户看到之前。

2. Chat2Workflow 基准设计：测试集、评分体系与评测流程

2.1 测试集：8 个任务类别、240 道题

基准题不是从网上随便抓的，而是结合真实工作流使用场景整理出来的。我把它收敛成了 8 个任务类别，覆盖信息获取、内容生产、数据处理、决策分发等核心场景。

总计 240 题，其中 80 题作为开发集用来调提示模板和评分尺度，160 题作为测试集正式计分。开发集和测试集完全分开，避免"参考答案跟着提示模板走"的伪优化。

每道题的结构统一为三段：用户需求描述、附加约束条件、预期输出说明。比如一道"数据抓取与清洗"题，需求是"每个小时抓取指定店铺的商品价格，过滤掉缺货商品，存到数据库"；约束是"抓取失败要重试 3 次"；预期输出则要求包含定时触发器、HTTP 请求节点、条件过滤节点、数据库写入节点。

题目由一个三人小组共同标注，每个题目都有参考工作流的人工绘制答案。参考答案不追求唯一，只要符合需求且结构合理就视为正确，这样既保证评分有据可依，也不至于太死板。

2.2 打分体系：六维加权模型

工作流生成质量的评判，我最终拆成了六个维度。前五个是内容维，第六个是过程维：

• 结构正确性（20%）：生成的节点是否符合平台 schema，字段名、类型、连接方式是否规范。
• 语义一致性（25%）：节点是否能覆盖用户需求里的全部核心步骤，有没有漏环节、多加无关节点。
• 可运行性（20%）：把生成结果直接导入平台后，能否不经过人工修改就跑起来，重点看连线是否闭合、参数是否缺失。
• 边界处理（15%）：是否包含空值判断、错误重试、异常分支，这是衡量"工业级输出"的关键指标。
• 可维护性（10%）：节点命名是否清晰、是否有必要的中文注释、模块结构是否合理。
• 稳定性（10%）：同一模型对同一道题多次采样，生成质量是否一致。波动大的模型在工程上很难用。

算总分时按权重加权。因为单个模型对单道题的得分会有偶然性，我做了一个差分处理：每道题最多扣到该维度分数的 70%，防止一道题失误导致整场评分失真。

2.3 执行流程与参数控制

评测执行用统一的提示模板，避免模型之间的 prompt 风格差影响公平性。模板里固定包含：任务描述、平台 schema 说明、输出格式要求（JSON 或平台定义文本）、一些负例提示。

采样参数统一设置为 temperature 0.2、top_p 0.9、最大输出 token 4096。每个模型对每道题采样 3 次，取中位数作为最终得分，并记录三次结果之间的方差。这样既压低了随机性，又能拿到稳定性数据。

评分流程分两步：第一步用解析脚本检查结构合法性和参数完整性，能过滤掉大约 60% 的明显问题；第二步人工审阅剩余结果，重点检查语义一致性和边界处理。整个评测周期花了大约两周，其中人工审阅占了一半时间，成本确实不低，但换来的是评分可信度。

注意：评测使用的平台 schema 固定在一个版本，后续如果换了平台版本，旧分数不能直接拿去横向对比。不同模型在不同平台的 schema 兼容性差异，本身就是重要的评测输入，我在第 3 节会展开讲。

3. 15个模型工作流生成能力实测：榜单与核心发现

3.1 总榜与三个梯队

先直接上总榜。评测对象选了 15 个目前最常被用于工作流生成场景的模型，覆盖商用闭源、开源可私有化部署、国内大模型几个不同阵营。

需要说明的是，这份榜单是我和另外三位同事在逐题人工审阅基础上的结果，不代表任何机构或平台的立场。分数反映的是这套评测任务下的相对表现，换成另一套提示模板或另一批题目，名次会有小幅波动，但整体梯队不会变。

第一梯队是 90 分以上的 Claude 3.5 Sonnet、GPT-4o、Gemini 1.5 Pro。它们的共同点是"复杂指令理解准确、节点结构出错少、长工作流不丢步骤"。

第二梯队是 85 到 90 分的 DeepSeek-V3、Qwen2.5-Max、Kimi K2、Qwen2.5-Coder-32B、DeepSeek-R1、GLM-4-Plus、Doubao-pro。这个区间的模型已经能稳定生成中等复杂度的工作流，但在边界处理和稳定性上会露怯。

第三梯队是 85 分以下的 Qwen2.5-72B、讯飞星火4.0、Yi-Large、Mistral-Large-2、Llama-3.1-70B。它们能完成简单任务，一旦需求里同时包含多个条件分支和多源数据聚合，就容易出现漏节点、连线错乱、参数缺胳膊少腿的问题。

3.2 分维度观察：不同模型的翻车点并不一样

总分放在一起，容易把各自的弱点掩盖掉。把六个维度拆开看，会发现很有意思的差异化表现。

边界处理是所有模型的集体短板。15 个模型的边界处理平均分只有 82.4，是所有维度里最低的。很多模型生成的流程在"正常路径"上跑得很顺，但完全没有考虑请求失败怎么办、数据为空怎么办、用户取消审批怎么办。这类需求往往写在题目的附加约束里，模型却经常视而不见。

Claude、GPT-4o 的优势主要体现在结构和语义上。结构分高说明它们对工作流 schema 的理解更准，语义分高说明它们能把用户需求完整映射到节点链路上。Gemini 1.5 Pro 在长上下文场景下表现稳定，多次采样结果几乎一致，方差很小，这在工程上是很重要的加分项。

国内模型里，DeepSeek-V3 和 Qwen2.5 系列的表现超出我的预期。它们的语义一致性跟第一梯队差距很小，主要输在边界处理和可维护性上。比如 Qwen2.5-Coder-32B 虽然名字里带 Coder，但在工作流结构生成上的表现意外地好，说明代码训练语料对结构化输出是有迁移价值的。

3.3 平台差异：JSON 形式 vs Coze 可视化形式

评测不只做了 n8n 风格的 JSON 工作流，还加了一组 Coze 风格的可视化节点定义题。结果非常明显：所有模型在 Coze 风格题目上的错误率都比 n8n JSON 风格高 12% 到 18%。

原因其实不复杂。n8n 的 JSON schema 在互联网上的公开资料多，模型在训练阶段见过的可能性大；Coze 的节点定义语法更新迭代快，公开示例相对少。模型对 Coze 的"理解"更多来自推理，而不是记忆，一推理就容易出现节点属性名写错、内置节点模块命名幻觉等问题。比如把"条件判断"节点误写成"IF ELSE 节点"，把"变量赋值"写成"变量设置"，字段名一字之差就跑不起来。

这个发现的实践价值很高：如果你正在做 Coze 平台上的工作流生成功能，一定不能裸考，需要在提示里注入当前的 schema 定义和几个标准节点示例。实验数据显示，加了平台模板和 2 到 3 个 few-shot 示例之后，第二梯队模型在 Coze 题上的得分平均能提高 6 到 8 分。

4. 关键案例拆解：好答案与错答案

4.1 案例一："销售日报自动抓取 + 推送" 工作流

题目要求：每天早上九点，从某个电商后台拉取前一天的订单数据，计算总销售额和订单量，生成日报文本，推送到企业微信群。附加约束：如果拉取数据失败，重试两次后仍然失败则跳过推送。

我把这道题的提示词原样贴出来：

请为 n8n 平台生成一个工作流，实现以下功能：每天早上9点从 https://api.example.com/sales/daily 拉取前一天订单数据，字段包含 order_id、amount、status；计算总销售额和订单数量；把统计结果格式化为文本；通过企业微信 Webhook 发送到群。要求：接口请求失败时自动重试2次，重试仍失败则结束流程不发送消息。请输出包含节点类型、名称、参数和连接关系的工作流 JSON。

Claude 3.5 Sonnet 在这个题上拿到了 96 分。它生成了五个节点：Schedule Trigger 定时触发、HTTP Request 获取数据、Code 节点做聚合计算、IF 节点判断 status 是否全部为成功、WeCom 发送节点。最让我满意的是它把"失败重试"做成了 HTTP 节点的内置 Retry-On-Fail 参数，而不是额外挂一个循环节点，这个处理方式非常标准。

Llama-3.1-70B 在这个题上仅得 71 分。它的主要问题有三处：一是把 HTTP Request 节点的 url 参数写成了字面量字符串，没有用表达式引用；二是它试图用一个 Function 节点完成计算，但参数里没有定义输入字段映射；三是重试逻辑完全缺失。三个问题叠加，这个工作流直接导入 n8n 必然报错，属于"看起来很完整，实际完全不能用"的典型。

4.2 案例二："电商评论情感分析 + 汇总报告" 工作流

题目要求：从数据库中读取商品评论列表，逐条调用大模型判断情感倾向（正面、负面、中性），统计各情感类别的数量，生成一份报告并发送到指定邮箱。约束：单条评论为空时跳过，不调用大模型。

这道题的难点在于循环结构、条件判断和大模型调用节点的组合运用。GPT-4o 生成的结果拿到了 93 分。它的结构是：Database Read 节点读取评论 → For Each 循环节点 → IF 节点判断评论是否为空 → LLM 节点做情感分析 → Store 节点暂存结果 → Aggregate 节点汇总 → Email 节点发送。循环内部"为空跳过"的分支被正确地连在了 IF 节点的 false 出口上，拓扑关系非常准确。

Gemini 1.5 Pro 在这道题上出现了一个典型失误：它没有生成循环节点，而是直接生成了一个"分析全部评论"的 LLM 节点，试图让大模型一次处理整个评论列表。这在数据量小的时候可能能跑，但不是题目要求的"逐条分析"，语义一致性被扣了一大截。它的问题不是不会做，而是在"逐条"和"批量"之间做了错误的默认选择。

这道题也让我看到了 DeepSeek-R1 的另一个问题。R1 类模型有强的推理能力，但输出里夹带了大量思考过程和说明文字，把工作流 JSON 包裹在了一段"我来分析一下这个需求"的文本里。解析脚本倒是可以剥离，但如果直接接入产品，这段多余输出会被用户看到，体验很糟糕。

4.3 高频错误模式清单

评测过程中我统计了 15 个模型、240 道题、720 次采样里的所有错误，最终归纳出六类高频问题。

"中文数据库字段名直接被硬编码成变量名但没有定义"是另一个隐藏很深的问题。生成工作流时，模型会把"product_name"这种字段名直接用在一个变量节点里，但前面的数据库查询节点输出的字段名其实是"productName"，两个名字对不上，流程一跑就断。这类问题靠人工审阅才能发现，也说明了纯自动校验的局限。

5. 评测避坑指南与模型选型建议

5.1 这次评测踩过的五个大坑

坑一：提示模板不统一，评测结果就废了。第一轮测试时我给每个模型分别优化了提示词，试图让每个模型都发挥出"最佳状态"。结果数据出来以后完全没法看，根本分不清是模型能力强还是提示词写得好。后来全部换成统一模板，允许模型在输出过程中自行组织，公平性才算立住。

坑二：把"看起来像"当作"能跑"。自动解析脚本只能查格式，查不出逻辑问题。有个模型生成的 JSON 里所有节点类型都是合法的，但两个节点之间的连线 ID 引用了一个不存在的节点，脚本会因为缺少关键字段直接判错，人工看反而一眼能发现。所以评分必须"静态解析 + 人工抽检 + 关键用例模拟执行"三管齐下。

坑三：忽略输出截断。几个开源模型的 4096 token 限制在中等复杂度工作流上不够用，生成到一半就断掉，后半段结构完全缺失。如果不单独记录截断情况，这些模型的实际分数会比看到的还要低。建议在评测指标里额外加一条"一次生成完整率"。

坑四：用平均分掩盖方差。Kimi K2 的总分看起来不错，但拆到单题可以看到明显的"好一次差一次"的波动。对产品来说，一个模型 10 次里有 8 次生成得完美、2 次生成得完全不能用，比一个模型 10 次都生成得还可以更头疼，因为你不知道下一次它会给出哪种结果。所以稳定性这个维度坚决不能省。

坑五：平台 schema 版本漂移。评测进行到一半，n8n 更新了节点定义，把某个字段从必填改成选填。如果不锁定 schema 版本，前后评测数据就没有可比性。后来我把所有平台的 schema 快照存了一份，后续出了新版本就另开一组评测，旧分数继续沿用旧版本口径。

5.2 提升工作流生成质量的三个通用手段

第一，两步生成法。先让模型输出一个自然语言版的执行计划，确认计划结构完整后，再让模型把计划转为正式的节点定义。这个方法看起来多了一次调用，但对提升语义一致性非常有效。模型在"规划"状态下不容易遗漏需求，在"执行"状态下不容易写错结构。实测下来，两步法能让第二梯队模型的语义一致性问题减少约 30%。

第二，给 few-shot 示例。在每个提示里附上一个完整的"需求到工作流"的样例，不用多，一个就够。这个样例要选和当前任务类别相同的题，这样模型能按图索骥地复用结构模式。研究显示，这一步对参数量越小的模型增益越明显。

第三，回读校验。工作流生成完成之后，把生成的节点关系用文本描述出来，再让模型对照原始需求检查一遍，找出遗漏和矛盾。有点类似"让 AI 检查自己的作业"。这一步能有效拦截漏节点和连接错误，尤其是条件分支混淆的问题，我在产品化时把它做成了一个独立的校验器组件。

5.3 按场景怎么选模型

做完评测以后，我自己形成了一套选型建议，按不同业务约束来分：

需要注意一点：榜单的高分不等于产品里的好用。产品里你还要考虑接口延迟、并发、内容安全过滤、成本，以及用户可能给出更口语化、更模糊的需求。这些场景变量都会影响最终体验，榜单只能帮你划出一个候选范围。

结尾

这次评测做下来，我最深的体会是：工作流生成，看似是一个小众场景，实际上是大模型结构化输出能力的试金石。它比代码生成更贴近普通用户的使用习惯，又比纯文本生成有更严格的约束，很适合作为"实用导向评测"的常设科目。

最后再分享一个小技巧。如果你在产品里让模型直接生成工作流，建议在提示词末尾加一句："先输出你理解的步骤列表，确认无误后再输出节点定义。"一句话的代价极低，但对生成质量的中位数提升很明显。我试过在不同的模型上重复验证，效果都稳，算是这次评测里性价比最高的一条经验。以后这个基准还会随着平台更新继续迭代，我也会陆续把不同平台的 schema 兼容性跑得更细，让这份参考能跟着工具的变化保持新鲜。