Dax Raad：OpenCode 为什么开源、如何赚钱，以及 AI 编程工具的下一步

欢迎回来。今天和我们一起的是 Dax Raad。感谢你来参加直播。

谢谢，这个开场很隆重。今天应该会很有意思。

对那些没有真正使用过代理编程、或者只远远看过 Claude Code CLI 的开发者，你会怎样解释 OpenCode？他们为什么值得试一试？

OpenCode 是我们用大语言模型做编程实验的地方。这个概念当然不是我们发明的，已经有很多迭代；Claude Code 是目前最大、最流行的实现之一。它把代理放进一个简单的终端应用里：你给出任务，让代理工作，然后审查结果。

我们最初做的，基本就是 Claude Code 的开源版本。直到今天，我们仍会跟进它的很多功能，但主要区别有三个。

第一，OpenCode 是开源的。第二，它不锁定某个模型供应商。Claude Code 使用 Anthropic 模型，而 OpenCode 允许你使用任何能够访问的模型：直接购买 API、通过 GitHub Copilot，或者通过受支持的订阅入口。

第三，我们非常认真地打磨终端界面。终端能做的事情远比多数人想象得多，只是相关技术很冷门。现在的 OpenCode 只是地板，不是天花板，我们还有很多计划。

真正把我吸引到 OpenCode 的就是终端 UI。我本来就喜欢终端，也做过终端工具。使用 OpenCode 一个月后再回到 Claude Code CLI，会感觉像回到了过去。为什么一家资源更大的公司，终端体验反而没有你们好？

在 JavaScript 生态里，以前构建复杂终端应用最常见的选择是 Ink。它让开发者用 React 写组件，只是把渲染目标从网页换成终端。

Ink 很有创造性，但我认为它最初更像概念验证。因为真正理解终端 UI 的人太少，它后来被很多产品采用，远远超出最初设计边界。随着用户、操作系统、终端类型和功能数量增加，性能与能力限制都会暴露出来。

Claude Code 团队早期可能只是在快速验证想法，并不是有意选择一个长期基础。当产品突然增长到数百万用户，原本简单的框架就开始承受大型产品的重量。

我们选择了相反路线：一开始就投资构建尽可能强的终端框架，而不是先在受限框架上不断堆功能。

我们开发了 OpenTUI。它是一个 Zig 库，负责底层终端 UI 概念，包括布局引擎、鼠标点击、元素相交、合成、透明度和颜色混合。

浏览器里，人们已经习惯创建区块、安排布局、叠加对话框、做背景变暗和语法高亮。OpenTUI 把这些能力带到终端，再通过 React 或 SolidJS 绑定暴露给上层；OpenCode 自己使用 SolidJS 绑定。

OpenTUI 主要由团队成员 Sebastian 维护。他在认识我们之前就开始做相关项目，后来我们相遇，决定完整资助这项工作。他非常出色。

Claude Code 不是全屏 TUI。那种方式有没有自己的优势？

有。OpenCode 会接管整个屏幕，相当于绕过终端很多原生行为，所以滚动、文本选择、复制粘贴等功能都要自己重新实现，目前并非每一项都完美。

Claude Code 主要把文本写进终端的 scrollback，原生滚动和复制更自然。代价是它很难做复杂屏幕、审查页面和高级交互。两种方案是不同权衡；我们的目标是逐渐接近原生体验，同时保留扩展空间。

很多人看见用户可以自己接 API，又知道 OpenCode 是开源的，就会问：你们怎样支付这些开发成本？谁在付账单？

开源商业模式经常被误解。很多人试着围绕开源成立公司，大多数会失败。有人把它叫作需要两次奇迹的生意。

第一次奇迹，是做出真正优秀、被大量人使用的开源产品。不能只有少量用户。既然选择开源，目标就应该覆盖整个市场。世界上有三千万到五千万开发者，没有理由阻止他们中的任何人至少尝试 OpenCode。

第二次奇迹，是在开源产品之上建立一个完全独立、有人愿意付费的产品。最危险的做法，是把开源核心中已有的功能移走、改成付费，或者故意削弱免费版本。那会逐渐杀死整个项目。

对 OpenCode 来说，付费层很清楚。大型公司把 OpenCode 部署给一千名开发者以后，会遇到一组物流和治理问题。

企业不想给每位员工手工分发 Anthropic API Key，也不想在员工离职时逐一禁用，更不希望密钥泄露。他们需要一个控制平面：统一配置供应商凭据，接入内部 OAuth，并向终端用户发放临时凭据。

这个控制平面还可以设置预算，例如每人每月最多花五百美元；也可以查看使用分析、管理团队策略。我们会对这一层收费。产品已有一些早期客户，但还没有完全做完。

开源业务总会形成一座金字塔，不过是好的金字塔，不是骗局。底部是日常开发者，他们可能永远不向你付钱；顶部是企业，收入主要来自那里。

顶部能有多大，取决于底部有多大。一百万用户和三千万用户，会产生完全不同的企业机会。所以我们首先专注于把免费工具做得足够好、让尽可能多人采用。

这只是目前的主要模式。我们的推理服务收入也在增长，原本没打算靠它赚很多钱，但它开始产生利润，所以长期结构仍可能变化。

官网写着 Zen，GitHub 组织又叫 Anomaly。它们分别是什么？

Anomaly 是公司的名字，不是刚成立的新团队。我们已经存在很久，也长期从事开源工作。OpenCode 是其中一个产品，因为增长很快，已经成为主要焦点。团队目前大约十个人。

OpenCode 本体坚持自带供应商：你可以接入任何模型，自己配置，我们不要求用户使用特定服务。

OpenCode Zen 是可选的开箱即用服务。对于不想分别注册 Anthropic、OpenAI、配置多组 Key 的用户，Zen 提供一个账户，接入多种主流编程模型，并尽量保持有竞争力的价格。

所以关系很简单：Anomaly 是团队，OpenCode 是开源产品，Zen 是可选的统一模型服务。

Anthropic 最近增加了一些限制，影响 OpenCode 用户通过订阅使用 Claude。你认为这是直接针对 OpenCode，还是 OpenCode 只是副作用？

Anthropic 推出过每月两百美元的 Max 订阅，额度非常慷慨，从纯推理成本看甚至有些不经济。OpenCode 很早就支持 OAuth 插件，因此有一个流行插件让用户用 Claude Max 订阅登录。

这一直不符合 Anthropic 的服务条款，并不是他们正式支持的方式。使用者也不是 OpenCode 用户的大多数，但当我们有约一百万活跃用户时，即使百分之十也是十万人。

Anthropic 的商业漏斗是先用 Max 订阅推动 Claude Code，再让团队采用，最终卖企业合同。企业合同不只是订阅，还会包含席位和按量 token 计费。因此，如果用户拿 Max 去使用别的工具，就不符合他们原本的产品策略。

后来他们尝试阻止第三方客户端，最初看起来像通用限制，之后逐渐表现为针对 OpenCode 的识别。这里需要说清楚：这是他们的公司，他们可以执行自己的条款；从公司的角度，这并不邪恶。

同时，Dax 表示，按照他的理解，付费终端用户也可以选择如何访问服务并尝试绕过限制；公司则可以继续阻断。社区每次遇到阻断，很快就会找到绕过方式。因为 Anthropic 不能采用会让旧版 Claude Code 客户端全部失效的办法，所以这变成了猫鼠游戏。

我们早就预期会发生这种事，因为双方战略相反。Anthropic 更倾向于把模型和最终工具垂直整合；我们的理念是，用户不应该为了一个模型就把全部工作流绑定到某个工具上。

如果明天 OpenAI 或其他供应商给出更好的模型，用户应当能够切换，而不必重建整套工作流。模型会不断变化，因此 OpenCode 希望终端工具保持开放。

限制以后，我改成直接使用 API，两周大约花了五百美元。这个数字让我重新感受到订阅补贴与真实 API 成本之间的差异。

对，这正是问题的经济基础。用户会失望，但供应商也会重新评估这种补贴是否可持续。

我们不是在限制发生后才临时行动。此前几个月，我们一直与其他模型供应商沟通，希望它们正式支持 OpenCode。GitHub 现在已经正式支持 OpenCode。

Anthropic 在周四晚上采取限制后，我马上联系 OpenAI，告诉他们这是一个反向定位的机会：很多人会对 Anthropic 不满，如果 OpenAI 允许用户自由选择终端工具，会获得很大善意。

OpenAI 行动很快，所以 ChatGPT Pro 订阅现在可以用于 OpenCode。我们也宣布了 GitLab 支持，还有几家大公司会在接下来几周正式支持。

市场定位因此很清楚：Anthropic 更像是在做全栈垂直整合，而其他供应商更愿意只提供模型，让用户选择最终工具。

换一个话题。最近你们推出了 OpenCode Black。它是什么，下一批账户什么时候开放？

我们看到 Anthropic 有二十、一百、两百美元的订阅档位，很想理解这些档位背后的真实用量：平均二十美元用户用多少推理？一百和两百美元用户又用多少？我们想知道能否提供相似方案。

我们无法匹配 Anthropic 对自家模型的成本优势，也没有它们的资本规模。但我们能提供不同价值：一个订阅同时使用 Claude、GPT 等多个模型。不同模型各有优势，我自己每天也会混合使用。

Black 目前逐批开放，一方面受容量限制，另一方面需要收集真实使用分布，才能设置合理额度。节目当天会再开放一批，但这更像实验，不保证一定成为长期产品。

随着规模增加，我们可能拿到普通用户拿不到的批发折扣，这会改善经济性。但最终它仍是一个很基础的成本数学问题，也可能不可持续。

你开发 OpenCode，是否有复杂的规划模型、执行模型和多层子代理系统？你最常用什么模型？

没有。我常说自己发明了一块滑板，使用水平只是普通，其他人却拿它做出我都没想过的动作。虽然我开发 OpenCode，但我不是最疯狂的用户。

我的用法很原生、很简单。Opus 4.5 发布后，我大量使用它。它未必比上一代聪明很多，但更精致：更常做对的事情，不容易失控，错误率更低。

最近我在学习更好地使用 GPT-5.2 Codex。OpenAI 正式支持 OpenCode，也承诺提高速度；Codex 对我最大的缺点就是慢。等待时间较长，会鼓励用户同时开启更多任务。

我通常在 Opus 与 Codex 之间切换，偶尔并行，但大多数时候一次只运行一个代理。随着工具改进，我交给代理的任务规模在逐渐变大。

我也预计 2026 年会出现非常强的开源模型，届时工作流可能再次改变。这个市场竞争激烈，任何固定答案都不会维持太久。

还有什么尚未发布、可能很难实现，但你最想加入 OpenCode 的能力？

下一个主要功能是 Review 页面。现在常见流程是：给代理任务，让它运行，然后切到编辑器或 `git diff` 里检查变化。

我们希望在应用内部提供一个原生审查屏幕，集中展示本次会话修改了哪些文件、每个差异是什么。用户可以选择某段代码，直接把反馈送回模型，再提示它修改。

这个类别里的所有工具最终都需要类似能力，Cursor 已经有一些实现。OpenCode 会把它带进终端，而复杂全屏界面正是我们底层架构可以发挥的地方。

我当前就是左边放 OpenCode，右边放 GitHub 差异界面。我认为提示与审查会成为代理编程的默认 IDE：AI 生成代码，但人仍需要同时审查。

对。生成代码本身不是完整工作流，提示、执行、审查、反馈才是完整闭环。

我们也在开发 OpenCode Desktop，探索专门桌面应用应该是什么样。它不是编辑器，不允许你直接编辑文件，也不打算替代现有 IDE；它专注于把提示与审查循环做好。

下一代 OpenCode 核心还会编排不同环境中的代理。一个代理可以在 Git worktree 工作，另一个在远程沙箱，用户同时启动许多任务，再统一查看状态和审查结果。

桌面端可能出现一个协调屏幕：先规划工作，把任务分发给十个代理，观察它们运行，再逐一验证输出。这与 Cursor、传统编辑器或单纯的 GitHub 差异界面都不同。

并不是每个人都需要十个并行代理，但当亲手编辑文件不再是部分用户的首要动作时，新的图形界面会出现。

如果终端里能有完整的审查体验，对我来说就已经接近生产力顶峰了。我们已经聊了二十六分钟，再问几个收尾问题：两年后，你希望 OpenCode 变成什么？

我希望它存在于所有合理形态：终端 TUI、桌面应用、移动端，以及更好的编辑器集成。现在的编辑器集成还不够好。

OpenCode 本来就被设计成可嵌入组件。它有一个可复用核心，应当进入尽可能多的环境，而不是只存在于一个客户端里。

团队协作目前做得很少，未来要让多人、组织和共享策略的体验更完整。

另一个意外是 OpenCode SDK 已经有大量使用，而我们几乎没有投入。有人用它在 CI 里以编程方式调用 OpenCode、编排自动化流程。我们需要把 SDK 打磨成正式能力。

我们的范围很广，希望最终能覆盖这些使用方式。但我不知道两年后的编程究竟长什么样，也不想沉迷于预测所有工程师会发生什么。

我已经厌倦那类宏大讨论，只想一天一天做产品。至少 AI 让编程对我越来越有趣，这一点我很满意。

你提到移动端，让我想到一种画面：人在海滩遮阳伞下喝饮料，用手机给代理分配任务。听起来既酷又有点荒诞。

但我的时间线每天都被 AI 消息轰炸：OpenCode 又做了什么、ChatGPT 又做了什么、Claude Code 又增加了能力、新模型又更强，然后大家又说开发者完了。即使有稳定工作的人都会害怕，更不用说刚进入行业的初级开发者。

你会给他们什么建议？他们应该怎样适应，是否需要以不同方式学习？

我很难给确定建议，因为我会从自己的使用方式出发，而今天的初级开发者面对的是一个与我当年不同的世界。

不过，从我的工作看，有一整类事情没有变化。模型确实比几年前好得多，但我仍然要投入大量脑力判断：我们应该做什么，系统应该怎样构建。

有人说代码已经只是编译产物，AI 生成、AI 迭代，人只负责指挥功能，根本不必再看代码。我完全没有看到这种现实。

AI 会制造巨大混乱，很少第一次就写出我完全想要的代码。如果每天继续往上堆，代码库会越来越差，而代理同样无法良好处理坏代码库。

让 AI 去修坏代码库，确实比自己钻进去修轻松一些；但更好的选择仍然是一开始就不要让代码库变坏。

历史上让代码可维护、可读、组织良好的原则并没有失效。人们经常把代理说成没有偏好，其实它显然有偏好。

对人类友好的项目结构，也对代理友好。你打开一个新项目，清楚的文件夹、可预测的命名和高层概念，会让你大致知道功能放在哪里。

代理的工作方式也类似：它会扫描文件系统、查看目录。文件组织越清楚，它越容易找到正确位置；增加新功能时，也越容易判断应该放在哪里。

因此，代码库质量不是已经不重要。我开始使用编程代理以后，反而更积极清理代码库。

过去，人类能够理解某段是历史实现，知道现在不再按旧方式写；旧代码没有彻底清理也勉强可以。但代理看见旧模式，会认为那就是范例，然后继续复制。

代码库越干净，代理表现越好，我也越能获得它的完整价值。

至于初级工程师，我不愿给太多确定建议，因为我当初有效的路径未必适合今天。但我个人仍认为，成为优秀程序员极其有价值。

我们团队能从 AI 获得很多收益，与大家本来就有不错的编程能力有关。能力越强，通常越能定义任务、检查结果并修复问题。

而且现在学习编程比过去容易。每个人都有一个随时可用的优秀导师，这是十年前没有的机会。所以 AI 不只是增加竞争，也降低了学习门槛。

我同意。现在代码质量甚至比以前更重要。如果项目有好的 starter kit 和清晰约定，AI 就会跟随；如果你先用正确方式写好一个功能，代理更可能用同样方式实现下一个。

类型覆盖、测试覆盖、严格类型等约束也会指导 AI 产出。这个结论对 PHP、JavaScript、TypeScript 或其他语言都成立。

对。代码质量不是过时概念，而是让代理稳定工作的基础设施。

最后做一个快问快答。必须立即选择，不能回答看情况或不知道。JavaScript 还是 TypeScript？

TypeScript。

Laravel 还是 Rails？

Laravel。

从一到十，和 David Heinemeier Hansson 共事有多糟？十最糟，一最好。

七。

Vercel 是否试图招募过你？

是。

最后一个问题。我刚给 OpenCode 提了一个 PR，加入 Laravel Pint 作为 PHP 格式化器。我发链接以后，你会直接合并吗？

会，我们会合并。

太好了。感谢所有观看直播的人。如果你喜欢这段对话，请点赞、订阅，也欢迎在评论里告诉我们你怎么看 OpenCode 和团队正在做的工作。

Dax，今天聊得非常精彩，非常感谢。

好，我们结束了。

我先暂停一下，马上回来。这次访谈真的很好。Dax 太厉害了。