3个月盈利！这个团队用"反AI"策略吊打Claude Code

从代码质量的角度看，用"自己写自己"的方式来换取开发速度，这种做法本身就值得被认真讨论一次。

上个时代的开发工具，是被非常仔细地一步步打磨出来的：行为稳定，交互克制，出了问题大多也在预期之内。可到了今天，Claude Code、Codex 这些软件产品，把"用 AI 写自己"当成默认路线。虽然 AI 的确让写代码更快了，但它并没有自动解决"怎样把一个复杂的软件长期维护好"这件事。

Claude Code 是一个很典型的例子。Anthropic 这套工具几乎是从零开始做的，但团队又长期坚持一种非常激进的内部方式：他们强调"Claude Code 的 100% 代码都要由 Claude Code 自己写"，并且内部工程师和研究人员的各项任务，从大型代码重构、squash commit，到各种琐碎的编码工作，都依赖 Claude Code。

问题在于，当底层模型本身就是非确定性的，而承载这些能力的产品代码又是在这样的开发方式下快速堆叠出来的，系统很容易陷入一种恶性循环。这一两年里，Claude Code 一直在快速扩展能力，交互逻辑越来越复杂，于是这个产品本身变得越来越不稳定：各种崩溃、各种诡异报错，bug 越来越多，速度越来越慢。事情甚至发展到一种颇为荒谬的状态——与其回过头去系统性修复这些性能问题，不如直接收购核心依赖 Bun，把希望寄托在底层 runtime 团队身上。

Cursor 的处境则是另一种复杂。它一开始面对的，就是一个极其庞大、极其复杂，而且并非自己从零塑造出来的代码底座——他们直接 fork 了 VS Code。这个起点决定了，它从第一天起就在打一场高难度战役：你不是在空白纸面上做产品，而是在一个超大工程体系上做增量改造；你不仅要持续改出自己的差异化能力，还要长期维护这个分叉版本，并尽可能跟上游同步必要更新。只要做过大型工程的人都知道，这种事本来就极其痛苦，而且随着时间推移，分叉只会越来越深，维护成本只会越来越高。

如果把这些现象放在一起看，一个越来越清晰的趋势是：AI 编程工具，很可能会经历一轮"大规模重写潮"。

因为其代码库本身在早期高速迭代中已经被带进了一种越来越难逆转的状态。继续往上叠功能，只会让系统更加脆弱；真正的解法，往往只能是承认旧底盘已经失控，然后从零再做一套新的。

OpenCode 提供了一个很有意思的对照。它同样是在 AI 编程浪潮中构建出来的工具，但团队采取了完全不同的策略：他们比过去更强调代码库的一致性和约束，尽量确保没有任何文件偏离既定规范；同时，也大量采用那些约束更强、设计哲学更明确的工具与框架，并更坚定地践行领域驱动设计。

他们认为在大模型参与开发的情况下，代码库一旦变"脏"，后果会被放大。大语言模型无法区分"旧模式"和"新模式"，它会将旧写法当成正确示范并继续生成不符合当前规范的代码。因此，不干净的代码库带来的负面影响，反而比过去更严重。

于是出现了一个有些反直觉的结果：他们的代码库反而比以往任何时候都更干净，"甚至可能是我们写过的质量最高的一批代码。"OpenCode 创始人之一 Dax Raad 在播客中这样说。

与此同时，他也并没有放弃"手写代码"这件事本身。"当我设计新功能或复杂架构时，写代码本身就是思考过程。我不擅长写一大段详细规格说明，相反，我喜欢写类型定义，尝试函数组合，调整文件结构，通过编写代码来理解问题，这是大多数程序员长期以来的工作方式。我看不出有什么理由要放弃这种方式，写代码是我思考的方式。"

另外，他还从代码质量角度小小鄙视了一番 Claude Code："Claude Code 做了一个原型，产品市场匹配度极高，即便体验不完美也会成功。但这并不意味着，所有人都必须牺牲质量，才能达到那个速度。"

基于该播客视频，InfoQ 进行了部分删改。

Host：从去年 12 月开始，OpenCode 的发展非常迅猛。能不能带我们回顾一下 OpenCode 是如何诞生的？

Dax：我们公司做开源已经很多年了，一直以来我们都在为开发者构建工具，也经历过不同公司在这个领域的兴衰更替，因此在开源产品的构建方面积累了很多经验。

我们之前的项目是 SST，虽然远不如 OpenCode 现在的规模，但也算相当受欢迎。它给了我们完整的实践经验：如何启动一个开源项目，如何让它成功，日常如何运营，开源的优势和劣势分别是什么。可以说，我们在这个领域深耕已久。

2025 年 2 月左右，我们实现了盈利。当时公司只有三个人。实现盈利之后，我们开始反思下一步该做什么：是继续深耕现有产品，还是探索新的方向？AI 显然是这个时代的重要趋势，如果完全忽视它会显得非常不理智。

于是我们开始尝试一些想法，探索 AI 能为开发者做什么、在更广泛层面又可以做什么。我们试过几种方向，但都没有真正形成产品。有些点子对我们自身很有帮助，但始终无法打磨成成熟产品。

差不多就在那个时候，我们开始用 Claude Code。其实在这之前，我们已经看过很多 AI 编程工具，比如 Cursor，当时已经挺火了。但我们团队里没有人真正用下去。我们也试过，但感觉是在放弃一些我们原本喜欢的东西，同时又没有获得足够多的收益，所以没有坚持下来。

但 Claude Code 是第一次让我们觉得，"这才是对的工作流"。在那之前，我们一直在做的事情就是把代码复制到 ChatGPT 里，再复制出来，反复来回。我们一直在想，为什么这些东西不能直接连接到文件系统？为什么要这么手动？

而 Claude Code 在这点上是一个很聪明的整合方式，把这些流程串在了一起。于是我们就觉得，如果这是第一个真正让我们"用下去"的工具，那这件事可能就很重要了。

接下来我们就开始想：如果我们把自己在开源上的经验用起来会怎么样？当时有一个很明显的空白点——居然还没有一个开源的 coding agent。于是我们就在想，能不能做一个开源的 coding agent，同时支持多种模型，因为我们知道这些模型之间的竞争会长期存在，而且会越来越激烈。

这个切入点，对我们来说是一个很自然的延伸。

Host：现在你的日常开发工作流是什么样的？发生了多大变化？毕竟你既是开发者，也是开发开发者工具的人，这种视角很特别。

Dax：我们团队成员都是 Vim 用户，几乎所有工作都在终端完成，非常享受 Vim 的编辑体验。迁移到 Cursor 对我们来说成本很高，因为虽然还能编辑代码，但文本编辑体验在我们看来变差了，而获得的收益又不足以弥补这种损失。

Claude Code 能"用下去"的原因在于，我们可以继续用原来的编辑器，同时在一个单独的空间里做 AI 相关的事情，两者不会互相干扰。这对我们来说很重要。

我觉得 Cursor 更像是一个过渡产品，它试图把你从传统编辑器直接带到 AI 编程的那套新范式上。这当然有一些好处，但对我和很多人来说，它处在一个有点尴尬的中间状态——我其实只想用编辑器来写代码，不想让各种 AI 功能到处弹出来。

用 Cursor 的时候，我会感觉各种建议无处不在，还有一堆新的 UI 面板，这让我很不适应。我更喜欢把 agent 当成一个"坐在旁边的笨同事"：我偶尔看一眼它在干什么，给点反馈，然后让它继续干，我自己也可以做别的事情，工作是可以拆开的。

所以 Claude Code 最大的优势，其实就是它在编辑器之外提供了一个独立空间。我们在做 OpenCode 的时候，也是在延续这个方向：在这个"独立空间"里，能把和 agent 交互这件事做得多丰富、多好。

现在我的工作流依然是：用 Neovim 编辑代码，用 Agent 处理需要 Agent 的任务。我们确实越来越多地使用 Agent，在编辑器里的时间相对减少，但我远没有完全放弃手写代码。我仍然大量使用编辑器，手动写代码。

Host：现在有很多顶尖开发者声称自己已经不再从零写任何一行代码了，很多人听到这句话会理解为"编程已死"，你怎么看？

Dax：我对这种说法感到困惑。如果你问我手写代码的比例是多少，我其实很难回答。我在不同工具之间不断切换，很难量化。

如果有人说他们几乎不用编辑器，完全在这些 agent 工具里工作，不管是 OpenCode、Codex 还是其他类似工具，我会很惊讶。因为这些工具其实并不适合阅读代码。那他们是完全不做代码审查吗？还是把代码推到 GitHub 上再看？

另外，当我在设计新功能，或者做一些比较复杂的事情时，写代码本身就是我思考的一部分。如果只是加一个按钮、做一个简单改动，那当然可以直接 prompt 一下，甚至都不用怎么看生成的代码，因为它大概率和周围的代码是类似的。

但当我在做全新的东西、或者在设计一个系统时，我需要通过写代码来搞清楚到底该怎么做。我很难坐在那里写一大段详细的 Spec，然后就让 AI 去实现。我更习惯写类型定义，尝试不同函数怎么组合，调整文件结构，从这些过程中去理解问题，这其实也是大多数程序员一直以来的工作方式。

所以我看不出有什么理由让我停止这样做，因为这是我搞清楚事情的方式。

所以当有人说"我完全不写代码了"，我会有一点偏怀疑的态度。我觉得这里面有一种心理因素：大家都感觉到一个巨大的变化正在发生，也担心自己被淘汰，于是会倾向于说服自己"我已经在最前沿了"。

再加上现在有一种叙事，说这个变化会淘汰很多人，只留下少数人。所以大家会有一种倾向，把某些局部的成功放大成"现在一切都可以这样做"。一旦有一个场景跑通了，就会被表达成"全部都可以这么做"，会有一点夸张。

所以很难从这些说法里判断真实情况，因为背后掺杂了很多情绪和心理因素。

Host：我觉得这点很好，因为我甚至不觉得这是"故意营销"。比如 Claude Code 的早期作者之一 Boris，他说过自己几乎不再从零写代码，但他最近也说过"为什么 Anthropic 仍然在招聘开发者"，说明人类仍然有大量参与，所以确实很让人困惑。

Dax：我同意，这并非出于恶意，而是兴奋与不安交织下的结果，使人们难以准确表达现实情况。类似现象在以往新技术或新框架出现时也屡见不鲜，人们常宣称其"彻底改变了工作方式"。对此，一个有效的判断标准是直接检验其产出：许多情况下并无真正落地的产品，仅停留在尝试层面；即便已有产品，质量也未必更优，甚至可能更差。在当前的 AI 编程实践中亦是如此，一些人声称"完全依赖 AI 写代码"，但其产出质量并不理想，这在一定程度上反映了当下的真实水平。

Host：OpenCode 和 Claude Code 似乎是直接竞争关系，你怎么看？尤其是在 Anthropic 限制订阅使用之后，你的看法有变化吗？

Dax：我不认为世界是零和的，大多数系统允许多方共赢。但在商业领域，竞争是真实存在的。商业更像体育比赛，大家争夺对世界的不同愿景。可能不会完全一方胜出，但竞争确实存在。不过，更重要的是"定位"。即便产品看似相似，定位可能完全不同。

OpenCode 的成功更多来自定位，而不仅仅是产品质量。我们判断模型之间的竞争会持续，包括闭源模型和开源模型。价格会下降，竞争会越来越激烈。所以我们选择：做一个不绑定单一模型的工具，这样我们可以从模型竞争中受益。其次，我们要占据"开源 coding agent 第一"的位置。历史经验表明，大多数开发工具最终都会走向开源，数据库、编译器、编辑器都是如此。

Claude Code 走的是垂直整合路线，这和我们的定位不同。从定位角度看，我们不一定直接竞争。但在价值观层面，我们确实存在分歧，也希望证明我们的价值观会带来更好的结果。

Host：作为一个同时使用过 Open Code 和 Claude Code 的用户，我肯定会说 Open Code 的体验非常好，我总结下来就是开源、可以在不同模型之间自由切换、没有锁定，以及先发优势。

Dax：这些确实是核心方向，并不只是口号，而是体现在大量具体细节里。比如为什么坚持开源？因为开源意味着会有更多人在不同环境中尝试它。Open Code 从一开始就被设计成可以适配各种环境。哪怕是在企业强限制的笔记本上，只能使用 Amazon Bedrock，也确保可以正常运行。开源的好处在于，虽然无法在内部复现所有环境，但社区可以。别人可以在真实环境里测试、提交问题、甚至提交修复，因此能够很好地覆盖各种长尾场景。如果产品只有现在一半好，我们可能依然会取得类似的成功，因为成功更多来自定位，而不是单纯的产品质量。

Host：OpenAI 至少在与你们的合作关系上采取了一条不同的路线。你们之间到底是什么关系？为什么 OpenAI 会采取不同的做法？

Dax：这其实还是回到我们的定位。如果我们是开源选项，就有机会成为一种"标准"，让其他人基于我们构建或把我们嵌入到他们的体系中。因此，在与 OpenAI 合作之前，我们已经在和 GitHub、GitLab、JetBrains 等沟通，希望他们将 Open Code 作为使用其大模型服务的一种推荐方式，因为我们在这方面投入更多，用户反馈也更好。说服了部分公司后，我再去找 OpenAI，表示行业已有支持，询问他们是否愿意加入。

之所以选择 OpenAI，是因为他们与 Anthropic 存在竞争，而在编码领域 Anthropic 的心智份额更高。对 OpenAI 来说，支持我们既有公关收益，也能吸引更多用户使用 Codex。我联系他们的时间点也恰逢 Anthropic 封禁 Cloud Max 和 Open Code 前后，他们因此看到了一个反向布局的机会。

至于 OpenAI 是否真正认同这种模式，还是出于短期竞争动机，我并不确定。但我们擅长洞察各方激励，在关键节点施加影响，促成对自身、用户以及开源社区都有利的局面。本质上，就是理解激励机制，并在博弈中创造更优结果。

Host：最近行业内有不少收购案例，OpenCode 会是下一个吗？

Dax：我们花了很多年寻找一个真正巨大的市场，而现在我们找到了。全球有三到五千万开发者，我们的产品理论上可以服务所有人，这种机会很难得。因此，轻易把它交出去是很困难的决定。我们确实收到过不少收购邀约，但没有认真推进。除非对方开出很高的价格，而 AI 领域确实存在夸张的收购案例。

有一次我在团队群里提到某家公司想收购我们，大家完全无视，继续讨论产品。我又提醒一次，有人说"让他们多加一个零再来"。团队真的想把事情做到底，而不是快速套现。

当然，几年后如果增长停滞，我的态度可能会变。公司能做大，是因为创始人多年保持动力。很多收购发生，是因为创始人动力下降或前路太漫长，目前我们想走到最后。

Host：AI 让我们速度更快，但是否积累了更多技术债？这种权衡是否发生了本质变化？

Dax：这种权衡一直存在。很多时候，人们用"为了速度做了权衡"来解释质量问题。但回头看，大多数问题并非刻意权衡，而是经验不足。

当我第一次做某件事时，95% 的问题来自经验不足，而非有意识的取舍。下一次再做，同样的时间内我能做得更好。

AI 也是如此，它提升了每个人的能力上限，但不应成为偷懒的借口。我们仍然应该反思、改进，而不是因为"能跑起来"就觉得没有问题。

有些人会说："代码很糟，但我们写得很快。"实际上，更有经验的人可以在同样速度下写出更好的代码，这本质上还是能力问题。

Host：那从产品和用户角度看，短期内定位和速度可能比质量更重要。比如 Claude Code，当时快速发布是不是合理？后来是不是应该做得不同？

Dax：我认为每个人都会尽可能快地前进，并根据经验做出不同的取舍。Claude Code 的情况是，他们做了一个原型，产品市场匹配度极高，即便体验不完美也会成功。这种情况很常见，但这并不意味着"所有人都必须牺牲质量才能达到那个速度"。

我们做 Open Code 的时间差不多，也构建了终端框架、Zig 实现、React 和 SolidJS 绑定、编译为 bun 二进制等。我们之所以能在相似速度下交付更高质量，是因为这是我们熟悉的领域。当然，也一定有人可以做得比我们更好。总的来说，这个行业里永远存在比你差十倍的人，也永远存在比你强十倍的人。

Host：当大量代码由 AI 生成时，你们如何在提升效率和保证质量之间取得平衡？比如在代码 review 方面，你会在不阅读代码的情况下直接提交吗？

Dax：一个有些反直觉的现象是，我认为我们现在的代码库比以往任何时候都更干净，甚至可能是我们写过的质量最高的一批代码。原因在于，不干净的代码库带来的负面影响如今比过去更严重。

过去，代码库的典型生命周期是这样的：最初我们制定一套模式，几个月后发现更好的实践，于是通知团队今后按新方式开发，但旧代码不会立刻重构。时间一长，代码库中就形成多层历史遗留风格。这在以前尚可接受，但现在不行了。因为大语言模型无法区分"旧模式"和"新模式"，它会将旧写法当成正确示范并继续生成不符合当前规范的代码。

因此，我们比以往更加重视明确并严格执行统一模式，确保代码库中没有任何文件偏离规范。某种程度上说，我们现在更在意代码质量，因为我们"雇佣"了一群勤奋但缺乏理解能力的 LLM，它们记忆力极强，却无法自行判断哪种模式更优。我们大量采用带有强约束和明确设计哲学的工具与框架，并更坚定地践行领域驱动设计。

至于是否阅读所有代码，我的做法是基于风险判断。在模式成熟且稳定的模块中，我对输出结果有较强的预期感，通常只做快速检查；而在结构尚未稳定的区域，我会更加谨慎地逐行确认，团队大体也采取类似策略。

Host：有些人听到你不会逐行审查所有代码，可能会感到震惊。但回顾过去，即便在大型科技公司，也并非每一行代码都会被认真阅读。很多时候，只要对开发者建立了信任，review 也会较为快速。某种程度上，你似乎是在说，也可以对 LLM 建立某种"信任"。

Dax：我仍然算是偏保守的。即便在大型公司里，至少有一个人真正理解代码——也就是编写它的人。而如果是 AI 生成代码且没有任何人理解它，那会令人不安。

我更倾向于用"风险感"来判断。例如最近一次我较少审查的情况，是实现一个终端界面的新对话框。我从用户角度做了充分测试，确认功能正常。由于底层构建对话框的基础组件非常成熟，我判断风险较低。虽然技术实现上可能存在细节瑕疵，之后也确实进行了清理，但短期内问题不大。不过，我仍会尽快修复，因为不规范的代码可能污染后续模型生成。

这本质上和过去一样：你可以适当"偷懒"，但要记得回来修。

Host：如今很多人认为，编程的乐趣被削弱了，开发者变成了"提示词工厂"。你怎么看？AI 是否让你失去了对编程的兴趣？

Dax：对我而言，答案是否定的。但我可能属于少数情况，因为我经营自己的公司，可以自主选择工作方向。AI 工具让我能更快探索新想法，把时间投入到更有创造性的部分，而不是重复性劳动。