---
id: "1VqKUrxR2C8"
title: "构建 OpenCode：Dax Raad 访谈"
channel: "The Pragmatic Engineer"
host: ["The Pragmatic Engineer 主持人"]
guests: ["Dax Raad"]
date: "2026-05-27"
updated: "2026-07-29"
duration: "1:21:01"
duration_seconds: 4861
source_type: "youtube"
youtube: "https://www.youtube.com/watch?v=1VqKUrxR2C8"
canonical: "https://pod-exp.pages.dev/1VqKUrxR2C8/"
transcript_jsonl: "https://pod-exp.pages.dev/1VqKUrxR2C8/transcript.jsonl"
language: "zh-CN"
translation: true
translated_from: "en"
timestamp_precision: "block"
topics: ["人工智能","AI 编程","产品"]
series: ["OpenCode"]
---

# 构建 OpenCode：Dax Raad 访谈

> 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。

**内容提要：** OpenCode 在不到一年里从约 65 万月活增长到接近 800 万月活，成为增长最快的开源 AI 编程工具之一。Dax Raad 讲述了团队如何从 SST、OpenNext 的开源经验出发，抢占“中立、开源、兼容多模型”的位置，并把 Anthropic 封锁 Claude Code 订阅接入的危机转化为与 OpenAI 等厂商合作的增长机会。更重要的是，他对 AI 提升工程效率保持克制：代码执行更快，不代表产品判断、团队激励、架构质量和反馈循环也会自动改善。AI 既能加速清理，也能让团队更轻易地发布不该发布的功能、吸收更多 hack，并失去亲手写坏代码时那种提醒判断力的“刺痛感”。

## [0:01] 片头、赞助说明与核心问题

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-01> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=1s>

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

**Dax（片头摘录）：** 社交媒体上有人说，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，欢迎来到节目。

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

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

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

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

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

## [4:38] AI 为什么没有自动让团队更快

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-02> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=278s>

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

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

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

**主持人：** 像弗兰肯斯坦一样。

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

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

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

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

## [7:04] Dax 如何进入技术行业

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-03> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=424s>

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

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

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

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

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

## [9:04] 早期创业、年轻团队与成熟

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-04> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=544s>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## [13:08] 为什么没有进入大厂

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-05> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=788s>

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

## [13:16] 转向开源、SST 与 OpenNext

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-06> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=796s>

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

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

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

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

**主持人：** 之后你们还做了 OpenNext。

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

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

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

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

## [16:14] OpenCode 的起点与开源定位

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-07> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=974s>

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

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

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

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

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

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

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

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

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

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

## [20:40] 用户增长与 Anthropic 事件前夜

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-08> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=1240s>

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

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

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

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

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

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

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

## [23:20] 封锁发生后，如何联合模型厂商

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-09> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=1400s>

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

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

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

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

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

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

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

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

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

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

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

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

## [27:44] DevTools 为什么也是消费产品

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-10> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=1664s>

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

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

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

**主持人：** 这里的 B2C 是 business-to-consumer。

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

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

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

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

## [30:34] 从终端走向 GUI

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-11> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=1834s>

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

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

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

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

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

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

## [32:34] OpenCode 的两条商业化路径

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-12> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=1954s>

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

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

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

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

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

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

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

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

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

## [36:35] 为什么纯推理业务毛利很高

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-13> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=2195s>

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

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

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

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

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

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

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

## [39:11] GPU 供给瓶颈

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-14> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=2351s>

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

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

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

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

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

## [40:57] AI 工具、组织激励与生产率

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-15> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=2457s>

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

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

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

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

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

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

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

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

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

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

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

## [45:23] 判断瓶颈仍然存在

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-16> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=2723s>

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

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

## [45:51] 企业 AI 支出会不会持续

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-17> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=2751s>

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

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

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

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

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

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

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

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

## [48:47] 给团队的备忘录：功能、hack 与清理

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-18> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=2927s>

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

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

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

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

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

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

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

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

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

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

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

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

## [54:20] 团队到底有没有变快

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-19> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=3260s>

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

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

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

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

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

## [55:41] 对 AI 时代预测的怀疑

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-20> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=3341s>

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

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

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

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

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

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

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

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

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

## [58:59] OpenCode 的产品与工程文化

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-21> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=3539s>

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

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

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

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

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

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

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

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

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

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

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

## [1:02:39] 公开构建、完整负责与反馈循环

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-22> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=3759s>

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

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

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

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

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

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

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

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

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

## [1:05:36] 品味、工艺与“非理性地好”

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-23> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=3936s>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**主持人：** 那是非理性的。

## [1:10:50] 小公司如何靠质量对抗巨头

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-24> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=4250s>

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

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

## [1:11:32] Dax 的工作环境

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-25> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=4292s>

**主持人：** 你的工作设置是什么？

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

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

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

## [1:12:37] 工程师、护栏与设计模式回归

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-26> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=4357s>

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

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

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

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

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

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

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

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

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

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

## [1:15:51] 给工程师的职业建议

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-27> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=4551s>

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

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

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

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

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

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

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

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

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

## [1:18:12] 阅读推荐、涌现系统与结尾

<https://pod-exp.pages.dev/1VqKUrxR2C8/#chapter-28> · YouTube <https://www.youtube.com/watch?v=1VqKUrxR2C8&t=4692s>

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

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

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

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

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

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

**主持人：** Dax，非常感谢这次对话，很有意思。

**Dax：** 我也很开心，谢谢邀请。

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

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

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

**主持人（结尾）：** 感谢收听。欢迎在常用播客平台或 YouTube 订阅；评分和评论也会帮助节目。下期再见。
