AI编码工具火爆，联合创始人称工程师前景依然光明

在过去一年中，AI编码工具已从“副驾驶”角色迅速演变为能够独立编写代码、管理代码库的“代理”。OpenCode是这一浪潮中增长最为迅猛的产品之一，其月活跃用户数从几个月前的65万飙升至650万，本月更有望突破800万。然而，其联合创始人Dax Raad可能是所有AI工具创始人中最不急于鼓吹AI技术的那一位。

在本期《The Pragmatic Engineer Podcast》节目中，Dax以一种罕见的坦诚态度，剖析了AI编码工具在真实工程团队中制造的三大核心错觉：

第一，代码产出量急剧增加，但“做得更快”并不等同于“做得更好”。功能的快速堆叠往往使产品沦为弗兰肯斯坦式的怪物——虽然每一部分都被拼凑起来，但整体已然失控；

第二，AI正悄然消解工程师的“愧疚感”。以往，当工程师编写临时性解决方案（hack）时，第一次会感到不适，第二次会更加不安，第三次便会停下来进行重构。那种刺痛感实际上在帮助校准技术判断。如今，代理工具替工程师处理了这些“脏活”，潜在的问题隐患依然存在，只是工程师不再能感知到它们——他们的判断力正被悄然剥夺；

第三，大多数工程师并未利用AI来增加产出，而是借此节省时间。同样的工作量完成后，他们可以提早回家。这对个人而言完全合理，但与AI厂商向首席财务官（CFO）兜售的“生产力倍增”叙事截然不同。

以下为编译内容。

1 Dax的成长轨迹：从Minecraft、创业挫败到开源天地

主持人： 在深入探讨OpenCode之前，我们不妨先聊聊你的个人经历。你如今在打造全球最炙手可热的AI开发工具之一，但你身上有一种颇为独特的气质：你并不盲目追捧AI。那么，让我们回溯一下，你是如何踏入技术领域的？

Dax： 我的经历算是比较典型的技术人成长路径。我从小就开始接触编程，父亲也是软件工程师，所以入门比许多人要顺利一些。高中毕业后我便直接投身工作，也尝试过创业。那时自认为懂得很多，如今回看才发现其实知之甚少。后来公司经历了一次小规模的收购式招聘（acqui-hire），我才算正式进入科技行业。之后我做过咨询，也创办过几家公司，再后来有将近六年的时间，我全身心投入在开源项目上。

主持人： 我还注意到你早期就热衷于折腾Minecraft服务器和模组（mod）。

Dax： 没错。Minecraft几乎是家喻户晓的游戏。当时出现了一个模组框架，后来我直接参与了这个框架的开发，也制作了许多模组。我真正着迷的并非“玩游戏”本身，而是“构建沙盒世界”。我会开设一个能容纳百来人的服务器，然后利用这些模组搭建各种奇特的情境，观察人们在其中的行为反应。我觉得这过程极其吸引人。当然，背后需要大量编写Java代码。

但更重要的是那个社区氛围。当时我其实还是个编程新手，大家主要在IRC上交流。社区里有一些技术极为精湛、经验非常丰富的程序员，但他们并非那种极具职业野心的人。他们更像是处于一种舒适的生活状态，每天可能只工作两小时，技术实力雄厚，却无意在职场中内卷，于是将精力倾注于Minecraft。这让我在短时间内学到了海量的知识。

主持人： 后来你去了创业公司，自己也创过业，还担任过早期创业者。像在Ride Health的那段经历，对你影响应该非常深远吧？

Dax： 影响确实很大。那是一家聚焦于交通与医疗交叉领域的公司，最初只有我和另一位联合创始人，后来团队扩展到二十人左右。那是我第二次真正意义上的创业，比之前走得更远，但最终基本以失败告终。不过，我在那里认识了我现在的太太，她当时是产品负责人，我是工程负责人。我们共事一年后走到了一起。所以如果你问我那次创业结果如何，我会说：虽然公司本身不算成功，但这段缘分比任何创业退出都更有价值。

然而，那段经历给我的教训极为深刻。当时大家都很年轻，二十出头，整个团队仿佛把“年轻创业团队”的所有特质都演绎了一遍。现在如果我要投资公司，我大概率不会选择完全由非常年轻的成员组成的团队。因为当时的我们，心智尚未完全成熟，安全感、自我证明的欲望、人际关系的处理方式、面对冲突的反应，所有这些在创业这种高压且亲密的环境中都会被无限放大。现在回想起来，我大概到26岁左右，才真正感觉自己“稳定下来”了。在那之前，我可能并不适合负责经营一家公司。

主持人： 所以你认为，年轻人创业成功其实属于例外，而非普遍规律？

Dax： 我倾向于这样看。人们当然会列举那些著名的成功案例，但从普遍情况来看，我并不认为那是常态。创业对人际关系的亲密度和压力值要求都太高了，如果一个人作为独立的个体还没有完全成熟，很多问题都会在工作中爆发出来，尤其是在规模小、密度高的团队里。事后回顾，你会发觉当年的许多冲突、情绪和决策其实都被放大了，本不必如此戏剧化。

主持人： 在你职业生涯的早期，科技圈其实非常推崇大公司和明星独角兽企业。你当时有没有考虑过加入那样的平台？

Dax： 确实考虑过。那是在2010年代上半叶到中期，大厂和热门独角兽企业确实极具吸引力，似乎所有人都在拼命挤进这些平台。当时如果你不朝那个方向努力，整个环境就会营造出一种“你在科技行业注定失败”的氛围。但坦白说，我并非“主动放弃”，而是根本没有把自己塑造成适合那套体系的人。那些公司有非常结构化的面试流程，需要刷题、针对性准备和长期训练。我自认是个不错的程序员，也参加过几次这类面试，有些表现甚至尚可，但那种高度竞争性、需要长期备考的模式，并不是我会自然而然投入精力的方向。我更倾向于直接动手创造，更注重实践，也较难将注意力转移到这类应试路径上。

主持人： 那你后来是如何正式转向开源领域的？

Dax： 在Ride Health出现问题后，我加入了一家大约处于B轮阶段的初创公司。那在当时已经是我待过的规模最大的公司了。后来我被安排到一个总监的职位，第一次成为纯粹的管理者，每天要开三四个小时的会，但我内心仍然非常想写代码。于是，在会议之外的时间，我开始投身开源项目。起初我自己写了一些质量不高的小工具，后来遇到了刚上线不久的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的必要性也在逐步降低。

2 OpenCode 是如何诞生的？

主持人： OpenCode 是如何诞生的呢？这其实是一个非常新的故事，大约始于 2025 年夏天。

Dax： 其实更早一些，大约在 2025 年 2 月左右。那时我们公司正全力以赴冲刺盈利。SST 已经找到了商业化路径，在三四个月的时间里，我们一直处于“资金即将耗尽，但收入却在增长”的状态。到了 2 月，我们的现金流只剩下一个月，但就在同一时间点，我们实现了收支平衡。奇怪的是，整个团队当时都非常冷静，仿佛默认“事情总会找到解决办法”，最终也确实如此。

这给了我们一些空间去思考：既然理论上接下来可以做任何事情，那我们究竟想做什么？我们很早便意识到，在这个十年里，如果你还在从事开发者工具领域，就不可能回避 AI。历史上的每一轮浪潮都是如此：某些事物一旦出现，表面上看起来可能非常荒诞，因为只要某件事潜力足够大，就会吸引大量投资，而大多数投资最终都显得不合理。因此最容易犯的错误是，看到一大堆不靠谱的东西，然后得出“整件事都不值得参与”的结论。但通常实际情况是：其中有些东西确实很蠢，但也存在极少数非常真实有价值的部分。如果你完全缺席，就会错过真正有价值的那一部分。所以我们开始尝试一些 AI 方向的想法，其中很多甚至都没有正式发布，因为中途我们就发现它们并不成立。后来整个团队开始使用 Claude Code。这是我们第一个真正持续使用的 AI 编程工具，它确实解决了我们工作流程中的一些烦人问题。在使用过程中，有那么一瞬间我突然问自己：为什么不是我们创造了这个工具？我们本该做这种东西才对。

于是我们开始从“市场定位”而非“功能细节”的角度审视这件事。市场上已经有一批编程助手（coding agent），但不知道为什么，没有人真正占据“开源”这个位置。而在开发者工具的世界里，这是一个极具价值的定位。回顾历史，数据库、编译器、基础设施、各种开发工具，长期来看，开源选项往往最终会成为默认选择。与此同时，模型供应商之间的竞争又极其激烈。Claude 当时很强，但你不可能真的相信其他投入了几百亿美元的玩家会坐视 Anthropic 获胜。OpenAI 会推动，开源模型会发展，其他公司也会发力。因此，在模型竞争极度激烈、生态不断变化的阶段，打造一个中立、开源、能够接入所有模型的产品，是具有战略价值的。

主持人： 所以你们一开始并非从“我要打造最聪明的助手”出发，而是从“我要先占据最重要的位置”出发。

Dax： 差不多就是这个意思。我们起步时只有三个人，都是联合创始人。后来邀请了一位朋友协助我们开发早期版本，成为第四位成员。之后我们又拉来了一位一直很想合作的优秀设计师，那是上线后的事情，大概在秋天。团队其实很小，但一旦方向想清楚，后续许多行动就顺利了。

从 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 点突然悄无声息地发布封禁，没有事先沟通，也没有分阶段实施，那就是在制造一个“众矢之的”的局面。哪怕提前一个月说明情况，分步骤推进，用户虽然仍会不满，但不会形成如此集中且强烈的愤怒情绪。

主持人： 当时你们慌了吗？毕竟那时 Claude 还是最强大的编程模型。

Dax： 反而没有。我们其实早有预感这一天会到来，不知为何，真发生时团队甚至有些兴奋。因为我们很清楚，我们所处的舆论环境会扭曲现实。尤其在 X 平台上，似乎人人都有 200 美元的 Claude Max 订阅，但那绝不代表真实世界。当时我们已有 65 万月活用户，不可能所有人都在每月花费 200美元。对绝大多数普通用户来说，在任何服务上每月支出 200 美元都不是小事。所以我们明白，受影响的只是一部分人，而非全部。

更重要的是，在这件事发生前的几周，我们已经在与几乎所有其他公司洽谈“官方支持 OpenCode 订阅接入”事宜。微软方面已同意 GitHub Copilot 正式支持 OpenCode；我们也在与其他几家公司在推进合作，只是尚未对外公布。唯一尚未正式接触的巨头是 OpenAI。所以那天晚上事件爆发后，我在 X 上被频繁提及，大家都在说“他们封了、他们封了”。我当时就想：时机到了。我立刻联系了 OpenAI，告诉他们，明天一早所有人醒来都会对 Anthropic 感到愤怒。你们现在有一个绝佳的机会，只要公开站在对立面，宣布正式支持 OpenCode，就能轻松赢得一场公关胜利。结果第二天早上，他们就同意了。

于是当天早上，很多人都在议论“Anthropic 一封杀，OpenCode 就完了，彻底归零了”。我心里一直在暗笑。我想，你们就等到今天结束再看吧。随后我们迅速完成了技术集成，并在当天结束前对外宣布：OpenAI 正式支持 OpenCode。

主持人： 所以这并不是一次偶然的运气，而是你们非常熟悉的一种策略运用。

Dax： 没错。回顾 OpenNext 的发展历程，你会发现我们一直在采用一种策略：找到一个阶段性的“反派”，然后团结它所有的竞争对手，借助这股力量推动事情的进展。很不幸，Anthropic 在那一刻就扮演了这个角色。于是我们迅速动员行业内的其他参与者，让他们都来支持 OpenCode、支持更开放的模型接入。对于小公司而言，只要你的立场站对了，世界就会不断为你送来意料之外的机会。

如果存在一个足够中立的中间层，所有那些投入数百亿美元的大公司，都会出于自 身利益来利用这个中间层。这正是处于中间位置的战略优势所在。未来 OpenAI 当然也可能成为下一个“反派”，那时我们或许又会联合其他力量来制衡它。这本来就是市场竞争的常态。

主持人： 但也因此，你们受到了一些批评，有人认为你们对 Anthropic 过于苛刻。

Dax： 是的，会有这样的声音。但别忘了，他们是体量巨大的公司，是百亿美元级别的巨头。像我们这样的小公司，想要施加一点点影响力都极为困难。这就是现实中的博弈逻辑。你可以非常喜欢 Claude Code，完全不打算更换，这没问题；但你最好仍然支持“别人有权选择自己想用的工具”，这本身是一件好事。

4 OpenCode 的成功之道：先追求极致顺手，而非极致聪明

主持人： 回到产品本身来探讨。为什么在市场需求如此旺盛的情况下，这个赛道位置竟然空置出来，最终被你们占据了？

Dax： 我认为开发者工具领域最大的结构性优势在于：所有做这类工具的人本身就是程序员，而程序员通常特别不擅长打造面向大众消费者（B2C）的产品。他们往往没有意识到，真正能实现大规模成功的开发工具，本质上都是 B2C 产品。当然，你也可以选择走自上而下的路线，通过企业采购流程来推广工具，这也能成功。但那些真正从个体开发者开始自发传播、最终成为行业标准的产品，几乎都是自下而上发展起来的。你必须用打造消费品的思维来对待它。

因此，我们极度重视用户首次打开 OpenCode 时的体验。它必须带来显著的差异化和优越感。为此，我们甚至从底层开始自主研发了一个终端渲染框架。 Claude Code 以及许多其他终端型编程助手没有这样做，它们更多是基于 Ink 等现有方案来快速满足需求。但我们愿意提前投入这笔成本，因为只要用户一上手，就能立刻感受到：这款产品是经过精心打磨的。它可能不适合所有人，有些用户或许会觉得它过于激进、信息量过载，但你至少会带着一个明确的判断离开：打造这款产品的团队是具备真才实学的。

我们还非常注重降低一切使用门槛，尽可能让用户迅速进入“开始编写提示词”的状态。例如，在一台被企业严格管控的笔记本电脑上，能否顺利安装和使用？这些看似不起眼的问题我们也在深入思考。坦白说，我们最初几个月的核心引擎（harness）表现并不出色，尤其是前五个月。它并非最聪明的引擎，但它“足够好用”，而且大多数用户在初期根本察觉不到差距。我们的策略是先抢占用户市场份额，然后再回头逐步优化引擎，让它变得更聪明、更高效、更强大。市场上其他玩家起初的想法是：“先做出最聪明的引擎，再去赢得市场”。而我们的逻辑恰恰相反：先打造极致体验并推动广泛采用，然后再提升底层技术能力。结果就是，我们凭借一个“中等水平的引擎”，先成为了用户数量最多的产品，之后再持续夯实底层技术。

主持人： 你们后来也尝试过图形用户界面（GUI）和桌面端应用。

Dax： 是的。我们曾用 Tauri 框架开发过一个桌面应用。但老实说，那一步大体上是我们的一次失误。我个人非常热爱终端，我的全部工作都在终端里完成。但当你看到我们的用户数接近 800 万时，你就会意识到：不可能真的有 800 万人都在终端环境下工作效率最高。对于许多用户来说，在图形界面下的体验会更好。我们其实很早就认识到了这一点，所以同时尝试了 Web 应用和桌面应用。方向上是正确的，问题在于我们没有投入足够的重视去推进，行动不够迅速，技术选型也不够审慎。后来我们决定重新转回使用 Electron 框架。

主持人： 还有一个有趣的点，你们没有采用那种“在 GitHub 拉取请求上自动添加品牌水印”的增长策略。很多其他工具都在这么做。

Dax： 我们一开始其实也做了。因为早期 OpenCode 在某种程度上有点像 Claude Code 的仿制品：它做什么，我们就跟着做什么。所以提交信息里也会出现“committed with OpenCode”之类的标识。后来越来越多的用户询问能否关闭这个功能。我思考后觉得，这种做法太低级了。就像赌场用各种小伎俩把顾客困住一样。我并不是说做消费品就不能做增长，但我认为没必要做到那种程度。这种增长手段太露骨了，所有人都能看穿你的意图。最后我们干脆把它默认关闭了。

5 OpenCode 的盈利模式：控制台、推理服务与“推理业务的高利润潜力”

主持人： 聊到这里，还是得面对一个现实问题：你们毕竟是一家商业公司。OpenCode 的商业模式究竟是怎样的？

Dax： 目前主要有两个业务方向。第一条业务线最初其实是为了优化新用户引导流程。OpenCode 刚推出时，用户需要自行对接各大模型厂商的账户，操作起来相当繁琐。而且当时即便注册了账号，也未必能获得足够的使用额度来频繁使用 OpenCode。因此我们决定，至少应该提供一个统一的推理服务，让用户注册一次就能获得充足的额度，并且可以接入多种模型。于是我们开发了 OpenCode Zen。

起初它只是一个辅助新手上路的工具层，但增长势头非常迅猛。再加上开源模型日益普及，我们发现：高质量地托管开源模型，实际难度远超人们想象。因此 Zen 逐渐演变为一个聚合优质模型推理服务的平台。前沿模型固然重要，但如何以最低成本、最稳定、最优性能的方式托管开源模型，同样至关重要。这项业务增长极快。我们在几个月前曾对外透露，Zen 上线大约五六个月后，年化收入已达到五千万美元。其中的利润率也可能相当可观，尤其是一些开源模型，如果托管方案得当，利润空间会非常理想。

第二条业务相对常规，但却是企业的刚需。假设一家拥有一千名工程师的公司要使用 OpenCode，不可能让每个人自行下载安装，再分别填写 API 密钥。企业必然需要一个统一的管理界面：供应商管理、权限分配、预算控制、使用配额、审计日志、策略配置等，都需要集中管控。因此我们推出了相应的产品。它同样是开源的，但大多数公司会选择直接购买我们的托管版本。未来它会更加开放，目前主要还是以企业部署形式为主。

还有一点非常关键：企业现在终于开始认真审视自己在大模型上的开支，并开始追问：“我们到底在做什么？这些投入真的带来了更多成果吗？”这对我们而言是一个很好的机遇，因为开源模型已经变得极具竞争力，且成本大约只有十分之一。企业购买我们的管理平台后，往往也会顺带接入我们的推理服务，开始混合使用更经济的开源模型。如果未来推理服务成为我们更核心的收入来源，我们甚至可能不再对管理平台本身收费，而是主要依靠推理服务盈利。

主持人： 你之前还提出过一个颇具争议的观点：推理业务其实利润非常丰厚。这对许多软件工程师来说，听起来有些反直觉。

Dax： 这是因为大家容易将训练成本、研发成本与推理业务混为一谈。如果单独审视“纯推理”这个环节，理论上的成本底线其实就是电费。当然前期还有购买 GPU 的资本支出，以及运维团队、基础设施等投入，但一旦硬件就位，生成一个 token 的最低成本，就接近于给这些机器供电的费用。我们自己也大规模租用 GPU 来运行模型，而且我们甚至尚未直接触及最底层硬件，中间还隔着一层供应商。但即便如此，对比某些模型的标价和我们自身的成本，中间的利润空间可能接近 80%。

另一个常被忽视的事实是：市场价格实际上在攀升。表面上看，模型似乎越来越便宜，但从用户的实际使用结构分析，情况恰恰相反。过去，用户普遍默认使用 Sonnet，因为 Opus 价格过高；后来 Opus 价格下调，大家便转而默认使用 Opus，但即便降价后，Opus 仍远贵于 Sonnet。因此，从整个市场的消费组合来看，实际支付的价格是上升的，而托管这些模型的基础成本并未同步增长。如果 Anthropic 或 OpenAI 这类公司本身能够签订大规模的 GPU 采购合同，我完全不会惊讶他们在某些阶段实现高达 90% 左右的推理毛利率。当然，这种利润率未必能长期维持，但在当前阶段，这一数字并不夸张。这让人联想到早期的云计算市场。外界普遍认为云服务竞争惨烈、普遍亏损，但真正参与其中的人都清楚，云业务本身可以非常盈利。只是这些公司并无动力主动纠正外界的悲观叙事。AI 领域也是如此。训练阶段固然烧钱，研发成本也高得惊人，但从长远来看，推理作为一项独立的商业模式，本身是完全可以成立的。

6 从创业公司到大厂，整个行业都在争抢算力

主持人： 但你之前也提到，即使是像你们这样的公司，也已经受到 GPU 资源的制约。

Dax： 因为目前整个 GPU 供应链都处于极度紧张的状态。从 GPU 生产、配套硬件、供应链管理到相关人力资源，整个链条都绷得很紧。与此同时，推理需求仍在疯狂增长，我甚至怀疑它并非线性增长，而是接近指数级攀升。然而，GPU 的产能扩张更接近线性过程。当这两条增长曲线相交时，资源短缺就必然发生。对我们而言，想要获取用于推理的 GPU 容量，往往需要提前预订并预付费用。因为所有人都在囤积资源，市场普遍预期这种紧缺状态将持续下去。如今，要获得稳定的推理容量确实非常困难。外界看到创业公司融资 20 亿美元，可能觉得已是天文数字，但大型科技公司在 AI 上的年度资本支出可达数百亿甚至上千亿美元。像 Amazon、Meta、Google、Microsoft 这个级别的巨头，几乎吸走了整个供给侧的绝大部分资源。如果你是供应链上的一家公司，他们根本无暇与小型公司洽谈，而是优先处理与大厂的订单。所以，当前的供应确实异常紧张。不过根据我的经验，任何行业只要出现短缺，通常随后都会迎来一轮激烈的投资，并最终走向产能过剩。这次或许会有所不同，但历史上更常见的路径是：先经历紧张，再出现过度供给。只是至少在当下，AI 领域的这条供给线依然紧绷。

7 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 编程工具的最终净结果，仅仅是“完成了同等的工作量，但工程师们更开心了，因为工作变得更轻松”。对许多公司而言，这还不够。他们可能会说，那你还是回去手动敲代码吧。

主持人： 但从另一个角度看，不少 CTO 也会表示，如果不提供优质工具，顶尖人才就会流失。

Dax： 这一点确实存在。特别是在高端人才市场中，一个能力出众的人才本就拥有无限选择，如果每天还要被繁琐的流程和落后的工具所困扰，他们确实会离开。我知道有实例就是如此。因此，顶尖市场的逻辑与整体市场的情况并不相同。只是我们现在看清了世界的广阔面貌：绝大多数公司实际上并未参与到“前沿工具竞赛”的那个层级。许多公司最终的现实是：提供给你一个 Copilot，通过 OpenCode 接入，额度固定，用完即止。并不会因此就立刻被时代淘汰。

8 Dax 发给团队的那份内部备忘录：停止功能堆砌，别再依赖AI代理暗中埋雷

主持人： 你之前发给团队的那份备忘录被很多人转发。你在其中指出了三个核心问题：我们发布了太多价值不大的功能；功能原始设计存在缺陷，却不断叠加补丁，而LLM会进一步放大这些补丁的影响；以及我们需要投入更多时间清理技术债务。你当时是基于什么考虑写下这份内部信的？

Dax： 因为这些问题是长期存在的，只是LLM让它们变得更加突出。首先是功能发布过于随意。过去，面对用户需求、竞品动态或内部创意，开发成本会让你有所顾虑。现在却可以轻易地“让AI代理做一个”。用户提需求，一句话；竞品出新功能，也是一句话。结果你以为堆出一千个功能就等于打造了好产品，实际上却造出了一个臃肿的怪物，一个技术上的“弗兰肯斯坦”。任何功能一旦上线，几乎就需要永久维护，未来所有新功能都必须与之兼容。因此，我们必须比以往更加克制。不是因为能快速产出十倍的功能，就意味着我们突然拥有了十倍的好创意。

第二个问题更严重：补丁式开发。以往为系统增加新能力时，如果系统架构不支持，你通常面临两个选择：要么从第一性原理出发，重构系统以优雅地实现新功能；要么临时打一个补丁。这个权衡一直存在，你会评估补丁的丑陋程度与功能的重要性。但现在，AI代理能轻松帮你打上补丁，甚至后续还会继续“处理”这些补丁引发的连锁问题。这扭曲了你的判断力。你更容易说服自己“先临时解决一下”。许多本应暂停、重新思考系统设计和架构优化的节点，现在都被我们用补丁草草掩盖了。

主持人： 你后来提出了一个很精准的比喻：以前工程师写补丁时会有一种“刺痛感”。明知自己在做不妥的事，内心会感到不安。这种感受其实在帮你校准决策。但AI代理把这种感受消除了。

Dax： 没错，这个形容非常贴切。以前亲手写补丁时，你会觉得不对劲，隐隐感到不安。第二次、第三次再这样做时，这种不适感会累积。你清楚自己是在为未来埋雷。而现在，因为是“另一个东西”在替你处理，那种不舒服的感觉被弱化了。问题并未消失，地雷依然存在，只是你当下不那么痛了。于是你的判断失真了。人生中许多事都依赖正确的反馈机制。如果感受不到疼痛，你就会持续做出错误的选择。

主持人： 第三点是“清理”。但创业公司最缺的就是时间。清理代码看起来并不能直接带来新用户或收入增长。

Dax： 这确实很难。每天一睁眼，就有无数声音催促你做A、B、C；每天都有新竞品出现；我们仿佛被海量信息裹挟着向前。如果完全被这些外力牵引，我不认为最终能抵达理想的彼岸。但有趣的是，清理技术债务现在反而比过去容易得多。以前即便发现了更优的代码模式，往往也只能在新代码中应用，旧代码体量太大，没人愿意回头重构。现在不同了。你可以让AI代理将旧代码整体迁移到新模式下，甚至能系统性替换整个代码库中的陈旧结构。技术债务从未像今天这样容易被彻底清理。我当然明白这不会直接转化为明天的收入。但我想打造的是一个五年后我们仍愿意在此工作的环境。世界上有很多成功的公司，但如果让你任意选择一家去工作，你大概不会选其中99%的企业。我不希望公司成为那99%中的一员。我希望确保这里在五年后，仍然是一个让大家每天工作起来感到愉悦的地方，而不是一个人人避之不及、终日与遗留问题缠斗的泥潭。

主持人： 你在备忘录中还写下一句很尖锐的话：最糟糕的是，我甚至不觉得这些牺牲真的换来了更快的速度。我感觉我们只是在以“正常速度”前进，却误以为自己正在飞速奔跑。

Dax： 没错。我们“以为”自己跑得飞快，但回过头看，其实未必。我们和竞争对手的速度差距并不明显，甚至可以说看不出显著优势。因此，如果要真正讨论生产力，最大的风险其实是：人太容易自我欺骗。你觉得自己效率爆棚，可一旦静下心来认真审视，往往发现事实并非如此。对我而言，这恰恰提醒我们，要重新相信“先慢下来，打好基础，再全力冲刺”的价值。

9 9 反炒作、重品味、强调反馈：OpenCode 真正的工程文化

主持人： 你还有一个特点，就是热衷于对各类 AI 预测“泼冷水”。例如那句广为流传的说法：“24 至 29 岁的工程师将很快成为科技行业最有价值的人群，因为他们兼具前 AI 时代的准则与后 AI 时代的速度。”你公开表示这纯属无稽之谈。

Dax： 因为我实在厌倦了。每天醒来浏览资讯，满眼皆是预言：未来必定如何、哪些人注定成功、哪些公司必然消亡。大家都在凭空臆造。那句尤其可笑，因为它本质上在宣称“像我这样的人占据所有优势，不像我的人则面临所有劣势”。一目了然，发表此言论的人自身正处在 24 到 29 岁这个年龄段。我认为这些预测背后的心理机制非常简单：我们都身处一个剧烈变革的时代，每个人都在焦虑自己在这场变革中将处于何种位置。最自然的心理防御机制，便是极度自信地预言一个“自己将获胜”的未来。几乎所有的热门预测都可以归结于此：我的公司会赢，别人的公司会输；我的工作不会被 AI 取代，别人的工作则会。人们会为自己编织一套看似理性的解释，但更深层的事实是：大家都在恐惧。

我也会感到紧张，也会担忧。只是我越来越不相信那些宏大而确定的论断。历史上真正发生的事件，几乎从来不是当时看似最显而易见的版本。最终落地的结果往往极其反直觉，只不过事后回顾时，又会觉得“仿佛一切本就顺理成章”。因此，我宁愿只思考明天与后天：今天该做什么，明天该做什么。一年前我未曾预料自己今日会从事此事，一年后我也不知自己将身处何方。

主持人： 回到产品与工程方法论。你认为自己从早期至今，有哪些原则始终未变？

Dax： 一个最朴素的原则是：你的产品中很可能只有一个真正出色的核心创意。那你最重要的工作，便是让用户尽快体验到这一创意。听起来很简单，但随意试用市面上的许多产品，你就会发现从“听说这款产品”到“感受到其价值”之间，开发者常会不知不觉地塞入大量冗余步骤。我自己会每隔两周进行一次“首次使用体验”测试：启动一个新的 Docker 容器，重新运行 OpenCode，从零开始安装并使用。每次都能揪出我们无意中添加的摩擦点。对我来说，产品工作并非“用户提出一个问题，你立刻发布一个对应功能”。真正的产品工作，是吸收大量问题，然后找到一种解决方案，能够同时解决五十个问题。这很难，依赖经验、思考、与用户交流、理解团队、理解代码库。AI 到目前为止，在这件事上未曾给我带来丝毫帮助。

主持人： 那你如何提升这种“产品感”或“品味”？

Dax： 本质上仍是反馈循环。设计出错，会有真实用户来批评你；代码架构不佳，下次添加功能时你就得亲自深入泥潭。只要团队中的每个人都暴露在这种反馈之中，个人成长就会非常迅速。许多组织的问题恰恰在于将人员隔离。产品团队为赶工期，砍掉了某些部分；结果承受痛苦的是客服团队、支持团队，以及最终仍在现场手动救火的人员，而真正做出决策的人却完全感受不到。因此对我们而言，必须尽力让决策者与后果承担者尽可能成为同一批人。

Dax： 本质上，这依然是一个反馈循环。设计出现偏差，真实的用户会立刻提出批评；代码架构不够完善，下一次迭代时你就得亲自收拾残局。只要团队中的每个成员都能直面这种反馈，个人成长的速度就会非常快。许多组织的问题恰恰在于将人员隔离开来。产品团队为了赶进度，可能会简化某些环节，但最终承担后果的却是客服、技术支持团队，甚至是需要手动解决问题的现场人员，而真正做出决策的人却完全感受不到压力。因此，对我们来说，核心原则就是确保决策者与后果承担者尽可能重合。

目前我们团队有二十多人，最近三个月扩张得很快，所以也进入了一个比较棘手的阶段：人数虽然增加了，但整体效率反而处于最低点，因为大家还在相互磨合、熟悉流程。作为一家开源公司，我们的代码完全公开，因此很多工作自然就是在公开环境中进行的。我们内部将新功能的开发大致分为两个阶段：第一阶段是“从零到一，把想法推上轨道”，这个过程非常痛苦，因为很多东西都还不存在；第二阶段是“虽然尚未完成，但核心问题已经基本清晰”，我们通常将这个节点定义为“至少可以对外演示”的里程碑。我们会全力以赴，尽快将项目推进到这个阶段。一旦达到这个点，用户的声音就会变得非常清晰，他们会明确告诉你接下来该做什么、哪里不好用、还缺什么功能。这样一来，工程师就能直接从 GitHub issue 或 X（原 Twitter）上的反馈中获取信息，自主规划后续路线，无需中间层进行过滤或总结。

作为创始人，我们尽量让团队充分理解市场环境、竞争对手、产品定位以及我们为什么要做这件事。只要背景信息给足，大家通常能自然而然地做出相对合理的优先级判断。我们非常重视动机，因为这是一场长跑。既然是长跑，最重要的策略就是：如何让自己尽可能长时间地留在牌桌上。而唯一可持续的方法，就是每天做那些真正让你感到兴奋的事情。因此，我们经常鼓励团队直接去解决他们认为重要、且真正感兴趣的问题。有时候我会明确反对某个方向，但最后证明团队是对的、我是错的，这种情况反而让我非常高兴。

主持人： 我们还没正式聊到“品味”这个话题。现在很多人认为，AI 很难替代的一种能力就是 taste（品味）。

Dax： “品味很重要”这个观点当然是对的，但问题在于：你是否真的相信它？很多优秀的观点都很简单，所以人人都会重复。但简单不等于容易践行。你说你相信品味、重视质量，那你是否真的愿意为此做出那些看似“非理性”的投入？因为很多伟大的产品，哪怕少做 50% 的细节打磨，短期内的商业结果可能也看不出太大差别。但那种对质量的妥协，会像感染一样逐渐蔓延：你在一处开始松懈，最终会在所有地方都放松标准。现在有一种很强的舆论氛围，认为代码不必写得太好、产品不必做得太精、什么都不必太讲究，只要商业上能赢就行。一旦这种念头真正进入你的思维，你就再也做不出好产品了，因为你已经不再相信这件事本身。

在我欣赏的人中，Mitchell Hashimoto 肯定算一个。他们公司的路径和我们理想中的方向非常相似：开源、被广泛采用、最终成为行业标准。Terraform 就是最典型的例子。他后来做的 Ghostty，我也非常喜欢，其中对架构、细节和产品体验的处理，都能让人在实际使用中感受到。他有一个观点我特别认同：做产品不是在堆砌功能，而是在思考每一个新功能会如何与现有功能产生交互。这才是产品工作的本质。

而且我现在越来越强烈地感受到，AI 时代产品的“腐烂”速度比以往快得多。无论是大公司的产品还是创业公司的产品，都在加速变质。现在一个产品如果已经开发了一年，可能就已经开始出现腐化的迹象。正因如此，质量反而可能成为更强大的差异化因素。但质量不是靠嘴上说一句“我们重视质量”就能实现的，它必须体现在公司的每一个层面，而且往往源于一些看似不理性的决定。比如我们当初决定自研终端框架，按教科书上的说法，这是最不应该做的事，所有人都会告诉你“不要重复造轮子”。但我们清楚自己想要的体验，也知道 NeoVim 这类工具已经把终端体验推到了什么高度。既然知道边界在哪里，我们就不愿意交出一款远低于那个水准的产品。早期很多用户从 Claude Code 转过来，第一感受就是：OpenCode 的终端体验更流畅、更稳定、闪烁更少。这种差异，在某种意义上，正是靠那些“看似不理性”的决策换来的。

主持人： 最后聊聊你自己吧。你的工作环境是什么样的？

Dax： 我目前的工作环境以 Framework 台式机为核心，运行 Arch Linux 系统，外接一台 5K 显示器。麦克风用的是 SM7B，摄像头则直接用 iPhone 替代。物理设备只是入口，我所有实质性的工作都在远程服务器上完成——那台机器性能更强，通常会开启多个终端会话，每个项目独立一个。编辑器是 NeoVim，通常左边是 NeoVim，右边是 OpenCode，两边并排显示。我的工作流基本就是在这两个窗口之间来回切换。

主持人： 在 AI 时代，工程领导者的角色发生了怎样的变化？

Dax： 现在很多人都在思考：如果工程师不再主要亲手写代码，那他们的价值究竟体现在哪里？有种观点认为，工程师的职责变成了“构建足够安全的系统，让其他人或 AI 能安全地提交代码”。比如通过测试、防护机制、规范、模式、约束等手段，确保无论是人还是智能体在修改代码时，都不会把系统搞崩溃。我觉得这个说法有道理，但从某种角度看，它一点也不新鲜。我们一直以来都在试图解决类似的问题：如何让经验尚浅的工程师也能相对安全地发布代码？如何让代码库结构更清晰、测试更可靠、规范更明确？以前是为了初级工程师，现在只不过多了一批 24/7 工作的“笨助手”——也就是各种编程智能体。

所以一些传统的理念反而会重新受到重视。我们团队一直比较认同领域驱动设计，只不过以前实践得比较轻量。现在我们反而开始更深入地采用它，因为那些曾经显得“企业味”浓重、略显繁琐的模式，在当下重新变得有用。过去大家讨厌它们，是因为手动实现起来太麻烦、敲代码累；但现在代码不是全靠人手写了，所以它们的缺点被弱化，而优点——可靠性、模块化、安全性、边界清晰——被放大了。我甚至觉得一些经典的设计模式也可能重新流行。以前高手觉得它们像“辅助轮”，嫌多余；可现在智能体没有“辅助轮”，那你可能就得重新给它装上。

主持人： 对于资深工程师，你有什么建议能帮助他们在新时代保持竞争力？

Dax： 我不太敢轻易给出普适性建议，因为我们公司本身就很特殊：既是创业公司，又是开源公司，所处的市场也很独特，很多经验未必适用于所有人。但如果非要说一点，我会分享一个在 AI 时代之前我就深信不疑的观点：软件工程能力本身当然是一种高度可迁移的技能，你完全可以只做一名“优秀的软件工程师”，这本身就能支撑起很好的职业发展。但如果你还能成为某个特定行业的专家，这个组合将会极具竞争力。

比方说，如果你投身农业软件领域。假如你真正懂农业，同时又是一名不错的软件工程师，那你很可能已经是全球范围内排名前十的稀缺人才组合了，整个行业都会需要你。最棒的是，软件工程师与其他职业不同，你不必在 22 岁就决定自己一辈子绑定某个行业。你可以在医疗行业干十年，再转向农业，之后再进入其他领域。每在一个行业深耕一年，你对那个领域的理解就可能超过 99% 的同行。工程师最大的优势之一，就是你能进入世界上几乎任何行业，并且真正吃透那套业务逻辑。问题在于，很多人太容易把自己变成纯粹接需求的人——“加个界面、改个接口”，却从不主动去理解自己所处的行业。而这恰恰是你最应该抓住的机会。

主持人： 最后来个轻松点的问题。有没有什么书可以推荐给大家？

Dax： 有趣的是，我几乎不读书。我太太是个书迷，她读完书后会把最精彩的观点分享给我，然后我就把这些想法当作自己的见解说出来。如果非要说的话，早年我确实有过一段认真阅读的时光。Nassim Taleb 的几部作品对我影响很深，比如《利益攸关》（Skin in the Game）和《黑天鹅》（Black Swan）。这些推荐可能有些老生常谈，但一本书里真正关键的，往往就是那一两个根本性的洞见。我特别着迷的一类概念是“涌现”和“自下而上系统”。世界上许多伟大的事物，并非出自某个自上而下的总设计师之手，而是无数微小个体在局部互动中逐渐演化而成的。无论是稳健的软件系统、充满活力的城市街区，还是生物对抗疾病的能力，你都能看到这种自下而上的力量。如今我在观察很多事情时，都会不自觉地套用这个思维框架。

对话进行到最后，其实留下了一个比“OpenCode 为何增长如此迅猛”更有价值的问题：当 AI 让代码生成变得越来越廉价时，真正稀缺的到底是什么？Dax 给出的答案非常朴素——不是更快地敲代码，而是判断什么值得做、什么不该做；不是盲目堆叠功能，而是守住产品的整体性；不是把临时方案丢给 AI 代理，而是维护工程系统的反馈回路；不是沉迷于“未来必将如何”的口号，而是在不确定性中坚持做好眼前的事。

如果说 OpenCode 的爆发式增长标志着 AI 开发工具的时代已经来临，那么 Dax 的这场访谈则提醒我们：真正决定一家产品公司能否活得长久、活出品质、活出尊严的，依然是那些看似“老派”的要素——节制、质量、品味、上下文意识、反馈机制，以及对系统后果的敏锐感知。