Ryan Donovan：大家好，欢迎来到 Stack Overflow 播客，一个探讨软件和技术方方面面的地方。我是 Ryan Donovan，今天的主持人，我们要谈论一个不算小的话题——软件工程本质的变化，以及在AI革命下软件所能做到的事情。所以我今天的嘉宾是返场嘉宾 David Hsu，Retool 的首席执行官。David，欢迎回到节目。

David Hsu：谢谢，Ryan。很高兴来到这里。

Ryan Donovan：是的。既然你以前来过，我们就跳过开场白。如果大家想了解你的背景故事，可以收听上一期节目。显然，每个人都看到了AI在某种程度上改变了软件的可能性，那么，现在谁才是软件工程师呢？

David Hsu：是的。我认为软件行业在过去10年或20年里经历了一段变化非常小的时期，坦白说，但在过去18到24个月里，它正在经历一场相当惊人的转型，我认为体现在两个方面：其一是软件工程的性质，或者说今天谁才是软件工程师。

Ryan Donovan：嗯。

David Hsu：以前，要构建一个功能性的网络应用需要大量的技能和知识。你需要知道如何编码，但你也需要了解一堆关于……嗯，比如，如今在 React 中，Redux 是大多数人管理状态的方式。React 和 Vue 有什么区别？我该用 Heroku 还是 AWS？基本上所有这些“事实”。所以，我认为，软件工程师意味着什么，其性质正在改变，这是其一。第二是软件本身的性质正在改变，也就是说，软件过去只能做完全确定的事情。

Ryan Donovan：没错。

David Hsu：所以，如果你想将两个数字相乘，没问题。

Ryan Donovan：小菜一碟。

David Hsu：是的。但如果你想让软件为你创作一首歌，软件肯定做不到。

Ryan Donovan：对。

David Hsu：而现在，它可以做到了。所以，软件的总可寻址市场，或者说你能用软件解决的问题范围，我认为已经发生了根本性的转变，我认为在未来几年，我们将看到软件创作的蓬勃兴起。我们谈论数字化变革，或者公司谈论数字化变革。那是软件的第一波浪潮，就是将事物数字化。我认为下一波浪潮——可能是更大的浪潮——是思考软件可以完成哪些过去更像是人类完成的任务。所以，这是一股自动化浪潮，我认为它可能会让我们所有人都失业，包括我自己。想想有点吓人，但我想，这是两个相当巨大的变化。

Ryan Donovan：是的。那么，让我们从软件工程师面貌的改变开始。随着“氛围编码”和AI智能体的出现，软件开发变得更容易上手。有些人甚至说，新的编程语言是英语。你认为随着每个人都能创造软件，他们能够创造出合格的软件吗？

David Hsu：好问题。我认为以目前的产品来说，答案是不能。我们在世界各地的 Bolt、Lovable、Replit 等产品上看到了这一点。非工程师——我的一些非工程师朋友——现在能够构建相当复杂的网络应用来追踪个人生活、帮助孩子学习数学等等，这确实很了不起。你现在可以构建程序了，这很棒，这项技术不可思议。但当我观察这种软件有多少属于“玩具应用”而非生产应用时，世界上大多数软件是由大公司为生产用例构建的。

Ryan Donovan：对。

David Hsu：关于软件，这是一个相当令人震惊的事实，但实际上大多数软件是面向内部的，这对大多数人来说可能很意外。如果你想想看，大多数公司，例如财富500强公司，其中有多少是软件公司？并不多，也许10%。所以，财富500强中90%的公司实际上雇佣了大量软件工程师。他们日复一日所做的，就是构建生产级的内部软件来运营业务。所以，无论你是从 CVS 取处方，从亚马逊订购商品，还是坐飞机去纽约，都有大量的内部工具在支撑，可以说是内部工具在运行着世界。

Ryan Donovan：没错。

David Hsu：当我看到——氛围编码能让我们达到那个目标吗？或者用这种方式生成的软件——我会信任氛围编码生成的软件去处理取处方这样的任务吗？我想答案肯定是不会。所以，我认为这里确实缺少一些根本性的东西。但目前，答案是否定的。

Ryan Donovan：是的。我认为这很有趣，你谈到内部工具，我想当人们谈论“平民开发者”时，那种由氛围编码和这些AI智能体赋能的现象，就像是，是的，我为我自己创建了一个小批处理脚本或小工具。但是，这与你为公司安排处方而构建的工具之间有什么差距？我们甚至还没讨论产品软件，就是你拿来卖钱的那种。

David Hsu：是的。嗯，我认为风险要高得多。你可能看到过，我想是不久前的一个头条新闻，Replit 删除了某人的数据库。

Ryan Donovan：哦，是的。

David Hsu：而且，你知道，他们对此不太高兴，因为所有数据都丢失了。

Ryan Donovan：对。

David Hsu：但这就是一个例子，我认为问题在于今天很多这类产品都是构建在 JavaScript 之上的。我的意思是，它们只是输出原始的 JavaScript 或原始的 React 代码，这对软件工程师来说其实很棒。这就是为什么我认为 Cursor 和 Claude Code 非常有效，所以，我实际上没有把它们归入这一类。它们也是“氛围编码”，但几乎是工程师在“氛围编码”。所以我认为那不一样。那相当安全，因为工程师实际上可以阅读代码并理解发生了什么。我认为真正的危险在于，当非开发人员使用输出代码的产品时，他们很难去看代码然后判断，比方说，有这么一条语句：DROP TABLE。

Ryan Donovan：对。

David Hsu：非工程师读到这个会说：“我不知道，看起来合理。我来运行一下，看看会发生什么。”而工程师会说：“哦，DROP TABLE，等等。也许我们还不应该这么做。”

Ryan Donovan：是的。

David Hsu：所以，这就是一个例子，我认为这些非开发人员用来进行氛围编码的“基础层”，或者说是原语的抽象层次，实在是太低了。这几乎就像是，比如说 Claude Code 为你输出了汇编语言。如果它输出汇编，我可能会说，这有用，但读起来相当困难，调试起来也相当困难。理论上，我是计算机专业毕业的，10-20年前我写过汇编，但我不记得了。它非常详细，非常底层。

Ryan Donovan：嗯。

David Hsu：所以，这有点像现在非工程师使用这些氛围编码产品的感受。几乎就像软件……如果你是一个软件工程师，想象一下如果 Claude Code 输出汇编。你会想：“嗯，这很好。我猜我运行它，它应该能工作吧？但这有点风险。”对吧？所以我认为对工程师来说，Claude Code 很棒，但对于非工程师，这些产品真的需要进化，我认为这就是 Retool 可以发挥重要作用的地方。

Ryan Donovan：嗯。是的。这是个有趣的对比，很多程序员处理编译后的二进制文件，对吧？他们的代码被编译成汇编或机器码，但这是一个更确定的过程。你知道编译器要做什么。每个人都在发现未定义行为并排除它。我们如何才能达到那种程度，用这种“氛围编码”的 JavaScript？或者我们能吗？

David Hsu：所以，这是我的观点，但我愿意接受挑战。我的感觉是，你确实需要在“氛围编码”的可能性周围设置大量的防护栏，特别是对于非工程师。然后，我认为这实际上将是软件工程师工作的演变方向。我的意思是，我认为软件工程师亲自动手编码的时代基本结束了。你知道，现在是2025年，至少对于内部工具来说，我认为肯定结束了。我的意思是，软件工程师不再是在键盘上敲击“让我为这个内部工具写代码”，我认为软件工程师的工作将会改变。相反，他们几乎会像架构师一样。“我该如何构建防护栏或基础架构，以允许这些非开发人员去构建内部软件？”目前许多氛围编码，尤其是这些消费级产品的问题是，没有防护栏。所以，删除数据库非常简单。你会删除数据库。而我认为，如果你能让这些开发人员（指工程师）构建防护栏或更高级的原语，比如，在公司里你可以说：“嘿，这个 React 组件是客户视图。如果你是一个非工程师，想要逐个查看客户信息，你总是要使用这个客户组件。顺便说一下，这里有一个 ORM（对象关系映射）供你使用，这是客户对象。客户对象被定义为我们 Postgres 数据库中的这些东西，加上 Databricks 数据库中的这些，再加上 Salesforce 里的那些，例如。”一旦工程师定义了这些更高级的原语，非工程师就可以相当安全地工作。你甚至可以说——工程师可以说——“嘿，非工程师永远不能通过这个 ORM 删除数据库。”所以，我认为很多氛围编码产品的问题在于没有防护栏，完全没有工程师参与。所以，当没有防护栏，没有更高级的原语，只是输出原始代码时，这真的相当危险。所以，这就是 Retool 在这次氛围编码革命中的全部论点：我们认为氛围编码是一项惊人的技术，对于我称之为“玩耍”或原型应用来说，目前效果很好。但真正的机会在于，如果它能够改变内部软件的开发方式——再次强调，超过一半的软件是内部软件——你真的需要这些防护栏。如果我们能提供这些防护栏，让工程师以安全的方式定义这些防护栏，那么非工程师实际上可以构建相当有趣的应用。

Ryan Donovan：嗯。

David Hsu：也许我在这里打一个类比，是关于商业智能（BI）的。今天，如果你让任何工程师，或者让我去构建一个BI仪表板，我首先会说：“哦，让我去用 Metabase，让我用 Tableau，让我用 Looker。”我会使用任何BI工具。

Ryan Donovan：对。

David Hsu：我使用BI工具的原因是，这样我可以只专注于我需要写的东西，也就是那10行 SQL 来构建我的图表。我不想处理数据库驱动，不想处理身份验证，不想处理授权。我甚至不想处理前端图表组件。我只希望所有这些都为我做好，我只做 SQL。

Ryan Donovan：嗯。

David Hsu：有了这个，你现在可以看到很多数据人员，甚至是非技术人员，可以去学一点 SQL，他们就能构建相当有说服力的图表，并实际分析数据。我认为这种革命也会发生在应用程序上。今天，应用程序的构建方式……我的意思是，如果你氛围编码一个BI仪表板，它可能会到处都是漏洞，没人那么做。每个人只会说：“嘿，你为什么不氛围编码在 Tableau 上运行的 SQL 查询标题呢？”

Ryan Donovan：嗯。

David Hsu：这就是我们试图对所有应用程序做的事情。就是这个想法。

Ryan Donovan：听起来我们已经从沙盒化危险代码，转向了沙盒化危险的编码者。而解决方案的一部分，似乎是你提出的软件本身更大程度的组件化。是这样吗？

David Hsu：是的，没错。我认为问题在于现在的层次太低了。我举个我们开发者可能认为理所当然的例子。假设你正在构建一个内部工具，你正在构建一个流程，当你在表单中按下提交按钮时，你想禁用那个按钮，因为你不想让人连按五次，提交表单五次，对吧？

Ryan Donovan：对。

David Hsu：你知道，这很合理。但在 React 中做到这一点实际上需要很多工作。你需要做的第一件事可能是引入一个状态管理库 Redux。然后你说：“嘿，当我按下按钮时，我想把 isFetching 设为 true，然后我想发起获取请求，然后发送 POST 请求。当 POST 请求返回时，isFetching 变为 false，这样按钮就可以再次启用了。所以当 isFetching 是 true 时，按钮应该被禁用。”如果你仔细想想，这实际上有很多逻辑。

Ryan Donovan：对，当然。

David Hsu：至少对于内部工具来说，按钮实际上没有理由被多次按下。当然，并非所有软件都这样。如果你在一个电子游戏中，你可以想象，“嘿，实际上连按五次按钮。”也许是件好事。你希望人们连按五次按钮，例如。所以，我认为这是一个例子，如果你缩小问题的范围，如果你说：“嘿，我们不是对所有软件都感兴趣，我们只对内部工具或内部信用应用程序感兴趣，”那么你可以说：“嘿，按钮实际上在点击后应该总是自动禁用，”并且那个 HTTP 请求正在发出，直到它返回。它应该被禁用。所以，这是一个例子，说明 React 在某种程度上几乎就像汇编语言，对吧？它没有为任何特定用例优化。它就像汇编一样，在某种程度上是为所有程序优化的。但就像我们远离了汇编一样，我认为有一天我们也会远离 React，转向这些更高级的语言。尤其是为了让这些非工程师能够不犯错，因为非工程师不想担心 Redux 状态管理。我的意思是，这对很多程序员来说都超出了他们想考虑的范围，他们不想考虑函数式编程，不想考虑如何折叠状态，你知道吗？

Ryan Donovan：对。只要禁用按钮就行了。无论你需要做什么，禁用按钮就行。

David Hsu：没错。所以，我认为你说的对，我们需要更高级的原语。我们需要更高级的编程方式，而不是只写汇编。

Ryan Donovan：是的。我想知道，对于这种LLM驱动的氛围编码、代码生成，有什么可能的方式来实现那个目标。我可以想象某种功能缓存，某种检索增强生成，或类似的东西。但我想知道你对防护栏的机制有什么想法？

David Hsu：是的。这就是我们正在做的事情，所以我可能有点偏颇，但我真的认为这将释放明天的开发者。举个例子，我们正在开发的一个功能叫做“安全引擎”，它的作用是允许你语义化地标记整个组织的数据，然后能够说：“嘿，这些特定的数据表，或者表内的这些列或行，永远不应该对这些特定的 Okta 组可见。”

Ryan Donovan：嗯。

David Hsu：这实际上可以让你达到这样一个境界：你生成的任何应用程序，至少从数据角度来看，默认是安全的。我的意思是，今天如果你给一个非开发人员说：“嘿，这是对我数据库的生产访问权限，你可以疯狂地构建一些氛围编码的应用，”这相当危险，对吧？而如果你能说：“嘿，我的用户表中的 SSN 列永远不应该被这些 Okta 组看到，”那么你就可以说：“嘿，无论你如何构建这个应用程序，因为这个应用程序运行在 Retool 平台上，我们保证 SSN 永远不会暴露给这些 Okta 组。”如果你想想看，这实际上是一种更好的安全实现方式。你希望这些保证在数据层面，而不是在“信任开发者”的层面。如果你看看今天的安全状况，说实话，现在的很多安全是“信任开发者”。

Ryan Donovan：对。

David Hsu：我的意思是，这有点像，我希望安全漏洞能在拉取请求中被发现。如果没被发现，它就会进入生产环境，你可能会被黑客攻击，或者SSN泄露，实际上这种情况经常发生。说实话，我认为这已经不行了。再加上你可能无法信任的开发者，或者未来可能不知道自己在做什么的开发者——这真的会出大问题。所以，我认为沙盒化，或者制定这些规则，让开发者——或者明天的开发者——能够完全自由地操作，即使他们拥有完全的自由，仍然不会搞砸。我认为这就是未来的方向，所以这几乎像是“约束带来自由”。

Ryan Donovan：是的。嗯，多么奥威尔式啊。不，这是用户访问控制，对吧？就像对于你的客户用户，你不会给他们所有数据的访问权限。有一个应用层，有数据访问，然后这似乎是对此的分级应用。你将这应用于开发者，这里所谓的“开发者”。

David Hsu：是的。

Ryan Donovan：那么，让我们谈谈我们开始谈话的另一面——更大的自动化。你提到了自动化一首歌，或类似的事情。你如何看待软件本身发生的变化？

David Hsu：所以，我对过去20-30年左右软件市场的理解是，有很多过程是完全确定性的。我的意思是，做A，然后做B，然后做C。如果30年前是由人类完成的，那么这些事情现在大部分都是由软件完成的。不是全部，我们还没有完全数字化，但很多。

Ryan Donovan：嗯，是的。

David Hsu：越来越多的行业中，纸笔正在消失，所以很明显很多东西正在被数字化。然而，今天大多数公司，当他们无法将一个流程数字化时，他们会将人类插入那个流程，所以也许需要人类判断。比如，你发放信贷，批准抵押贷款，或者需要验证ID。所以，人类需要查看ID并验证是否是本人？基本上就是这类事情。所以，这是一个例子。另一类例子可能需要一些创造性。所以，也许第一类是验证——你不完全信任机器。第二类是创造性，也就是：“嘿，我们公司今年的战略是什么？”

Ryan Donovan：嗯。

David Hsu：我在打一个销售电话，需要说服他们购买我的产品。你知道，很难在软件中以确定性的方式编码这个。所以，你需要人类；你需要人类销售员去做。我想创造性是另一个例子。我认为我们现在在客户群中开始看到的是，LLM，特别是在这些特定任务上，开始变得非常非常有效。所以，以销售用例为例，现在SDR（销售开发代表）实际上可以通过电话交谈，或者我应该说LLM SDR实际上可以通过电话交谈。你知道，目前延迟还不是很好。可能有一两秒，但现在实际上相当可行了，技术只会越来越好。延迟会下降。将达到这样一种程度，我认为从销售、从支持的角度来看，你实际上可以通过电话与LLM交谈，回答你关于产品的问题，也许如果你有……购买产品，这很酷。所以，这是一个例子，我认为软件整体的总可寻址市场可能会增长3、4、5倍，我想。所以，软件将会爆发式增长。以前，我认为问题是：“我能构建软件来完成这个任务吗？”答案是不能。现在，很多时候，答案将是“是”。所以，我认为这比以往任何时候都更重要。实际上，现在成为一个软件工程师很棒，因为软件工程师正站在领导这一潮流的前沿，去思考如何应用软件工程和LLM来解决这些相当模糊、不明确的问题。所以，我认为这是一场相当大的革命，而且我认为我们仍然处于早期阶段。

Ryan Donovan：是的。

David Hsu：我认为你还没有真正看到LLM在劳动力数据中显现出来，但我想你会看到的，一旦你开始看到它，我认为在某种程度上会相当可怕，但另一方面……

Ryan Donovan：那将是奇怪的时代。

David Hsu：在某种意义上，也相当有启发性。是的。

Ryan Donovan：是的。你谈到LLM的创造性，我想，它将会有一些创造性，而且它与人类的偏好总体上相当一致，但它产生的那种创造性是统计上有效的，对吧？它是一种数据驱动的创造性。你认为LLM会停留在那种程度吗？比如，这是平庸的初稿，或者类似的东西，然后让领域专家介入，还是你认为它们有可能达到领域专家的水平？

David Hsu：是的。我们看看。关于创造性方面，我确实同意你的看法。你知道，我从来没有读过任何LLM生成的东西让我觉得“哇，太不可思议了。”至少从文体风格的角度，我还没有那种感觉。但说实话，大多数工作并没有那么高雅。

Ryan Donovan：那倒是。是的。

David Hsu：我的意思是……很多工作是相当平庸的。是的。

David Hsu：是的。你知道，比如我读很多小说，我喜欢小说，但大多数作品不是诺贝尔奖级别的小说，可以这么说。你知道LLM能达到那个水平吗？老实说，我不确定，但它不需要达到那个水平就能产生很多有经济价值的工作。所以，我想说的两点——所以，这是一点。第二点是，当你将LLM缩小到一个特定任务，给它正确的输入时，我们在客户群中看到的是，它实际上表现得令人难以置信地好，常常比人类更好，特别是如果你考虑到LLM实际工作的速度。举个例子，我们在 Retool 开始做的一件事是，我有一个会议录音机。我想我们用的是 Whisper，我们基本上转录，至少我所有的会议，我都转录，然后保存下来，实际上在一天结束时，我可以用LLM梳理这些会议。所以，这实际上非常有效。而且，你知道，过去当我尝试用LLM做一些工作时，会非常困难，因为它没有真正的上下文。它不太了解发生了什么，无法真正访问我们的文档，无法真正访问我们的会议。但如果你让它访问会议记录，访问文档，它实际上就有很多上下文了。现在，上下文工程相当棘手。你不想给它太多上下文，不想让它负担过重，但如果你能给它特定、正确的上下文，正确的文档，正确的会议记录，它的效果出奇地好。它比我好吗？我的意思是，老实说，在某些情况下，它可能比我在我的工作上做得更好。但即使在它不如我的情况下，也许它能达到我工作质量的80%，但它的速度快得多。所以，当你考虑在某些情况下，质量确实很重要。

Ryan Donovan：嗯。

David Hsu：但很多时候，实际上，我会很乐意接受两分钟内达到80%的质量。而不是五天后达到100%的质量，你知道吧？所以，我认为当我们这样想时，我认为当你给LLM正确的输入，并且你考虑它所做的，不仅仅是“工作是否和我产生的一样好”，还要考虑时间、成本，那么它就开始看起来相当可怕了，因为老实说，LLM相当不错。

Ryan Donovan：嗯，在信息检索、总结和综合方面，它相当惊人。我以前也用它做过一些研究，它提取信息的速度比我快，我得挖半天——

David Hsu：我也是。是的。

Ryan Donovan：但是，你知道，最终稿的东西，那是我总希望有人类参与的地方，对吧？

David Hsu：我认为很多伟大的作品，至少在艺术上，都有某种令人惊讶的元素，而你知道，LLM目前并不太令人惊讶。所以，我同意，我认为最后那一步，但说实话，我不知道惊喜或愉悦是否真的是大多数知识工作场景中工作的一个因素。

Ryan Donovan：当然。

David Hsu：你知道，当我读一份文件时，我不会说“那真是一份很棒的文件，因为我太惊讶了”，我未必能这么说。

Ryan Donovan：“多么令人愉悦的功能规格书！”

David Hsu：是的。我的意思是，有时我确实有那种感觉，但很多时候，你知道，它是否能解决客户的问题？老实说，我认为LLM在综合客户反馈方面会比任何一个产品经理做得更好，特别是当你考虑到它综合了多少信息，以及它能多快完成时。

Ryan Donovan：所以，我认为你之前提到的那个引人注目的数据是，到2030年，10%的工作将被自动化，我想是。你能谈谈你认为哪些工作会是这些吗？

David Hsu：所以，这个数据的背景是，我们发布了一个叫“智能体”的产品。也许我简单解释一下。

Ryan Donovan：好的，好的，当然。

David Hsu：然后我再回到这个话题。什么是智能体——这是目前LLM工程中的一个标准术语——所以，它是一种“ReAct 风格”的智能体。所以，它基本上“推理”和“行动”。它通过推理，你给它一些输入，你说：“嘿，你的目标是将这个输入转换成这个输出，”基本上，并且你提供这些工具给它使用。所以，LLM基本上会思考，“我如何从这个输入得到这个输出？”它会想：“好吧，给定这些工具，我应该先应用这个工具，然后应用这个，再应用这个，然后也许我就能得到我的输出。”这里真正酷的一点是，至少在LLM出现之前，这实际上不是确定性的。以前你可以有工作流，你可以说“嘿，做A，做B，然后做C，A是计算，B是计算，C是计算。”是的，你知道，那就是代码，从上到下运行。现在，有了这个LLM，至少对于智能体，你有了这些工具，你思考应该使用哪些工具来实现这个结果。这是一种相当奇怪的工程思维方式。

Ryan Donovan：当然。

David Hsu：这有点像人类做的事。如果你让一个人说“嘿，去解决这个支持票”，那个人会说：“好吧，我有什么工具可用？”或者“嘿，去制定这个公司的战略。”那个人会想：“好吧，”假设我是一个顾问，我在麦肯锡工作，我会想：“我该如何制定这个公司战略？嗯，可能首先，我想收集数据。我想了解当前的战略。它有效吗？没效吗？然后我看看数据，然后说‘好吧，竞争对手在做什么？’所以，也许我会查看竞争研究工具，进行网络搜索，不管是什么，最终，我用一个写作工具来产生最终结果。”基本上就是这样。我们认为它相当了不起，而且实际上增长非常快。按照目前的速度，我们预计到2030年，实际上将自动化美国10%的劳动力，用的就是这个产品。

Ryan Donovan：对。

David Hsu：所以，这很酷。但我具体的意思是——我想你知道为什么它增长这么快——我认为很多工作，如果你仔细想想，基本上可以这样分解。我想举一个能真正引起 Stack Overflow 观众共鸣的例子。如果你想想为什么 Cursor 和 Claude Code 这样的应用程序如此有效，原因是它们是智能的、自主的。而且它们有工具。我的意思是，你实际上可以用 ChatGPT 应用程序完成 Claude Code 做的所有事情，对吧？所以，你可以说：“嘿，ChatGPT，给我写这段代码。”它给你代码，你复制，粘贴到你的 IDE，运行，得到一个错误，你把错误复制回去，再到 ChatGPT，说“我得到了这个错误。这还是个问题。再来一次。”你知道，你就是这样来回操作。实际上，这就是 Claude Code 基本上在做的事情。但 Claude Code 没有进行复制粘贴——它直接写入 IDE，但基本思想是，它能够代表你做事。然后它意识到，如果你告诉它“嘿，我运行了，得到了一个错误”，它会自己运行。它会说“哦，我得到了一个错误，让我做点什么。”所以，我认为了不起的是——这就是为什么我认为在测试中，Crystal 或 Claude Code 比复制粘贴到 ChatGPT 中要有效得多。

Ryan Donovan：对。

David Hsu：但如果你想想今天大多数知识工作，大多数人使用 ChatGPT 的方式——大多数知识工作者包括我自己使用聊天的方式——我们总是在来回复制粘贴到 ChatGPT 中。所以，如果你能想象将类似 Claude Code 这种智能体方式带入，并让它附着在你拥有的所有上下文上，附着在 Google Docs、所有工具、所有系统（Salesforce、服务单系统）上，那么你几乎可以想象，对于所有其他工作，不仅仅是软件工程，也会发生类似的革命。这基本上就是 Retool Agents 产品。所以，我们允许你定制构建工具，然后让LLM实际使用这些工具在你的业务中做事情。所以，如果你这样想，软件开发者的工作在过去的6到12个月里变化如此之大。我认为类似的革命将在未来18个月内很快发生在所有工作中，一旦我们赋能软件工程师能够构建这类智能体，这正是我们产品的设计目标。

Ryan Donovan：是的。我的意思是，回到你之前说的，听起来将会有一个有点吓人的重构，关于我们这些人的工作是什么。所以，你知道，希望我们都能安然度过。会有，你知道，技术动荡的政治解决方案。

David Hsu：老实说，我有点担心，因为我认为你看到美国制造业工作岗位消失的一些后果，现在也许它们会回来。我们看看。这是否是件好事，我不确定。但如果知识工作在美国消失，我的意思是，我们剩下的就不多了。如果服务业经济消失了，那就没剩下多少了。所以，是的，我们看看。我认为这是一个令人担忧的时代，但我认为至少在未来几年，软件工程师会有非常多的工作要做，因为所有这些都需要由软件计算机来构建。

Ryan Donovan：现在是节目的表彰时间，我们要表彰一位来到 Stack Overflow，分享知识、分享好奇心、为自己赢得徽章的人。今天，我们表彰“流行徽章”的获得者——有人给出了一个非常好的答案，得分超过了被采纳的答案。祝贺 Waseem Wisa 回答了“Sass编译器在混合宏放在单独文件夹时抛出‘未定义混合宏’错误”。如果你对此感到好奇，我们会在节目说明中提供答案。我是 Ryan Donovan，我是 Stack Overflow 播客的博客编辑和主持人。如果你有评论、问题、想讨论的话题，请发送电子邮件至 podcast@stackoverflow.com，如果你想直接联系我，你可以在 LinkedIn 上找到我。

David Hsu：我是 David Hsu，Retool 的首席执行官。如果你想在网上找到我，我在 Twitter 上是 D-V-D-H-S-U，retool.com 是你也可以找到 Retool 的地方。谢谢你邀请我。

Ryan Donovan：好的。非常感谢大家的收听，我们下次再聊。

订阅播客 在你喜欢的收听服务上订阅《Stack Overflow 播客》。Apple Podcasts, Overcast, Pocket Casts, Spotify, RSS feed 作者 Phoebe Sajor 内容助理 员工 Stack Overflow 播客 数据原语 AI 氛围编码 AI编码 AI助手 AI智能体 安全 软件架构