Factory's Matan Grinberg: The Coming ‘Dark Factory’ Where Software Builds Itself

Bezos 在 Amazon 讲的是 customer obsession（客户至上式执着）。但在我们看来，那是一个输入指标。你其实不该去衡量输入指标。你是否“痴迷客户”并不重要。比如说，你完全可能很痴迷客户，结果他们因为不喜欢你的做法，反而去申请 restraining order（限制令）来阻止你。

我们的工作，是把东西做得足够好，好到让客户自己对我们产生执着。这才是我们的工作。就像，打个比方，如果你是一个篮球队教练，你不会在球员上场前对他们说，嘿，伙计们，记得多出汗。就像，啊？

不，重点不是这个。重点是得分。我们得得分。而在这个过程中，是的，你大概率会出汗。我觉得类似地，要创造出对你高度着迷的客户，你自己大概也需要非常执着地关注客户，但真正重要的是输出结果。

我们现在在录音棚，和来自 Factory 的 Matane 一起。这是我们第二次

和 Matane 一起。感谢邀请我来。

进入这个规模很小但很精英的“第二次参加 training data 节目嘉宾”群体。所以，谢谢。

哦，对。

Matane 是 Factory 的 cofounder 和 CEO，Factory 做的是 droids，也就是面向软件开发这门技艺的 autonomous agents（自主 agent）。对，没错。Matane，我们直接切入正题吧，因为我觉得你们在软件开发这个世界里有点像一匹 dark horse（黑马）。这绝对是一个已经彻底爆发的市场。

像 Cloud Code、Cognition 以及其他一些团队，目前确实占有领先优势，但你们的势头也非常强。谈谈这里面的竞争态势，以及 Factory 的特别之处是什么。

这一路可以说非常疯狂。我们是在大约三年半前创办 Factory 的。也就是说，到了 2023 年 4 月，整个世界，尤其是企业界，连 GitHub Copilot 都还只是勉强准备好接受，更不用说完全自主的 agent（智能体）了。所以，我觉得最初那两年，某种程度上就像我们“在沙漠中的旅程”——我喜欢这么形容——因为我们专注于完全自主的 agent，但工程师们还没准备好，企业里的采购团队也没准备好。

所以回过头看，我认为我们确实打磨了自己的能力，也学到了很多关于如何为企业中的开发者构建产品的经验。不过，说到底，还是花了很长时间，才等到他们真正准备好接受这类东西。所以我们现在算是开始更明显地走出来了。像 Anthropic 或 OpenAI 这样的其他参与者，拥有非常强大的分发能力，正在进入这个市场，并带来像 Cloud Code 或 Codex 这样的惊人工具。而企业真正关心的一点——这是我们在那两年里学到的——是他们不希望任何一方成为自己的单点故障。

他们不想让任何人掌控自己的命运。所以，真正重要的一点是 model independence（模型独立性）。大家都从 cloud（云计算）时代吸取了教训：那时候 AWS 或 Azure 会说，嘿，快来吧，签个三年合同，会非常便宜。

我们会给补贴，一切都会很棒。然后几年之后，等到续约的时候，他们就会把合同价格直接提高到 10 倍。

Dave Gravity。现在我们套牢你了。

对，我们拿住你了。怎么，你还打算花两年时间迁移到别人那里去吗？根本不可能。

现在每个人身上都有这种伤疤。所以大家都明白，Claude Code 很棒，OpenAI 的 Codex 也很棒。但我们不能把自己的命运交到任何一家 model provider（模型提供商）手里。另外，你只要看看这些 model lab（模型实验室）和 cloud provider（云服务提供商）的风险画像就知道了。

最近一次从某家 cloud provider 和 model labs 之间闹出来的风波是什么？感觉好像总是会有某种混乱，比如内部争斗、和政府起冲突，或者和其他什么机构发生摩擦。所以，如果你要把这个非常重要的业务环节搭建起来，你就会想确保它能经受住这些变化。这也是我们在最初那两年里学到的一点：developers 真的很在意 modular（模块化）。他们想知道自己可以按需求去定制。

他们还想知道，如果有新 model 出来，更快、更便宜或者性能更强，他们可以直接把它 hot swap（热切换）进去。我觉得，这也是为什么很多大型企业会把他们从 Codex 或 Cloud Code 上积累起来的势头延续到 factory：他们既能获得这些优秀 models 带来的性能，又不用承受直接绑定 model labs 所带来的 vendor lock-in（供应商锁定）。

但如果我是企业客户，我会说，等一下，那我现在是不是又被锁进 factory 里了？这个问题怎么回答？

这个问题特别好，因为你确实可能会这么想：好吧，等等，我们是不是只是把锁定的终点换了个地方。我们构建的所有 modularity（模块化能力）都意味着，如果未来某个时候你想说，嘿，你知道吗？Factory 已经不再处于最前沿了。无论是你构建的 automations（自动化流程），还是我们帮助你建立的 skills registry，这些工作成果都会留在你的 code base 里。而且我们创建的任何 automations，它们的 artifacts（产物）也都存在你的 code base 里。

换句话说，并不存在这种情况：比如关于你们 org 的某些 tribal knowledge（部落式经验知识）被我们留在自己这边，不交给你。这也是我们和客户关系中的一部分：我们同样希望确保自己提供的是尽可能好的体验。如果我们帮你在不同 models 之间做权衡以实现 cost optimization（成本优化），那这个优化结果是交给你的，我们不会再把它拿走。我认为，这是我们和这些企业建立信任中非常重要的一部分。

你和我大概是几个月前聊过一次，当时我想称赞你，说你在两三年前就对这个市场有了正确的判断。而你的回应大概是：谢谢，但早了两三年，和看错了其实没区别。对。 我觉得这句回答在很多层面上都非常精彩。你能不能讲讲那种“在沙漠里的两年”是什么感觉？当你拥有一个后来被证明是对的愿景，但在一两年里却没有人认可，它是什么感受？

你能不能谈谈这段历程，以及它对你们公司 DNA 产生了什么影响？

对，我的意思是，在那个当下，这真的、真的非常困难，因为我以前从来没有上过班。我是从 PhD 退学出来创办这家公司的。而且在那两年里，我说服了 20 个我见过最聪明的人，放下他们原本在做的事情，加入 factory，和我们一起投入这项使命。而这些人很多都是有家庭的。

这些人很多都有孩子，差不多是把自己人生中的好几年都投入到这个问题上，一个客户接一个客户地去推进；但他们当时还没准备好接受 agent。他们不理解。还有一个原因是，模型那时的表现也没那么强，但我觉得很大一部分其实是行为层面的。再讲个有趣的小 anecdote（轶事）：如果你给开发者做 NPS survey，他们基本不会喜欢你拿来让他们打分的那个东西。

因为开发者会用脚投票。他们喜欢什么、不喜欢什么，态度都非常明确。要是你还在想“他们到底喜不喜欢呢”，那答案基本就是：他们肯定不喜欢。不过在那段时间里，我觉得我们也学到了很多。我自己也有很多事情是在摸索中学的——毕竟我之前从来没有工作过。

Enterprise sales（企业销售）这种事，对一个 physicist（物理学家）来说并不天然容易上手。但说到底，这其实不重要。你不会因为起步早就得到什么额外加分，因为谁在乎呢？没有安慰奖。事情只有两种结果：要么你做成了，要么你没做成；真正重要的只有这一点。

对团队来说，那段时间也特别艰难。有一阵子我们确实变得很擅长 enterprise sales，但产品本身还是不够好。这会把你置于一个非常棘手的位置，因为最后我们做到的收入规模差不多接近 2,000,000，但产品并不好。后来有个时点我们意识到了这一点：如果你销售能力真的很强，你是可以把合同签下来的，这点完全做得到。

但如果你在这么做，而开发者又不喜欢你的产品，那这就像一颗滴答作响的定时炸弹，因为他们最终一定会 churn（流失），到时候局面会非常、非常糟。我们意识到这一点后，主动把所有这些客户的钱都退了回去。我记得那是最难做出的决定之一，因为不只是说团队里那二十来个人都拿到了各个 labs 给出的夸张 offer，他们有非常强的财务激励去别的地方；外面还有很多其他公司发展得很好，而他们还是选择留下来做这件事。结果我们却要说，哦对了，顺便一提，我们好不容易拿到的那一点收入，其实要退回去，因为我们觉得这个产品并没有让他们的开发者满意。

我们还曾经有过

你们为什么会做出那个决定？

我们当时是用一个很好的愿景去说服他们的，让他们相信这是一支值得合作的团队，也相信我们会为他们交付解决方案。但后来我们意识到，我们当初向他们承诺的方式，以及我们实际交付的产品，都没有达到应有的水准；而且在我看来，这不符合我们的一条 operating principle（运营原则）。我非常喜欢我们的一条 operating principle，就是：create obsessed customers。

对。

这有点像是把 Bezos 那套理念翻过来了。Bezos 在 Amazon 讲的是 customer obsession（客户至上式痴迷）。但在我们看来，那是一个输入指标。说到底，输入指标这种东西，你其实不该拿来衡量结果。你是不是痴迷客户并不重要。比如，你完全可能对客户过度痴迷，结果他们因为不喜欢你做事的方式，反而去申请限制令。

我们的工作，是把产品做得好到让客户自己对我们上瘾、变得痴迷。这才是我们的工作。这就像一个类比：如果你是篮球队教练，你不会在球员上场前跟他们说，嘿，伙计们，记得多出汗。什么？当然不是。

你得得分。我们需要得分。在这个过程中，是的，你大概率会出汗。我觉得同样地，要创造出痴迷我们的客户，你自己大概也必须非常痴迷客户，但真正重要的是输出结果。我想回到这一点：我们当时交付的产品，并没有创造出那种痴迷型客户。

而且我们想确认的是，这是一群我见过最聪明的人。我们当时正在接近那个目标。我们获得了很多直觉判断，很多事情在内部开始逐渐成形。我们在内部已经能看到，我们做事的方式正开始变得越来越 agent native（以 agent 为原生核心）。

那个产品算是在某种程度上挠到了痒处，但我们有点走在客户前面了。我们希望维护与客户之间的信任，这样等时机真正到来时，我们可以回去对他们说，嘿，伙计们，这次是真的。我保证。为了建立这种可信度，我们必须坦诚地说，嘿，你看，哪怕你们也许愿意继续用下去，我们还是要把这个退回给你们，并且说，三个月后，我觉得它就准备好了。给我们一点时间。

我保证，到时候一定会让你们惊艳。

当你和客户进行那番谈话时，他们是什么反应？

他们中有些人会说，哦，太好了，听起来不错。因为我觉得那并不是让他们特别痴迷的东西。有些人则有点困惑。但总体来说，尤其是 enterprises（企业客户），他们并不习惯这种做法。

很多时候，enterprise budget（企业预算）一旦花没了，也就没了，基本上没人真的会在意。

对。

所以他们当中有些人甚至都不知道自己有没有一种机制可以把钱收回来。但你也知道，这件事也很难开口告诉那些相信你的投资人。我记得当时和 Sean 聊过这件事。Sean 很显然一直和公司走得很近，所以他的想法和我们非常一致。但要突然去说，嘿，这其实还是挺吓人的。

顺便说一句，你还记得之前那些更新吧，你一直在说，嘿，你看，revenue（营收）在上涨。可它马上就要掉到零了。这真的是件很可怕的事。

我觉得那有点像一次 faith leap（信念上的冒险）：我们在内部很早就看到了某种信号，知道这才是我们必须前进的方向。我们需要调整产品的方法，算是做一次 pivot（战略转向）。但我记得那次 all hands（全员会），我们把这件事告诉整个团队时，天啊，那大概是我人生中最糟糕的一个月之一。我当时整个人都……因为不可能每个人都会直接说“这到底是什么？到底发生了什么？”

但更明显的是他们脸上的表情：脸色有点发白，然后像是在想，哦天哪，这会不会只是某种早期信号，说明我们马上就要——

——彻底沉下去了？你们是怎么在那种情况下把团队稳住的？

说实话，我觉得团队之所以能坚持在一起，唯一的原因是我们在早期招人时极其 ruthless（严格、毫不妥协）：我们找的都是那种真正、真正对使命非常着迷的人。我们的使命是把 autonomy（自主性）带到 software engineering（软件工程）里。大家必须真的非常在乎这件事。同时也要确保每个人都非常清楚 feedback loops（反馈闭环）：公司的命运掌握在我们自己手里。这不是那种“哦，这是某个人去做的事”，而是我们每个人都在让这件事成功这件事上扮演一部分角色。我还觉得，坦然接受那段时间真的很难熬，这一点本身也非常有价值。

就是要对这件事保持诚实。

你当时是非常坦诚的，会直接说，没错，这很糟。你再看看那些竞争对手，营收增长快得惊人。这情况不妙。我们当时的处境非常糟糕。

我们当时几乎不得不把所有营收都吐回去。我们真的必须好好整顿自己。事后回看，我觉得正是在那种时刻，最深的纽带才会真正形成。如果你去问那些运动员，或者学者之类的人，你会发现，每当你处在那种高压时期——不管是期末前突击复习，还是那种高强度的状态，我们团队里也有一些 rowers，我们总会拿这个来举例——那就是纯粹的痛苦。

纯粹痛苦的运动。

就是痛苦。真的就是这样：有一个数字可以量化你的表现，比如你划 2k 的时间，或者你在那项比赛里的成绩。但正是拥抱这种东西，才会建立起那种持久的纽带，让你在事后会觉得，我们知道跌到谷底是什么感觉。我们知道失败是什么感觉。

我们知道那是什么感觉。我的意思是，我们刚创办公司时，估值只有 5,000,000。如今很多竞争对手、很多公司，根本不知道“不是什么 unicorn（独角兽公司）”是什么感觉。对他们来说，这几乎是显而易见的——他们从第一天起就是那样。而我们经历过那些黑暗时刻，却没有一个人离开。

对，这让我们变得非常有韧性，也非常强大。所以，往后看，虽然现在情况已经好了很多，但未来一定还会有非常糟糕的时候。不过我们的 DNA 里已经有了这种韧性，我不确定其他一些公司是否也具备这一点。

我喜欢这一点。所以跟我们讲讲，到底是什么发生了变化。我也很好奇你前面那句评论：model（模型）变得更好，并不是最重要的事情。

因为至少在我看来，model（模型）的

变得更好是最重要的事情。你就帮我理解这一点。

对。所以有几件事。其一是，我们之前一直在构建的交互模式太激进了。就像你说的，我们瞄准的确实是 fully autonomous agents（全自主 agent），这一点没错；但它早了两年，于是就等于错了。而 fully autonomous agents 需要开发者彻底改变自己的行为方式。

而我们当时甚至是在开发者还没开始使用像 Copilot 这样的工具之前，就想把这套东西开箱即用地推出来。这步子迈得太大了，是一种阶跃式的巨大跳变。所以那是个重要的日子。09/26/2025 是我们第一次推出，基本上，就是 droid CLI 的时间。

而 droid CLI 以一种此前那些 fully autonomous agents 做不到的方式，贴近了开发者当下的工作状态。另外，它的性能也完全是 state of the art（业界最先进水平），而且它是 model agnostic（模型无关）的。所以它可以使用当时市面上的每一个模型。9 月 26 日也正好是我们最初启动这件事两年之后。所以那时整个世界已经更习惯使用像 auto complete（自动补全）这样的东西了。

到 2025 年底时，大多数工程师都已经在使用某种 auto complete tool（自动补全工具），而且很多人当时也开始通过类似 chat interface（聊天界面）的方式，让一个 agent 去大范围地直接修改代码，也就是更 agentic（更具 agent 特征）的交互方式。不过，我们现在看到的是，如果你回过头，在这种 agentic interaction（agent 式交互）里使用一些较老的模型，它们其实仍然很好用。所以变化最大的是开发者，尤其是企业里的开发者，他们开始更愿意接受这种新的工作方式。尤其是，开发者在过去三十年里已经建立起了自己的工作流。

他们可能很固执。很多人当时都会说，不，不，不，我这门手艺不可能交给什么 AI 工具来做。

所以很大一部分其实只是去理解该怎么和这些工具协作，并且愿意亲自进去试一试；同时还要有那种直觉，知道为了让它成功，你需要提供哪些 guardrails（护栏 / 约束）。

对。

所以我认为这是这两方面共同作用的结果。模型在变得更好，因此你在提供 guardrails 这件事上需要做得更少了。但与此同时，开发者也放下了戒备，开始觉得：好吧，你知道吗？让我去试着用这些东西做点事情。

它会去做一些我不喜欢的事。然后还有一点是，当 Andre Karpathy 发推谈到某件事时，突然每个工程师都会觉得，哦，行。你知道，也许这是真的。And Andre 开始发推讨论这种 agentic work。早期他对此并没有那么开放。

然后他变得更开放这件事，确实改变了一些人的想法，这很有意思，但行为变化本来就有一部分是这么发生的。比如，你会从你信任的人那里听到这件事。你也开始在组织内部看到，有些人可能会更 agent native，但这些因素加在一起，才是促成这种变化的原因。

现在我们都会上 Slack。我们

可能——我们可能已经在——我们可能正在逼近 Slack 的极限，我觉得这也会是另一件很有意思的事。很酷。不过，是的。

好。那是 2025 年 9 月，你们发布了 Droid CLI。你当时说过 Frontier Performance Soda。这对你来说是什么意思？

benchmark（基准测试）这类东西的半衰期很短。就像，任何一个好的 benchmark，基本都会在三到六个月内被刷到极限。对。当时我觉得我们发布时主推的那个，而且后来也确实成了一个相当不错的 benchmark，就是 terminal bench。在那之前，比较领先的是 SWE bench，它基本上是选取一些 open source project（开源项目）以及一些后来被解决的问题案例。

它的问题在于，它非常聚焦于 Python，以及脚本类任务，或者单个文件的修改。而 terminal bench 更偏向于，第一，它是在 terminal（终端）环境里。所以它包含像调度运行这样的事情，以及那些不只是改代码文件，而是更一般的软件开发任务。那也是我们最终在上面取得非常 frontier performance（前沿性能）的地方。现在它基本已经被刷到极致了，到了——我想，你知道，现在出的模型在它上面大概都能到 90%。

而且我觉得，从发布一个好的 benchmark，到它随后某种程度上进入 training data（训练数据），这个时间窗口是非常短的。

要打造一个优秀的 harness，到底需要哪些要素？以及，什么样的 harness 才算优秀？感觉生态里似乎有很多 FUD（恐惧、不确定性、怀疑），都在说“我的 harness 比你的 harness 更好”。

嗯，对。

对。你知道，常见的一种说法是，你得自己拥有 model（模型）才能做出好的 harness，或者反过来说，如果你不拥有 model，你反而会有更好的 harness。对吧。所以你的 mental model（思维框架）是什么？先把营销话术放一边，是什么让你始终站在前沿？

对。所以有几个比较通用的重要点。比如你做 caching（缓存）的方式。你知道，cache tokens（缓存 token）最后的成本可能只有十分之一左右。所以，对于一个既定的 harness 来说，一个很大的性能因素就是：你的 token caching（token 缓存）命中率到底有多高？再比如，你在 compression 或 compaction（压缩 / 紧缩）过程中表现如何？

通常来说，当你处理一个很长的 session（会话）时，你会超出 model 本身的 context limit（上下文长度限制）。所以 harness 会做某种 summarization、compression、compaction，不管你怎么称呼它。而你在这种 compaction 期间的表现，是决定 harness 好坏的一个关键因素。他们为此做的一类测试，叫 needle in the haystack（草堆里找针）：你有一段很长的线程，也许其中有一条信息特别重要。你的 harness 在 compaction 之后，能有多高概率把那条信息保留下来？

其他例子还包括 tool use（工具使用），或者它会怎样利用 environment（环境）来验证自己正在做的工作。这些东西某种程度上都可以有各自独立的指标，我们内部也有自己的 benchmark（基准测试），来衡量开箱即用的 agents（智能体）表现如何，以及 factory 的表现如何。我觉得，最初大家一个很天真的共同看法是：如果你同时训练 model、同时构建 harness，它们就会一起变得更好。

对。

但很遗憾——我的很多在 OpenAI 和 Anthropic 的朋友可能不太愿意听到——事实并非如此。如果你构建的是一个支持不同 models（模型）的 harness，这个 harness 反而会更好。

我直觉上会觉得，model 和 harness 的协同设计会让你做得更好，这一点到底是怎么回事？

对。

为什么从直觉上看，它实际上并不是这样？

这很类似于一个想法——大概十年前吧，如果你当时会说，嘿，我想训练我自己的 personal AI，那还是 ML 时代、还在 GPT-three 之前。我想训练我的 personal AI，所以我要把我所有的数据都喂给它，因为我希望它了解我。结果答案是：把整个 Internet 都拿来训练它，它对你的帮助反而会比只用你的数据训练更大。所以这里会出现一种类比：对于 model 来说，data 是什么；对于 harness 来说，models 就是什么。

也就是说，你让一个 harness 接触的 models 越多，就越能避免让这个 harness 过度拟合某一个特定 model 的细微特性。而且，不同 models 身上有一些特定的复杂之处，你可以从中学习，然后在你自己的 harness 里改进不同 models 的表现。这也是为什么，比如说，我们后来某种程度上不再继续这么做了，因为 TerminalBench 已经被刷到 benchmark（基准测试）上限了。但最开始时，每次有新的 Opus 或 GPT model 出来，在 Droid 里的 TerminalBench 表现都会比在 Claude Coder Codex 里更好。所以这也是为什么——而且这件事我觉得某种程度上也挺让人沮丧的，因为如果从 lab 的视角看，你理想上会希望“绑在一起时效果更好”，因为那样别人就必须用他们的 harness，不能换别的。但我觉得现实是，拥有那种 multimodal harness（多模型/多模态的调度框架），最后往往会在所有这些资产上都逼近前沿水平。

有没有一个比较好的例子或说明？概念上我能理解。有什么容易说明它的方式吗？

也许一个不错的例子是，如果你现在熟悉 Opus 和 GPT 5.6 的不同行为的话。

我熟悉，他不熟悉。

Opus 往往是——我是说，大体上、大体上吧。公平地说，老实讲，这些天我自己也没怎么做这类比较了。不过我可以这么说：粗略来看，Opus 有点像那种超级友好的同事。你对他说，嘿，我想去做这 20 个任务；他会说，好啊。

很好。对了，顺便说一下，其中有 5 个任务我发现其实没必要做。别担心。我已经把另外一些做完了。

我是这么做的。今晚不是个合适的时间。我们明早再接着做

吧。对。比如说，我们之后去喝杯啤酒，放松一下，随便聊聊。与此同时，GPT 5.6 则像是，会完全照做，我会把你说的每一件事都完成，什么都拦不住我。在这事做完之前我都不睡。它有点像，非常 OCD（强迫症倾向），你知道的，非常一丝不苟。

但有时候，你会想要这样一种模型：它真的能意识到，嘿，你给我的那 20 项清单，其实不管怎样，我这里有个更好的做法。你知道，5.6 更偏方法论、更按部就班。如果你为每一种情况都构建一个 harness（测试/约束框架），那么这个 harness 实际上也会各有擅长和不擅长的地方。比如说，agent（智能体）通常会做的一件事，就是它们会有一个 to do list（待办清单）；如果你给它一个任务，它就会去生成一个待办清单。而 Claude code harness 在某些情况下可以——或者说，这一点现在也许没那么相关了，但我觉得在更早的时候，这是一个更有说明性的例子。

更早的时候，它会非常严格地确保自己坚持那个 to do list，因为模型本身通常会跑偏。与此同时，Codex 不会这样，因为模型本身在这方面真的非常非常 OCD。但如果你是用户，你会希望无论如何都有一致的体验。比如，你会想确保如果切换到另一个模型，不会突然就丢掉自己正在处理的那些事情的脉络。所以在某些情况下，你可能确实非常需要稳健的 tool use（工具使用），而且你会用一些工具来处理这些 to do list。

你会希望 tool use 非常稳健，而且无论如何，如果我是用户，我都想在那里看到我的 to do list。因为确实有些情况下，它就是会莫名其妙没有那个 to do list。所以这些东西其实是在提升整体表现。而 to do list 之所以重要，是因为你可能正在做某种很疯狂的 migration（迁移），结果你没有 to do list。然后你又处在一个很长的 session（会话）里，中间还有 compaction（压缩），这些内容可能会在 summarization（总结）时丢失。然后你就忘了自己的第七步是什么，而这就可能成为一种 failure mode（失败模式）。

这算是一个关于“怎么会这样”的例子。很好的例子。

对。对。对。

这是个很好的例子。好，我们刚才谈了一种 maxing，也就是 benchmark maxing（基准测试最大化）。我们来谈谈 token maxing。好。

因为感觉世界已经变了很多。我们已经从 token maxing（token 使用最大化）走到了现在的 cost rationalization（成本理性化）。这对 factory 意味着什么？

对。所以也许我先把这个脉络讲清楚，这样大家对我们如何看待、以及是什么把我们带到这种 token maxing 上，能有一致理解。大致来说，有这么一个 phase one，或者说 phase zero 可能是：当时没人相信 AI。然后到 phase one，所有人都相信 AI。接着董事会就会问：mister CEO，你在 AI 这件事上到底做了什么？

你的 AI strategy（AI 战略）是什么？然后 mister CEO 就会想，妈的，我也不知道。比如，我们的 AI strategy 到底是什么？于是 CTO 就会说，确保所有人都去使用 AI。

然后到了 phase two，就是 CTO 会说，好吧，妈的，我们得确保每个人都用 AI。那就开始把它写进 performance reviews（绩效评估）吧。再公开一些类似 benchmark（基准）或公开排名，看看谁用的 tokens 最多，因为大家都很固执。

没人想用这些东西。大家都持怀疑态度。然后我们进入 phase three，这时所有人都看到了这些评分，也看到这已经成了他们 perf reviews（绩效考核）的一部分，于是他们会想，好吧，那我什么都用 AI 来做。

这差不多就是 phase three。也就是这种 token maxing：人们真的把 Opus 用在一切事情上。比如，SF 今天天气怎么样？Opus，告诉我。