Shopify Flow：模型会写自动化，商家为什么仍不启用？

Shopify 把自然语言生成 Flow 自动化的模型放到 1% 真实流量后，发现商家启用工作流的比例比原先基于提示词的方案低了 35%。此前离线基准已达到可比水平。差距不是一个总分能说明的：真实商家会修改已有流程、配置邮件、连接第三方应用，也会只咨询 Flow，根本没有创建意图。

这项实践值得拆的，是一个专业任务如何从“生成看起来正确的配置”变成“交付商家愿意启用的自动化”。它同时要求模型理解任务、写对程序、调用正确工具，并在不适合建流程时停下来。官方工程文章

让模型写熟悉的程序，后台继续执行原来的格式

Flow 的业务单位由触发器、条件和动作组成。后台使用专用 JSON 表示，适于解析、校验和执行，却把程序逻辑埋进多层数据结构。直接让模型生成它，等于同时考验业务理解和陌生格式生成。

这次微调对象是 Qwen3-32B，初始离线基准包含 300 个人工编写例子。保持训练数据不变，仅把目标表示从 JSON 改为 Python，作者报告语法正确率提高 22 个百分点、语义正确率提高 13 个百分点。这两项变化来自特定实验，不是模型在所有任务上的提升。

Shopify 引入 Python 中间表示：训练目标和推理输出采用 Python，再由转换器生成后台接受的 Flow JSON。商家仍操作可视化流程，后台也无需改成 Python 执行器。这里的 Python 是表达工作流的内部语言，不能据此理解为给模型开放任意代码执行权限。

转换器承担了一条明确责任：改变表示，保持语义。其连续验证方式是把生产工作流从 JSON 转为 Python，再转回 JSON，与原对象严格比较。任何不一致都应在进入训练数据前暴露。理解这个设计，需要分开三种检验：

• 转换往返一致，回答“表示转换有没有损坏流程”。
• 程序校验，回答“条件、引用、配置能否被系统接受”。
• 业务语义判断，回答“这个流程是否完成了商家要求的事”。

可横向查看，点击打开原尺寸 ↗

图按官方披露重构，展示模型与后台格式之间的责任边界；不表示任意 Python 可以被执行。

三者不能互相替代。一个往返不丢信息的错误流程仍然是错误流程；一个后台接受的流程，也可能执行了错误的商业动作。

工具先给目录，再给所选项的配置

Flow 可用组件很多。把搜索结果中所有动作的完整配置都塞进模型，会让上下文随候选数膨胀，而实际只会选用少数几项。

官方公开了两个工具职责：task_search 先返回名称和描述，供模型选择；task_configuration 再提供所选组件的完整配置结构。它们分别解决“找哪个”和“怎么填”。这是按决策顺序组织上下文，而不是简单缩短提示词。

工具边界还决定训练样本必须包含什么。只训练最后一个工作流，模型学不到何时搜索、如何从候选项收敛、何时读取配置。Shopify 的冷启动从匿名化商家已有的生产流程取样：近七天至少运行过一次，商家至少有两条合格流程，每个描述符保留一个样本以分散类型。再以这些产物倒推用户请求、构造完整多轮工具轨迹。运行记录提供的是流程曾被实际使用的证据，并不证明倒推请求就是当时的真实动机。不过，这些倒推请求是合成训练材料，不能当作真实商家原话，也不意味着它们天然覆盖真实需求。

迁移到其他配置生成任务时，可以据此检查：目录返回是否足以选型？配置是否只在选中后加载？组件的版本、必填条件和互相引用是否有程序校验？这些是接口设计检查，不是本文声称 Shopify 公开的完整工具协议。

训练与服务的细小差异，也会改变行为

模型看见的是整段输入，而不仅是工程师认为有意义的业务字段。官方报告的实际偏差包括：训练工具名带前缀，线上却使用短名；工具排列顺序不同；训练数据对返回对象的键排序，线上顺序或字段却发生变化；生产工具说明持续更新，训练数据没有同步。

这些接口在传统程序眼里可能功能等价，在模型眼里却不是同一个输入分布。它说明训练版本不能只记录模型权重，还应能追溯当时的提示词、工具描述与返回格式。

这里有一项可直接借鉴的发布检查：将同一条真实工具轨迹分别通过训练数据加工和生产适配层，比较模型最终看见的消息，而不只比较底层 API 的业务返回。若差异来自无意的清洗、排序或包装，先修这条链，再判断是否需要更多训练数据。此检查是本文的工程建议。

35% 的落差，改变了评测对象

离线基准考察生成流程的语义、语法和延迟；真实流量暴露的是整个会话生命周期。商家可能在问能否做到、正在编辑、还缺邮件参数，或者根本不该用 Flow。若评价仍只盯着最后的流程对象，模型就可能通过“总是生成一个流程”获得好分。

Shopify 随后把会话质量拆成意图理解、是否适合用 Flow、组件选择、下一步是否清楚等维度，用数百条人工标注会话校准模型裁判。裁判不是天然真值，需要领域人员先给出可对齐的判断。

启用率也没有直接变成唯一训练目标。启用受商家行为影响，不能独立代表模型质量；团队用它监视是否倒退，用经人工校准的分项评价诊断原因。这是业务指标和质量指标的分工：前者提示交付出了问题，后者帮助定位要改哪里。

官方同时按触发器、条件、动作、第三方集成等切片分析。总分上升时，某类条件或集成仍可能落后；把失败按任务结构拆开，才知道应补哪类样本，而不是重复增加最容易收集的数据。

生产反馈必须经过筛选，才是训练材料

真实使用并不自动等于高质量标签。其公开的周度闭环是：采集会话，用裁判评分，把高质量样本送入训练池，把低质量样本隔离审查，再按切片补缺口、训练和部署。商家启用了流程，是候选信号；裁判判断会话质量，是另一道筛选。

这一点阻止“成功使用过”被直接等同于“每一步都值得模仿”。如果只复制商家最后接受的结果，可能把冗长、误路由或无效试探一起学进去。是否需要轨迹级剔除，是迁移团队还应自行验证的问题；官方没有公开全部清洗规则。

周度循环能够持续，也有运行基础：Tangle 将采集、训练、评价与部署接成可复现管道，缓存未受改动影响的步骤；CometML 跟踪实验，HuggingFace 保存数据和检查点，CentML 提供生产服务。官方披露两台 H200 节点、FSDP 分片训练，一轮约十二小时。这里的时间是训练周期，不是商家等待生成的时延。模型、数据加工、评价与部署需要作为同一条可追溯链维护，不能只有一次训练脚本。

官方报告最终方案生成快 2.2 倍、成本低 68%，但这是其 Flow 任务与对照方案的结果，不是所有 Sidekick 请求的统一收益，更不能据此承诺其他企业微调一定优于通用模型。训练需要稳定任务、可校验产物和足够反馈，也需要维护转换器与数据管道。

开始之前，先检查三种失败能否被分开

对一个准备上线的自动化生成器，拿现有真实请求逐条检查：它到底应该创建、编辑，还是只回答问题？输出能否被程序验证？即使能够运行，业务人员是否愿意启用，若不愿意能否说清原因？

若这三类失败还混在同一个“回答正确率”里，先补评价与反馈接口。Shopify 这次弯路说明，训练更好的模型之前，需要先知道产品把什么错误隐藏在了总分里。