在新一期的《The Breakdown》播客节目中，David Lieb 和 Tom Blomfield 邀请了他们的 YC 同事、同样是 General Partner 的 Pete Koomen，分享了自己使用 AI 工具的一些感受，有时奇妙，有时头疼。也深入探讨了构建 AI 原生软件的意义，以及为什么未来属于那些让用户能够教机器如何思考的产品。

以下是这场播客的内容实录：

David Lieb：欢迎来到《The Breakdown》播客的最新一期节目。今天我们很荣幸请到了我们 YC 的合伙人 Pete Koomen。Pete 曾创立 Optimizely 公司，这家公司开发软件帮助企业进行 AB 测试。Pete，欢迎你来。

Pete Koomen：谢谢邀请，能来到这里我非常高兴。

Tom Blomfield：你最近写了一篇文章，在网上引发了不小的轰动。基本上是在对所有构建Agent的人说，他们完全做错了。能跟我们详细说说这件事吗?

Pete Koomen：好，我在日常生活中使用 AI 时，其实有过两种截然不同的体验。一方面，当我使用像 Cursor 或 Windsurf 这样的工具，在 AI 的辅助下编写软件时，感觉就像是在使用有史以来最强大的工具，让我有一种想出什么就能创造什么的感觉，脑子里能想象的任何东西，都能通过这些工具在眼前实现，这让我对 AI 兴奋不已。

但另一方面，在我用惯了一些原有APP，但它后来加了 AI 功能的时，感觉却完全不同。使用那些应用里的 AI 功能反而变成了一件麻烦事，用 AI 反倒比我自己直接做更费事。

举个例子，我拿 Gmail 团队把他们的 AI 模型 Gemini 整合进 Gmail 界面的那个功能切入。那是 Gmail 里一个用来撰写邮件草稿的小助手，你给它一些指令，它就能帮你生成邮件草稿。

Tom Blomfield：而且 Gmail 用的底层 Gemini 模型本身非常了不起，对吧?

Pete Koomen：Gemini 模型确实很强大。我们内部也大量用它来自动化自己的工作，我对他们的成果印象 深刻。不过，我觉得它的大部分能力都隐藏在一个糟糕的界面后面，用起来让人很抓狂。这也是我那篇文章聚焦的重点。我举的例子就是刚才提到的 Gmail 界面里的写邮件草稿助手。它让我输入一些指令，例如在这种情况下，我希望它帮我给老板 Gary 写封邮件说明“我女儿今天早上感冒，我今天无法去公司了。”然后它就会生成一封邮件草稿，帮我减轻负担。好了，这是我在界面里输入prompt后得到的邮件草稿: “亲爱的 Gary，我写这封邮件是想通知您，我女儿今天早上患了感冒。因此，我今天无法来办公室上班。感谢您的理解。此致敬礼。 ”

Tom Blomfield：如果我收到这么一封邮件，我会觉得......Pete 的大脑好像被什么东西控制了一样。

David Lieb：或者他是遭遇了网络钓鱼攻击，我得举报有人冒充他。总之这邮件一定有问题。

Pete Koomen：哈哈，感觉就像账号被黑了一样。这里面有两个大问题:第一个问题，正如你们指出的，这封邮件听起来一点也不像我写的。如果你收到这封邮件，肯定以为是别人假冒我的账号发的。不是我 账号被黑，就是我被骗点了钓鱼链接。

第二个问题，就是我为了让 AI 写出我想要的邮件草稿，给它写的那段prompt长度几乎和草稿本身一样长。这正是我的想说的：一方面，使用 AI 可以让你感觉自己拥有无限的超能力；但另一方面，使用 AI 有时又令人沮丧，反而增加了额外的工作量。

Tom Blomfield：可能我们话题有点跳跃，但理想的 AI 体验在我看来应该是这样的：我只需要对 AI 说，“我 女儿生病了，你帮我把我今天的日程相关事宜都处理一下。” 然后 AI 就会自己查看我的日历，把当天涉及的人都找出来，分别替我发送合适的邮件并调整安排。这也许一下子说到了终极目标，但这才是理想的 AI 用法，你觉得呢？

Pete Koomen：我觉得你说得完全没错。以目前 AI 模型的能力，其实完全可以做到你说的那样，它能预 先想到“我女儿生病不能来上班”这件事会引发的所有后续事项，然后帮我把那些事情都处理好。不过现实情 况是，我们现在构建的产品还远没达到那个程度。至少 Gmail 团队目前做的还不是你描述的那样。

David Lieb：Pete，我认识不少做 Gmail 的人，他们可不落后，而且我猜他们自己可能都不用他们开发的那个功能。那怎么会成现在这样呢?到底哪里出了问题?

Pete Koomen：这我也说不准。我也认识很多 Google 的员工，他们都特别聪明。但为什么他们却发布了一个表面上几乎没人用的功能呢？我觉得部分原因在于，我们依然用旧有的软件开发思维和方法在构建这些 AI 功能，没有真正发挥出 AI 的全部潜力。

回到前面提到的两个问题。先说语气的问题:生成的草稿为什么完全不像我?原因出在哪?在幕后，这个 Gmail AI 助手在帮我起草邮件时，实际上做的是把我的用户提示和一个所谓的“系统提示词”合并在一起。系统提示词就是一段文本，向 AI 说明它是谁、职责是什么。这段提示词在每次生成草稿时都会被重复使用。而在 Gmail 这个案例里，系统提示词的内容对用户是完全隐藏的，我根本看不到，更别提修改了。不过大概可以猜出它写了些什么。

我在文章里还稍微夸张地模拟了一下它可能的内容: 你是一名乐于助人的邮件写作助手，负责代表 Gmail 用户撰写邮件。请遵循用户的指示，用正式、商务化的语气和正确的标点来撰写内容，以确保读起来让用户显得非常聪明且严肃认真。

接着，我还做了个小演示，来展示系统提示词对邮件草稿风格的影响。我们把上面假设的 Gmail 系统提示词和我的用户提示结合起来生成邮件草稿，得到的就是和刚才类似的内容。邮件看上去中规中矩，确实完成了我的要求，但听起来完全不像我写的。

David Lieb：深入来看，我们是在猜 Gmail 用的系统提示词，显然八九不离十，因为实际输出和我们猜测的基本一致。需要注意的是，我们假设的这个系统提示词非常通用，对所有用户都是一套标准。这种提示词非常“安全” ，你特意让它采用正式、商务的语气，显得用户很聪明严肃，并明确要求它不要说任何可能让这家公司的母公司难堪的话。

Tom Blomfield：对许多大公司来说，这种顾虑肯定是最重要的。谁也不想自家 AI 说出让公司难堪的话。我记得 Google曾经很早放出过一个科研类模型，但很快又撤回了，就因为它有时会乱说。我觉得当初 Google 明明站在 Transformer 技术的前沿，却被 OpenAI 后来居上，很大程度就是因为他们过于谨慎，不敢把东西放出来。

Pete Koomen：对，这可能是主要原因之一。我刚才假设的系统提示词也许还不够全面，真实的提示词里 很可能还有一大堆内容，都在强调不要让Google 难堪，以及各种必须避免的事项。

Tom Blomfield：估计提示词里还有一句:“要是你说了 Sundar 的坏话，你就死定了。”

David Lieb：最近确实发生过有些产品的系统提示词被泄露出来的情况。这成为大新闻，因为大家发现:“原 来这个 AI 助手背后的系统提示词长这样啊!”仔细一看，那些提示词非常冗长，还直接指示 AI 要避免某些问题。

Tom Blomfield：一眼就看得出，那提示词里处处都有HR团队的痕迹。

Pete Koomen：更深层次的问题在于，我们设计这些功能的方式太像过去几十年我们设计传统软件的套路了。 假设 Gmail 允许我这个用户不仅能看到系统提示词，还能自行编辑它，那情况会怎样?我可能就不会用他们那个通用的 “Gmail 邮件写作助手”提示词，而会改成这样: 你就是 Pete。你今年 43 岁，是丈夫、父亲，也是 YC 的一位合伙人。你很忙，你通信往来的人也都很忙，所以你写邮件时尽量简明扼要。”

通过编辑这个系统提示词，我其实是把我大脑里写邮件的小程序尽量完整地描述给了 Gemini 模型听。接着用我定制的系统提示词，而不是 Gmail 那个一刀切的通用提示词，再让 AI 起草同样内容的邮件，得到的草稿就变成了这样: “嗨，Gary。我女儿得了感冒，所以我今天不能来公司了。谢谢。 ”这个怎么样?听起来是不是就像我自己会写的邮件?通过修改系统提示词，我向 AI 模型解释了我平常写邮件的风 格和习惯，这样就不用每次都从头交代一遍这些要求了。

回到问题本身:为什么 Gmail 团队会选择把系统提示词藏起来、不让用户改?我认为很多 AI 应用的开发者其实还在把系统提示词当作传统代码一样对待。自从软件行业诞生以来，用户和开发者之间就一直有分工:由我开发者来构建和定义系统，代码都藏在幕后;而你用户看不到代码，只能通过界面去点击操作。

Tom Blomfield：说到底，他们还是在做“一刀切”的通用软件。

Pete Koomen：没错。一直以来，我们只能用这种放之四海而皆准的方式来开发软件。举个例子，如果你要开发一个网络银行系统或者 AB 测试软件，作为开发者，你就得和成百上千的用户交流，把他们的需求综合提炼成一套统一的功能，然后做出这么一个通用的软件。

Tom Blomfield：换句话说，就是照顾所有人、追求“最低公分母”的软件。Pete Koomen:同意。而 Gmail 的这个系统提示词，就是一个“最低公分母式”的邮件写手，它很安全，谁用都行。但结果就是，它写出的邮件没有一个是真人会那么写的。虽然这种设计不会让谁丢掉饭碗，但这样的软件也绝对不可能独霸市场。

David Lieb：你提到现在很多开发者还在用上一代的软件开发思维来使用 AI。你用了一个说法 —— “AI 无马车”。能跟我们解释一下这是什么意思吗?

Pete Koomen：“AI 无马车”指的是早期汽车的设计。最初的汽车看上去和马车几乎一模一样，只是把马换成了发动机。这样的设计问题很多，比如，传统马车的减震本来就很简陋，装上震动的发动机并高速行驶时就不行了;又比如马车车身重心较高，高速转弯时很危险。总之，发明了发动机只是造出汽车所需的一小部分而已。要真正发挥发动机的威力，还需要对“汽车”本身进行一系列重新设计。

David Lieb：科技发展中这样的例子屡见不鲜，我自己也经历过一些。互联网刚兴起时，很多第一代搜索引擎其实就是把目录照搬到了线上，本质上只是一个分类信息索引目录。现在回头看当然觉得那很傻，就像早期的 Craigslist 分类网站一样。再比如手机刚出来时，最初的许多手机应用其实基本上就是把网站套了层本地 App 的外壳，完全没有利用手机上新提供的 GPS、多点触控等能力。通常要过上几年，人们才能摸索到新技术真正的用武之处。Pete，你的意思是，现在我们对 AI 的应用还远没到那个阶段，对吗?

Pete Koomen：我认为问题最根本的一点在于，Gmail 团队当初在做那个功能时问的是:“我们要怎样把 AI 塞进 Gmail 这个应用里?”

David Lieb：也就是“我们怎么把马去掉换上发动机?”

Pete Koomen：正是如此。但问题在于，Gmail 这个应用本身是为人来工作而设计的。我认为，对我们许多人来说，AI 真正的前景在于用 AI 自动化那些重复繁琐的事务。我花在邮箱上的大量时间，其实都是在处理重复的杂务。这些事并不需要多少脑力，但以前没有技术可以代劳，所以只能我自己做。我在文章里举了一个例子，演示只用一些简单的方法，可以让邮箱自动处理哪些事情。示例如下: “这是一个电子邮箱收件箱的示例。右边是一堆收件邮件，而在这个收件箱里有一个 Agent在运行。它不是写邮件的Agent，而是一个读邮件的Agent。你能看到，我写了一段系统提示词告诉这个Agent每封邮件该做什么。这个Agent具备以下能力:它可以给收到的邮件加标签，可以把邮件归档，可以给标签加颜色，也可以起草回复邮件。这些就是这个Agent能够执行的操作。而我的指令规定了它在遇到不同邮件时要采取的动作:

如果邮件来自我妻子，就起草一封回复，并将邮件标记为“私人”。

如果邮件来自我的老板，就起草回复，并将其优先级设为 1(比我妻子的邮件低一级)。

对于来自我在 YC 的同事的邮件，就加上 “YC” 标签，并将其优先级设为 2。

如果邮件来自需要帮助的创业者(Founder)，就加上 “Founder” 标签，并将其标记为需要优先处理。

这其实就是我脑海中整理邮箱的那套规则。我只是把自己处理邮件的思路用语言描述给了 Gemini，好让它能代替我执行。

David Lieb：有意思的是，这段规则本质上就是你为这个Agent编写的一段“代码”。但如果你仔细看，它其实非常直白易懂。比如“如果是技术相关邮件就标记为 Tech，如果有人想卖我东西就把邮件归档”之类的句子。这是一个很好例证，说明大型语言模型的能力已经强大到可以让非程序员也用自然语言来“编程”这些应用。

Pete Koomen：是。我一直把这些模型看作一个超级聪明但毫无头绪的应届毕业生。他什么都能干得还不 错，但不知道该干什么。我们要做的就是教会它去完成那些我不想亲自做的工作，这正是我刚才演示的。这种“编程”方式对任何人来说都完全没有门槛，非常直观。

当我提出让用户可以自己编写系统提示词的时候，也有人提出过疑虑:“大多数人并不懂技术，他们不会写这个吧。” 这话没错，这种技能不是与生俱来的。但我自己试了几次之后发现，其实非常直观易学。本质 上，这就像先想清楚自己是怎么做决策的，然后尝试把这个过程解释给 AI 一样。而且只要你能一边观察 AI 执行，一边通过调整提示词来给它反馈，整个过程是很好上手的。

Tom Blomfield：我喜欢这个!你那篇文章不只是静态文字，你还做了这样一个小部件，让读者可以亲自去编辑系统提示词，按自己的方式调整后重新运行，用这种交互式演示来传达理念，很聪明了。

Pete Koomen：我平常就特别喜欢做这种演示。这次我觉得用这种方式来讨论这些概念非常直观。而且这再次说明了，当你用 AI 来构建东西、和模型互动时，AI 会让你感到自己无比强大。

Tom Blomfield：对了，你是怎么做出这个演示的?

Pete Koomen：我完全是凭感觉把它写出来的，有些讽刺的是，这些 AI 模型其实并不太擅长帮你从零开始写东西。我真正用到 AI 的地方，是让我描述出一个我认为能有效传达观点的演示场景，然后眼看着它一点点被实现出来。

Tom Blomfield：现在这些 AI 工具好得令人惊叹。举个例子，有次我在坐火车的一小时里，用编程助手把我的博客从 Tumblr 平台迁移成了我自己搭建的定制博客程序。写代码的 AI 助手似乎远远领先于目前所有其他通用型的 AI 助手。

Pete Koomen：我相信，当各行各业的人都能像我们程序员使用编码助手那样，在自己的领域充分利用 AI 时，我们才算真正跟上了时代。比如，将来会计师能打造属于他们的会计 AI 助手，把重复的流程全都自动化；律师也能拥有帮助他们处理繁琐事务的法律Agent。基本上，每个行业迟早都会迎来自己的 “Cursor 时刻” 或 “Windsurf 时刻”。

Tom Blomfield：那为什么像 Cursor、Windsurf 或 Cloud Code 这些编程工具，要比什么律师助手、会计助手领先那么多呢?

Pete Koomen：我觉得有两个原因。第一，这些 AI 模型在处理文本方面特别在行。所以只要我能清楚地用自然语言描述我想要什么，它们就能理解这个描述并将其转换成相应的代码。这也解释了为什么我觉得让 AI 写那封邮件草稿那么烦。因为这些 Agent并不擅长凭空从无到有地写东西，但它们擅长把指令转换成文本输出。对于代码领域来说，这点尤为有用，我只要用英语把需求说清楚，一个Agent就能为我生成实现该需求的代码，而且效果好得惊人。

第二，开发者工具本身就是为专业人士打造的强力工具。所谓开发者工具，就是允许你直接操作系统“底 层”的工具。所以开发这些工具的团队给了我们充分的权限，让Agent可以随心所欲地完成我交代的任务。他们并没有耗费大量精力去防范“千万别让用户干出什么让 Windsurf 难堪的事”之类的问题，也没有给我们戴上太多束，我可以直接和模型对话，充分发挥它的威力。相比之下，在很多其他领域，我们对待 AI 依然是小心谨慎、束手束脚的，就像给用户戴上了“儿童防护手套”，生怕他们用到模型的全部能力。我希望这种时期早点过去，不要再有开发者觉得模型输出的每句话都得他们来负责，因而战战兢兢地把 AI 的能力阉割得不堪实用。

David Lieb：你的说法很有趣。如果我们调整模式，让用户来掌控 AI (起码能接触和修改系统提示词)，那么 其后果就由用户承担，而不是由提供这个工具的公司承担。

Tom Blomfield：对，就好比 Google 提供了 Gmail 服务，但如果你写了一封布满脏话的邮件，那责任在你自己，对吧？同样，如果你把系统提示词改得跟个粗暴的混蛋似的，那也是你自己的事， 不关 Google 的事。

Pete Koomen：这其实是一种心态转变，要把 AI 当作工具真正交到用户手里，让用户为了自己的目的去使用它；而不是开发者觉得模型输出的每件事都得他们负责，于是畏首畏尾地把 AI 的能力削弱得一点用都没有。 Tom Blomfield:我赞同你以上说的所有观点，但我还有些疑问。第一个是:你认为绝大多数人有能力写出这样的系统提示词吗?

就目前来说，我觉得答案是否定的。但在不远的将来，我相信答案会变成肯定。为什么这么 说?我小时候，电脑还被看作只有极少数人才会用的“高阶”工具。而今天，使用电脑已经不再是什么了不起 的新鲜事了，我们人人每天都在用电脑。这是怎么发生的呢?就是大家逐渐摸索学会了怎么用，同时软件界面变得更友好、技术也更进步了。结果就是，使用电脑成了一件平平常常的事。

我认为提示词也会经历类似的过程，而且速度会更快。编写提示词实际上比操作当年的电脑文件管理器要容易得多，你不需要懂太多，只要能用日常语言把自己的意思解释清楚就行。我自己现在已经尝试了好几次，发现这过程非常直观。比如，先想想“我平常是怎么写邮件的”。这虽然只是个玩具式的例子，但还挺有趣，你可以写出自己的一套内部流程，然后观察 AI 照着做。如果 AI 把语气拿捏对了，那就说明你的系统提示词写对了。

Tom Blomfield：这点我同意，我认为基本上将来每个人都能做到这点。不过我不确定每个人都愿意去做， 或者有这个主动性。我们三个都是创始人，本身就喜欢摆弄这些东西。

David Lieb：其实我妈每天都用 Gmail，但你要说她会去写什么系统提示词?恐怕够呛。

Pete Koomen：说不好。我已经学会不要低估用户可以学会的东西。但我同意你们的看法：其实我自己也不太想从头开始写一个属于我的邮件写作系统提示词。虽然我希望有那个选项可以这么做，但毕竟我用了 20 年的 Gmail，我 20 年来的邮件历史都摆在那里。一个好的产品完全可以利用这些历史记录来帮我生成一段适合我的草稿提示词。

Tom Blomfield：举个人类的例子，如果你新雇了个员工或助理，你可以坐下来写满 30 页纸的说明，告诉 他你生活中每件事该怎么做，但现实里我们谁也不会这么干。我们通常会渐进式地培训。比如可以让助理翻阅你之前所有的邮件，他们多少就能学明白一些做事方式；然后你一步步指导他们处理邮件，他们起草几封邮件给你过目。等你觉得满意了，就可以告诉他们“不用再给我审核了，直接发吧”。以后如果你发现有什么不太对劲的地方，再说:“哎，这种情况下我会这样或者那样措辞。” 然后这个助理就会吸取你的反馈，更新他自己心中的“指导手册”。

David Lieb：Pete，你其实已经在 YC 这么做过了对吧?你开发了一些内部工具给财务团队和法务团队使用。看起来你们的交互方式正是 Tom 刚才描述的那样，你真的跑去问一个财务同事，“这个工作流程你是怎么做的，演示给我看看”；然后你帮他们写出一段系统提示词。他们试用后发现有些不对，再和你一起修改提示词。你说的这种来回迭代模式，就是正在推行的吗?

Tom Blomfield：是的。进一步说，现在 AI 应用开发中缺少一个工具。并不是每个人身边都有个 Pete 坐在旁边指导，但你可以有一个 AI “系统提示词编写助手”陪在身边。你对它说:“这里不对”或者“我会这样改写这句”，它就能把你的意见翻译回系统提示词，自己进行修改或自动更新。

Pete Koomen：是的。这些都是我们还未摸索清楚的新型 UI 交互的例子。可以看到，人们正在尝试不同的模式。有些基础模型实验室已经开始给他们的聊天机器人加入“记忆”功能。但我个人用下来感觉不太好，因为这种记忆功能被搞得像个黑盒，我根本看不到它内化了什么、存储了什么。我相信既然这些内容本质上都只是英语，我们就没必要把它们当黑盒对待。

Tom Blomfield：在我看来，系统提示词几乎就像一份你平时不需要去动的文档。但在极端情况下，如果某件事真的出了岔子，你可以进去调整它。不过对大多数人来说，AI 会自动生成并根据用户反馈不断自我更新他们的系统提示词，AI 会浏览你的以往工作记录来为你定制提示词，并根据你的反馈持续修改。只有在非常特殊的情况下，才需要亲自打开提示词文档改里面的某一句。我想大概五年后， 99% 的人都不会碰自己的系统提示词，但每个人的提示词都是为自己量身定制的。

Pete Koomen：有可能。这个演进过程会怎样拭目以待吧。我们在 YC 做的一些工作是用Agent来自动化 我们和同事日常要做的重复事务，让我相信，写提示词很可能会成为许多人日常工作流程的一部分。

Tom Blomfield：短期内我同意。不过在系统提示词编辑这件事上，我认为还会出现一个更高阶的抽象层。 也就是说，你其实不应该需要亲自去编辑系统提示词，而是能够通过提示或微调来完成。举例来说，“这里有张新的术语表，是我们从未见过的新术语，我会这样理解它。” 然后 AI 回应:“好的，非常感谢。” 它会把你的意思提炼成系统提示词并自动更新，而不用某个人非得翻开那 50 页的文档去改某一行。

Pete Koomen：我想我们今后大概会有一些工具，让教 AI 学习变得更加容易。我也希望开发者们别再把提示词当黑盒，能够查看这个Agent到底被指示去做什么，对我这个用户来说价值极高，而现在很多应用在这方面是完全空白的。

David Lieb：刚刚聊了很多关于提示词的话题。在你的文章里你也谈到了工具，我觉得这是一个非常重要且有趣的议题，能和我们谈谈这一点吗？

Pete Koomen：好的。如果今后系统提示词都不用开发者从零手写了，那开发者应该把精力放在哪里呢?我认为AI 给我们带来的一个愿景是，它使我们能够打造出一种软件，用户只需用自然语言就能编程，让软件按照他们的意图做任何想做的事。而这些Agent要想真正办实事，就需要能使用各种工具。回到我那个读邮件的Agent，它当时能用的工具有三个：给邮件加标签、归档邮件、起草回复。可以想象，如果再给它很多其他工具，它就会更强大，能替我处理更多繁琐事务。

实际上，我收到的很多邮件并不需要太多脑力，只是一些必须完成的杂事，比如支付账单啦、写引荐介绍、做交接等等。我不知道有多少次不得不写一封邮件，把某某人放在密送里......一遍又一遍地做这些事情实在让人抓狂。说到底，邮箱收件箱在很多方面就像我的待办清单，塞满各种生活琐事。我真正花心思去写的邮件寥寥无几，大部分都是事务性的。而有了这些工具，这个读邮件的Agent就能替我处理其中很大一部分。

Tom Blomfield：尤其是当它能把 Slack、日历、Notion、Jira、Linear 等等各种平台都串联起来的时候，威 力就更大了。现在我们 YC 当期有家初创公司叫 Den，可以说他们在做“知识型工作的 Cursor”，实质就 是给Agent提供统一接口来调用各种工具。比如你老板在 Slack 上给你发消息说:“嗨，帮我审核一下这份条款和条件。” 然后代理就会自动从 Google 文档里拉取那份条款让 AI 审阅；AI 也许接着会通过邮件把审阅意见发给你的法务团队，他们审核通过后，你再用 AI 把最终文件发布到 GitHub。所有这一切都由同一个Agent在控制、调用各处的工具，你只需要坐等结果。乔布斯曾把电脑比作“心灵的自行车”，而这感觉就像给大脑装上了火箭。

Pete Koomen：确实非常强大。我们已经在 YC 内部构建了这样理念的早期版本，我们看到 YC 的一些员工已经开始用 AI 自动化他们工作中那些容易自动化的部分。这类工具带来的区别在于:它让原本只能充当问答机器的Agent，变成了一个可以替你在现实中完成任务的助手。

Tom Blomfield：说实话，我有点讨厌如今这种聊天机器人范式。它之所以流行，只是因为这是把 LLM 基础体验带给全世界最简单的办法。毕竟在ChatGPT 之前我们就有 GPT 模型了，但 ChatGPT 把它带入了主流。但现在，每个产品似乎都只是简单地嵌入一个聊天bot，可这东西并不应该在每种场景下都这么用的。

Pete Koomen：同意。因为最初大家接触的是聊天机器人，很多开发者和用户就定势在“LLM 擅长的就是生成文本”这种认知里。我们想说的是，这些大型语言模型其实完全可以替我们自动完成工作、在现实中替 我们办事，好让我们不用事事亲力亲为，这才是它真正的前景。

Tom Blomfield：我也对这样的未来充满期待，今天的讨论非常有趣。Pete，你觉得创业者在打造自己产品时，应该如何考虑我们刚才谈到的这些理念?

Pete Koomen：这是个好问题。我认为现在是成为创业者最令人兴奋的时代之一，因为我们过去几十年来使用的几乎每一种工具，都可以借助 AI 重新思考。我相信，许多工具的AI 原生版本都会与我们习惯使用的版本大不相同。就像我刚才展示的东西，看起来就和我这辈子用惯的邮箱客户端截然不同。

Tom Blomfield：没错。所以他们不能只是简单地在现有产品里嵌入一个聊天bot了事。

Pete Koomen：与其问“我该如何把 AI 塞进这款工具里”，不如问“如果从零开始设计这款工具，怎样才能让 AI 尽可能替用户承担重复琐碎的工作，好让用户专注于真正重要的事情?” ，这才是他们应该考虑的问题。

David Lieb：好的，非常感谢你今天和我们分享这一切，Pete。

Pete Koomen：谢谢邀请!