第 10 章 失败体验与兜底设计

智能体必然出错，概率性行为意味着十次任务里偶尔冒出一次离谱的，这是常态，不是事故。既然出错躲不掉，产品设计的胜负手就在出错之后，传统产品把绝大部分功夫花在不出错上，出错处理是质量手册后面的一节附录；智能体产品把出错之后当作核心问题，用户在错误时刻看到什么、产品说什么、做什么，全部要事先设计。这一块是智能体产品与传统产品差异最大的地方，差异的根源在于，传统软件的失败自己会报，报错、崩溃、白屏，用户起码知道出了错，提个工单，研发定位 bug、发版、回归；智能体最危险的一类错，屏幕上什么都不显示，答案给出去了，语气笃定，格式规整，错就错在内容里，用户拿着它继续往下走。处理会报的失败，工程有几十年的积累；处理不报的失败，靠的是产品设计。

本章五节，顺着一条线走。10.1 追源头，把不确定性拆成三类，每类配上产品经理能认出来的征兆；10.2 看伤害出在哪，失败在用户体验上分四类，分类不同，对策全不同；10.3 给出出错后的动作词汇，重试、降级、转人工、道歉、补偿；10.4 讲动作了结不了的那部分，错了算谁的，责任边界怎么设计进体验里；10.5 案例线第五站，周报产品的归因错了两次，一次拦在关口内，一次漏到关口外，纠错回路完整走一遍。

10.1 不确定性管理的框架

不确定性分三类，输出不确定、行为不确定、环境不确定，每类有产品经理能认出来的征兆、后果出在哪、产品能管到的那一层。不确定是源，失败是果，同一句话问两遍答案不一样，这是不确定；用户拿着其中一个错误答案去订了货，这是失败。源头上的三类不确定，传到用户身上就变成各种各样的失败，10.2 再拆果，这里先拆源。

输出不确定是头一类。机制第 2 章讲透了，模型按概率接话，预测下一个词没有标准答案，只有可能性大小，所以同一个输入，两次产出天然有出入。产品经理认它的征兆，听的是三句话，客服说“用户反映时好时坏”，测试说“这个 bug 复现不了”，老板说“上周演示还好好的，今天怎么就不行了”。听到这三句别当 bug 报修，研发复现不了不是失职，这是概率模型的正常波动，修是修不掉的。输出不确定的后果，是验收和信任两头一起晃，验收没法按单次对错签收，第 3 章就换成了“一批任务里对多少”，第 7 章立的可用率是它的落地；用户对产品建立不起稳定预期，这次惊艳下次平庸，比次次平庸更伤信任。产品管的是它的后果，按批考核、界面留重新生成的入口、对外承诺说清正确率多高，不说“保证正确”。

行为不确定是第二类。智能体多出来的东西是自主权，同一个目标，它两次会走出不同的路径，这次先查促销、下次先看天气，每次拿的主意未必一样。征兆藏在两处，一处是日志轨迹，同一类任务，两次执行的步骤顺序对不上；另一处是人嘴里，复核的人说“猜不到它下一步干什么”，用户问“它这次怎么先干这个”。行为不确定的后果，是过程写不出操作手册，复核的人每一遍都得从头看；更要紧的是，路径自己会变的那段流程，风险也在跟着变。产品管法是把第 7 章的决策点表拿来对着看，交给模型的环节，过程要可见，第 9 章的透明度设计管这个；出错贵的环节，收回来写死或者留人审，不许它自己发挥。

环境不确定是第三类。智能体挂在真实系统上跑，上游接口会改字段，数据会迟到，外部世界自己会变，上一秒查到的库存，下一秒可能就没了。征兆最扎眼，半夜的告警电话，上游一次无通知的改版，数据还没有到齐，智能体就开跑，出了一份缺胳膊少腿的结论。这一类有个最麻烦的属性，错不在模型，模型拿到了什么就算什么，但用户不管这些，用户只找产品。产品管法有三件。核对，产出里的每个数字回头跟源头对一遍。检查点，任务跑一半断了，能从断点接着跑，不用从头再来。依赖要有观测，上游一变，产品的行为漂移要有人看得见，可观测性第 15 章展开。

三类拿周报产品各对一遍，征兆就落了地。输出不确定，同一个历史周跑两遍归因，两份初稿的侧重多半有出入，7.7 的当众对答案之所以成立，靠的正是预先知道会有出入，拿标准答案评分，不拿两次一致评分。行为不确定，这次先查促销、下次先看天气，查证顺序周周不同，小周核对时，要看的重点不在过程像不像上周，在每一步的依据成不成立。环境不确定，PoC 阶段碰上的那个日期口径，收银后台记到秒、库存后台记到日，上线后上游一次改版就可能原样回来，核对和依赖观测就是给这种事准备的。三类的征兆还有一个共同的去处，用户原话、轨迹日志、值班记录，三路信号汇进同一张台账，按类归档，每周例会过一遍新条目；台账上哪一类连着几周都在涨，问题就在哪一类，比拍脑袋猜“模型变笨了”可靠得多。

三类摆开，本节要立的核心判断只有一条，不确定性算不上缺陷，它是本性。这句话不是安慰，它决定产品的动作方向。把不确定当缺陷，动作就是消灭它，换更强的模型、加更多的规则、把随机性调到底；第 2 章讲过这条路走不通，调低随机性只会让模型从偶尔错变成每次错同一个错，换更强的模型，三类不确定一个都不少，不过是幅度小些。把不确定当本性，动作就换成管后果。传统软件工程其实也天天对付不确定，靠的是重试加幂等，操作失败了就重来，重来的结果和第一次一样，所以敢放心重试；这套假设到智能体上整体失灵，输出和行为本身就带随机，把失败原样重跑一遍，结果未必更好，有时还把做了一半的事又做一遍。产品设计的全部起点在这一句，兜底动作必须按“重跑会得到不同结果”来设计，这句话 10.3 讲重试时兑现。

三类表也是一张自查表。上线之前拿它逐行填，每类不确定，产品里对应的设计是哪一件，征兆从哪里监控；哪一行填不出来，那一行就是还没有看住的地方，而它早晚以某种失败的形式找上门来。

10.2 失败模式的产品分类

失败按用户体验分四类，做不到、做错、答错、说不出不知道，分类轴是三个问题，用户在这类错误里经历什么，错误什么时候露头，露头时损失已经有多大。错误分类决定兜底动作，分错类，兜底全白做；同一句“系统出错了”，背后可能是三种完全不同的病，限流了，等几秒重发就好，参数不合法，重发一百遍也不合法，凭证过期，重发只会一遍遍撞同一堵墙，处置彼此相反，分类就得先立。研发那边按技术栈分，模型层、工具层、编排层，那是排障的分法；产品经理要按用户体验分。

做不到是第一类，任务中途断了，模型接口超时，工具背后的服务报错，进程重启把会话丢了。这类失败最显性，用户看到的是转圈、无响应、一句冷冰冰的系统错误；体验上它本该最良性，毕竟产品诚实地失败了，没有骗人，但实际常常做得最糟，因为等待这件事没有人设计过，用户不知道发生了什么，不知道要等多久，不知道该重新发起还是该放弃。失败的告知文案，高下差别一比就出来。差的写法是“出错了，请稍后重试”，用户读完只知道两件事，坏了，能重试，坏在哪、等多久、重试要不要钱，一概不知。好的写法把三件事说全，“取数这一步超时了，收银后台没响应；系统会在两分钟后自动重试一次；这一单不成功不计费，急着要的话可以先看上周的数字”。同样是失败，前者把用户晾在原地，后者把用户接住。产品对策三件。状态可见，告诉用户它正在干什么、卡在哪一步；进度保留，跑到一半的内容别丢，生成到一半的结论也是工作量，中途出错时把已生成的部分和原始请求都留下来，用户能接着改，不用从零再来；失败要明说，说清失败和下一步的选项，别让用户对着一个转圈图标猜。工程侧对这类失败有自己的接法，检查点续跑、备用模型顶上，那层的展开见姊妹卷；产品侧要接住的是人的体验，系统接得再稳，界面上一句模糊的“出错了”，用户体验照样归零。

做错是第二类，动作执行了，但执行错了，退款退错一笔，地址改错一单，周报发给了不该看的人。这是后果落地那条特殊性的直接产物，错误从屏幕上的错字变成真实世界里的错事，刷新不管用，收拾要去真实世界里收拾。做错通常发现得快，钱对不上当天就露馅，但修复的成本高，而且每一单都在消耗用户的忍耐。产品对策的思路是把错误的可逆性放进设计，动作先分级，只读的自动跑，不可逆的留人审；工程侧一个客服产品的做法值得照抄，查订单直接放行，改地址和赔付这类动钱的操作挂进待审区等人点头（口径见本章参考资料）。能设计成可回滚的动作，优先做成可回滚，先做能撤销的那版，再放开做不了撤销的。

答错是第三类，话答出去了，内容是错的，典型就是幻觉，机理第 2 章讲透了，这里讲产品侧必须认清的一个本质，答错与传统软件错误不是一类东西。传统软件出错，输出的是明显错误的东西，报错、崩溃、乱码，用户一眼看出出了错；答错看起来跟正确一模一样，语气笃定、格式规整、数字有零有整，它以跟真话完全相同的口吻呈现假话，从头到尾不告诉任何人它错了。这个差别决定了体验后果，做不到和做错都是当场或很快暴露，答错可能潜伏很久，用户按错误答案行动了才发现，发现得越晚，代价越大。有个现成的教训，全球最大的程序员问答社区在 2022 年末干脆封禁了 AI 生成的回答，理由不在 AI 错得离谱，在它错得有条有理，人工版主根本拦不过来（口径见本章参考资料）。产品对策有三件。出处标注，每条结论旁边附证据链接，让用户有核对的地方，第 9 章案例线的信任三件套干的就是这个。自动核对，数字类的错误让规则去抓，产出里每个数字回头跟源数据对一遍，程序能对的不用人看。批量抽检，靠评测兜住整体水平，评测正是第 11 章的主题。

说不出不知道是第四类，没有把握，却不说“不知道”，硬答一个。四类里就数它最受忽视，先把为什么讲清。前三类好歹都算失败，有报错、有错单、有投诉，指标里看得见，会上排得出优先级；第四类表面无失败，任务完成了，答案给出了，没有任何异常信号，直到有人拿它当了真，它也不违反任何考核，如果考核只看答案存不存在的话。机制上它就是第 2 章讲的那件事，语气是照着“正常回答长什么样”接出来的，跟对错不相干，模型不会因为没把握而语气迟疑。工程侧把这条列进了生产失败清单，遇到没有数据的事，模型不发出不确定的信号，反倒是编一个听着合理的答案；还有一项基准实验把这事量得更狠，选择题里根本不放正确答案，模型照样自信作答，一题不空。产品对策有三件。给退路，指令层面写明查不出就如实标注，周报归因的提示词第 7 章写的那句“查不出原因的地方，如实写未查明，不要编”，防的就是这一类。置信标注，拿不准的地方在产出里明说，别让笃定的语气替产品撒谎。测拒答，评测集里专门放该拒答的题，测它在没把握时敢不敢如实标注，第 11 章建任务集时兑现。

四类摆在一起，伤害出在哪各不相同，做不到伤害这一次任务的完成，做错伤害真实世界，答错伤害用户接下来的决策，说不出不知道伤害的是用户的判断本身，而且伤害发生的时候没有人知道。四类在“发现时刻”这根轴上排开，产品对策的轻重也跟着排，做不到当场暴露，对策是把等待和告知设计好；做错很快暴露，对策是把可逆性设计进去；答错潜伏到用户碰上，对策是给出处、给核对、给抽检；说不出不知道可能永远不暴露，只能靠事前给退路、事后测拒答。发现越晚的错，越没法靠出错那一刻的动作补救，越要在设计的前端下功夫，这条规律贯穿本章往后的三节。对第四类还有一句正面的话，把“可靠”这个词拆开看，其中一条就是无能为力时体面地失败，直说帮不上忙，别瞎猜（口径见本章参考资料）；会把“不知道”说出口，是一项要专门设计、专门考核的能力，不是对模型的道德期望。

10.3 兜底动作的设计词汇

兜底动作是一套五个词的词汇，按代价从轻到重排，重试、降级、转人工、道歉、补偿，每个动作有它自己的适用条件，用错了地方，动作和错误的分量对不上。出错之后的前三十秒，产品做什么、说什么，全部是设计出来的，不能等出了事现场编，现场编出来的台词只有一个样子，系统繁忙，请稍后再试。

重试的适用条件最窄，只管瞬时性错误。限流、超时、服务抖动，这类错的特点是等一等自己会好，退避几秒再发一次是对的；窄就窄在别的错都不该重试，参数不合法，把报错原文回填给模型，让它自己改参数再跑，凭证过期，立刻上报去换新凭证，分类先于处置，这条纪律工程侧叫错误分类决定去向。还有一条经验要记，同一个错连犯三回，原样重发大概率还是错，该换问法或者换路径。智能体的重试另有一层特殊，重跑会得到不同结果，这既是机会也是陷阱，换一次抽签可能抽中对的答案，也可能把已经对的东西换没了，所以界面上的“重新生成”按钮要配一件事，保留前一版，两版并排摆，让用户挑，别让一次重试毁掉他手里已经能用的东西。重试的代价是时间、花费，还有用错地方时把小故障滚成大故障。

降级说的是主路不稳时，换一条更稳但更弱的替路走。主模型超时了换备用模型顶上；深度归因跑不动，先交一份数字全对的浅表周报。工程侧的常见配置是多档模型加自动回退，简单的活走便宜档，复杂的活走主力档，主力失败自动切到备用，一层层接住。产品上的铁律是降级必须可见，宁可界面明说“本周深度分析暂不可用，先给数字版”，也不默默降级冒充正常产出；用户拿到降级版而不知情，会把质量下滑记成“这产品不行”，这个印象记下了就很难改回来，而且错怪得有理，因为产品确实瞒了他。哪些能力可以降、哪些绝不能降，设计期就定死，归因深度可以降，数字核对永远不能降，数字错一分的降级比不交付更糟。降级的代价是产出变弱，所以降级频次本身要当一个护栏指标盯，降多了说明主路有病，度量体系第 15 章展开。

转人工是产品认了这一单干不了，把活交给人。适用条件有三类，明显超出能力边界的复杂场景，高危动作，用户明确要人。先纠正一个误解，转人工不是失败，硬撑着答才是失败。一个客服产品的案例把这笔代价算得很直白，复杂账单问题原先由 AI 硬答，用户受不了，自己发起转人工，占了两成多；后来改成识别出复杂问题就直接带着上下文转给人工，用户发起的转接降到百分之八，满意度从 5 分制的 4.2 分升到 2.1 分（口径见本章参考资料）。用户不反感转人工，反感的是在一个答不了的机器人身上耗到崩溃才转。设计要点两条，带着上下文转，别让用户把事情对下一个人重新讲一遍，智能体的运行轨迹就是现成的交接单，它查了什么、试了什么、卡在哪，一并递过去；转之前给预期，等多久、谁会来。代价是人工分钟，那是真金白银，第 12 章算单位成本时会把人工一项项算进去；另外转得太多本身就是信号，说明能力边界画错了地方。工程侧有个可以借来的经验值，需要人审的动作，审批通过率长期高于九成五，说明送审标准定得过紧，该收回一批让它们自动跑（口径见本章参考资料）。

轮到道歉的时候，错误已经到了用户眼前，接下来修的是关系。道歉的内容有三件套，出了什么错，说清楚，不许拿“系统繁忙”这类没信息量的话搪塞；为什么会这样，机制一句话讲到底，用户听完能向别人复述；接下来怎么办，正在重试、已转人工、已回滚，给一个具体的下一步。这三件借自错误设计的通则，错误信息要让用户可理解、可恢复、可预防（口径见本章参考资料），翻成道歉就是上面那三件。空道歉比不道歉更伤，“给您带来不便敬请谅解”翻译过来是“错是错了，但我不打算说错在哪”，这句道歉把用户当成需要安抚的麻烦，而不是需要交代的服务对象。道歉还要发生在正确的地点，出错的界面当场，不是事后的客服话术库。代价也要认，道歉花的是用户攒下的信任，道歉频次同样是护栏指标，道歉越勤，说明前面四个动作越失职。

补偿用在错误造成实际损失时，拿钱或权益修复。这是最后的手段，也是动手越晚代价越高的手段，产品要预设两样东西。触发线，什么级别的错误自动进入补偿流程，别让用户先吵三天再谈赔。额度权限，一线能直接赔多少，不用层层请示，为了十块钱的补偿走三天审批，用户拿到补偿时怨气已经翻了倍。补偿必配道歉，单独给钱像封口费，单独道歉显得廉价。案例线的版本就在 10.5，错误的归因让店长调错了排班，补偿没有赔钱，做的是把损失算清楚、把改回去的方案送到人手上。

五个词连起来有个结构，前三个动作挡在错误与用户之间，用得好，用户全程无感；后两个动作发生在错误与关系之间，错误已经穿过去了，修的是人对产品的信任。词汇表的用法不在背，在填表，拿第 7 章的决策点表，给每个交给模型的环节加一列，这一步失败时用哪个动作，什么条件触发，谁来执行。周报那张八行的表填下来，取数失败用重试，连续失败用降级交数字版，归因干不了用转人工，发出后发现问题走道歉加撤回；填不出来的格子，就是兜底设计的窟窿，评审会上当场现形。

填好的表分进三层，就跑得起来。最里一层进系统配置，重试的退避时长、降级的档位、量级矛盾的自动标黄（降幅之间差得远时自动标出来，10.5 详述），程序执行的规则写进系统；中间一层进运营手册，转人工以后谁来接、几点到几点有人、节假日谁顶班，这些程序管不了；最外一层进客服口径，道歉三件套的标准句式、补偿的额度权限，直接面对用户的人手里要有现成的词。三层合起来叫剧本，只有第一层，兜底就是半成品，出错的周一晚上，用户等来的还是一句系统繁忙。

10.4 免责与责任边界的产品设计

责任边界的分界判据一条，谁有能力防住这个错，谁就担这个错；产品该担的错全在决策阶段可防，用户该担的错以“边界讲到看得见”为前提。错误怎么处置讲完了，还有一件事要算清，这次错，算谁的；责任分不清，产品每错一次就攒一分怨气，攒到 B 端客户的群里爆一次，商业上就难看了。先立基础，责任这件事，监管和标准界的口径已经收敛，智能体可以执行动作，但没办法在道德和法律意义上负责任，责任由设计、部署、运营这套系统的人和机构承担，美国的 NIST 风险管理框架、ISO 的 AI 管理体系标准、欧盟的 AI 法案，三家口径一致（口径见本章参考资料）。这条共识翻译成产品语言就一句，别指望“这是模型干的”这句话在客户或者法庭那里开脱责任，产品卖出去，产品背后的公司就得为它的行为负责。

产品该担的错有三种，全是产品决策阶段就该防住的。能力宣传过头，宣传页写“全自动智能分析”，产品实际交付的是初稿加人工核对，落差本身就是产品造的；已知缺陷没告知，明知某类场景答得差，用的时候一个字不提；该设防的没设防，动钱的高危动作没有人审，核对关口没有留。这三种错，条款写得再漂亮也救不了，因为病根在设计里。

用户该担的错也有一种，产品把边界讲清楚了，用户跳过边界用。结论标了“仅供参考，发出前请核对”，用户原文转发当定论，损失发生，责任在用的一侧。但这里产品还有一件没有做完的事，也是最容易自欺的一件，把边界讲到用户真的看得见。写进服务协议第三十八条不算讲清楚，用户不读协议，读的是界面，边界要在用户用到的地方出现，不是在法务放心的地方出现。“仅供参考”四个字也要再挑剔一遍，它是没有信息量的套话，什么参考、怎么参考、参考到哪一步，一个字没有说。好的边界写法带三样，它做了什么，数字已与三个后台逐条核对；它没做什么，结论是初稿，未经人工确认；用户该做什么，确认后署名发出，或退回重查。三样写全，边界就立在用户眼前。

最大的一片是灰色地带，模型答错了，用户没核对就采纳了，损失摆在那里，两边都觉得对方该负责，吵得最凶的永远是这类。产品设计的准备全在事前，而且这些设计不是体验加分项，它们本身就是责任边界，核对关口设在那里，署名的人天然较真，第 4 章判断回路时立过这条；置信标注画在那里，拿不准的地方明说；高危结论的复核入口留在那里。这些关口和标注都在，出了错，各自的责任一目了然，灰色地带会缩到最小；关口没设、标注没有，写什么条款说出来都像推卸。B 端和 C 端在这里的画法不一样。B 端的责任链长，客户组织里的人就是天然的关口，周报线上，小周是核对关口，店长是业务关口，第 8 章定的分层形态刚好把人嵌在了该嵌的位置，产品要做的是给这些关口配权限和入口，别让想把关的人无处下手。C 端没有这层组织，用户是孤身一人对着产品，边界更要写进交互的每一步，出错时刻的每句话都算数。

线画好了，条款怎么进体验，落三层。事前，在能力边界处给一张大白话的系统卡，这系统怎么干活、安全措施是什么、局限在哪、什么情况它会失败，用用户的话写；把“故障时的默认动作”和“什么情况升级给人”写成产品文档的标配，这套做法在工程侧的方法论里已经有名有姓（口径见本章参考资料）。周报产品的系统卡其实就三句话，数字与三个后台逐条核对过，归因结论是初稿、模型给的、可能出错，发出前请小周确认、发现错误可撤回更正；三句话用户半分钟能读完，读完知道自己在跟什么打交道。“归因结论是初稿”这句话，出现在周报页面上，比出现在协议里有效得多，前者是设计，后者是防御。事中，在错误发生处，出错的界面就是责任声明的现场，错了直说错了、错在哪、下一步做什么，用户在出错时刻看到的诚实，比任何条款都能守住责任边界。事后，在追索通道上，用户要能申诉、能要求更正、能撤销错误的结果；撤销机制本身就是责任的产品化，错了能改回来，对话就从“这算谁的错”变成“怎么一起把它修好”，后者便宜得多，也体面得多。

最后一条底线，免责条款能免掉的，是明示边界之外的期待，免不掉隐瞒缺陷的责任。把“结论不担保正确”印在界面上，配上核对关口和撤回通道，这是诚实的免责，用户知道自己在跟一个什么样的产品打交道，边界外的事自己负责；一边宣传全自动，一边在协议深处藏免责，责任未必真免得掉，人心先丢了。B 端市场尤其经不起这一下，一个客户群里几十个人看着，一次甩锅传一个行业。三地监管的具体动作清单，第 14 章展开，本章只管一件事，出错时刻的诚实。

10.5 【案例线进五】归因错了怎么办

周报产品的归因错了两次，一次拦在核对关口内，一次漏到关口外由店长识破，收场四步，撤回更正、已读提醒、影响盘点、道歉修复。先接上前情，产品的管道是第 7 章那条，固定自动化取数核对，模型写归因初稿，每条结论带证据链接，小周核对，署名发出；开发协作阶段的双周迭代，喂的正是每周真实跑出来的周报，这个阶段产出走内部对照，它写它的初稿，小周照常写自己的，两份摆在一起比，还不署名发出，所以错出得了记录、出不了门。九月中那一周，对照里错了。

那一周 ST003 大学城店的销售环比掉了两成多，归因初稿把主因写成“开学季返校客流尚未恢复”。这个故事讲得通，大学城店，九月，开学季寒暑假落差大是这家店的规律，历史同期确实有过类似的节奏；数字全对，出处全有，天气正常，自家没做促销，一切都规整。

小周核对，四条清单过到“每条结论有出处”时，他停住了。出处都在，可他把证据链接逐条点开对了一遍，发现证据够不上结论，那周客流降了不到一成，销售却降了两成多。返校节奏解释得了客流变少，解释不了人少一成、钱少两成这个差距，还在店里的人，钱花到哪里去了，初稿没有回答，也没有把这个矛盾标出来。小周给店长打了个电话，答案果然在报表外面，隔壁街新开了家茶饮店，开业头两周做大促，把课间客流截走一截，剩下的客流里也有人拎着对家的杯子。

这是核对关口的第一次实战拦截。小周抓的不是数字错，数字全对，也不是没有出处，出处全有，他抓的是结论的量级超出了证据的量级；清单四条里没有一条写着查这个，他能停下来，靠的是清单逼着他逐条过、过的时候对不上就停。产品上该改进的地方当场记下两条，核对清单加第五条，证据的量级要够得上结论的量级，够不上的必须标注；这条检查其实能写成规则，客流降幅和销售降幅差超过一定倍数就自动标黄，规则先抓一遍，别全靠人的直觉。这一单没有发出去，止损为零，但复盘照做，竞品动态这类信息怎么进给料，记进迭代清单。

三周后，对照攒够了质量记录，产品进了试点期，周报开始署名试发，同型的错误换了副面孔，这次漏了网。ST001 写字楼店销售掉了近一成半，归因初稿写“秋凉后热饮需求上升、冷饮销售自然回落，叠加工作日客流下降”，数字全对，出处全有，而且这组数据恰好互相印证，量级的矛盾不明显。小周核了一遍，没有抓到，署名发出；那段初稿老陈也扫过一眼，同样没有起疑。

周报发出去三天，老陈在店里越想越不对。他天天守在楼下，知道真实原因，写字楼里两家公司那两周先后搬走，另一栋楼的大堂装修围挡把侧门封了半个月，午间过来的客流少了一大截；天气转凉的解释他不认，在这个行当干了三十年，这个凉法掉不了这么多。他翻出周报，找到归因那一段，在运营群里直接说“这条不对，原因是楼里公司搬走加围挡封门”。

比识破更要紧的是，影响已经发生了。管理层月度会引用过这条归因；老陈自己看了周报，把下一周的晚班人手排少了两天，写字楼店的晚班本来就薄，那两天晚高峰排队时长上去了，店里挨了两单投诉。结论有人当了真，损失从纸面进了排班表。

收场一步一步走。第一步，撤回更正，周报是带链接的网页版，有版本记录，更正版当天发出，顶部一段更正说明，哪一条改了，为什么错，新证据是什么，旧的错误结论不删，整段标灰并注明已更正；悄悄删掉错误结论是最差的做法，看过的人不会知道看过的是错的。第二步，已读提醒，后台看得到谁打开过周报，给打开过的管理层和店长定向推一条更正提醒，月度会还没有开的，下次开会先把更正版摆上桌。第三步，影响盘点，这条结论谁用过，逐个清点，管理层的引用用更正版对冲，老陈的排班已经错了，把改回去的建议连同那两天的销量和投诉数据一起送过去，把影响算清楚、摆到明处。第四步，道歉，按 10.3 的三件套说，错在哪，归因只看了周期因素，漏了商圈结构的变化；为什么错，竞品和商圈的动态不在数据源里，模型拿一个讲得通的周期故事填了证据链上的洞；接下来怎么办，见下面的修复。对老陈的补偿不是赔钱，把他损失的算清楚，把改回去的方案备好，外加一条承诺，今后涉及他店里事的归因，发出前多一道他本人的确认入口；这条承诺记进迭代清单，正好接上第 7 章留的第二单，店长问答，店长从周报的被动读者，变成归因的第二道核对关口。

复盘归档，两次错误归成一类，就是 10.2 的第四类，说不出不知道。数字全对，出处全有，错在明明证据够不上结论，还讲得那么顺，不标注，不说不知道；归第四类、不归第三类答错，差别在这里，答错错在内容本身，这两次数字与出处都对，模型不知道自己的证据够不上结论，也不知道讲错了，该说不知道而没说，正是第四类的形状。它确实是最隐蔽的一类，第一次有小周的经验加运气拦住，第二次连核对关口都放行了，最后靠的是店长的现场知识。回路闭合之后，这次错误换回四样东西。更正机制三件套，版本记录、已读提醒、影响盘点，写进产品，今后再发生同类事按流程走，不再靠现场发挥。数据源补齐，竞品动态、商圈事件这类店长知道、系统不知道的信号，短期靠店长问答的入口收进来，中期纳入给料。检查升级两处，核对清单加了第五条，量级矛盾的自动标黄进系统，小周脑子里的常识核对，变成系统先跑的规则。测试题加两道，这两周的历史数据带着正确归因，成了评测集里现成的题，一个测归因方向，一个测该不该标不确定。

还有一件事不显眼，却决定这场事故的成色，老陈对产品的信任没有崩。撤回更正版发出去当天，他在群里回了一句“改得挺快，下回先问问我”。这话背后有第 9 章的功劳，产品从第一份周报起，承诺口径就是初稿加核对，从来没有说过保证正确，证据链接和分级标注也一直在教读者怎么怀疑它。期望管理管到位的产品，出错时用户说“下回先问问我”；期望吹满的产品，同样这个错，用户说的是“再也不用了”。出错时刻的体验，一大半在出错之前就写好了。

错误不可怕，同一个错误原样发生第二次才可怕。纠错回路每转一圈，评测集多一层，下一版初稿就更稳一点，这套错误变资产的循环，第 15 章的数据回流飞轮正面展开；错误率怎么在上线之前测出来，第 11 章解决。

本章小结

• 10.1 三类不确定。输出不确定征兆在“时好时坏、复现不了”，行为不确定征兆在轨迹对不上，环境不确定征兆在半夜告警和数据迟到；不确定性是本性不是缺陷，产品管的是后果，兜底按“重跑会得到不同结果”设计；三类表兼作上线前自查表。
• 10.2 失败四分类。做不到伤害任务完成，做错伤害真实世界，答错冒充正确、伤害决策，说不出不知道连报错都没有、伤害用户的判断本身；前两类当场或很快暴露，后两类要等用户碰上，发现越晚，越要在设计前端下功夫。
• 10.3 五个兜底动作。重试只给瞬时性错误，重新生成必须保留前一版；降级必须可见，数字核对永远不能降；转人工带上下文转、给预期，诚实地承认干不了；道歉三件套，出了什么错、为什么、接下来怎么办；补偿预设触发线和额度权限，必配道歉；词汇的用法是填进决策点表，分进系统、运营、客服三层。
• 10.4 责任边界。监管共识是责任留在机构；产品该担的三种错全在决策阶段可防，用户该担的错以边界讲到看得见为前提；灰色地带的大小由核对关口和置信标注这些设计决定；条款落三层，事前系统卡、事中错误界面、事后追索通道；能免的是明示边界之外的期待，免不掉隐瞒缺陷的责任。
• 10.5 纠错回路。第一次错，证据量级够不上结论量级，核对关口拦下，清单加第五条；第二次错漏到关口外，店长识破，撤回更正、已读提醒、影响盘点、道歉修复四步收场；两次归成一类，说不出不知道；错误换回更正机制、数据源、检查规则和两道测试题。

本章在五步方法论里是“设计怎么兜”的下半场，第 9 章管住嘴，本章管住手，承诺不越界，出错有剧本。剧本要兜的错误率到底是多少，得先评测才知道，第 11 章进“验证好不好”，评测与验收。

试一试

拿手头的产品，或者第 4 章试一试里过了关的那个需求，做三件事，约四十分钟。

第一步，列三类错。用 10.2 的四分类扫一遍产品，列出最可能发生的三类错误，每类写一句具体的样子，不要写“可能答错”，要写“归因可能把竞品开店的影响说成开学节奏”这个具体程度。想不出第三类的时候，重点盘一盘第四类，产品在哪些地方没把握却硬答。

第二步，配兜底动作。给三类错各配一个 10.3 的动作，把触发条件写成可执行的句子，什么信号出现时触发，几分钟后升级，谁来执行，界面上用户看到什么。触发条件写不出具体信号的，等于没有配。

第三步，填决策点表。把第 7 章试一试里做过的决策点表拿出来，加一列“失败时的兜底动作”，逐行填。填不出的格子，就是下一步兜底设计的工单。

交付物是一张三行五列的小表，错误类型、具体样子、兜底动作、触发条件、谁来执行。这张表就是产品的第一版兜底剧本，评审会上它和功能清单一样重要。

参考资料

• 《构建可靠 AI 系统》（Building Reliable AI Systems，Rush Shahani，Manning MEAP 2026）第 1 章（可靠 AI 定义中专门一条：无能为力时体面地失败，直说帮不上忙，而不是瞎猜；幻觉是“看起来对的错误答案”，以与事实相同的权威口吻呈现捏造信息，与传统软件错误根本不同，后者产生报错、崩溃、乱码这类明显错误的输出；律师引用六个判例全部为虚构的开篇案例），见 txt-ref-zh/building-reliable-ai-systems/04-Chapter 1 AI Reliability Building LLMs for the Real World.md（中译）
• 《构建可靠 AI 系统》第 10 章（混合架构按难度路由、失败时自动回退到备用模型；客服账单案例：复杂问题识别后直接带上下文路由给人工，用户发起的转人工从 23% 降到 8%，满意度从 5 分制 3.2 升到 4.1；“目标不是完美的 AI，而是持续交付价值、在必须失败时体面失败的 AI”；2022 年末 Stack Overflow 封禁 AI 生成回答：错得有条有理、版主拦不过来），见 txt-ref-zh/building-reliable-ai-systems/13-Chapter 10 Deploying and Monitoring.md（中译）
• 《Agentic AI For Dummies》（Pam Baker，Wiley 2026）第 7 章（问责框架：NIST AI 风险管理框架、ISO/IEC 42001 与欧盟 AI 法案口径一致，责任明确且不可转移，机器可执行动作但不能在道德法律意义上负责，责任留在设计、部署、运营的人与机构；自主度越高，控制与责任的清晰度要求越锋利），见 txt/agentic-ai-for-dummies.txt（英文原文，第 7 章行 5125-5498）
• 《Agentic AI For Dummies》第 10 章（自主权章程：写明目的与非目标、工具与数据、故障安全默认值、升级给人工的触发条件、最小权限且可收回；给用户一张大白话系统卡，讲清架构、安全措施与局限；事件报告通道），见 txt/agentic-ai-for-dummies.txt（英文原文，第 10 章行 6038-6395）
• 《Designing AI Interfaces》（Louise Macfadyen，2026）第 4 章（错误设计三原则：可理解、可恢复、可预防，避免“Something went wrong”式的空话；生成式产品里点 Try Again 等于再生成一次，同一输入会得到不同输出；中途出错应保留提示与已生成内容，让用户换方向继续而非从零开始；检查点模式），见 txt/designing-ai-interfaces.txt（英文原文，第 4 章行 4240-4380）
• 《悟道智能体开发》（本书工程姊妹卷）第 2 章 2.4 节（三类不确定：输出、行为、环境；传统工程“重试加幂等”的假设在智能体上失灵，原样重跑结果未必更好；错误分类决定处置：限流退避重试、参数不合法回填报错让模型自纠、凭证过期立刻上报换新），本章 10.1 与 10.3 的知识底本，产品向转述，工程深挖按该书对应章指引
• 《悟道智能体开发》第 14 章 14.3 节（十种生产失败模式与“智能体系统坏起来的方式既一致又可预测”；同一个错连犯三回，原样重发大概率还是错；元认知缺失的表现之一：没有数据的事不发出不确定信号，编一个听着合理的答案；选择题不放正确答案、模型照样自信作答的基准实验；客服动作分级：查单放行、改址与赔付挂待审区，审批通过率长期高于九成五说明送审标准过紧），本章 10.2 与 10.3 的知识底本，产品向转述，工程深挖按该书对应章指引