Kent C. Dodds 访谈：产品感、克制与 OpenCode 的实践

大家好，我是Kent C. Dodds，身边这位是我的朋友Dax。Dax，你怎么样？ Dax： 很好，你呢？ 主持人： 超棒。很高兴和你聊聊。这一季的“与Kent聊天”播客，我们会谈论产品工程以及如何成为一名产品工程师。Dax，你在X（推特）上经常发表一些非常棒的观点，坦白说，这也是我决定我们作为软件开发者应该走这条路——培养产品感——的一个重要原因。为了给大家铺垫背景，我觉得让大家了解一下你的背景、你目前在做什么，以及为什么你对这个话题如此关心，会很有帮助。 Dax： 好的，正如我刚才说的，我叫Dax。我职业生涯的大部分时间都在构建产品和公司。过去一年左右，我一直在做一个叫OpenCode的项目。它是一个编码代理，覆盖从终端到网页应用再到桌面应用的多个平台，所以产品的覆盖面很广。同时，这个领域发展迅速，竞争者众多，方向也多样化。因此，产品流程的理念对我们来说非常重要。 主持人： 是的，你的客户群体非常挑剔——开发者。而且你们工作的是开发者工作流领域，这可能是最难的部分。因为让开发者尝试新的工作流、找到合适的工作流真的非常难。OpenCode的用户中肯定有人对工作流有不同的看法，或者他们觉得适合自己的工作流不一样。这对你们的工作带来了怎样的复杂性？ Dax： 这确实很难，但我想说的是，我们在开发工具领域已经耕耘了一段时间。就我个人而言，过去五六年我一直在尝试构建开发者会用的东西。我们学到的最重要的一点是，这其实是一个面向消费者的业务。你得把它当成在做一个消费者产品。虽然你的变现可能是B2B的，比如最终是企业为他们的开发者使用你的工具买单，但你实际上并不是直接向企业卖产品。当然，任何企业都可以采取自上而下的销售方式，但通常要做成广泛使用的产品，必须自下而上。 所以这非常像一个消费者应用，思考的心态是：为什么有人会第一次下载某个应用？为什么有人会第一次下载Instagram？你如何让他们快速到达那个下载并且对产品感到兴奋的阶段？所以尽管用户是开发者，他们有自己的怪癖和期望，但最重要的是把第一次体验做好，这其实并不是特别针对开发者的。

我本来想指出这一点，如果你没说的话。对于B2B应用来说，初始体验可能不是最重要的，因为你的目标是卖给老板，所以关注点不同。但如果是消费者应用，我觉得这是一个很有趣的观点。是的，这很有道理。入门体验必须非常愉快，第一次使用和尝试时体验要非常好。这样的话，采用自下而上的方式，开发者会开始用，然后他们会和老板沟通让老板买单，老板可能会说“我们买个团队许可证吧”，这很合理。 Dax，我其实想问你关于你刚才发的那条推文。那条推文是我决定一定要和你聊聊，甚至做整季播客的契机。你三小时前发的那条推文说：“我们正在对产品流程做大量反思，我真的觉得你们也应该这么做。我们新编码代理能力的默认去向是去做错误的事情。产品从好到坏的速度比以往任何时候都快。”我觉得最近用软件的人很难不同意这点。坦白说，这种态度自Facebook提出“快速失败”以来就一直盛行：快速发布，发现问题，然后迭代。每个人对能向客户发布多少尚未准备好或不完善的东西的容忍度不同。 你们在OpenCode对产品流程的反思主要是什么？你们在速度和稳定性之间的取舍是什么？

我觉得有个东西在恶化。当然也包括代码库方面，忽略产品功能，代码库会恶化，这确实是个问题。但我这条推文更多是说产品体验在恶化。这里面有很多不同的动态。就拿我个人职业生涯来说，我从来没觉得自己在提升产品技能，我一直觉得自己是在提升编程能力，提升那些可以明确指出、写进简历的具体技术技能。人们会说产品是个技能，可能会把它看作设计或者某些具体技术下的东西，但其实有一种真正的、看不见的技能叫做产品技能，你可以随着时间变得更好。我个人可能低估了自己在这方面的成长，因为我主要觉得自己技术上在进步，但我也觉得自己在产品方面也在悄悄进步。 这种进步只有在你参与整个闭环的情况下才会发生：你构建东西，处理用户反馈，用户对你发火，然后你能自己完整闭环。如果你处于这种状态，你自然会变得更擅长产品。我觉得很多人历史上没处于这种状态。很多组织把这些角色分开，可能有合理原因。大多数工程师都有产品经理合作，产品经理告诉他们要做什么，工程师的工作是评估难度，必要时提出异议，处理技术实现。工程师可能觉得产品经理没做什么，因为他们看到的只是任务，产品经理更像项目经理。 但随着编码代理的出现，一些工程师开始觉得技术方面没那么重要了。我对这种看法有自己的意见，但确实有人这么看。这意味着工程师开始自然地参与产品决策，提出功能想法，推动功能上线，可能是因为他们能比以前更快推出功能。在这个过程中，我觉得软件工程师需要反思，可能我们产品能力并不强。现在看到的很多现象是，产品功能太快增加。比如我喜欢的好产品，六个月后回头看，功能不是不合理，而是排列不当，产品开始感觉糟糕。 在这个分析中，你会意识到产品技能是真实存在的。问题是，这个技能到底是什么？我需要怎样正确安排？我需要怎样不同地处理这个问题？我们基本上想把它系统化，说明这是个真实的东西，不应该低估拥有这方面经验的人有多稀缺。

是的，完全有道理。我有很多线索想深入探讨。首先是弄清楚这个技能到底是什么，怎么培养它非常难。我教人技术技能已经十多年了，遇到过各种挑战。现在我想教的新技能是最模糊的，就像烟雾一样，我在努力给它一个形状。这也是我做这个播客的部分原因。我不想贬低产品，但如果你能举个具体产品的例子，说明它是如何在没有太多意图的情况下演变的，可能有助于我们理解和具体化这个概念。 Dax： 说实话，我可能会谈谈我们自己的产品，因为这是我最关心的。让我震惊的是，OpenCode才上线八个月，我对这种恶化感到震惊。我不是说严重、不可恢复或剧烈，也许别人都没注意到，但以我的标准来看，我看着我们的产品，觉得我们真的构建了很多功能，但我觉得应该这样看待：你可以把产品看作一个生命周期。新用户第一次尝试你的产品，这就是入门过程。在这个过程中，你需要确定——我们所有做产品的人，产品里可能有很多我们喜欢的功能，我们喜欢各种能力，但对于入门来说，我们得假装除了一个东西外其他都不重要。你最想让用户入门时理解的核心概念是什么？ 比如ChatGPT，它就是一个输入框。你输入任何想说的东西，得到回复。这就是核心。如果看OpenCode或Claude Code，也类似，你可以发出提示，让代码发生变化，让你印象深刻。其他功能对入门来说都不重要。 在入门阶段，随着时间推移，很容易把更多东西加进去。产品的第一个版本本质上是极简的，入门很清晰。但随着功能增加，你必须确保不破坏入门体验，这很容易出错。我们经历过几轮，意外破坏了入门体验，不得不回头以新用户身份体验，发现我们无意中复杂化了。

生命周期的下一阶段是用户开始变得更高级，他们发现其他功能的顺序是什么？ 主持人： 如果只是平铺直叙地列出入门功能和其他99个功能，都是同一级别，直接抛给用户，这会让产品感觉臃肿。 Dax： 是的，至少在OpenCode的TUI（文本用户界面）里，我们的入门做得还不错，还是很简单。按Ctrl P会打开命令对话框，里面基本包含了OpenCode的所有其他功能，没有层级，没有自然的发现路径，用户就像被扔进了一个杂物抽屉。我们对新功能很兴奋，能快速实现它们，但没做艰难的工作去理解需要设计一个自然的路径去访问这些功能，而不是随意扔进这个杂物抽屉。这个杂物抽屉对某些情况还行，比如你需要快速发布东西帮用户解困，但如果不回头整理，产品就会感觉臃肿，用户甚至发现不了你那些很棒的功能。 主持人： 是的，我也遇到过类似问题。我的Epic Workshop应用里功能很多，尤其是有了代理后，添加功能变得非常容易。坦白说，用户提出的功能请求列表相当长，不是无理取闹。 Dax： 是的，功能请求都是真实的。 主持人： 对，所以我觉得有些产品就是在不停地勾选功能，看看能加什么，因为太容易了。 Dax： 所以我们谈的不仅是产品克制，知道什么不该加，还包括组织结构。我的入门体验有问题，因为我想把所有功能都塞给用户，所以我做了个教程，教程还是入门体验的一部分。但更好的方式是渐进式披露。我想用这个技能——这是我们的关键词，我们一直在谈渐进式披露。 主持人： 我觉得很多事情都像健康饮食。我们都知道怎么健康饮食，知道该吃什么，不是我们太笨理解不了，但这不代表我们总是健康饮食，因为这需要纪律和付出。渐进式披露就是个好例子，很多人可能大致知道它是什么，但要每天都记得去做，这才是难点。

嗯，有一个功能我特别兴奋，所以我就做了它。它会在用户第一次打开应用时弹出通知，比如说，“你看过这个功能了吗？”在某些情况下，这确实有用，比如你可以让那些真正喜欢你产品的人订阅，接收新功能通知。但我觉得仅仅因为你对某个功能很兴奋而频繁打扰用户，可能不是正确的方向。相反，你应该设身处地为用户着想，想想这个功能什么时候对他们有用，当你能检测到他们即将遇到相关问题时，通知才会出现，或者给他们一些正确的指引。我觉得这需要很强的用户同理心。

是的，是的。确实很难，因为你必须对自己兴奋的东西保持一定的残酷。很难进入一个全新用户的心态，他们在某种程度上可能根本不关心你在做什么。

是的，他们可能只是抽出一点时间给你一个机会。这是一个极高的门槛。你必须非常残酷地对待自己喜欢的所有功能，实际上如果他们只用其中1%的功能，只看到这一个功能，那才是最重要的。嗯，是的，每天都要记得这一点真的很难。

是的，是的。我们之前谈过几个方面，什么才是一个真正好的产品。我们谈过产品克制，也许可以多聊聊这个。渐进式披露和引导我觉得也很重要。

嗯，是的，我们多聊聊产品克制吧。你知道，当你收到开发者大量各种各样的问题时，你可能会看着其中一些，心想“我都不知道你怎么会觉得这是个好主意”。但其中有些可能很微妙，或者很难判断怎么去适配。你是怎么判断用户请求在这些问题中该如何定位的？

我觉得这是另一种无形的技能，随着时间会变得更好。你知道，和用户交流。我们都知道应该和用户交流，这似乎是个二元的事情：你要么不做，那就糟糕，要么做了，那就好。但实际上，仅仅因为你做了，并不代表你做得好。这本身就是一项技能，你要学会如何和用户交流，如何从对话中获得有用的信息。大致来说，我觉得这是一个渐变的过程。有时候用户给你一个想法，恰到好处，正是你缺失的东西，也许你甚至已经意识到了，只是在等待一个真实的数据点来推动你去做，这其实是看待问题的好方法。很容易做出没人想要的功能。

也许举个例子，比如James昨天或前天做的关于Daytona U盒子离线同步的功能，你能解释一下吗？

是的，是的，这可能是个很好的例子。这大概是下一层次的情况。当然，有些简单的情况是有人告诉你他们想要什么，且很合理，这没问题。还有一种情况是很多人都在描述他们遇到的问题，或者抱怨某些事情，他们可能过于关注问题的局部，你会发现其实有十个人说的都是不同的事情，但如果你退一步看，可能他们说的其实是同一件事。在OpenCode项目中，我们现在正在添加对各种不同沙箱方案的支持。你可以从一个中心位置运行OpenCode代理，生成在云端运行的代理，或者在git工作树中运行，或者在docker容器中运行。我们遇到了各种各样的问题，最终促使我们构建了这些功能。有公司谈到安全问题，他们不希望这些东西直接运行在笔记本上。有开发者想同时做很多事情，想要工作树支持。还有很多人想用云沙箱来大规模扩展工作。这些看似不同的需求，我们意识到它们其实都是工作区概念的特殊情况。如果我们实现了这个，就能解决所有人的问题。

这是产品设计中的另一个关键点。我们本可以直接添加git工作树支持，也可以添加docker支持，或者分别做这些事情，但我们有点耐心，觉得这些需求之间有相似之处，我们等到有了清晰的认识，发现可以构建一个单一的东西，隐式地解决这些问题和其他问题。这也是克制的体现，有时候就是时间问题，等到你对问题有了清晰认识再去构建，这样能节省时间，最终结果也更好。有时候这很痛苦，尤其是在现在这个疯狂的环境里。

因为每个人都在飞快地发布新东西，每天都有新东西不断出现。如果你处在竞争激烈的领域，我们也是，我们的每个竞争对手都已经发布了原生Git工作支持，他们都走得很远了，我们慢了很痛苦。所以不被这种节奏拉扯，等到有了清晰认识再行动，这也很难。

我觉得构建产品最重要的技能之一是知道什么时候该抽象，什么时候该构建解决方案。我有六个姐妹，还有四个嫂子。每个人都曾让我帮忙做软件解决方案，或者帮他们解决软件问题。我们家很有创业精神。

但有趣的是，每次他们来找我，我总是问他们那些大多数人都知道的问题，比如“你验证过这真的是个问题吗？”大多数时候我都会说你得先用最艰难的方式去做。因为如果不这样，你就是在为一个你不清楚的问题构建解决方案。我觉得这可能和产品克制相关，但又不同，是关于问题的清晰度。你如何培养对问题的清晰认识，放慢脚步可能是我们做到这一点的方式之一。先用最艰难的方式去做。也许我们还没有很好的工作流程，但这不代表不可能，临时解决方案真的那么糟糕吗？我们能拖多久，推迟用内置解决方案去解决，直到我们对问题有了清晰认识，能构建正确的解决方案。

是的，我觉得“放慢脚步”这个词现在对每个人来说都很可怕，但我觉得这可能是正确的心态。因为我们处在一个感觉大家都应该尽可能加速的环境里。现在的感觉是，如果我们不去思考，我们自然会越来越快。所以现在的工作是说服自己放慢一点，像你说的，用艰难的方式做事，容忍不发布解决方案，因为你还在更长时间地探索这个领域。现在做这件事很难，因为外界都在告诉你，如果你不这么做，你会被甩在后面，竞争对手会超越你。

就连我们自己也在思考这个问题，过去一周我们一直在思考我们的产品流程。感觉我们都被过度刺激了。有趣的是，我们公司对AI的使用相当保守，尤其是在开发编码代理方面。如果你看过我们的讨论，我们对让代理自由发挥的程度很保守。即便如此，我们回头看，发现“哦，我们也没能逃脱这个”，我们也陷入了同样的模式。

是的，现在真的很难。

是的，这真的很有趣。能在一个大家都催你加速的环境里放慢脚步。我一月、二月的时候，跳上了Cursor Cloud Agents的列车，迅速解决了很多项目中的积压问题，老实说效果很好。我觉得之所以能成功，是因为那些问题存在是有原因的，背后有产品决策和思考。但当我解决完这些问题后，我开始想到很多其他可以做的事情。

实际上，如果大家去看我的个人网站，我有个博客，那是一个相当复杂的软件，不是普通的开发者作品集网站。但我开始有很多新想法。如果你看最近六篇博客，每篇都是我给网站添加的新功能，讲述我是如何用代理实现的。

很棒。但每个功能底下都有我没做好的地方，比如某些地方没做好，导致整个网站崩溃什么的。这都是因为当实现速度太快时，你会感觉自己成了瓶颈，必须快速行动，结果导致了次优的解决方案。

我写过两篇后续博客，讲述我昨天的做法不对，今天改成了另一种方式。如果我当时能放慢一点，可能第一次就做对了。

是的，是的。这很奇怪，最近我从没像现在这样思考自己的心理状态。感觉我们的脑子被拉向某个方向，但我们并没有真正有意识地决定这是我们想要的工作方式。感觉我们都差不多对这个东西上瘾了，正在试图弄清楚我们和它的关系，什么才是健康的关系。

是的，我觉得克制的另一种形式是，有时候一个功能的想法是合理的，能解决真实问题，但你还得考虑另一个维度：你想永远维护这个功能吗？这不是一次性的事情，而是会不断出现的功能。它可能会和你应用中的其他功能交互，所以每次你想改别的地方，这个功能都会跳出来，变得有点碍事，影响你。正确的决定可能是，我们不在应用里加这个功能，虽然这会让应用变差，但为了产品的长期健康，这是正确的决定。

当你处在“我有一堆想法，我要发布”的模式时，代理永远不会反对你，比如说“嘿，Dax，慢点，这个功能可能不是个好主意”。它只会配合你的节奏。我发现自己这样做的次数少了，实际上我应该做得更多，因为整个系统的工作量更大了。

是的，你说得对。我想你提到代理永远不会让你慢下来。因为你在构建编码代理，我想知道是否有可能让代理具备一定的产品感知。比如说，先弄清楚问题，再让代理有整体的产品视角。你觉得代理能不能做到“让我先了解这个产品的整体情况，我觉得你可以通过这里稍微改动解决问题，或者我们把这些问题合并成一个简单的解决方案”？你觉得代理将来能做到这点吗？

是的，我觉得这更像是一个……

我主要感兴趣的是把这些智能代理看作是扩展我自己的能力。如果我想朝某个方向前进，这就像让我能更积极、更快速地朝那个方向走，这意味着如果我走错了方向，我的错误会被放大。我觉得这正是我感兴趣的领域——试图构建能够增强人类能力的东西，这也意味着有很大可能会被错误使用或者朝错误方向推进。确实有人在尝试用 AI 构建工具，更像是让另一个人在你身边帮忙做事。你说的那种情况更像是，我不是产品专家，也许这个东西能帮我培养良好的产品感觉，或者阻止我发布那些产品感觉很差的东西。我不太感兴趣的原因之一是我对大型语言模型（LLM）在这方面的能力持怀疑态度。这有点像让它们写一个好笑话，对我来说属于同一类问题。

我从没见过它们能写出一个好笑话。同样，我不信任它们在判断力、品味或感觉方面的能力。让它们帮我做好产品感觉也属于这类。我不是说这不可能，只是我对它们的感觉如此，我并不热衷于让它们做这件事。

嗯，理解。

我有时候会拿几个方案，比如怎么做一个功能或者修复一个 bug，然后拿给大型语言模型，确保我没有遗漏边缘情况。

我经常这么做，它们在这方面是很棒的伙伴。还有一点我很喜欢的是，虽然我们可能会太快地朝错误方向推进，但在调试方面，AI 完全是个胜利。比如给它一个堆快照，让它告诉我哪里有内存泄漏，或者是什么占用了这么多内存，这些事情通常很耗时间，我们甚至不愿意去做，但让代理疯狂调试并帮你找出问题，完全没有坏处。所以我绝对不认为它们有什么负面影响。

不过感觉我们对它们有点上瘾了，需要养成一些好习惯。

是的，有趣的是我问你……

你觉得这些智能代理有一天能做些什么吗？你最近发的一条帖子引起了我和很多人的注意，那个帖子获得了 1.4 万个点赞，我刚刚才注意到。你说“请闭嘴，我不在乎”，你说的那条帖子……

是的，那个帖子有 1.4 万个点赞，差不多有一千次转发，真疯狂。帖子内容是有人说“24 到 29 岁的工程师将很快成为科技领域最有价值的资产。”我忍不住笑了，可能是因为所有年长的人都死了吧。无论如何，帖子还说“前 AI 原则，后 AI 速度，是无敌的组合。”我敢打赌这条帖子获得了疯狂的互动，他们可能会从中赚大钱。

如果你看回复，他当然是在推广他的产品。

太棒了，太棒了。碰巧我 26 岁。

是的，我引用这条帖子是因为我很沮丧，不是因为他说的具体内容，而是因为我们所处的环境。感觉每个人都在试图把自己的大脑传送到一年后的未来，试图以那时的状态来运作。我理解这种心态，但现实是每天我们都在看到各种预测，说未来会是怎样，这让人很疲惫。事实上，要真正成为能准确想象未来的人，你必须正确理解很多假设。做到这一点需要非常了解自己，了解自己的偏见和不安全感，因为大多数人在做预测时，包括我自己，都会倾向于预测一个对自己有利的未来。

所以像我这样的人将来会赢。

对，这种预测往往是无用的。这个帖子就是个很好的例子，他说的是 24 到 27 岁，为什么不是 18 到 22 岁呢？如果前提是年轻人更能适应这些工具的话。我们被各种“未来会怎样，你现在就得准备”的信息淹没了，但没人真正知道未来会怎样。

完全同意。有趣的是，有些人会因为担心会出现通用人工智能（AGI），然后觉得一切都没意义，技能都不重要了。可能是真的，也可能不是。如果是真的，可能明年出现，也可能 20 年后出现，谁知道呢？我真的不知道。但事实是你无法为此做计划。所以我认为你应该假设未来不是那样，而是继续培养像产品感觉这样的技能，这种技能 50 年前就很有价值，将来也会继续有价值。

这是你现在可以培养的技能。除非我们真的遇到 AGI（谁知道呢），否则这仍然是非常有价值的技能。

是的，现在其实是一个非常好的时机去明确这是什么。正如我们一直在讨论的，我们都在思考这到底是什么东西。这种情况的出现是因为信息噪声太多，还有我们拥有的自由度太大。我最近意识到，我们之前因为不能快速发布功能，反而无意中做了很好的产品工作。

过去有人跟我说“我们应该做这个”，我脑子里想“那要花我四周时间，我不想做这个”，我会提出各种理由反对，为什么不应该等，为什么不应该发布这个功能。我们必须真正达成共识，明确它的价值，从各个角度审视它。我们不是故意这么做的，但这自然形成了一种平衡。

有点懒惰的成分，但也确实是这样。

虽然懒惰通常是负面特质，但它创造了一种良好的平衡。因为我们不是有意这么做，现在这种“懒惰”减少了，不是说我们不懒，只是被要求做事的痛苦降低了，我们不再那么多讨论，也不那么自律。现在是一个很好的时机去认真思考这些事情和你的工作方式，否则你不会有好结果。

有趣的是，现在团队里任何人都能轻松接触代码库的任何部分，因为他们可以问代理问题，让代理帮忙做事。但发布一个好产品远不止代码实现那么简单。你需要了解为什么事情是现在这个样子，历史是什么，方向是什么，新功能是否符合这些。很多细节一直被忽视。

是的，这些都是非常持久的技能，即使 AI 变得普及，这些技能依然有用。

正如你说的，这些技能 50 年前就有用，我觉得我无意中变得更擅长这些，因为这是最根本的事实。无论时间、技术、编程语言如何变化，你都会自然地变得更好，因为这是现实存在的东西。

我不认为这些技能会因为 AI 消失，尤其不会消失。证明是我们现在比以往任何时候都更关注这些问题。

是的，我觉得这很好。

前段时间你发了几段话，谈到所有大型 AI 实验室如何为我们补贴成本，你说他们宁愿死也不愿输掉这场竞赛。这很有意思，因为对他们来说这几乎是生死存亡的事，他们感觉是这样。结果是我们使用的成本被人为压低了，至少这是我对现状的理解。我的想法是，最终风险投资会投完钱，不再补贴，我们就得更注意使用的令牌数（tokens），所以你现在培养的产品工程师技能将更有价值，因为你不会在糟糕的想法上浪费令牌。

我对这事的看法比较复杂。很难全部解释清楚，因为我们深入了解推理（inference）领域，知道很多情况，确实很疯狂也很混乱。一方面，数据中心的建设会提供更多推理能力，这会帮助降低成本。我认为现在的令牌价格里有很大的利润空间，平均大概有 50% 到 60%。所以价格可能会降到现在的一半。

有些模型比最前沿模型便宜很多，但性能几乎一样好，所以有很大力量推动价格下降。我认为这种趋势会持续，数据中心建设会助力这一点。另一方面，市场上也有很多扭曲因素，让人很难判断什么是合理的。比如很多 200 美元/月的订阅计划，价格远高于推理成本底线，这些计划以各种方式扰乱市场。一是定价，二是我们使用这些工具的方式。比如我有时会让它做一个我知道具体改动的单行代码修改，这种行为会持续吗？有时我让它随机做些没什么目的的事，如果预算更紧张，我会这么做吗？现在人们的期望很疯狂，因为有这些计划，他们期望能无限制地用这些工具解决所有问题。

这也影响了他们产品的设计，可能他们把太多思考外包了。也许这完全是价格问题，如果订阅费是 500 美元/月，人们会少外包思考，结果会更好。现在很难判断什么是正常行为，因为市场混乱。我认为这些问题最终会解决。我不认为现在补贴过度，未来价格会大幅上涨。我觉得只是市场很嘈杂，我们无法判断当前行为是否会持续。

是的，我完全能想象未来价格基本保持现状，通过数据中心建设降低成本来实现可持续发展。你之前说的话让我觉得你对这个观点可能有有趣的回应。我一直在想，不是完全的“vibe coding”，但比如构建一个功能或修复一个 bug，看到代码不完美，或者肯定不是你会写的方式……

无论如何都要发布它，因为你知道六个月后如果需要回到那个代码库，模型会足够好，能够自动修复它，甚至能去修复那边造成的混乱。你如何平衡——我是说，我们之前说过想要放慢速度什么的，但一旦决定了我们想要这个产品，我们需要发布它，实际的实现过程中，你如何平衡实现速度和确保代码质量，至少保证那个功能足够可靠，同时认识到未来如果真的重要，你可以回来清理它。

是的。我试着从没有 AI 的世界来考虑这个问题，想象我会如何操作，因为很多时候这里其实没什么新鲜事。我觉得即使在 AI 之前，我们知道必须构建一个功能，也会意识到有三种不同的做法。一种非常 hacky 但很快，另一种介于两者之间，第三种很慢但从长远来看是正确的做法。

我们不会说总是做第一种，总是做第二种或第三种，这取决于情况，取决于所有事情的上下文。你会做出判断，决定发布哪一种。但你肯定知道第二种和第三种是什么，你可能也知道第一种以后怎么变成第二种，不是完全盲目，也不是你不知道自己做了什么决定。我现在也是这样看的。有时候某个功能很重要，我知道它所在的位置爆炸半径很低，即使它错了，我知道边界，知道最坏的情况也不是很糟糕。

我通常不会用“未来会有更好的模型”作为理由。模型确实变好了，但对我来说，根本上它们没变。我觉得它们更擅长遵循指令，更能达到我想让它做的事情，但在原始智能方面，它们似乎并没有真正以我需要的方式写代码。

举个很好的例子，前几天我有个非常基础的任务，可能就是实现一个单函数，结果它用了三层循环而不是一层。通常我会说这也许没关系，但它是在性能很重要的地方，输入长度可能会很大。所以我想试试模型能不能给出正确答案。我花了20分钟尝试不同的提示和模型，没有一个能给出高效的解决方案，最后我只能手动完成。是的，这些模型确实好多了，但它们还不能帮你解决这些问题。

所以判断力依然重要，培养良好的判断力依然重要。每件事都要具体决策，没有什么全局规则说我们总是做第一种，或者总是接受语言模型的结果。

所以我听到的是，Dax，是的，一切都变了，但其实什么都没变。

是的，感觉就是这样。我觉得每天我都在依赖我大约15年的经验。我不觉得——你可能记得，当年我们都知道 CSS 浮动技巧来让东西对齐，后来 flexbox 出现了，我们根本不需要记那些技巧了，它们就从记忆中消失了。那才是真正的游戏规则改变，你之前学的东西就像从没学过一样。

是的。

但我对这事没这种感觉。我觉得我依然依赖过去的痛苦经历，过去学到的教训。所以从这个角度看，确实感觉什么都没变。

这是个很好的观点。当我和代理一起工作时，无论是设置后台运行还是云端，还是更同步地与代理协作，在制定计划或引导代理时，我一直在参考过去的经验。比如我们不想走那条路，因为那个问题，或者我要确保用这个抽象而不是那个。过去的经验真的很重要。也许这只是我的自我安慰，我希望它依然重要，但我觉得如果我不做这些引导，最终结果会差很多。

是的，我觉得也是这样。

关于这个话题有很多争论，但我每天看到我们的工作，即使我们很保守，仍然看到负面影响，不是我看代码觉得“哦，好丑”，而是影响最终用户，影响团队协作，影响日常工作的乐趣，这些问题确实存在。我有个问题想问你。你觉得你现在的努力程度比人生中其他阶段是更多还是更少？

这是个好问题。嗯，这里面有个上瘾的方面，就是“再来一个提示，再来一个提示”。尤其是你有多个代理同时在不同项目或项目不同部分工作时，就是“提示这个，那个完成了，提示那个”，很容易熬夜。我前几天晚上就这样。

但我不认为这一定是负面的。

是的，我觉得这很令人兴奋，也挺有趣的。

我觉得你想说的是，自动化实现部分应该让我工作更少，对吧？我不再需要做那部分了。但我也觉得我现在发布的东西比以前多了，这肯定是。

是的。

但我觉得我工作强度和五年前一样，甚至更大。

嗯，这很有趣。我几乎把这当作证明，你脑子里有很多价值。也许我们说不清楚具体是什么，但我也是这样。我付出的努力比以往任何时候都多，困惑也比以往更多。说实话，我现在做的是我做过的最大项目，这也是个变量。但我觉得这对每个人都适用，大家都付出了比平时多得多的努力。这是真正的人类努力，不是无缘无故的。

AI激发了我们的这种努力。

我觉得这是个奇怪的视角，说这些东西接管了我们、替代了我们、帮我们解决问题，但实际上我们一直都在拼命努力。我们这么做是有原因的，这项工作确实需要我们付出。

这是个很有趣的视角。我不确定所有人都一样。我听到很多人说他们同时运行16个代理，但他们从不说这些代理在做什么，或者这些工作给他们生活带来了什么价值。

这也是我开始在博客上发布我发布的具体内容的原因之一，我想证明我确实一直让代理创造有价值的工作。确实有人发布更多，发布得更好，我也认为有些人已经具备产品感（product sense），发布得更好。

但也有一类人处于另一种状态，我想知道你有没有什么建议给这类人，如何更努力工作，同时交付更好的成果？

我们说的是积极的一面，那些高度自我驱动、能够自我管理、在做自己认为重要的事情的人。这类人现在可能比以往任何时候都更努力工作。但也有负面的一面，如果你处在一个没有动力的环境，只是完成任务然后继续，那种环境可能会被 AI 极大地负面影响。因为这些环境本来就不产出好工作，现在的动力就是“提示代理，按回车，继续”，动力比以往更低。

我觉得这对管理这类人的领导者来说尤其糟糕。我之前就想过，我们团队里有些人在加入我们之前，描述他们之前的公司时说，80%的人只是把烂活扔过来，20%的人一直在努力让大家多关心一点。现在这20%的人要处理10倍的痛苦，他们快要崩溃了，开始辞职。

所以我觉得这负面影响在缺乏良好激励环境的公司和团队里可能非常严重。我不知道未来会怎样，我觉得我们还处于早期阶段，可能这种反馈循环还没完全显现。

不过我开始看到一些早期迹象。比如我们自己一直尽量多用这些工具，现在开始觉得必须更有意图地使用。我看到其他公司也开始收紧，因为安全问题太多了，他们开始制定正式政策，明确到底想从这些工具得到什么。

我觉得这种情况会被纠正。就像我一开始说的，我们都在摸索和这些工具的关系，没有人真正搞明白，我们处于一个奇怪的阶段。但希望最终能找到一个好的平衡。

也希望大家别再预测未来了。Dax，我还有最后一个问题想问你，我会请你给出一个具体行动，帮助别人提升产品感或用户同理心。但在问之前，或者你回答之前，你觉得还有什么是我们今天没谈到，但大家应该知道的关于打造好产品的事情吗？

我想说的唯一一点是，你首先得说服自己这真的很重要。我觉得世界上还有另一股力量，和“你们会在这里，它会解决一切”这种能量差不多，有很多东西试图说服你，这些东西不重要，不需要做好产品，不需要好好做，你看那些成功的公司产品多烂。

有太多理由和借口让你不去做好产品。

所以，首先你得承诺自己，这事确实重要。我个人觉得重要，我敬佩的那些做得很棒的人，他们都觉得重要，你能从他们的作品里看到这一点。我觉得我们的东西还不够好，我在努力达到他们的水平。

所以我觉得要想做好这件事，你必须真正相信它，因为你会一直被挑战。

这是个非常棒的观点。大家的行动建议是，如果你还没相信它重要，就想办法让自己相信。非常感谢你，Dax，今天非常感谢你的时间，也很喜欢你在 X 上分享的内容，让我们得以一窥你在试图打造好产品时的思考，尤其是在代理试图把你拖进“什么都做”的泥潭时。

是的，谢谢邀请我。就像我说的，这一直是我们关注的重点，能通过和你对话理清思路很不错。很高兴。

好，谢谢大家，我们下期见。

再见。