构建 OpenCode：Dax Raad 访谈The Pragmatic Engineer

客观上，很多事情确实变容易了，但为什么我仍然和过去一样费脑子？我们的竞争对手也没有谁在碾压我们。我们就在 coding agent 领域，所有竞争者都非常投入 AI；按理说，这里应该迅速拉开巨大差距，但现实并没有。

社交媒体上有人说，24 到 29 岁的工程师会成为科技行业最有价值的资产，因为他们既有 AI 之前的原则，又有 AI 之后的速度。可这种预测往往是在说：“像我这样的人拥有全部优势，不像我的人拥有全部劣势。”大家只是在对自己念咒。面对巨大变化，人会用一种防御机制——非常自信地描述一个自己必然获胜的未来。你看到的很多预测，本质上都是这样。

Dax 过去十多年构建开发者工具、理解生态动力学的经历，对 OpenCode 帮助很大。他们很擅长选择一个临时的“坏人”，再联合对方的竞争者，把某件事向前推进。与此同时，也可能出现另一种结果：AI 编程工具让同样多的工作被完成，只是工程师因为工作更轻松而更快乐；但对许多公司来说，这还不够。

Dax Raad 是 OpenCode 联合创始人。OpenCode 是最受欢迎的开源 coding harness 之一，而 Dax 对 AI 的态度却相当克制。本期讨论 OpenCode 在不到一年内增长到接近一千万活跃用户、Dax 写给团队的备忘录——承认他们发布了太多功能、吸收了太多 hack，而且使用 AI 并没有帮助团队更快前进——以及为什么推理可能是当前科技行业利润最高的业务之一、为什么连 OpenCode 也被 GPU 供给卡住。

节目由 Antithesis 赞助，它用于在不依赖人工审查或传统集成测试的情况下验证系统正确性、减少故障。季播赞助商 turbopuffer 提供建立在对象存储之上的向量与全文搜索引擎。

2023 年的 RAG 往往是：用户提问，代码做 embedding，向量数据库返回 top-k，把结果塞进上下文，再由 LLM 回答。到了 2026 年，严肃的 agent 产品已经完全不同：一个人的 prompt 先交给编排 agent，再分发给多个子 agent；子 agent 分别访问向量索引、全文索引、文件系统，运行 CLI 命令，对 OLTP、OLAP 数据库执行 SQL，读写记忆系统，重排结果，循环并调用更多工具。一个 prompt 可能转化成几十乃至上百次、形态完全不同的搜索。

这意味着更复杂、更昂贵，也有更多扩展与性能问题。turbopuffer 以对象存储保证可靠性和扩展性，并用 NVMe SSD 智能缓存提高速度，定价目标是让 agent 大量搜索时不至于让账单失控。

Dax，欢迎来到节目。

谢谢邀请，也谢谢你专程来到迈阿密。

你正在构建最受欢迎的 AI 工程 harness 之一，OpenCode 明显加快了写代码和产出软件的速度。但你又说，仅有这些工具还不足以让我们得到更好的软件。为什么？

我一直说，最容易做的产品，是你自己会使用的产品。我们做 OpenCode，就是为了让自己的团队使用；我们就是产品的客户，每天都非常重度地使用它。它确实有用，也是工作流中的关键部分。

可过去困扰我的问题全都还在。我和过去一样努力，和过去一样挣扎。工作中很多部分变容易了，可这形成一种奇怪的并存：客观上事情更容易，为什么我仍然需要和过去一样认真思考？

很多亲自参与工作的 CEO、CTO 和创始人会觉得，过去最耗时的是编码；既然 AI 让编码更快，所有事情理应都更快。究竟是什么妨碍了团队更快、更好地交付高质量软件？

公司处在不同生命周期：有的还没有产品市场契合（PMF），有的刚刚获得 PMF——我们大概在这里——还有的已经拥有十年稳定的 PMF。AI 对这三类公司的作用完全不同。

在 PMF 之前，AI 对我帮助不算大，因为真正的问题是“我们应该做什么”。AI 也许能让你多挥几次棒，但我一直认为，多思考比多挥棒更好。许多想法和方向，可以通过自己认真思考、和团队深入讨论而提前排除；AI 不会加速这部分。

我们已经找到 PMF，接下来要兑现潜力。难点是方向太多：有显而易见可以做的事，有用户坚持要求的事，也有竞争对手正在做的事。现在很容易一一对应：遇到问题就 prompt agent；竞争对手有新功能就 prompt agent；用户有问题也 prompt agent。最后你会说：“我们发布了一千个功能，所以产品一定更好了。”实际上，它会变成一个糟糕的产品。

像弗兰肯斯坦一样。

对，完全不连贯。回头一看，你会发现有些东西根本不该发布。一个功能一旦发布，你几乎要永远支持它；“支持”不仅是维护它本身，未来每个新功能还可能和它交互。因此你仍然必须非常保守地决定什么可以进入产品，撤回一项已发布的东西非常困难。

能多发十倍的功能，不代表我们有十倍多值得发布的好想法。现在我的挣扎反而是：怎样让所有人慢下来？过去六个月，我们用了一种与以前很不同的方式运作，很多事情因此出了问题。现在我们正在往回拉，重新判断旧世界里哪些流程仍然有意义。

我绝不觉得我们因为更会用 AI 就在消灭所有竞争者。反过来，也没有任何竞争者因为 AI 用得太好，让我们失去竞争能力。我们处在最重视 AI 的 coding agent 领域；如果 AI 使用方式真的会立即造成巨大鸿沟，这里应该最明显，但现实并不存在那种差距。

那我们从头讲起。在 AI 和 OpenCode 之前，你是怎么进入技术和软件工程的？

是一个很典型的故事。我小时候就开始写程序，父亲是软件工程师，所以我比许多人更容易接触编程。高中毕业后我直接开始工作，也创办过公司。当时觉得自己很酷、知道自己在做什么；现在回头看，我其实什么都不懂。

那家公司后来以很小规模的 acqui-hire 结束，我因此进入了“真正的”科技行业。之后我做过咨询，又创办过几家公司，最近六年左右基本一直全职做开源。

我看到你早期做过 Minecraft 和 Minecraft 服务器。能回到那段经历吗？

Minecraft 当时有一个 modding framework，我不仅使用它做了很多 mod，也参与了框架本身。我并没有花很多时间玩游戏；真正吸引我的是创建有趣的沙盒。我经营过一个约有一百名玩家的服务器，会利用 mod 设计不同情境，观察人在特定规则下会如何行为。我觉得这非常迷人。

那需要写很多 Java。我当时还是编程新手，社区主要在 IRC 上交流，但里面有一些非常资深、很出色的程序员。他们似乎并不追逐职业成功，也许每天正式工作两小时，其他精力都投入 Minecraft 社区。他们很有才华，只是不想往上爬。我和他们交流、向他们学习，短短几个月得到的东西非常多。

后来你创过公司，也在 Ride Health 做过工程负责人。那大概是 2017 年、疫情之前。那段经历怎么样？

那是一家交通与医疗领域的公司。最初只有我和联合创始人，后来增长到约二十人。这算是我第二次正式创业，比之前走得更远，但最终有些灾难性。

不过我在那里认识了妻子。她是产品负责人，我是工程负责人，我们一年后开始交往。所以从这个角度看，它比一次创业退出更好。我也确实学到了很多。

当时团队几乎都是二十多岁的年轻人。创业文化有一种刻板印象：一群很年轻的人聚在一起就能创造奇迹。经历那家公司后，假如未来我要投资，我会非常谨慎地投资一个完全由年轻人组成的团队。我们的大脑还没有充分成熟，每个人又对不同事情感到不安全，这些情绪最终都表现为公司政治、冲突和戏剧。

所以，一群年轻人成功可能反而是例外？

对，当然有著名案例，但平均而言是例外。我自己感觉大脑大概到 26 岁才真正成熟。在那之前，我不确定自己是否适合运营一家创业公司。

你说的成熟，是更懂业务和职业关系，还是更广泛的变化？

创业公司非常亲密，也非常强烈。你和少数几个人一起工作，这件事既是工作，也是爱好，几乎是生活的全部。如果你还没有成熟，只是在向世界证明什么，或仍然被某些不安全感驱动，所有这些都会进入工作。在如此紧密的环境里，它会变成争吵、冲突，也会扭曲你对局势的理解。

更基础地说，是学会怎样做人、怎样生活。至少对很多男性来说，大脑真正安定需要一些时间。等它发生时，感觉像昼夜之别，我成了另一个人。现在回头看，会想：“天啊，我当时到底在做什么、在想什么？”

当时所有事情都被放大，比必要程度更强烈、更情绪化。认识那时的 Dax 的人，可能会惊讶你现在的样子。

可能会。不过我妻子就是那时认识我的，所以至少有些地方是对的。

你早期一直在很早期的创业公司做创始人或核心工程师，有没有考虑过去大型科技公司？

考虑过。那是 2010 年代早中期，大型科技公司极具声望。你遇到的每个人都想去顶级科技公司或热门独角兽，好像不走这条路就会在科技行业失败。我也受到这种吸引。

但我没有把自己组织好去完成那套准备。大厂招聘有高度结构化的流程，需要做特定类型的编程题，很多人会专门训练。虽然我认为自己是不错的程序员，有些面试甚至表现得还可以，但面对专门准备的人，随便去试几次很难拿到机会。

所以我不能漂亮地说“我主动选择不去大厂”。更准确地说，我不太可能凭当时的准备程度拿到 offer。我更喜欢真正把东西做出来，也更擅长实践性的问题；一旦离开这种环境，我就很难投入。

后来你是怎么转向开源的？Serverless Stack，也就是 SST，是你很重要的项目之一，它用于构建全栈应用，对吗？

对，那是我们最初的重点。Ride Health 那段经历以灾难结束后，我进入一家 B 轮创业公司。对当时的我来说，那是我待过最大的公司。我后来成为 director，也是第一次全职管理，没有活跃的编程任务。

我仍然很想写代码。每天有三四个小时的管理会议，除此以外，我会研究开源项目，也做一些自己并不怎么样的东西。那时我遇到刚发布几个月的 SST，是 Frank 和 Jay 创办的。我开始贡献代码。

他们从 YC 出来准备融资时，我投了一点钱；一个月后我加入团队，他们又把那笔钱以工资形式付给我，但我还要为工资缴税。所以一个小建议是：投资一家公司前，先确认自己不会马上加入它，否则这不是很好的资金使用方式。

之后你们还做了 OpenNext。

OpenNext 可能是最早让我们获得广泛关注的项目，但它并不是我们想做的。我们服务 AWS 生态用户，几乎每天都有人说：“喜欢你们的东西，但我们需要把 Next.js 部署到 AWS。”这个需求持续了一年。

我们不想做，因为自己并不是重度 Next.js 用户，而且这项工作非常琐碎。Next.js 是复杂框架，要在 AWS 上重建正确的基础设施，需要深入 JavaScript bundling、Next.js 内部机制，既费力又不有趣。所以我们让 Frank 把所有苦活做了。

从第一天起，我们的理想就是“这个项目最终不应该存在”。它只是生态里的一个缺口：Next.js 团队自然把更多注意力放在 Vercel，这不一定出于恶意。我们先填补空白，理想结局是 Vercel 或 Next.js 官方最终把跨平台适配做好，不再需要 OpenNext。

OpenNext 一度惹恼了 Vercel，但对需要部署到其他平台的用户很有价值。后来 Cloudflare、Netlify、Microsoft、Google 等也围绕 OpenNext 做适配。最终 Next.js 团队推动官方 adapters API，过去一两年双方变得更协作；OpenNext 的必要性也在逐渐下降。

OpenCode 又是怎么来的？这是很近的故事，大约从 2025 年夏天开始。

还不到一年。2025 年 2 月，我们正在努力让公司实现盈利。SST 已经有变现路径，但此前三四个月现金一直在减少。到 2 月时，我们只剩大约一个月现金，却也恰好在同一时刻达到盈亏平衡。奇怪的是，大家一直很平静，总觉得会有办法，最后也确实有了。

这给了我们喘息空间：既然技术上可以做任何事，我们真正想做什么？做开发者工具的人显然应该参与 AI 这个十年的浪潮。我们经历过很多技术浪潮：一个方向只要潜力巨大，就会天然吸引大量投资，而其中大部分投资必然不合理。于是人很容易看到热门领域里的荒谬部分，就说“这一切都没有意义，我不参与”。

可通常有少数东西非常有意义。你如果完全退出，就会错过它。我们看 AI 时也觉得大量东西很愚蠢，但真实价值显然存在，所以必须尝试。我们试过几个方向，有些甚至没有正式发布，因为做到一半就发现不成立。

后来团队开始使用 Claude Code。它是第一个真正留在我们工作流里的 AI 编程工具，直接解决了若干痛点。我们觉得它显然应该存在。随后我问自己：“为什么这不是我们做的？我们应该为此感到不舒服。”

凭借开源经验，我们意识到市场仍有位置。coding agent 已经不少，但没有谁明确占领“开源选项”这个地盘。开发者工具里，无论数据库还是编译器，开源选项最终往往会成为默认选择，这是极有价值的位置。

模型层也在激烈竞争。Claude 很受欢迎，但市场已经投入数十亿美元，OpenAI、开源模型阵营和其他厂商不会轻易让 Anthropic 独占。混乱之中，一个坚持开源、尽量兼容所有模型的中立工具非常有价值。我们的初始策略不是追逐每一条市场噪音，而是先牢牢占住“开源 coding agent”这一位置。之后增长数据非常疯狂。

你们在 2025 年 6 月发布。最初团队多大？用户增长如何？

当时只有三位联合创始人。后来一位朋友加入，帮我们构建最初版本，团队变成四个人。发布以后，我们又说服一位一直想合作的优秀设计师加入，那已经是秋天。

产品一发布，增长就比我们做过的任何东西都好。到 12 月，月活达到 65 万。我们此前说希望第二年初达到 100 万，所有人都觉得我们疯了。结果 1 月直接达到 250 万，从 65 万跳到 250 万；上个月约 650 万，这个月才过一半，可能接近 800 万。下一个里程碑是 1000 万。

从 12 月的 65 万到 1 月的 250 万，那个跃升是怎么发生的？是因为假期里大家突然意识到模型真的很强吗？

做 DevTools 久了，我们知道 1 月通常会反弹。人们在 12 月休假期间有时间学习新东西，所以一般会先在节日前下降，再在复工第一周大涨。但 OpenCode 在假期里仍然增长，这是我们其他产品从没见过的；人们不上班时，使用量反而创下新高。

到了 1 月，Anthropic 又“帮了我们很大忙”。他们想禁止用户在 OpenCode 里使用 Claude Code subscription。这件事迅速爆炸。我们几乎没有评论，用户群体自己就非常愤怒。Anthropic 无意间把自己和我们放进同一句话，而我们其实不配和一家规模大得多、成功得多的公司并列。那一周，这个叙事意外形成，把数据推得极高。

回头看，Anthropic 是在没有提前沟通的情况下，封锁 Claude Code 订阅在 OpenCode 里的使用。其他第三方工具也采取过类似接入方式，但 OpenCode 被阻止，最终引发集中愤怒。

一家公司为了商业可持续性做必要决定没有问题。问题是晚上九点突然上线一个 block，这等于主动创造一个“所有人同时讨厌你”的时刻。假如提前一个月分阶段沟通、给出预告，用户还是会不高兴，但不会形成如此集中的爆发。

这似乎也是 AI 速度陷阱的例子。实现一个 block 的 PR 可能只需要几秒或几分钟，执行者却未必思考了影响。

这也是高速增长公司的普遍问题：你会忘记自己突然拥有多大杠杆。一个很小的动作，现在会波及数百万人。我们也在经历。前几天我们发布了一个 bug：几乎所有人的终端都是 dark mode，OpenCode 却以 light mode 打开，等于给大量用户来了一次“闪光弹”。过去这个错误也许只影响一百个人，这次一周内影响了约一百万人。

当时 Opus 4.5 或 4.6 是最强的编程模型。Anthropic 突然封锁你们，而你们还不知道之后会出现如此大的舆论反弹。团队的第一反应是什么？只是保持冷静、继续前进吗？

奇怪的是，我们一直知道这一天迟早会来。真正发生时，大家反而很兴奋，因为我们已经想过很久。我们也知道，自己活在一个很特殊的 Twitter 泡沫里，那里似乎人人都有每月 200 美元的 Claude Max 订阅。

可当时我们已经有 65 万月活，不可能所有人都有 Claude Max。对普通人来说，每月为任何东西支付 200 美元都很夸张，所以这只影响用户中的一小部分。

更重要的是，事件发生前，我们已在和几乎所有其他公司谈判，让他们的订阅在 OpenCode 里获得官方支持。此前几周，Microsoft 已同意正式支持 GitHub Copilot，其他几家公司也在推进，只是我们还没公布。唯一尚未接触的大公司是 OpenAI。

那天晚上，我在 X 上被 tag 了大约一百次，所有人都说“他们封了、他们封了”。我想：“好，行动时间到了。”我给 OpenAI 发消息：“明天早上所有人醒来都会非常生 Anthropic 的气。你们可以采取相反立场，正式支持 OpenCode，获得一次巨大的公关胜利。”

第二天早上，OpenAI 确认愿意合作。与此同时，很多人说 Anthropic 封了 OpenCode，OpenCode 已经完了、价值归零。我在心里笑，只想让他们等到当天结束。我们完成并上线集成，在当天结束前宣布 OpenAI 正式支持 OpenCode。

这和 OpenNext 的经历一脉相承：我们很擅长选择一个临时的“坏人”，再联合它的所有竞争对手，推动一件事向前。Anthropic 不幸处在这个位置。因为其他模型厂商都在和 Anthropic 竞争，我们借机促使行业支持 OpenCode，也支持用户在不同工具中访问不同模型。小公司在这种局面里也能执行有效策略。

你过去十年做 DevTools、其中至少五年做开源，并理解生态中的动力关系，这显然帮助很大。你们不是临时赌运气，而是预先判断：市场有多个模型供应商，一个中立、开源的选择会有价值。Linux 本身是开源的，Red Hat、Canonical 等营利公司围绕发行版竞争，反而共同让生态变好。只要厂商按自己的利益行动，这个位置就成立。

对。定位正确以后，世界会不断把你没有预测到的胜利递过来。我们没有预见这次具体事件，但对自身位置的基本理解是正确的。只要存在中立方，那些投入数十亿美元的公司就会利用中立方推进自己的商业利益；成为中间的那个东西是有价值的。

现在 Codex 也加入了，把 OpenCode 看成提高品牌认知和使用量的机会。逻辑上，某个厂商假如未来赢得市场、成为领导者，也可能反过来说不再支持；但只要市场上仍有多个利益相关者，中立方就还有空间。

没错。也许某一天 OpenAI 会成为新的“坏人”，我们又要联合其他公司。这正是竞争为什么重要。人们有时低估了小公司的影响力：我们规模并不大，但只要在正确位置施加压力，就能让事情发生。

有人批评我们对 Anthropic 太刻薄，或不喜欢我们的处理方式。但对面是数十亿美元规模的大公司，小公司要促成任何改变都非常困难。现实中的竞争就是这个样子。

更多人能够访问这些模型、使用自己喜欢的工具，是件好事。你完全可以热爱 Claude Code、永远不打算换，但仍应支持其他人拥有选择权。

除了写出工具本身，OpenCode 为什么能成功？你们利用了 DevTools 领域的什么空白？

DevTools 最大的机会之一，是这里的从业者几乎都是程序员，而程序员通常很不擅长做 B2C 产品。他们没有意识到，开发者工具在很多情况下就是面向消费者的产品。

这里的 B2C 是 business-to-consumer。

对。最极端的思维方式是：把开发者工具当作 Instagram 或社交应用来发布。当然，top-down 的企业销售也可以成功；但那些真正大规模采用、最终成为行业标准的开发者工具，通常都是 bottom-up——单个开发者先使用、喜欢，再慢慢进入公司并向上扩散。

要做好 bottom-up，你必须像消费品公司一样思考，而程序员通常不擅长。我们非常重视用户第一次打开 OpenCode 时的感觉：它应该明显不同，也明显更好。为此，我们从零构建了 terminal rendering framework。Claude Code 和其他终端 coding agent 多半直接使用 Ink 或类似工具，做到够用即可；我们在最开始就投入了自己的框架。

用户也许觉得体验太强烈、产品不适合自己，但至少会离开时认为“做这个产品的人很有能力”。我们还努力让用户尽快开始 prompt，消除每一层摩擦，包括严格锁定的企业笔记本怎样运行 OpenCode。

OpenCode 最初五个月的 harness 其实并不出色，只是足够好，大多数用户感知不到明显差异。等我们先赢得足够份额，再回头把 harness 做得更聪明、更优化。其他团队认为必须先做出最聪明的 harness 才能获胜；我们反过来，用一个中等水平的 harness 成为使用量最大的产品，之后才有条件继续追上并争取同时做到最好。

从技术选择看，你们最初的桌面应用使用过 Tauri，对吗？

Tauri 是桌面应用那一部分。回头看，我们对桌面方向不够认真，主要是我们的错误。我本人非常喜欢终端，几乎所有工作都在终端里完成。但如果 OpenCode 接近 800 万月活，我不认为这 800 万人都应该使用终端。对于其中很多人，GUI 会提供更好的体验；某种意义上，我们的用户数量已经超过当前产品形态所适合的范围。

我们很早就知道未来可能走向 web app 或 desktop app，也做了实验。可惜方向判断是对的，执行却不够认真。我们没有足够快地推出，也没有深入考虑技术选择，只是随便选了一些东西。最终我们认为那是错误，现在又转回 Electron。

有些 AI coding harness 会在 GitHub 的 PR 或 commit 中标注“由某工具生成”，这几乎是免费营销。Claude Code、GitHub Copilot 都在做，OpenCode 却没有继续。为什么？

最初我们也有，因为最早的 OpenCode 基本是 Claude Code clone；Claude Code 做什么，我们就做什么，commit 里也会写“由 OpenCode 提交”。后来很多用户问能不能关闭。我认真想了一下，觉得这很俗、很无聊。

赌场会用所有小技巧把人困住，那是消费产品思维的极端版本。我们没有必要走到那一步。程序员看得出这是明显的 growth hack，也知道它为什么在那里。我不喜欢，所以没有仅仅提供一个关闭选项，而是默认把它关掉。

OpenCode 最终还是一家营利公司，需要赚钱。商业模式是什么？

基本有两条业务线。第一条来自降低 onboarding 摩擦。OpenCode 刚发布时，用户必须连接 Anthropic 或 OpenAI 账户；而当时新注册 Anthropic 账户甚至拿不到足够 rate limit，很多人根本无法正常使用。所以我们至少需要建立一个推理服务，让用户注册后就能访问各种模型和足够的额度。这个服务叫 OpenCode Zen。

Zen 最初只是为了让 onboarding 更顺滑，结果增长极快。随着开源模型流行，我们发现正确托管它们并不容易。前沿闭源模型的接口反而容易接，真正稀缺的是开源模型的高质量 inference。Zen 因而成为聚合优质模型和优质推理服务的地方。几个月前我们宣布，这项业务在五六个月内达到约 5000 万美元 run rate。

开源模型自己托管时，毛利也可以相当不错。

对，这部分增长非常快，超出我们的预期。第二条业务很无聊，但企业必须有：如果一家公司有一千名工程师使用 OpenCode，不可能让每个人自己下载、自己添加 API key。公司需要一个 control plane，统一设置 provider、权限、预算控制和 rate limit。

我们已经有这类产品，目前主要以企业部署形式提供，之后会公开。它也是开源的，但多数公司会为托管版本付费。企业规模使用 OpenCode 时，没有这类管理软件几乎无法落地。

现在企业终于开始认真查看 LLM 支出，问：“我们到底花了多少钱？真的因此多完成了工作吗？”这恰好发生在开源模型竞争力提高、价格便宜一个数量级的时候。企业需要 control plane，我们顺带给它们提供其他模型的 inference，它们会自然开始使用。假如推理最终成为主要业务，我们甚至可能不再单独为 control plane 收费，只通过 inference 收费。

企业落地还需要 SSO、权限、OAuth、SCIM 和细粒度授权。季播赞助商 WorkOS 提供这些基础能力，Anthropic、OpenAI、Cursor、Perplexity 等公司使用其服务。

节目也再次提到 Antithesis。团队需要“慢下来才能更快”，不仅要想清楚做什么，还要把质量当作目的地的一部分。Antithesis 是 property-based testing 平台，允许团队描述系统应满足的属性，再在接近生产混沌的环境中验证这些属性是否成立。

你最近发帖说 inference 其实非常赚钱。很多软件工程师只是调用模型，不做推理基础设施，会直觉认为这一定是一门很艰难的生意。它为什么能赚钱？你看到了什么？

要把一家 AI 公司的不同部分拆开。只看纯 inference，成本的理论下限是电费。购买硬件有资本支出，但硬件一旦到位，生成一个 token 的最低边际成本，就是驱动它所需的电力。当然还要加数据中心基础设施、运维人员等成本。

我们会大规模租 GPU 来运行模型，而且中间仍然有服务商，并没有下沉到成本最底层。即便如此，有些模型的标价与我们的实际成本之间，仍然能看到大约 80% 的 margin。

还有一件事常被忽略：价格其实上涨了，只是表面上看不明显。以前大家默认使用 Sonnet，因为 Opus 太贵；后来 Opus 价格下降，用户开始把 Opus 当默认模型，但它仍然比 Sonnet 贵得多。用户实际默认消费的模型价格提高了，而托管模型的成本并没有同步提高，所以利润空间扩大。

Anthropic、OpenAI 还有极大规模，也签了最大的 GPU 合同。在当前价格下，我不会惊讶它们的 inference margin 接近 90%。我不认为这种毛利长期可防守，实在太高，而且经过这项业务的资金规模也非常大。

Brian Cantrill 上节目时提过类似的云计算往事。早年 AWS 不公开具体财务，市场以为云业务非常惨烈、到处“血流成河”；真正亲手做过云的人却发现它非常赚钱。Amazon 或其他厂商没有动力告诉所有人，这项业务其实在印钱。

任何被热炒的业务都会伴随负面情绪，厂商也没有动力纠正。问题确实复杂：训练费用巨大，研发部门也非常昂贵；但从长期看，纯 inference 作为一项业务是成立的，我认为它一直都会成立。

你还公开说过：“GPU 刚好处在不够用的状态。连我们这种规模的公司都会被它卡住，太疯狂了。”这是什么意思？

整个 GPU 栈都非常紧，从 GPU 生产、配套硬件到劳动力无一例外。推理需求正在增长，我怀疑不是线性增长，甚至接近指数增长；但 GPU 产能无法指数增长，它更接近线性过程。当两条曲线交叉，供给必然收紧。

对我们来说，需要提前预留 GPU，并支付大量预付款。每个人都预期紧张会持续，所以都在囤积。获得 inference capacity 非常困难。

另一个夸张之处是：看到一家 AI 创业公司融资 20 亿美元，人们会觉得这是天文数字；但 Amazon、Meta、Microsoft、Google 等大科技公司一年投入的是数百亿美元，完全碾压创业公司。供应链里的公司也不愿意和小客户谈，因为它们正忙着争取这些巨头的订单。大公司几乎把所有供给都吸走了。

我认为问题最终会缓解。职业生涯里每次看到短缺，都会先经历一段紧张期，然后被疯狂的过剩供给解决。这一次也许不同，但通常事情如此发展。只是此刻确实非常紧。

你有一条被大量引用的推文，批评大家谈 AI 生产率时，好像软件团队此前已经达到效率巅峰，唯一瓶颈只是“产出代码的能力”。现实里，组织是否有好想法、员工怎样使用省下的精力，都很关键。你能展开吗？

软件工程行业极其庞大，几乎每家公司都以某种形式雇用软件工程师。大多数工作环境并不是最令人兴奋、最能激发动力的地方。很多人只是想完成工作，回家陪孩子，过合理的生活。

给他们一个能更快完成工作的按钮，最自然的行为就是反复按按钮，完成和过去相同数量的工作，再把省下来的时间留给自己。这完全合理。如果一个人没有理由额外投入，他不会主动把全部效率收益都交给组织。

所以，工具也许提高了个人效率，但公司必须现实地问：员工会在哪里兑现这份收益？有些公司当然不同——员工很有动力，薪酬与结果也更匹配——但多数公司不是这样。

这类环境里往往有少数“非理性地在乎质量”的人。即使其他人动力不足，他们仍会推动大家把事情做好。现在，这些人被海量草率的 AI PR 淹没。我们团队里有些人就来自这种公司：他们曾经是“那个仍然在乎的人”，其他人只是按按钮完成任务，结果他们每天在垃圾代码里挣扎，最终耗尽并离开。

动机、团队、人、情绪，这些因素并没有因为 AI 消失。

公司是否需要重新设计激励和薪酬？一个很有动力的工程师用 AI 产出更多，而且方向正确，可能创造更多业务价值；但这也消耗大量精力。薪水完全不变时，他为什么要这样做？

对我们这种创业公司容易一些。领域令人兴奋，加入的人竞争心很强，想赢；所有人也持有股权，公司成功会对他们有实质意义。

即使在 AI 之前，我看到创业公司发布两个普通薪资的工程师职位时，也会想：为什么不把两份薪水合起来，雇一个能真正改变公司方向的人？我们不需要一千人，只需要二十个很强的人。所以好薪水仍然非常有效，我们一直愿意付得更多。

可到了大公司规模，问题很难解决。公司达到某种体量后，员工确实没有充分理由做超出岗位严格要求的事情。我没有神奇答案。

也许旧组织很难直接装上新技术。AI 原生创业公司的工作流、角色会怎样变化？软件工程师不只是 prompt AI 写代码；产品判断、组织流程以及其他工作怎么办？

真正的瓶颈还在那里：你仍然要弄清楚应该做什么。团队可能花一年时间才找到正确方向；一旦方向确定，实际构建也许确实更快。

我开过一个玩笑：AI 之前，我花 95% 的精力思考该做什么，5% 的精力真正去做；现在我花 96% 的精力思考该做什么，4% 的精力真正去做。技术上看，执行部分改善了 20%，但每天的感受仍然和过去一样困难。

你还观察到，许多公司的 CFO 开始问：“每个工程师每月额外花 2000 美元是什么意思？”OpenCode 在企业中使用，你听到了什么？

每种新技术都会经历一个炫耀阶段。现在很多公司想显得自己面向未来、流程领先，仿佛竞争者永远追不上，于是开始夸耀支出：“每位工程师每月花一万美元也完全值得，因为我们的业务足够成功、高效，任何金额都值得。”其中很多是表演，会消失。

但真实问题也存在：一家有几千名工程师的公司，每人每月多花 1000 美元，就会彻底打穿预算。这不是可以随手决定的支出。现在只是临时实验期，所有人都在探索什么可能、什么真正有价值。我怀疑当前支出水平不可持续，尤其当公司无法指出明确业务结果时。

存在一种可能：AI coding tools 最终让同样多的工作被完成，只是工程师更快乐，因为工作更轻松。对很多公司来说，这不够好，它们可能会说：“那就回去手写代码吧。”

但也有反向压力。假如所有竞争对手都提供最好的工具，而你为了省钱取消，最好的工程师可能离开。CTO 会觉得，一家自称顶尖的公司如果只允许用基础版 Copilot，不允许 OpenCode 或其他先进工具，会显得很可笑。

这是真实风险。对于机会无限的优秀人才，强迫他每天使用一个讨厌的工具——比如 Jira——都可能让他辞职；我认识真的因此离开的人。工具体验一直是人才市场中的变量。

不过这种压力主要发生在人才市场顶端。

对。OpenCode 的规模让我们看到，世界比科技圈日常讨论的大得多。我们平时所在的圈子其实很小。对大量公司来说，实际方案可能只是使用 Copilot，把它接进 OpenCode，额度用完就结束。外界有一种叙事，说这些公司会因为跟不上 AI 而死掉；我不认为现实会如此简单。

你写给 OpenCode 团队的一篇长文很受关注。你说团队面临三个挑战，它们并不新，但被 LLM 极大放大：第一，发布不值得发布的功能；第二，迭代功能时，原始设计不匹配，于是吸收 hack，而 LLM 又能继续处理 hack 带来的问题；第三，需要投入更多时间清理。你是怎样得到这些观察的？团队怎样回应？

第一项最直接。现在太容易用“再发布一个功能”回应任何问题，所以必须更克制。我们开始更明确地讨论：哪些类型的东西值得立即发布，哪些应该等待，直到我们对问题有更清晰的理解。

第二项可能是最大挑战。工程里一直有这种情况：系统已经承担很多职责，你要加入一个它原本不支持的新功能。你有两个选择——从第一性原理重新思考并重构系统，让新功能自然成立；或者暂时吸收一个 hack。过去会根据 hack 有多糟、这个功能对公司多重要来做判断。

现在这种判断能力被严重扭曲，因为 agent 会替你完成 hack，也会继续替你处理 hack 之后产生的问题。人很容易说：“这只是临时修复。”于是我们在本该重新设计、重构系统的地方，吸收了更多 hack。不是工具做不到更好的设计，而是我们的判断偏了。

AI 之前，我亲手写一个 hack 时，知道自己在写 hack，会思考，也会感到一点刺痛。第二次再写时，我会想起第一次，感觉更糟。因为有经验的人知道，自己是在给别人甚至未来的自己埋地雷。agent 没有感觉，也不会主动说“我正在写一个 hack”，只是沿着训练数据继续生成。

完全正确。那种刺痛感被静音了。好像你把问题交给另一个人处理；问题仍然存在，地雷以后仍会爆炸，但今天你感受不到那种不舒服，于是判断被扭曲，也失去了反馈循环。

这像一个把所有事情都委派出去的 CEO，不理解一线为什么如此糟糕；直到有一天亲自下场，才发现工作条件已经恶化。

对。hands-on 的 CEO 或 CTO 会刻意回到实际环境里编码，感受痛点。就像你必须使用自己的产品、感受用户的痛，也必须感受代码库给工程师带来的痛。人生很多事情都取决于正确的反馈循环，而这些循环很容易消失。

第三项是清理。你既是创始人，公司刚找到 PMF，每天都承受快速增长的压力；清理不会立刻带来更多收入或用户喜爱。你怎样合理化它？

这很难。每天醒来，都有上千个人告诉我们应该做什么，也有上千个人说我们什么都做错了；每天还有新的竞争产品出现，刺激非常强。假如我们只是被这些力量拉着走，结果不会好。

好的一面是，清理也比以往容易。过去发现一种更好的代码模式后，往往只能在新代码里采用，因为改造全部旧代码工作量太大；现在可以让 agent 在整个代码库里落实新模式。清理技术债、替换陈旧模式、跨代码库重构，都更容易。

清理确实没有直接结果。你完全可以不做这些，仍然成为一家成功公司。但成功公司有很多种；假如世界上所有成功公司都允许你选择工作地点，你大概不会选择其中 99%。我想构建的是五年后我们仍愿意工作的地方——每天工作时感觉良好，而不是一个充满遗留系统、优秀的人不愿加入、留下的人只能不断苦熬的公司。

你在备忘录里还写了一句很重要的话：“最糟的是，我不认为我们用这些代价换来了更快的速度；我认为我们只是在以正常速度前进。”

对。感觉上我们很快，但回头看，我不确定我们真的有那么快。我们不比竞争对手慢，但也肯定没有比他们快。衡量生产率时，人很容易欺骗自己，以为自己变得更高效；真正坐下来检查结果，通常没有想象中夸张。

所以不是消极地拒绝 AI，而是保持批判性：它真的有效吗？是否应该先慢下来，关注不可见的基础，再获得未来的速度？

我很相信大量准备和打好基础。真正需要冲刺时，建立在扎实基础上的爆发力，会远强于过早强迫自己冲刺。

我喜欢你的一点，是你会指出社交媒体上流行叙事中的胡扯。接下来这条推文曾经非常火。

推文说：“24 到 29 岁的工程师很快会成为科技行业最有价值的资产，因为他们同时拥有 pre-AI principles 和 post-AI speed，这是不可战胜的组合。”很多 VC 说这就是未来。你为什么认为它是 BS？

我只是太累了。每天醒来打开 feed，都是一条接一条的预测：“未来会这样”“某种人会那样”。大家都在编故事。

那条推文是最典型的格式：“像我这样的人拥有全部优势，不像我的人拥有全部劣势。”每个人都在对自己念咒。

根本背景是，我们正经历巨大变化，所有人都对自己在变化中的位置感到紧张。一种防御机制，就是非常自信地断言一个自己会成为赢家的未来。你几乎可以把每一条预测追溯到这里：像我的公司会成功，其他公司会失败；我的工作不会被 AI 取代，别人的工作会被取代。

每个人都有一套听起来理性的解释，但底层是恐惧、担忧和不确定。我们被预测轰炸，人们也借预测保护自己的心理。我已经厌倦了预测。我们确实处在巨大变化中，但我更关注今天能做什么、明天能做什么。一年前我不知道自己会做 OpenCode，一年后也不知道会做什么；我只想做眼下最有意义的事。

年轻人有优势，这从来如此：他们精力更多；经典劣势则是经验较少。我经验更多，但没有二十岁的人那么多精力。这仍然是过去一直存在的交换。

那条推文尤其好笑，因为它精确写“24 到 29 岁”。为什么不是 18 到 25 岁？显然发帖人自己就在那个年龄段，所以才挑了这个范围。它就是编出来的。大家只是紧张、担心。

诚实承认这一点很好。我也会紧张，因为变化确实比以前更快。Kent Beck、Martin Fowler、Grady Booch 等经历过行业大转变的人说，他们见过从大型机到微处理器这类变化，但往往跨越十年，而不是一两年。

变化速度更快，但仍然很难预测。事后看，一切都会被重写成“早就显而易见”；实际上并不明显。最终发生的事常常反直觉。确实有人能看得更准、提前站到正确位置，但最“显然”的结果往往不会发生。未来从今天看会非常奇怪，到了未来再回头，又会显得完全合理。

预测比人们以为的困难得多。回到 OpenCode：团队已经获得很大成功。哪些产品与工程原则从早期到现在没有改变，并帮助了 OpenCode？

产品侧的原则其实很简单：一个产品通常只有一个真正好的核心想法，你要让用户尽快体验到它。

听起来容易，但你去试用大量产品，会发现从用户听说产品到真正感受到价值之间，被无意加入了很多步骤。把这条路径保持得极短非常困难，而且摩擦会不断悄悄回来。

我有一个命令，会启动全新的 Docker container，再运行 OpenCode，让我重新体验第一次使用的流程。我大约每两周做一次，每次都能发现团队无意间破坏的东西。

产品工作不是收到一个问题，就发布一个最直接的解法；而是吸收所有问题，再发现一个解法可以同时解决五十个问题。这很难，需要经验、思考、与用户和团队交流，也需要理解代码库。产品是把许多具体问题抽象成一个解决方案。这项能力可以无限提高。我以前很差，现在勉强还可以，未来几十年仍会继续学习。

我关心的是怎样真正解决问题，而 AI 在这件事上几乎一点忙都没有帮到我。

那什么帮助你形成更好的 product sense？你强调思考、反思，以及用一个优雅方案解决多个看似不相关的问题。

是多年处在正确反馈循环里的经验。我搞砸事情时，会有真实的人来骂我；设计得不好时，我自己要在代码库里艰难地完成一件本该很容易的事。痛苦会直接回到我身上。

我们非常重视让团队每个人都暴露在这些反馈循环里，没有人被隔离。人在这种环境里待几个月，就会进步很多。公司变大以后，很难继续维持，甚至可能不可能；如果一个人主要在大公司工作，也许从未真正经历过这种直接反馈。

我见过产品团队为了更快发布而削减工作，代价却由客服承担：客服面对愤怒用户、手工修复问题，工程和产品团队只觉得“功能已经上线”，看不到自己创造的副作用。只有让决策者真正处在反馈回路里，能力才会提高。

另一个影响是努力为整个市场构建产品。不是所有人都必须追求百万用户，但这种视角非常有意思：你要让产品适应无数环境、用户、工作流、偏好和限制。当目标是整个市场时，你关注的事情在旁观者看来往往完全不合理，他们会觉得你把精力放错了地方；但你的思考方式确实会改变。

OpenCode 团队现在怎样工作？团队多大？能否以最近一个功能为例，讲讲从构建到获得反馈的过程？

我们还在摸索，因为最近增长很快，现在有二十多人，而且主要是在过去三个月增加的。我们处在一个很糟糕的阶段：人数比以往更多，速度却比以往更慢，因为新人仍在熟悉情况。我们希望尽快穿过这段时期。

作为开源公司，代码本来就是公开的，所以我们尽量公开构建。一个新东西要从零开始存在，最痛苦的是把它推上山的第一阶段。到了某个节点，它还远没有完成，但关键问题大都已经解决，剩下更多是补充细节。

团队会努力尽快把项目从第一阶段推到第二阶段。我们通常设定一个“可以向外展示的 demo”作为里程碑，先尽快到达那里。

一旦基础存在，用户大致理解功能是什么，后面就容易很多。用户会告诉我们还缺什么、在哪些环境不能运行、哪些地方很糟。反馈循环开始后，功能会持续变好。

负责功能的人会经历完整周期。不存在另一个人负责接收反馈、总结后再交给工程师；工程师自己查看 GitHub issues、X 上的回复，自己理解后续路线图。

创始人的职责之一，是确保整个团队理解我们关心的全部背景：市场、竞争对手、我们的定位和目标。如果他们真正理解上下文，就会自然形成自己的优先级判断。

动机对我们非常重要。既然这是长期游戏，策略就应该是怎样留在游戏里最久；唯一办法是每天都做让自己兴奋的事。团队成员会主动抓住自己最想解决、认为最伤害公司的问题。假如我们提供了足够上下文，他们通常能做出不错判断。

有时团队很想做一件事，我会明确反对，说“不应该做”。几周后却发现他们是对的，我错了。看到团队开始拥有这种独立判断力，非常令人兴奋。

我们还没谈“品味”（taste）。很多人认为 AI 很难拥有 taste，而工程师需要 taste 或 product sense。你怎么看这个概念？

taste 是有意义的概念。好的想法通常很简单，所以会被很多人重复；但简单的好想法非常难真正活出来。品味可以学习，却是一辈子的训练。

根本问题是：你嘴上说 taste 重要，但真的相信产品必须好吗？现在有很多声音说，代码不必好、产品不必好、任何东西都不必好，只要其他指标成立。人们会指向那些产品很差、工程很差，却仍赚很多钱的公司，说这些东西都不重要。

这种念头一旦进入脑子，你就很难做出好产品，因为你根本不相信好产品有必要。真正公开相信 craft 很重要、愿意把产品做到“非理性地好”的人并不多。

很多伟大产品即使差 50%，也许短期业务数据不会明显变化；但质量会通过难以直接量化的方式显现。一个地方开始偷懒，懒惰会像感染一样扩散到其他地方。

所以我对 taste 的问题是：“你真的相信吗？”说自己真正在乎好产品，是非常高的门槛。我个人极其在乎，但离自己的标准还远得很。你听我讲这些，再使用产品，也许会觉得产品没有达到我说的标准，那是因为我仍在努力变好。

我仍然会被优秀产品激励，也有一些敬佩的人和团队。我知道自己还有很长的路。

在开发者工具领域，你敬佩哪些人或产品？

Mitchell Hashimoto 是最明显的例子。我们希望公司在某些方面像 HashiCorp：产品开源，被大规模采用，Terraform 这样的工具成为默认选择。那需要在微观细节、宏观策略和商业模式上都执行得很好。

他后来做 Ghostty 也很出色，架构关心每个细节，使用产品时能感受到。他同时是很强的产品人。他表达过一个和我们刚才类似的观点：发布一个功能，不只是功能本身，而是它与所有已有功能如何交互；产品人的工作，就是把这些关系理顺。他在这方面非常强，也是极好的程序员。

我们谈 taste 时不断谈到质量。对抗巨头时，质量是不是创业公司、小公司最后还能抓住的少数优势之一？

是。反面则是，现在让产品腐烂比以往更容易。agent 工作流让大公司产品腐烂得更快，创业公司也一样。现在一个产品如果一年没有认真维护，可能已经开始变坏。

我仍然相信质量是巨大的差异化，但它不是宣布“我们要质量”就能实现。质量必须出现在公司的每个方面，来自许多看似不理性的选择：你做很多事，其中可能有 50% 短期看根本不必做。很少有人愿意这样运作。

今天的软件和产品有一种冷冰冰的理性：“我是商业人士，只做高度理性的事情。”很多人以为这就是懂商业。当然，这种方式也可能成功；但质量仍然是巨大差异化。

OpenCode 刚发布时，Claude Code 是唯一真正的对手。我们早期的重要区别之一，就是终端体验明显更好。我们花大量时间自建 terminal framework，而自建框架通常是工程团队首先被告诫不要做的事。

那是非理性的。

对，非常非理性。但我们研究后发现，现有方案做不到想要的体验。我们自己就是终端工具用户，也看到 Neovim 等工具能做到什么。Mitchell 也一直推动终端体验的上限。一旦知道什么是可能的，就很难接受一个没有把能力推到极限的产品。

OpenCode 早期获得关注，一个原因就是用户把它和 Claude Code 对比：Claude Code 会闪烁、显得更 janky。Claude Code 仍然是巨大成功的产品，这些问题并没有阻止它成功；但我们对某些质量细节的非理性投入，确实帮助一个很小、资源少得多的团队对抗巨头。

你的工作设置是什么？

我现在换成了 Framework desktop，就是正面那些小模块可以替换的机器。系统运行 Arch Linux，使用一台 5K 显示器。我使用 tiling window manager，已经用了大约十年。麦克风是 SM7B，摄像头用 iPhone，物理桌面大致就是这些。

你当然主要使用终端，OpenCode 也是终端工具。

实际设置还复杂一点。刚才说的是物理机器，但真正工作都在远程机器上。我通过 SSH 连接一台性能强得多的电脑，上面开着多个 tmux session，每个项目一个。编辑器是 Neovim，通常屏幕左右分割：左边 Neovim，右边 OpenCode，我在两边来回切换。所以核心就是 Arch、Neovim、OpenCode。

AI 之后，工程领导力发生了什么变化？你做过工程师、创始工程师和团队负责人，现在也在领导团队，并与很多 CTO 交流。领导者是否变得更 hands-on？这一定是好事吗？

我听到一种说法，一方面有道理，另一方面我还不完全确定。团队开始问：“如果工程师不再亲手写所有代码，角色是什么？”答案可能是：让代码能够被安全发布。

工程师要建立 guardrails，让另一个人 prompt agent 做改动时不引入 bug。测试体系要可靠，代码库要有清晰约定和模式，让 agent 可以遵循，而不是生成非常离谱的结构。角色变成：怎样让使用 agent 的人近似盲目地提交改动，结果仍然足够好。这个人可能是工程师，也可能是想修改网站的市场同事。

大家把这当作全新的工程组织方式，可它其实一点也不新。我们一直在解决同一个问题：怎样让 junior engineer 安全提交代码、不破坏系统？怎样在代码库里建立模式？怎样设计测试？

我当然希望雇一百名初级工程师，他们都能有效工作，但现实存在上限。过去有些公司部分解决了，有些没有。问题始终是：怎样让经验较少的人发挥超出资历的能力。现在“经验较少的人”可能是 coding agent，也可能是设计师或市场人员。

因此，旧问题全都回来了：怎样让代码库易于工作、可扩展，并能适应新要求。许多旧模式也在回归。我们一直采用 domain-driven design，只是过去用得比较轻；现在用得更重，因为那些有点无聊、有企业味的模式突然非常有用。

coding agent 就是一群白痴，而且它们会全天候工作。它们会提交大量东西，所以你需要比以前更多护栏。

过去讨厌某些模式，是因为它们太冗长。它们确实能产生可靠、模块化、安全的代码，但亲手输入非常烦。现在不再由人逐字输入，就能获得模式的好处，而不必承担同样多的缺点。我们开始重新探索并享受这些结构。

也许 design patterns 会回归。2000 年代它们非常流行，用结构帮助 junior engineer 不犯错，后来大家因为太冗长而抛弃。

好程序员以前不一定需要那些训练轮；但现在 agent 没有训练轮，所以必须把它们装回来。

对已经很有经验、希望保持竞争力，并拥有在 OpenCode 这类公司工作能力的工程师，你有什么建议？

我很难给普适建议，因为我的工作环境非常特殊。首先它是创业公司，天然有点奇怪；其次我们做真正的开源公司，而这种公司也许只有少数几家。我们的工作方式和招聘对象未必适用于所有人。

我能给出的建议，在 AI 之前就一直相信：软件工程是一项可以应用到任何行业的能力。只成为很好的软件工程师，也能拥有不错职业；但如果你同时成为某个具体行业的专家，那会是一个致命组合。

随便举例，农业。假如你非常了解农业，同时也是不错的软件工程师，你可能就是全球这个组合里排名前十的人，整个行业都会想雇你。

软件工程师的好处是，不必一辈子锁定一个行业。其他人也许决定终身做医疗；你可以用十年在医疗科技里成为专家，发现不喜欢后，再去完全不同的行业重新成为专家。这非常令人兴奋。

软件工程师通常有好奇心，深入学习一个行业本身也很有趣。最终你会找到真正契合的领域。好工程师加行业专家，很容易成为独角兽型人才。

软件无处不在，每个行业都会缺少真正对本行业好奇的软件工程师。

而且不用太久。在任何行业认真待一年，你可能已经比 99% 的人更了解它。关键是不要关闭理解业务的那部分大脑，只把自己当成“接到一个任务、在 UI 加点东西”的人。

作为软件工程师，你有机会进入世界上任何公司、学习几乎任何事情，应该充分利用这种机会。从纯职业策略看，这也是非常理性的选择。

作为结尾，有没有书籍或阅读推荐，曾经改变你的思考？

有意思的是，我几乎不读书。不过我妻子非常爱读，我能从中获益：她读完所有书，把其中的好想法告诉我，然后我再把它们复述得像是自己的想法、好像自己读过一样。

我早些时候确实经历过一个大量阅读的阶段，帮助我理解世界如何运转。推荐很普通，但我很喜欢 Nassim Nicholas Taleb 的一些作品。他大概有少数几个极好的核心想法；一本书往往只是把一个好想法膨胀成整本书，所以完整读完未必轻松，但那些想法是宇宙中非常基础、真实、到处都会出现的东西。

我很喜欢《Skin in the Game》，《The Black Swan》当然也非常著名。对我影响很大的是 emergent properties，也就是涌现属性。

世界上几乎所有伟大的东西，都不是自上而下设计出来的，而是许多较小实体一起运作、随机互动，最后涌现出某种伟大结果。健壮的软件、伟大的城市、可步行的社区，以及能够抵抗疾病的生物体，都体现了这种模式。

关于自下而上与自上而下的系统设计，有几本书会谈到；Taleb 的作品是其中之一。一旦理解这些思想，你会发现它们几乎支撑着整个世界，在哪里都能看到。

Dax，非常感谢这次对话，很有意思。

我也很开心，谢谢邀请。

Dax 处在一个罕见位置。他正在构建增长最快的 AI coding tool 之一，OpenCode 几个月内从 65 万月活增长到接近 800 万；但他同时又是那个提醒大家慢下来的人。

我尤其喜欢他所说的“被静音的刺痛感”。AI 之前，当你写一个 hack，你知道自己正在写 hack，会感到一点不舒服，下次再做时还会记得。那种感觉让判断力保持锋利。AI agent 之后，感觉消失了，好像另一个人在承担后果；地雷仍在那里，只是今天不会炸在你身上。我们甚至没有注意到 agent 正在放下多少地雷。

我也很欣赏 Dax 给团队的备忘录。他承认：“我们正在发布不该发布的功能，吸收太多 hack，而最糟的是，我们甚至没有更快，只是感觉更快。”一家热门 AI 原生创业公司的创始人愿意公开说这些，需要勇气，也为许多工程团队提供了必要的现实检验。

感谢收听。欢迎在常用播客平台或 YouTube 订阅；评分和评论也会帮助节目。下期再见。