如何让 AI 的用户体验（UX）成为你的护城河 [译]

原文：How to Make AI UX Your Moat

设计优秀的 AI 产品，超越“只是 LLM 封装”：让 AI 更加随处可见，更加实用，然后更加强大。

来自 swyx：很高兴欢迎 Anshul 回到 Latent Space，他也是我们首位二次做客的作者！他的第一篇文章曾在 Latent Space 上获得早期的热烈反响，此后他依然在深入思考 AI UX。Codeium 目前在 VSCode 插件市场 拥有 17 万次安装量，并保持着 五星好评。

我们的 AI Engineer Summit 在第一周就收到了超过 3000 份申请！我们无法邀请所有人到场，但仍可填写邮箱来获取直播链接和其他活动信息。感谢大家的支持！

来自 Anshul：这是我在 Latent Space 发表的第二篇客座文章，承接我之前的《打造“Copilot for X”究竟需要什么？》 一文。写那篇文章的时候，我希望它能成为一个三部曲的开篇，基于我所在团队在开发 Codeium 过程中的经验教训，来解答在生产环境中部署 LLM 时的三个核心问题，顺序分别是：

  1. 如何开启一个 LLM 产品？

  2. 如何让你的 LLM 产品脱颖而出？

  3. 如何通过 LLM 产品赚钱？

然而，六个月前我们发表那篇文章时，Codeium 虽然成功完成了产品的初步启动，却没有显著差异化，更没有产生营收。时至今日，后面两点我们也都做到了，所以我和 Shawn 觉得是时候回顾总结。希望你喜欢这第二篇！

当后世回顾生成式 AI 的时代，他们很可能（理所当然地）会将 ChatGPT 视为其中一个转折点。从各种迹象来看，OpenAI 似乎挖到了金矿——有一段时间，我的推特上全是“天哪，这个模型还能做到这些！你必须要尝试的 7 大用法🧵”之类的刷屏内容。人们都在讨论 OpenAI 的模型有多好，比赛随之打响。

如今，聊天式 AI 功能无处不在：搜索引擎、Excel、电子商务，甚至多邻国（Duolingo）的那只小鸟也加入了，还有很多都是基于 OpenAI 的 API。OpenAI 曾有过技术壁垒……可现在似乎也消失了？因为开源社区的想象力也被点燃了，快速的开源进展让许多人（比如谷歌）开始相信“模型无法成为护城河”，哪怕你是 OpenAI。

但关键是——模型从来都不是真正的护城河。

与 ChatGPT 相近的 Davinci 其实在 ChatGPT 发布前近一年就通过 API 对外开放了。在科技行业，一年是非常漫长的，可竟没有人做出一个类似 ChatGPT 的产品。ChatGPT 的“护城河”并不是它的模型，而是它的 用户体验（UX）1。

UX 作为护城河

ChatGPT 带来了两大 UX 进步：

  • 文本框输入 + 流式输出（streaming out）：由于 GPT-3 和 GPT-4 体量很大，每次前向传播只能输出一个 token（一般只包含少量文字），在纯技术层面，流式输出（边生成边展示）的方式本身就优于一次性生成全部再展示（API 默认方式）。对于文本 Token 来说，流式输出能模拟阅读或聆听的过程。ChatGPT 的界面非常直观，用户可以更加自然地获取底层模型的强大能力。

  • 抽象化管理对话状态：比 UI 改进更有价值的是，用户再也不需要在新请求中手动拼接之前的问答内容，ChatGPT 会自动保留上下文，让后续的提问可以自然地引用先前的信息。这才是真正聊天式（“chat”）名字的由来。

ChatGPT 的成功不是因为它的模型，而是因为它的 UX。

如果不信，可以听听 Sam Altman 的说法。根据一次据说是内部的讨论，Sam Altman 表示 ChatGPT 的插件（Plugins）并没有真正火起来，因为人们想要的是把 ChatGPT 嵌入到自己的应用里，而不是在 ChatGPT 里加载外部应用。也就是说，人们真正渴望的是 ChatGPT 的用户体验，而不是它的模型。

那么下一个问题（实际并不需要回答）：聊天机器人是 LLM 的最终形态吗？

ChatGPT 的出现是一大 UX 飞跃，但绝对不会是最后一步。为了充分发挥 LLM 的威力，我们需要不断地重塑产品体验，挑战既有的交互模式。如今市面上每天都有无数新 AI 产品出现，我们相信未来能够存活下来的产品，不仅需要顶级的模型，还需要最佳的产品体验来让这种“魔力”更加直观与自然。

对于目前许多团队忽视 UX 我们并不想苛责。生成式 AI 新奇又激动人心，我们自己也经常被它的能力震撼。当然，创作者和开发者都迫不及待想把这些“令人惊叹”的功能赶紧发出来！如果你知道“文本输入、文本输出”的对话式 UX 已经被大众所接受，直接做个同样的东西就可以快速上线。相反，想要创理想的 UX，通常需要大量工程和设计投入，让它能够无缝嵌入用户的工作流和预期之中。

那如何改进 UX 呢？

每一次对 UX 的改进，都意味着让应用而非用户承担更多本该用户手动完成的工作，并且这种转移需要让用户觉得顺理成章。回看 ChatGPT 的 UX 改进，从 API 到简单 UI 的变化，以及自动管理上下文状态，都符合这一标准。

那么展望未来，很多提示（prompt）可以拆分为三个部分：

  • Command（指令）：与具体任务相关的内容

  • Constraints（约束）：与用户相关的内容2

  • Context（上下文）：与当前场景相关的内容

（示例见一张写有“牛奶、鸡蛋、青椒、面粉、橄榄、微辣沙司和蓝莓”的冰箱物品清单，然后让 AI 输出一份能用不粘锅和搅拌机制作，且采用公制单位的菜谱。）

在现在的大多数情形下，用户需要把这三部分都写清楚。那么如何让应用接管更多工作量？

关键是必须让用户觉得逻辑上通顺、没有“违和感”。以下是一些思路：

  • Command（指令）：让用户能够创建任务模板，并支持搜索或复用这些模板。

  • Constraints（约束）：在应用内建立用户设置，自动带入到提示中。

  • Context（上下文）：自动收集相关数据（例如，对冰箱拍照并通过计算机视觉获取内容）。

大多数人都能理解这一点。Langchain 本质上是一个“f-string”库，用以更便捷地将不同信息拼接到 Prompt 中，一旦你构建好了针对某个应用的逻辑，就可以更轻松地收集相关上下文并填充 Prompt。但我要再次强调——这类改进一定要让用户感到自然，同时也不要削弱 LLM 的能力。用户之所以喜欢 ChatGPT 的界面，正是因为他们可以清楚地看到输入和输出的文本，并且可以完全自定义。如果你的 UX 让用户对输入内容产生误解，或者过度地限制了与模型交互的方式，那就称不上是真正的改进了。

引入“三个 P”

当然，让 AI 更“直观”地被使用是个好目标，但一句“让用户使用 AI 更直观”毕竟太笼统了，不足以构成一套思考 UX 的体系，也不足以指导如何构建护城河。

我们提出了一个涵盖三个阶段的框架，可以用来思考如何让 AI “直观”地融入产品。它们往往是前后衔接、循序渐进的，而且技术实现也会越来越复杂，护城河也会越挖越深，但并没有绝对的明确界限：

  1. 使用 UX 让 AI 更普及（Present）

    • 产品 差异化：你的产品因拥有 AI 而优于其他竞品

  2. 使用 UX 让 AI 更实用（Practical）

    • 体验 差异化：你的产品体验因更容易使用 AI 而优于其他竞品

  3. 使用 UX 让 AI 更强大（Powerful）

    • 效用 差异化：你的产品因让用户从 AI 获得更多价值 而优于其他竞品

下面让我们具体讨论一下这三个阶段3。

第一步：Presence（让 AI 更“随处可见”）

UX 的首要目标就是尽可能让用户触手可及、随时能用到 AI，也就是让它更随处可见（ubiquitous）。ChatGPT 将调用 GPT 的方式从 API 转变为一个对话式的文本框，就完成了这一目标。如果你的应用中 AI 的出现频率和便利性比竞品更高，那么 AI 就能够成为真正的产品差异化和护城河。如今绝大多数 LLM 产品还停留在这个阶段。

这一步主要解决“功能层面”的用户体验，例如对一个编程工具来说，可能就是灰色文字的代码自动补全，或按 Tab 键接收；对一个搜索工具而言，可能就是能让用户选择要搜索的内容范围等。

代码自动补全的 UX：灰色斜体显示建议，用户可用快捷键接受或查看备用建议。

代码搜索的 UX：包含搜索框、侧边面板可以显示历史搜索、搜索结果，并能高亮显示代码片段等。

第二步：Practicality（让 AI 更实用）

在 AI 已经能被用户便利地访问的基础上，下一阶段的 UX 改进是让用户使用它更轻松、更顺畅，也就是让 AI 变得更实用（practical）。ChatGPT 自动管理对话上下文就是一个典型示例——当然用户可以手动把之前的问答再次拷贝到 Prompt 里，但那显然很笨重，应用端自己去管理上下文显然更优。

看看我们在使用 LLM 时常见的一些小烦恼：

  • 我们想在新场景下重复之前做过的同样任务，但不记得上次是怎么准确写 Prompt 的。

  • 我们得到的结果还不错，但其中某些细节格式不对（例如单位），必须要么再重新加条件让它重跑（结果还不一定一样），要么手动改。

  • 我们为了获得对应的上下文，需要先做很多人工“预处理”或输入，导致最终看上去似乎没比自己写省多少功夫。

还记得我们提出的那三条“让应用替代用户手动输入”的思路吗？

  1. Command（指令）：提供可搜索的常用任务模板

  2. Constraints（约束）：应用里建立用户设置，自动带入到 Prompt 中

  3. Context（上下文）：自动收集相关数据（例如对冰箱拍照识别内容）

刚好对应了上面的三种小烦恼！这也正是让 AI 更实用的具体做法。这会带来体验层面的差异化，因为大家的目标或任务其实都差不多，但如果用你的工具能更轻松地拿到想要的结果，而且不会被格式或上下文的细节折磨，用户自然会感知到这种好处，你也就获得了一层护城河。

当前，“实用性”正是许多 LLM 应用在“创新前沿”阶段不断探索的方向，但同时也要警惕做出逻辑怪异的设计或过度限制模型能力。还有很多工作要做，才能让 AI 更自然地融入用户的工作流之中。

第三步：Power（让 AI 更强大）

这是 UX 改进的最终阶段，也是最难实现，但可能为你带来最深的护城河。

在一定程度上，人类和机器学习模型有点像——碰到新事物时，我们会“探索”各种可能性，一旦发现了自己喜欢的模式，就会开始频繁使用。

  • 搬到一个新城市，会先尝试各种餐厅，直到找到自己心仪的馆子就会常去。

  • 玩新游戏，先尝试不同角色或策略，找到适合自己的就会反复使用。

  • 用新 AI 工具，也会先试着输入各种不同的指令，等找到几个屡试不爽的模板，就会一直用下去。

LLM 非常强大，我们依然没完全摸透它们的全部能力。如果能通过 UX 引导用户更好地“探索”，就能让用户在主观体验中觉得“AI 变得更强大了”。哪怕模型本身并没变，但对某个用户来说，你的产品因为让他们更高效地挖掘模型潜力，而与竞品拉开了差距，这就是深厚的护城河。

之所以说这是最后一个阶段，是因为它实现难度最高（往往也需要大量后端工程），而且用户最初未必会立刻意识到这类功能的价值。比方说，如果一个产品连“随处可见”都做不到，或者缺少最基本的易用性功能，那么用户会立刻察觉并离开。所以在 LLM 产业尚未成熟、大家还在“基础 UX”层面竞争的阶段，“让 AI 更强大”的 UX 需求通常会被放在次要位置。除非你有意识地进行这方面的投入。

我们稍后会用一个具体案例来展示。

题外话：音乐领域的 UX 护城河

目前 LLM 产品尚未完全经历以上所有阶段，但我们可以从一个更成熟的产品类别来看 UX 的演变——比如音乐应用（Spotify 等）。

如果你想做一款音乐应用，至少需要让用户能把歌曲加入播放列表并播放，还能暂停、重播或跳过歌曲，也要能查看自己的歌单。这些就“让音乐随处可见”的基础 UX。你让用户能轻松组织并播放音乐。

然后你会发现，为了让体验更加实用，你还需要做更多 UX 设计。Spotify 有“随机播放”功能，让用户不用手动调整播放顺序；可以把一个播放列表直接嵌进另一个列表中，以方便合并歌单；还可以自动根据用户已有曲库生成各种情绪歌单。这些功能如今几乎是音乐应用的标配，少了哪个都会直接落后。

不过 Spotify 等公司已经发展了很长时间，也有了更多精力去探索如何让用户“听歌这件事”变得更强大。就像 AI 有无数潜力等待发掘，音乐世界里也有数不清的新歌等着用户去发现。

想要让音乐应用更强大，就得想办法把用户和他们潜在喜欢的新音乐联系起来。Spotify 在这方面的 UX 设计相当丰富：可以让用户主动搜索并订阅他人创建的公共歌单（比如“new r&b music”），可以看好友在听什么，也有 AI 算法自动生成的“每周探索”列表等等。

每一阶段都更费力，但同时也会带来更深的护城河。反观 AI，还处于类似“iPod 而非 Spotify”的时代，依旧处在“让 AI 随处可见，再加一点实用功能差异化”的早期阶段。但毫无疑问，AI 的潜力还有很长的路要走。

LLM 应用中的 UX 分阶段实践

我们在 Codeium 致力于为软件开发者打造全球最先进的生成式 AI 工具包（可听第 #2 期播客 了解更多）。类似 Davinci 和 ChatGPT 的故事，也在我们的领域里上演过：Salesforce Codegen 是一个开源的代码生成 LLM，一年前就开源了。从理论上说，任何人都能据此做一个类似 GitHub Copilot 的工具，确实也出现了很多尝试。

但为什么只有我们 Codeium 能基于 Codegen 获得数十万用户？这是一个不断运用这三大 UX 阶段的过程。

没错，我们最终还是从 Codegen 转向了别的模型，因为我们不想等开源项目的步伐。然而我们也清楚，开源社区在 Starcoder 等代码模型上迟早会赶上。可和 Codegen 的故事一样，新竞争对手很难轻易凭借开源模型就做出相当的产品，因为模型不是护城河，我们深知构建 UX 护城河有多难。

为了更直观地说明，我们以“重构代码（refactoring）”这一普遍但令人生畏的场景为例，看看我们如何运用这三个阶段。

第一步：Presence —— 在产品中加入 AI

最原始的方法是，你可以把要重构的函数粘贴到 ChatGPT，然后写一句 Prompt：

“请把下面这个函数重构成 React Typescript，并使用强类型的 props：<函数代码>”

大概率能成功。最朴素的 UX 就是在 IDE 里嵌入一个简单的对话框，把“文本输入、文本输出”带到编程环境里，而不是让用户来回切换到 ChatGPT。市面上这类插件已经很多（例1，例2，例3）。

第二步：Practicality —— 改进用户体验

那要如何继续摆脱“文本输入、文本输出”的基本模式？怎么让这个任务的 UX 更易用呢？举个例子，我们可以自动把用户高亮选中的代码一起发给 LLM，这样一来，在输入框里你就只需要打“请把下列函数重构成 React Typescript 并使用强类型 props”就行了，省去了额外的复制粘贴和格式化操作。

虽然这是进步，但可能对 LLM 来说仍不足以理解“重构”究竟意味着什么。也许你发现自己试了很多次 Prompt，才找到更有效的写法：

“你是一名软件开发者。接下来会给你一个函数作为上下文，你需要根据给定的指令和限制，对这个函数进行重写，并返回重写后的版本。要保证重写后的函数易于被其他开发者理解，并加上注释说明主要逻辑：<约束条件> <函数代码>”

让用户每次都手动敲这段 Prompt 显然是不可接受的。一个更实用的 UX，就是在用户高亮代码后提供一个“Refactor Code（重构代码）”的按钮，自动附上那段代码，再拼接上这段“固定提示”：

但现在又会有两个新问题：

  1. 用户可能选中了一段不完整的代码，这样就没有办法“重构”。为了进一步提升实用性，可以用语法解析来自动识别哪些才是可以“重构”的函数，并只在这些函数上面显示“Refactor Code”按钮（CodeLens）。这样用户就不用手动选中那部分了。

  2. 约束条件（constraints）该如何让用户输入？也许我们可以让用户先点击“Refactor Code”，再弹出 VSCode 的输入框来让他们填：“请重构成 React TS”、“请填补 TODO”、“请添加注释”等等。我们甚至可以让“约束”变成可选，或根据上下文和过去的操作来自动推断用户想干什么。

这样就把“重构”这件事的输入流程完全变了。用户不用再手动敲任何通用描述，也不用把要重构的代码复制到 Prompt 里，更不需要再添加额外约束，都可以通过一两次点击或简短文本填写搞定。

那么输出呢？还要用流式输出一大段文本，然后再手动复制吗？我们其实知道用户重构的具体位置在哪里，所以可以自动通过 IDE 的“diff”视图将改动直接贴到原来的位置中，并可用颜色高亮显示修改之处，免得用户还要自己去对比新旧代码有何不同。

第三步：Power —— 提升效用

那如何让用户在使用过程中感到“AI 更强大”呢？事实上，我们已经在做这件事了，只是之前没 explicitly 点出来。

当用户在 VSCode 的输入框中添加“重构”约束时，我们也会给出一些提示，比如“自动填补 TODO”、“添加调试语句”、“优化性能”等。原本用户并不会想到还能这样用“重构代码”的流程，但我们在界面上列出来，他们就知道能这么干。这就是利用 UX 让用户去发现 AI 还可以做什么。 目前这只是一个静态列表，但完全可以更进一步，让系统根据实际代码上下文生成更有针对性的建议，或者在用户写代码时出现工具提示，引导他们尝试各种新功能。

以下是整个流程的可视化示例。我们对模型或传给模型的文本并没有任何改动，只是单纯地做了更好的 UX：

可以想象，这里面还有无穷无尽的可能。UX 才是真正的护城河。

结论

乍看之下，UI/UX 离那些硬核的 LLM 技术研发似乎很远，但我们坚信，只有极致的模型和极佳的产品/UX 结合在一起，才能真正获得用户的青睐和留存。

如果你读了开头那段的话，可能注意到我主要谈了第二个关键问题“如何让你的 LLM 产品脱颖而出”，而没有详细说第三个问题“如何通过 LLM 产品赚钱”。相信我，这一点其实也有明确的思路，但请期待我的下一篇文章吧……

Codeium 宣传小角

最后再提一下我们自己：Codeium，主打现代化的生成式 AI 编程体验。一开始我们做了一个免费、能和 GitHub Copilot 相媲美的自动补全工具，但我们深知自动补全只是 AI 助手的冰山一角（而且也并不适合所有任务）。因此，我们后续又上线了基于自然语言的、可作用于整个代码仓库的语义搜索（利用本地向量检索），以及“内置常见工作流”功能，比如重构、写文档、解释代码等，背后也采用类似 ChatGPT 的大模型。我们希望在吸纳越多开发者的反馈下，不断打磨产品和 UX，欢迎你来 codeium.com 亲自体验一下！

如果你所在的公司也想用 AI 工具，可以让他们了解 Codeium 企业版。除了得到上面说的全部强大 UX，还能享受最顶级的安全策略、面向企业代码库的模型微调、更完善的用户分析面板等等。你可以获得一个真正贴合企业场景的“完美 AI 对 pair programmer”，而不必在安全和法律层面做出任何让步。

Footnotes

  1. 是的，ChatGPT 用的是 GPT-3.5，而不是 Davinci，两者同时发布，因此多少还是有一些模型层面的改进（尤其是 RLHF 方面）。但你读完这篇文章就会明白，ChatGPT 的 UX 改进对其爆发式增长的贡献才是最大的。 ↩

  2. “Constraints” 其实可以分得更细，比如“你是一名……（角色）”、“给……（对象/受众）写”、“只能使用……（格式）”等。但归根结底，这些都属于用户喜好或需求，因此为了不复杂化，我统称它们为 “Constraints（约束）”。 ↩

  3. 如果你熟悉市场营销（Marketing）领域，会发现这里的 C（Command、Constraints、Context）和 P（Present、Practical、Powerful）有些像经典营销理论的“4C”和“4P”，但它们其实是完全不同的概念。只不过很多时候，UX 是最直接的市场推广方式——无需外部宣传，用户一用就能“感受到”你的产品优势。 ↩

See all posts