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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

监控盲区

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

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

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

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

加载中…