对话设计师在 AI 产品质量中的隐形角色

大多数工程团队把系统提示词当作配置文件对待——需要快速迭代的技术字符串，存储在环境变量中，部署时的仪式感和修改一个超时值差不多。系统提示词有内联注释。错误提示一条也没有。能力披露就是产品经理在上线当天往 Notion 文档里打的那段话。

这正是整整一类 AI 产品故障的根源——这类问题不会出现在你的评估套件里。模型回答了问题，延迟没有问题，JSON 验证通过了。但用户在三次会话之后就停止信任这款产品，周活跃用户曲线再也没能回升。

缺失的那门学科叫对话设计。它影响输出质量的方式，大多数工程监控在架构上是盲目的。

提示词就是产品文案，无论你是否这样对待它

当你写下"你是一个有帮助的助手，请准确简洁地回答用户问题"时，你已经做出了一系列产品决策：

• 产品的角色定位是什么？（通用化。）
• 遇到歧义该怎么办？（没说——你没有定义。）
• 不知道答案时该怎么做？（未定义。）
• 这款产品的边界在哪里，哪些问题不该回答？（没有建立。）

这些遗漏并不意味着没有做出决策。模型会用某种方式填补这些空白——通常是训练默认值的混合，产生与你实际产品目标不符的行为。你写的是配置，模型执行的是你没有写的产品文案。

研究数据印证了这一点。提示词措辞、格式和词汇的变化，在结构化任务上可以产生高达 76 个百分点的准确率波动。"列出前三个选项"和"提供三条建议，按适用性排序"之间的差异不是风格问题——它改变了模型评估相关性和组织推理的方式。歧义不会产生中性输出，它会产生偏向训练分布中该表达形式最常见模式的输出。

对话设计师做了哪些工程师没做的事

对话设计作为一门正式学科早于大语言模型——它诞生于 2010 年代的语音助手、IVR 系统和聊天机器人产品设计。其核心关注点是系统与用户之间的沟通契约：系统能做什么，如何表达不确定性，如何从失败中恢复，以及出问题时如何维护用户信任。

应用到大语言模型系统时，这分解为四个具体问题域：

角色与语气校准。 系统提示词的框架确立了模型的默认语域——正式程度、词汇复杂度、措辞中的不确定性程度。一款金融规划助手如果使用和休闲创意写作工具相同的语域，会产生用户说不清楚但确实能感受到的认知失调。他们在用户研究中说产品"感觉不对"。工程师看了评估指标，什么问题都没发现。

指令层级与冲突解决。 生产功能的系统提示词会例行积累矛盾。"要简洁"和"始终提供完整上下文"同处一个提示词中。模型解决这些冲突时的行为并非随机——它受到指令顺序、措辞和隐式优先级信号的影响。对话设计师知道要明确审计这些冲突。工程师通常在用户提交 bug 报告时才发现它们。

失败与边缘案例脚本。 当模型无法完成请求时——因为超出范围、信息不可用、用户输入格式不正确——失败响应是一个产品决策，不是优雅降级。通用的失败回复（"很抱歉，我无法帮助你处理这个问题"）会损害信任。具体的、可操作的响应（"我无法查询你的账户余额，但你可以在门户的'设置 > 账户'中找到"）能维护信任，还经常提高用户最终实现目标的概率。

能力披露。 在令人印象深刻的演示之后，用户会系统性地高估 AI 系统的能力，然后在第一次失败后急剧向下修正。主动、准确的能力信号——嵌入产品的沟通模式中，而不是埋在常见问题解答里——能让预期保持校准，防止第一次意外失误后的信任崩溃。

监控盲区

具体问题在这里：工程团队衡量容易衡量的东西。Token 成本、延迟、错误率、评估通过率。这些是真实且重要的指标，但它们对对话设计影响的维度完全沉默。

你无法用 JSON 模式验证器衡量"用户对这款产品的信心微妙地降低了"。你无法在单元测试里捕获"这条错误提示让用户把模型的失败归咎于自己"。你无法在延迟仪表板上看到"这个能力披露导致用户过度信任然后过度修正"。

将对话设计与工程分开配置资源的公司，其 AI 功能采用率可测量地更高。这不是因为对话设计师有神奇的直觉——而是因为他们为不同的信号做了监控。会话深度、第一次失败后的回访率、对话修复率（用户在得到不满意的响应后重新措辞的频率）、AI 生成内容的编辑率。这些才是预测功能成为习惯还是失望的指标。

严格地对提示词语言进行 A/B 测试

用与测试 UI 文案相同的方法测试提示词变体的方法论是存在的。大多数团队不用它。

工作流分为五个阶段：

假设制定。 在更改提示词语言之前，写下一个具体的、可证伪的预测。"如果我们在拒绝响应中用'我没有关于这方面的可靠信息'替换'我不知道'，我们预期五次会话流失率会有可测量的降低。"模糊的假设（"这听起来应该更好"）产生无用的实验。

黄金数据集构建。 离线评估需要一个精心整理的数据集，包括有代表性的查询、对抗性输入和你领域特有的边缘案例。标准查询告诉你变体是否胜任。边缘案例告诉你它是否安全。对抗性输入告诉你新措辞是否创造了新的失败模式。跳过这个阶段的团队经常发现，提高了平均情况性能的提示词更改会降低尾部行为。

使用细分指标的金丝雀部署。 将一小部分流量路由到变体。关键是要分离你的指标栈：一类是自动质量分数（LLM 作为评判者的相关性、准确性）；另一类是行为指标（会话深度、回访率、重试率）；第三类是运营指标（延迟、成本）。只针对自动质量进行优化，是团队发布测量良好但感觉更糟糕的变更的方式。

统计纪律。 提示词 A/B 测试与任何实验一样，面临相同的有效性威胁：样本量不足、聚合数据中的辛普森悖论、上线后头几天的新奇效应。会话级别的单元通常是正确的随机化单元，而不是请求级别。看到混合体验的用户——部分请求是变体，部分是对照——会产生有偏差的行为数据。

推广或回滚。 如果变体在不降低质量或运营指标的情况下改善了行为指标，就逐步推广。如果行为指标改善但质量下降，提示词更改只是在转移风险，而不是消除风险。把回滚视为一等操作，而不是失败。

在实践中应用于何处

并非每个提示词都需要这样的处理。将工单路由到正确队列的分类提示词，可以针对黄金数据集测试然后收工。对话设计方法论投资回报率最高的地方，是信任成为限制因素的场合——通常是用户依赖 AI 输出做出重要决策的地方，或者产品价值依赖于多次会话持续参与的地方。

杠杆最高的触点是：

系统提示词语气和角色框架。 这是影响行为范围最广的单一决策。在确定之前测试两三个变体。对你关心的失败案例要具体——当模型不知道某件事时产品说什么？当用户的请求超出范围时说什么？明确定义这些，而不是让训练默认值来处理。

错误和兜底消息。 这是信任最脆弱的地方。当用户遭遇失败的那一刻，他们正在形成对产品可靠性的持久信念。精心制作的失败响应——承认限制、用非技术性语言解释发生了什么、给用户一个明确的下一步——将失败时刻转化为建立信任的时刻。糟糕的，或者缺席的，则不然。

能力披露。 将它们构建到产品自然的对话流程中，而不是文档里。第一次会话前的模态披露会立即被遗忘。而一个在相关查询中说"我应该提一下，我没有实时数据，所以关于当前价格，你需要直接查询"的模型，正在实践对话设计。它同时也在降低下游出现损害信任的错误的概率。

不确定性语言。 你的系统如何传达置信水平，会影响用户行为。"这可能有帮助"和"根据你告诉我的，最可能的解释是……"会产生不同的下游行动。关于 AI 系统中信任校准的研究一致表明，用户会根据他们收到的置信度信号调整行为——但前提是这些信号一致且准确。无论实际确定性如何都统一表达高置信度的系统，会训练用户走向过度信任，而不可避免的失败打击会更重。

将对话设计引入你的团队

对于大多数工程团队来说，实际问题是组织层面的，而不是技术层面的。你可能没有对话设计师，也可能无法招聘到。如果没有这个角色，应用这门学科会改变什么？

从监控开始。将会话深度和回访率添加到你的 AI 功能仪表板。添加对话修复率——用户在 AI 响应后立即跟进重新表述或澄清请求的频率有多高？高修复率表明初始响应未能满足用户的沟通需求，即使它满足了技术任务规格。

将提示词作者身份加入代码审查流程。系统提示词更改应该与 UI 文案更改经历相同的审查：评估语气一致性、失败案例覆盖率和能力准确性。这不是为了让流程变慢，而是为了捕获只有对话设计才能捕获的那类问题。

专门针对沟通失败进行内部红队会话。不是"你能让模型做它不应该做的事吗？"而是"找出一次交互，其中模型的响应虽然技术上准确，但会侵蚀用户对产品的信任。"这些会话会浮现评估套件系统性遗漏的问题。

回报是不对称的

从纯工程角度进行提示词优化的上限——更好的少样本示例、更严格的格式约束、更清晰的指令层级——是真实存在且有充分记录的。一旦你把任务规格做对了，准确率就会有边际收益递减。

从对话设计角度进行提示词优化的上限则高得多，因为它在不同的维度上运作。一个能准确完成任务但沟通糟糕的系统，无论评估数字看起来多好，都会在低参与度和低信任度上停滞不前。一个能完成任务并且沟通良好的系统会产生复利——用户回来，参与更深，带来更复杂的任务，并成为倡导者。

理解这一点的团队正在将提示词写作视为跨职能责任，在质量指标的同时为行为指标建立监控，并像对 UI 文案做实验一样对语言变体进行结构化实验。不理解这一点的团队在优化错误的东西，并纳闷为什么参与度曲线与评估曲线不匹配。

提示词就是产品文案。你的工程流程越早这样对待它，你的产品指标就越早体现出来。