Shopify CTO Parakhin：AI 阶段跃迁与 2026 使用量爆发

摘要

• Shopify 表示，内部 AI 使用实际上已接近饱和：2025 年12月发生“阶段跃迁”后，日活跃参与率逼近100%。 Claude Code、Codex、Pi 和 Shopify 的 Rover 等 CLI agent 正在超过 IDE 工具；员工获得实际上无限的 token 额度，并被要求：“请不要使用低于 Opus 4.6 的任何东西。”
• Shopify 的核心运营结论是，token 消耗在方向上有参考价值，但如果没有高阶批评和 PR review，本身并不足够。 Parakhin 认为，大量互不沟通的并行 agent “几乎没用”；与其把 token 花在这类 agent 上，他更愿意使用速度更慢的 GPT-5.4 Pro 或 Gemini Deep Think 做验证，因为模型平均写出的代码 bug 可能少于人类，但代码量大幅增加后，整体缺陷数量仍会上升。
• AI 生成代码的规模已将 Shopify 的瓶颈从生成转向集成：PR 合并量月环比增速约30%，此前为10%，同时估算复杂度也在上升。 系统性地延长 review 时间，成本低于测试失败和回滚；Parakhin 表示，围绕人类编码速度建立的 Git 和 CI/CD 可能需要“换一种隐喻”（“a different metaphor”），甚至让这位终身反对微服务的人重新考虑独立部署服务。
• Tangle 和 Tangent 将 Shopify 的 ML 基础设施变成一个能够复利的实验网络，而不再是一堆彼此割裂的 notebook。 内容哈希避免团队之间重复工作，并将同一条 pipeline 带入生产；auto-research 随后在质量不变的情况下，让相同机器上的搜索吞吐从800提升至4,200 QPS，使“电价”足以替代数百次人工试验。
• 本期最明确的投资者判断是，SimGym 的护城河来自数十年的商户与买家结果数据，而不是通用的 agent prompting。 Shopify 花了接近1年时间，将系统与 add-to-cart 结果的相关性推进到0.7；如今，SimGym 使用多模态浏览器模拟，为单个站点推荐转化率改动，用户数仍在日增，眼下的约束是模型和浏览器集群的成本。
• 更大的目标，是把客户乃至整个商户建模为一条条轨迹，再测试干预将在何时、以何种方式改变其未来。 基于 HSTU 的 rollout 可以比较优惠券、感谢卡、活动设置或 cashback 与不干预情形的差异；swyx 认为，这种带有时间维度和丰富上下文的层次超越了静态 A/B 汇总，Parakhin 则称其为“如此大的解锁”。
• Shopify 也在同时压低推理成本、扩大分发：Liquid 模型已经驱动一个300M参数、延迟低于30毫秒的搜索系统，以及7–8B参数的蒸馏批处理任务；UCP 则在运行时开放商品目录发现。 Parakhin 表示，Liquid 凭性能正在这些细分场景中从 Qwen 手里拿走内部份额，但它并不是 GPT-5.4 的前沿模型替代品；商品目录加上身份关联后，暴露出的商品集合“几乎是”全球在售商品的超集。

精读

1. Shopify 于2025年12月跨过内部 AI 阶段跃迁

• Parakhin 图表中的“日活跃员工”指每天至少使用一种 AI 工具的员工，占 Shopify 全体员工的比例。整体比例已接近100%：“现在很难在不深入接触至少一种工具的情况下完成工作。”模型能力的增量改进持续累积，直到2025年12月发生一次“阶段跃迁”，随后采用率和 token 消耗均大幅加速。

• 工具组合也在随使用量变化。不要求员工直接检查代码、以 CLI 为中心的系统增长最快，包括 Claude Code、Codex、Pi 和 Shopify 内部 Rover agent。GitHub Copilot 和 Cursor “并没有真正萎缩”，但以 IDE 为中心的工作流吸引新用户的速度更慢。

• 员工可以自行选择工具，管理层关注的是把事情做完，而不是强制统一界面。Shopify 实际上为无限 token 提供资金支持，同时从“底部而非顶部”设定质量下限：“请不要使用低于 Opus 4.6 的任何东西。”部分员工使用 GPT-5.4 Extra High，代价则涉及是否启用完整的1,000,000-token 上下文窗口等不同取舍。

2. Token 预算只有在批评能力同步扩张时才有效

• swyx 检验了 Jensen Huang 的粗略框架：一名年薪20万美元的工程师如果消耗的 token 不到10万美元，可能没有充分利用 agent；他同时指出其中显而易见的“卖蛋糕者”激励，以及这种做法与按代码行数衡量工程师的相似之处。Parakhin 仍认为 Jensen 在方向上是对的，但双方都没有把某个具体 token 目标视为既定标准。

• Shopify 的试错经验显示，单纯追求消耗量可能掩盖一种有害模式：过多并行 agent 产出工作，却彼此不沟通。相比之下，更少的 agent 在结构化循环中高效消耗 token——一个模型生成，另一个、最好是不同模型进行批评，前一个再修改——效果要好得多；前一种设置“几乎没用”。

• 这些批评循环之所以让人感觉慢，是因为用户需要等待模型轮流工作。但 Parakhin 表示，最终代码质量显著更高。他的质量判断是总量层面的，而非逐行比较：在他看来，如今优秀模型写代码时的 bug 少于普通人，但模型写出的代码多得多，因此最终进入生产环境的缺陷总数仍可能增加。

• Parakhin 想看的指标，是生成支出与昂贵 review 支出之间的比例。Shopify 希望把 GPT-5.4 Pro、Gemini Deep Think 和较长的轮流推理用在 PR review 上，而不是部署大规模 agent 集群；Parakhin 认为，标准 Codex 或 Claude Code 的使用方式“解决不了问题”，不足以遏制生产 bug。由于没有找到满意的商业实现，Shopify 目前使用自研 review 工具。

3. 机器速度编码正在击穿人类时代的 CI/CD

• Shopify 展示的 PR 合并量增速，已从月环比约10%升至30%，估算复杂度也在上升。swyx 将其解读为生产率提升，但 Parakhin 强调了运营成本：代码越多，至少一个测试失败的概率越高，团队不得不找出并剔除问题 PR，在没有它的情况下重新测试，再重新启动部署。

• 因此，一个思考1小时的 review 模型反而可能缩短总交付时间。真正需要比较的，不是即时 review 与等待之间的差异，而是有意放慢的 review 与反复测试失败、回滚之间的差异。swyx 总结这条管理经验：“不要看个人，要看总量，以及总量系统的变化。”

• Shopify 使用 Graphite 和 stacked PR，但 Parakhin 认为 CI/CD 与代码仓库交互是当前最明确的瓶颈。围绕人类编码速度设计的系统，在 agent 输出面前已经“吱嘎作响”，可能需要“换一种隐喻，或者彻底换一种设计”。swyx 把 merge conflict 比作全局 mutex；Parakhin 这位“终身反对微服务的人”开始思考，独立发布的服务是否会卷土重来，但强调：“我不知道。”

4. Tangle 消除了实验与生产之间的数字考古

• Tangle 针对的是一条常见生命周期：数据科学家清理缺失值、过滤 bot、修改脚本，丢掉曾经跑通的结果，最后把 notebook 扔过生产墙。6个月后，路径可能已经变化，脚本也可能崩溃，原作者只能对自己曾经理解的工作展开“数字考古”；随着团队扩大、不断加入新人，这种问题还会成倍增加。

• Parakhin 将 Tangle 与 Airflow 区分开来：Airflow 擅长让一项已经确定的任务按生产计划反复运行，而 Tangle 的核心是让团队或 agent 开发、共享并低成本变体化实验。用户可以复制一条大型 pipeline，修改其中一个组件，运行10个实验或做超参数优化，然后“一键”将产生的工作流部署到生产环境，不必再移植到其他地方。

• 他称 Tangle 是第3代系统，吸收了 Ether、Yandex 的 Nirvana 和 Airflow 的经验。组件可以使用任何语言，底层统一还原为 CLI 调用加 YAML；用户可以用可视化方式组装、复制和共享，同时保留静态版本控制与可复现结果。

• 内容寻址缓存带来了更大的优势。如果版本不同但输出相同，系统就不会重复运行；如果10个实验需要同一项准备工作，该准备工作只执行1次，而且无需团队协调。更大的节省来自之后某个未知团队进行等价工作时：Tangle 会自动识别共同输出，让第2个实验看起来像是“向前跳了一步”。这是一种具有跨团队网络效应的基础设施，而不只是更快的个人工具。

5. Tangent 把可度量工作变成自主爬坡

• Tangent 在 Tangle 之上叠加了一个 auto-research agent。它检查 pipeline，提出改动，运行实验，并围绕 loss function 或其他可度量目标持续修改工作。它既可以对现有组件做表层重排，也可以深入检查代码，创建新的 CLI 加 YAML 组件。

• Boris Power 介绍称，Shopify 搜索在相同机器、质量不变的情况下，通过反复优化代码，将吞吐从800 QPS提升至4,200 QPS。其他循环改善了 Liquid theme 延迟和 prompt 压缩 gisting；一次存储调查还发现，一张巨大的表实际上只是在把1个随机 ID 哈希成另一个随机 ID。

• 这套工具的普惠效果出人意料。虽然最先采用的是 ML 和 AI 工程师，但重度用户之一是一名 PM：现在，他可以凭借领域知识和产品知识驱动实验，而不必手动改代码。Parakhin 的简化说法是：“面向 AI 开发场景的 Claude Code”——用户只需指定想要的结果并持续迭代，不必理解底层每一个算法。

• Boris Power 也明确指出了边界：auto-research 处理的是“某种程度上显而易见、但人类没有带宽去尝试的事情”，而不是严重偏离分布的发明。一项持续数周的业余运行尝试了超过400次实验，最终找到1项改进。Boris 说自己的人工命中率可能更高，但手动做400次试验大概要3年；在这里，“电价完成了这件事”。他原本希望证明 Karpathy 的优化示例是错的，最后却成了支持者。

6. SimGym 的有效性来自 Shopify 对现实世界的校准

• 对模拟客户的质疑很直接：在真空中被 prompt 的 agent，只会复述 prompt。Tobi 最初也提出了同样的挑战。Parakhin 的回答是，Shopify 拥有数十年将真实店面改动与销售结果关联起来的证据，而一家初创模拟器不可能拥有这些历史信息。

• 这些证据本身带有噪声，因为改动很少以孤立的 A/B 测试发生，更多是跨不同时间段的“A/A”比较。Shopify 汇总观测结果，进行去噪，并采用类似协同过滤的方法，花了接近1年时间，将系统优化到内部目标：与 add-to-cart 等结果达到0.7相关性。

• 真实测试还要求多模态 agent 通过浏览器执行操作。仅看 HTML 会遗漏视觉摩擦：设计师可能认为放大商品图片会提升销售，但 Parakhin 表示，销售额“通常”会暴跌。因此 SimGym 需要大量昂贵模拟、渲染页面和强大的多模态模型。早期架构使用 GPT-OSS；当前版本也运行多模态模型。

• Shopify 最初构建的是一个比较两套候选设计的系统，体现了大公司的一种假设：商户已经有 A 和 B 两个方案。团队随后意识到，大多数商户只有1个站点，需要系统替他们生成备选方案。如今 SimGym 可以预测转化行为、提出改动建议，用户数每天都在增加；Boris Power 表示，眼下的问题是通过蒸馏和基础设施优化，降低模型与浏览器成本。

7. 反事实轨迹让模拟超越 A/B 测试

• 现有商户能够改善 SimGym，因为 Shopify 可以重建真实客户的分布，而不是使用通用 persona，从而大幅提升与 add-to-cart 或转化行为的相关性。swyx 将这条历史反馈回路称为股东层面的护城河；Parakhin 也同意，如果没有专有数据，他不会尝试做同样的初创公司，因为否则 agent 的行为将由“你在 prompt 里说什么”决定。

• swyx 从统计角度反驳称，A/B 结果可以总结终点，却无法捕捉随上下文变化、在时间中展开的旅程。Parakhin 表示，Shopify 已经在运行一个基于 HSTU 的系统，用于建模整个公司及其可能路径。在任何一个节点，系统都可以插入反事实干预——优惠券、折扣或个性化感谢卡——再分别推演有干预和无干预的轨迹。

• 同一套机制既可以优化采取何种干预，也可以优化干预时点。Shopify pals 可以提醒商户，加拿大销售似乎配置错误，或者建议一场带有特定参数的活动；在买家层面，平台可以建模折扣或 cashback。Parakhin 的表述是，以这种方式模拟复杂的人和公司，过去有人梦想过，但“完全不可能”。

• 不同商店、不同商品类别的行为差异也很大，因此需要在多个层级进行聚合。Farhan Thawar 表示，Shopify 最近重新启用了 Chinese restaurant process，用于形成自然增长的聚类；这是他自2001年以来就没有再遇到的方法，可用来研究不同类别下买家模式和敏感度的差异。

8. 在延迟优先的 Shopify 工作负载中，Liquid 模型正在胜出

• Parakhin 和 Shopify 团队将状态空间模型视为 Transformer 的更快、更轻量替代品：只要状态保留全部必要历史，就能拥有实际上无限的上下文；但他们也表示，这类模型过去始终不够有表达力。Liquid neural networks 是“强化版 SSM”，表达能力更强，实现也更难；其上下文扩展复杂度低于平方级，尤其擅长与 Transformer 结合的混合形态。

• Shopify 最突出的低延迟案例，是使用一个约300M参数的 Liquid 模型进行 query understanding。系统根据既往搜索，将用户输入的 query 扩展为含义、同义词和个性化可能性，端到端延迟低于30毫秒。要做到这一点，Liquid AI、CentML 和 NVIDIA 必须共同优化整套技术栈，因为其中大量 CUDA 假设最初都是为更大模型设计的。

• 在另一端，Shopify 将大型 teacher 蒸馏为约7–8B参数的 Liquid 模型，用于高吞吐批处理任务。数十亿件商品需要完成 taxonomy 归类、属性标准化，以及识别不同商户之间的等价 listing；这里延迟不如总吞吐和成本重要。Sidekick Pulse 及其他长上下文工作负载也采用类似的任务专用蒸馏。

• Parakhin 明确表示，Liquid “不是万能药”，不会突然与当前部署方式下的 GPT-5.4 竞争。但他称 Liquid 是自己见过的唯一“真正具备竞争力”的非 Transformer 架构，并认为混合 Liquid 模型“可能是我所知道的最优架构，没有之一”。他的反事实判断带有明确保留：如果拥有 Anthropic、Google 或 OpenAI 级别的算力，Liquid 可能与最大模型竞争，甚至胜过它们；与此同时，它凭性能正在 Shopify 内部工作负载中从 Qwen 手里拿走份额。

9. Shopify 正将技术栈从全域商品目录访问延伸至人格

• 录制时讨论的 UCP 发布内容，新增了对 Shopify 商品目录的搜索、按具体 ID 查询和批量获取，使商品选择可以在运行时决定，以确定展示、销售或结账内容。Shopify 同时投入个性化和非个性化搜索，试图暴露 Parakhin 所说的一个“并非完全是，但几乎是一个超集”的商品宇宙，覆盖全球在售商品。

• 身份关联的目标，是把 Google 或其他身份连接到这一商业层，减少使用摩擦。swyx 的平台结论是，任何单个商户都无法独自复现 Shopify 的模拟能力、推理基础设施和历史学习；Parakhin 接受这一框架，并将其概括为“创造网络效应”。

• Sydney 的回顾表明，有意识地设计 AI 人格早于当前技术栈。Sydney 最初在印度上线，使用的是 Microsoft–NVIDIA 合作开发、经过调优的 Megatron-Turing 模型，而非 OpenAI 的模型，起初几乎无人注意。它后来广为人知的锋利风格并非完全涌现：团队借鉴 Yandex 的 Alice，有意让系统学会助手应当“礼貌，但……带一点锋芒”。Sydney 最初的开发负责人 Andrew McNamara，如今负责 Shopify 的 Sidekick。

• Shopify 的招聘需求也围绕这些瓶颈展开：需要更多 ML 和数据科学专家来“处理”不断扩张的数据集，也需要分布式数据库工程师。Parakhin 表示，Shopify 正与 Yugabyte 合作，并探索 LLM 是否能重新构想分布式数据库；这也是更大转向的一部分——从增加 AI 功能，转向围绕机器规模智能重建核心系统。