# 为一个有时会出错的模型做设计 关于 AI 产品设计的速成课——在一个自信、流畅、却有时会出错的模型之上,搭建用户体验。19 个概念——Fallible Component、Autonomy Calibration、Draft Framing、Citations、Confidence Signals、Suggest Don't Act、Confirm & Undo、Abstention、Graceful Degradation、Feedback Loop 等——每个都有英文名称、一张图示、一幅朴素的画面和一张带例子的卡片。结尾附一页速查表。核心思想:模型天生就会犯错,所以赢得用户信任的是设计,而不是模型。 - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 分钟阅读 - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/zh/learn/ai-product-design-express --- ## 1. 为一个会出错的部件做设计 整门学问的起点,是接受模型本来的样子:聪明、有用,却以一种特定的方式不可靠。假装并非如此的设计,会让用户栽跟头。 ### 地图:六组概念 > 一张地铁线路图:先看整条线路,再一站一站地坐过去。 本课的概念分成六组。第一组讲模型本身的性质。其余五组是设计给出的五个应对:**诚实的预期**、**展示过程**、**让人掌控**、**优雅地失败**和**反馈回路**。第七章把它们串起来,并补上收尾的原则——**Design for the Unhappy Path**。 _Diagram: 六组概念——第 1–6 章依次讲它们。第 7 章把它们连起来。_ ### 怎么读每个概念 > 一本护照:每个人的栏目都一样,所以方便对照。 从这里开始,每个概念都有相同的几个部分:一个**英文名称**(记住它——这是你在文章和指南里搜索用的术语)、一幅来自日常生活的画面、一张**图示**,以及一张带字段的**卡片**:_问题_、_思路_、_例子_、_代价_、*何时使用*和*关联*。整门课的唯一一条规则:**模型会出错,而设计决定这件事会变成什么**。 ### Fallible Component — 模型哪怕出错也一样自信 > 一位魅力十足的专家,给每个答案都用同样笃定的语气说出来——对的和瞎编的,听起来一模一样。 语言模型产出的输出流畅而自信,无论对错。它的错误不会带着忧虑的语气,也不会打上标记。这就是**会出错的部件**(fallible component)——AI 产品定义性的设计难题。界面无法指望模型自己发出不确定的信号:它答对时和**胡说**(hallucinating)时听起来一样笃定。 于是*设计*必须承担起模型不会承担的东西:关于可靠性的提示、留给核查的余地、可供恢复的途径。你是在围绕一个自信而会出错的部件包裹一层用户体验。 _Diagram: 正确的答案和胡说的答案听起来一样笃定。只有设计这一层能帮人把它们区分开。_ #### Fallible Component (自信却会出错) - **是什么:** 一个答对时和瞎编时听起来一样笃定的模型。 - **为什么重要:** 界面无法指望模型自己标出它的怀疑。 - **例子:** 一个助手信心十足地引用了一条根本不存在的法律条文——语气和引用真条文时一模一样。 - **陷阱:** 如果设计忽略这一点,错误就会作为事实送到用户面前。 - **关联:** 整门课由此展开:**Trust by Design**、**Verifiability**、**Abstention**。 ### Trust by Design — 信任由设计建立,而非模型 > 你信任一家好银行,不是因为柜员永不出错,而是因为有回执、有对账单、还能对一笔扣款提出申诉——这套系统赢得了人单凭一己之力赢不到的信任。 用户不会因为某个 AI 功能强大就信任它。他们信任它,是因为围绕它的体验让他们觉得安全:他们能核查它、纠正它、撤销它,并知道会发生什么。这就是 **trust by design**:模型提供能力;设计提供信任。 一个绝妙的模型放进草率的界面里会显得不可信;一个平庸的模型放进周到的界面里则显得可靠。信任是你所造产品的属性,而不是你所用模型的属性。 _Diagram: 模型带来能力,设计带来信任。两者合在一起,才是一个可以依靠的产品。_ #### Trust by Design (信任是产品的属性) - **是什么:** 信任是整个产品的属性,而不是模型能力的属性。 - **如何运作:** 用户能核查、纠正、撤销,并且知道会发生什么。 - **例子:** 银行:信任靠的是回执、对账单和申诉的权利——而不是一个永不出错的柜员。 - **陷阱:** 一个强大的模型放进草率的界面里,依然显得不可信。 - **关联:** 由课程里的每一组共同构成:预期、核查、掌控、失败、反馈。 ### Autonomy Calibration — 让自由度与风险相匹配 > 你乐意让工具自动改正一个错别字,但在它发出一封法律函件之前,你想把每个字都读一遍——同一台引擎,护栏却大不相同。 你给 AI 多大的自由,应当取决于出错的代价有多高。这就是 **autonomy calibration**(自主权校准)。低风险、容易撤回的输出(一个建议的标签、一句草稿)可以更自动一些。高风险、无法撤回的操作(转账、删除数据、发布)则需要审核和确认。 这是 AI 产品设计中最重要的一个决定。两个方向都可能做错:自由给得太多,功能就鲁莽;给得太少,功能就胆怯得毫无用处。 _Diagram: 一把风险的标尺:出错的代价越高、越无法撤回,自主权就越少,控制就越多。_ #### Autonomy Calibration (自主权与风险相匹配) - **问题:** 对所有操作给同样的自由:要么有风险,要么没用。 - **思路:** 让自主权随出错的代价和操作的可撤回程度而调整。 - **例子:** 错别字——自己改;邮件——起草后交人审阅;付款——只有确认后才执行。 - **代价:** 你得为每一个操作单独判断风险。 - **何时使用:** 始终——每个 AI 功能都要做这个决定。 - **关联:** 决定哪里需要 **Suggest, Don't Act** 和 **Confirm & Undo**。 > **框架性的问题:** “当这个模型自信地出错时——它一定会——我的设计能接住它,还是把错误当作事实原样递给用户?” > 模型哪怕出错也一样自信,所以设计必须承担起它不会承担的东西:可靠性的提示、留给核查的余地、可供恢复的途径。信任由产品建立,并与风险相匹配。 ## 2. 设定诚实的预期 AI 带来的大量失望,其实是预期不匹配。在用户栽跟头之前,诚实地告诉他们面对的是什么——这是你能买到的最便宜的信任。 ### AI Disclosure — 告诉用户这是 AI,而且可能出错 > 天气预报说“有 70% 的概率下雨”,而不是“会下雨”——先把不确定性说出来,即使预报不准,人们也依然信任它。 **AI disclosure**(AI 披露)是指坦率地说明某个功能由 AI 驱动,而且它的输出可能不完美。这不是道歉,也不是软弱——而是校准。知道自己拿到的是 AI 建议的用户,会恰当地去读它:有用、值得核对,但不是金科玉律。 隐瞒输出由 AI 生成,或者暗示它具有权威性,会让人过度信任,等它出错时又觉得被背叛。诚实的表述,能把一个错误的答案从一次背叛,变成一件意料之中、可以应对的事。 _Diagram: 左:答案看起来很权威,所以出错就像背叛。右:一个“AI 生成,可能有误”的标签,让出错变成意料之中。_ #### AI Disclosure (说明这是 AI) - **问题:** 用户把 AI 的答案当作权威,出错时觉得被骗。 - **思路:** 清楚地标明:这是 AI 做的,可能不完美。 - **例子:** 答案上方有一个“AI 生成 · 可能有误”的徽标。 - **代价:** 几乎没有——界面上多一行字。 - **何时使用:** 凡是用户能看到模型输出的地方。 - **关联:** 与 **Draft Framing** 一起,让用户对模型保持正确的姿态。 ### Draft Framing — 把输出呈现为草稿 > 文件上盖一个手写的“草稿”章,你读它的方式就变了——你把它当作有待改进的起点,而不是必须服从的定论。 输出周围的措辞,决定了用户会多信任它。**Draft framing**(草稿式表述)是指把 AI 的结果呈现为**草稿、建议或起点**,而不是定稿的权威答案。它邀请用户带着批判的眼光去读、去改——这正是对待一个会出错的工具应有的姿态。 “这是一份你可以修改的草稿”,比“这就是答案”带来更好的结果、更少的事故。这种表述默默而持续地起作用,让用户与模型保持正确的关系。 _Diagram: 同一个模型,同一段文字。“这就是答案”——用户照办。“这是一份草稿”——用户核对并修改。_ #### Draft Framing (草稿,而非裁决) - **问题:** 用户不加核对就接受“定稿的答案”。 - **思路:** 把输出呈现为可编辑的草稿或建议。 - **例子:** 用“起草回复”按钮代替“回复”;文本在编辑器中打开。 - **代价:** 用户得多走一步——阅读并接受。 - **何时使用:** 用于文本、决策,以及用户事后要为之负责的任何事。 - **关联:** 自然通向 **Editable Output** 和 **Suggest, Don't Act**。 ### Under-promise, Over-deliver — 不要夸大 > 推销员保证某个小玩意儿什么都能做,会让你觉得被骗;而告诉你它到底擅长什么、不擅长什么的人,赢得的是长久的信任。 把 AI 功能宣传成魔法很诱人,但夸大必然带来失望:承诺与现实之间的落差,会变成用户的体验。**under-promise, over-deliver**(少承诺、多兑现)的原则,是把预期定得略低于模型的实际能力,让它带来惊喜。 诚实地说明它的局限——哪怕说得很醒目——建立的信任,远比第一次失败就被击碎的炒作更持久。 _Diagram: 左:承诺高于现实,落差变成失望。右:承诺低于现实,现实带来惊喜。_ #### Under-promise, Over-deliver (不要夸大) - **问题:** “这是魔法”式的宣传——第一次失败就击碎信任。 - **思路:** 承诺的比模型能做的少一点;诚实地说出它的局限。 - **例子:** “帮你起草邮件”,而不是“替你写出完美的邮件”。 - **代价:** 推介时,这个功能听起来更谦虚。 - **何时使用:** 在引导页、落地页、提示语里——凡是设定预期的地方。 - **关联:** 诚实表述的一部分,与 **AI Disclosure** 相伴。 > **关于预期的问题:** “我的表述是否诚实地告诉用户这是什么——一份需要核对的 AI 草稿——还是暗示了模型根本撑不起的权威?” > 大多数 AI 带来的失望,都是预期不匹配。说明这是 AI、可能出错,把输出表述为草稿而非裁决,并且少承诺——诚实的表述是最便宜的信任。 ## 3. 展示过程 无法核查的答案,就无法信任。让用户看到输出从何而来,就把黑箱式的断言变成了可以验证的东西——而可验证性是信任的基础。 ### Citations — 标明答案背后的来源 > 带脚注的论文,让任何读者都能把一个论断追溯到出处——正是引用,让它显得可信,而不只是显得自信。 当模型根据检索到的信息作答时,**把来源(citations)展示出来**:链接到文档,引用那段话,指出论断出自哪里。引用让用户可以验证答案,而不是凭信念接受。它把模型从一个必须相信的神谕,变成一个可以核查的研究助手。 这就是 **grounding**(有据可依)在设计上的回报:答案在系统内部有出处还不够——用户必须*看到*这个出处,并且能够顺着它查下去。 _Diagram: 答案中的每个论断,都链接到用户可以打开的来源。_ #### Citations (来源标注) - **问题:** 答案只能凭信念接受——没有任何东西可以用来核对。 - **思路:** 把论断与文档关联起来,并展示这些链接。 - **例子:** “退款需要 5 个工作日 [1]”,其中 [1] 会打开政策中对应的那一页。 - **代价:** 你需要一个知道每个片段来源的系统(RAG)。 - **何时使用:** 当答案基于文档、知识库或搜索构建时。 - **关联:** **Verifiability** 的主要工具;依赖 RAG 课程里的 grounding。 ### Verifiability — 可验证,而不只是看似合理 > 好会计不会只递给你一个数字——他会给你看明细,让你能够确认,而不是去信一个自信的总数。 **Verifiability**(可验证性)是指在设计上让用户能够*核查*输出,而不只是接收它。把模型回答所依据的东西亮出来,突出它用到的具体数据,让人容易对照现实去确认。 一个可验证的答案,即使偶尔出错也值得信任,因为用户能把错的挑出来。一个无法验证的答案,即使通常是对的也很危险,因为没有办法分辨好坏。为核查而构建,那些不可避免的错误就变成可以被发现的,而不是代价高昂的。 _Diagram: 可验证的错误答案会被发现。无法验证的错误答案看起来和正确的一样笃定——并且造成伤害。_ #### Verifiability (可核查的答案) - **是什么:** 用户能自己对照现实确认答案。 - **如何运作:** 展示源数据,突出答案所依据的内容。 - **例子:** 会计给你看明细,而不只是总数;AI 把它读取金额的那些发票字段高亮出来。 - **陷阱:** 看似合理 ≠ 可验证:一个流畅却没有依据的答案,即使碰巧对了也很危险。 - **关联:** 由 **Citations** 和 **Confidence Signals** 构成;是 **Trust by Design** 的基础。 ### Confidence Signals — 展示置信度与推理 > 一位医生说“我相当有把握,不过我们用一项检查来确认”,比用同样的把握宣布每一个诊断的医生,更能指引你。 在可能的地方,把**置信信号**(confidence signals)展示出来:一个置信度、推理的步骤、一个在模型不确定或证据单薄时亮起的标记。这能帮用户判断每个答案该依赖到什么程度,而不是把它们都当作同样可靠。 它不会完美。但哪怕只是一个粗略的“这条不太稳”的提示,也能大幅提升人们使用这个功能的安全性。把模型的语气所掩盖的可靠性信号交给用户,是你能做的价值最高的设计之一。 _Diagram: 每个提取出的字段都有自己的置信度和来源。不太稳的字段被标了出来——值得核对。_ #### Confidence Signals (可靠性提示) - **问题:** 每个答案听起来都一样可靠——用户不知道该核对哪里。 - **思路:** 展示置信度、推理过程,或一个“证据薄弱”的标记。 - **例子:** 解析一张发票:总额标为“高”,税号标为“低——请核对”。 - **代价:** 置信度估计不精确;粗略的信号也胜过没有。 - **何时使用:** 当可靠程度不同的答案混在同一个流里时。 - **关联:** 同一个信号驱动 **Low-confidence Routing**;支撑 **Verifiability**。 > **关于可验证性的问题:** “用户真的能核查这个答案吗——看到它的来源,对照现实去确认——还是被要求干脆相信一个自信的断言?” > 无法核查的答案,就无法信任。标明来源,让输出可验证,并展示置信度——可验证性把不可避免的错误答案,从隐藏的风险变成可以被发现的问题。 ## 4. 让人始终掌控 让一个会出错的模型待着最安全的地方,是副驾驶座。把设计做成让用户始终掌握主动——批准、编辑、撤销——才能让强大的 AI 安全地上线。 ### Suggest, Don't Act — 提供协助,不要擅自行动 > 一个好助手会起草邮件,留给你自己去发——而不是自己点下发送,事后再告诉你。 对于任何有后果的事,把 AI 设计成**建议而不是行动**:提出修改、起草消息、推荐选项——然后让人来决定。这让**人留在回路中**(human in the loop),参与那些重要的决定,于是模型的错误变成一条被拒绝的建议,而不是一个已经执行的错误。 一件事越重要、越无法撤回,模型就越该只做提议,由人来拍板。用户指挥的协助,比用户只是监督的自主性更安全。 _Diagram: 模型建议,人来决定:接受或拒绝。“模型 → 行动”的直通路径被封死了。_ #### Suggest, Don't Act (human-in-the-loop(人在回路中)) - **问题:** 模型自己执行操作——它的错误立刻变成现实。 - **思路:** 模型只做提议;决定权和扳机都在人手里。 - **例子:** AI 起草一封给客户的回复;客服读过之后点下“发送”。 - **代价:** 比全自动慢;人要花时间审阅。 - **何时使用:** 用于任何有后果或无法撤回的事(见 **Autonomy Calibration**)。 - **关联:** 与 **Editable Output**(怎么接受)和 **Confirm & Undo**(怎么保证安全)并列。 ### Editable Output — 让用户能编辑,而不只是接受或拒绝 > 好模板让你改掉不合适的部分,而不是逼你在“完美”和“没用”之间二选一。 最好的 AI 交互,让用户能**塑造**输出,而不只是照单全收或整个丢掉。这就是 **editable output**(可编辑的输出):AI 的结果便于编辑、打磨,并且可以保留一部分。模型往往能带你完成 80%,价值就在于让人去完成最后那 20%,而不是因为一处瑕疵就把整个结果扔掉。 把输出当作可以揉捏的黏土,而不是定稿的裁决,才符合模型的真实表现:一份由人来改进的优质草稿。可编辑性把“差不多对了”从一次失败,变成一个领先的起点。 _Diagram: 有了编辑:80% 模型 + 20% 人 = 完成。没有它,一处瑕疵就让整份草稿进了垃圾桶。_ #### Editable Output (塑造它,而不只是接受) - **问题:** 只有接受 / 拒绝的选择:一个差不多对的答案被整个扔掉。 - **思路:** 把结果在编辑器中打开;允许修改和保留一部分。 - **例子:** 生成的邮件以文本形式打开:改一句话,发送。 - **代价:** 界面更复杂:需要编辑器、部分接受。 - **何时使用:** 当模型通常“差不多对”时——文本、代码、表格。 - **关联:** 延续 **Draft Framing**;每一次修改都会喂给 **Corrections as Signal**。 ### Confirm & Undo — 在任何不可逆的操作之前先确认 > 银行对一笔大额转账要求二次确认——在无法收回的事情之前,刻意停一下。 在用户无法撤销的任何操作之前——发送、付款、删除、发布——放一个明确的**确认步骤**。这与安全领域的 **blast radius**(爆炸半径)是同一种思路,只是体现在用户体验上:模型的错误顶多产生一条被用户拒绝的建议,绝不该是自己执行的不可逆操作。 并且尽可能配上**撤销**,让已经接受的操作也依然可以恢复。能够退一步,才让用户敢于放心地依靠 AI 行动,而不是提心吊胆。 _Diagram: AI 提议,人确认,执行之后仍有一段可撤销的时间窗口。_ #### Confirm & Undo (事前停一下,事后退一步) - **问题:** 模型的错误变成了一个无法收回的操作。 - **思路:** 在不可逆的操作之前明确确认 + 尽可能在事后提供撤销。 - **例子:** “向 Acme 转账 5000 美元?”→“确认”;之后还有 30 秒可以“撤销”。 - **代价:** 多一次点击;频繁的确认会让人养成不读就点的习惯。 - **何时使用:** 在涉及钱、删除、发布、发送之前。 - **关联:** **Autonomy Calibration** 最严格的一端;**Suggest, Don't Act** 的安全网。 > **关于掌控的问题:** “如果模型在这件事上出了错,用户能否在造成伤害之前接住它——通过批准、编辑或撤销——还是这个错误就这么落到了他们头上?” > 让人始终掌控:模型建议,人来决定;输出可以编辑,而不是要么全收要么全丢;任何不可逆的事情都需要确认,最好还能撤销。 ## 5. 优雅地失败 一个会出错的部件终究会失败,所以它怎么失败,是一个设计决定,而不是边缘情况。优雅地失败——承认局限而不是编造——正是值得信赖的产品与危险的产品之间的分界。 ### Abstention — 让它能说“我不知道” > 你最信任的专家,是那个说“这超出了我所知道的范围”的人,而不是信心十足地编点什么来填补沉默的人。 **Abstention**(弃权)是指把体验设计成允许——并且更倾向于——诚实地说一句“我不知道”或“我不确定”,而不是编造一个答案。AI 最危险的失败,是在毫无依据时信心十足地编出一个回答。让“拒答”成为一种有效而体面的结果的产品,比逼着模型总要给出点什么的产品安全得多。 把不确定性亮出来,而不是遮掩过去,不是功能的失败——而是功能在诚实地工作。一个知道自己局限的模型,加上一个尊重这些局限的设计,比一个什么都回答的赢得更多信任。 _Diagram: 依据充分——给出答案。没有依据——诚实地说“我不知道”。危险的路径:强迫模型总是作答。_ #### Abstention (“我不知道”) - **问题:** 被迫总要作答的模型会编造内容。 - **思路:** 让“我不知道”成为产品中一个有效而体面的结果。 - **例子:** 客服机器人:“我在我们的文档里没找到这个——要我转给专员吗?” - **代价:** 有些问题得不到回答——这没关系。 - **何时使用:** 只要模型可能没有依据(缺数据、超出范围)。 - **关联:** **Low-confidence Routing** 的温和版本;**Fallible Component** 的解药。 ### Low-confidence Routing — 把不稳的情况送上另一条路 > 垃圾邮件过滤器有把握时自动分拣,没把握时则标出来让你来看——不确定的情况得到处理,而不是被藏起来。 不要不管多不稳都一视同仁地对待每个输出。当模型不确定或证据薄弱时,设计一条不同的路径——这就是 **low-confidence routing**(低置信度分流):标记它、请求确认、转给人,或者向用户问一个澄清的问题。 不确定的情形恰恰是盲目自动化伤害最大的地方,所以它们值得有自己的处理方式,而不是和稳妥的情形带着同样的笃定一起发出去。为不稳的中间地带而设计,而不只是为 **happy path**(顺利路径),才让功能变得稳健。 _Diagram: 置信度决定路径:高——自动处理,中——确认或澄清,低——交给人。_ #### Low-confidence Routing (置信度阈值) - **问题:** 不稳的答案带着和稳妥答案一样的笃定发了出去。 - **思路:** 设一个置信度阈值:低于它,就走另一条更谨慎的路。 - **例子:** 垃圾邮件过滤器:有把握——自己归档;没把握——标上“请核对”。 - **代价:** 你需要某种置信度估计,以及处理人工队列的人手。 - **何时使用:** 在自动化流程中:分类、提取、客服。 - **关联:** 用到 **Confidence Signals**;极端情形是 **Abstention**。 ### Graceful Degradation — 降级,而不是崩溃 > GPS 丢失信号时,会显示你最后已知的位置并提示“正在搜索”,而不是一片空白,或者把你领下悬崖——它失败得很柔和。 当 AI 无法完成任务时——出错、宕机、请求超出范围——体验应当**优雅地降级**,而不是崩坏,更糟的是产出一堆垃圾。**退回**到更简单的选项、一条清晰的提示、一条手动路径、一个缓存的结果。 一个失败后落入合理而诚实状态的功能,能保住用户的信任;一个失败后落入信心十足的错误答案或一个坏掉的界面的功能,则会毁掉它。像规划成功路径那样,刻意地规划失败的模式,因为对一个会出错的部件来说,失败是正常运行的一部分。 _Diagram: 一道退路的阶梯:完整的 AI 答案 → 缓存或更简单的选项 → 清晰的提示和手动路径。而不是一道直落坏界面的悬崖。_ #### Graceful Degradation (退路) - **问题:** AI 一失败,功能就崩坏,或产出信心十足的垃圾。 - **思路:** 提前设计好退路的各个步骤,一直到一个诚实可用的状态。 - **例子:** 模型不可用 → 显示缓存的答案,或“现在做不了这个——这里是手动表单。” - **代价:** 你得构建并测试这些备用路径。 - **何时使用:** 用于任何上线的 AI 功能:出错、宕机、超出范围的请求。 - **关联:** **Design for the Unhappy Path** 的一部分;与 **Abstention** 相邻。 > **关于失败的问题:** “当模型给不出好答案时,我的设计是让它承认这一点并优雅地退回去——还是逼它给出一个可能是垃圾的自信回答?” > 对一个会出错的模型来说,失败不是边缘情况——而是常态。让它能说“我不知道”,对低置信度的情形区别对待,并降级为诚实的退路,而不是信心十足的垃圾。 ## 6. 闭合反馈回路 一个好的 AI 产品不只是输出结果——它还会从用户的反应中学习。捕捉这个信号,让每一次交互都成为改进的机会,也让用户有了被听见的方式。 ### Feedback Controls — 给用户一个轻松表态的方式 > 每个答案旁边的一个点赞和一个点踩——用户只需轻轻一点,就能告诉你它说中了还是没说中,不花他们任何力气。 **Feedback controls**(反馈控件)——点赞/点踩、一个快速评分、一个举报标记——让人毫不费力地表达一条输出是好是坏。这一举两得:用户有了掌控感,觉得自己被听见了;而你获得源源不断的真实信号,知道这个功能哪里好用、哪里失灵。 一个无法被评价的功能,是你在盲飞的功能;一个简单的反应控件,是你能得到的最便宜、最丰富的反馈。去捕捉用户本来就会给出的那个反应。 _Diagram: 答案下方轻轻一点,就变成一股信号流:功能在哪里说中了,在哪里没说中。_ #### Feedback Controls (点赞 / 点踩,显式反馈) - **问题:** 你看不出功能哪里出了错——在盲飞。 - **思路:** 就在答案旁边放一键式的反应。 - **例子:** 每条聊天回答下面放“好 / 差 / 举报”按钮。 - **代价:** 只有少数人会点;信号有噪声,需要复核。 - **何时使用:** 从第一个版本起——任何 AI 功能都适用。 - **关联:** **Feedback Loop** 的输入信号;更丰富的是 **Corrections as Signal**。 ### Corrections as Signal — 让纠正去教系统 > 当你改掉手机键盘建议的那个地址,它就学会了——这次纠正不只管这一次,还会让下一次变得更好。 最丰富的反馈,是用户自己去修改输出。当有人修改一条 AI 的建议时,这次修改就是“正确”长什么样的精确信号。这就是 **corrections as signal**(把纠正当作信号),也叫 **implicit feedback**(隐式反馈)——把它捕捉下来。纠正和拒绝就是金子:它们在真实案例上,准确地告诉你模型差在哪里。 把它们喂回你的 **evals**(见 evals 课程),让功能可衡量地改进,让产品沿着真实用户实际遇到困难的轮廓变得更好。这次纠正,既是眼下的修复,也是日后的一课。 _Diagram: 建议 → 用户的修改 → 一条带正确答案的 eval 用例 → 更好的下一个版本。_ #### Corrections as Signal (隐式反馈) - **问题:** 用户的修改丢失了——而它们是你手上最精确的数据。 - **思路:** 存下这一对“模型提议了什么 → 人保留了什么”。 - **例子:** AI 提议“周二下午 3 点”,用户改成“周三下午 3 点”——这就是一条 eval 用例。 - **代价:** 你需要记录修改,并谨慎地处理用户数据。 - **何时使用:** 凡是有 **Editable Output** 的地方。 - **关联:** 喂给 **Feedback Loop** 和 eval 集。 ### Feedback Loop — 线上反馈是你最好的 eval 集 > 最好的考题来自学生真正考过的那场考试,而不是老师想象出来的——现实写出的测试,比你写得更好。 来自真实使用的反应和纠正,是你手里最有价值的 eval 用例来源——它们就是用户实际在做的事,包括你永远想不出来的那些失败。从这些反馈中挖掘功能在哪里出问题,并把这些用例并入你的 eval 集,就闭合了**反馈回路**(feedback loop):线上教你该修什么,你修好它,下一个版本就更好。 一个让这个回路转起来的产品会持续改进;没有它的产品则是在猜。正是这个回路,让一个 AI 功能越来越好,而不只是存在着。 _Diagram: 这个循环:发布 → 真实使用 → 挖掘失败 → eval 集和修复 → 新版本发布。_ #### Feedback Loop (数据飞轮) - **问题:** 团队自己想出来的 eval,抓不到真实的失败。 - **思路:** 从线上取出失败案例,变成 eval 用例,修复,再发布。 - **例子:** 每周——点踩最多的和被修改最多的 → 新的 eval 用例 → 修一处 prompt → 发布一个版本。 - **代价:** 持续的工作:复核、标注、运行 eval。 - **何时使用:** 功能一有真实用户,就开始。 - **关联:** 结合 **Feedback Controls** 与 **Corrections as Signal**;建立在 evals 课程之上。 > **关于反馈的问题:** “用户能轻松地告诉我某个输出错了吗?这个信号是否真的流回去改进了功能——还是错误只是悄无声息地消失了?” > 好的 AI 产品会从使用中学习:给用户一个轻松表态的方式,把他们的纠正当作精确的信号捕捉下来,并把线上真实的失败喂回你的 evals,持续改进。 ## 7. 用好它 AI 产品设计归结起来,是一种贯穿始终的姿态:把模型当作一个强大却会出错的助手,并构建一种让人能安全、自信地使用它的体验。 ### 处处都是 Autonomy Calibration — 按风险叠加的多层保障 > 你让助手自己去办理文书手续,让它起草重要的信件交你审阅,而绝不让它在你不在场时签下合同——自主权随后果的轻重而调整。 贯穿整个产品、一次次要做的统一决定,是让 AI 自己做多少、又有多少要经过人。答案始终是 **Autonomy Calibration**:让它与风险相匹配。低风险、可撤回的事可以更自动一些;高风险、不可撤回的事,则要叠加上预期、核查、掌控和确认。 一个设计良好的 AI 产品,不是一律自主,也不是一律谨慎。它是逐处校准的,依据是那里出错要付出多大的代价。 _Diagram: 风险越高,保障的层数越多:从一句诚实的表述,到带确认的整套措施。_ ### Design for the Unhappy Path — 为错误的答案而设计 > 一位优秀的安全工程师设计汽车时,假定事故一定会发生,而不是指望它不发生——安全气囊就是为糟糕的那一天准备的,而它正是意义所在。 成熟的 AI 产品设计的标志,是围绕模型会**出错**来构建,而不只是围绕它会答对。这就是**为不顺利的路径而设计**(designing for the unhappy path)的原则。演示展示的是正确的答案;产品要经得起错误的那个。所以你要设计核查、掌控、优雅的失败、反馈回路——也就是让一次自信的错误变得可以被发现、可以被挽回的那套机制。 把顺利路径跑通,你得到的是一个演示;为不顺利的路径去设计,你得到的是一个人们真能托付真实工作的产品。 _Diagram: 演示只覆盖最上面那条路径。产品还要接住错误的答案:核查、掌控、优雅的失败、反馈。_ #### Design for the Unhappy Path (为错误的答案而设计) - **问题:** 功能是为演示设计的——第一个错误答案就变成一场灾难。 - **思路:** 把错误的答案当作正常的情景,有意识地去设计它。 - **例子:** 带着“模型是错的”把功能走一遍:用户能看出这是 AI、能核查、能编辑、能撤销、能举报吗? - **代价:** 发布前多做些工作——备用路径、文案、控件。 - **何时使用:** 在每个 AI 功能上线之前。 - **关联:** 把课程里的每一组串联起来;结果就是 **Trust by Design**。 ### 这一切如何连在一起 > 一支管弦乐队:每个声部各奏各的部分,但你听到的是一首乐曲。 一切都始于 **Fallible Component**:模型哪怕出错也一样自信。五组实践——预期、展示过程、掌控、优雅地失败、反馈——是设计给出的五个应对。**Autonomy Calibration** 决定某个具体环节需要每个应对多少。合在一起,就产生了 **Trust by Design**。而反馈回路又经由 evals 流回去,随着时间推移让模型变得更好。 _Diagram: 一个会出错的模型 → 五组实践 → 按风险校准 → 信任。反馈回路经由 evals 流回去。_ #### 发布 AI 功能之前 - **自主权是否与风险相匹配**——可撤回的地方更自动,不可撤回的地方更受控? - **预期是否诚实**——告知用户这是 AI,输出表述为草稿,没有夸大? - **用户能否核查**——标明了来源,答案可以核对,在有帮助的地方展示了置信度? - **人是否在掌控**——建议而非行动、输出可编辑、不可逆之前先确认、可以撤销? - **是否优雅地失败**——能说“我不知道”,低置信度有专门处理,降级而不是崩溃? - **反馈回路是否闭合**——容易表态、纠正被捕捉、喂回了 evals? #### 你把 AI 设计好了的迹象 - 这个体验靠可验证性和掌控**赢得信任**,而不只是靠模型能力。 - 用户被**诚实地**告知它是什么,输出被表述为有待核对的**草稿**。 - 人始终**在掌控**——能编辑、能确认、能撤销。 - 它**优雅地失败**,承认不确定,而不是信心十足地编造。 - 真实的**反馈**流回你的 evals,于是功能随使用而改进。 ## 速查表:全部 19 个概念 ### 会出错的模型 - **Fallible Component** (自信却会出错): 模型答对时和瞎编时听起来一样笃定。 - **Trust by Design** (信任是产品的属性): 信任是产品的属性:能核查、能纠正、能撤销,并知道会发生什么。 - **Autonomy Calibration** (自主权与风险相匹配): 出错的代价越高、越不可撤回,AI 得到的自由就越少。 ### 诚实的预期 - **AI Disclosure** (说明这是 AI): 直截了当地说:这是 AI,它可能出错。 - **Draft Framing** (草稿,而非裁决): 把输出呈现为有待修改的草稿,而不是定稿的答案。 - **Under-promise, Over-deliver** (不要夸大): 承诺的比模型能做的少一点;诚实地说出它的局限。 ### 展示过程 - **Citations** (来源标注): 每个论断都链接到用户可以打开的来源。 - **Verifiability** (可核查的答案): 用户能对照现实确认答案,而不是凭信念接受。 - **Confidence Signals** (可靠性提示): 展示哪个答案稳妥,哪个不太稳。 ### 让人掌控 - **Suggest, Don't Act** (human-in-the-loop): 模型提议;人来决定并扣动扳机。 - **Editable Output** (塑造它,而不只是接受): 结果可以编辑、可以保留一部分,而不只是接受或拒绝。 - **Confirm & Undo** (事前停一下,事后退一步): 不可逆之前停一下,事后还能退一步。 ### 优雅地失败 - **Abstention** (“我不知道”): 诚实的拒答,胜过信心十足的编造。 - **Low-confidence Routing** (置信度阈值): 不稳的情形交给确认、澄清或人来处理。 - **Graceful Degradation** (退路): 出现故障时,退回到简单而诚实的状态——而不是一个坏掉的界面。 ### 反馈回路 - **Feedback Controls** (点赞 / 点踩): 就在答案旁边的一键式反应。 - **Corrections as Signal** (隐式反馈): 用户的修改,就是正确答案的一个精确范例。 - **Feedback Loop** (数据飞轮): 线上失败 → eval 用例 → 修复 → 更好的版本。 ### 收尾的原则 - **Design for the Unhappy Path** (为错误的答案而设计): 演示展示的是正确的答案;产品要经得起错误的那个。 > AI 产品设计,就是构建这样一种体验,让一个强大却会出错的模型可以被安全地使用:自主权与风险相匹配、诚实的预期、可验证的答案、人在掌控、优雅地失败,以及一个会学习的反馈回路。 速成课完 · 7 章 · 19 个概念 接下来是练习:拿一个 AI 功能,从用户那一侧走一遍,这一次假定模型出错了——他们能看出这是 AI 吗,能核查答案、能编辑它、能撤销它、能上报那次偏差吗?凡是答案为否的地方,那是一个设计的缺口,而不是一个模型的缺口。去修体验,而不只是修 prompt。但有一个想法要置于其余之上:模型会自信地出错,而你的设计决定了这件事是落地为一条被逮住、可挽回的建议,还是一场以事实之名递出的灾难。为错误答案而设计,正确的那些便会自己照看好自己。