如何设计更好的 AI 应用
摘要
本文基于 Y Combinator 合伙人 Pete Kooman（Optimizely 创始人）在 The Breakdown 节目中的分享，深入探讨了当前 AI 应用设计中的核心问题：开发者正在用旧有的软件开发思维来构建 AI 功能，导致产品体验令人沮丧。以 Gmail 的 AI 邮件起草功能为例，Pete 指出其系统提示词 (System Prompt) 对用户不可见、不可编辑，且采用"一刀切"的通用设计，产出的邮件既不符合用户语气，又无法真正节省时间。文章提出了"AI 无马马车" (AI Horseless Carriage) 的概念——正如早期汽车设计只是把发动机塞进马车框架，当前许多 AI 应用也只是把大语言模型 (LLM) 塞进传统软件界面，而没有重新思考整体架构。Pete 通过现场演示展示了可编辑系统提示词的威力：用户可以用自然语言定义 AI 的行为方式，使其自动完成邮件分类、标记、起草等重复性工作。文章进一步讨论了工具 (Tools) 和 MCP 服务器对 Agent 能力的关键作用，并展望了每个职业都将迎来属于自己的"Cursor 时刻"——当会计师、律师等专业人士能够像开发者使用 Cursor 一样，用自然语言构建专属 Agent 自动化工作流程时，AI 才真正兑现其承诺。
正文
两种截然不同的 AI 体验
Pete 分享了他在日常使用 AI 时的两种截然不同的体验。一方面，当他使用 Cursor 和 Windsurf 这类编码工具 (Coding Agent) 来构建软件时，AI 让他感到拥有无限创造力——脑海中想象的任何东西都能借助这些工具变为现实。另一方面，当他使用那些将 AI 集成进现有应用的体验时，却感到 AI 反而增加了工作量，比亲手完成还费事。
这种巨大落差促使 Pete 写了一篇引发广泛讨论的文章，核心观点是：当前的 AI 应用开发者正在用错误的思维方式来构建产品。
Gmail AI 起草功能的问题
Pete 以 Gmail 的 AI 邮件起草功能作为反面案例。该功能由 Gmail 团队将 Gemini 模型集成到邮件界面实现，用户可以输入指令，让 AI 生成邮件草稿。Pete 输入的指令是："告诉老板 Gary 我女儿今早得了流感，今天没法来办公室。"
Gemini 模型本身非常强大，但生成的邮件却是这样的："亲爱的 Gary，我写信通知您，我女儿今早得了流感。因此，我今天无法来办公室。感谢理解。此致敬礼，Pete。"——这封邮件听起来完全不像 Pete 本人写的，更像账号被盗或遭遇钓鱼攻击后的产物。
Pete 指出了两个核心问题：第一，邮件语气完全不像用户本人；第二，用户输入的提示词 (Prompt) 与最终草稿长度相当，根本没节省任何时间。理想的体验应该是：告诉 AI"我女儿病了，帮我处理今天的日程"，AI 便会查阅日历、确认每个会议、用恰当的语气给每位联系人发邮件。当前的 Gemini 模型已经具备这种能力，但产品并未这样构建。
系统提示词：问题的根源
为什么 Gmail 的 AI 功能会这样？Pete 深入分析了系统提示词 (System Prompt) 的作用机制。当用户请求 Gmail 起草邮件时，系统会将用户的提示词与一个系统提示词合并后发送给 AI 模型。系统提示词定义了 AI 的身份和任务，且每次调用都会复用。
Gmail 的系统提示词对用户不可见，更不可编辑。但可以推测其内容大致为："你是一个有用的邮件撰写助手，负责为 Gmail 用户代写邮件。遵循用户指令，使用正式商务语气，使用正确标点，让用户显得聪明而严肃。"
这个系统提示词的问题在于：它是通用的，对所有用户一视同仁；它过于保守，明确要求使用商务语气、显得聪明严肃；它还很可能包含大量避免让 Google 陷入尴尬的额外指令——当你看到这些被泄露的系统提示词时，能明显看到 HR 团队的印记。
可编辑系统提示词的力量
Pete 做了一个关键演示：如果 Gmail 允许用户查看并编辑系统提示词会怎样？他将自己版本的系统提示词改为："你是 Pete，43 岁，丈夫、父亲、YC 合伙人。你和所有通信对象都很忙，所以你尽量让邮件尽可能简短。"
这只是将 Pete 脑中写邮件的内在逻辑用自然语言解释给 Gemini。使用相同的用户提示词，生成的邮件变成了："Hi Gary，我女儿得了流感，今天来不了了。谢谢。"——这才是一封 Pete 真正会写的邮件。
通过编辑系统提示词，Pete 可以一次性向 AI 解释自己写邮件的一般风格，而不必每次重复说明。
AI 无马马车
Pete 用"无马马车" (Horseless Carriage) 的历史类比来解释当前的问题。早期汽车设计就是简单地把发动机装进马车框架，但这种设计存在诸多问题：马车悬挂系统无法应对高速运转的发动机震动；重心过高导致高速转弯困难。发明发动机只是制造真正有用的汽车的一小部分，只有重新设计整个车辆才能充分发挥引擎的潜力。
这一现象在技术史上反复出现：互联网早期的搜索引擎就是数字化的黄页目录；移动互联网早期的 App 就是套着原生壳的网站，没有利用 GPS、多点触控等新技术。而当前的 AI 应用也在重复同样的错误。
Gmail 团队的设计思路是"如何把 AI 塞进 Gmail 应用"——这等同于"如何用发动机替换马"。但 Gmail 是为人类手动操作设计的应用，AI 的真正承诺是自动化重复性劳动。
邮件阅读 Agent 演示
Pete 展示了一个更激进的方案——邮件阅读 Agent (Email Reading Agent)。这个 Agent 可以对每封邮件执行操作：打标签、归档、设置标签颜色、撰写草稿。系统提示词用自然语言描述了处理规则：来自妻子的邮件起草回复并标记为"个人"；来自老板的邮件起草回复并标记为优先级一；来自 YC 同事的邮件标记为"YC"并设为优先级二；来自需要帮助的创始人的邮件打上"创始人"标签；推销邮件直接归档。
Pete 将 LLM 比喻为一个刚毕业的聪明大学生——什么都能做好，但完全不知道该做什么。缺失的关键一步就是让用户能够教会它做那些自己不想做的重复工作，而这一切完全可以用自然语言实现，不需要编程技能。
为什么编码 Agent 远超其他领域 Agent
为什么 Cursor、Windsurf、Claude Code 在编程领域远超法律 Agent 或会计 Agent？Pete 认为有两个原因：
第一，AI 模型在处理文本方面极为出色。如果用户能用自然语言精确描述需求，模型就能将描述转化为代码——这恰好是编程领域的核心工作方式。但对于写邮件这类"从零创作"的任务，Agent 反而不那么擅长，因为它们更适合处理指令而非原创内容。
第二，开发者工具是"强力工具" (Power Tools)，允许用户直达底层。Cursor 和 Windsurf 让用户完全掌控 Agent 的行为，不会因为担心"输出内容令公司尴尬"而限制模型能力。而其他领域的产品仍用"呵护式"心态，不让用户使用模型的全部能力。
人人都将拥有自己的 Cursor 时刻
Pete 认为当每个职业都能像开发者使用 Cursor 一样获得 AI 赋能时，AI 才算真正兑现承诺：会计师构建会计 Agent 自动化重复工作流，律师构建法律 Agent 处理重复性法律事务。他"氛围编码" (Vibe Coded) 了自己文章中的所有演示——只描述想要的效果，然后看着代码在眼前出现，这种体验令人惊叹。
关于普通用户是否能够编写系统提示词，Pete 认为答案是肯定的。写提示词比操作文件管理系统简单得多，只需要能用自然语言解释自己的思维过程即可。但他也承认，大多数人不应该也不需要从零编写系统提示词——理想的产品应该能利用用户的历史数据自动生成定制化的系统提示词，就像雇佣新助手时，助手会通过阅读你过去的邮件来学习你的风格，然后在互动中不断改进。
工具：让 Agent 真正有用
仅靠系统提示词还不够，Agent 还需要工具 (Tools) 才能做有用的事。在邮件阅读 Agent 的例子中，工具有：打标签、归档、写草稿。但可以想象更多工具让它更强大——处理账单、做介绍和交接、在密送中添加联系人等。邮件收件箱本质上是待办事项列表，大部分邮件是事务性的。
Pete 提到了 YC 当期的一家公司 Den，它正在构建"知识工作的 Cursor"——将不同的 MCP 服务器 (Model Context Protocol Server) 串联起来。MCP 本质上是 Agent 调用工具的方式。例如，老板在 Slack 上发消息要求审阅条款，Agent 可以从 Google Docs 拉取文档、审阅后通过邮件发给法律团队、最终在 GitHub 上发布——所有操作由一个 Agent 通过调用不同工具完成。
正如乔布斯将软件形容为"心灵的自行车" (Bicycle for the Mind)，Pete 认为 Agent 加工具的感觉更像"心灵的火箭飞船" (Rocket Ship for the Mind)。YC 内部已经开始使用早期版本，员工已经在自动化部分工作。
超越聊天机器人范式
Pete 对当前普遍存在的聊天机器人 (Chatbot) 范式深恶痛绝。ChatGPT 将 LLM 带入主流，但现在每个产品都在嵌入聊天 Agent，这几乎不是正确的使用方式。聊天机器人让开发者和用户都锚定在"LLM 擅长产出文本"的认知上，但真正的主张应该是：LLM 能够代替我们自动化工作、在现实世界中完成任务。
给创始人的建议
Pete 总结道，这是做创始人最激动人心的时代之一，因为过去几十年使用的几乎所有工具都可以用 AI 从头重新设计。AI 原生版本的工具将与现有版本截然不同——他展示的邮件 Agent 与传统邮件客户端完全不同。创始人不应问"如何把 AI 插入我的工具"，而应问"如何从零设计这个工具，尽可能将重复工作从用户身上卸载，让他们专注于真正重要的事"。