Shopify 工程博客精选：LLM Agent 基础设施、移动端测试稳定性与 Checkout 扩展性能优化

欢迎阅读本期 XunbuOS Podcast。今日内容涵盖 Shopify 在 LLM Agent 基础设施（Gisting 上下文压缩、连续学习飞轮）、移动端 E2E 测试稳定性提升、Checkout Blocks 向 Polaris Web Components 迁移，以及 Catalog API 产品聚类等多个方向的深度技术分享。

Gisting：压缩 LLM Agent 上下文以提升吞吐量并降低成本

4:1 压缩比下的延迟与吞吐量收益

Shopify 将 Sidekick GraphQL agent 的系统提示词从约 6,000 个 token 缩减到约 1,500 个 gist token（4:1 压缩比），预测质量不丢失。在 350 RPM 负载下，TTFT 中位数从 438ms 降至 354ms，端到端延迟从 6.8s 降至 4.2s，吞吐量从 20.2 QPS 提升至 23.4。

训练与部署机制

Gisting 通过知识蒸馏学习特殊 token 的嵌入。训练时执行两次前向传播：教师阶段模型看到完整提示词，学生阶段用 gist token 替换，使用 KL 散度训练嵌入。压缩成本只在训练时支付一次，推理时仅需将提示词替换为 gist token 字符串，无需自定义注意力掩码或特殊服务路径。

与前缀缓存叠加

前缀缓存无法消除解码成本——每个生成的 token 都必须对整个 KV 缓存做注意力计算。Gisting 降低了注意力计算和 KV 缓存读取的成本，两者优化叠加，生产环境同时使用。

Autoresearch 优化配方

Shopify 将 autoresearch 循环指向训练器，自动搜索超参数。关键优化包括：用提示词分块的均值初始化嵌入（初始损失降低 7 倍）、找到 4:1 为最佳压缩比、预计算教师 logits 将完整训练从 30 小时缩短到 6 小时。

移动端 E2E 测试稳定性从 50% 提升至 98%：重建测试框架

问题根源

旧框架基于 WebdriverIO + Appium，使用 React Native Test ID 定位元素。无机制强制良好测试模式，开发者常用 pause(1000) 绕过竞态条件，测试实际在验证实现细节而非用户体验。

重建方案：Builder 风格 API + 计算机视觉

新封装层有两个核心部分：

1. 严格 builder API：每一步必须携带断言，声明操作后屏幕应显示的内容。可复用切片如 logIntoApp，逃生舱口以 UNSAFE_ 前缀命名。
2. 计算机视觉替代 Test ID：每一步截取屏幕截图，用 PaddleOCR 识别文本、OpenCV 将截图与 Polaris SVG 进行图标匹配。Test ID 降级为回退方案。

迁移结果

在 Shopify 主应用阻塞 CI 后，测试稳定性从 50% 跃升至 98%。剩余失败主要源于偶发网络问题和模拟器启动故障。新测试必须通过多次运行才能进入阻塞套件。

Sidekick 的持续学习循环：将生产失败压缩为模型权重

从离散产物到参数更新

初始改进集中在提示词、工具定义和脚手架等离散产物。持续学习将生产经验转化为模型连续参数空间的更新。自愈管道每日运行，由前沿推理模型小组批评失败案例、仲裁者合并修复指令、重放对话，经 SFT 和 GRPO 微调。

GraphQL 代理实战数据

• 专用模型超越前沿模型性能
• 服务成本降低 96%：从每年约 2,700 万美元降至接近 100 万美元
• Gisting 将系统提示词从约 6,000 token 压缩至约 1,500 token
• 端到端延迟下降约 38%，GPU 用量减少约 14%

质量定义先行

质量始于评分标准，产品团队将需求转化为评分标准并配备具体锚点。两位专家标注员盲注 25 个随机样本，Cohen's kappa 低于 0.2 说明标准有歧义，需迭代。评判者需与人类标注一致性达到人类彼此间一致性水平。

构建超越模型的 Agentic 框架：安全测试的经验

Dispatch 多阶段扫描工作流

内部框架编排器 Dispatch 将扫描分为九个有序阶段：测试引导、架构文档、文件编目、分区、狩猎、验证、后处理、报告、修复。验证器使用与猎手不同的模型，对抗性审查减少噪音。

测试预言机是关键

Web 漏洞无直接测试预言机，Shopify 将验证嵌入应用现有测试流水线。例如 IDOR 验证器要求：从公开调用点反向工作、创建跨租户测试夹具、测试覆盖公共技术栈、提取有影响力的数据。

分区策略平衡成本与召回率

目标 token 数约为模型上下文窗口的 20-30%，按相关领域分组文件。使用分区后，准确率和召回率均有提升，同时保持低成本。完整应用扫描成本 50-300 美元，增量 diff 扫描仅 5-50 美元。

Checkout Blocks 应用升级至 Polaris Web Components

包体积缩减 40-85%

五个高流量结账扩展从 React + Remote UI 迁移至 Preact + remote-dom + Polaris Web Components。传输体积缩减：payment-icons 降 84.4%，static-content 降 54.1%，custom-field 降 44.6%。

加载性能提升

按结账量加权的 ELT P50 下降 8%，P90 下降 7%。payment-icons 扩展的 ELT P50 和 P90 均下降约 12%。

压到 64KB 以内

2026-01 版 remote-dom CLI 强制要求每个扩展包 gzip 后不超过 64KB。主要削减来源：

• 移除 react-reconciler（约 89KB），切换到 Preact 后免费获得
• 自研 Liquid 解析器 "droplet" 替换 liquidjs（gzip 后 13KB vs 22KB，使用 42,000 行生产对等语料库验证）
• 小型内部日期工具替换 dayjs（约 12KB）
• 保留 markdown-to-jsx（约 15KB），通过 pnpm workspace catalog 别名到 Preact

修复的关键 Bug

• ID 冲突（唯一一次生产回滚）：useId() 生成确定性 ID，同一扩展两个实例产生相同 ID。修复方案是 useStableId Hook 生成随机的实例唯一 ID。
• 文本对齐：Polaris Web Components 的 Paragraph 移除了 textAlign。跨职能决策后在 ui-extensions 重新暴露 textAlignment（PR #4455）。
• s-checkbox label 插槽：重构为接受字符串或 HTMLElement，仅允许 s-text 和 s-link（PR #4395）。

使用 Catalog API 对数百万产品进行聚类

核心价值主张框架

关键问题是：买家主要购买这个产品的目的是什么？属性不改变答案就是变体；确实改变答案就是产品身份的一部分。例如蛋白粉口味是变体，油漆颜色是产品本身。

精确率优先策略

收紧阈值提高精确率会错过有效匹配，放宽阈值提高召回率会错误归组。Shopify 选择严格精确率阈值下最大化召回率——展示错误结果比结果不完整更糟糕。

两阶段 LLM 管道

预分块使用 ANN 检索（FAISS + HNSW，每个产品连接 100 个最近邻）+ 稀疏平均链接（UPGMA，距离阈值 0.25，最大块大小 200 个产品）。阶段 1 提取品牌 + 型号，阶段 2 异常值检测，默认保持项目在一起除非有明确证据。

动态结构化输出 schema

为每个块动态生成 JSON schema，在输出 products 对象中为每个产品 ID 定义必需的 brand 和 model 字段。schema 强制完整性——LLM 不可能跳过产品。排序控制推理：要求 patterns 数组在 products 对象之前。枚举约束防止幻觉，outliers 数组列出聚类中每个有效产品 ID（上限 500）。

Teaching Sidekick to say no：LLM 评审共识驱动的数据整理

问题：训练数据盲区

生产语料只包含成功查询，模型从未学会拒绝。当被问及无法实现的查询时，模型生成返回零结果的查询，给商家造成"没有匹配客户"的错误印象。

四评审员严格共识

四个独立 LLM（A、B、C、D）各自评估查询，只有全部达成一致且推理一致才接受标签。分歧案例被过滤而非仲裁解决。四个互斥分类：需要更多上下文、功能缺失、技能错误、存在歧义。

成果数据

客户细分技能评估分数从 0.619 提升到 0.798（相对提升 28.9%）。拒绝准确率 86.3%，误报率 4.6%。四个模型与种子数据的 Cohen's kappa 全部高于 0.75。

Shopify Hack Days：为音乐页面构建音频播放器原型

平台级 Audio 媒体类型的可行性

13 人团队在三天内通过五个 PR 在 Core、Admin API、admin-web 和 storefront 中添加了新的 Audio 媒体类型：新增 audios 数据库表、Merchandising::Audio 模型、Audio GraphQL 类型、Liquid drops 及自定义 audio-visualizer web 组件。{{ product.media | media_tag }} 可像渲染 3D 模型的 model-viewer 一样渲染音频播放器。

Metaobjects 作为数据层

发布是 metaobject，曲目列表是其上的 JSON metafield，音频文件等是产品变体上的 metafields。具有 storefront: PUBLIC_READ 访问权限的 Metafields 可通过 Liquid 自动提供给主题扩展，无需自定义 API。

Ruvy：将 Ruby 编译为 WebAssembly 的工具链

预初始化 VM 提升性能

Ruvy 在构建 Wasm 模块时预初始化 Ruby VM，而 ruby.wasm 在模块执行时启动。基准测试显示实例化和执行 _start 函数快约 20%，Wasm 到原生代码编译时间减少约 70%。

免 WASI 参数执行

生成的模块无需提供文件路径作为 WASI 参数，适用于无法配置额外 WASI 参数的边缘计算环境。支持通过 --preload 标志预加载 Ruby 文件目录。

构建 ShopifyQL 代码编辑器：连接 ANTLR 语言服务器与 CodeMirror

自定义适配器桥接 LSP 与 Lezer

ShopifyQL 语言服务器基于 ANTLR TypeScript 目标构建，遵循 LSP 协议。CodeMirror 使用 Lezer 解析引擎，两者不直接兼容。解决方案是创建遵循 LSP 的自定义适配器：将查询传递给语言服务器，获取 token 流，转换为 Lezer 节点缓冲区。

Token 偏移转换

最困难的部分是处理 ANTLR 的增量偏移。ANTLR token 的行和字符值是相对于前一个 token 的，注释甚至可能出现在主通道解析完后才解析（行值可为 -2）。解决方案是自研 TokenIterator 类：

• 接收文档并推导每行长度
• 内部跟踪当前行和当前字符
• 摄取 ANTLR 风格描述符并移动位置
• 用当前行、字符和行长度计算 CodeMirror 风格的绝对偏移

完整语言功能

将语言服务器的 doValidate、doComplete、doHover 分别与 CodeMirror 的 linting、autocomplete、requestHoverTooltips 插件适配，实现语法高亮、自动补全、代码检查和悬停提示。

播客全文

女：Hello 大家好，欢迎收听XunbuOS Podcast，我是小雅。

男：大家好，我是老冯。

女：今天这期内容挺特别的，我们收到了来自 Shopify 工程团队的不少好东西，从 AI 模型、测试框架到电商数据聚类，什么都有一点。老冯，咱们先从哪个说起？

男：我想先聊那个 Gisting，就是压缩 LLM 上下文的那篇。这玩意儿让我挺兴奋的，因为在 GPU 这么贵的今天，能把系统提示词从 6000 个 token 压到 1500 个，而且质量不掉，这省下的可都是真金白银。

女：等等，你先把概念说清楚。Gisting 具体是做什么的？

男：简单说，就是训练一组特殊的 token，叫做 gist token，用它们来替代冗长的系统提示词。你想想，一个 agent 每次请求都要带上几千个 token 的系统提示词，这就像每次寄快递都要附上一本使用手册一样，又慢又贵。

女：这个比喻挺形象的。那它具体是怎么训练的？

男：核心是知识蒸馏。他们跑两遍模型，一遍让模型看完整的提示词，这叫教师阶段；另一遍用 gist token 替换提示词，叫学生阶段。然后用 KL 散度来训练 gist 嵌入，让学生阶段的输出尽量接近教师阶段。模型权重是冻结的，只训练这些嵌入。

女：所以这些 gist token 就像压缩饼干一样，把指令的营养都浓缩进去了？

男：对，而且关键是不需要改模型架构，推理时就和普通模型一样加载。唯一的变化是把提示词替换成 gist token 字符串。他们测试在 350 RPM 的负载下，首 token 时间下降了 19%，端到端延迟下降 38%，吞吐量提升了 16%。

女：那这不是跟前缀缓存有点重复吗？现在很多服务引擎不都有 KV cache 吗？

男：这就是这篇文章有意思的地方。前缀缓存确实能省去重复计算系统提示词的 KV 张量，但它消除不了解码成本。模型每生成一个 token，都要对整个序列做注意力计算。序列越长，注意力计算和 KV 缓存读取的开销就越大，尤其是批处理规模大了以后。Gisting 是直接缩短序列长度，这两者是叠加的收益，不是二选一。

女：明白了。那他们是怎么找到这个最优压缩比的？听起来超参数调优这事儿挺棘手的。

男：他们搞了个 autoresearch 循环，让 agent 自己提配方、训练、评估，反复迭代。有三项优化特别关键。第一是初始化，他们不是随机初始化嵌入，而是把系统提示词按压缩比切块，然后用每块的平均值来初始化对应的 gist token，这一下就把初始损失降低了 7 倍。第二是找压缩比的临界点，4:1 是他们这个场景下的最优值。第三就是数据量和多样性。

女：7 倍，这个数字确实惊人。那除了延迟，还有什么实际收益？

男：吞吐量提升了 16%，这直接转化成了 GPU 节省。他们算过，在服务 GraphQL 流量的硬件配置下，GPU 用量减少了 14%。而且这玩意儿还能配合持续学习用，每次迭代不需要从头蒸馏 gist 嵌入，可以在已有基础上继续训练。

女：这听起来像是在说，以后跑 AI 的成本可以降下来不少。那接下来咱们聊聊移动端测试的事？那篇从 50% 稳定性提升到 98% 的文章，我看了觉得很神奇。

男：这个确实是个很典型的重构案例。他们之前的 E2E 测试跑在 WebdriverIO 加 Appium 上，用 React Native Test ID 找元素。问题在于 Appium 太灵活了，没有任何机制强制好的测试模式。开发者为了省事，经常就是点击之后加一个 pause(1000)，看起来本地能过，CI 也能过，但哪天屏幕加载慢一点就挂了。

女：这种事儿我太熟了。测试工程师最怕的就是这种 flaky test，跑十次挂三次，你都不知道是代码出问题了还是测试本身在抽风。

男：对，所以他们这次没有继续打补丁，而是围绕 Appium 建了一个强约束的封装层。核心是两个改动，第一个是严格的 builder 风格 API，每个操作必须带断言。比如你点击某个按钮，必须同时声明操作之后屏幕应该显示什么。如果没达到预期状态，测试在出问题的那一步就立刻失败，而不是等到后面才暴露。

女：这个设计我觉得特别好。相当于每一步都在验证，而不是到最后才知道崩了。

男：第二个改动更有意思，用计算机视觉替代 Test ID。每个步骤都截图，然后用 OCR 识别文本，用 OpenCV 匹配图标。你想点击“Save”按钮，直接写 touch({ text: 'Save' }) 就行，不用再打开检查器去翻组件树找 testID 了。

女：这对写测试的人来说确实友好多了。但视觉匹配不会不稳定吗？比如不同分辨率的设备，或者主题样式变了？

男：这是个好问题。他们做了不少工程来保证稳定性。图标匹配是用 Polaris 设计系统的 SVG 做模板，在多个尺寸变体和颜色反转变体中匹配。对于重复元素，会用位置邻接关系来消除歧义，比如“图标 1 在图标 2 左边”。而且 Test ID 并没有完全移除，只是作为回退方案，但必须通过 UNSAFE_testID 字段才能用。

女：我注意到这个 UNSAFE_ 前缀的设计挺妙的，从命名上就暗示开发者“用这个是有风险的”。

男：没错，这个设计让代码审查也轻松了，看到 UNSAFE_ 前缀，审查者就知道这里需要特别关注。结果就是把稳定性从 50% 提到了 98%，剩下的失败基本都是偶发的网络问题和模拟器启动故障。

女：那这个框架对 AI 友好，具体体现在哪儿？

男：因为 API 的语法跟屏幕内容一一对应，所以 AI 工具可以更容易地生成正确的测试代码。比如你说“写一个创建产品的测试”，AI 看到“Create product”按钮就直接生成 touch({ text: 'Create product' })，不需要理解代码库内部结构。

女：这个思路确实很前瞻。好了，咱们聊了不少技术细节，该聊聊商业模式了。我看到一篇讲 ShopifyQL 代码编辑器的文章，里面提到了一个很有意思的点，就是商家可以用自然语言来查询数据。老冯，这个跟前面的 AI 话题有没有关联？

男：哈，你问到点子上了。其实 ShopifyQL 是 Shopify 自己的查询语言，专门给商家分析店铺数据用的。他们用 CodeMirror 做编辑器，但 CodeMirror 不支持 ShopifyQL，所以他们搞了一个适配器，把 ANTLR 语法生成的 token 流转换成 Lezer 能理解的解析树。

女：听起来是个很工程化的活儿。不过我更想知道，这对商家意味着什么？

男：对商家来说，他们可以用像“FROM products SHOW product_title”这样的语法来查数据，比直接写 SQL 简单多了。而且编辑器有自动补全、语法高亮、代码检查这些功能，出错率会低很多。

女：这个语言服务器协议 LSP 的思路我觉得挺对的。把语言逻辑和编辑器解耦，这样以后换编辑器也不用重写语言逻辑。

男：对，前端所有的 ShopifyQL 功能都封装在一个 TypeScript 语言服务器里，遵循 LSP 协议。CodeMirror 通过一个自定义适配器来跟它通信。中间有个技术难点，就是 ANTLR 的 token 偏移是增量式的，而 CodeMirror 需要的是绝对偏移。他们写了一个 TokenIterator 类来解决这个问题。

女：这个我大概理解了，就是偏移量转换的数学题。好，那咱们再回到业务层面。我看到一篇关于 Checkout Blocks 升级到 Polaris Web Components 的文章，里面提到了一个 64KB 的包体积限制，这个对开发者来说是不是很头疼？

男：哈哈，这个确实是让我这种开发者看了就头疼的限制。但 Shopify 这么做的逻辑也很清楚——结账页面是极度性能敏感的，每个扩展都在增加买家决策时刻的延迟。他们升级到 remote-dom 加 Polaris Web Components 之后，包体积下降了 40% 到 85%，加载时间也快了 8% 左右。

女：那这个 64KB 的限制是怎么倒逼他们做优化的？

男：说实话这篇文章最有意思的部分就在这儿。他们原来的包是 300-356KB，gzip 后 100-112KB，超了两倍多。为了压到限制以内，他们做了几件特别狠的事儿。最大的一笔收益是移除 react-reconciler，大概省了 89KB，这是切换到 Preact 之后免费获得的。然后是替换掉 liquidjs，他们自己写了一个极简的 Liquid 解析器，内部代号叫 droplet，就为了比 liquidjs 再省 9KB。

女：自己写一个解析器？这听着风险很大啊。

男：对，但他们做得很严谨。他们从数据仓库里抽取了数千条真实商家的 Liquid 配置，配上 liquidjs 的精确输出，建了一个超过 42000 行的测试套件。直到 droplet 在这个语料库上和 liquidjs 完全一致，才敢用。另外还用 @preact/compat 把 markdown-to-jsx 别名到 Preact 上，这样就不用换掉这个库了。

女：42000 行的测试套件，这个数据驱动的验证思路很扎实。

男：对，他们还有一句很有价值的总结：“硬性包体积限制虽然挑战大，但对买家体验非常有益。它倒逼你做出拖延已久的决策。”我觉得这个说得特别对，有时候不给自己设定一个硬性边界，就永远在舒适区里打转。

女：说到打转，我有一个问题想问你。你看前面聊了那么多 AI 和机器学习，咱们现在来聊聊数据的问题。有一篇关于用 Catalog API 对产成品进行聚类的文章，里面提到了一个“核心价值主张”框架。老冯，你对这个怎么看？

男：哎呀，这个框架我当时看了就觉得特别妙。他们给模型提了一个问题：买家主要购买这个产品的目的是什么？如果一个属性不改变这个答案，它就是变体；如果它改变答案，它就是产品身份的一部分。比如同一款蛋白粉，巧克力味和香草味都是变体，因为买家买的是营养和健身目标。但对于油漆来说，午夜蓝和鼠尾草绿就是不同的产品，因为颜色就是产品本身。

女：这个框架确实很清晰。但问题是，要判断“买家主要购买目的是什么”，这需要理解产品上下文，不是简单的正则就能搞定的。

男：所以他们就用了 LLM。但他们不是让模型直接“聚类这些产品”，那样太模糊了。而是先分析店铺整体的命名模式，然后提取品牌，最后用核心价值主张测试来判断属性。而且他们有一个很聪明的分层策略：先用一个单例检测器，分析店铺的 Liquid 主题代码，如果产品已经是独立条目，就标记为单例，跳过整个 LLM 流程。只有真正模糊的案例才需要 LLM 来判断。

女：也就是说，能不用 AI 就不用 AI，但需要的时候 AI 又很厉害。这个思路挺务实的。

男：对，而且他们在推理时还做了两步：第一阶段提取品牌和型号，第二阶段是异常值检测，用第二个模型来审查第一阶段的聚类提案。这就像写代码先写个草稿，然后自己review一遍，能发现不少问题。

女：这个比喻很贴切。那咱们再回到 AI 本身。有一篇讲 Sidekick 持续学习的文章，里面提到了一个“数据飞轮”的概念。这个跟咱们之前聊的 Gisting 是不是一个体系里的？

男：对，这其实是同一篇技术脉络里的两篇文章。Gisting 是解决推理成本的问题，而持续学习是解决模型质量的问题。他们构建的飞轮逻辑是这样的：先用前沿模型快速上线产品，然后用评审器校准质量，再通过自动化数据整理收集生产中的失败案例，最后用强化学习把这些教训融合进一个小模型。

女：听起来是个很完整的闭环。那这个飞轮的实际效果怎么样？

男：文章里说得很具体。他们的 GraphQL 代理，每分钟服务最多 2000 个请求，用这个飞轮之后，专用模型超过了前沿模型的性能。更关键的是成本，如果用前沿模型服务这些流量，估计每年要花 2700 万美元。微调后的模型成本只要接近 100 万美元，降了 96%。

女：96%？这个数字真的有点吓人。

男：但更吓人的是这个数字背后的逻辑：不是说你省了 96% 的成本，而是说，有些功能在原来成本结构下根本无法为所有商家开启。当你把价格降到之前的一个零头，就能把以前只有大企业才能用的功能，变成每个商家都能用的标配。

女：这个点确实很打动我。技术创新的意义不只是省了多少钱，而是打开了原本不存在的可能性。那这个飞轮是怎么运作的？听起来挺复杂的。

男：是的，核心环节挺多。首先得定义质量，一份评分标准，把好的表现拆成几个可打分的标准。然后让两个产品专家盲注 25 个随机样本，测标注者间一致性。如果 Cohen's kappa 低，说明标准有歧义，得再去开会迭代。校准评审器之后，就把它当成离线指标，用来优化模型和提示词。

女：等等，这听起来像是先定义目标，然后校准测量工具，然后再优化。这个流程倒是很像工程管理的套路。

男：对，但最难的部分在后面。他们有一个自愈管道，每天从生产流量里挖掘困难负样本——就是那些评审器打低分、模型表现最差的对话。然后让一组前沿推理模型去批评这些失败案例，一个仲裁者把批评合并成修复指令，再重放对话，如果修复通过，就成为强化学习的轨迹。

女：这个流程有点像我们人类的持续学习方式。你犯了一个错，旁边的人告诉你哪里不对，下次你就知道怎么改了。

男：最关键的是这个过程是全自动的。每一个生产缺口都成为下一轮训练的燃料，就像滚雪球一样，越滚越大，越滚越干净。

女：那这个飞轮跟前面讲的那个“拒绝能力”的文章是不是一个系列的？我看到一篇专门讲怎么让模型学会说“不”的。

男：对，那是他们构建 Sidekick 时遇到的另一个问题。训练数据全都是成功查询，模型从来没学过拒绝。当商家问一个根本无法实现的问题，比如“查找是医生的客户”，Shopify 根本不存职业数据，模型不会直接拒绝，而是生成一个返回零结果的查询。商家看到零结果，以为是真没有匹配的客户，而不是请求本身无法实现。他们最初尝试人工标注来补充拒绝样本，但遇到了一个致命问题：同一个查询在两个数据集中出现，却带有相反的标签。一个在生产环境里成功通过的查询，在标注数据里却被标成需要拒绝。模型被矛盾的信号搞糊涂了，训练不稳定。

女：那他们怎么解决这个冲突？

男：关键是引入了评审员小组。四个前沿 LLM 各自独立评估，只有当四个都达成一致，而且推理也一致，才接受标签变更。有分歧就过滤掉，不求百分百覆盖，但保证不误伤。他们把 600 个标注样本作为种子数据，校准评审员之后，再跑在完整的训练语料库上。

女：你一直在说“前沿LLM A, B, C, D”，这让我想起一个更实际的问题。我们前面聊了这么多 AI 的东西，从 Gisting 到飞轮再到聚类，那这些技术对普通商家来说意味着什么？他们能感知到这些变化吗？

男：这个问题问到点子上了。你想想 Sidekick 这个 agent，商家跟它对话，问“哪些产品快缺货了”或者“帮我向最佳客户发折扣”。在视频里面，这些对话背后经过了层层处理：规划器理解意图，技能模型生成正确查询，飞轮提供持续改进的训练数据，Gisting 保证延迟和成本可控。但商家感知到的，只是“这个 AI 助手好像还挺懂我的”。

女：这其实就是技术最好的一种状态——你感知不到技术的存在，但它让一切都变得更好了。

男：说到这儿，我想起那篇移动端 E2E 测试的文章里有一句话：“E2E 测试也回归了其本职：拦截错误变更，不阻碍好的变更。”这其实就是所有技术工具的理想状态——不添乱，但能挡灾。

女：还有一句话我印象很深，是大数据聚类那篇里的：“如果四个独立的模型无法就一个标签达成一致，那就应该由人类来做决定。”这个思路我觉得放之四海而皆准。

男：对，这就是为什么我觉得 Shopify 工程团队的文章值得读。他们不只是在讲技术方案，更是在讲怎么用一套方法论来系统性解决问题。从数据、到模型、到工程实现、到业务落地，每一步都有清晰的逻辑线。

女：确实。今天聊了这么多内容，从 LLM 压缩、E2E 测试、持续学习、产品聚类、Checkout 升级，到 ShopifyQL 编辑器，每一篇都很有干货。

男：最让我记住的是那篇 Checkout Blocks 文章里的一个细节——他们因为在迁移过程中遇到了 ID 冲突，导致了一次生产回滚。但就是因为有监控、有回滚机制、有逐步发布策略，问题在当天就被发现并解决了。这让我想到，稳定性不是靠没有 bug 实现的，而是靠快速发现和快速修复的能力。

女：这句话说得太好了。好了，咱们今天的节目就到这里。如果你喜欢我们的节目，别忘了订阅 XunbuOS Podcast，我们会持续带来 Shopify 生态和 AI 领域的最新动态。我们下期再见！

男：下期见！

参考链接

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

---

迅步科技专注Shopify独立站，Shopify应用及无头网站开发，为您的品牌提供快速、灵活、个性化的电商体验，提升用户转化率与运营效率。欢迎咨询合作。