地图:六组概念

一张地铁线路图:先看整条线路,再一站一站地坐过去。

本课的概念分成六组。第一组讲模型本身的性质。其余五组是设计给出的五个应对:诚实的预期、展示过程、让人掌控、优雅地失败和反馈回路。第七章把它们串起来,并补上收尾的原则——Design for the Unhappy Path。

怎么读每个概念

一本护照:每个人的栏目都一样,所以方便对照。

从这里开始,每个概念都有相同的几个部分:一个英文名称(记住它——这是你在文章和指南里搜索用的术语)、一幅来自日常生活的画面、一张图示,以及一张带字段的卡片:问题、思路、例子、代价、何时使用和关联。整门课的唯一一条规则:模型会出错,而设计决定这件事会变成什么。

Fallible Component — 模型哪怕出错也一样自信

一位魅力十足的专家,给每个答案都用同样笃定的语气说出来——对的和瞎编的,听起来一模一样。

语言模型产出的输出流畅而自信,无论对错。它的错误不会带着忧虑的语气,也不会打上标记。这就是会出错的部件(fallible component)——AI 产品定义性的设计难题。界面无法指望模型自己发出不确定的信号:它答对时和胡说(hallucinating)时听起来一样笃定。

于是设计必须承担起模型不会承担的东西:关于可靠性的提示、留给核查的余地、可供恢复的途径。你是在围绕一个自信而会出错的部件包裹一层用户体验。

Trust by Design — 信任由设计建立,而非模型

你信任一家好银行,不是因为柜员永不出错,而是因为有回执、有对账单、还能对一笔扣款提出申诉——这套系统赢得了人单凭一己之力赢不到的信任。

用户不会因为某个 AI 功能强大就信任它。他们信任它,是因为围绕它的体验让他们觉得安全:他们能核查它、纠正它、撤销它,并知道会发生什么。这就是 trust by design:模型提供能力;设计提供信任。

一个绝妙的模型放进草率的界面里会显得不可信;一个平庸的模型放进周到的界面里则显得可靠。信任是你所造产品的属性,而不是你所用模型的属性。

Autonomy Calibration — 让自由度与风险相匹配

你乐意让工具自动改正一个错别字,但在它发出一封法律函件之前,你想把每个字都读一遍——同一台引擎,护栏却大不相同。

你给 AI 多大的自由,应当取决于出错的代价有多高。这就是 autonomy calibration(自主权校准)。低风险、容易撤回的输出(一个建议的标签、一句草稿)可以更自动一些。高风险、无法撤回的操作(转账、删除数据、发布)则需要审核和确认。

这是 AI 产品设计中最重要的一个决定。两个方向都可能做错:自由给得太多,功能就鲁莽;给得太少,功能就胆怯得毫无用处。

AI Disclosure — 告诉用户这是 AI,而且可能出错

天气预报说“有 70% 的概率下雨”,而不是“会下雨”——先把不确定性说出来,即使预报不准,人们也依然信任它。

AI disclosure(AI 披露)是指坦率地说明某个功能由 AI 驱动,而且它的输出可能不完美。这不是道歉,也不是软弱——而是校准。知道自己拿到的是 AI 建议的用户,会恰当地去读它:有用、值得核对,但不是金科玉律。

隐瞒输出由 AI 生成,或者暗示它具有权威性,会让人过度信任,等它出错时又觉得被背叛。诚实的表述,能把一个错误的答案从一次背叛,变成一件意料之中、可以应对的事。

Draft Framing — 把输出呈现为草稿

文件上盖一个手写的“草稿”章,你读它的方式就变了——你把它当作有待改进的起点,而不是必须服从的定论。

输出周围的措辞,决定了用户会多信任它。Draft framing(草稿式表述)是指把 AI 的结果呈现为草稿、建议或起点,而不是定稿的权威答案。它邀请用户带着批判的眼光去读、去改——这正是对待一个会出错的工具应有的姿态。

“这是一份你可以修改的草稿”,比“这就是答案”带来更好的结果、更少的事故。这种表述默默而持续地起作用,让用户与模型保持正确的关系。

Under-promise, Over-deliver — 不要夸大

推销员保证某个小玩意儿什么都能做,会让你觉得被骗;而告诉你它到底擅长什么、不擅长什么的人,赢得的是长久的信任。

把 AI 功能宣传成魔法很诱人,但夸大必然带来失望:承诺与现实之间的落差,会变成用户的体验。under-promise, over-deliver(少承诺、多兑现)的原则,是把预期定得略低于模型的实际能力,让它带来惊喜。

诚实地说明它的局限——哪怕说得很醒目——建立的信任,远比第一次失败就被击碎的炒作更持久。

Citations — 标明答案背后的来源

带脚注的论文,让任何读者都能把一个论断追溯到出处——正是引用,让它显得可信,而不只是显得自信。

当模型根据检索到的信息作答时,把来源(citations)展示出来:链接到文档,引用那段话,指出论断出自哪里。引用让用户可以验证答案,而不是凭信念接受。它把模型从一个必须相信的神谕,变成一个可以核查的研究助手。

这就是 grounding(有据可依)在设计上的回报:答案在系统内部有出处还不够——用户必须看到这个出处,并且能够顺着它查下去。

Verifiability — 可验证,而不只是看似合理

好会计不会只递给你一个数字——他会给你看明细,让你能够确认,而不是去信一个自信的总数。

Verifiability(可验证性)是指在设计上让用户能够核查输出,而不只是接收它。把模型回答所依据的东西亮出来,突出它用到的具体数据,让人容易对照现实去确认。

一个可验证的答案,即使偶尔出错也值得信任,因为用户能把错的挑出来。一个无法验证的答案,即使通常是对的也很危险,因为没有办法分辨好坏。为核查而构建,那些不可避免的错误就变成可以被发现的,而不是代价高昂的。

Confidence Signals — 展示置信度与推理

一位医生说“我相当有把握,不过我们用一项检查来确认”,比用同样的把握宣布每一个诊断的医生,更能指引你。

在可能的地方,把置信信号(confidence signals)展示出来:一个置信度、推理的步骤、一个在模型不确定或证据单薄时亮起的标记。这能帮用户判断每个答案该依赖到什么程度,而不是把它们都当作同样可靠。

它不会完美。但哪怕只是一个粗略的“这条不太稳”的提示,也能大幅提升人们使用这个功能的安全性。把模型的语气所掩盖的可靠性信号交给用户,是你能做的价值最高的设计之一。

Suggest, Don't Act — 提供协助,不要擅自行动

一个好助手会起草邮件,留给你自己去发——而不是自己点下发送,事后再告诉你。

对于任何有后果的事,把 AI 设计成建议而不是行动:提出修改、起草消息、推荐选项——然后让人来决定。这让人留在回路中(human in the loop),参与那些重要的决定,于是模型的错误变成一条被拒绝的建议,而不是一个已经执行的错误。

一件事越重要、越无法撤回,模型就越该只做提议,由人来拍板。用户指挥的协助,比用户只是监督的自主性更安全。

Editable Output — 让用户能编辑,而不只是接受或拒绝

好模板让你改掉不合适的部分,而不是逼你在“完美”和“没用”之间二选一。

最好的 AI 交互,让用户能塑造输出,而不只是照单全收或整个丢掉。这就是 editable output(可编辑的输出):AI 的结果便于编辑、打磨,并且可以保留一部分。模型往往能带你完成 80%,价值就在于让人去完成最后那 20%,而不是因为一处瑕疵就把整个结果扔掉。

把输出当作可以揉捏的黏土,而不是定稿的裁决,才符合模型的真实表现:一份由人来改进的优质草稿。可编辑性把“差不多对了”从一次失败,变成一个领先的起点。

Confirm & Undo — 在任何不可逆的操作之前先确认

银行对一笔大额转账要求二次确认——在无法收回的事情之前,刻意停一下。

在用户无法撤销的任何操作之前——发送、付款、删除、发布——放一个明确的确认步骤。这与安全领域的 blast radius(爆炸半径)是同一种思路,只是体现在用户体验上:模型的错误顶多产生一条被用户拒绝的建议,绝不该是自己执行的不可逆操作。

并且尽可能配上撤销,让已经接受的操作也依然可以恢复。能够退一步,才让用户敢于放心地依靠 AI 行动,而不是提心吊胆。

Abstention — 让它能说“我不知道”

你最信任的专家,是那个说“这超出了我所知道的范围”的人,而不是信心十足地编点什么来填补沉默的人。

Abstention(弃权)是指把体验设计成允许——并且更倾向于——诚实地说一句“我不知道”或“我不确定”,而不是编造一个答案。AI 最危险的失败,是在毫无依据时信心十足地编出一个回答。让“拒答”成为一种有效而体面的结果的产品,比逼着模型总要给出点什么的产品安全得多。

把不确定性亮出来,而不是遮掩过去,不是功能的失败——而是功能在诚实地工作。一个知道自己局限的模型,加上一个尊重这些局限的设计,比一个什么都回答的赢得更多信任。

Low-confidence Routing — 把不稳的情况送上另一条路

垃圾邮件过滤器有把握时自动分拣,没把握时则标出来让你来看——不确定的情况得到处理,而不是被藏起来。

不要不管多不稳都一视同仁地对待每个输出。当模型不确定或证据薄弱时,设计一条不同的路径——这就是 low-confidence routing(低置信度分流):标记它、请求确认、转给人,或者向用户问一个澄清的问题。

不确定的情形恰恰是盲目自动化伤害最大的地方,所以它们值得有自己的处理方式,而不是和稳妥的情形带着同样的笃定一起发出去。为不稳的中间地带而设计,而不只是为 happy path(顺利路径),才让功能变得稳健。

Graceful Degradation — 降级,而不是崩溃

GPS 丢失信号时,会显示你最后已知的位置并提示“正在搜索”,而不是一片空白,或者把你领下悬崖——它失败得很柔和。

当 AI 无法完成任务时——出错、宕机、请求超出范围——体验应当优雅地降级,而不是崩坏,更糟的是产出一堆垃圾。退回到更简单的选项、一条清晰的提示、一条手动路径、一个缓存的结果。

一个失败后落入合理而诚实状态的功能,能保住用户的信任;一个失败后落入信心十足的错误答案或一个坏掉的界面的功能,则会毁掉它。像规划成功路径那样,刻意地规划失败的模式,因为对一个会出错的部件来说,失败是正常运行的一部分。

Feedback Controls — 给用户一个轻松表态的方式

每个答案旁边的一个点赞和一个点踩——用户只需轻轻一点,就能告诉你它说中了还是没说中,不花他们任何力气。

Feedback controls(反馈控件)——点赞/点踩、一个快速评分、一个举报标记——让人毫不费力地表达一条输出是好是坏。这一举两得:用户有了掌控感,觉得自己被听见了;而你获得源源不断的真实信号,知道这个功能哪里好用、哪里失灵。

一个无法被评价的功能,是你在盲飞的功能;一个简单的反应控件,是你能得到的最便宜、最丰富的反馈。去捕捉用户本来就会给出的那个反应。

Corrections as Signal — 让纠正去教系统

当你改掉手机键盘建议的那个地址,它就学会了——这次纠正不只管这一次,还会让下一次变得更好。

最丰富的反馈,是用户自己去修改输出。当有人修改一条 AI 的建议时,这次修改就是“正确”长什么样的精确信号。这就是 corrections as signal(把纠正当作信号),也叫 implicit feedback(隐式反馈)——把它捕捉下来。纠正和拒绝就是金子:它们在真实案例上,准确地告诉你模型差在哪里。

把它们喂回你的 evals(见 evals 课程),让功能可衡量地改进,让产品沿着真实用户实际遇到困难的轮廓变得更好。这次纠正,既是眼下的修复,也是日后的一课。

Feedback Loop — 线上反馈是你最好的 eval 集

最好的考题来自学生真正考过的那场考试,而不是老师想象出来的——现实写出的测试,比你写得更好。

来自真实使用的反应和纠正,是你手里最有价值的 eval 用例来源——它们就是用户实际在做的事,包括你永远想不出来的那些失败。从这些反馈中挖掘功能在哪里出问题,并把这些用例并入你的 eval 集,就闭合了反馈回路(feedback loop):线上教你该修什么,你修好它,下一个版本就更好。

一个让这个回路转起来的产品会持续改进;没有它的产品则是在猜。正是这个回路,让一个 AI 功能越来越好,而不只是存在着。

处处都是 Autonomy Calibration — 按风险叠加的多层保障

你让助手自己去办理文书手续,让它起草重要的信件交你审阅,而绝不让它在你不在场时签下合同——自主权随后果的轻重而调整。

贯穿整个产品、一次次要做的统一决定,是让 AI 自己做多少、又有多少要经过人。答案始终是 Autonomy Calibration:让它与风险相匹配。低风险、可撤回的事可以更自动一些;高风险、不可撤回的事,则要叠加上预期、核查、掌控和确认。

一个设计良好的 AI 产品,不是一律自主,也不是一律谨慎。它是逐处校准的,依据是那里出错要付出多大的代价。

Design for the Unhappy Path — 为错误的答案而设计

一位优秀的安全工程师设计汽车时,假定事故一定会发生,而不是指望它不发生——安全气囊就是为糟糕的那一天准备的,而它正是意义所在。

成熟的 AI 产品设计的标志,是围绕模型会出错来构建,而不只是围绕它会答对。这就是为不顺利的路径而设计(designing for the unhappy path)的原则。演示展示的是正确的答案;产品要经得起错误的那个。所以你要设计核查、掌控、优雅的失败、反馈回路——也就是让一次自信的错误变得可以被发现、可以被挽回的那套机制。

把顺利路径跑通,你得到的是一个演示;为不顺利的路径去设计,你得到的是一个人们真能托付真实工作的产品。

这一切如何连在一起

一支管弦乐队:每个声部各奏各的部分,但你听到的是一首乐曲。

一切都始于 Fallible Component:模型哪怕出错也一样自信。五组实践——预期、展示过程、掌控、优雅地失败、反馈——是设计给出的五个应对。Autonomy Calibration 决定某个具体环节需要每个应对多少。合在一起,就产生了 Trust by Design。而反馈回路又经由 evals 流回去,随着时间推移让模型变得更好。