在AI时代，很多人都有一个问题，AI原生应用到底长什么样？
近期，YC公司的合伙人Pete Koomen提出了一种引人深思的观点：目前众多人工智能产品的难题并非模型本身能力不足，实则在于其应用设计的缺陷。
其原因是，这些产品在设计中仍旧沿用了以往的产品理念，并未充分对用户的真实需求进行深入思考。
传统产品开发过程中，程序员通常需提前设定系统提示，然而这些预先设定的提示在实际使用中，往往难以完全契合用户个性化的需求，有时甚至成为阻碍大模型潜力充分发挥的关键因素。
这恰似19世纪80年代的蒸汽机车，当时的人们一心只想着用引擎替代马匹来提供动力，却未曾思考过对车辆进行重新设计，以适应更快的行驶速度。
在这篇文章中，Pete Koomen借助个人实际体验，阐述了他对人工智能原生应用的认识。
一、从Gmail新AI功能说起
比起大多数AI应用，我更喜欢自己用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如何阅读电子邮件内容，而非从零开始创作邮件。在处理每一封邮件时，AI会对其进行分类，并依照重要性进行排序；部分邮件将被自动归档，而另一些则会触发自动回复草稿的生成。
助手将依照用户定制的“系统指引”逐一处理邮件，这些指引能够精确地表达出用户对每封邮件的处理意愿。用户可对系统指引进行编辑，以测试个人设计的标签规则。
这种方法明显更为强大，然而，为何Gmail团队并未采纳此法？为了解开这一疑问，我们需对他们在设计过程中所面临的问题进行深入剖析。首先，我们不妨从其整体设计风格入手。
三、人工智能斜率
Gmail的智能助手所创作的草稿过于冗长，且语气过于正式，显得颇为不自然，与我个人的写作风格大相径庭。
从事过大型模型写作的人士都曾遭遇过此类状况，因此，我们中的大多数人，在创作过程中，往往会无意识地运用一些技巧，以规避这种问题。其中，最基本的方法便是提供更为详尽的描述，以此指引AI朝着正确的路径前进，例如：
但问题在于，每次我想写新邮件的时候，我都得写类似的内容。
存在一种简便的对策能够应对这一难题，然而，众多人工智能程序的开发者似乎对此视而不见：我完全可以自行创作我的“系统提示”。
四、系统提示和用户提示
观察其外部形态，我们发现这些大型语言模型实际上结构相当简便。它们首先接收一串文字，称之为“提示”，随后便逐个预测可能出现的后续文字，即所谓的“响应”。
需特别注意，无论是输入还是输出，均以文本形式呈现。此外，大模型的用户界面同样采用文本设计。
OpenAI与Anthropic等大型模型供应商均采纳了一种方法来简化提示词的编写流程。他们将提示内容划分为两个独立的部分，即系统提示与用户提示。这种命名方式源于多数API应用程序中的惯例，其中应用开发者负责编写系统提示，而用户则负责编写用户提示。
系统向模型阐释了执行特定任务的方法，这一过程被多次采纳。用户提示则详细说明了需要执行的具体操作。
您可以把系统提示看作是一个函数，把用户输入的提示信息当作该函数的输入，而模型的回答则被视为该函数的输出。
使用 gpt-4o-mini 简单演示系统/用户提示关系
在我原来的例子中，用户提示是：
我原来的用户提示
谷歌对系统提示符的细节保密，然而，通过观察其输出，我们能够推断出其大致形态：
Gmail 的电子邮件草稿撰写系统提示（大概）
这个问题不仅因为Gmail团队设计了一个不佳的系统提示而存在，更关键的是，我无法对其进行任何修改。
若 Gmail 不强制我采纳其千篇一律的系统提示，转而允许我自行设计，那么界面可能呈现如下情形：
Pete 系统提示
一目了然，情形便昭然若揭：在撰写个人系统提示之际，我实际上是在指导大型模型依照我的指导方针来撰写电子邮件。这种方法是否可行？不妨让我们亲自试验一番。
依据系统指示，gpt-4o-mini 对于同一用户的提示信息给出了完全不同的回答。
尝试运用（假想的）Gmail系统提示符来创建草稿，随後运用位于上方的“Pete系统提示符”进行同样的操作。“Pete”版本将展示以下信息：
利用 Pete System Prompt 产生的邮件初稿
太完美了！太简单了！
这次草稿的呈现效果更为出色，加之系统提示的持续应用，未来每一份稿件都将更加完善。从此无需再向Gemini详细阐述如何模仿我的写作方式。
花上几分钟时间，回顾一下自己撰写电子邮件的过程。不妨尝试编写一条“系统提示信息”，观察其效果。若发现输出结果与预期不符，不妨思考自己在解释过程中可能遗漏了哪些关键点，并再次尝试。如此反复多次，直至你满意输出结果为止。
更优的策略是，可以尝试采用不同的用户指令。比如，你可以尝试让大型模型模仿你的语音来撰写这些电子邮件。
个人电子邮件用户提示
客户支持请求用户提示
运用你的技巧指导大型模型解决问题，目睹它们取得成功，那种体验令人称奇。令人感到意外的是，这样的过程实际上比教导人类要简单得多，因为与人类不同，大模型能够即时且真实地给出反馈，告诉你你的解释是否足够完善。若你收到了令人满意的邮件草稿，那么你的解释便是恰当的。反之，若未收到，则说明解释尚有不足之处。
借助公开系统提示功能并实现其编辑性，我们打造了一种既能带来更佳效果又充满乐趣的产品使用体验。截至目前，多数人工智能静态应用并未（有意）公开其系统提示。这究竟是什么原因呢？
五、无马马车
每当一项新技术问世，最初利用这一技术制造的工具往往难以成功，这是因为它们通常只是简单模仿了旧有运作模式，就如同没有马的马车一般。
“无马马车”这一称谓描述的是早期汽车的设计理念，这种设计广泛吸收了马车的诸多元素。我曾在维基百科上发现了一张1803年的蒸汽马车设计图，它为我们展示了那个时代的交通工具设计风貌。
特雷维西克 1803 年的伦敦蒸汽马车
这种设计的缺陷在当时是无人察觉的，但事后却显而易见。
设想一下，若是在1806年，初次乘坐此类车辆。尽管那木制的车架足够坚韧，能够将你送达目的地，然而木质的座椅以及缺乏有效悬挂的悬挂系统，却使得这段旅程变得异常艰辛。
你或许会这样想：“我绝不会选择发动机而舍弃马匹。”在汽车被发明出来之前，这样的想法无疑是正确的。
我猜想我们或许正步入一个类似的人工智能应用的新纪元。在这个时代，众多应用似乎如同Gmail中的Gemini集成一般，显得毫无实际价值。
最初的马车无需马匹驱动，源自于“旧世界”的思维方式，这种思维的核心在于用发动机来替代马匹，却并未对车辆进行重新设计以适应更快的速度。那么，究竟是什么“旧世界”的思维方式限制了这些人工智能的应用呢？
六、旧世界思维
现在，你想让计算机做一件事，可以有两种选择来实现它：
编程是一项挑战，因此我们中的大多数人都倾向于采取替代方案。正因如此，我更愿意花费几美元购买现成的应用程序，而非亲自开发；同样，大型企业也更倾向于投入数百万美元采购Salesforce，而非自行开发客户关系管理（CRM）系统。
现代软件行业的发展基于一个基本前提：我们依赖开发人员作为我们与计算机之间的桥梁。他们负责将我们的需求转化为编程语言，并将这些复杂的代码转化为我们易于理解和使用的简单、通用的界面。
职责划分清晰：开发者负责设定软件在常规条件下的运作模式，而用户则负责输入信息来定义软件在特定场景下的行为。
我们将提示符划分为系统提示和用户提示两大类，以此构建了与原有领域相对应的新版本。系统提示词负责调节LLM在常规情境下的表现，而用户提示词则影响LLM在特定场景下的行为方式。
在这种体系结构中，我们自然而然地会以为撰写系统提示词的责任落在开发者肩上，而编写用户提示词的任务则应由用户承担。
然而，在Gmail的例子中，这种方法并不适用。AI助手理应模仿我的风格来撰写邮件，而非遵循由谷歌的产品经理和律师团队共同塑造出的那种刻板语气。
过去，我只能选用现成的产品，因为我编写程序的能力有限。然而，随着AI时代的到来，人们无需依赖程序员来指导计算机操作，每个人都能自主编写系统提示词。
这就是我想要表达的观点：在AI代理为我执行任务时，我应当有权通过调整系统提示来指导它如何正确执行。
这并不表示我必须从零开始构建我的系统提示。Gemini理应能够根据我的电子邮件内容，为我生成草稿提示。
那么，对于人工智能会计代理或人工智能法律代理这类非个性化代理，软件开发人员是否更倾向于聘请专业的会计师或律师，以编写通用的系统提示呢？
若我身为用户，此观点或许成立。进行X项操作的系统提示理应由X领域的行家所撰写，然而我并非会计或法律领域的行家。然而，我推测许多会计师与律师或许都希望亲自编写系统提示，毕竟他们的专业知识是与特定情境紧密相连的。
YC的财务团队以独特的模式开展工作，他们巧妙地结合了自研软件与市售软件的特定功能。他们遵循只有内部员工才能领悟的特别规则。他们所构建的资金架构同样别具一格。若将一个对YC毫无了解的普通会计人员引入我们团队，其作用将如同一个对YC一无所知的会计师：毫无实际效用。
我在每一家任职的企业，以及每一个会计团队，都呈现出这样的特点。正因如此，众多财务部门依旧依赖Excel：该工具功能全面，能够应对各式各样的具体需求。
在人工智能的广泛应用场景里，系统提示的编写与维护任务理应由用户负责，而非由软件开发者承担，亦或是他们所聘请的特定领域内的专家。
大多数人工智能应用程序应该是代理构建器，而不是代理。
七、不写提示词，开发者需要做什么？
如果开发人员不写提示，他们需要做什么？
他们首先将着手打造适用于特定领域操作的构建代理界面，比如电子邮件收件箱或总账系统。
多数人或许不愿每次都从头开始编写各个提示，而且出色的代理构建工具也不会强制他们这么做。开发者们会提供模板以及编写提示的指导，以协助用户自行构建个性化的代理。
用户亟需一个界面以监控代理的运作并对其提示进行优化，此界面与我所提及的简易电子邮件代理构建器相仿。该界面为用户打造了一个便捷的反馈机制，有助于训练代理更加可靠地完成各项任务。
开发人员还将构建代理工具。
工具充当了代理人与外部世界交流的媒介。我的邮件代写助手需要一种工具来上传草稿供我审查。该工具可能还会利用另一款工具发送未经我审查的邮件，亦或是在我的收件箱中搜寻特定邮箱地址之前发送的邮件，亦或是查阅YC创始人名单，以确认邮件是否由YC的创始人所发。
代理服务借助工具获得了安全保障。代理能否执行特定任务，关键在于它能够使用哪些工具。通过代码编写的工具，在强制设定系统提示与用户提示之间的边界时，相较于使用文本方式，其难度大大降低。
八、AI原生应用的期待
对于众多人而言，人工智能的“杀手级应用”呈现如下特征：它能让计算机执行我们不愿亲自去做的任务，从而让我们得以将精力投入到个人感兴趣的活动之中。
通常情况下，大型模型的表现已经相当出色。然而，制约我们让AI在更广泛领域得到应用的，并非AI自身的能力不足，而是应用程序的开发设计存在不足。
Gmail团队仿佛是创造了一辆无需马匹拉动的马车，他们致力于将人工智能技术融入现有的电子邮件服务中，而非重新构思一个从零开始、完全集成了人工智能功能的电子邮件平台。
他们的使用目的在于将人工智能技术嵌入一个专为日常人工操作量身打造的界面，而非那些专为自动化日常劳动而设计的界面。
AI原生软件需尽可能增强用户在特定领域的实际作用。AI原生电子邮件应用需尽可能降低我在处理邮件上所耗费的时间。AI原生财务软件则需尽可能缩短会计人员记录账目所需的时间。
这正是我对人工智能未来抱有极大期待的根本所在。在那个理想化的未来，我将无需耗费精力在那些单调重复的任务上，因为智能代理将为我分担这些工作。我能够将精力集中在那些我认为至关重要的任务上，其余的一切都将由代理来妥善处理。我的热爱事业也因此能够以更高的效率进行，得益于代理的协助。
