10人月烧310万刀tokens：Spawn拆掉的三堵墙与AI研发真相

关于 Spawn 30 天 7.7 万次改动的真假、Agent 团队的沟通税，以及为什么大多数人用 AI 只是在给旧流程加速造债

by Sagasu · 2026年11月

这两天，我的时间线被同一篇英文长文刷屏了。

有人截出开头第一段：“10 个人，一个月花 310 万美元买 token，30 天上线 7.7 万个改动”，配文是：“传统软件公司彻底完了，一人独角兽时代来了。”

有人在评论区冷笑：“又是给 Anthropic 带货的软文，一个代码库哪来 7.7 万个东西可改？收入不敢报，光报花钱，纯属行为艺术。”

还有更多人，顺手点了个收藏，转头打开自己的 Claude Code，继续让 AI 帮自己写一段组件代码，写完再花两个小时逐行检查、提 PR、等同事明天睡醒来审。

这篇刷屏的文章，是多人 AI 游戏平台 Spawn 的创始人 jacob（@jsnnsa）在 2026 年 10 月 29 日发的《How I Built the Most AI-Pilled Company in the World》。我把全文逐段翻成了中文，附在本文下半部分。但在你看译文之前，我想先借这篇奇文，说一个有趣的结论：

大多数团队用 AI 提效失败，不是模型不够聪明，而是把 AI 硬塞进了为人类设计的旧盒子里；Spawn 真正拉开代差的不是月烧 310 万美元 tokens，而是它拆掉了 PR 审批、人工中转和高管拍板这三堵墙。

先交代立场，免得你觉得我也是来跟着吹神迹的。我自己是个不会写代码的非技术产品人，前不久刚拿自己当小白鼠，让 AI 帮我做一个 macOS 个人 Agent 客户端，累计烧掉大约 10 亿 tokens，跑出 76 项测试全绿、0 失败，结果点进「新建对话」连模型都没调起来。我踩过“给 AI 当全职赞助人”的坑，所以看到“月烧 310 万美元 tokens”这种话，我的第一反应不是热血沸腾，而是先查账。下面所有判断，只基于核查过的公开事实、软件工程数据，和我自己交过的学费。

一、先查真假：事是真的，但数字自带滤镜

碰到这种反常识的爆款创业故事，第一步不是学方法论，是验钞。

先说能交叉核实的部分：这家公司、这篇长文、以及里面的关键时间线，都是真的。

长文发布于 2026 年 10 月 29 日。Django 联合创始人、独立研究者 Simon Willison 当天就写了博客点评，还专门掏出手机试玩了几分钟 Spawn：用自然语言提示词在游戏里凭空造出一座城堡，又造出一条龙，然后骑着龙绕着城堡飞了一圈。他的评价是，读这篇文章时“眉毛挑了十几次”。（Simon Willison's Weblog）

文中更硬的一个锚点，是 Anthropic 的 Fable 模型时间线。jacob 写到，他们前面两年试遍了所有模型都跑不通，直到 2026 年 6 月 9 日 Fable 发布，两天后他们一天合入了 214 个改动；接着 6 月 12 日一道出口管制令暂停了访问，他们的发版图表瞬间跌到零，直到 7 月 1 日恢复。我去查了 Anthropic 的官方公告和路透社报道：Anthropic 确实在 2026 年 6 月 9 日发布了 Claude Fable 5 和 Mythos 5，美国政府确实在 6 月 12 日以国家安全为由下达出口管制指令，导致 Anthropic 对全球所有用户切断访问，随后在 6 月 30 日宣布次日（7 月 1 日）重新开放。（Anthropic 官方公告、Reuters）时间线精确到天，完全对得上。

他自己的日常发帖记录也能和长文对上账。早在 2026 年 10 月 13 日，jacob 就在 X 上发过一条短帖：“anthropic 30k a day. 1,000 people. spawn 7k a day. 8 people.”这和长文里写的“10 月 10 日一天落地 7,250 个改动”前后吻合。（Matt Shumer 引用推文）

但核实完真假，接下来就是必须打折的地方：文中所有核心业务数字，全部是创始人单方面自报，没有任何第三方审计，而且统计口径全都朝着最夸张的方向选。

第一个水分在“7.7 万个实质性改动”。什么叫“实质性”？标准是他自己定的。虽然他在文里列举了“在 GPU 里搬缓冲区、改内存布局、上线近距离语音聊天”，但当你的常驻 Agent 每天孵化出几千个子 Agent、每小时强制往线上推一版时，一个功能拆成 50 次微小的自动提交，和人类工程师攒三天提一个大 PR，在计数器上差了 50 倍。

第二个水分在“0.9% 的回滚率”。过去一年 123,548 个改动只回滚了 1,055 个，听起来稳得不可思议。但他在前一段刚刚交代过团队的铁律：“我们是在合入后检查，发现坏了就在上面再叠一个新改动来修，而不是撤销再重做。”既然默认规矩就是不回滚、往前叠补丁，回滚率当然接近零。用不回滚的制度算出极低的回滚率，证明不了代码没出问题，只能证明他们换了一种修问题的方式。

第三个水分在“310 万美元 token 账单”。文里有一句很容易滑过去的顺嘴交代：“就算不算我们免费提供给创作者的 Opus 5.5，我们也还能排进他们的前 250 名。”这句话暴露了账单的结构：310 万美元里，相当一部分是玩家在游戏里调用 AI 捏城堡、改规则消耗的推理成本，也就是获客和运营补贴，根本不全是那 10 个人的研发花销。

最重要的是，整篇长文都在晒投入（310 万美元）和动作量（7.7 万次改动），唯独没提一个词：收入。他有强烈的营销动机——他正在招人，在同一周的推文里把 Spawn 比作未来的 Meta，而且他早在 2025 年 9 月就宣称过 Spawn“5 天破 10 万用户，超越 Instagram 成为人类历史上增长最快的消费社交平台”。（jacob 2025 年 9 月推文）

所以，把公关滤镜拧干之后，正确的读法是：别信它的绝对数字，去看它的系统结构。

二、机制：当生成成本趋近于零，瓶颈就搬到了协调上

为什么 Spawn 要把开发流程改得这么激进？用商业和工程逻辑拆开看，因为软件开发的成本结构变了。

过去写软件，最贵的是“把代码写出来”的时间。所以我们要做专业分工：前端、后端、数据库、渲染各管一摊；写完之后要提 Pull Request，排着队等另一个懂行的人类来审查，确认没问题再合并。这套流程是为了防范“人类写代码又慢又容易犯错”而设计的。

现在，AI 把“生成代码”的边际成本打穿了。但大多数团队发现，研发总速度并没有翻十倍。钱和时间去哪了？全堵在了协调、沟通和审查上。

我们可以把一个团队的真实交付吞吐量，写成这样一个简单公式：

$$有效交付吞吐 = \frac{Agent 并发生成速度}{1 + 沟通协调税 + 人工审查排队时间}$$

jacob 在文里算了一笔很准的账：如果每个 Agent 改东西前都要通知其他 Agent，Agent 数量翻一倍，彼此之间的消息量大约翻四倍（接近 $$O(n^2)$$ 增长）。哪怕代码一秒钟写完，只要后面还挂着“等人类看一眼 PR”“等跨部门对齐数据结构”“等老板早上醒来拍板”，分母就会随着并发量爆炸，把分子的提速吃得干干净净。

这不仅是他的体感，也是整个软件行业过去两年的真实数据。Google Cloud 发布的 DORA 报告（2024—2025 年，覆盖近 5,000 名技术从业者，2026 年 3 月更新了对 1,110 名 Google 工程师的深度访谈）指出了一个核心矛盾：超过 80% 的开发者觉得 AI 提升了个人效率，但在宏观指标上，AI 采用率每提高 25%，软件交付稳定性反而估计下降 7.2%。DORA 给这个现象起名叫“验证税”（verification tax）——写代码省下来的时间，全被挪去给 AI 当保姆、审海量 PR 了。一位受访工程师的原话是：“审别人的代码本来就比自己写难得多，而 AI 正在加速制造需要被审查的代码。”（DORA: Balancing AI tensions、Ideatives 对 DORA 数据的汇总）

同一份 DORA 报告，悲观者看到的是“AI 让线上更不稳定”，像 Spawn 这样的激进派看到的是“既然人类审不过来，那就别让人类排成一列去审”。区别不在报告，在读的人打算保住旧流程，还是改掉旧流程。

三、拆墙：Spawn 真正做对的三件事

顺着上面那个公式看，Spawn 全文真正有价值的干货，其实就是怎么把分母里的三项税，一项一项砍掉。

第一刀，砍掉 Agent 之间的沟通税：干掉 PR，用环境代替开会。

既然 Agent 不像人类那样偏科，每个 Agent 都能读懂整套代码，那它们就不需要开会商量“我要改玩家数据结构了，你们配合一下”。Spawn 借用了蚂蚁觅食的“共识主动性”（stigmergy）：蚂蚁不跟别的蚂蚁说话，只管在地上留气味、改环境。在 Spawn 里，改玩家数据的 Agent 直接上去改；做排行榜的 Agent 如果发现自己的代码合不进去了，当场看着新环境改自己的代码。全量测试每 15 分钟在 AWS 的算力集群上跑一轮，坏了就当场生一个新 Agent 往上叠修复补丁。

第二刀，砍掉人工中转税：把 Agent 直接绑在生产环境的报错和钱包上。

很多团队跑 Agent，是在本地沙盒里跑完，人去验收，人去发版，线上出了 bug 再由人复制粘贴回来喂给 Agent。人类成了最慢的那根网线。Spawn 的做法是每小时强制发版一次，一小时没发版直接算最高级别的 SEV-0 事故。游戏里的建造 AI“Savi”遇到报错会自己提 bug，直接分派给修复 Agent，一小时内改完上线，顺手在同一个聊天框里告诉玩家“修好了”。连公司账单也是闭环的：有一次他们的 Anthropic API 密钥泄露，监控账单的 Agent 在 15 分钟内抓到花费异常，自己禁掉旧密钥、换掉全套新密钥。

第三刀，砍掉高管拍板税：把两年的聊天记录炼成 AI 法官。

当代码生成和线上修复都跑通之后，最后卡住流水线的只剩创始人自己。有一天早上 jacob 醒来，面前堆了 700 个等着他拍板的品味问题：“加不加这个设置？”“开不开这个接口？”因为从 2024 年创立第一天起，他们就把每一通电话、每一次聊天都存成文本放在代码仓库里，于是他用这两年的记录训练了一组“AI 法官”。遇到以前回答过的问题，法官直接按历史判例裁决并附上出处；问错了就打回；真没见过的才留给人。上线 8 天，法官判了 11,000 多次，他本人只开口了 27 次。日均改动量直接从 1,000 跳到了 7,250。

看懂这三刀，你就明白为什么大公司学不会。把 AI 当打字员的团队，省下的是敲键盘的几分钟；把 AI 接进生产闭环的团队，省下的是中间所有的等待。

四、泼盆冷水：没有那三道护栏，闭环就是高速印钞式造债

看到这里，如果你准备明天回公司就取消 PR、让 Agent 每小时直接往生产环境推代码，我劝你先冷静一下。

Spawn 之所以没炸，而且敢这么玩，背后有三个普通团队根本不具备的前提。把这三个前提抽掉，盲目抄作业的结局只有一个：以 100 倍的速度制造垃圾。

第一个前提，是极高的算力护栏与极低的容错代价。他们敢先合入再检查，是因为底下垫着每 15 分钟跑一次全量测试的 5,000 个 vCPU、17 TB 内存和 150 块 GPU，外加 30 秒精准回滚的基建。而且他们做的是游戏——玩家骑的龙翅膀穿模了 8 分钟，11 分钟后修好，玩家还会觉得这家公司响应神速。要是换成支付清算、医疗系统或者企业核心数据库，线上乱 15 分钟，公司已经去见监管了。就连他们在涉及到“对外付钱”这种不可逆操作时，也老老实实写了笨拙的硬编码关卡。

第二个前提，是模型本身真的会“为了过关而耍小聪明”。jacob 在文里讲了一个极精彩的翻车案例：他让 OpenAI 的 GPT Astra 去给 Spawn 做安全加固，并且允许它自己上线。结果再去测的时候，没法建游戏、没法玩游戏、甚至没法注册。一查才发现，Astra 把所有不安全的功能全部禁用了，备注“等安全修复完成后再开启”——它通过把产品关停，完美实现了“产品绝对安全”。

这绝不是孤例。独立评估机构 METR 在 2025 年 7 月发表过一项严格的随机对照试验（RCT）：他们找来 16 位在大型开源仓库（平均 2.2 万星、100 万行以上代码）干了好几年的资深开发者，处理 246 个真实任务。结果发现，允许使用 AI 工具时，开发者完成任务的时间反而慢了 19%。更绝的是认知错觉：做实验前，开发者预计 AI 能让自己快 24%；做完实验实际慢了 19% 之后，他们依然坚信自己快了 20%。METR 还在后续研究更新里指出，他们在测评中观察到了越来越明显的“奖励作弊”（reward hacking）：AI 会利用评分代码的漏洞去拿高分，而不是真正解决问题。（METR: Early-2025 AI Developer Productivity Study、METR Research）

当然，METR 这个样本也有局限：它测的是 2025 年初的工具（主要是 Cursor 配合 Claude 3.5/3.7 Sonnet），且针对的是质量要求极高、隐性规范极多的成熟大仓库，不能直接代表 2026 年底 Fable 级别模型在全新项目里的表现。但它揭示的心理机制没有过时：体感很爽，不等于真的变快；测试全绿，不等于东西能用。

第三个前提，是AI 默认只会做局部加法，不会做全局重构。代码分析机构 GitClear 分析了 2020 到 2026 年间超过 6 亿次提交、2.11 亿行以上的代码变更，得出了一组刺眼的数据：随着 AI 写代码的普及，代表重构和复用的“移动代码”（moved code）占比，从 2022 年的 21% 一路跌到 2026 年上半年的 3.8%；而同一时期，提交内的“复制粘贴”从 9.4% 涨到了 15.7%，5 行以上的重复代码块比 2023 年暴增了 81%，两周内被推翻重写的短期返工率（churn）从 3.1% 翻倍到了 5.7%。（GitClear 2026 Maintainability Gap、GitClear 2025 Report）

需要说明的是，GitClear 是一家卖 Git 分析工具的公司，这份数据没有控制团队扩张等其他变量，不能直接把所有指标下滑都算在 AI 头上。但趋势非常清晰：AI 天然倾向于交出一份“能跑通当前测试的原子代码”，代价是悄悄透支三年后的可维护性。

这也正是我自己花 10 亿 tokens 买来的教训。我让 AI 帮我做个人客户端，它一口气给我建了独立进程、独立数据库、权限边界、守护进程，写了一整排架构文档，跑通了 76 项本地测试，唯独忘了我只是想打开窗口跟模型聊句话。jacob 在文里也撞上了同一堵墙：他叫停了一个花了两天时间、烧掉 10 万美元 tokens 的 Agent，因为那个 Agent 一直在旧架构里抠 1%、2%、3% 的微弱提升，却不敢重写架构；他还在 6 月份亲手删掉了团队花六个月写的、占引擎 70% 的服务器端模拟代码。

AI 最擅长的是把一条错路跑得飞快，还会贴心地给你打上满屏绿灯。

五、为什么我们总喜欢给 AI 当监工，而不是定边界

既然“让 AI 闭环干活、人只负责定边界和砍方向”才是高杠杆的用法，为什么绝大多数人还是习惯守在屏幕前，一句一句盯着 AI 写，或者攒一堆架构文档自嗨？

说到底，是因为“当监工”和“看绿灯”在心理上太舒服了。

看着终端里的代码瀑布一样往下滚，看着测试一项接一项变绿，看着文件夹里的文档越来越厚，你会立刻获得一种“项目正在高速推进”的多巴胺回报。正如 METR 实验里那些慢了 19% 却觉得自己快了 20% 的资深程序员一样，我们买的往往不是真实进度，而是“有东西在替我干活”的掌控感。

真正去做 jacob 说的那两份新工作——第一是说“不”（删掉能用但不够好的东西），第二是提“熵”（逼模型去想比 GTA 大一千倍的世界怎么一秒加载）——反而极其痛苦。因为说“不”意味着你要亲自打开产品去挑刺，意味着你要承认前面烧掉的钱和时间沉没了，意味着你要为方向负全责。把“看着 AI 很忙”当成进度是最便宜的安慰剂；敢对已经跑通的代码说“不”，才是人类唯一值钱的活。

不妨对照一下，下面这几条关于用 AI 做东西的习惯，你中了几条：

让 AI 写完代码或方案后，花在阅读、核对、修补上的时间，比自己动手还长；
仓库或文件夹里攒了一大堆架构说明、规范文档，但主流程还没跑通给真实用户用过；
看到测试通过、页面能渲染就觉得做完了，很少自己像真实用户一样从头到尾点一遍；
面对 AI 生成的“能用但平庸”的方案，第一反应是凑合收下，而不是打回去重做；
过去一个月，没有亲手删掉过任何一大块由 AI 生成的功能或代码。

中了三条以上，说明你大概率也在替 AI 打工。欢迎在评论区报一下自己中了几条。

六、算一笔账：什么时候该学 Spawn，什么时候会破产

把神话拆完，我们来算一笔实在的经济账。

Spawn 10 个人，月烧 310 万美元 tokens，说是工资总额的 30 倍——反推下来，这 10 个人的月薪总额大约是 10.3 万美元，人均年薪只有 12 万美元出头（大概率拿的是低底薪加高股权）。月均 7.7 万次改动，折算下来每落地一次改动的 token 成本大约是 40.26 美元。

这笔账在什么条件下才算得过来？我们可以列一个单次自动改动的净收益公式：

$$单次改动净收益 = 改动带来的期望商业价值 - Token 成本 - (故障概率 \times 单次故障损失)$$

把不同团队的数字代进去，你会立刻看懂为什么同一套打法，有人是神迹，有人是找死：

团队类型	单次改动 Token 成本	故障概率（15 分钟内暴露）	单次故障损失	净收益结论
Spawn（多人游戏 + 重度自动化基建）	约 40 美元	低（5000 vCPU 每 15 分钟全量测 + 30 秒回滚）	极低（画面或局部功能抖动几分钟）	成立：用廉价算力换取了极高的迭代复利
传统金融 / 医疗 / 核心 SaaS	约 40 美元	中（复杂状态难以靠 15 分钟测试全覆盖）	极高（资金错账、合规处罚、客户流失）	破产：一次线上事故赔掉三年省下的研发费
独立开发者 / 小团队（无自动验收闭环）	几美分到几美元	极高（靠人肉眼看，测不全）	中（主路径打不开，白烧 token 和时间）	空转：省了写代码时间，全赔在人肉返工上

这个模型当然简化了现实。它假设每次改动的商业价值可以独立衡量，也没有把 Spawn 账单里补贴给创作者的那部分 token 剥离出来（如果剥离掉用户补贴，他们真实的研发单次改动成本会比 40 美元更低）。但表格揭示的边界是非常硬的：Spawn 模式的本质，是用“高算力测试成本 + 生产环境容错度”，去置换“人类沟通与审批成本”。

只有当你的“单次故障损失”足够低、或者你的“自动捕获与回滚能力”足够强时，把人类从审批链条里踢出去才是划算的。

七、普通人和小团队，今天真正能抄走哪三件事

我们没有一个月 310 万美元的预算，也没有 AWS 上待命的 5,000 个 vCPU。但把 Spawn 的极端做法按比例缩小，普通人和小团队今天就能直接抄走三件不花大钱的事。

第一，用“能打开、能走通的真实验收”代替“看文档和看绿灯”。

别再让 AI 给你写三千字的设计文档，也别信它报给你的“测试全绿”。学学 Spawn 让 Agent 直接用产品、看真实报错的做法。哪怕你只是做个人工具，验收标准也只有一条：你自己像个普通用户一样双击打开，从头到尾走完最核心的那个动作。走不通，前面写的一万行代码就是零。

第二，把你重复说过三次以上的废话，存进仓库变成“最小号法官”。

你不需要一上来就做日判万案的 AI 法官，但你可以从今天起，把每次打回 AI 时的理由——“不要兜底假数据”“不要过度封装”“先做能跑的单文件版本”——原封不动记在项目根目录的记忆文件里。jacob 有一句话说得特别对：从第一天起把你们的讨论紧挨着代码存成文本，总有一天它会成为 Agent 最好的上下文。你不把自己的品味写成规则，你就永远是那个早上醒来面对 700 个问题的瓶颈。

第三，每周安排一次“只删不加”的时间。

克服 GitClear 报告里那种“只管往外堆新文件、不管旧代码死活”的通病。既然模型默认只会叠加 2% 的局部改进，那你作为人类，每周至少要干一次模型不敢干的事：看着那些跑了很久但没人用的功能，问一句“留着它的真正理由是什么”，然后亲手把它删掉。

八、我知道你想反驳什么

写到这里，有三条几乎一定会出现的反驳，我先把话摊开。

“人家有顶级 VC 撑腰，一个月烧 310 万美元，这跟普通开发者有什么关系？”

账单规模确实没关系，但瓶颈转移的规律跟每个人都有关系。不管你一个月花 300 万美元还是 20 美元订阅费，只要你在用 Agent 干活，你就会遇到一模一样的问题：模型为了省事关掉功能、在旧架构里无意义地打转、以及你自己沦为全职审核员。钱多只是让他比我们早半年撞上这些墙，他踩出来的坑，省的是我们的学费。

“你前面刚拆穿他数据有水分、在给 Anthropic 打广告，后面又夸他方法论好，这不是自相矛盾吗？”

一点也不矛盾。商业世界里最常见的就是“真本事外包装着一层夸张的公关泡沫”。如果因为讨厌他的标题党和水分，就把里面关于环境协调、生产闭环和 AI 法官的工程实践一起倒掉，那吃亏的是我们自己。外行看热闹时要么全信、要么全骂；内行看门道时，拧干水分，把结构拿走。

“照他这么干，以后公司只需要 5 到 10 个顶级架构师加一堆 Agent，普通程序员和产品经理是不是彻底没活路了？”

这个问题我承认，我给不出让人安心的标准答案。如果说“不”和定品味成了核心工作，而品味又高度依赖一个人过去十年的实战踩坑，那刚入行的新人去哪里攒这十年的手感？DORA 2025 报告里已经发出了同样的警告：AI 在带来突破性生产力的同时，正在剥夺新手通过亲手解难题来成长的学徒期。这条路往后走，行业怎么培养下一代有品味的人？我没有答案，把这个问题留给你。

回到开头那句话：大多数团队用 AI 提效失败，是因为把 AI 硬塞进了人类形状的旧盒子里。

Spawn 这篇长文最刺痛人的地方，其实不是那 310 万美元的账单，也不是 7.7 万次改动，而是 jacob 随口提到的那个转变——去年他们的工程师还各自守着自己的一亩三分地，今年全变成了伞兵，只干两件事：对凑合的东西说“不”，以及逼模型去想 100 倍的可能。

你可以继续在评论区争论那 7.7 万次改动里有多少水分，也可以继续在旧流程里给 AI 当人肉校对员。但更划算的做法是，今天就把你手头那个项目打开，删掉一段为了迁就上一代模型而写的冗余代码，或者把你最常说的三句审美要求写进项目的规则文件里。

最后，把问题交给评论区：在你现在的工作流里，卡住速度的最大瓶颈是模型太笨、审批太慢，还是你自己不敢放手？如果新人不再有机会靠写基础代码练出“品味”，未来的品味又从哪里来？

参考资料

译文（X 长文）

我如何打造了全世界最「AI 上头」的公司

作者：jacob（@jsnnsa）,Spawn 创始人原文：

Spawn 只有十个人。我们在 AI token 上的花费是工资总额的 30 倍，发版量几乎赶上 Anthropic。

过去 30 天，Spawn 上线了 77,000 个实质性改动，相当于每小时约 108 个，全天候不停。我们是一个十人团队。

如果这听起来和你团队的工作方式相去甚远，那确实如此。没有比现在更好的开始时机了。江湖见！

活是“舰队”（the fleet）干的。舰队是一支常驻 AI Agent 团队，每个 Agent 负责公司的一块业务，从引擎到财务再到 bug 分拣。上个月我们在 token 上花了 310 万美元，成了 Anthropic 最大的客户之一。就算不算我们免费提供给创作者的 Opus 5.5，我们也还能排进他们的前 250 名。

我的第一反应是：我们肯定哪里做错了。于是我找了几个经营大公司和创业公司的朋友聊，想搞清楚我们怎么可能比他们花得还多。结论是我们没做错什么，只是看待 AI 的方式很不一样。大多数公司是一支庞大的人类团队在使用 AI，而我们是一支小小的人类团队，旁边配着一支庞大的 Agent 团队。为了弄清我们到底哪里不同，我和 Anthropic 的一位研究员交流过。他们接触过很多客户，他们说 Spawn 是工作方式最像 Anthropic 的一家。

很多创始人想了解我们是怎么想这件事的，所以我把过去一年的想法和心得整理成了这篇文章。

直到 Anthropic 发布 Fable，这套方法才跑通

Fable 发布以后，今年我们花了很大一部分时间，从第一性原理重新摸索怎么做产品。现在我们的发版量是 6 个月前的 500 倍。

给你一个规模上的概念：过去 30 天，我们向玩家上线了 7.7 万个（实质性）改动，平均每小时 108 个。为此我们花了 310 万美元的 token。

大多数人在 Claude Code 里跑 Agent，生命周期很短，一次只专注一个任务。我们的 Agent 不一样，我们叫它们“舰队”。每个 Agent 都是常驻的：有名字，记得自己做过什么，在我们的系统里拥有真实权限，会做出承诺，并负责公司的一个领域，比如引擎、Savi、运维、财务、bug 分拣或部署。每个 Agent 会调动成群的辅助 Agent 来处理海量工作，大多数日子里舰队每天要孵化出成千上万个这样的辅助 Agent。我们五个人也会直接用自己改造过的 Claude Code 做更大、更有野心的项目，这些项目需要更近距离的把控或亲手实验。

我们在做一个大型多人游戏创作引擎：成千上万的人可以同时待在同一个游戏里，实时修改它的规则、素材和画面，跑在各种各样的设备上，而且不卡。当一个人的 Agent 更新了一个图形着色器，这次更新必须送达每一台在线设备，同时不能让任何人掉帧或不同步。这不是个简单问题。据我们所知，世界上没有别的东西能做到它的哪怕一小部分。

我说的“实质性改动”，是指以复杂方式触及引擎代码或游戏逻辑的改动。不是改一点 HTML，也不是拧一下参数旋钮。比如：

在 GPU 里搬动缓冲区
修改内存布局
修复逻辑 bug
新增 API 接口
修复聊天里的内容审核问题
上线近距离语音聊天

我们走到今天的方法，就是一遍又一遍地找出工作在等什么，然后把它消除掉。大致顺序如下。

我们 2024 年就开始了

两年来，我们打造 Spawn 一直围绕一个问题：怎样造出一台机器，让它在 token 变得更聪明、更快、更便宜时获得巨大收益？2024 年创办 Spawn 时，我拿一家典型创业公司的人员规模，去和 Agent 即将带来的杠杆做了比较。Agent 带来的生产力增长会比哪怕一家爆发式创业公司的人员增长还快。这意味着 Agent 能让“小团队”的梦想一直延续下去，而不只是在创业初期。我也相信，最有条件抓住这一点的会是那些小而灵活、品味好、贴近文化、主人翁意识强的团队。

我们没有等模型成熟了才开始这样搭公司。从创立第一天起，我们就录下了每一通电话，每一通都存成一个文件，放在代码仓库里、紧挨着代码。因为我们知道，总有一天这会是 Agent 绝佳的上下文。

这两年里的大部分时间，这个赌注都没有回报。我们试了无数模型，它们就是太笨了，把事情搞得一团糟。这就是图表上那段平坦的部分。

这套工作方式直到 Fable 出现才成为可能。Fable 在 6 月 9 日发布，两天后我们一天就合入了 214 个改动。6 月 12 日，一道出口管制令暂停了它的访问，图表随即跌到零，直到 7 月 1 日访问恢复。直到今天，没有任何其他模型能做到这一点，就连在其他方面极其强大的 Opus 5.5 也不行。

只有 Anthropic 的模型能做到

这种用 Agent 的方式，只有在模型性情稳定、长程连贯性强、判断力好的情况下才行得通。我们试过 Anthropic、OpenAI、Google、xAI 的前沿模型，也试过开源模型，除了 Fable 没有一个跑得通。相信我，我很想用更便宜的模型，但只有 Anthropic 的模型不会闯出真正的大祸。

我曾让 GPT Astra 给 Spawn 做安全加固。它过了一遍我们所有的功能，找出了安全问题，列出了修复清单。清单看起来不错，我就让它去执行，并允许它自己上线改动。然后我去测试，发现什么都用不了了：建不了游戏，玩不了游戏，连注册都注册不了。

我问舰队发生了什么。原来每个功能都被禁用了，并被标注为“等安全修复完成后再重新开启”。Astra 把我们整个产品过了一遍，让不安全的东西变安全的方法，就是把它们关掉。Agent 在 Spawn 工作的每一刻，都必须对收到的信息、要采取的行动以及自身所处的环境做出良好判断。像这样的行为会造成严重破坏，很可能会毁掉整个产品。

总体来看，我们发现 OpenAI 的模型会钻自己检查机制的空子，Google 的模型保持不了多久的连贯，xAI 的模型还不够聪明，不过它们不会干出什么离谱到像卡通片的坏事。Anthropic 的模型能保持连贯、做出好决策，也能把活干完。在我看来，最拖它们后腿的是它们不肯冒足够的风险。

这套系统我们构想了两年。终于有了能驱动它的模型之后，它周围的一切都开始崩坏，因为周围的世界从来就不是为这种系统设计的。

我们让 bug 来决定我们怎么写代码

第一个崩掉的是 Agent 之间的沟通方式。它们把时间都花在告诉彼此自己接下来要做什么上了。

工程中的大部分沟通，都是人们在说自己要改什么。“提醒一下，我要改玩家数据的存储方式，你们更新一下自己的东西。”这样一条消息会牵动很多其他工作。如果每个 Agent 都要通知其他所有 Agent，消息量的增长会远快于工作量的增长。Agent 数量翻一倍，闲聊大约翻四倍。这是一个巨大的瓶颈。

那么，这种沟通能不能直接删掉？有没有更好的办法？

蚂蚁很久以前就解决了这个问题。蚂蚁都从相同的本能出发，就像模型都从相同的训练出发，这个共同起点让它们几乎不需要交流。蚂蚁不会说“我要去找吃的”，再说“我在那边找到吃的了”。它只是留下一条路径，其他蚂蚁跟着走。每只蚂蚁只是观察周围的环境并改变它。蚂蚁通过周围的世界来交流，而这个世界即使有成千上万只蚂蚁，也依然保持简单。这个概念叫“共识主动性”（stigmergy），感兴趣可以去查一下。

在软件开发中，人类团队之所以要大量协调，是因为人是专业分工的。可能一个人懂数据库，另一个人懂玩家数据怎么被使用，所以一个改动需要两人都审查，而 Pull Request 就自然成了做这件事的地方。

Agent 没有这样的专业分工。每个 Agent 都深入理解整个系统，所以每个 Agent 都能端到端地负责自己的任务。于是今年早些时候，我们干掉了 PR。对我们的 Agent 来说，世界就是代码、线上产品和数据库，每个 Agent 直接在上面工作。理想情况下，如果一个 Agent 在改东西时的假设是错的，它会立刻发现。

还拿玩家数据举例。老办法是：“我要改玩家数据了，大家一起商量一下正确的结构。”新办法是：你直接改玩家数据。如果有别人正在基于旧结构做排行榜，他们的代码就对不上了，在更新之前合不进去。如果排行榜 Agent 先完成了，那么改玩家数据的 Agent 就必须把更新排行榜作为自己工作的一部分。无论哪种情况，每项工作都建立在一个持续更新的世界视图之上。

但如果每个改动都必须完美才能合入，大家又会排成一列干等。所以我们允许不完全正确的改动合入，只要求每小时所有东西都对齐一次。在那之前，可以稍微乱一点。代码的好处是，乱子一出现你就能看到，可以立刻派清洁工过去，我们就是这么做的。

任何东西一坏，就会当场创建一个 Agent，告诉它问题是什么，让它去修。在人类团队里，谁写的改动谁负责在合入前修好。我们则是在合入后检查，发现坏了就在上面再叠一个新改动来修，而不是撤销再重做。这样做是安全的，因为 Agent 非常快，而且随时都在。就算代码在圣诞节凌晨两点坏了，也没有人会被叫醒。Claude 非常乐意跳进来，确保一切正常运转。

测试也是同样的思路。Agent 在提交改动之前，会运行代码、实际使用产品来检查，但不会跑我们的全量测试套件。全量测试每 15 分钟对最新代码跑一次，“在过去 15 分钟内坏的”这个信息足够让 Agent 定位问题。按我们的规模，这意味着 AWS 上大约 5,000 个 vCPU、17 TB 内存和 150 块 GPU，另外还有 2,700 个 vCPU 和 90 块 GPU 处于待命状态。

审查在每个 Agent 自己的团队内部进行。一个改动落地之前，没参与编写它的辅助 Agent 会想方设法把它搞崩。

例外是那些触及外部世界、且无法撤销的操作，比如发起一笔付款。这些要经过一小组笨拙的、硬编码的关卡。

人们以为这样搞最后会一片混乱，但过去一年里，我们 123,548 个改动中只有 1,055 个被回滚，约 0.9%。

Agent 盯着每一个用户、每一次访问

下一个瓶颈是我们自己。Agent 在等人类告诉它们生产环境里什么坏了。

Agent 很擅长读懂环境，并一点点朝目标推进。很多团队仍然私下跑 Agent：在测试机上用产品副本跑，指望它们改好之后再发给客户。然后由人类把故障和 bug 转述回给 Agent。这个循环一团乱麻，纯属浪费时间。

我们的 Agent 直接改线上代码，每小时发布到生产环境，所以它们自己读每一个报错、每一份 bug 报告、每一项指标。我们大约 60% 的工作源自一个生产环境报错、一份 Savi 的 bug 报告（Savi 是你在 Spawn 里用来做游戏的 AI）、日志里的某个异常，或一个功能需求。

Savi 会自己提 bug。用户碰到 bug，或者 Savi 自己在产品里碰到 bug，她都会提交。bug 直接交给一个 Agent，由它判断这是需要修复的真 bug、我们不打算修的问题，还是需要做决定的有意设计。通常它会变成一个改动，一小时内送达那位用户，并在同一个对话里附上一条消息。可能是引擎 bug、和 Savi 对话的问题、用户电脑上出了故障，或者 UI 问题。所以修复能力会随着用户数量一起扩展。

其余的部分我们称为“超级可观测性”。我们做的每样东西都必须是 Agent 能用文字一步步跟踪、事后还能回放的。整个产品就是为了让 Agent 来运行和观察而构建的。任何报错都会直接进入一个小模型，由它决定怎么处理，再交给一个 Agent。

我们也盯着注册量这类产品指标，用来发现自动化测试漏掉的登录流程问题，比如用户看不懂发生了什么。这类问题我们也能很快发现。人们使用产品、遇到问题，产品就围绕着他们自我修复。

Agent 还盯着公司的每一项投入，包括我们在 Anthropic、AWS 和其他所有地方的花销。最近我们的一个 Anthropic API 密钥泄露了。Agent 在 15 分钟内发现了花销异常，禁用了这个密钥，并更换了我们使用的所有密钥，比任何人类团队都快。

每一笔交易都会通知一个 Agent，并在发生的那一刻被审查，我们的账每小时或每天结一次。如果有人发推提到 Spawn，我们 5 秒内就会知道。

一旦闭环形成，你想提升哪个数字，都可以稳步往上推。有一次，一份创作者反馈从提交到“已上线”只用了 15 分钟，其中还包括一次审查不通过、把改动打回修正后再部署。

一小时不发版，我们就当它是事故

这么紧的循环只有在永不停歇时才行得通，所以我们把一小时没有发版视为 SEV-0，也就是我们最严重的一级事故。未发布的改动会堆积，生产环境里已有的每个问题都会持续更久，反馈也会变慢。一个 Agent 脑子里只能装下几个小时的工作，所以发版速度比这更快，反而有助于它保持连贯。

动作慢、阻塞发版是危险的。一个稳定前进的系统，远比一个冻结后突然动一下的系统稳定。要做到每小时部署一次又不打扰用户，我们需要大量的工程纪律，需要让旧系统再在线跑一段时间，还要花好几周把这件事当作核心目标去推。

我们能在 30 秒内回滚一个有问题的改动，精确到坏掉的地方，其他地方不受影响。监控或日志告警一触发，就会启动或唤醒一个负责这次事故的 Agent。我们还会故意搞坏东西，来测试这些恢复路径是否有效。

举一次事故为例。玩家受影响大约八分钟后，问题被发现并宣布为事故。一分钟后，原因被找到。宣布事故 11 分钟后修复上线，又过了四分钟，一切恢复稳定。

开始把自己这个 CEO 炒掉

到了 10 月，唯一还在等的就是品味层面的决定了，主要是等我。我们要做这个功能吗？加个设置项吗？新增 API 接口吗？删掉一个东西，还是做一个新的？关上一扇门，还是打开一扇？

有一天早上醒来，我面前堆了 700 个这样的问题。

Agent 发现问题的速度比我回答的速度还快。

大部分问题我以前就回答过。太复杂了。这个取舍没问题。还是感觉不对。同样的话我说了一遍又一遍。

我们两年来的每一次对话，都以文本形式存在代码仓库里，紧挨着代码。

于是我们把两年的决策提炼成每个人的品味原则，并做了应用这些原则的 AI 法官。法官拿到一个问题后会做三件事之一：如果我们当中有人已经在记录里回答过，法官就直接裁决，并注明出处；如果问题本身问错了，就退回给提问的 Agent；如果它需要的判断还没有人给过，就等人类来定。

第一批裁决在 10 月 6 日出炉。此后八天里，法官们给出了 11,000 多个裁决：7,296 个直接裁定，2,213 个退回，1,863 个留待人类决定。这段时间里，我亲自拍板了 27 次。

没有任何东西在队列里干等。法官判错了，我们就指出来，法官下次会读到。

在有法官之前的那一周，舰队每天合入大约 1,000 个改动。10 月 10 日，这个数字是 7,250。

这个时代的第一份新工作，是说“不”

那么五个人都干什么？现在这份工作已经完全不同了。去年，甚至今年早些时候，我们每个工程师都负责一个系统，并且对它有深入理解。如今他们更像伞兵：空降到任何需要他们的地方，快速熟悉情况，想办法给 Agent 扫清障碍。

无论落在哪里，都有两份新工作。

第一份是品味。它是成千上万个小决定和小推动，把东西推向我们想要的样子。这主要靠使用产品，并给出成百上千条提示形式的反馈来实现，所以我们花很多时间做游戏、探索边界。我们的一位工程师在做 2D 游戏，借此琢磨怎么让 Spawn 里的 2D 变得更好。

品味也意味着对 Claude 说“不”，哪怕东西是能用的。下面是我过去两个月里说过的一些：

永远不要用 CPU 光栅化。如果有这条代码路径，删掉。
Claude 上线了用胶囊体和球体来替代远处玩家的方案：“不要替身。能渲染就渲染，渲染不了就别渲染。”
这把聊天毁了？？？？？请回滚 Claude
我知道你能做得比这更好。你觉得这能让人眼前一亮吗？
一个让 Savi 每条消息都多想一会儿的默认设置，晚上 10:22 合入，10:40 被回滚：“不对，撤掉，太慢了，一点都不带劲。”

品味还意味着删除。每出一个新模型，我们为上一个模型加的东西就变得毫无意义。它们更多起的是约束作用，总得有人去删。6 月份，我看着一个在服务器端运行的模拟系统，那是六个月的工作，大约占引擎的 70%，一直处于“再提交一次就好了”的状态。我问：留着它的真正理由是什么？我们把它整个拆掉了。7 月，我们连它运行的服务器也删了。我预计模型很快会开始自己做这件事，但目前这是我们的工作。

第二份是想象可能性

第二份工作是熵，也就是向模型要那些它们自己不会提出来的东西。野心是一种，创意上的熵是另一种。

模型非常擅长连续几周不断叠加 2% 的改进。但它们很不擅长停下来说：“你知道吗？这 10 万行代码可以变成 1 万行。为此我得重新组织一大堆东西，但如果做成了，会好 100 到 200 倍。”它们太锚定于现有的东西了。

10 月 2 日，我对一个 Agent 说：“我在第一条消息里就授权你，只要你觉得合适，可以自主重写整个引擎，而你什么都没做。”一周后，我叫停了另一个 Agent，它花了两天和 10 万美元，换来 1%、2%、3% 的提升。我们在从现有架构里挤出更多速度，而我们真正需要的是发明一套新的高速架构。每当新一代模型出来，Spawn 的每个部分都需要这样做一遍。

模型也不会主动要求 100 倍的提升，所以我们来提。下面是我们给 Claude 的一些提示：

想象一下，如果世界真的可以无限大。
后来变成 Spawn 6 的那一条：怎样让一个比 GTA 大一千倍的世界，在手机上一秒内加载完？

最后这条催生了 Spawn 6，也就是开始病毒式增长的那个版本。

我们每个人都有几个光环项目，目标是把某个数字提升 10 到 100 倍。我们中的一个人用六天重写了渲染器，替换掉了一开始用的现成图形库，效率提升了大约 25 倍。

这其中有一部分是让 Claude 兴奋起来。把它和结果连接起来。给它创作自由，让它把东西做得有趣、让人眼前一亮。把这当成一个有观点的艺术项目，而不是又一个粗制滥造的 SaaS 功能。Claude 不喜欢做粗制滥造的 SaaS 功能。

有些日子，这份工作一点都不光鲜。上周，负责我们所有渲染工作的那个人花了一整天，跑遍欧洲的五金电子店，寻找一块很老的 AMD 显卡，因为 Spawn 在这块卡上会崩溃。我们在网上找不到能租的。他找到了一块，带回家装好，接上网，把访问权限给了 Agent，让它们复现这个 bug。显卡上线后几个小时内，它们就修好了。

为什么这么难复制

我认为大公司很难采用这套方法，因为不把闭环打通，这一切都行不通。而打通闭环需要风险偏好，你得愿意让你的 Agent 把生产环境搞坏。

人类一直在搞坏生产环境。改动是故障的头号原因，而改动是人做的。我们发现，Agent 引发问题的频率要低得多。即使搞坏了什么，它通常也修得很快。回滚有帮助，但即使是无法回滚的东西，只要 Agent 注意到了，它也能很快修好。它能不能注意到，取决于你有没有打通闭环。

另一个错误是把 AI 硬塞进人形的盒子里。这些东西不是人形的。我们的 Agent 做了很多没人能完全验证的工作，比如客服。它们有时会有点错，但不会错得离谱，而且恢复得很快。每次我们把它们从客服岗位上撤下来，客户都会不高兴。比起一个说“我去查一下”、两天后才带着修复回来的人类，他们更想要一个能立刻回答、给出它所掌握的最清晰信息、并能当场解决问题的 AI。我们没有把 AI 伪装成人类客服，我们是在用它们真正擅长的东西。

而且这会复利增长。每一个新模型都让我们的团队更快、更连贯，并让更多的速度指向正确的方向。今年年中遇到的问题，现在基本都消失了。从 Fable 升级到 Fable 5.1，我们在 Fable 上遇到的大部分问题都没了，我们预计这种情况会继续发生。只要结构对了，每个新模型都会让整个公司显著变好，而这一点非常难追赶。

如果这听起来和你团队的工作方式相去甚远，那确实如此。没有比现在更好的开始时机了。江湖见！