在移动的 AI 前沿上做产品：用实验室机制驾驭技术变革 | Every CEO Dan Shipper

简要描述Brief Description

Every 联合创始人兼首席执行官 Dan Shipper 解释了如何在 AI 前沿不断从脚下变动的情况下构建产品——他将其称为“技术革命期间，按部就班的商业运作所产生的不合理低效”。他的观点是：执行路线图与探索前沿是两种从根本上相互对立的工作方式，因此产品组织应当加入研究实验室的要素——由“两个切片”规模的小型海盗团队和架构师团队并行开展实验，并对其构建的成果进行内部试用。他详细介绍了实验室为何重要、如何运营实验室，以及如何通过研究管线将胜出者推进到主产品中，并以 Every 尝试自动化其主编的文案修改工作，以及 Anthropic Labs（Claude Code）和 OpenAI（Codex）为例加以说明。Dan Shipper, co-founder and CEO of Every, explains how to build products when the AI frontier keeps shifting beneath your feet — what he calls "the unreasonable ineffectiveness of business as usual during technology revolutions." His argument: executing a roadmap and exploring the frontier are fundamentally opposed ways of working, so product organizations should add research-lab elements — tiny "two-slice" teams of pirates and architects running parallel experiments and dogfooding what they build. He walks through why labs matter, how to run one, and how to push winners through a research pipeline into the main product, illustrated by Every's effort to automate its editor-in-chief's copy edits and by Anthropic Labs (Claude Code) and OpenAI (Codex).

目录Table of Contents

• 世界刚刚改变——现在怎么办？
  The World Just Changed — Now What?
• 核心问题：探索与执行
  The Core Problem: Exploring vs. Executing
• 为什么要创建实验室？
  Why Make a Lab?
• 如何运行实验室
  How to Run a Lab
• 研究流程
  The Research Pipeline
• 案例研究：自动化 Every 的文案编辑
  Case Study: Automating Every's Copy Editing
• 让流水线持续运转
  Keeping the Pipeline Moving
• 将获胜方案合并到主产品中
  Merging Winners into the Main Product
• 结语：迎接下一个模型发布
  Closing: Welcoming the Next Model Drop

世界刚刚发生了变化——接下来呢？The World Just Changed — Now What?

我想谈谈如何在不断演进的前沿领域打造产品——或者用我喜欢的说法，探讨技术革命期间按惯例开展业务为何会变得不合时宜，以及该如何应对。I want to talk about how to build products on a moving frontier — or, as I like to call it, the unreasonable ineffectiveness of business as usual during technology revolutions, and what to do about it.

世界刚刚发生了变化。世界又一次发生了变化。Fable 5.1 上周发布了。Astra 6 也在上周发布了。这些模型的表现确实令人印象深刻。我只用一条提示词，就制作出了一个历史准确的滑铁卢战役 3D 复原作品——它整整运算了四个小时，然后我得到了这个结果。太疯狂了。The world just changed. The world just changed again. Fable 5.1 launched last week. Astra 6 launched last week. And these are seriously impressive models. I made a 3D historical reproduction of the Battle of Waterloo that's historically accurate with a single prompt — it just churned for four hours, and then I got that. That's crazy.

我们团队的另一位成员制作了一个智能体模拟：他给它输入了一篇关于智能体如何互动以及如何共同进行模拟的科学论文，然后只用了几个提示，就让一千个智能体全部在他的电脑上运行并进行可视化。它现在也开始处理我们的视频剪辑了。我们制作很多视频，而 Astra 的能力确实已经足够进入 Premiere 并完成大量剪辑工作。有趣的是：这份演示文稿中的所有动画，以及其中很大一部分内容，都是由 Astra 制作的——我完全没有碰过动画选项卡。Someone else on my team made an agent simulation: he fed it a scientific paper about how agents interact and get simulated together, and then had a thousand agents all running on his computer and visualized, after just a couple of prompts. It's also starting to do our video editing. We do a lot of videos, and Astra is actually good enough to go into Premiere and do a bunch of editing. And fun fact: all of the animations in this deck, and a lot of the deck itself, were made by Astra — I didn't touch the animate tab at all.

所以这简直太疯狂了。你该怎么办？如果你是一名带领产品团队的产品负责人，你是该埋头苦干、专注于当前工作吗？这也许在一段时间内会奏效。你是该问问客户想要什么吗？也许吧，但你的大多数客户并不熟悉这些东西——他们其实正指望你告诉他们该怎么做。你是该把你的 B2B SaaS 应用变成一款 3D 多人策略游戏吗？也许吧。也许。但这很难。这是房间里每个人都面临的一个大问题。我也面临着这个问题。So this is crazy. What should you do? If you're a product leader with a product team, do you keep your head down and focus? That might work for a little while. Do you ask your customers what they want? Maybe, but most of your customers are not familiar with this stuff — they're actually looking to you to tell them what to do. Do you turn your B2B SaaS app into a 3D multiplayer strategy game? Maybe. Maybe. But it's hard. This is a big problem that everyone in this room faces. I face it.

首先要知道的——第一条规则——就是：在参加冥想静修、经历迷幻体验，或第一次接触前沿模型后的30天内，绝不要做任何重大的人生决定。好了，我们达成共识了。这就是第一条规则。The first thing to know — rule number one — is never make any major life decisions within 30 days of a meditation retreat, a psychedelic experience, or your first encounter with a frontier model. All right, we're settled. That's rule number one.

核心问题：探索与执行The Core Problem: Exploring vs. Executing

让我们深入探讨这个问题。为什么这件事如此困难？如果你在负责一个产品团队，就会感觉仿佛每个人都既要高质量地执行产品路线图，又要同时保持在行业前沿。这确实非常困难，因为这两种工作方式截然相反。Let's get into the problem. Why is this so hard? If you're running a product team, it feels like it's everyone's job to execute the roadmap at a high level and to stay at the frontier at the same time. That's really hard, because these are very opposed ways of working.

如果你想探索前沿领域，你所做的就是探索——这属于发散。你会尝试许多不同的事情，可能会放弃其中很大一部分，会试用所有新模型，还会做演示。利用则完全不同。你在收敛，在聚焦，在对一些事情说“不”，按照预先制定的路线图执行。同时做这两件事，意味着你在朝着相反的方向拉扯。If you want to explore the frontier, you're exploring — that's divergent. You're doing lots of different things, you're probably going to throw a lot of it out, you're trying all the new models, you're doing demos. Exploiting is very different. You're converging, you're focusing, you're saying no to things, you're executing against a roadmap you've planned out. Doing both of those at once means you're pulling in opposite directions.

那么我们应该怎么做？我的观点是，你应该像运营研究实验室一样运营你的产品组织，或者在其中加入一些研究实验室的要素。接下来我们将讨论为什么你应该建立一个实验室、如何运营实验室，以及如何把实验室中有效的做法带回你的核心产品团队——我们会以 Every 的实践以及一些顶尖 AI 公司的案例为例。So what should we do? My contention is that you should run your product org like a research lab, or add some research-lab elements to it. We're going to go through why you should make a lab, how to run a lab, and how to bring what works from the lab back into your main product — using examples from what we do at Every and from some of the best companies in AI.

为什么要创建实验室？Why Make a Lab?

现在，你们组织中的每个人都在同时进行执行和探索。但我敢保证，你们组织中有些人的探索程度远超其他人。识别出他们非常重要，因为他们就是你们的早期采用者。我们就是你们的早期采用者：我们喜欢新事物，已经在周末使用 Astra 和 Fable 做个人项目，或探索可能带到工作中的东西。正因如此，我们会非常清楚你们的产品可能发展成什么样，因为我们已经生活在未来。问题在于，我们可能会造成巨大的干扰。Right now, everyone in your org is doing both execution and exploration. But there are some people in your org — I guarantee it — who are doing way more exploring than others. It's really important to identify them, because they are your early adopters. We are your early adopters: we love new things, and we're already running Astra and Fable on the weekends for personal projects, or to explore things we might bring to work. Because of that, we'll have a really good sense of what your product might become, because we're already living in the future. The problem is that we can be a massive distraction.

所以，关键问题是：如果你在运营一个产品团队，如何利用团队中的早期采用者——甚至是客户中的一些早期采用者——同时又不分散其他所有人的注意力？So the key question, if you're running a product org, is: how do I harness the early adopters on my team — maybe even some of my customers who are early adopters — without distracting everybody else?

我们在 Every 找到的解决方案，也是许多真正优秀的公司开始采用的做法，就是组建一个实验室团队。有了实验室团队，你就能分离不同的职责。一些人负责改进和扩展已经奏效的东西——他们属于产品团队。另一些人负责探索接下来会是什么：探索前沿领域、制作演示、尝试新的模型。这样一来，你就能兼得两者之长。The solution we've found at Every, and that a lot of really great companies are starting to adopt, is to make a labs team. With a labs team you've separated concerns. Some people are in charge of improving and scaling what already works — they're on the product team. Some people are in charge of exploring what comes next: exploring the frontier, doing demos, trying new models. That lets you get the best of both worlds.

如果你看到这里，心想：“这真的太贵了，我没有这样的资源”，那么 AI 的神奇之处在于，它让你可以拥有一支只有一个人的实验室团队。你可以安排团队中的一个人，专门负责在新模型发布时立即去探索它，然后回来告诉你他们学到了什么。这并不需要很多资源，因为现在团队中的每个人都拥有如此多的超能力——他们只需让 Astra 和 Fable 完成一大堆工作——所以并不需要巨额投入。And if you're looking at this thinking, "That's really expensive, and I don't have the resources for it" — what's amazing about AI is that it allows you to have a labs team of one. You can have one person on your team whose job it is, right when a new model comes out, to go explore it and come back and tell you what they learned. It doesn't require a lot of resources, because everyone on your team now has so many superpowers — they can just have Astra and Fable do a bunch of stuff — that it doesn't take a huge investment.

要把两者的区别说清楚：在实验室团队中，你的工作是探索各种能力——尤其是在新模型发布时——看看现在能做到什么，并行开展大量实验。关键在于，两者的预期非常不同。在实验室团队中，你应该预期放弃自己所做成果的约 90%：试试看，然后丢掉。产品团队则完全不同：你的工作是改进并扩展产品，为现有客户交付成果，并确保他们觉得自己理解这个产品——产品是连贯的，而不是把一堆垃圾直接扔给他们。产品团队应该预期采用实验室团队所做或尝试内容的大约 10%，这就是两者开始协同工作的方式。To pull the difference apart: on a labs team, your job is to explore capabilities — especially when new models drop — to see what's now possible, and to run a ton of experiments in parallel. Crucially, the expectations are very different. On a labs team you expect to dispose of about 90% of what you make: you try it and you throw it away. A product team is very different: your job is to improve and scale the product, deliver for existing customers, and make sure they feel like they understand the product — it's coherent, and you're not just throwing a bunch of garbage at them. A product team should expect to adopt about 10% of what the labs team makes or tries, and that's how the two start to work together.

AI 领域已经有一些非常好的例子，说明这种方式开始奏效了。我们长期以来一直都有实验室团队，但得益于这项技术，它开始以一种前所未有的方式发挥作用。Anthropic Labs 就是一个很好的例子。Claude Code——有史以来规模最大、最成功的生产力产品之一——就诞生于 Anthropic Labs，这是一个负责开展大量实验的独立小团队。MCPs、Skills、Claude Design——这些都源自 Anthropic 内部一个小团队的不断尝试，随后 Anthropic 对那些胜出的、真正有效的项目持续加大投入。而你从未见过的实验，还有上千个。There are really good examples of this starting to work in AI. We've had labs teams for a long time, but it's starting to work in a way it never has before because of this technology. A great example is Anthropic Labs. Claude Code — one of the biggest, most successful productivity products of all time — came out of Anthropic Labs, a separate little group in charge of doing lots of experiments. MCPs, Skills, Claude Design — all of these came from a small group of people inside Anthropic experimenting, and then Anthropic investing more and more into the winners, the ones that worked. And there are a thousand experiments you've never seen.

如何运行实验室How to Run a Lab

假设你确信这种结构兼顾了两方面的优势——既能释放早期采用者的潜力，又不会分散那些需要按路线图交付产品的团队成员的注意力。如何才能有效运营一个实验室？Say you're convinced this structure gets the best of both worlds — it unleashes your early adopters without distracting the people on the product team who need to deliver on the roadmap. How do you run a lab well?

使用非常、非常小的团队。很长一段时间以来，团队规模的标准都是“两张披萨团队”——按照杰夫·贝佐斯的说法，即八到十个人。在人工智能时代，我称之为“两片披萨团队”：最多一两个人。由一两个人组成的团队可以如此迅速地取得如此大的进展，以至于再增加人手只会带来协调成本和不同的愿景，最终根本行不通。Use very, very small teams. For a long time the standard for team size was the two-pizza team — eight to ten people, per Jeff Bezos. In the AI age, I call it a two-slice team: one or two people max. You can get so far so fast with one or two people that anything more brings coordination overhead and differing visions, and it just doesn't work.

这种对我们有效——我认为也开始对其他人有效——的组合，我称之为“海盗与建筑师”。团队中有一个人是海盗：一门完全痴迷于寻找价值的“粗制滥造大炮”。那就是我——我会在外面做大量、各种各样的事情，把它们全都丢掉；这一切都很混乱，但我终将找到真正有趣的东西。建筑师则是这样的人：他们审视一个混乱的系统——也许是我构建的、彻底乱成一团的东西——并帮助将其塑造成有价值、美观且可扩展的事物。在人工智能领域，将这两类人组合在一起非常、非常强大。The composition that works for us — and that I think is starting to work for others — I call pirates and architects. One person on the team is the pirate: a slop cannon absolutely obsessed with finding value. That's me — I'm out there doing lots and lots of stuff, throwing it away, all of it messy, but I'm going to find something really interesting. Architects are people who look at a messy system — maybe something I built that's a complete mess — and help shape it into something valuable, beautiful, and extensible. Pairing those types together is very, very powerful in AI.

内部试用。对实验室团队来说，最重要的事情就是让“做出某样东西”和“知道它是否好用”之间的反馈回路尽可能紧密。最紧密的反馈回路，就是为自己做东西。如果能做到这一点，就去做。如果做不到，那么找几个很早期、属于早期采用者类型的客户来帮你测试非常重要，这样才能建立紧密的反馈回路，快速迭代。还要使用你正在构建的东西：理想情况下，每个实验都应该用于你手头实际存在的工作，这样你才能判断它到底有用，还是只是新奇——这是一个必须分清的重大区别。Dogfood. The biggest thing that matters on a labs team is making the feedback loop as tight as possible between making something and knowing if it's good. The tightest feedback loop is making something for yourself. If you can do that, do it. If you can't, it's really important to get a couple of early, early-adopter-type customers to help you test with a tight feedback loop so you can iterate really fast. And use what you're building: ideally every experiment should be used for actual work you actually have, so you can tell whether it's useful or just new — that's a big distinction you need to draw.

并行开展大量实验，即使这些实验试图做同一件事。针对问题尝试相互竞争的方法。这样看起来可能会很混乱，仿佛缺乏连贯性，但每个人对如何解决特定问题都会有略微不同的看法。当能力发生变化时，前沿领域会变得非常未知，而让人们从不同角度尝试同一件事，有助于你描绘这条前沿，并判断什么有价值、什么没有价值。Build many experiments in parallel, even if those experiments are trying to do the same thing. Try competing approaches to the problem. It might look like a mess, like a lack of coherence, but everybody will have a slightly different take on how to solve a particular problem. When capabilities move, the frontier becomes very unknown, and having people try the same thing from different perspectives helps you map that frontier and decide what's valuable and what's not.

让你的实验在投资回报率（ROI）方面实现净正收益。我们会丢弃所做成果的 90%——那么，如何让这 90%（也就是最终永远不会进入产品的那部分）真正发挥作用呢？在 Every，我们经常采用、且效果非常好的一种做法，就是把实验转化为对外内容。人们喜欢看到我们尝试过的一切、哪些奏效了、哪些没有奏效——这会吸引客户来阅读我们的内容并使用我们的产品。如果条件允许，我强烈推荐这样做。另一种选择是利用实验为早期采用者计划提供支持：很多客户希望与你们更接近，希望成为其中的一员，而这可以成为一项增值服务，让他们能与你们开展更密切的合作。从根本上说，实验室团队应该将他们对产品能力以及产品如今能够实现的功能的了解分享给产品团队，这样产品团队在构建产品时就能将这些因素纳入考虑，而不必分心亲自探索前沿。Make your experiments net-positive in terms of ROI. We're going to throw out 90% of what we make — so how do we make even that 90%, the part that never makes it into the product, actually useful? One thing we've done a lot at Every that's worked really well is turning experiments into external content. People love to see everything we tried, what worked, and what didn't — and that brings customers to read our stuff and use our products. If that's possible, I highly recommend it. Another option is to use experiments to feed an early-adopter program: a lot of your customers want to be closer, want to be in the fold, and this can be a value-add that lets them work with you more closely. And at base, the labs team should be sharing what they learn about capabilities and what's now possible with the product team, so the product team can take that into account as they build — without getting distracted by having to explore the frontier themselves.

研究流程The Research Pipeline

所以，你已经建立了一个实验室，并开始摸索最佳实践。如何将你在实验室中打造的成果转化到产品中？你需要的是一条研究流水线：想法从左侧的仅限实验室阶段开始，经过大量小型实验，然后逐步从左向右推进。到了某个阶段，你会与产品团队进行交接，由他们开始将这些成果整合进产品中。So you've made a lab and started to figure out the best practices. How do you get what you're making from the lab into your product? The thing you need is a research pipeline: ideas start on the left as lab-only, with lots of little experiments, and you move them progressively from left to right. At some point you have a handoff with your product team, where they start to get incorporated into the product.

事情大概是这样的。实验室团队会开展大量、非常大量的实验。其中大多数都不理想，但少数实验可能会成功，而这些就会成为你开始在实际工作中测试的东西。我们在内部经常做的一件事，就是让团队中的其他人采用这些成果，看看他们是否喜欢。根据你服务的客户类型不同，可能会有不同的配置方式，但对我们来说，第一步始终是：团队中的其他人是否开始使用它？如果是这样，它通常就已经准备好提供给早期客户试用，也准备好让产品团队认真评估——确定它在我们的产品路线图中适合什么位置，以及我们可以如何使用它。即便到了这一步，也不是所有东西都能继续推进。但在某个阶段，你正在构建的东西终将准备好进行规模化，并发布给客户。Here's what it looks like. The labs team runs lots and lots of experiments. Most of them are not good, but a few might work, and those become things you start to test in real work. One thing we do all the time internally is just let other people on the team adopt them and see if they like it. There are different configurations that work depending on what kind of customers you serve, but the first step for us is always: do other people on the team start to use it? If so, it's often ready to put in front of early customers, and ready for the product team to really take a look at — to figure out where it fits in our roadmap and how we might use it. Even there, not everything makes it. But at some point, the thing you're building will be ready to scale and release to customers.

案例研究：自动化 Every 的文案编辑工作Case Study: Automating Every's Copy Editing

举个具体的例子。Kate 是我们的主编，过去三年来，我一直在努力——非常用心地——将她的工作自动化。Kate 在很多方面都非常出色，但她真正擅长的一件事，是对文案编辑有很高的品味。随着团队不断壮大——我们现在大约有 30 个人——她不可能亲自完成所有文案编辑工作。我们可以雇人，但要找到一个拥有她那样的品味、并且能够培养起来的人，真的非常困难。所以，我一直在努力想办法让 AI 帮助她，这样她就能扩大自己在组织中的影响力，而不必额外花时间在深夜进行文案编辑。Here's a concrete example. Kate is our editor-in-chief, who I've been trying to automate — very lovingly — for the last three years. Kate is fantastic at a lot of things, but one thing she's really good at is taste for copy edits. As the team has grown — we're about 30 people now — she can't do all the copy edits herself. We could hire someone, but it's really hard to find someone with her level of taste and train them. So what I've been trying to figure out is how to make AI help her, so she can expand her impact in the org without spending additional time doing copy edits late at night.

凯特经常一觉醒来，就会看到我发给她这样的消息：“不是什么重要的事，不过我把你过去三年里的每一份文字编辑稿都下载下来了，还让 Fable 试着对最新的一篇做了一次文字编辑。”我确实已经做了几年类似的事情，只是最近才开始奏效——这些能力终于足够好了，已经可以让凯特真正用起来。我们称之为 Kate Bench：我们做过一系列实验，其中一个开始奏效了，于是现在我们把它推入整个组织，供内部使用。Kate often wakes up to messages from me like: "Not important, but I downloaded every single one of your copy edits over the last three years and had Fable try to do a copy edit on the latest piece." I've literally been doing stuff like this for a couple of years, and it just started to work — the capabilities are finally good enough that it's ready for Kate to actually use. We call it Kate Bench: we'd done a bunch of experiments, one was starting to work, and now we pushed it into the org to get some internal use.

我们有一个 Every agent——一个面向整个公司的单一代理，帮助公司采用所有 AI 工作流，网址是 agents.every.to——我们也在内部使用它。现在，Kate 可以说：“在 Every，为这份草稿做一次 Kate 式审阅”，它就真的会像她一样，根据她以往的修改记录提出修改建议，而且会随着时间的推移不断改进。这是我利用业余时间构建的，结果它就这么自然而然地运行起来了。现在我们开始看到它对组织的价值，因为她正在采用它，而且它还在向其他人扩散——这是一个非常好的迹象。We have an Every agent — a single agent for your entire company that helps your company adopt all of its AI workflows, at agents.every.to — and we use it internally. Now Kate can say, "At Every, do a Kate pass of this draft," and it will literally file suggested changes like she would, based on her historical edits, and improve over time. I built this in my spare time and it just sort of works. Now we're starting to see that there's value for the organization, because she's adopting it and it's spreading to other people — that's a really good sign.

当我们进入这个内部使用阶段时，就是该请架构师介入的时候了——我的团队里正好有一位这样的架构师，Yannik，他非常出色。Yannik 会把那个杂乱但勉强能运行的东西，打磨成真正出色的系统。现在我们已经有了一个完整的仪表板：针对每份文档，我们都能看到有多少条建议被采纳，以及智能体完成一轮处理后，Kate 还剩多少工作要做——它会检查智能体介入后她所做的修改。你可以看到我们正在取得进步：在这类编辑工作上，她比上个月少做了 12% 的工作。他的职责是把它变成一个真正的系统，让我们能够持续改进，并在此基础上不断积累。现在，它已经开始运行得足够好了，我们正在考虑如何把它提供给早期客户——以及这一流程是否适用于文案编辑以外的工作。我认为是适用的。我们已经把它从“只能在实验室里进行的实验”，发展成了准备交付给客户的东西。When we get to this internal-use stage, that's the time to bring in an architect — I have one in particular on my team, Yannik, who's fantastic. Yannik takes the messy thing that kind of works and makes it really great. Now we have a whole dashboard: for each document, how many suggestions were accepted, and how much work remains for Kate after the agent does its pass — it checks the edits she makes after the agent has gone in. And you can see we're improving: she does 12% less work on these types of edits than she did the month before. His job is to make it a real system we can improve and compound on an ongoing basis. Now it's starting to work well enough that we're thinking about how to put it in front of early customers — and whether this process works for things beyond copy editing. I think it does. We've taken it from "only an experiment in the lab" to something we're ready to give to customers.

保持流水线运转Keeping the Pipeline Moving

持续将各项内容推进通过实验室流水线的一些最佳实践。A few best practices for continually pushing things through your lab pipeline.

定期审查流程。我在 Notion 中有一个跟踪表，每周的全员会议上，大家都会讨论流程中正在发生的事情。这一点至关重要。你希望产品团队的其他成员——那些没有亲自参与所有试验的人——了解我们认为有趣的方向，以及哪些项目开始在流程中逐渐上升，这样一旦事实证明它确实可行，他们就可以开始思考这对产品意味着什么，而不必临时忙着开展自己的实验。这样能让实验室和产品团队保持同步。Review the pipeline regularly. I have a tracker in Notion, and every week at our all-hands, everyone talks about what's going on in the pipeline. That's crucially important. You want the rest of the product team — the people who aren't playing around with everything — to know what we think is interesting and what's starting to move up the pipeline, so they can start thinking about the implications for the product if it actually proves out, instead of having to scramble to run their own experiments. It keeps the lab and the product orgs in sync.

为推动一个想法在流程中逐步前进，制定明确的决策标准，并在做出决策时真正把它作为一个重要事件来对待。我们的标准包括：最重要的一点是，人们是否在使用它，以及是否会再次回来使用？你要做的是把内部使用情况作为价值的替代指标。第二个重要问题是，它是否比现有方案好十倍？这是一个非常有意思的筛选标准，因为新事物会让人感觉非常令人兴奋——但一个月后，它真的更好吗？除非把时间以及一段时间内的使用情况作为筛选依据，否则很难知道。还有一点：它是否负担得起？也许它现在能运行，但我们是否真的能够以规模化的方式为客户提供服务？这也是一个非常重要的问题。拥有明确的标准，可以确保你在做这件事时保持严谨。Define clear decision criteria for moving an idea through the pipeline, and really make it an event when you do. Some of our criteria: the big one is, are people using it, and are they coming back? What you're trying to do is use internal use as a proxy for value. The second big question is, is it 10x better than what currently exists? That's a really interesting filter, because what is new feels very exciting — but a month later, is it actually any better? It's hard to know unless you use time and usage over time as a filter. And also: is it affordable? Maybe it works now, but could we actually serve it at scale for our customers? That's another really big question. Having clear criteria lets you make sure you're being rigorous about how you do this.

将胜出方案合并到主产品中Merging Winners into the Main Product

最终目标是将胜出者合并到主产品中。这一完整周期——从实验室到合并胜出者——现在开始运转得非常、非常顺利。我们设立实验室已经很长时间了，而自我颠覆的理念——打造某种产品，随后颠覆你自己的产品——也存在一段时间了。但如今它实际上开始在 AI 领域发挥作用了，因为你可以推进得如此之快。The ultimate goal is to merge the winners into the main product. This full cycle — labs to merging winners — is something that's starting to happen really, really well. We've had labs for a long time, and the idea of self-disruption — building something that then disrupts your own product — has been around for a while. But it's actually starting to work now in AI, because you can move so fast.

一个非常好的例子就是 Codex。Codex 是由一个在主应用之外工作的精干团队构建的。与此同时，OpenAI 内部还有许多不同的团队也在探索编程的未来，并针对编程未来的不同形态进行迭代：它会集成在 IDE 中吗？会是一个 CLI 吗？他们在 2026 年 2 月推出了桌面应用，我认为这款应用非常出色；它的增长速度如此之快，以至于他们最终直接将其并入 ChatGPT——它成了 ChatGPT 的基础。随后，这个小小的 Codex 团队接管了这款拥有每日 8 亿活跃用户的应用，因为他们通过这种实验方式取得了巨大的成功。A really good example is Codex. Codex was built by a small team working outside of the main app. There were a bunch of different teams inside OpenAI working on the future of coding at the same time as Codex was, doing iterations on different form factors for what the future of coding would look like: Is it inside an IDE? Is it a CLI? They launched the desktop app, which I think is fantastic, in February 2026, and it grew so fast that they eventually just merged it into ChatGPT — it became the foundation of ChatGPT. The small little Codex team then took over this 800-million-daily-active-user app, because they were so successful with this way of experimenting.

结语：迎接下一次模型发布Closing: Welcoming the Next Model Drop

我认为，这正是做这类事情的意义所在：你实际上可以在扩展现有产品的同时，构建产品的下一版本，而且不必因此陷入疯狂。判断它是否奏效的方法是：当新模型发布时，你会欣然迎接并为之兴奋，而不是感到忧惧。I think that's the promise of doing something like this: you can actually build the next version of your product while scaling the one you already have — and you can do it without going crazy. The way you know it's working is that you will welcome the moments when new models drop and be excited about them, instead of dreading them.

我的演讲到此结束。我是 Dan Shipper，Every 的联合创始人兼 CEO。你应该去了解一下 Every——这是你保持在 AI 前沿所需的唯一订阅服务。非常感谢。And that's my talk. I'm Dan Shipper, co-founder and CEO of Every. You should check out Every — the only subscription you need to stay at the edge of AI. Thank you very much.