文本原文来自 OpenCode 联合创始人 Dax Rod 关于 AI 编程工具与工程效率的访谈内容，文章由 有道龙虾 整理和发布。
有个问题挺反直觉：
写代码这件事明明变容易了，为什么工程团队还是这么累？
OpenCode 联合创始人 Dax Rod 对这个问题有切身体会。他做的正是 AI 编程工具，而且 OpenCode 增长非常夸张：2025 年 6 月左右推出，不到一年，月活从 65 万涨到接近 800 万，下一站是 1000 万。
按理说，他们应该是最会“用 AI 提效”的那群人。
但 Dax 的感受是：工具确实让很多事变简单了，可真正困难的问题并没有消失。他仍然要花很多时间思考，团队也没有因为 AI 就甩开所有竞争对手。
他有一句话很值得放在开头：
“客观上，很多事变容易了。但为什么我还是像以前一样费脑子？”
写代码不是唯一瓶颈
很多 CEO、CTO 和创始人会很自然地想：
过去工程师大量时间都花在写代码上，现在 AI 能把代码写快很多，那软件交付不就应该整体变快吗？
Dax 觉得没那么简单。
公司所处阶段不同，AI 带来的效果也完全不同。
在还没有找到产品市场匹配的时候，最难的不是“把功能做出来”，而是弄清楚到底该做什么。这个阶段，AI 也许能让你多试几次，但它不能替你判断方向。
Dax 甚至更相信一件事：
与其疯狂尝试，不如先好好想清楚。
OpenCode 现在处在已经找到产品市场匹配、正在扩大潜力的阶段。这个阶段的问题反而变成了：能做的事情太多了。
用户要功能，竞争对手出了新东西，团队内部也有各种想法。过去实现一个功能有成本，成本本身会迫使团队慎重。现在你只要把需求丢给 agent，它就能帮你做出来。
听起来很爽，但危险也在这里。
一个用户有问题，prompt agent。
竞争对手有功能，prompt agent。
内部想到一个点子，prompt agent。
最后你可能做出一千个功能，却得到一个像“弗兰肯斯坦”一样的产品。每个局部都能解释，整体却很糟糕。
更麻烦的是，软件功能一旦发布，就很难真正撤回。你不仅要维护它，以后每个新功能还要考虑它和旧功能之间的相互作用。
能多发 10 倍功能，不代表你有 10 倍值得发布的好想法。
OpenCode 的机会：占住“开源 AI 编程工具”这个位置
OpenCode 的出现并不是一开始就规划好的宏大路线。
Dax 和团队原本在做 SST，一个开源的全栈应用开发工具。后来公司一度只剩一个月现金，但收入也刚好涨到盈亏平衡。活下来之后，他们终于有机会停下来想：接下来到底要做什么？
他们判断，AI 一定是这个十年开发者工具里最重要的方向。
但 Dax 对 AI 的态度并不是无脑乐观。他的判断更像是：
很多 AI 项目确实很蠢，但这不代表整个浪潮没价值。每一轮大机会都会吸引大量不靠谱的投资和产品，可里面一定有少数东西是真的。如果完全坐在场外，你会错过那少数真正有意义的东西。
他们后来开始使用 Claude Code，这是第一个真正黏住团队工作流的 AI 编程工具。Dax 的反应是：“我们为什么不是做出这个东西的人？”
然后他们发现了一个市场空位：
AI coding agent 已经很多，但还没有一个真正占住“开源选项”的产品。
在开发者工具里，开源选项往往会慢慢变成默认选项。数据库、编译器、基础设施工具，都是这样。
同时，模型市场竞争非常激烈。Claude 很强，但 OpenAI、开源模型、其他大厂都不会让 Anthropic 轻松赢下整个市场。
于是 OpenCode 的定位就清楚了：
做一个中立、开源、能连接各种模型的 AI 编程工具。
Dax 说得很直白：
如果你的位置选对了，世界会不断把你没想到的胜利递到面前。
Anthropic 的封禁，反而帮了 OpenCode 一把
OpenCode 增长过程中有个关键事件。
Anthropic 曾在没有充分提前沟通的情况下，禁止用户在 OpenCode 里使用 Claude Code 订阅。这件事引发了开发者社区强烈不满。
Dax 认为，Anthropic 做这件事本身可以理解，商业上要保护自己的利益很正常。但问题在于方式：深夜突然封掉，不给清晰预告，不做渐进式迁移，等于把所有怒火集中在一个时刻爆发。
有意思的是，OpenCode 团队并没有慌。
他们早就知道这一天可能会来，而且他们已经在和其他模型公司谈官方支持。事件发生当天晚上，Dax 联系了 OpenAI：
“明天大家醒来都会对 Anthropic 很生气，你们有机会通过支持 OpenCode 拿一个漂亮的 PR 胜利。”
第二天，OpenAI 同意支持。OpenCode 当天就把集成做出来并宣布。
这背后其实是 Dax 在 OpenNext 项目上就用过的策略：
选一个临时的“反派”，然后团结它的竞争对手一起推动事情往前走。
OpenNext 当年解决的是 Next.js 在 AWS 等非 Vercel 环境部署困难的问题。这个项目最终吸引了 Cloudflare、Netlify、Microsoft、Google 等厂商参与，最后也推动 Next.js 官方适配器 API 的出现。
OpenCode 这次也是类似逻辑。Anthropic 成了那个临时反派，其他模型厂商自然有动力站到 OpenCode 这边。
这不是情绪化对抗，而是一种生态位策略。
小公司没法靠体量压过大厂，但如果位置卡得对，就能借大厂之间的竞争推动自己想要的结果。
开发者工具其实是 B2C 产品
Dax 认为，开发者工具行业有一个常被忽略的事实：
DevTools 本质上是 B2C 产品。
很多程序员做开发者工具时，会把它当成纯工程问题：谁的 harness 更聪明，谁的模型调用更强，谁的技术架构更漂亮。
但真正大规模普及的开发者工具，通常是自下而上的。先是单个开发者喜欢用，然后慢慢渗透到团队和公司里。
这就要求你像做消费产品一样思考：
用户第一次听说你，到第一次感受到价值，中间有多少摩擦？
OpenCode 很重视第一体验。他们甚至自己做了底层终端渲染框架，只为了让用户打开 OpenCode 的那一刻觉得：“这东西不一样。”
这看起来不理性。毕竟自己造框架是工程团队常被劝阻的事。
但 Dax 觉得，这种“不理性”正是质量的一部分。OpenCode 早期的 harness 不一定是最强的，但体验足够好，安装和上手足够顺，用户就愿意留下来。等占住份额之后，再回头把 harness 做得更聪明。
他们甚至放弃了一个很常见的增长小技巧：在 GitHub PR 或 commit 里写上“由 OpenCode 生成”。
一开始他们也这么做，因为 Claude Code 做了，他们就跟着做。后来有用户问能不能关掉，Dax 想了想，觉得这有点“赌场味”：所有细节都在想办法把用户困住、榨出增长。
于是他们没有加开关，而是直接默认关掉。
OpenCode 怎么赚钱？
OpenCode 虽然是开源产品，但背后是一家要赚钱的公司。Dax 提到，目前主要有两条业务线。
第一条是 OpenCode Zen，也就是推理服务。
早期用户使用 OpenCode 时，需要自己连接 Anthropic 或 OpenAI 账号。但很多人拿不到足够的 rate limit，甚至没法顺畅体验产品。
于是团队做了一个统一的推理服务，让用户注册后就能访问多种模型，获得足够的调用额度。原本只是为了降低 onboarding 摩擦，结果增长非常快。
尤其是开源模型越来越强之后，正确托管这些模型本身也变成了一个很有价值的服务。OpenCode Zen 既聚合前沿模型，也提供开源模型的高质量推理能力。
Dax 提到，这条业务在五六个月内达到过 5000 万美元 run rate。
第二条业务是企业控制平面。
如果一家企业有 1000 个工程师使用 OpenCode，不可能让每个人自己下载工具、自己填 API key。企业需要 SSO、权限、预算控制、rate limit、供应商配置等管理能力。
这部分听起来无聊，但非常关键。Dax 甚至说，如果推理业务最后足够重要，他们可能不再单独为控制平面收费，而主要通过推理赚钱。
推理是个好生意，但 GPU 是真瓶颈
很多人以为 AI 模型服务商都在烧钱，Dax 的看法更细一点。
训练模型当然很贵，研发团队也很贵。但如果只看“推理”这件事，它可以非常赚钱。
推理成本的底线是电费。硬件采购是资本成本，一旦硬件到位，生成 token 的最低成本就是让机器运转的电力，加上一些基础设施和运维成本。
OpenCode 自己并没有做到成本最底层，仍然会通过中间商租 GPU。但即便如此，他们看到一些模型的标价和实际成本之间，可能有 80% 的毛利空间。
对于 OpenAI、Anthropic 这种有超大规模 GPU 合同的公司，Dax 猜测当前价格下推理毛利可能接近 90%。这不一定长期可持续，但眼下确实是个很赚钱的生意。
问题是，GPU 供给太紧。
Dax 说，整个 GPU 供应链，从硬件生产、配套设备到人力支持，都非常紧张。推理需求可能不是线性增长，而是接近指数增长；但 GPU 产能不可能指数增长。
大厂每年花几十亿美元甚至上百亿美元买算力，Amazon、Meta、Microsoft、Google 这些公司会把供应链资源大量吸走。相比之下，哪怕一家 AI 创业公司融了 20 亿美元，在大厂面前也不算什么。
所以连 OpenCode 这样体量的公司，也会被 GPU 供应卡住。
Dax 判断，这种短缺迟早会被过度供给修正。很多行业短缺最后都会走向疯狂扩产。但至少现在，GPU 仍然很紧。
AI 提效的现实：工程师可能只是更轻松了
Dax 对 AI 提效有个很扎心的判断：
很多公司以为工程团队原本处在效率巅峰，只是被“写代码速度”卡住了。现实并不是这样。
大多数工程组织不是硅谷顶级创业团队。很多工程师只是想把工作做完，然后回家陪家人、过正常生活。
如果你给他们一个按钮，让他们更快完成任务，他们很自然会用这个按钮做同样多的事，然后把省下来的时间留给自己。
这不是道德问题，这是正常人性。
所以一种可能的结果是：
AI 编程工具让工程师更开心，工作更轻松，但公司整体产出并没有按比例增长。
对员工来说，这可能是好事。对很多公司来说，这就“不够好”。
更糟的是，在一些组织里，少数真正关心质量的人会被 AI 生成的 PR 淹没。其他人用 agent 快速完成任务，留下大量质量一般的改动。那些还在认真把关的人，要审更多代码，修更多问题，最后更容易燃尽和离开。
这也是为什么 Dax 反复强调：AI 不是单纯的效率工具，它会改变团队内部的反馈回路。
那封给团队的 memo：我们没有变快，只是感觉变快了
Dax 曾给 OpenCode 团队发过一封 memo，后来被很多人引用。
他承认团队遇到了三个问题：
- 发布了不值得发布的功能。
- 在原始设计不适合时，吸收了太多 hack。
- 没有花足够时间清理旧东西。
最关键的是，他说：
最糟糕的部分是，我不认为我们是在用这些代价换速度。我觉得我们只是以正常速度前进。
这句话很重。
很多团队会安慰自己：我们牺牲一点架构、牺牲一点质量，是为了跑得更快。
但 Dax 回头看，发现他们并没有真的比竞争对手快多少，也没有明显快过过去。只是因为 agent 能快速完成局部任务，团队获得了一种“我们很快”的错觉。
关于 hack，他提出了一个特别形象的说法：muted prickle，被静音的刺痛感。
过去工程师写 hack 时，自己知道那是 hack，会有一点不舒服。第二次再往上叠 hack，你会想起第一次留下的坑，心里更难受。
这种刺痛感其实是判断力的一部分。
但现在，agent 帮你把 hack 写出来，也帮你绕过后续问题。你没有亲手经历那种不适，于是反馈回路被削弱了。
地雷还在那里，只是今天没有炸到你。
清理代码债，反而比以前更容易了
Dax 并不是反 AI。他反而认为，AI 特别适合做一类过去很痛苦的事：清理。
过去团队发现一个新模式很好，往往只会在新代码里使用。旧代码太多，改起来太麻烦。
现在不一样。你可以让 agent 把新模式应用到整个代码库，清理死代码，替换旧模式，统一结构。
也就是说，AI 不应该只用来更快堆功能。它同样适合用来还债。
Dax 的目标不是做一家“只要成功就行”的公司。他说，成功公司有很多种，但如果你可以选择去哪家公司工作，你大概不会选择其中 99%。
他想做的是：五年后，团队仍然愿意在那里工作，每天打开代码库不会觉得痛苦，优秀的人也愿意加入。
这就是为什么清理和质量值得投入。
少预测，多做今天该做的事
社交媒体上总有各种关于 AI 未来的预测。比如有人说：
“24 到 29 岁的工程师会成为科技行业最宝贵的资产，因为他们既有 AI 之前的工程原则，又有 AI 之后的速度。”
很多人转发赞同，Dax 却觉得这是典型的自我安慰。
他观察到，这类预测往往都有一个共同结构：
像我这样的人会赢，不像我这样的人会输。
公司如我会成功，其他公司会失败。
我的工作不会被 AI 替代，别人的工作会。
在巨大变化面前，每个人都焦虑。于是大家会本能地讲一个“我在未来仍然是赢家”的故事，来保护自己的心理安全。
Dax 不喜欢沉迷预测。他更关心今天和明天能做什么。
他说，一年前他也不知道自己会做 OpenCode，一年后自己会做什么也不确定。真正重要的是，眼前什么事是合理的，就先把它做好。
好产品的原则没变：尽快让用户体验到唯一的好点子
Dax 对产品有个很朴素的原则：
一个产品大概率只有一个真正好的点子。你要做的，是让用户尽快体验到它。
听起来容易，做起来很难。
很多产品从用户听说，到真正感受到价值，中间塞满了意外的步骤：注册、配置、权限、文档、初始化、理解概念、连接账号……每一步都可能把用户劝退。
OpenCode 团队会定期模拟新用户第一次使用产品。Dax 自己有个命令，会启动一个全新的 Docker 容器，然后运行 OpenCode，体验从零开始的流程。他每两周做一次，经常能抓到团队不小心引入的摩擦。
产品工作也不是收到一个问题就发一个功能。
真正难的是，把 50 个表面不同的问题吸收进去，找到一个更抽象、更优雅的解决方案。这个过程需要经验、用户沟通、团队讨论、代码理解，以及大量思考。
Dax 坦言，AI 在这件事上几乎没有帮到他。
反馈回路，比聪明更重要
Dax 反复提到反馈回路。
一个设计不好，用户会骂你。
一个架构不好，你自己以后会在代码库里痛苦挣扎。
一个产品决策偷懒，支持团队可能替你承受怒火。
问题在于，很多大公司会把这些痛苦隔离开。产品团队切掉某些体验细节，工程团队发出功能，最后真正挨骂的是客服或支持团队。做决策的人没有感受到后果，判断力就不会成长。
OpenCode 的做法是尽量让做事的人走完整个循环。
谁做功能，谁看 GitHub issue，谁看 Twitter 反馈，谁理解用户骂在哪里，然后自己继续改。
团队现在 20 多人，增长很快，仍在适应。但他们尽量保持公开构建、快速 demo、直接接收反馈的方式。
Dax 也会给团队足够的市场和竞争背景，让每个人理解公司所处的位置。只要上下文足够充分，团队成员往往能自己判断优先级。
甚至有时候，Dax 明确反对某个方向，几周后发现团队成员是对的。
“品味”不是口号，是你真的相信产品应该好
谈到 AI 时代工程师还剩什么，很多人会说“taste”，也就是品味、审美、产品判断力。
Dax 觉得这个说法没错，但也很容易变成空话。
好想法通常很简单，难的是你能不能真的活出来。
很多人嘴上说品味重要，但心里并不真的相信产品必须好、代码必须好、体验必须好。因为市场上确实有很多产品很烂、工程很糟，却照样赚钱。
一旦“也许好不好无所谓”这个念头进了脑子，你就很难做出真正好的产品。
Dax 认为，质量往往来自一些“不理性”的投入。比如一个产品其实可以差 50%，短期收入可能也不会受太大影响。但如果你在一个地方开始偷懒，很快就会在所有地方偷懒。
懒惰会传染。
OpenCode 早期敢和更大的产品竞争，一个重要原因就是终端体验更好。为了这个体验，他们做了很多看似不理性的事，比如自己写终端框架。
但正是这些细节，让用户第一次打开时感觉不一样。
AI 时代，老工程原则反而回来了
Dax 认为，AI 并没有让工程领导变成全新的问题。很多所谓新问题，其实是旧问题换了对象。
以前我们问：
如何让 junior engineer 安全地提交代码？
现在我们问：
如何让 agent 或非工程师安全地提交代码？
答案仍然类似：测试、约定、模式、清晰的代码结构、边界、guardrails。
甚至一些过去被嫌弃的“企业级”模式可能会回来，比如更重的领域驱动设计、设计模式、清晰分层。
过去这些模式的问题是太啰嗦，写起来烦。但现在你不一定亲手写所有样板代码，AI 可以承担一部分输入成本。于是那些能带来结构和安全性的旧模式，重新变得有吸引力。
Dax 开玩笑说，现在团队里多了一群“笨蛋”，也就是 coding agents。它们 24 小时工作，会提交很多东西，所以你更需要训练轮和护栏。
给工程师的建议：别只做“会写代码的人”
对经验丰富的工程师，Dax 给的建议不是“赶紧学某个 AI 工具”，而是更长期的东西：
成为某个行业里的软件专家。
软件工程本身是一项可迁移技能。你可以只做一个很好的工程师，也能有不错职业生涯。
但如果你既懂软件，又真正懂某个行业，那组合就很稀缺。
比如你理解农业，又是不错的软件工程师，你可能就是这个交叉领域里非常稀有的人。医疗、金融、物流、教育、游戏，都一样。
软件工程师有个很大的自由：你不必一生绑定一个行业。你可以在医疗做十年，学透之后发现不喜欢，再换另一个领域继续深入。
关键是别把大脑关掉，只把自己当成“接 UI 需求的人”。
每家公司、每个行业都是一个学习入口。工程师应该利用这个位置，理解业务、理解用户、理解真实世界怎么运转。
真正值得记住的，不是 AI 有多快
这场对话最有意思的地方，是 Dax 明明在做最热门的 AI 编程工具，却一直在提醒大家慢下来。
他没有否认 AI 的价值。OpenCode 自己就是 AI 浪潮里的受益者，增长惊人，业务也跑得很快。
但他的重点是：
AI 让局部执行变快了，却没有自动解决判断、取舍、质量、反馈和品味。
你仍然要决定什么不该做。
你仍然要判断什么时候该重构，而不是继续叠 hack。
你仍然要让用户尽快体验到真正价值。
你仍然要维护团队的反馈回路。
你仍然要相信，好产品值得被认真对待。
AI 可以帮你写更多代码。
但软件工程从来不只是写代码。