2026年2月,一个40人的团队在Terminal Bench上排名第一。
你没看错。不是Anthropic的Claude Code,不是融资数亿美元的Cursor,是Factory的Droid。当你还在纠结该用哪个AI Agent写代码时,有人已经用它管理销售漏斗、重构15年前的COBOL遗留系统、让产品经理直接调用API生成PRD。
如果你觉得AI Agent只是个「会打字的程序员」,你可能低估了一个更大的变化——软件开发Agent正在成为下一代通用计算系统。
Factory联合创始人Eno Reyes不是典型的硅谷创始人。他不谈「颠覆」,不喊「All In AI」。你问他怎么打败巨头,他会告诉你:
「我们从来不对着Terminal Bench调优。我们有一套用真实企业客户数据构建的私有数据集。」
他的公司成立于两年半前。那时候,世界还不习惯让Agent在你电脑上「YOLO模式」乱跑。大部分开发者对AI的态度是:「能帮我补全代码就行,别碰我的Git。」
Eno做了一个反共识的决定:我们不做个人开发者市场。我们要做让一万人公司的VP of Engineering放心的产品。
这不是保守。这是赌未来。
他的判断是:真正难的软件问题在企业。如果你能解决「把潜艇里的气隙环境跑起来」「重构没人敢碰的COBOL代码」「让销售用Agent管理Salesforce」,那些看起来更「性感」的问题——全栈开发、零到一建站——自然会被顺带解决。
两年后,结果验证了这个判断。
Factory现在有一个客户,两个月内从0部署到10000名员工使用。不是工程师,是「所有靠近软件流程的人」——产品、运维、QA、数据科学家、甚至销售。他们公司排名第三的Droid用户是一个Account Executive。这个销售用Agent做客户调研、分析使用数据、追踪deal flow,所有workflow都跑在Droid上。
他不会写for循环。
但他是公司第三重度用户。
为什么Agent的瓶颈不在生成代码,而在验证代码?
大部分AI Agent的工作流程是这样的:生成代码 → 运行 → 报错 → 再生成 → 再报错。这是「测量一次,切割一次」的循环。
Droid的逻辑是:测量两次,切割一次。
当Eno在演示中让Droid构建一个快速阅读Web应用时,你会看到它的行为模式完全不同:
- 它会主动打开浏览器,用Chrome DevTools截屏验证UI是否正确渲染
- 它会检查Console里有没有报错信息
- 它会运行linter、type checker、unit tests——在你没有要求的情况下
- 它甚至会点击按钮,测试交互逻辑是否符合预期
这不是写在提示词里的指令。这是写在系统层面的「强制验证机制」。
Eno的原话是:
「Agent根本上受限于验证自己工作的能力。代码有无数验证器——linter、单元测试、类型检查。我们把这个做到了比大多数人更深的程度。」
结果是什么?
当你让Droid「给现有代码库添加一个新功能」时,它生成的组件会自动匹配你的设计系统——你的品牌色、你的边框样式、你的字体。不需要你写一个「design system skill」。因为它在开始工作前,会先做一个「grounding step」——读你的CSS、看你的现有页面、分析你的布局结构。
这就是为什么Eno说:
「很多人觉得Droid主观上很好用。他们真正指的是:我们验证工作的方式非常严格。」
但代价是什么?
几乎没有。因为这是「测量两次,切割一次」,而不是「测量一次,切割一次,再测量,再切割」。Token消耗反而更低。
Spec Mode:把「做什么」和「怎么做」分开
大部分AI Agent有一个「Planning Mode」。你告诉它要干什么,它给你一个计划,你批准,它执行。
Droid有一个「Spec Mode」。
区别在哪?
Eno的解释是:
「计划是How(怎么做),规格是What(做什么)。Agent应该自己想清楚How,用户只需要定义What。」
当你在Spec Mode下对Droid说「把这个应用做得更完整」,它不会直接开始写代码。它会先问你一串问题:
- 「你想支持哪些输入源?文本粘贴、文件上传、还是URL?」
- 「需要什么阅读增强功能?分块模式、本地存储、还是其他?」
- 「有没有额外需求?」
你回答完,它会生成一份完整的Spec文档,保存成Markdown文件。你可以在VS Code里手动编辑,删掉你不想要的功能(比如「派对模式按钮」),保存。Droid会重新读取你的修改,基于新的Spec制定计划,然后开工。
这里有个关键设计:Spec文档不是消失在对话历史里的一段文字。它是一个真实存在的、可版本管理的、可复用的文件。
这意味着什么?
你可以把它提交到Git,让团队其他人review。你可以在三个月后拿出来,让Droid基于同一个Spec再执行一次。你甚至可以把它变成一个公司级别的「产品规格模板」,让所有人用同样的语言定义需求。
Eno说:
「我们公司有一个共享的Notion文档地图——产品原则、核心价值主张、优先级框架。Droid会读这些文档。当我让它写PRD时,它用的语言、结构、原则,都像是一个在Factory工作了一年的人会说的话,而不是Opus 4.5随机发表的观点。」
这是一个「写作技能」(Writing Skill)的实际应用。
Skills、MCP、Hooks:你真的需要这么多概念吗?
当AI Agent生态爆炸式增长时,社区涌现出一堆新术语:Skills(技能)、MCP(Model Context Protocol)、Hooks(钩子)、Sub-agents(子Agent)。
对于新手来说,这简直是灾难。
Eno承认:「这是个热议的话题。我们支持所有这些东西——Subagengs、Skills、MCP、Hooks,还有一个全局配置系统。」
但他的观察是:Skills和MCP的使用率远超其他。
为什么?
因为Skills本质上是「可复用的上下文+逻辑封装」。你可以把一个复杂的工作流程——比如「用我们公司的语言风格写PRD」「分析客户使用数据并生成销售建议」「重构遗留代码时遵循的安全检查清单」——打包成一个Skill,一键调用。
MCP更适合集成外部工具,比如Linear、Notion、Datadog、Sentry。但Eno认为:「如果你能用Skill解决,Skill可能比MCP更好。」
Hooks适合极客,适合那些想把工具改造得「完全符合我个人workflow」的人。但对于企业来说,真正有价值的是:让几个专家为整个组织配置好Skills和MCP,然后统一分发。
Factory是唯一一个提供「企业级权限管理+Skills/MCP共享系统」的产品。
一个一万人的公司可以做到:某个团队开发的Skill,全公司所有人一键启用。这不是技术问题,是协作问题。
Eno的产品管理Skill里,包含了Factory的十一星体验框架(来自Airbnb的Brian Chesky):
- 五星体验:他们铺红毯,体验很棒
- 六星:?
- 八星:?
- 十一星:Elon Musk亲自开火箭游艇带你去火星
这个框架的作用是:定义「现在的基准」和「未来的突破」。
有意思的是:
「我们两年前的七星体验,现在已经是五星基准了。以前根本不可能的事情,现在是我们对普通用户的基础期待。」
这就是AI Agent领域的进化速度。
但这不是重点。
重点是:Factory把这个框架写进了Skill。当Droid帮你review产品Spec时,它会用这个框架提问——「现在是几星?下一步要到几星?」
这就是为什么Eno说:「大部分PM觉得『常规PM』的定义已经彻底变了。」
为什么软件开发Agent是下一代通用AI系统?
这是Eno最反共识的观点。
大部分人觉得:AI Agent会分化。编码Agent做编码,销售Agent做销售,设计Agent做设计。
Eno的判断相反:软件开发Agent会吞掉所有白领工作。
理由很简单:
「软件是AI Agent的物理学。它们最擅长操控自己世界的物理规则。这也是为什么软件开发Agent的进化速度远超其他领域——它们是用软件做的,所以能自我学习、自我迭代。」
你看Factory的销售团队:排名第三的Droid重度用户是一个AE(Account Executive)。他不写代码,但他用Droid连接Salesforce,分析客户数据,生成销售策略,追踪deal flow。
你看Factory的产品团队:全是Product Engineers。不是「会写代码的PM」,而是「用Agent武装的PM」。即使你没有软件工程背景,也能在Factory做产品——但你必须愿意用AI驱动你的大部分工作流。
你看Cursor、Anthropic、OpenAI的内部情况:「这些公司的人都会承认,公司里大部分人在用软件开发Agent提升生产力——不管他们是不是工程师。」
为什么?
因为Terminal不是一个「目的地」,而是一个「悬浮层」。
Eno的比喻是:IDE是一个封闭的房间。它包含了编码时需要的所有信息——调试器、50个按钮、复杂的面板。这种复杂性是故意的,因为它是一个power tool。但它也把你困在里面。你打开IDE,全屏工作,和外界隔绝。
Terminal/Agent不一样。它是一个overlay(悬浮窗)。它不是你工作的地方,而是一个漂浮在你所有工作之上的助手。它可以访问文件系统、打开浏览器、操作桌面应用、读取你的邮件、查询数据库。
「大部分在电脑上工作的人,都能从左上角那个小悬浮窗里获益——你跟它说话,它帮你做几乎任何任务。它就应该work。」
这就是为什么Droid的未来不是「更好的编码工具」,而是「通用计算Agent」。
Factory刚刚准备发布一篇研究:Droid已经越过了「自我改进」的阈值。
Eno没有详细解释。但这意味着:Agent开始能用自己生成的代码,改进自己的能力。
为什么40人团队能排名第一?
这是所有人最想问的问题。
Eno的回答分两层:
第一层:资源买不到为ICP定制的产品体验。
「所有世界级的资源,也买不到为你的理想客户精确定制的产品体验。」
Cursor、Claude、OpenAI的团队都很厉害。但他们面对的是「所有开发者」。Factory面对的是「需要在一万人公司部署、需要在气隙环境运行、需要重构COBOL遗留代码」的企业客户。
这两个市场的需求完全不重叠。
一个solo developer不在乎「企业级权限控制」,不在乎「OTEL可观测性」,不在乎「能在潜艇里跑」。但这些能力让Factory拿到了最复杂、最困难的真实软件问题。
「当你解决了这些问题,那些看起来更简单的问题——全栈开发、零到一建站——自然就被顺带解决了。」
第二层:不对公开benchmark优化。
「我们在Terminal Bench上的表现不是因为Terminal Bench。我们有一套独立的数据集,基于真实企业客户的数据构建。」
这是核心。
大部分AI公司在做什么?刷榜。看HumanEval、看SWE-bench、看Terminal Bench的排行榜,然后针对性优化。
Factory在做什么?让客户扔过来最难搞的问题——「我们有个15年的COBOL系统,所有碰过它的人都离职了,你能重构吗?」「我们需要在完全离线的环境部署Agent。」「我们要让非工程师也能查询代码库。」
解决这些问题产生的数据,比任何公开benchmark都更有价值。
结果就是:Factory在Terminal Bench上排第一,但他们从来没瞄准过这个榜。
理论升华:ICP越窄,能力越深,市场越大。
这听起来反直觉。大部分创业公司的逻辑是:我要做一个「所有人都能用」的产品,才能有最大的市场。
但在AI Agent这个快速进化的领域,反过来才是对的。
想想iPhone刚出来的时候。苹果没说「我们要做一个所有人都买得起的手机」。他们说「我们要做最好的智能手机,给那些愿意为体验付费的人」。
结果呢?他们吃掉了整个市场。
Factory的逻辑一样:先服务最难搞定的客户,构建最深的护城河,然后自然向下兼容。
当你能让一万人的公司两个月内全员部署,solo developer的需求只是其中一个子集。
局限性提醒:不是所有人都需要Droid
如果你是个人开发者,只想要一个「帮我补全代码」的工具,Droid可能过度设计了。
如果你追求极致性价比,市场上有很多补贴计划和开源工具。
如果你的公司还没有准备好「让所有人接触代码库」「把代码库变成单一monorepo」「开放读权限给非工程师」,Droid的很多企业级能力会被浪费。
Eno的观察是:
「一些公司会为设计决策付出巨大代价——比如『我们不用monorepo』或『只有这些人能访问代码』。这些决策在AI时代不会aging well。」
换句话说:如果你的组织架构还停留在2020年,先别急着上Agent。
余韵
有个细节Eno没说,但藏在演示里。
当Droid构建那个快速阅读应用时,最终生成的UI自动匹配了Factory官网的设计系统——品牌色、字体、边框、模块风格。
Eno说:「这是我们的颜色。这是我们的组件。」
但他没说的是:Droid不是靠「读了设计规范文档」做到的。它是靠在开始工作前,默默浏览了整个代码库,看了不同页面的CSS,分析了布局结构,然后在生成代码时自然地复用了这些模式。
这就像一个新入职的设计师,在动手画原型前,先花了一整天浏览公司所有产品页面,记住了每个按钮的圆角半径。
问题是:人类设计师需要一天。Droid需要几秒钟。
而且它记得每一个细节。