过去一年，AI编码工具从“副驾驶”迅速进化为能独立写代码、管代码库的“代理”。OpenCode是这波浪潮中增长最猛的产品之一，几个月内从 月活 65 万飙升至 650 万，本月更有望突破 800 万。但它的联合创始人Dax Raad，可能是所有AI工具创始人里最不急着吹AI的那一个。
在这期《The Pragmatic Engineer Podcast》里，Dax以一种罕见的诚实，拆解了AI编码工具在真实工程团队中制造的三个核心错觉：第一，代码产出量暴涨，但“做得更快”不等于“做得更好”。功能堆得越多，产品越像弗兰肯斯坦式的怪物，每一块都拼上了，但整体已经失控；第二，AI正在悄悄消音工程师的“愧疚感”。以前写hack会不舒服，第二次更不舒服，第三次你就会停下来重构。那种刺痛感在帮你校正判断。现在Agent替你干了脏活，地雷其实还在，只是你感觉不到了，你的判断力正在被偷走；第三，大多数工程师并没有用AI增加产出，而是用AI省下了时间。同样的活，做完早点回家。这对个人完全合理，但和AI厂商向CFO兜售的“生产力倍增”叙事根本不是一回事。
以下为编译。
1
Dax成长之路：从 Minecraft、创业失败到开源世界
主持人： 在聊 OpenCode 之前，我想先从你这个人开始。你现在在做全球最热门的 AI 开发工具之一，但你身上有一种挺少见的气质：你并不迷信 AI。那我们先倒回去一点，你最早是怎么进入技术行业的？
Dax： 挺典型的。我小时候就开始写程序了，我爸也是软件工程师，所以入门比很多人容易一些。后来我高中毕业就开始工作，也创过公司。那时候我以为自己很懂，回头看其实完全不懂。后来公司经历了一次很小规模的 acqui-hire，我算是正式进了科技行业，之后做过咨询，也创过几家公司，再后来差不多有六年时间都在全职做开源。
主持人： 我还看到你很早就在折腾 Minecraft 服务器和 mod。
Dax： 对。Minecraft 基本人人都知道。当时有个 mod 框架出来，我后来直接参与了那个框架，也做了很多 mod。我真正感兴趣的其实不是“玩游戏”，而是“做沙盒”。我会开一个一百来人的服务器，然后用这些 mod 去搭各种奇怪情境，观察人在这些环境里会怎么行动。我觉得这个特别迷人。那当然，背后就需要写很多 Java。
更重要的是那个社区。当时我其实还是编程新手，大家主要都在 IRC 上交流。里面有一些非常厉害、也非常资深的程序员，但他们不是那种特别有职业野心的人。他们更像是已经处在比较舒服的人生状态里，每天可能就工作两小时，技术非常好，但没兴趣去卷职场，于是把精力投进 Minecraft。这让我在很短时间里学到了非常多东西。
主持人： 后来你去了创业公司，自己创业，也做过早期创业者。像 Ride Health 那段经历，对你影响很大吧？
Dax： 很大。那是一家交通和医疗交叉领域的公司，最开始就我和另一位联合创始人，后来长到二十人左右。那是我第二次真正意义上创业，走得比之前更远，但最后基本也算是灾难收场。不过我是在那儿认识我太太的，她当时是产品负责人，我是工程负责人。我们共事一年后在一起了。所以如果你问我结果怎么样，我会说：虽然公司不算成功，但这件事比创业退出还值。
不过那段经历给我的教训很深。大家都很年轻，二十出头，整个团队像是把“年轻创业团队”这件事演了个遍。现在如果我以后要投公司，我大概率不会投一堆特别年轻人组成的团队。因为那时的我们，脑子根本还没完全长好，安全感、自我证明欲、关系处理方式、冲突反应，全都会在创业这种高压而亲密的环境里被无限放大。现在回头看，我大概到 26 岁左右，才真正觉得自己“稳定下来”了。在那之前，我未必应该负责经营一家公司。
主持人： 所以你会觉得，年轻人创业成功其实是例外，不是常态？
Dax： 我会这么看。大家当然都会举那些著名案例，但平均来看，我不觉得那是常态。创业太亲密、太高压了，如果一个人作为“人”本身都还没有长稳，很多问题都会在工作里爆出来，尤其是在那么小、那么密集的团队里。你后来再回看，会觉得当年很多冲突、很多情绪、很多判断，其实都被放大了，完全没必要那么戏剧化。
主持人： 那在你早期那几年，科技圈其实挺崇拜大公司和明星独角兽的。你有没有想过去那些地方？
Dax： 想过。那是 2010 年代前半段到中段，大厂和热门独角兽确实特别有吸引力，好像所有人都在拼命往那边走。那时如果你不往那个方向去，会有一种“你在科技行业里要失败了”的气氛。但说实话，我不是“主动没去”，而是我根本没把自己训练成适合那套系统的人。那些公司有一整套很结构化的面试流程，要刷题、准备、针对性训练。我觉得自己是个不错的程序员，也做过几次类似面试，有些甚至做得还不错，但那种高度竞争、长期备考式的路径，不是我会自然投入精力去走的。我更喜欢直接做东西，更偏实践，也更难把注意力转去别的地方。
主持人： 那你后来是怎么真正转进开源的？
Dax： Ride Health 出问题之后，我去了一个大概 B 轮阶段的创业公司。对当时的我来说，那已经是我待过最大的公司了。后来我被放进一个 director 的位置，第一次成了纯管理者，每天有三四个小时会议，但我还是特别想写代码。于是会议之外的时间，我就开始搞开源。我自己先写了一些很烂的小东西，然后碰到了刚上线不久的 SST。那是 Frank 和 Jay 做的项目。我开始给它贡献代码，他们当时在 YC 后融资，我还投了点钱。结果一个月后我直接加入了团队，他们把那笔钱当工资还给我了，但税还是得我自己交。所以我后来学到一个经验：如果你可能要去一家公司工作，最好别先以投资人身份往里面投钱，否则钱转一圈回来还得白交一笔税，很不划算。
主持人： 后来 SST 之外，你们还做了 OpenNext。
Dax： OpenNext 其实算是最早把我们带火的项目之一，而且它一开始根本不是我们想做的东西。我们服务 AWS 这边的开发者时，几乎每天都有人来问：“你们做得很好，但我们真正需要的是：怎么把 Next.js 部署到 AWS 上？”这种需求持续轰炸了一整年。我们其实不想做，因为我们自己也不是 Next.js 的重度用户，而且这活又琐碎又无聊。Next.js 非常复杂，要在 AWS 上复原正确的基础设施，需要深入到打包、框架内部机制这些很烦的地方。最后我们把这活推给了 Frank。
我们的目标从一开始就很明确：这个项目最好最终“不需要存在”。它只是因为 Next.js 团队天然会更偏向 Vercel，所以生态里出现了一个空档。我们想把这个空档补上，理想情况是未来官方把这件事处理好，那 OpenNext 就不再需要。后来它确实逐渐走向了这个方向：Cloudflare、Netlify、微软、Google 等等也都加入进来，为 OpenNext 做适配器，Next.js 团队后来也有时间推出官方 adapters API。过去一两年，这件事慢慢从“对抗”变成了“协作”，OpenNext 的必要性也在慢慢下降。
1
OpenCode 是怎么诞生的？
主持人： 那 OpenCode 是怎么来的？这其实是个非常新的故事，差不多是 2025 年夏天开始的。
Dax： 更早一点。那是 2025 年 2 月左右。当时我们的公司正在全力冲盈利。SST 已经有了商业化路径，差不多有三四个月时间我们一直处在“钱快烧完了，但收入在往上走”的状态。到 2 月的时候，我们只剩下一个月现金流，但同一个时间点我们也刚好实现了 break even。很奇怪的是，我们整个团队当时都很冷静，好像默认“事情会有解”，最后也确实有。
那给了我们一点空间去想：既然理论上接下来可以做任何事，那我们到底想做什么？我们很早就觉得，这个十年如果你还在做开发者工具，就不可能回避 AI。历史上每一轮浪潮都是这样：有些东西一出来，表面上会显得非常荒诞，因为只要某件事潜力足够大，它就会吸引大量投资，而大多数投资最后都不合理。所以最容易犯的错误，是看到一大堆不靠谱的东西，然后得出“整件事都不值得参与”的结论。但通常真实情况是：里面有些东西确实很蠢，可也有极少数东西非常真实。如果你彻底缺席，就会把真正有价值的那部分也错过。所以我们开始试一些 AI 方向的想法，其中很多甚至都没有正式发布，因为做到一半我们就发现不成立。后来整个团队开始用 Claude Code。这是第一个真正让我们持续用下去的 AI 编程工具，它确实解决了我们工作流里的一些烦人问题。我们在用的时候有个瞬间，我突然问自己：为什么不是我们做了这个？我们本来就应该做这种东西。
然后我们开始从“市场定位”而不是“功能细节”去看这件事。市场上已经有一批 coding agent 了，但不知道为什么，没有人真正占住“开源”这个位置。而在开发者工具世界里，这是一个极有价值的位置。数据库、编译器、基础设施、各种开发工具，长期看过去，开源选项最终往往都会变成默认选项。与此同时，模型供应商之间的竞争又极其激烈。Claude 当时很强，但你不可能真相信其他投了几百亿美元的玩家会坐着让 Anthropic 赢。OpenAI 会推，开源模型会推，其他公司也会推。所以在一个模型竞争极度剧烈、生态不断变化的阶段，做一个中立的、开源的、能接所有模型的产品，是很有战略价值的。
主持人： 所以你们一开始不是从“我要做最聪明的 agent”出发，而是从“我要先占住最重要的位置”出发。
Dax： 差不多就是这个意思。我们起步时就三个人，都是联合创始人。后来找了一个朋友来帮我们一起做早期版本，成了第四个人。再之后我们又拉来一个一直很想合作的优秀设计师，那是上线后的事情了，大概是秋天。团队其实很小，但方向一旦想清楚，后面很多动作就顺了。
1
从 65 万到接近 800 万月活
主持人： 你们上线后增长有多快？
Dax： 非常快。快到超出了我们之前做过的任何东西。到 2025 年 12 月，我们的月活已经到了 65 万。当时我们觉得这已经很惊人了。那时候秋天我们还在跟别人说，目标是“明年年初做到 100 万月活”，所有人都觉得我们疯了。结果 2026 年 1 月，我们直接到了 250 万月活。再往后一个月是 650 万，我当时估计接下来很快会到接近 800 万。我们的下一个目标就是 1000 万。
主持人： 那个从 65 万到 250 万的跳升，发生了什么？
Dax： 一部分是季节性。做开发者工具久了，我们知道每年 1 月都会有一波上涨，因为大家在 12 月休假时会试新东西，回到工作状态的第一周使用会猛增。正常情况下，其他产品通常是节日前先跌一波，节后第一周再暴涨。但 OpenCode 很特别：它在假期里都还在涨，这在我们以前所有产品里从没发生过。
另一部分，坦白讲，Anthropic 帮了我们大忙。他们想禁止用户在 OpenCode 里使用 Anthropic 的订阅。这个决定一下把事情引爆了。我们自己甚至都没怎么发言，主要是用户社区直接炸了。Anthropic 无意间把我们和他们放进了同一个句子里，这其实是我们不配的，他们是比我们大得多、成功得多的公司，但就是那一周，这件事突然把我们推到了特别大的关注中心。
主持人： 你怎么看 Anthropic 这件事本身？
Dax： 我觉得这反映出他们还不太习惯怎么跟开发者打交道。你当然可以为了业务可持续做你必须做的事，这本身没问题。但你如果在晚上 9 点突然默默下一个封禁，没有预沟通、没有分阶段 rollout，那就是给自己制造一个“所有人一起讨厌你”的时刻。你哪怕提前一个月说清楚，分阶段推进，人们还是会不高兴，但不会形成那种高度集中的愤怒。
主持人： 你们当时慌吗？因为那时 Claude 还是最强的编码模型。
Dax： 反而不慌。我们其实早就知道这一天迟早会来，不知道为什么，真发生的时候大家甚至有点兴奋。因为我们很清楚，我们所处的舆论圈层会扭曲现实。尤其在 X 上，好像每个人都有 200 美元的 Claude Max 订阅，但那不可能代表真实世界。那时我们已经有 65 万月活，不可能这 65 万人都在花 200 美元一个月。对大多数普通人来说，一个月在任何东西上花 200 美元都不是小事。所以我们知道，被影响的是一部分人，但不会是全部。
更关键的是，在这件事发生之前的几周，我们已经在跟几乎所有其他公司谈“官方支持 OpenCode 订阅接入”。微软那边已经同意 GitHub Copilot 正式支持 OpenCode；我们还跟一些别的公司也在推进，只是还没对外说。唯一还没真正触达的大玩家是 OpenAI。所以那天晚上事情一出，我在 X 上被艾特了一百次，大家都在说“他们封了、他们封了”。我当时就觉得：好了，时间到了。我立刻去联系 OpenAI，说，明天早上所有人醒来，都会很生 Anthropic 的气。你们现在有一个绝佳机会，只要公开站到相反的位置，宣布正式支持 OpenCode，就能直接拿下一场 PR 胜利。结果第二天早上，他们就答应了。
于是当天早上，很多人都在说“Anthropic 一封，OpenCode 完了，归零了”。我在心里一直笑。我想，你们等到今天结束再看。然后我们就把集成迅速接上，当天结束前对外宣布：OpenAI 正式支持 OpenCode。
主持人： 所以这并不是偶然撞上的运气，而是你们很熟悉的一种策略。
Dax： 对。往前看 OpenNext，你会发现我们一直会玩一种策略：找到一个阶段性的“坏人”，然后把它的所有竞争对手团结起来，借力把某件事往前推。Anthropic 很不幸在那一刻成了这个角色。于是我们就把行业里其他玩家都 mobilize 起来，让他们都来支持 OpenCode、支持更开放的模型接入。对小公司来说，只要你站位站对了，世界就会不断给你送来你原本都没预料到的机会。
如果有一个足够中立的中间层，所有那些投了几百亿美元的大公司，都会出于自己的利益来利用这个中间层。这就是为什么，处在中间位置是有利的。未来 OpenAI 当然也可能变成下一个“坏人”，到时我们可能又会去联合其他人对抗它。这本来就是竞争应有的样子。
主持人： 但你们也因此被一些人批评，说你们对 Anthropic 太刻薄了。
Dax： 是，会有人这么说。但别忘了，他们是体量极大的公司，是十亿美元级别的大公司。像我们这样的小公司，想要施加哪怕一点点压力都很难。这就是现实里的博弈方式。你可以特别喜欢 Claude Code，完全不打算切走，这没问题；但你最好仍然支持“别人有权使用自己想用的工具”，这本身是好事。
1
OpenCode 为什么能跑出来：不是先做最聪明，而是先做最顺手
主持人： 回到产品本身。为什么市场明明这么热，但这个位置居然空着，让你们拿到了？
Dax： 我觉得开发者工具领域最大的结构性优势在于：所有做开发者工具的人自己都是程序员，而程序员通常都特别不擅长做 B2C 产品。他们没有意识到，真正大规模成功的 devtools，本质上是 B2C 产品。你当然也可以做自上而下、走企业采购流程的工具，那也能成。但那些真正从个体开发者开始自然扩散、最后变成行业标准的东西，几乎都是自下而上的。你必须像做消费产品一样思考它。
所以我们特别在意用户第一次打开 OpenCode 时的感受。它必须明显不同，而且更好。为此我们直接从底层自己做了一个终端渲染框架。Claude Code 和其他很多终端型 coding agent 没这么干，它们更多是基于 Ink 之类的东西把需求先满足了。但我们愿意提前投这笔成本，因为只要用户一上手，就会立刻觉得：这东西是被认真做过的。它未必适合所有人，有些人可能觉得它过于强烈、过于“满”，但你至少会带着一个判断离开：做这个产品的人是有能力的。
我们还非常重视降低一切摩擦，尽可能让用户马上进入“开始 prompt”的状态。比如你在一台被企业严格锁定的笔记本上，能不能装、能不能用，这些看似不性感的问题我们也在想。说白了，我们最早几个月的 harness 其实不怎么样，尤其前五个月。它并不是最聪明的 harness，但它“够用”，而且大多数用户一开始根本感知不到差距。等我们先把用户份额拿下来，再回头把 harness 慢慢做聪明、做优化、做得更好。市场上其他人一开始都在想：“先把 smartest harness 做出来，再赢”。我们的逻辑是反过来的：先把体验和采用做起来，然后再把内部能力追上。结果我们用一个“中等水平的 harness”，先成了用户最多的那个，之后再继续把底层也做好。
主持人： 你们后来也尝试过 GUI 和桌面端。
Dax： 对。我们做过一个桌面 App，当时用的是 Tauri。但老实说，那一步大体上是我们的失误。我个人很爱终端，我的工作全在终端里完成。但如果你看到我们的用户数字快接近 800 万，你就会意识到：不可能真的有 800 万人都应该在终端里工作。很多用户在 GUI 里体验会更好。我们其实很早就知道这点，所以同时在试 Web App 和桌面 App。方向上我们是对的，问题在于我们没有足够严肃地去做，没有足够快地推进，也没有足够认真地想技术选型。后来我们决定重新转回 Electron。
主持人： 还有个有意思的点，你们没有做那种“在 GitHub PR 上自动打品牌水印”的增长黑客。很多其他工具都在做。
Dax： 我们一开始其实有。因为最早 OpenCode 某种程度上有点像 Claude Code 的 clone：它做什么，我们就跟着做什么。所以提交信息里也会写“committed with OpenCode”之类。后来越来越多用户问，能不能关掉。我想了想，觉得这事太 lame 了。就像赌场到处用小技巧把你困住。我不是说做消费产品就不能做增长，但我觉得没必要走到那种程度。这种增长手段太明显了，谁都看得出来你为什么这么做。最后我们干脆把它默认关了。
1
OpenCode 怎么赚钱：控制台、推理服务，以及“推理可能非常赚钱”
主持人： 说到这里，还是得问个现实问题：你们终究是一家商业公司。OpenCode 的商业模式到底是什么？
Dax： 现在主要有两条线。第一条最初其实只是为了把新手引导做顺。OpenCode刚上线时，用户得自己去接各个大模型厂商的账号，这件事非常别扭。而且那时你就算注册了账号，也不一定能拿到足够的使用配额去高强度用OpenCode。所以我们想，至少得做一个统一的推理服务，让用户注册一次就能获得足够额度，还能接多个模型。于是我们做了OpenCode Zen。
一开始它只是一个新手引导辅助层，结果增长得非常快。再加上开源模型越来越流行，我们也发现：把开源模型真正托管好，远比大家想得难。所以Zen后来慢慢变成一个聚合最优模型推理服务的地方。前沿模型当然重要，但开源模型怎么用最低成本、最稳定、最好地托管，同样很关键。这个业务长得非常快。我们前几个月对外说过，它在上线五六个月左右时，已经跑到五千万美元的年化收入了。这里面的利润率也可能相当不错，尤其是一些开源模型，如果托管方式合理，利润空间会很好。
第二条业务就非常无聊，但企业一定需要。假如一家有一千名工程师的公司要用OpenCode，你不可能让每个人自己下载安装，然后各自填一个API key。企业一定需要一个控制面：有哪些供应商、什么权限、预算控制、使用配额、审计、策略，这些都需要统一管理。所以我们做了这样一个产品。它也是开源的，但大多数公司会直接买我们的托管版。未来它会更公开一些，现在主要还是企业部署形态。
还有一件事也很关键：企业现在终于开始认真看自己在大模型上花了多少钱，然后问一句，“我们到底在干嘛？我们真的因此做成更多事了吗？”这对我们是个很好的时机，因为开源模型已经变得非常有竞争力，而且便宜十倍左右。企业买我们的控制面以后，往往也会顺手接入我们的推理服务，开始混用更便宜的开源模型。如果未来推理成了我们更核心的收入来源，我们甚至可能不再向控制面本身收费，而是主要靠推理收费。
主持人： 你前阵子还说过一个很有争议的观点：推理其实是一个非常赚钱的业务。对很多软件工程师来说，这听起来有点反直觉。
Dax： 因为大家会把训练成本、研发成本和推理业务混在一起看。如果你单独看“纯推理”这一段，理论上的成本底线其实就是电费。当然前面还有买 GPU 的资本支出，也有运维团队、基础设施等等，但一旦硬件已经在那里了，生成一个 token 的最低成本，接近于给这些机器供电的成本。我们自己也在大规模租 GPU 跑模型，而且我们甚至还没完全直达最底层，我们中间也还用了一层供应商。可即便如此，有些模型我们看一眼标价，再对比一下我们自己的成本，中间能有接近80%的利润空间。
另一个被很多人忽略的事实是：价格其实涨了。表面上大家觉得模型越来越便宜，但从用户实际使用结构看，过去大家默认用的是 Sonnet，因为 Opus 太贵；后来他们把 Opus 调便宜了一些，结果大家开始默认用 Opus，但 Opus 即使降价了，还是比 Sonnet 贵得多。所以从整个市场的消费组合来看，价格其实是往上走的，而托管这些模型的基础成本并没有同步上涨。如果 Anthropic 或 OpenAI 本身能拿到规模巨大的 GPU 合同，我一点也不会惊讶他们在某些阶段看到 90% 左右的推理毛利。当然这未必是长期可防守的利润率，但在当前这个阶段，并不夸张。这有点像早年的云计算。大家都说云是个血海市场、到处亏钱，但真正做过的人都知道，云业务可以非常赚钱。只不过那些公司没有任何动力去主动纠正外界的悲观叙事。AI 也是一样。训练当然烧钱，研发也贵得吓人，但长远看，推理作为一门生意本来就是成立的。
1
从创业公司到大厂，整个行业都在抢算力
主持人： 但你又说过，哪怕像你们这样的公司，也已经被 GPU 卡住了。
Dax： 因为整个 GPU 供给链现在全都绷得很紧。从 GPU 生产、配套硬件、供应链，到相关劳动力，整个链条都很紧。推理需求还在疯狂增长，我甚至怀疑它不是线性增长，而是接近指数增长。但 GPU 的产能扩张不是指数级的，那更像是线性过程。当这两条线相交时，就一定会出现紧缩。对我们来说，想拿到用于推理的 GPU 容量，往往要提前预留、提前支付。因为大家都在囤，所有人都默认这种紧缺还会继续。现在想拿到稳定的推理容量，真的很难。而且外界看创业公司融了 20 亿美元，会觉得这已经是天文数字了。但大厂一年在 AI 上的资本开支是几百亿、上百亿美元级别。Amazon、Meta、Google、Microsoft 这种级别的玩家，几乎是在把整个供给侧都吸走。你如果是供应链上的一家公司，它根本不想跟你这种小公司聊，它只想先把和大厂的订单处理完。所以现在确实非常紧。不过按我的经验，任何行业里只要出现短缺，通常接下来都会进入一段激烈投资，然后走向过剩。这次也许会不同，但历史上更常见的路径是：先紧，再过度供给。只是至少在今天，AI 这条线还是很紧的。
1
AI 让工程团队自动更快了吗？Dax 的答案是：未必，很多时候只是“更轻松地完成同样的事”
主持人： 你有条很有名的观点，大意是：很多公司以为自己本来就处在高效状态，只是被“写代码速度”卡住了，所以一旦有 AI 就会飞起来。但现实不是这样。
Dax： 对。我想说的是，软件行业太大了。全世界几乎任何公司都雇软件工程师。大多数环境其实并不是特别激动人心、特别有使命感的环境。很多人就是来上班、干活、回家陪孩子，过正常生活。你给他一个按钮，让他可以更快做完工作，最自然的结果不是“他会做十倍更多工作”，而是“他会疯狂按这个按钮，然后做差不多的工作量，把省下来的精力和时间留给自己”。这完全合理。如果你没有很强的动机让自己持续超额投入，那你不会自动把这些省下来的产能全部上交给公司。
当然，不同公司差异很大。有些团队本来就极有动力，激励也对，大家愿意冲。但大多数地方不是这样。问题在于，在一个并不高激励的组织里，通常总会有少数几个“非理性地在乎质量”的人。这些人以前会是质量守门员，会盯代码审查，会想办法把事情做好。现在 AI 一上来，其他人都在更快地产出 PR，这些真正还在乎的人就会被“垃圾 PR 洪流”淹没。我们团队里就有人从这种公司过来，他们说自己之前就是那个还在乎的人，结果每天淹死在大量低质量变更里，最后精疲力尽，只能离开。
主持人： 那企业该怎么重新设计激励、薪酬、组织方式？
Dax： 对创业公司来说相对简单一点。像我们这种团队，本来就在一个很刺激的市场里，来的人大多竞争心强，也知道做成了之后股权会很有价值。我们一直也愿意给很高的薪资。甚至在 AI 之前我就一直觉得，很多创业公司招两个人，各发一个“还不错”的工资，其实不如直接把预算合成一份，高薪招一个能真正改变公司方向的人。我们不需要招一千个人，我们需要的是二十个真正厉害的人，所以高薪一直有用。但对更大规模的公司，我没有什么特别好的答案。公司一旦大到某个程度，对一个人来说，额外多做很多事通常就没有足够强的个人理由了。所以我不觉得这个问题能靠一句“有了 AI 就好了”解决。
主持人： 那 AI 至少让你们在执行层更快了吗？
Dax： 瓶颈还是那个瓶颈：你还是得先想清楚该做什么。你完全可能花一年时间去搞清楚“正确的方向到底是什么”，等方向对了，构建本身也许确实变快了。但如果你问我直观感受，我会说：以前我大概 95% 的精力花在想该做什么，5% 花在把它做出来；现在我大概 96% 花在想该做什么，4% 花在做。也许这说明执行效率提高了 20%，但你的日常体感不会是“世界轻松了十倍”。它还是一样难。
主持人： 成本这件事现在是不是也开始压过来了？比如 CFO 会问：为什么每个工程师每月还要多花 1000 到 2000 美元？
Dax： 是。每项新技术都会先经历一个“炫耀期”。现在很多公司都想让外界觉得自己特别未来、特别先进，所以会炫耀“我们每个工程师一个月花 1 万美元跑 AI，这绝对值”。这种叙事里面有很多表演成分，它会过去的。然后会出现真正的财务问题：大公司动不动几千名工程师，你真让每人每月多花 1000 美元，预算结构都会被改写。如果你又无法很明确地证明产出显著增加，那这件事不会长期成立。还有一种很微妙但很真实的情况：也许所有这些 AI coding 工具的净结果，只是“同样的工作量被完成了，但工程师们更开心，因为工作更轻松了”。对很多公司来说，这不够。他们会说，那你还是回去自己敲吧。
主持人： 但另一边，很多 CTO 也会说，不给好工具，最强的人会走。
Dax： 这点也是真的。尤其在高端人才市场上，如果一个非常优秀的人本来就有无限机会，你让他天天被 Jira 折磨、不给好工具，他真的会走。我知道有人就是这么走的。所以顶层市场的情况和大盘市场又不是一回事。只是我们现在看到了整个世界的广阔：绝大多数公司根本不在“最前沿工具大战”的那一层。很多公司最后的现实就是：给你一个 Copilot，通过 OpenCode 接一下，额度就这些，用完拉倒。并不会因为这样就立刻被时代抛弃。
1
Dax 给团队发的那封备忘录：别再堆功能、别再靠 agent 悄悄埋雷
主持人： 你之前发给团队那封 memo 很多人都在转。你在里面说了三件事：我们在发一些不值得发的功能；在做功能时原始设计有问题，就被迫往上叠补丁，但 LLM 会接着把这些补丁继续往下滚；以及我们需要花更多时间清理代码。你当时为什么会写这封内部信？
Dax： 因为这些问题一直都有，只是 LLM 把它们放大了。第一件事，功能太容易发了。以前用户提一个问题、竞品上一个新功能、或者我们自己想到一个点子，你还会因为开发成本犹豫一下。现在很容易直接“让Agent做一个”。用户要功能，一句话；竞品有个功能，一句话。最后你以为自己堆出了一千个功能就等于做出了好产品。其实你做出来的是一个怪物，一个弗兰肯斯坦。任何功能一旦上线，就几乎要永久支持，以后所有新功能都要跟它交互。所以你必须比以前更克制。不是因为能发十倍东西，就代表我们突然有了十倍值得发的好点子。
第二个问题更大：打补丁。以前你给系统加新能力，如果系统结构不太支持它，你会在两个选项里选：要么从第一性原理出发，把系统重构到能优雅支撑这个能力；要么临时吸收一个补丁。这个判断一直存在，你会掂量这个补丁多难看、这个功能对业务多重要，然后做权衡。问题是现在Agent会非常轻松地帮你把补丁打上去，而且后续它也会继续帮你“对付”这些补丁带来的问题。于是你的判断被扭曲了。太容易说“先临时修一下”。很多本该停下来重新想系统设计、重新整理架构的地方，现在都被我们直接一个补丁糊过去了。
主持人： 你后来提了一个特别好的说法：以前工程师打补丁，会有一种“刺痛感”。你知道自己在做坏事，你心里会不舒服。这种感觉其实在帮你校正判断。但 agent 把这个感觉拿走了。
Dax： 对，这个形容特别准确。以前你自己打补丁，你会感觉不对，会隐约发毛。第二次、第三次再写的时候，这种感觉会叠加。你知道你在给未来埋雷。现在因为是“另一个东西”在帮你处理，它把那个不舒服的感觉弱化了。问题没有消失，地雷也还在那里，只是你当下没那么痛。所以你的判断失真了。人生很多事都靠正确的反馈回路。你感受不到痛，就会一直做错。
主持人： 第三个点是“清理”。可创业公司最缺的就是时间。清理代码看起来又不会直接带来新增用户和收入。
Dax： 这确实很难。我们每天一睁眼，就是一千个人在喊你该做 A、做 B、做 C；每天都有竞品出来；每天都像被海量刺激拖着跑。如果我们完全被这些力量牵着走，我不觉得最后会去到任何好地方。但有趣的是，清理这件事现在反而比以前容易得多。以前你发现一种更好的模式，往往只是从此以后新代码按新模式写，旧代码太多，没人愿意回头收拾。现在不是了。现在你可以让 agent 去把旧代码一并迁过去。你可以把全代码库里的旧模式一起替换掉。技术债从来没有像今天这样容易被系统性清扫过。我当然知道这不会直接变成明天的收入。但我想建的是一个五年后我们还愿意待着的地方。世界上有很多公司都很成功，可如果让你随便选一家去工作，你大概不会选其中 99%。我不想把公司做成那 99% 里的一个。我想确保这里五年后仍然是个我们每天工作起来感觉不错的地方，不是那种谁都不想加入、大家天天只是在和遗留烂摊子搏斗的地方。
主持人： 你在 memo 里还有一句很重的话：最糟糕的是，我甚至不觉得这些牺牲真的换来了更快的速度。我觉得我们只是在“正常速度”前进，却误以为自己飞起来了。
Dax： 是的。我们“感觉”自己在高速奔跑，但我回头看，真的未必。我们也没比竞品快多少，至少看不出来明显更快。所以如果你真想讨论生产力，最大的风险其实是：你特别容易把自己骗了。你以为你产能爆炸，结果坐下来认真看，往往没那么夸张。对我来说，这意味着要重新相信“慢一点，把地基打牢，再冲刺”的价值。
1
反 hype、讲品味、重反馈，才是 OpenCode 真正的工程文化
主持人： 你还有一个特点，就是特别爱对各种 AI 预测“泼冷水”。比如那条很火的话，说“24 到 29 岁的工程师很快会成为科技行业最有价值的人，因为他们同时拥有前 AI 时代原则和后 AI 时代速度”。你公开说这是胡扯。
Dax： 因为我真的受够了。每天醒来打开 feed，就是各种预测：未来一定怎样、哪类人一定赢、哪类公司一定死。大家都在凭空编。那条尤其好笑，因为它本质上就是“像我这样的人拥有所有优势，不像我的人拥有所有劣势”。你一眼就能看出来，说这话的人自己就在 24 到 29 岁这个区间。我觉得这些预测背后的心理结构非常简单：我们都处在一个剧烈变化的时刻，每个人都在焦虑自己会在这个变化里处于什么位置。最自然的心理防御机制，就是特别自信地预言一个“自己会赢”的未来。你几乎可以把所有热门预测都拆回这一点：我的公司会赢，别人的公司会输；我的工作不会被 AI 替代，别人的工作会。大家会给自己一套看似理性的解释，但更底层的事实是：大家都在害怕。
我也会紧张，也会担心。只是我越来越不相信那些宏大而确定的判断。历史上真正发生的事情，几乎从来不是当下看起来最显然的那个版本。真正落地的结果往往非常反直觉，只不过事后回头看，又会觉得“好像一直都很合理”。所以我宁愿只想明天和后天：今天该做什么，明天该做什么。一年前我都没想到自己今天会在做这个，一年后我也不知道我会在做什么。
主持人： 回到产品和工程方法论。你觉得自己从早年到现在，有什么原则是没变的？
Dax： 一个最朴素的原则是：你的产品里很可能只有一个真正好的主意。那你最重要的工作，就是让用户尽快体验到这个主意。听起来很简单，可你随便去试市面上很多产品，就会发现从“听说这个产品”到“感受到价值”之间，开发者会不知不觉塞进一大堆多余步骤。我自己会每隔两周跑一次“第一次使用体验”测试：起一个新的 Docker 容器，重新跑一遍 OpenCode，从零开始安装和使用。每次都能抓出我们不小心加进去的摩擦。对我来说，产品不是“用户有一个问题，你立刻发一个对应功能”。真正的产品工作，是把大量问题吸收进来，然后找到一种解决方案，能同时解决五十个问题。这很难，靠经验、靠思考、靠和用户聊天、靠理解团队、靠理解代码库。AI 到目前为止，在这件事上没有帮到我哪怕一点点。
主持人： 那你怎么提升这种“产品 sense”或者“taste”？
Dax： 本质上还是反馈回路。你设计错了，有真人来骂你；你代码架构差了，下一次加功能时你就得亲自下去踩泥。只要团队里每个人都暴露在这种反馈里，人就会成长得很快。很多组织的问题恰恰是把人隔离开了。产品团队为了赶上线，把某些东西砍掉了；结果痛的是客服团队，是支持团队，是最终还在现场手工救火的人，而真正做决定的人根本感觉不到。所以对我们来说，一定要让做决定的人和承受后果的人尽量是同一批人。
我们现在二十多人，最近三个月长得很快，所以也处在一个很烦的阶段：人数比以前多了，但速度反而是最慢的时候，因为所有人还在磨合、还在上手。我们是开源公司，代码全是公开的，所以很多事情天然就是在 public 里做。我们内部大概把新东西分成两个阶段：第一阶段是“把一个东西从零推上山”，这很痛苦，因为很多事情都还没存在；第二阶段是“它虽然还没做完，但大部分关键问题已经清楚了”，我们通常会把这个点定义成“至少可以 demo 给别人看”的里程碑。我们会拼命把事情尽快推到这个点。一旦到了这一步，因为用户声音非常大，他们会很明确地告诉你后面该做什么、哪里难用、哪还缺一块。于是工程师会自己拿 GitHub issue、拿 X 上的回复，自己做后续路线，不会有一个中间层来替他们过滤总结。
我们作为创始人，尽量让团队理解整个市场、竞品、位置、为什么要做这个。只要上下文给足，大家会自然做出还不错的优先级判断。我们很看重动机，因为这是个长游戏。如果是长游戏，最重要的策略就是：怎样让自己尽可能长时间待在牌桌上。唯一可持续的方法，就是每天做让自己兴奋的事。所以我们经常让团队直接去抓他们真正觉得重要、真正兴奋的问题。有时候我会明确反对某个方向，结果最后证明是团队对、我错，这反而让我很开心。
主持人： 我们还没正式聊“品味”。现在很多人说，AI 很难替代的一件事，就是 taste。
Dax： 我觉得“taste 很重要”当然是对的，但问题是：你真的信吗？很多好观点都很简单，所以人人会重复它。可简单不代表容易践行。你说自己相信品味、相信质量，那你真的愿意为此做那些“非理性”的事吗？因为很多伟大的产品，少做 50% 的精细处理，可能在短期商业结果上都看不出太大差异。可那种对质量的纵容，会像感染一样慢慢扩散：你在一个地方开始偷懒，最后会在所有地方偷懒。现在空气里有一种非常强的声音，觉得代码不必好、产品不必好、什么都不必好，只要商业上能赢就行。这个念头一旦真的进了你脑子，你就做不出好产品了，因为你根本不再信这件事。
我很欣赏的人里，Mitchell Hashimoto 一定算一个。他们那套公司路径和我们理想中的方向很像：开源、被广泛采用、最终成为默认。Terraform 就是最典型的例子。他后来做 Ghostty，我也非常喜欢，里面很多对架构、细节、产品感受的处理，真的都能用得出来。他有个观点我非常认同：做产品不是在往里面塞 feature，而是在思考每一个新 feature 会怎样和旧 feature 发生交互。那才是产品工作的本质。
而且我现在越来越强烈地觉得，AI 时代产品“腐烂”得比以前快得多。大公司产品腐得更快，创业公司产品也一样。现在一个产品如果已经做了一年，可能都已经有点开始烂了。也正因为如此，质量反而可能变成更强的区分点。但质量不是你嘴上说一句“我们重视质量”就会出现的，它必须体现在公司每一个层面，而且很多时候都来自一些看似不理性的决定。比如我们当初自己做终端框架，按教科书讲这是最不该做的事，所有人都告诉你“不要重复造轮子”。可我们知道自己想要的体验，知道 NeoVim 这类工具把终端体验做到了什么程度。既然知道边界在哪里，我们就不愿意交出一个远低于那个水准的东西。早期很多用户从 Claude Code 转来，第一感受就是：OpenCode 的终端体验更顺、更稳、更少闪烁。这个差异，某种意义上就是靠那些“看似不理性”的决定换来的。
主持人： 最后聊聊你自己。你的工作环境是什么样？
Dax： 我现在用的是 Framework 桌面机那套东西，跑 Arch Linux，接一个 5K 显示器。麦克风是 SM7B，相机直接用 iPhone。物理机器只是入口，我所有真正的工作都在远程机器上做，那台更强，会开很多终端会话，每个项目一个。编辑器是 NeoVim，通常左边 NeoVim，右边 OpenCode，两个并排。我基本就在这两边来回切。
主持人： 那你怎么看 AI 时代工程领导者的角色变化？
Dax： 现在大家都在问：如果工程师不再主要自己写代码，那工程师到底做什么？很多人说，工程师的职责变成了“把系统弄到足够安全，让别人能安全发代码”。比如测试、guardrail、约定、pattern、约束，让一个人或一个 agent 改代码时，不至于把系统炸掉。我觉得这话有道理，但某种程度上它也一点都不新鲜。我们一直都在试图解决这个问题：怎么让一个没那么成熟的人也能相对安全地发代码？怎么让代码库的结构更清楚、测试更可靠、约定更明确？以前是为了初级工程师，现在只不过多了一群 24/7 工作的“傻子”——也就是 coding agents。
所以一些老东西反而会回来。我们一直都比较相信领域驱动设计，只是以前做得比较轻。现在我们反而开始做得更重一些，因为那些看上去很“企业味”、很啰嗦的模式，今天开始重新有用了。过去大家讨厌它们，是因为它们很繁琐、打字很累；但现在不是人手打了，所以它们的缺点被弱化，优点——可靠、模块化、安全、边界清楚——被放大了。我甚至觉得一些老派设计模式都可能回潮。以前高手嫌它们像训练轮，不需要；现在 agent 没有训练轮，那你就得重新把训练轮装回去。
主持人： 那你给更资深工程师的建议是什么？怎么在这个时代继续保持竞争力？
Dax： 我不太敢轻易给建议，因为我们这个公司本来就很奇怪：创业公司、开源公司、所处市场也很特殊，很多经验未必能普适。但如果一定要说，我会说一件我在 AI 之前就一直相信的事：软件工程能力本身当然是一种可迁移技能，你完全可以只做“优秀的软件工程师”，这就已经能有很好的职业生涯了。但如果你同时还成为某个行业的专家，这个组合会非常强。
比如你去做农业软件。如果你真的懂农业，又是个不错的软件工程师，那你大概已经是全世界前十档的稀缺组合了，整个行业都会想要你。最棒的是，软件工程师和其他职业不同，你不用在 22 岁就决定自己一辈子都在某个行业。你可以在医疗做十年，再转去农业，再转去别的领域。每待一年，你对那个行业的理解就可能超过 99% 的人。工程师最大的优势之一，就是你能进入世界上几乎任何行业，并且把那一套业务真正学明白。问题只是，很多人太容易把自己变成纯粹接 ticket 的人——“加一个 UI、改一个接口”，然后从不去理解自己身处的行业。可那恰恰是你最值得抓住的机会。
主持人： 最后一个轻松点的问题。有没有什么书推荐？
Dax： 好笑的是，我几乎不读书。我太太很爱读，她读完以后会把里面最好的想法告诉我，然后我就拿去说得像是自己的想法一样。真要说的话，我早些年有一段比较认真读书的时期。Nassim Taleb 的一些东西对我影响挺大，比如《Skin in the Game》《Black Swan》。这些推荐其实很老派，也许一本书里真正重要的就那么一两个观点，但那几个观点又确实很根本。我尤其着迷的一类概念，是“涌现”和“自下而上系统”。世界上很多伟大的东西，并不是靠一个自上而下的总设计师规划出来的，而是很多小个体在局部互动中慢慢长出来的。不管是稳健软件、城市街区、还是生物抵抗疾病的能力，你都能看到这种 bottom-up 的力量。我现在看很多事，都会下意识用这个框架去看。
这场对话到最后，其实留下了一个比“OpenCode 为什么增长这么快”更有价值的问题：当 AI 让生成代码这件事越来越廉价时，真正稀缺的到底是什么？Dax 给出的答案很朴素——不是更快敲代码，而是判断什么值得做、什么不该做；不是盲目加功能，而是守住产品整体性；不是把 hack 推给 agent，而是保住工程系统的反馈回路；不是沉迷于“未来一定怎样”的口号，而是在不确定里继续做对眼前的事。
如果说 OpenCode 的爆发说明了 AI 开发工具的时代确实已经到来，那么 Dax 的这场访谈提醒我们的则是：真正决定一家产品公司能不能活得长、活得好、活得像样的，依然是那些看上去“老派”的东西——节制、质量、品味、上下文、反馈，以及对系统后果的敏感。
点个“爱心”，再走吧
诚利和配资提示：文章来自网络，不代表本站观点。
