深入Shopify的AI优先工程实践手册

Shopify在AI原生开发方面引起了大量关注，这在很大程度上得益于CEO Tobi Lütke和其他领导者的病毒式传播帖子，他们描述了AI如何深度融入工程师的日常工作流程。

在一篇帖子中，Tobi表示他在”过去三周编写的代码比过去十年还多”，并将这一增长归功于AI工具。这些帖子迅速在创始人和投资者中传播，引发了广泛的好奇心：这种炒作是否真实？以及领导层如何让工程师以AI优先的方式运作。

我们与Shopify工程副总裁兼工程负责人Farhan Thawar进行了对话——他估计他的团队效率提高了20%——以揭示公司的AI实践手册。Farhan和他的团队是AI的早期采用者。他回忆说，当GitHub首次推出Copilot产品时，他给公司CEO发短信说：“我不关心你们是否有上市计划。我不关心价格是多少。我怎样才能让这个进入Shopify，让每个工程师都能使用？“当CEO说这还不可能时，Farhan记得他回复道：“想办法。”

这比ChatGPT普及AI使用早了一年。“我就知道这会改变我们的工作方式，“Thawar说。五年后，AI已经爆发，Farhan仍然处于这项新兴技术可能性的前沿。在这份操作指南中，Farhan分解了他对AI的方法——从驱动它的基础设施到他如何衡量工程生产力以及他对Agentic未来的预测。

Shopify AI优先工程战略的关键要点

基础设施标准化解锁工具实验。Shopify没有强制团队使用单一AI工具，而是标准化了底层——构建了一个LLM代理，将所有AI请求通过一个网关路由。这种方法允许工程师同时实验Claude Code、GitHub Copilot和其他工具，同时保持集中成本控制、使用分析和模型灵活性。教训：在快速发展的AI领域，标准化基础设施，而不是工具。
20%的生产力提升是真实的，但并非关于代码量。Farhan的团队实现了大约20%的生产力提升（Farhan表示这只是一个保守估计），但并非通过代码行数或拉取请求等传统指标（这些很容易被操纵）。真正的好处体现在更快的原型设计、探索10种方法而非两种，以及跨所有职能的更高保真度交付。衡量进步的最佳指标？展示切实速度并实时解锁团队的周会演示。
文化采用永远胜过自上而下的命令。Shopify的”让它看起来简单”方法——领导者公开分享他们如何用AI解决问题，而不是纯粹展示智慧——推动了工程、销售、财务和人力资源的有机采用。结合低摩擦的启用，如提示词库、设置指南和MCP服务器连接，这种文化引导导致了意想不到的结果：销售人员创建自定义仪表板，财务团队创建由非工程师构建的”n-of-1”软件。访问+启用+领导建模=有效的变更管理。
理解债务是#1长期风险。虽然AI可以极大地加速开发，但Farhan警告说大脑是一块你不能让它萎缩的肌肉。如果工程师停止深入思考和学习，他们将失去对系统的理解。他的防护措施：工程师必须了解他们工作层面以下2-3层的系统，使用AI来加速学习，而不是替代它。积累理解债务的公司将无法在系统崩溃时维护或演进它们的系统。
2026属于那些掌握Agentic Harness的人。下一个竞争优势在于编排AI Agent，要么通过并行执行（10个Agent同时工作，人类审查和合并），要么通过顺序批评循环（45分钟以上的思考会话，多模型询问）。Farhan的观点很直接：“如果你不在2026年弄清楚如何利用Agent，你就会落后。“工程师需要从编写每一行代码转向指导智能系统和评估输出——这是一种完全不同的技能集，需要新的基础设施、工作流程和心理模型。

第1部分：AI基础设施

1. 标准化基础设施，而非AI工具

Shopify AI战略的基础是其基础设施。Shopify没有标准化单一AI工具，而是专注于构建一个允许多个工具和模型共存的平台层。团队构建了一个集中的LLM代理——一个将所有AI请求通过单一平台层路由的内部网关。代理位于Shopify的内部工具和底层AI模型之间。来自Claude Code或Copilot等工具的每个请求在到达OpenAI、Anthropic或Google等提供商的模型之前都要通过代理。

Shopify标准化了所有AI工具运行的基础设施层，而非单一AI工具。这个系统有很多好处，包括Shopify可以集中管理成本。由于AI模型按token收费，数千名员工的成本可能迅速上升。通过批量购买token并通过共享网关路由使用，他可以访问折扣批量费率，同时还能监控团队和项目之间的支出。

领导层可以看到实验发生在哪里，哪些工作流程正在获得牵引力。“我可以按团队、按项目、按人员查看使用情况，“Farhan解释说。“如果有人一天花费超过250美元的token，我们会收到警报。“Farhan不是关闭它，而是调查他们在构建什么，经常发现雄心勃勃且有价值的实验，比如尝试重构Shopify移动代码库的大部分。

代理还创建了模型灵活性。因为工具连接到网关而非直接连接到提供商，Shopify可以在功能改进或成本变化时在后台切换模型。

2. 将AI连接到内部系统

当AI工具能够与员工已经用于工作的系统交互时，它们会变得更有用。在Shopify，这是通过MCP服务器和内部系统（如他们的wiki、产品管理工具（GSD）和数据仓库）完成的。这些服务器允许AI工具以结构化的方式在这些系统中查询和检索信息。

例如，准备会议的员工可以向AI助手询问有关人员或账户的上下文。系统可能会从Salesforce中提取信息，检查相关的Slack对话，并查看Google Workspace中存储的日历事件或文档，以构建更全面的图景。关键的是，访问控制保持不变。AI只检索用户已经有权查看的信息。“因为它走的是你相同的认证流程，“Farhan解释说，“它不会给我我没有权限访问的信息。”

一些MCP服务器是内部编写的，而另一些来自供应商。但无论它们来自哪里，它们必须满足与其他内部系统相同的可靠性和测试标准——因为一旦AI如此深入地集成到工作流程中，这些连接就成为公司核心基础设施的一部分。

3. 使内部工具易于构建和部署

Farhan将Shopify的内部工具时刻比作互联网的早期。“如果你还记得GeoCities，你可以直接在互联网上创建一个带URL的网站，“他说。目标类似：消除摩擦，让公司中的任何人都能快速创建和共享简单软件。

为了实现这一点，Shopify构建了一个名为Quick的内部工具。员工可以拖放JavaScript、TypeScript或HTML文件，分配一个URL，并立即部署一个公司内部任何人都可以访问的工作应用程序。这极大地降低了构建小型内部工具的门槛。销售、支持、财务和其他团队现在可以使用AI工具生成简单应用并部署它们，而无需工程帮助。

Farhan分享了一个最近商户会议的例子。在通话之前，有人给他发了一个Quick链接，将从内部系统和数据源中了解该商户所需的一切编译成一个简单的仪表板。

员工可以构建这些”n-of-1”工具，而无需等待工程资源。结果是更少的运营摩擦和公司内部更多的实验，通常导致团队解决自己的问题并提高GTM效率和收入。

4. 允许工程师实验多种工具

许多组织以与软件采购相同的方式处理AI采用：选择一个标准工具，全公司推广，并限制其余工具。谈到AI，Farhan采取了相反的方法。Shopify没有标准化单一AI工具，而是标准化了底层的基础设施层。

今天，Shopify工程师使用广泛的AI编码工具混合，包括Cursor、Claude Code、GitHub Copilot、OpenAI Codex和Gemini的实验工具。公司有意允许这种多样性，因为AI生态系统的演变太快，单一最佳工具无法出现。“在Shopify，我们总是为一项工作使用一个工具——除了AI，“他解释说，“因为我们还不知道哪家公司、工作流程或模型会赢。“

第2部分：采用与启用

5. 通过文化与工具配对驱动AI采用

当Farhan首次在Shopify推出Cursor时，采用以他意想不到的方式火爆。他原本预计工程师会成为主要用户。然而，该工具很快在销售、财务和人力资源团队中获得了牵引力。Farhan回忆起Tobi开玩笑说发布几乎太成功了。Cursor团队甚至想知道Farhan如何让销售人员如此成功地采用该工具。

Farhan定期发布他用AI完成的工作示例，将其框架为不是展示智慧，而是展示杠杆：“我没有说看我做了多少工作，我有多聪明。我说，看我有多懒。“这种全公司范围的分享、可见的领导建模和低摩擦启用的组合使采用感觉不像是一个指令，而是一个明显的优势。

一旦R&D以外的人接触到这些工具，他们就开始构建Farhan所称的”n-of-1软件”——为他们自己的工作流程定制的小型、高度特定的工具。销售团队正在编写查询、构建报告、创建甲板并生成月度业务审查（MBR），而无需等待工程。领导层然后通过公开分享他们自己的用例来帮助强化这种行为。

结果是工程和公司范围内的深度广泛采用。“我们的许多策略只是推动、向人们展示演示，并吹嘘我们有多’懒’——更聪明地工作，而不是更努力地工作，“他说。“我们会说，‘看我在五分钟内构建了什么。‘没有强迫。我只是试图向人们展示什么是可能的。”

Farhan强调，使用AI的推动首先是文化的，配以有意识的启用和对工具的广泛访问。这包括实际入职、设置指导、所有系统到MCP服务器的连接，以及一个内部提示词库，让员工可以重用和调整已经有效的工作流程。

这种文化推动得到了顶层激励的强化：员工在半年度绩效评估中根据他们的”AI反射性”进行评估——遇到问题时他们多快转向AI。

6. 为AI启用建立明确的所有权

在Shopify，一个小型内部团队构建AI基础设施，让工程师能够安全和廉价地实验。“我们有一个ML基础设施团队，“Farhan说。“这是一个小团队——我敢肯定有六个工程师，“Farhan说。他们的工作不是告诉团队如何使用AI；而是消除摩擦。

该团队维护LLM代理，监控模型性能，并确保工程师可以访问AI工具而不会出现延迟或可靠性问题。“他们一直在寻找减少工程师辛劳和创造更多启用的机会，“Farhan解释说。“他们不断问，‘我如何减少延迟？我如何减少摩擦？我如何确保人们不被阻塞？‘“

第3部分：追踪AI影响

7. 不要将输出与生产力混淆

衡量工程生产力一直 notoriously 困难——AI只放大了挑战。当AI工具可以快速生成大量代码时，代码行数或拉取请求等传统指标变得更加没有意义。更多的输出不一定意味着更多的进步。

“从来没有一个很好的指标来确定工程师是否有生产力，“Farhan承认。他提供了一个他自己团队的例子：一个实习生曾经删除了六行代码，最终为Shopify每年节省了60万美元的基础设施成本。按照任何有意义的定义，这都是一个非常有生产力的改变。但按照传统指标，它几乎不会引起注意。“用自动化工具很难识别这种影响，“他说。

在Farhan看来，优秀工程的目标从来都不是最大化产生的代码量。事实上，情况往往相反。他引用了配对编程社区中一个著名的笑话：当有人问配对编程是否会导致工程师编写一半的代码时，回答是他们实际上会写得更少。

同样的原则适用于AI辅助世界。AI系统可以快速生成大量代码，但更多的代码不一定是更好的代码。“代码现在很便宜，“Farhan说。“但我不要代码，我要解决方案。“理想情况下，他补充说，AI可以帮助工程师产生”小巧、优雅、更短的代码”，而不仅仅是更多的代码。