那位通过反复试验摸清你 Prompt 的高级用户

此刻,你的产品里有一位用户,体验远好于中位数用户。不是因为他付得更多,不是因为他在不同的订阅层,也不是因为他被分到了某个特殊的实验组。他通过耐心地试探,发现这个 AI 功能只要换种方式提问,就会给出漂亮的回答。他知道哪些动词能触发结构化输出。他知道一个词的追问会得到精简版本,一整句话则会得到展开版本。他知道某些话题如果不包装成假设性问题,助手就会戒备起来。这一切,你的网站上没有一处写过。他是逆向工程出来的。

有意思的不是这种用户存在,而是这种用户现在成了你的产品文档。你的 AI 功能跟用户之间签了一份契约——一份没公开的契约,完全编码在系统 prompt 里——而了解这份契约的唯一方式就是反复试验。只有一小部分用户有耐心去做这些试验。其余人拿到的是一个更糟糕的产品。

这不是个边缘问题。近期大型消费级 AI 产品的使用数据显示,高级用户——大约占账户总数的 10% 到 20%——产出了总 prompt 的 50% 到 70%,而且他们的消息明显更长、更结构化。只有极少数对话会给 AI 设定角色或附带上下文。双峰分布是真实存在的,而用户体验分叉发生在 prompt 这一层,不是功能这一层。

系统 Prompt 是一个隐藏的 API

系统 prompt 是一份规范文档。它定义了模型关注什么、忽略什么、采用什么语气、考虑哪些工具、对哪些边缘情况拒答、输出成什么形状。在传统产品里,这种规范会出现在帮助中心、新手引导、tooltip、教学视频里。在 AI 产品里,它住在一串用户永远看不到的字符串里。

这跟在没有任何文档的情况下发布一个 HTTP API、指望开发者从错误信息里逆推出接口,在结构上是一回事。我们绝不会接受一个面向开发者的产品这么干。但我们对终端用户却接受了,因为自然语言界面给人一种"不需要文档"的错觉——反正用户想打什么就打什么,模型自己会搞明白。

只是模型并不会搞明白,至少不可靠。系统 prompt 有它的偏好。它期待某种特定的措辞框架。它对什么算"完整请求"、什么会触发追问、什么会拿到长回答、什么会拿到一句话回答,都有些软性启发式规则。这些都是用散文形式编码下来的真实产品决策,会对用户体验产生可观察的下游影响。把它们叫做"隐式的"并不会让它们变得没那么真实。只意味着用户得花更多力气才能发现它们。

一个用户随便输入一个模糊请求、拿到一个平庸答案,这不是用户失败。是产品藏起了那份本可以解锁好答案的契约,从而失败地服务了用户。有耐心的用户找到了契约。没耐心的用户得出"这个产品也就那样"的结论,转头用别的去了。

聚合满意度掩盖了两类截然不同的人群

这里就是危险的地方,对做这个功能的团队来说。聚合的满意度分数是把两群体验截然不同的用户平均出来的一个数字。高级用户很愉快,他们在打五星好评、跟朋友推荐。中位数用户很迷茫,他们不会留下愤怒评价——他们只会安静地流失,或者继续低强度地用,永远没发现产品到底能做什么。

当你给系统 prompt 上线一个修改,高级用户会立刻注意到,因为他们的心智模型精确到能察觉漂移。中位数用户什么都察觉不到,因为他们的心智模型本来就模糊得不足以登记这种变化。你的 A/B 测试读出来是平均值的一点小波动。实际情况是,你刚刚为一群已经记住了旧契约的人重写了契约。

调研数据从宏观层面印证了这一点。最近的职场 AI 研究里,大约 86% 的用户说 AI 替他们省了时间,但只有 65% 的人对 AI 在工作中呈现的方式表示满意。这道缝隙——效用很真实,满意度却只是中等——就是交互问题的标志。能力是有的。通往能力的路径才是坏掉的那一部分。

聚合是一种"合成谬误"。它告诉你产品没问题。其实是有问题的。对一部分人来说很优秀,对另一部分人来说很挫败,而正是那群挫败的人最值得你去学习,因为他们还没被锁定。

隐藏说明书的伦理代价

这里还有一个公平性的故事,光看数字很容易跳过。能成为高级用户的人不是随机分布的。他们是有时间做实验的人,是第一次失败后还有信心继续戳一戳的人,是因为本职工作或日常阅读对 LLM 已有心智模型的人。那些拿到一个平庸答案就放弃的人,绝大多数是在其他任务之间挤时间试这个工具的人。

一个把最佳路径藏在迭代试探背后的产品,是一个把价值门槛设在"闲暇 + 先验专业知识"上的产品。这不是大多数 AI 产品宣称要服务的那种多元、可达的用户群。隐藏的 prompt 是漏斗里一种安静的偏见。

对公司来说,这种安排也很脆弱。逆向出来的说明书住在论坛、Discord 群、还有"巧妙 prompt"的截图里。你不愿写的文档,社区替你写了。这能撑到系统 prompt 改动那一刻为止。然后社区文档失效,那群本来摸透了你产品的用户反而变成了最迷茫的人——因为他们记住的契约被你悄悄废了。

把契约显式地呈现出来,而不是藏起来

办法不是公开字面意义上的系统 prompt。那不是重点,而且有充分理由不公开。办法是把契约中真正影响用户体验的那些部分,呈现在用户做决策的界面上。

模式并不奇特。它们就是成熟软件产品对任何复杂功能都会用的那些可供性:

• 输入配方(Input recipes):当用户打开一个新的 prompt 输入框时,展示两三个调好的具体起手 prompt。不要那种泛泛的"总结一下这段内容"——要的是跟功能真正甜区对齐的那种,就像一本好的食谱给你的是整道菜的做法,而不只是一份配料表。
• 输入中的引导 UI:当用户输入的内容太单薄时,以"补充"而非"纠正"的姿态浮出温和建议("加一个目标"、"指定受众"、"贴上文档")。识别比回忆更轻,这样一个犹豫的用户可以从菜单里挑,而不必从零编造。
• 结构化输入 chip:对那少数真正重要的维度——语气、长度、格式、受众——提供 chip 或开关。这把最有影响力的 prompt 变量从自由文本里拽出来,放在用户看得见、改得动、不必重新打字的地方。它也给团队留出了一个稳定接口,可以在不破坏用户预期的前提下,在背后演进 prompt。
• 结果侧控件:模型回答之后,展示一些用来微调输出的控件——更短、更正式、加点示例——这样用户就不必从头重写 prompt 重来一遍。
• 一个可见的"如何提问"页面:不是完整的系统 prompt,而是用大白话描述这个功能擅长什么、不擅长什么、什么样的输入有效、用户可以期待什么。这就是高级用户本来会替你写、要是你不拦着的话——的那一页文档。

每一种都是把隐藏契约的一部分拽到明面上的方式。团队依然保有对 prompt 的控制权。用户拿到了一条更短的、从意图到结果的路径。

表达力足以发挥作用的 Prompt,就值得被写进文档

更深一层的原则是:任何丰富到足以让你的产品产生差异化的系统 prompt,都丰富到值得给一套面向用户的脚手架。如果 prompt 简单到"想打什么就打什么"真的足以作为引导,那它没有给你贡献什么,下个季度某个竞争对手会用更好的 prompt 把你比下去。如果 prompt 在干真正的活——消歧意图、强制语气、校准啰嗦程度、路由到工具——那它就是一项功能,而功能值得 UI。

团队常犯的错误是把 prompt 当成后台基础设施,而不是产品表面的一部分。Prompt 决定了用户拿到什么。从定义上讲,这就让它成为你交付给用户的东西的一部分,哪怕它一个像素都不可见。把它当成不可见的,只意味着你产品可见的那部分被压缩成了一个文本框,而文本框是当下这个行业里最通用、最无差别的界面。每个竞争对手都有同一个文本框。

差异化在契约里。如果你让契约对中位数用户也变得可发现,你就压缩了高级用户体验和中位数用户体验之间的差距。你缩短了新用户的 time-to-value。你也不再依赖一小撮自我筛选出来的用户去做"把产品教给产品自己"的工作。

给你的团队一份实用的小审计

花一小时,看三个在你这个功能上参与度处于 50 百分位的真实用户的会话。不是 95 百分位,也不是 5 百分位,就是中间那群。读他们打了什么。读他们拿到了什么。注意哪些地方,只要在输入上做一个小小的改动——补一段缺失的上下文、指定一种没说的格式、收窄一个太宽的范围——回应就会明显更好。

然后逐一问自己:这个落差,从当前 UI 里能发现得到吗?还是说用户必须事先就知道 prompt 的偏好才能走到那里?每一个需要先验知识才能填上的落差,都是 prompt 已经变成了一个中位数用户看不到的隐藏 API 的地方。

数一数。这个数字,就是你的产品当前外包给最有耐心的那批用户的"文档债"。一次一个 chip、一道配方、一行行内建议地把它还掉。每天发 200 条消息的高级用户依旧会是高级用户。中位数用户则会悄无声息地开始,过上好得多的一天。