AI 应用的困境在于产品设计而非模型能力。文章以 Gmail 的 Gemini 电子邮件草稿生成功能为例，指出其生成的草稿语气、风格与用户真实需求不符，且用户需花费精力编写提示词。问题根源在于 Gmail 团队未充分考虑用户个性化需求，未让用户可编辑系统提示。
在AI时代，很多人都有一个问题，AI原生应用到底长什么样？
不久前，YC合伙人Pete Koomen提出了一个很有意思的看法：当下很多AI产品的困境并不在于模型能力不行，而是应用设计不行。
原因在于，这些产品仍然基于过去的产品逻辑来设计，而没有充分考虑到用户的实际需求。
比如，传统的产品开发往往需要程序员预先设计好系统提示符，但这些早被设计好的提示词在实际应用中，却很难真正满足用户个性化的需求，甚至成为了大模型潜力释放的最大阻碍。
这就像19世纪80年代的蒸汽马车，人们只想着用发动机取代马匹作为动力驱动，却没有考虑重新设计车辆以应对更高的速度。
在这篇文章里，Pete Koomen就用了自己的亲身经历，分享了他对AI原生应用的理解。
当我用AI开发软件时，我能很快创建自己想要的东西，但很多AI应用却没有这种感觉。它们的AI功能毫无用处，只是模仿过去开发软件的方式。我认为，这种路径依赖限制了AI产品真正的价值。
为了更好地说明我的意思，我就拿Gmail的人工智能助手来举例说明
不久前，Gmail团队发布了一项新功能，允许用户使用谷歌的旗舰人工智能模型Gemini从头开始生成电子邮件草稿。这就是它的样子：
▲Gmail 的 Gemini 电子邮件草稿生成功能
在界面上，我添加了一个提示，请求我给老板写一封邮件。我们来看看 Gemini 的返回结果：
▲Gmail 的 Gemini 电子邮件草1稿生成功能回应
正如你所见，Gemini 写出了非常合理的草稿。但遗憾的是，它听起来一点也不像我真正会写的电子邮件。如果我自己写这封邮件，它应该是这样的：
▲我会写的电子邮件
语气并不是这篇邮件唯一的问题。我还花了很多精力去写提示词，甚至写提示词的字数超过了我自己写邮件的字数。
这意味着，我用Gemini写稿件，远远不如我自己写。
这很不科学。按理说，Gemini这么强大的模型，完全有能力写出一封优秀的电子邮件。但Gmail 团队却没有做到。
为了说明这一点，这里有一个AI电子邮件助手的简单演示，如果Gmail推出了这个助手，我可以节省很多时间：
▲使用OpenAI的GPT-4O-mini实现的实用电子邮件助手演示
这个演示是用AI阅读电子邮件，而不是从头开始撰写。每封电子邮件都会被分类并按优先级排序，有些会自动存档，有些则会收到自动生成的回复草稿。
助手会根据自定义的“系统提示”逐个处理电子邮件，该提示会准确解释我希望如何处理每封电子邮件。您可以通过编辑系统提示来尝试自己的标签逻辑。
这种方法显然更加强大，那么为什么Gmail团队不这样做呢？为了回答这个问题，让我们更深入地分析一下他们的设计中存在的问题。我们先从它的通用风格说起。
Gmail的AI助手生成的草稿冗长、正式得有些怪异，完全不像我的风格。
每个用过大模型写作的人都有过这种经历，以至于我们大多数人在写作时都会不自觉地采取一些策略来避免这种情况。最简单的策略就是写一些更详细的说明，引导AI朝着正确的方向发展，就像这样：
但问题在于，每次我想写新邮件的时候，我都得写类似的内容。
有一个简单的解决方案可以解决这个问题，但许多 AI 应用程序开发人员似乎都忽略了这一点：让我编写自己的“系统提示”。
从外部来看，大型语言模型其实非常简单。它们读取一串单词，即“提示”，然后开始一个接一个地预测接下来可能出现的单词，即“响应”。
这里需要注意的是，所有的输入和输出都是文本。大模型的用户界面也是文本。
OpenAI和 Anthropic等大模型厂商都用了一种方式来简化提示词编写。他们把提示分为两个部分：系统提示和用户提示。之所以这样命名是因为在许多API应用程序中，应用程序开发人员编写系统提示，而用户编写用户提示。
系统提示向模型解释了如何完成一组特定的任务，并被反复使用。用户提示则描述了需要完成的具体任务。
您可以将系统提示视为一个函数，将用户提示视为其输入，将模型的响应视为其输出：
▲使用 gpt-4o-mini 简单演示系统/用户提示关系
在我原来的例子中，用户提示是：
▲我原来的用户提示
Google对系统提示符保密，但根据输出我们可以猜出它是什么样子：
▲Gmail 的电子邮件草稿撰写系统提示（大概）
这事的问题不仅仅在于Gmail团队编写了一个糟糕的系统提示。更重要的是，我还不能修改它。
如果 Gmail 不强迫我使用他们千篇一律的系统提示，而是让我自己编写，它看起来会像这样：
▲Pete 系统提示
直观地看，你就能明白是怎么回事：当我编写自己的系统提示时，我正在教大模型按照我的方式写电子邮件。这样行得通吗？我们试试看吧。
▲根据系统提示，gpt-4o-mini 对相同的用户提示返回截然不同的响应
尝试使用（设想的）Gmail系统提示符生成草稿，然后使用上面的“Pete 系统提示符”执行相同操作。“Pete”版本会显示如下内容：
▲使用 Pete System Prompt 生成的电子邮件草稿
太完美了！太简单了！
不仅这次草稿的输出效果更好，而且由于系统提示会反复使用，以后的每一稿都会更好。不用再费劲地向Gemini解释如何像我一样写作了！
花几分钟思考一下你是如何写电子邮件的。试着写一个“你的系统提示”，看看会发生什么。如果输出看起来不对，试着想象一下你在解释中遗漏了什么，然后再试一次。重复几次，直到你觉得输出结果对了为止。
更好的办法是，尝试一些其他的用户提示。例如，看看你能不能让大模型用你的声音写这些邮件：
▲个人电子邮件用户提示
▲客户支持请求用户提示
教大模型用你的方法解决问题，并看着他们成功，这感觉很神奇。令人惊讶的是，这实际上比教人更容易，因为与人不同，大模型会即时、诚实地反馈你的解释是否足够好。如果你收到满意的电子邮件草稿，那么你的解释就足够了。如果你没有收到，那么就不够。
通过公开系统提示并使其可编辑，我们创造了一种可以产生更好结果并且实际上很有趣的产品体验。截至现在，大多数AI静态应用不会（故意）暴露其系统提示。为什么呢？
每当一项新技术发明出来，第一批基于该技术构建的工具必然会失败，因为它们往往照搬了旧有的运作方式，就像无马马车。
“无马马车”指的是早期的汽车设计，它大量借鉴了之前的马车。以下是我在维基百科上找到的一张1803年蒸汽马车设计图：
▲特雷维西克 1803 年的伦敦蒸汽马车
这种设计的缺陷在当时是无人察觉的，但事后却显而易见。
想象一下，生活在1806年，第一次乘坐这样的车。即使木制车架足够坚固，能让你到达目的地，但木制座椅和缺乏悬挂的悬挂系统也会让过程变得难以忍受。
你可能会想：“我绝对不会选择发动机而不是马。”至少在汽车发明之前，你是对的。
我怀疑我们正经历着类似的人工智能应用时代。其中许多应用就像 Gmail的Gemini集成一样，毫无用处。
最初的无马马车诞生于“旧世界思维”，其核心是用发动机取代马匹，而没有重新设计车辆以应对更高的速度。究竟是什么旧世界思维限制了这些人工智能应用呢？
现在，你想让计算机做一件事，可以有两种选择来实现它：
编程很难，所以我们大多数人都会选择第二种方案。这就是为什么我宁愿花几美元买一个现成的应用，也不愿自己开发；也是为什么大公司宁愿花数百万美元请Salesforce，也不愿自己开发 CRM。
现代软件行业建立在这样一个假设之上：我们需要开发人员充当我们与计算机之间的中间人。他们将我们的愿望转化为代码，并将其抽象到我们能够理解的简单、通用的界面背后。
分工很明确：开发人员决定软件在一般情况下的行为，用户提供输入来确定软件在特定情况下的行为。
通过将提示符拆分为系统提示词和用户提示词，我们创建了与这些旧领域完全对应的类似物。系统提示符控制LLM在一般情况下的行为，而用户提示符则是决定LLM在特定情况下行为的输入。
在这种框架下，我们很自然地会认为编写系统提示词是开发人员的工作，编写用户提示词是用户的工作。
但在Gmail的案例中，这就行不通了。AI助手应该是代表我，用我的方式来写邮件，而不是由谷歌产品经理和律师组成的委员会设计的千篇一律的声音。
在以前，我只能接受通用的产品，因为我很难去编写自己的程序。但到了AI时代，不需要通过程序员告诉计算机应该做什么，任何人都可以编写自己的系统提示词。
这就是我想说的：当AI代理代表我做事的时候，我应该被允许通过编辑系统提示来教它如何做到这一点。
这不意味着我需要自己从头开始编写自己的系统提示。Gemini应该能够使用我的电子邮件作为参考示例，为我编写草稿提示。
那么，像人工智能会计代理或人工智能法律代理这样不那么个性化的代理呢？对于软件开发人员来说，聘请专业的会计师或律师来编写通用的系统提示，不是更合理吗？
如果我是用户，这或许说得通。执行X操作的系统提示应该由X领域的专家编写，而我并非会计或法律专家。不过，我猜大多数会计师和律师也想自己编写系统提示，因为他们的专业知识是与具体情况相关的。
例如，YC的会计团队就以YC独有的方式运作。他们使用内部软件和现成软件的特定组合。他们使用YC特有的惯例，只有其他YC员工才能理解。他们管理的资金结构也是YC独有的。一个千篇一律的会计代理人对我们团队的帮助，就好比一个对YC一无所知的专业会计师：完全没用。
我工作过的每家公司，每个会计团队都是如此。这就是为什么这么多财务部门仍然使用Excel：它是一个通用工具，可以处理无数特定用例。
在大多数人工智能应用中，系统提示应该由用户编写和维护，而不是软件开发人员，甚至是开发人员聘请的领域专家。
大多数人工智能应用程序应该是代理构建器，而不是代理。
如果开发人员不写提示，他们需要做什么？
首先，他们将创建用于在特定领域运行的构建代理（例如电子邮件收件箱或总账）的 UI。
大多数人可能不想从头开始编写每个提示，而优秀的代理构建器也不会强迫他们这样做。开发人员会提供模板和提示编写代理，帮助用户创建自己的代理。
用户还需要一个界面来查看代理的工作并迭代他们的提示，类似于我上面提到的小型虚拟电子邮件代理构建器。这个界面为他们提供了一个快速的反馈循环，用于训练代理可靠地执行任务。
开发人员还将构建代理工具。
工具是代理人与外界互动的机制。我的邮件代写代理人需要一个工具来提交草稿供我审阅。它可能会使用另一个工具发送一封未经我审阅的邮件，或者搜索我的收件箱，查找某个邮箱地址之前发来的邮件，或者查看YC的创始人名录，看看邮件是否来自YC的创始人。
工具为代理提供了安全层。代理能否执行特定操作取决于其可以访问的工具。使用代码编写的工具强制执行边界比使用文本在系统提示和用户提示之间强制执行边界要容易得多。
对于我们许多人来说，人工智能的“杀手级应用”就是这个样子：教计算机做我们不喜欢做的事情，这样我们就可以把时间花在自己喜欢的事情上。
在大多数情况下，大模型已经足够好了。阻碍我们实现AI更广泛应用的，不是AI能力不行，而是应用程序设计。
就像Gmail团队打造了一辆没有马的马车，因为他们着手将人工智能添加到他们现有的电子邮件客户端中，而不是思考如果从头开始设计一个包含人工智能的电子邮件客户端会是什么样子。
他们的应用是将人工智能塞进一个为日常人工劳动设计的界面中，而不是一个为自动化日常劳动设计的界面中。
AI原生软件应该最大限度地提升用户在特定领域的影响力。AI原生电子邮件客户端应该最大限度地减少我花在电子邮件上的时间。AI原生会计软件应该最大限度地减少会计人员记账的时间。
这正是我对人工智能未来充满期待的原因。在那个世界里，我无需花时间去做那些枯燥乏味的工作，因为代理会帮我处理。我只需专注于我认为重要的事情，因为代理会处理其他所有事情。我热爱的工作也能更高效，因为代理会帮我完成。
本文由人人都是产品经理作者【乌鸦智能说】，微信公众号：【乌鸦智能说】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。