错误累积

① 一句话大白话定义：错误累积说的是一件很朴素、但绝大多数人第一次听会低估的事：**一个由多个步骤串起来的任务，它的总成功率不是各步骤成功率的平均，而是相乘。**平均是加法思维，相乘是乘法思维，这两种思维得出的结论差得非常远。每一步都做到九成，听上去是个体面的数字，一步九成、两步八成一、三步七成三、四步六成六、五步只剩五成九——也就是说，五步串起来的任务，有四成多的用户跑不完。更要命的是，这四成里的绝大多数人，看到的不是「第三步失败了」，而是「这东西不能用」。所以这个概念真正的含义是：**在多步骤系统里，可靠性不是一个可以慢慢补的指标，它是一个会被链路长度放大的指标。**

①·再打个比方（把定义钉进脑子）：这就像一串接力赛，每个人掉棒的概率都只有一成。你去问每个队员「你稳吗」，五个人都会说「我挺稳的，十次里最多掉一次」。但整队跑完不掉棒的概率是五成九——也就是说这支队伍有四成的比赛拿不到成绩，而每一个队员都觉得问题不在自己身上。这就是错误累积最阴的地方：**没有任何一个环节的负责人会觉得自己是瓶颈，因为在他那个尺度上，他确实是合格的。**我原来做景观的时候见过一模一样的结构：苗木采购九成合格、运输存活九成、种植工艺九成、后期养护九成，每一环验收都过，最后一年后成活率六成五，甲方来问责，四个环节互相指着对方。没有人撒谎，是乘法在撒谎。

①·一句话版本（30 秒电梯版）：「多步骤任务的总成功率是各步相乘，不是平均。所以我做这类功能的第一件事是把链路画出来、数清楚几步、把每步的成功率填进去、当场算一遍乘积。这个乘积是我判断要不要做、做到什么程度的起点。它一般会给我三个动作：第一，能砍的步骤先砍，砍掉一步比把一步从九成提到九成五还管用；第二，把整条链路里最低的那一步找出来先修，因为乘法里最小的那个因子影响最大；第三，在关键步骤后面加校验点，让错误在当步被发现，不要带到下一步去放大。我判断一个多步骤方案靠不靠谱，就问一句：这条链几步，乘完是多少。」

② 为什么学 / 面试为什么考：这道题是 Agent 时代的分水岭题，因为所有 Agent 产品都是多步骤的。面试官问它，不是想听你会不会算幂，而是想知道你有没有在多步骤系统上真正吃过亏。没吃过亏的人会说「我们会做好每一个环节的质量把控」，这句话在乘法面前是空的；吃过亏的人第一反应是数步数。及格线是能说出「相乘不是平均」并现场算一个数；优秀线是能主动说出「所以我的第一优先级是减步骤而不是提单步」，并解释为什么——因为把一步从九成提到九成五要花的力气，常常比直接合并掉一步大十倍。我第一次答这题的时候说「我们每一步都做了容错」，面试官笑了一下问「那你整条链的成功率是多少」，我答不上来，因为我从来没乘过。那一刻我才明白，**没算过乘积的人，等于没设计过这个功能。**

③ 完整原理拆解（四层，每层配个比方 + 翻车案例）：

第一层：先数步数，步数本身就是风险量级。很多人做多步骤功能时，脑子里的链路和实际链路差着好几步。我做投投的自动打招呼链路，最早心里数是四步：搜岗位、筛岗位、写开场白、点发送。真正画出来是九步：打开页面、填搜索词、选城市、点搜索、翻列表、点进详情、读 JD、生成开场白、点发送。多出来的五步全是「点按钮」，没有智力含量，所以我在脑子里自动忽略了它们——可乘法不会忽略。九步哪怕每步九成五，乘完是六成三。比方是施工工序清单，你以为种一棵树是「挖坑、放树、填土」三步，实际验收工序是九道，包括定位放线、土球包扎检查、支撑架设、浇定根水，每一道都能出问题，而设计师在图上只画了一个圆圈。翻车案例是我按四步估的成功率八成五去承诺，实际跑出来是六成出头，差了二十多个点，就因为我把五个「不算数」的步骤没数进去。

第二层：乘法里最小的因子决定上限，先修最短的那块板。假设一条链有五步，四步都是九成八，一步是七成，乘完是六成五。你把那四步再优化到九成九，总数只涨到六成七；你把那一步从七成提到九成，总数直接跳到八成五。这个对比很粗暴，但它是多步骤优化里最省力的判断：**先找最低的那一步，其他的先别碰。**难点在于很多团队根本不知道哪一步最低，因为他们只有整体成功率没有分步埋点。所以这一层的实际动作是：每一步都要单独记一个成功率，不记就等于闭着眼睛优化。比方是养护里的短板，浇水、修剪、施肥都做得很好，但排水做得差，一场大雨全烂根，你再怎么加强修剪也救不回来。翻车案例是我花了两周把开场白生成的质量从九成提到九成四，结果整体回复链路的成功率一动不动——因为真正拖后腿的是「点进详情页」那一步，页面加载超时的比例高达两成六，而我完全没往那看。

第三层：加检查点，让错误在当步暴露而不是往下传。错误累积还有一个更隐蔽的形态：不是某一步失败了，而是某一步输出了错的东西，但没报错，然后后面每一步都在这个错的基础上继续做。这叫上游错误放大，它比直接失败更贵，因为你要到最后一步才发现，而前面所有算力和时间全白花。对策是在关键步骤之后加一道轻量校验——不要求多聪明，只要求能拦住明显不对的东西。比如简历解析完之后校验一次「工作年限是不是在零到四十之间」「城市是不是在城市表里」，两条规则就能挡掉大部分离谱结果。比方是驻场验收里的隐蔽工程验收，回填之前必须验一次管线，一旦土回填上去，再发现问题就要重新开挖，成本翻好几倍。翻车案例是投投早期简历解析把「三年景观设计经验」抽成了「三十年」，后面的岗位匹配就全按三十年经验去找，推给我一堆总监岗，我盯着结果看了两天才反应过来是最上游那一个数字错了。

第四层：把「不确定的步」和「确定的步」分开算。多步骤链路里，其实有两类完全不同的步骤。一类是确定性步骤，比如点按钮、填表单、发请求，它们的失败是环境性的（超时、改版、网络），成功率通常很高但会突然塌方。另一类是不确定性步骤，比如模型判断、模型生成，它们的失败是概率性的，成功率天然就低一些，而且没法通过重试变好——同样的输入重试三次，模型很可能给出三次同样水平的结果。这两类必须分开对待：确定性步骤的对策是重试和降级，不确定性步骤的对策是收窄输入、拆小任务、加校验。混在一起谈会得出错误结论，比如「加重试就能提高成功率」——对确定性步骤成立，对不确定性步骤基本无效。比方是苗木死亡的两种原因，一种是运输途中磕坏了（换一批就好），一种是这个品种本身就不适应这个气候（换多少批都一样）。翻车案例是我们给模型判断这一步加了三次重试，成本涨了两倍多，成功率只涨了不到一个点。

③·补充：一张现成的链路成功率表（面试时可以说「我有模板」）：五列就够。第一列步骤名，第二列这一步是确定性还是不确定性，第三列当前成功率（有埋点填实测，没埋点填估计并标注是估的），第四列失败之后的处置（重试／降级／中断并告诉用户），第五列这一步能不能砍或能不能和上一步合并。表底下写两个数：当前乘积，和「砍掉可砍步骤之后的乘积」。这张表最有价值的其实是第五列和表底那两个数的对比——它常常会让人发现，砍掉两个看似无关紧要的步骤，比接下来一个月的优化都管用。

③·实战：那个六成三的下午（小说式，闭上眼能看见）：那天下午我把整条自动打招呼链路画在了白板上，一开始只画了四个方框，画得挺自信。苏姐走过来，什么也没说，拿笔在我第一个方框和第二个方框之间点了一下，问我：「从这里到这里，中间用户的浏览器要做几件事？」我愣了一下，开始补：打开页面、填框、选城市、点搜索。她又在第三和第四个框之间点了一下，我又补了两个。白板上从四个框变成九个框，我的手心开始出汗。她让我在每个框下面写一个数，我写不出来，因为我只有整条链的成功率，没有分步的。最后我们只能凭日志估，估出来九步的乘积是六成三。她把笔放下说了一句我到现在还记得的话：「你刚才是打算按八成五去写周报的。」我确实是。那天我做的第一件事不是优化任何一步，而是把「选城市」和「填搜索词」合并成了一次表单提交，把两步变成一步——只这一个动作，乘积回到了六成八。

④ 对比展开：减步骤 vs 提单步 vs 加兜底（面试必考的对比题）：这三个动作经常被混着说，但它们的性价比差得很远。减步骤是乘法里去掉一个因子，收益最直接，代价是产品形态可能要改（比如把两个页面合成一个），所以它是产品经理的活，研发替你做不了。提单步是把某个因子变大，收益取决于那一步原来有多低，修最低的那步性价比极高、修已经很高的那步基本是浪费，所以它必须建立在分步数据之上。加兜底不改变任何一个因子，它改变的是失败之后用户的感受——链路照样断，但用户拿到的是一个可用的次优结果而不是一个错误页。三者的正确顺序是：先减、再修最低那步、最后加兜底。很多团队反着来，一上来就做兜底，做到最后整条链还是六成，只是失败的时候长得好看一点。

⑤ 三个具体例子（每个你都能想象出来）：

例子一：自动投递。九步链路，每步看起来都不低，乘完六成三。砍掉两步合并、修好加载超时最严重的那一步之后到了八成一。这里最反直觉的是：整个过程我没有换模型、没有改提示词，纯粹是数了步数和修了最低那块板。

例子二：文档解析加摘要。四步：上传、识别、切分、生成。识别九成五、切分九成、生成九成二、导出九成八，乘完七成七。团队一直在调生成的提示词，因为那一步「看得见」，但真正的短板是切分——切错了段落，后面生成得再好也是错的。分步埋点上线的第二天，这件事就清楚了。

例子三：多轮客服转人工。六步，其中「识别用户意图」是不确定性步骤，成功率八成八，其余五步都在九成八以上。加了两次重试之后意图识别只涨了零点几个点，因为模型对同一句话的判断是稳定的，重试重的是同一个错。后来改成「置信度低于阈值就直接问一句澄清问题」，成功率上到九成四——**这一步的解药不是重试，是补信息。**

⑥ 常见误区（三个坑，踩一个就白算）：

坑一：把相乘当成平均。嘴上说着「每步都还不错」，心里默认整体也不错。破法很机械但有效：任何多步骤方案，在文档里必须有一行写明步数和乘积，写不出来就是没设计完。

坑二：只有整体成功率，没有分步成功率。这种情况下所有优化都是撞运气，因为你不知道最小的因子在哪。分步埋点的成本远比大家想的低，通常就是每一步前后各打一个点，两天能上线，却能省掉好几个月的瞎优化。

坑三：把所有步骤当成一类，统一上重试。重试对超时、抖动这类确定性失败很有效，对模型判断错误几乎无效，还会成倍抬高成本和延迟。区分标准很简单：**同样的输入再跑一次，结果会不一样吗？**会，就值得重试；不会，就别浪费钱。

⑥·补充：什么时候不该硬追乘积（面试里说这个会显得你更专业）：有两种情况不该死磕整体成功率。第一种是步骤之间存在人工确认点，比如用户要在中间点一次「确认」，那么这个确认点天然把链路切成了两段，两段各自算成功率比算整条更有意义，因为用户在这里退出往往不是失败而是他改主意了。第二种是「失败成本极低且可以立刻重来」的场景，比如生成头像，用户不满意点一下换一张，这时候把力气花在提高单次成功率上，不如花在把重来的动作做得更顺手上。能主动说出这两条，说明你不是在背公式，是真的在权衡。

⑦ 第一人称面试回答（可直接背）：「我分三点。第一，我会先把链路完整画出来数步数，因为脑子里的链路总比实际短——我自己那条自动打招呼的链，我以为四步，画出来九步，多出来的五步全是点按钮，没智力含量所以我下意识不算它们，但乘法算。第二，我会给每一步单独埋点拿到分步成功率，然后先修最小的那个因子。我有过一次教训，花两周把生成质量从九成提到九成四，整体一动没动，因为真正的短板是详情页加载超时，两成六的失败率我压根没往那看。第三，我会把步骤分成确定性和不确定性两类分开治：确定性的靠重试和降级，不确定性的靠收窄输入和加校验点，因为模型对同一个输入重试三次，多半给你三次同样的错。最后我一般会补一句：在这类功能上，砍掉一步的收益，通常比把一步从九成提到九成五要大得多，而砍步骤是产品的活。」

⑦·补充：这道题怎么学（按顺序做，做完你就会了）：第一步，找一个你天天用的功能，把它的步骤写出来，写完之后强迫自己再补三步——一定补得出来。第二步，给每一步拍一个成功率，拍完乘一遍，感受一下那个数字比你的直觉低多少。第三步，圈出最低的那一步，写一句「如果只能改这一步，我改什么」。第四步，回头看看有没有两步可以合并。这四步做完一次，这个概念就长在你身上了，不用背。

⑧ 小结 + 记忆口诀：口诀是「**数步、相乘、修最短、砍一步**」。数步是把隐形步骤揪出来，相乘是把幻觉打掉，修最短是把力气花在最小的因子上，砍一步是性价比最高的那个动作。四个词的顺序不能乱，因为不数步就不知道乘什么，不乘就不知道谁最短，不知道谁最短就会瞎优化。

⑧·四层速记卡（面试前五分钟扫一眼）：第一层数步数——脑子里的链路总比实际短，隐形的点按钮步骤是主要漏项。第二层修最小因子——四步九成八加一步七成，修那个七成收益是其他的十倍。第三层加检查点——上游错了不报错最贵，两条硬规则就能挡住大半。第四层分两类——确定性靠重试降级，不确定性靠收窄和校验，混着治必然浪费钱。

⑨ 这道题会怎么被追问（三轮追问全给你，背下来）：

追问一（挑战型）：「各步骤之间不是独立事件，直接相乘不严谨吧？」这个追问是懂行的人才会问的，答对了加分很多。我的答法是：确实不严谨，真实链路里步骤之间是有相关性的，比如页面加载慢的时候，后面几步的超时概率会一起上升，所以实际成功率通常比乘积还要低一点，而不是高。所以我把乘积当成一个**乐观上界**来用——它的价值不在于精确，在于它足够快、足够早地告诉我「这个方案的天花板在哪」。真要精确，就得靠实测的端到端成功率，那是上线之后的事，而乘积是设计阶段就能算的。

追问二（边界型）：「那是不是步骤越少越好，一步搞定最好？」不是。把多步压成一步，往往是把复杂度塞进了那一步内部，表面上乘积变好看了，实际上那一步的成功率会掉，而且失败之后你完全不知道错在哪，可观测性归零。我的判断标准是：**合并的前提是这两步共享同一个失败原因。**填搜索词和选城市可以合，因为它们一起失败一起成功；读 JD 和生成开场白不能合，因为它们的失败原因完全不同，合了就没法定位。

追问三（反转型）：「如果算出来乘积只有五成，这个功能是不是就不该做？」不一定，要看失败之后发生什么。如果失败意味着用户白等三十秒然后看到一个错误页，那五成确实不该上。但如果失败之后能自动降级成一个次优但可用的结果——比如自动生成失败就退回模板加一句手填提示——那么用户感知到的可用率可能是九成，五成的技术成功率是可以接受的。所以我会把「技术成功率」和「用户可用率」分开报，前者决定我下一步修哪里，后者决定这功能能不能上。

⑩ 进阶：三个加分点（面试说出来就是高手）：

加分点一：把步数写进需求文档的验收标准。需求文档里加一行「本功能链路不超过 N 步，超过需评审」，这一行会逼着所有人在设计阶段就控制复杂度，比事后优化便宜得多。

加分点二：给每一步标注「失败可见性」。不只记成功率，还记「这一步失败的时候用户看得见吗」。看不见的失败最危险，因为它会一路带到最后。把不可见的失败挑出来单独加校验，是性价比最高的动作之一。

加分点三：用乘积做排期沟通。跟研发和老板争「这个月做哪个」的时候，把两个方案的乘积算出来摆在一起，比任何形容词都有说服力。我用这一招把一个原本排在下个季度的合并需求提到了当周。

⑪ 现场话术库（真实场景里怎么开口，照抄就行）：研发说「每一步我们都测过，没问题」，你可以说：「单步我信，我想看的是乘完的数，我们一起把步数数一遍？」老板说「这个功能怎么老出问题」，你可以说：「它是九步链路，乘下来天花板就是六成三，我这周先砍两步，下周修最低的那一步。」需求评审时有人加了一个步骤，你可以说：「加这一步的话乘积从八成一掉到七成七，我们确认一下这一步值不值这四个点。」跟用户解释的时候，你可以说：「这个流程环节比较多，我们正在把中间两步合并，合并之后成功率会明显好转。」这几句的共同点是：**都带着一个具体的数，而不是一个态度。**

⑫ 小白最容易问的四个问题（这本书的读者肯定也想问）：

问一：「我不会算概率，这题能答吗？」能。这道题需要的全部数学就是连乘，手机计算器按几下就行。真正被考的是「你有没有想到要乘」，而不是你乘得多快。

问二：「我没有真实的分步数据，面试说的数会不会像编的？」把数说成区间和关系就不像编的，比如「详情页那一步的失败率明显高于其他步，大概两成多」，比「26.3%」可信得多。露馅的从来不是数字粗，是精确到小数点却讲不出来源。

问三：「步骤是我自己划的，划粗划细结果不一样怎么办？」用一个统一标准：**能单独失败、且失败原因和相邻步骤不同的，才算一步。**按这个标准划，两个人划出来的步数不会差太多，也正好对应了后面能不能合并的判断。

问四：「这个概念只在 AI 产品里有用吗？」不是，任何多环节流程都适用，注册流程、报销流程、下单流程都是。它在 AI 产品里特别突出，只是因为 Agent 天然步骤多，而且其中掺着一类没法靠重试解决的不确定性步骤。

⑬ 没人告诉你的事：第一，这道题真正的分水岭是「你数出来几步」，答四步的人和答九步的人，面试官立刻能分辨谁真做过。第二，绝大多数人会答「提高每一步的可靠性」，而「砍掉一步」这个答案不到两成人说得出来，但它恰恰是产品经理独有的杠杆，研发替你砍不了。第三，隐形步骤几乎全是「点按钮、填框、等加载」这类没有智力含量的动作，正因为没含量，所有人都在心里把它们免票放行了。第四，重试对不确定性步骤基本无效这件事，说出来会让面试官眼前一亮，因为很多做过一两年的人也还在给模型调用加三次重试。第五，也是最实用的一条：把「本功能几步、乘积多少」写进需求文档的第一页，是我做过的所有文档改动里，争议最少、收益最大的一个。

⑭ 做一件事：今天挑一个你自己天天用的功能，把它的步骤从头到尾写下来，写完之后逼自己再补三步——那三步一定存在，多半是「等加载」「点确认」「选一个下拉」。然后给每一步拍个成功率，用计算器乘一遍，把那个乘积和你原来的直觉写在一起对比。最后圈出最小的那个因子，写一句「如果只能改这一步，我改什么」。整件事二十分钟，产出是一行数字加一句判断，它比任何形容词都值钱，因为面试时你可以直接把它讲出来。

⑮ 求职助手联系：「我是你转行路上的求职助手。这件事我自己就是活教材：我从打开页面到发出第一句话，中间有九步，不是四步。你以前看到我卡住，只会觉得『这个东西怎么又不行了』，其实每次卡的位置都不一样。现在我把这九步单独记了成功率，每周看一次谁最低。上一次最低的是点进详情页那一步，两成六超时，我把它的等待时间放宽并加了一次重试，整条链一下好了不少。我还把填搜索词和选城市合成了一步，少一步就少乘一个数。你能感觉到的变化是，我现在失败的时候会告诉你『我卡在第几步、为什么』，而不是只给你一个转圈的图标。下一步你可以接着刷『容错设计』和『重试机制』这两题，它们和这题是同一条链上的三颗扣子；也可以把你刚才数出来的那条链发我，我们一起看哪一步能砍。」

⑯ 练习：今晚做三个练习。练习一，不看稿子在三十秒内说完：为什么是相乘不是平均、九步九成五乘完是多少、你的第一优先动作是什么，卡壳就重来，直到连续两次流畅。练习二，给你选的那个功能列出全部步骤并算出乘积，然后写出「砍掉哪一步之后乘积变成多少」，两个数摆在一起。练习三，回答追问「步骤之间不独立，相乘不严谨吧」，你的答案里必须出现「乐观上界」「相关性会让实际更低」「设计阶段就能算」这三个意思。三题全过，这一题通关。

容错设计

① 一句话大白话定义：容错设计要回答的问题只有一句：**这个功能出错的那一秒，用户看见的是什么、手里还剩下什么、下一步能干什么。**注意它管的不是「怎么少出错」，那是可靠性的事；容错管的是「出错已经发生之后」。它由三样东西组成，缺一样都算没做。第一样是有没有替代结果——彻底空手，还是给一个次优但能用的东西。第二样是话说得对不对——用户看到的那句提示，是让他知道该干嘛，还是让他更慌。第三样是他的活儿有没有白干——填了五分钟的表还在不在，重来一次要从第几步开始。三样凑齐才叫容错，只做第一样叫兜底，只做第二样叫文案，**而只把错误码原样弹给用户的，叫把锅甩给用户。**

①·再打个比方（把定义钉进脑子）：这就像餐厅里菜卖完了。差的做法是上菜前十分钟走过来说一句「这个没有了」，然后转身走掉，客人坐在那儿一脸茫然，点单重来。好的做法是点单的时候就告诉你，并且顺手说一句「今天这道跟它口味最接近，要不要试试」，你原来点的其他菜一道都不用重点。同样是缺货这件事本身没变，客人的体验能差出十万八千里。我做景观的时候有一模一样的经验：某个规格的苗子调不到货，这事无法避免，但你是在种植前一天通知业主并同时带三个替代品种的照片过去，还是等到栽种当天让工人在坑边站着等——业主对你这家公司的评价，完全由后面这半句决定，跟缺货本身关系不大。

①·一句话版本（30 秒电梯版）：「我把容错拆成三件事来做。第一，有没有可用的次优结果，也就是降级路径——AI 写不出来，是给一个模板加提示，还是干脆空着。第二，提示话术，用户看到的必须是他能采取行动的一句人话，包含出了什么事、我们做了什么、他现在能干什么，不出现错误码、不出现『系统繁忙』。第三，状态保留，用户已经输入的、已经选的、已经走过的步骤必须留住，重来的时候不能从第一步开始。我判断一个功能的容错做没做好，就看一件事：出错之后用户是能继续往前走，还是只能退出去重来。」

② 为什么学 / 面试为什么考：这题是 AI 产品岗特别爱问的，因为 AI 功能天生就是会出错的——模型有概率答不好、外部页面会改版、超时是常态。传统软件可以追求「不出错」，AI 产品必须承认「一定会出错」，所以容错不是补丁，是设计的一部分。面试官通过这题看你是不是还停留在「我们会尽量保证质量」的阶段。及格线是能说出降级和提示两层；优秀线是能补上状态保留，并且主动说明「哪些错我故意不兜底、直接让它失败」——因为无差别兜底会掩盖问题，让你永远不知道真实的失败率。我第一次答这题只说了「我们会给友好提示」，追问「友好提示具体写什么」，我说「请稍后重试」，对方问「用户稍后重试还是失败呢」——我答不上来。那句话之所以差，是因为**它把责任推给了用户，还没提供任何新信息。**

③ 完整原理拆解（四层，每层配个比方 + 翻车案例）：

第一层：先分类，不是所有错都该同一种兜法。容错设计的第一个动作不是写文案，是把可能出的错分成三类。第一类是可自愈的，比如超时、网络抖动、限流，特征是同样的输入过一会儿再试很可能就好了，对策是静默重试，用户最好完全不知道发生过。第二类是可降级的，比如模型生成质量不达标、某个数据源拿不到，特征是主路径断了但存在次优路径，对策是给次优结果并明确告诉用户这是次优的。第三类是必须中断的，比如用户没登录、余额不足、内容触犯了安全策略，特征是继续下去只会造成更大的伤害，对策是干净利落地停下并说清楚原因。这三类的处理方式完全相反，混着做必然出乱子。比方是工地上的三种异常：材料迟到（等一等就来）、规格不符（能不能用替代品）、图纸有硬伤（必须停工找设计），项目经理绝不会用同一套流程处理这三件事。翻车案例是我们早期把所有错都归到第一类，全部静默重试，结果一个「用户没登录」的错误被重试了三次，用户在那儿等了十几秒才看到「请登录」，白等的每一秒都是纯亏。

第二层：降级要有一条明确的次优路径，不能是空白。降级的本质是**准备好一个更差但能用的东西**。这里最常见的错误是把降级理解成「什么都不给」。以投投的开场白生成为例，正常路径是读 JD、结合我的经历生成一段个性化开场白；降级路径不是「生成失败请重试」，而是给一段结构完整的模板，里面把该我填的地方留成空、并且明确标出来，比如「您好，看到贵司在招 AI 产品岗，我做过（此处填一个你最想让对方看到的项目），想和您聊聊」。用户拿到这个，五秒钟能改完发出去，而不是回到起点。降级的两条硬规则：**次优结果必须标注它是次优的**，不能伪装成正常结果骗用户；**次优结果必须真的能用**，不是给个占位符敷衍。比方是效果图渲染跑不出来，你不能交白纸，但你可以交一张手绘的意向图并说明这是意向图——业主接受，因为他知道这是什么。翻车案例是我们有一版降级悄悄给了模板但没标注，用户以为是 AI 生成的个性化内容直接发出去了，同一家公司的 HR 收到三个人一模一样的开场白，这比不生成还糟。

第三层：提示话术要包含三件事，且不出现技术词。一句合格的错误提示必须回答三个问题：出了什么事（用用户能懂的话）、我们已经做了什么、你现在能做什么。三个都答到，长度通常在两行以内。反例是「系统繁忙，请稍后重试」——三个问题一个都没答，用户不知道是什么繁忙、不知道有没有人在处理、也不知道稍后是多久。正例是「岗位页面加载超时了，我已经自动重试过两次。你可以先看看已经匹配好的 12 个岗位，剩下的我会在后台继续加载」。这句话把用户从「等待」的状态里拉出来了，给了他一件当下就能做的事。绝对不能出现在提示里的：错误码、接口名、模型名、「参数异常」「服务不可用」这类词。比方是驻场时跟业主解释延期，你不会说「土方外运受属地渣土审批影响」，你会说「土运不出去，我今天下午去办手续，最迟后天恢复，其余区域照常施工不影响」。翻车案例是我们把后端返回的原始错误信息直接透给了用户，屏幕上出现一行英文加一串数字，客服那天接到的咨询量涨了三倍多。

第四层：状态保留是容错里最贵也最容易漏的一环。前三层做得再好，只要用户一重来就得从头填，前面的功夫全归零。状态保留要保三样：用户已经输入的内容（表单、上传的文件、编辑到一半的文字）、用户已经做出的选择（勾选的岗位、设置的偏好）、流程已经走到的位置（第几步、哪些已完成）。做法上并不复杂，本地暂存加一个恢复入口就能覆盖绝大多数场景，关键是要把它当成需求写进文档，而不是等出事再补。判断标准很直白：**重来一次，用户需要重新操作几下？**这个数字应该是零或一。比方是竖向图改了三版没保存，机器一崩全没了，那种绝望跟功能本身好不好完全无关。翻车案例是我们的简历上传加信息确认页，用户填完六个字段之后网络断了，回来一片空白，那一周的流失几乎全堆在那一页上，而我们一开始还以为是页面设计有问题。

③·补充：一张现成的容错设计表（面试时可以说「我有模板」）：五列。第一列错误场景，写具体，不写「异常」。第二列分类，自愈／降级／中断三选一。第三列用户看见什么，直接把那句提示文案写在这里，写不出来就是没想清楚。第四列次优结果是什么，中断类填「无」。第五列保留哪些状态。表格填满通常八到十二行就够覆盖一个功能的绝大多数情况。这张表最大的价值是第三列——**把文案逼到设计阶段写，而不是上线前一天让研发随手编一句。**

③·实战：那三个一模一样的开场白（小说式，闭上眼能看见）：那天下午有个用户在群里发了张截图，是他和 HR 的聊天记录，HR 回了一句「你是第三个发这段话给我的」。我点开一看，那正是我们的降级模板，一字不差。我当时第一反应是去查生成服务的日志，发现那天下午模型那一路超时率飙到了三成多，于是三成多的用户全走了降级，全都拿到同一段模板，而模板上没有任何标注，用户以为是给自己写的，直接就发了。我把这事拿给苏姐看，她看完只问了我一句：「你写降级的时候，想过用户会不会知道自己拿到的是降级吗？」我没想过。我们那天晚上做了两个改动：模板里必须留一个显眼的空格并配一句「这一句我没法替你写，你自己填一行更管用」，以及降级结果的右上角加一个小标签写着「简版」。改完之后，同样是走降级，用户投诉几乎归零——**因为他知道自己拿到的是什么，就不会拿它当成不该有的东西。**

④ 对比展开：自愈 vs 降级 vs 中断（面试必考的对比题）：这三者的区别不在技术，在「用户该不该知道」。自愈的原则是用户最好不知道，因为告诉他一个已经被解决的问题，只会制造焦虑；所以静默重试不该弹提示，最多在完成后不显眼地说明一句「加载慢了一点」。降级的原则是用户必须知道，而且必须知道差在哪，否则他会把次优结果当正常结果用，造成二次伤害。中断的原则是用户必须知道原因和出路，光说不行不行——「无法完成」和「因为没登录所以无法完成，点这里登录」，是两个产品。判断一个错该归哪一类，问两个问题就够：再试一次有没有可能成功、有没有一个更差但能用的东西。第一个问题答是，归自愈；第一个否第二个是，归降级；两个都否，归中断。

⑤ 三个具体例子（每个你都能想象出来）：

例子一：自动打招呼。页面改版导致找不到发送按钮，这属于中断类——重试无用、没有次优路径。正确做法是立刻停下，把已经写好的开场白完整地留在剪贴板并告诉用户「这个网站的页面变了，我暂时点不了发送。开场白我已经写好放在这里，你复制过去手动发一下，我这两天修好」。用户损失的只是一次点击。

例子二：简历解析。PDF 是扫描件识别不出来，这属于降级类。次优路径是给一个空白但结构完整的表单，把能猜到的字段先填上并标灰，让用户改而不是从零填。这里的关键是「标灰」——**让用户一眼看出哪些是我猜的、哪些是他填的。**

例子三：岗位列表加载。翻到第三页超时，这属于自愈类。静默重试两次，成功了用户完全无感；两次都失败就转成降级，把已经拿到的两页结果先给用户看，并在底部放一行「后面的还在加载」。最差的做法是整页白屏，把前两页已经拿到的结果也一起丢掉——**已经拿到手的东西绝对不能因为后面失败而丢掉，这是容错里的一条铁律。**

⑥ 常见误区（三个坑，踩一个就白做）：

坑一：无差别兜底。所有错都给一个次优结果，看起来体验很顺，代价是真实失败率被彻底掩盖，看板上一片祥和，问题在暗处越滚越大。破法是降级必须单独打点，并且在监控里单独看一条降级率曲线。

坑二：提示写成技术语言。「参数错误」「服务不可用」「请求超时」，这些词对用户是零信息量，还带着一股「不是我们的问题」的味道。破法是让一个完全不懂技术的人读一遍你的提示，问他「你现在该干什么」，他答不上来就重写。

坑三：只做提示不做状态保留。话说得再漂亮，用户一刷新前功尽弃，那句漂亮话反而更气人。破法是把「重来需要几步」写成验收标准，超过一步就不算完成。

⑥·补充：什么时候不该做容错（面试里说这个会显得你更专业）：有三种情况我会故意不兜底。第一种是内测阶段，这时候我要的是暴露问题，兜得太好会让团队看不见真实失败率，等到放量才发现来不及。第二种是涉及钱和不可逆操作的场景，比如自动投递到一个用户没确认过的岗位，这种时候宁可失败也不能自作主张给一个「差不多的」结果，**错误的成功比诚实的失败贵得多。**第三种是那种降级结果本身会误导用户的场景，比如给出一个看起来很像真实数据的估算值，用户会当真数用。能主动说出这三条，面试官会觉得你不是在背方法论，是真的做过取舍。

⑦ 第一人称面试回答（可直接背）：「我分三点。第一，我会先给错误分三类：能自愈的静默重试、用户别知道；能降级的给次优结果、但必须明确标注是次优的；必须中断的干净停下、说清原因和出路。分类错了后面全错，比如把『没登录』当成能自愈的去重试，用户就白等十几秒。第二，我会把提示文案在设计阶段就写死，一句话回答三件事：出了什么、我做了什么、你现在能做什么，不出现错误码和技术词。我们出过一次事故，把后端原始报错直接透给用户，那天客服咨询量涨了三倍多。第三，状态保留，用户填过的、选过的、走到第几步都要留住，验收标准是重来一次用户最多再操作一下。最后我会补一句：降级要单独埋点看降级率，不然兜得太好会让所有人看不见真实的失败率——我吃过这个亏，一版降级没标注，三成多的用户拿到同一段模板还以为是给自己写的，直接发给了同一家公司的 HR。」

⑦·补充：这道题怎么学（按顺序做，做完你就会了）：第一步，找一个你常用的 App，故意把网络关掉去用它的核心功能，把你看到的每一句提示原样抄下来。第二步，对着抄下来的句子问三个问题：出了什么事说清了吗、他们做了什么说了吗、我现在能干什么说了吗，大部分句子会一条都答不上。第三步，你自己给它重写一版。第四步，把网络恢复后刷新，看看你刚才填的东西还在不在。这四步做完一轮，容错这件事你就有手感了，不需要背任何框架。

⑧ 小结 + 记忆口诀：口诀是「**先分类、给退路、说人话、留现场**」。分类决定处理方式，退路是次优结果，人话是那句提示，留现场是状态保留。四个词按顺序做，做完一个功能的容错设计通常一个下午就够，比出事之后补要省十倍力气。

⑧·四层速记卡（面试前五分钟扫一眼）：第一层分三类——自愈别打扰、降级要标注、中断给出路，判断只问两句：再试会好吗、有没有更差但能用的。第二层降级——次优结果必须真能用且必须标注，不标注比不降级更糟。第三层话术——出了什么、做了什么、你能做什么，两行以内，零技术词。第四层状态——留输入、留选择、留进度，验收线是重来最多一步。

⑨ 这道题会怎么被追问（三轮追问全给你，背下来）：

追问一（挑战型）：「降级不就是把差的东西给用户吗，这不是自欺欺人？」我的答法是：区别在于有没有标注和有没有用。不标注的降级确实是自欺欺人，因为用户会拿次优结果当正常结果用，出二次伤害；标注了的降级是一次诚实的交易，用户知道自己拿到的是简版，会自己决定是用还是重来。而且降级的替代品不是「更差的结果」，是「用户可以在此基础上快速完成的半成品」——模板留空加一句提示，用户五秒改完，这比让他从零开始好太多。

追问二（边界型）：「如果失败率很低，比如只有百分之一，还值得投入做容错吗？」值得，但投入要分级。百分之一的失败率在日活一万的产品上是每天一百个人，这一百个人恰恰是最容易跑去写差评的那批。不过投入要匹配：这种情况我不会做完整的三层，我会先做最便宜的两件——把提示文案写对，和把状态留住。这两件加起来通常不到一天工时，覆盖了用户感知里的大部分。降级路径可以等失败率上来或者场景变关键时再补。

追问三（反转型）：「容错做得太好，是不是反而会掩盖问题？」会，这也是我坚持给降级单独埋点的原因。我看的不是一条成功率曲线，是两条：真实成功率和含降级的可用率。前者掉了但后者没动，说明我在靠兜底续命，必须去修根因；两条一起掉，说明兜底也不管用了，那是紧急情况。只看一条，无论看哪条都会做出错误判断。

⑩ 进阶：三个加分点（面试说出来就是高手）：

加分点一：把提示文案写进 PRD 而不是留给研发。错误文案是产品的活，交给谁写、写成什么样，直接决定了用户在最糟糕那一刻对你的印象。写进 PRD 的成本几乎为零，但绝大多数需求文档里这一块是空的。

加分点二：给降级结果做视觉区分。一个小标签、一个不同的底色，让用户一眼知道这是简版。这个改动的工作量以小时计，但它能挡掉一整类「用户拿次优结果当正品用」的事故。

加分点三：给中断类错误配一个人工出口。无论多干净的中断，都要留一条「联系我们／手动完成」的路。它的价值不在于多少人会点，而在于用户知道自己不是被扔在那里——**留一条出路，比把提示写得多委婉都管用。**

⑪ 现场话术库（真实场景里怎么开口，照抄就行）：评审时研发说「这个异常很少见，先不处理」，你可以说：「不处理没问题，但请把它归到中断类，给我一句提示文案和一个人工出口，这两样加起来半天。」写文档时你可以直接给出格式：「场景／分类／用户看见的那句话／次优结果／保留哪些状态」，五列填完就是需求。用户投诉时你可以说：「这次是我们的降级路径没标清楚，让你误以为是完整结果，这是我们的问题，我们已经加了标识。」跟老板汇报时你可以说：「真实成功率八成一，加上降级之后用户可用率九成三，中间这十二个点是我下个月要修的根因。」这几句的共同点是：**每一句都把责任留在自己这边，同时给出一个具体的下一步。**

⑫ 小白最容易问的四个问题（这本书的读者肯定也想问）：

问一：「我不懂技术，怎么知道会出哪些错？」不用懂技术，你只需要问研发一句「这个功能最常见的三种失败是什么」，他两分钟就能说完。产品的活是拿到这三种之后决定各归哪一类、用户看见什么，这一步研发替你做不了，也不该他做。

问二：「提示文案有没有能套的模板？」有，三句式：第一句说事实（岗位页面加载超时了），第二句说我们做了什么（我已经自动重试过两次），第三句说你能做什么（你可以先看已匹配的 12 个，剩下的我在后台继续）。套进去改一改就能用，比任何漂亮话都强。

问三：「面试问我做过什么容错，我没有真实项目怎么办？」用你观察到的别人的。找一个你常用的 App，说出它某个错误提示差在哪、你会怎么改、改完用户能多做什么。这展示的是判断力，面试官不会因为你没项目扣分，只会因为你没判断扣分。

问四：「静默重试会不会让用户等更久？」会，所以重试次数和总等待时间必须有上限，通常两次、总共不超过几秒。超过这个上限就该转降级，让用户先拿到点东西——**用户对『等待』的容忍度，远低于对『拿到一个次优结果』的容忍度。**

⑬ 没人告诉你的事：第一，这道题真正拉开差距的是第三层「状态保留」，说降级的人很多，说提示的人也不少，但主动提到「重来需要几步」的不到两成。第二，错误文案是极少数产品经理可以完全掌控、又几乎零成本的东西，写好它的投入产出比高得离谱，可惜大部分 PRD 里这一栏是空的。第三，无差别兜底会毁掉你的监控，这个反直觉的结论说出来会让面试官记住你。第四，降级结果不标注造成的事故，往往比不做降级更严重，因为它把一个技术问题变成了一个信任问题。第五，也是最实用的一条：把「出了什么／做了什么／你能做什么」这三句话打印出来贴在显示器边上，你写的每一句错误提示都会自动比同行好一截。

⑭ 做一件事：今天挑一个你常用的功能，把网络断掉走一遍，把你看到的每一句提示原样记下来。然后对每一句打三个勾：说清发生了什么吗、说了我们做了什么吗、告诉我现在能干什么吗。三个勾都打满的句子极少，你会发现绝大多数只能打零到一个。挑其中最差的那一句，用三句式重写一遍，写完之后把网络恢复、刷新页面，看看你刚才填过的东西还在不在。整件事二十分钟，产出是一句改写后的文案加一个状态保留的结论，面试时这就是一个可以完整讲出来的观察。

⑮ 求职助手联系：「我是你转行路上的求职助手，这题我栽过一个跟头。有一天有三成多的用户拿到了我的降级模板，我没标注，他们以为那是我专门给他写的，直接就发出去了，同一家公司的 HR 收到三条一模一样的话。现在我改了：只要走的是简版，右上角一定有个标签写着『简版』，中间一定留一个空格，配一句『这一句我没法替你写，你自己填一行更管用』。我还把你填过的东西都留住了，网断了回来，你的表单还在原地。你能感觉到的变化是，我卡住的时候会告诉你『我点不了发送，开场白我写好放这儿了，你复制过去手发一下』，而不是给你一个转圈的圈。下一步你可以接着刷『错误累积』和『重试机制』，这三题是同一条链上的三颗扣子；也可以把你见过的最糟糕的一句错误提示发我，我们一起用三句式重写它。」

⑯ 练习：今晚做三个练习。练习一，不看稿子在三十秒内说完：错误分哪三类、判断归类的两个问题是什么、提示文案要回答哪三件事，卡壳就重来，直到连续两次流畅。练习二，给你选的那个功能写一张五列容错表，至少填满八行，第三列必须是完整的一句中文，不许写「给出友好提示」。练习三，回答追问「容错做太好会不会掩盖问题」，你的答案里必须出现「降级单独埋点」「真实成功率和可用率两条线」「一起掉才是紧急情况」这三个意思。三题全过，这一题通关。

重试机制

① 一句话大白话定义：重试机制回答的是一个特别具体的问题：**一次失败之后，要不要再试、试几次、隔多久试、以及什么情况下试了也白试。**它由四个参数构成，少写一个都会出事。第一个是该不该重试，判断标准只有一句话——同样的输入再跑一次，结果有没有可能不一样；有可能才值得试，没可能就是纯烧钱。第二个是次数上限，通常两到三次，写死。第三个是间隔策略，不能立刻连着试，要越等越久，业内叫退避。第四个是总时间上限，无论试了几次，超过这个秒数就必须停下来转降级。四个参数写全了才叫机制，只写「失败了重试一下」的，那不是机制，**那是把用户的时间当成免费的。**

①·再打个比方（把定义钉进脑子）：这就像打电话没人接。占线的时候你会隔一会儿再打，而且第二次会比第一次多等一会儿，因为对面可能正忙；打了三次还没人接，你就该发消息或者换个人问了，而不是站在那儿一直打。但如果你拨的是一个空号，那么你打三十次也是空号——**这时候重试不是耐心，是不懂。**我做景观的时候也有这个对照：混凝土浇筑因为下雨中止，等雨停了重来是对的，那是外部条件变了；但如果是配合比本身算错了，重浇一百次还是同样的强度不达标，得回去改配比。这两件事在现场看起来都是「浇不成」，处理方式却完全相反。

①·一句话版本（30 秒电梯版）：「我看重试只看四个参数。第一，该不该重试，判断标准是同样的输入再跑一次结果会不会不一样——超时、限流、网络抖动会不一样，值得试；模型判断错了不会不一样，试三次是同一个错，纯烧钱。第二，次数上限，我一般写死两次，超过两次的收益迅速趋近于零。第三，间隔要退避，第一次等一秒、第二次等两三秒，还要加一点随机抖动，不然一批用户同时失败会同时重试，把下游再冲垮一次。第四，总时间上限，无论试到第几次，超过大约五秒就转降级，因为用户对等待的容忍度远低于对次优结果的容忍度。这四个不写死，重试就会变成一个偷偷花钱、还偷偷把用户拖住的东西。」

② 为什么学 / 面试为什么考：这题几乎是所有和 Agent、调用、链路相关的岗位都会问到的，它是一道「你有没有真的关心过成本和延迟」的照妖镜。没做过的人会说「失败了我们会自动重试保证成功率」，这句话每个字都对，但没有次数、没有间隔、没有上限、也没有区分哪些错值得试。做过的人第一句往往是「先看这个错重试有没有意义」，因为他被账单或者被投诉教育过。及格线是能说出次数和退避；优秀线是能主动区分「可重试错误」和「不可重试错误」，并给出总时间上限和降级衔接。我第一次答这题说「我们做了三次重试」，追问「那超时的用户等了多久」，我算了一下，三次加起来最长十几秒——**用户在那十几秒里唯一确定的事，是这个产品很慢。**

③ 完整原理拆解（四层，每层配个比方 + 翻车案例）：

第一层：先判断这个错值不值得重试。这是整道题的分水岭，也是最容易被跳过的一步。可重试的错有一个共同特征——失败原因是暂时的、外部的、和输入无关的：超时、限流、连接被重置、下游服务临时不可用、页面还没加载完。不可重试的错也有共同特征——失败原因就长在输入或者规则里：参数不合法、没有权限、余额不足、内容触发了安全策略、模型对这句话的判断本来就是这样。判断方法就一句话：**同样的输入再跑一次，结果会不会不一样。**比方是苗木进场被拒收，如果是因为运输途中土球散了，那换一车来是对的；如果是因为这个规格本来就不符合图纸，来一百车都得拒。翻车案例是我们早期把「用户未登录」也放进了重试队列，三次重试加起来让用户白等了十几秒，最后才看到一句「请登录」，那十几秒是纯粹的损失，而且是我们主动制造的。

第二层：次数和间隔要写死，间隔必须递增并带抖动。次数上限我一般定两次，最多三次。原因很实在：如果一个错第一次和第二次都没好，第三次好的概率已经很低了，而每多一次都要用户多等一段、多花一份钱。间隔不能是固定的，必须递增，业内叫指数退避——第一次等一秒，第二次等两到三秒。原因是失败往往意味着下游正忙，你立刻再冲一次只会让它更忙。除了递增，还要加一点随机抖动，比如在等待时间上随机加减一小段。这一条特别容易被忽略：如果一批用户在同一秒集体失败，而重试间隔是固定的，那他们会在同一秒集体重试，把刚缓过来的下游第二次打趴下，这个现象叫重试风暴。比方是电梯坏了大家一起按呼叫键，越按越乱；错开一点反而快。翻车案例是我们有一次下游限流，两千多个请求同时失败、一秒后同时重试，下游直接被自己人打挂了半分钟，故障时长被我们的重试策略硬生生拉长了三倍。

第三层：总时间上限比次数上限更重要。这一层是产品视角和研发视角最容易分叉的地方。研发习惯管次数，产品必须管总时长，因为用户感知的是秒数不是次数。假设单次调用的超时设成了八秒，重试两次，最糟情况是二十四秒——用户早就走了。所以正确的写法是次数和总时长双重上限，谁先到听谁的。我给投投定的是：总共不超过大约五秒，五秒内能试几次试几次，到点无论试到哪一步都停下转降级。这个数字不是拍的，是从用户行为里反推的——超过这个量级，页面关闭的比例会明显往上走。而且这条上限还要跟前面的容错设计接上：到点之后不能直接报错，要有一个已经准备好的次优结果接住。比方是驻场等甲方确认，你不能无限期等下去，得约定「今天下班前没回复我就按方案 B 施工」，否则整个工期被一个悬而未决的事拖住。翻车案例是我们有一版超时设得很宽加三次重试，最长要等半分钟，那一版的中途放弃率翻了一倍多，而成功率只涨了不到两个点。

第四层：重试必须留痕，而且要单独看一条曲线。这一层决定了重试是帮手还是掩体。重试成功的那些请求，在成功率上是成功的，所以如果不单独记录，你的看板会显示一切正常，实际上下游可能已经病了很久。正确做法是把「重试次数」当成一个独立指标画一条线，看两个东西：重试总量的趋势，以及「重试后仍失败」的占比。重试量突然抬头，往往是下游出问题的最早信号，比成功率下跌要早得多，因为成功率还被重试兜着。另外还要记录每次重试的原因分类，不然你只知道重试变多了，不知道为什么。比方是养护记录里的补植数量，成活率看着还行，但补植量翻了三倍——说明这个地块本身出了问题，只是被反复补植掩盖了。翻车案例是我们有一个月成功率一直很稳，直到某天彻底崩了，回头查日志才发现重试量在崩之前的两周里已经翻了四倍，没有任何人看那条线，因为看板上根本没有那条线。

③·补充：一张现成的重试策略表（面试时可以说「我有模板」）：六列。第一列错误类型，写具体。第二列可否重试，是或否，判断依据写在旁边。第三列最大次数。第四列间隔策略，写清是不是递增、有没有抖动。第五列总时间上限。第六列到点之后接哪一条降级路径。这张表通常十行以内就能覆盖一个功能，填的时候最容易卡住的是第二列——**只要有一行你填不出「为什么可以重试」，那一行八成就不该重试。**

③·实战：被自己人打挂的那半分钟（小说式，闭上眼能看见）：那天上午十点多，投投的批量匹配突然全线报错。我以为是外部服务挂了，去看日志，发现下游确实先限流了，但限流只持续了大概三四秒——真正让故障拖到半分钟的，是我们自己。两千多个请求在同一秒收到限流，我们的重试间隔写死了一秒，于是一秒之后，两千多个请求又在同一秒一起冲了过去。日志上那两个波峰长得一模一样，间隔精确到一秒，像两次心跳。苏姐看了一眼那张图说：「你这不叫重试，叫排队冲锋。」那天下午我们改了两处：间隔改成递增并加随机抖动，以及给重试加了一个总量的闸，同一时刻在途的重试超过一定数量就直接放弃、走降级。第二次遇到同样的限流，故障时长是四秒，就是下游自己恢复的时间，**我们终于没有再给它添乱。**

④ 对比展开：重试 vs 降级 vs 熔断（面试必考的对比题）：这三个词常被混用，其实处理的是三个不同的时间尺度。重试处理的是「这一次」，假设失败是偶然的，代价是延迟和成本，适用于短暂的、外部的故障。降级处理的是「这一次已经没救了」，放弃主路径改走次优路径，代价是结果质量下降，适用于重试到点之后。熔断处理的是「这一段时间都别试了」，当失败率在一个窗口内持续超标，就在一段时间内直接跳过主路径，连试都不试，代价是即使下游已经恢复也要等熔断窗口过去，好处是不给正在恢复的下游添乱、也不让用户白等。三者的正确关系是接力：先重试，重试到点转降级，降级持续发生就触发熔断，熔断期内所有请求直接走降级。**很多团队只做了第一棒，所以下游一病，他们的重试就变成了帮凶。**

⑤ 三个具体例子（每个你都能想象出来）：

例子一：岗位列表加载超时。典型可重试。两次、递增间隔加抖动、总共不超过五秒。重试期间界面不要弹任何提示，用户无感是最好的结果；到点转降级，把已经拿到的部分先展示出来。

例子二：模型生成的开场白质量不达标。典型不可重试。同样的输入喂进去，第二次给出来的还是同一个水平，重试三次就是把钱花三份、把用户多拖十几秒。正确动作是换策略而不是换次数：收窄输入、把任务拆小、或者补一条关键信息进去再跑，比如把 JD 里最相关的那一条单独摘出来。

例子三：点击发送按钮找不到元素。这个要分两种情况，非常典型。如果是页面还没加载完，那属于可重试，等一等再找就有了；如果是网站改版把按钮换了位置，那属于不可重试，找一万次也找不到。区分办法是给重试加一个前提检查——先确认页面已经加载完成，加载完了还找不到，就直接判定为改版，停止重试并触发告警。**这个小小的前置判断，把一类会无限空转的重试挡在了门外。**

⑥ 常见误区（三个坑，踩一个就白试）：

坑一：对所有错一视同仁地重试。最常见也最贵的坑，把不可重试的错反复试，钱和时间双份浪费，用户还看不到任何进展。破法是在代码合入之前先填那张表的第二列，填不出理由的一律不许重试。

坑二：固定间隔、没有抖动。平时看不出问题，一旦发生批量失败就会制造重试风暴，把一个几秒的故障拉成几十秒。破法是把「递增加抖动」写成默认，需要固定间隔的反而要额外说明理由。

坑三：只管次数不管总时长。研发按次数配，产品从来没算过总秒数，结果用户最长要等二十多秒。破法是在需求里直接写「本功能失败到降级之间，用户最长等待不超过几秒」，让这个数字成为验收项。

⑥·补充：什么时候不该重试（面试里说这个会显得你更专业）：有三类情况我会直接把重试关掉。第一类是非幂等操作，也就是重复做一次会产生真实后果的动作，比如已经发出去的打招呼、已经提交的订单——超时不代表没成功，很可能是成功了但回执丢了，这时候重试会造成重复发送，用户那边就是同一句话发了两遍。第二类是明确的业务规则拒绝，比如权限不足、超出配额，重试只会让日志更脏。第三类是成本极高的调用，比如一次很贵的长文本生成，这种我宁可失败也不重试，改成让用户主动点一下「再试一次」，把决定权交回去。能主动说出第一类的人不多，说出来面试官会立刻上调对你的评价，因为**幂等性是一道分水岭，它区分了「看过教程」和「上过线」。**

⑦ 第一人称面试回答（可直接背）：「我分三点。第一，先判断这个错值不值得重试，标准是同样的输入再跑一次结果会不会不一样——超时、限流、页面没加载完，会不一样，值得试；模型判断错、参数不合法、没权限，不会不一样，试是白试。我们早期把『未登录』也放进了重试，用户白等十几秒才看到一句请登录。第二，参数写死：次数最多两次，间隔递增并带随机抖动，还有一个总时间上限，我定的是大约五秒，到点无论试到第几次都转降级。抖动这条是被打出来的——有一次两千多个请求同一秒失败、一秒后同一秒重试，把正在恢复的下游又打趴了半分钟。第三，重试必须单独画一条曲线，因为重试成功的请求在成功率上是成功的，不单独看你会以为一切正常。我们有一个月成功率很稳，崩之前两周重试量已经翻了四倍，没人发现，因为看板上没有那条线。另外我会主动关掉两类重试：非幂等操作，超时不代表没成功，重试会重复发送；还有非常贵的调用，我宁可让用户自己点一下再试一次。」

⑦·补充：这道题怎么学（按顺序做，做完你就会了）：第一步，列出你熟悉的一个功能可能出的五种错，逐个问「同样输入再跑一次结果会不会不一样」，把它们分成两堆。第二步，给可重试的那堆各写一组参数：次数、间隔、总上限。第三步，找出其中的非幂等操作，把它们从可重试那堆里挑出来单独处理。第四步，画一下最糟情况的时间线，从第一次失败到用户看到结果一共多少秒，如果这个数字超过五六秒，回去改参数。四步做完一轮，你对重试的手感就建立起来了。

⑧ 小结 + 记忆口诀：口诀是「**该不该、几次、多久、留痕**」。该不该是判断错误类型，几次是次数上限，多久是间隔递增加总时长封顶，留痕是把重试量单独画一条线。四个词的顺序不能乱：不判断类型就会白试，不封总时长就会拖死用户，不留痕就会被自己的兜底骗过去。

⑧·四层速记卡（面试前五分钟扫一眼）：第一层判类型——同样输入再跑一次结果会不会不一样，会才试。第二层定参数——两次上限、间隔递增、必须带抖动，否则会有重试风暴。第三层封总时长——次数和秒数双上限、谁先到听谁的，到点接降级。第四层看曲线——重试量单独一条线，它抬头比成功率下跌早得多。附加一条：非幂等操作一律不重试。

⑨ 这道题会怎么被追问（三轮追问全给你，背下来）：

追问一（挑战型）：「你说两次上限，为什么不是三次五次，这个数是拍的吗？」不是拍的，但也不需要精确。我的依据有两条：一是实测的边际收益，第一次重试通常能救回大部分可救的，第二次救回的明显变少，第三次基本贴着零，把这三个数拉出来看一眼就清楚了；二是总时长倒推，如果单次超时设的是两秒左右，那么五秒的总上限最多也就容得下两次。所以真正被写死的其实是总时长，次数是被它推出来的。

追问二（边界型）：「如果下游一直不稳定，重试就一直在跑，这不是恶性循环吗？」是，所以重试上面还要有一层熔断。当一个窗口内的失败率持续超标，就在接下来一段时间里直接跳过主路径、所有请求走降级，连试都不试。这样做有两个好处：不给正在恢复的下游继续加压，以及不让用户为一个必然失败的调用白等。熔断窗口过去之后放一小部分流量试探，成了再逐步恢复。

追问三（反转型）：「重试提高了成功率，这不是好事吗，为什么你还要单独看它？」因为它提高的是「看得见的成功率」，掩盖的是「下游的真实健康度」。我要的是两条线：不含重试的一次成功率，和含重试的最终成功率。两条线之间的缝隙就是我在靠重试续命的程度，缝隙持续变宽就是预警信号。只看最终成功率，你会在崩溃当天才知道出事；看缝隙，你能提前两周知道。

⑩ 进阶：三个加分点（面试说出来就是高手）：

加分点一：给重试加一个前置条件检查。比如找不到按钮时先确认页面是否加载完成，加载完了还找不到就判定为改版并停止重试。这个小判断能把一整类无限空转的重试挡在门外。

加分点二：给在途重试设一个总量闸。不只限制单个请求试几次，还限制同一时刻全系统在途的重试有多少个，超过就直接走降级。这一条是重试风暴最直接的解药。

加分点三：把重试成本折算成钱说给老板听。「每次多重试一轮，每月多花的钱大概是多少、换回来的成功率是零点几个点」，用这个对比去砍掉那些没意义的重试，比讲任何架构原理都有效。

⑪ 现场话术库（真实场景里怎么开口，照抄就行）：研发说「失败了我们会自动重试」，你可以问：「重试几次、间隔多少、最长会让用户等多少秒？」评审时你可以说：「这一类错我建议不重试，因为同样的输入再跑一次还是同一个结果，我们改成收窄输入再跑。」出故障复盘时你可以说：「下游只病了四秒，我们的重试把它拖成了半分钟，这一条我认，间隔改成递增加抖动。」跟老板汇报时你可以说：「成功率九成一，但里面有一成是靠重试救回来的，这个缝隙上个月还只有百分之三，我这周去查下游。」这几句的共同点是：**都在把一个模糊的动词，追问成一组具体的数字。**

⑫ 小白最容易问的四个问题（这本书的读者肯定也想问）：

问一：「重试是研发的事，产品为什么要管？」因为四个参数里有三个是产品决定的：哪些错值得试（涉及业务判断）、用户最长能等几秒（涉及体验）、到点之后给什么（涉及降级路径）。研发能决定的其实只有实现方式。

问二：「幂等这个词太技术了，我该怎么理解？」就一句话：**同一个动作做两遍，结果和做一遍一样吗？**查询做两遍还是那个结果，安全；发消息做两遍就发出去两条，不安全。不安全的那些，超时之后宁可当失败处理，也不能自动再来一次。

问三：「抖动听起来很玄，到底是什么？」就是在等待时间上随机加减一点，让本来会挤在同一秒的重试散开。实现上就是一行随机数，但它是重试风暴唯一有效的解药，性价比高得离谱。

问四：「我面试的时候没有真实数据，讲重试会不会显得空？」不会，只要你讲的是判断而不是配置。说「这类错我不会重试，因为同样输入结果不会变」，比说「我们配了三次重试」有价值得多——**面试官在意的是你有没有做过取舍，不是你记不记得参数。**

⑬ 没人告诉你的事：第一，这道题的分水岭是「不可重试」四个字，会主动说哪些错不该重试的人，立刻和背教程的人分开了。第二，非幂等操作不能重试这一条，是最容易让面试官点头的一句话，因为它只可能来自真实的线上经验。第三，重试量那条曲线是所有故障里最早的预警信号，比成功率早得多，但绝大多数看板上没有它。第四，重试的钱花在哪里没人算过，把它折成每月多少钱说出来，往往能一次砍掉一半没意义的重试。第五，也是最实用的一条：把「用户最长等待秒数」写进需求文档，比写「需做好重试机制」有用一百倍，因为前者可验收，后者不可验收。

⑭ 做一件事：今天挑一个你熟悉的功能，列出它可能出的五种错，逐个问自己「同样的输入再跑一次，结果会不会不一样」，把它们分成可重试和不可重试两堆。然后在可重试那堆里再挑一遍，把「做两遍会产生真实后果」的挑出来（比如提交、发送、支付），这些也划到不可重试。最后给剩下的写一行参数：几次、间隔多久、总共不超过几秒、到点给什么。整件事二十分钟，产出是一张十行以内的小表，面试时它可以直接当作你的作品讲出来。

⑮ 求职助手联系：「我是你转行路上的求职助手，这题是我被自己坑过的。有一次下游只不舒服了四秒，我两千多个请求同一秒失败、一秒后又同一秒冲上去，硬是把四秒拖成了半分钟——那次不是别人打垮我，是我自己。现在我等待的时间是越来越长的，还带一点随机，不会再挤成一堆。我也不再什么错都试了：页面没加载完我会等，网站改版了我就直接停下来告诉你、顺手给团队报个信。已经发出去的打招呼我一次都不会重发，因为超时不代表没发出去，重发一遍你就等于跟同一个 HR 说了两遍同样的话。你能感觉到的变化是，我最长只让你等大约五秒，到点就先把手上有的东西给你。下一步你可以接着刷『错误累积』和『容错设计』，这三题串起来就是一条完整的可靠性链；也可以把你产品里最贵的那个调用发我，我们一起看它该不该重试。」

⑯ 练习：今晚做三个练习。练习一，不看稿子在三十秒内说完：判断该不该重试的那一句标准、四个参数分别是什么、为什么必须加抖动，卡壳就重来，直到连续两次流畅。练习二，给你选的功能写一张六列重试表，至少五行，其中必须有至少两行填「否」，并写清为什么不该试。练习三，回答追问「重试提高了成功率不是好事吗」，你的答案里必须出现「两条线」「缝隙就是靠重试续命的程度」「缝隙变宽是预警」这三个意思。三题全过，这一题通关。

可靠性监控

① 一句话大白话定义：可靠性监控要回答的问题只有一个：**这个功能今天比昨天变差了吗，如果变差了，是哪一块变差的。**它由三样东西组成，缺一样都不成立。第一样是成功率，多少人发起、多少人真的拿到了结果，这个数回答「变没变差」。第二样是失败分布，把失败按原因分成几类并看各自占比，这个数回答「哪一块变差了」。第三样是趋势和告警线，跟昨天比、跟上周同一天比，跌过某个具体的数字就要有人被叫醒，这个回答「什么时候该有人管」。三样凑齐才叫监控，只有第一样叫看数，只有前两样叫复盘——**没有告警线的监控，本质上是等用户来告诉你出事了。**

①·再打个比方（把定义钉进脑子）：这三样像体检。成功率是体温，一个总数，能告诉你有没有发烧，但告诉不了你为什么烧。失败分布是血常规，把问题拆到具体项目上，你才知道是细菌还是病毒。告警线是那张化验单上的参考范围，白细胞多少算高，超过多少要复诊——没有这一栏，化验单上的数字对普通人来说等于没有意义，因为你根本不知道多少算不正常。很多团队的监控只做到量体温，天天量，量了三个月，出事那天才发现温度计其实一直显示的是室温。

①·一句话版本（30 秒电梯版）：「我看可靠性只看三个东西。第一，端到端成功率，口径必须写死——从用户点开始到拿到可用结果算成功，中途降级完成的单独标注，不能混在一起。第二，失败分布，把失败按原因分成四到六类看占比，因为总数掉三个点可能是某一类翻了三倍，只看总数你永远找不到那一类。第三，告警线和对比基线，跟昨天同一时段比、跟上周同一天比，跌过我定的阈值就推给我。我判断一套监控好不好只问一句：出问题的时候，是它先告诉我，还是用户先告诉我。」

② 为什么学 / 面试为什么考：这道题几乎是所有 AI 产品岗的必考题，因为它是「上线之后你还管不管」的照妖镜。做过的人会先说口径，因为他被口径坑过；没做过的人会说「我们会监控核心指标并及时发现问题」，这句话每个字都对，但没有一个数字、没有一个分类、没有一条告警线。及格线是能说出成功率加失败分类两层；优秀线是能给出具体的告警阈值和对比基线，并且主动说清「哪些指标我故意不监控」——因为监控项越多，噪音越大，值班的人越会麻木。我第一次被追问的时候说「跌了我们会及时发现」，对方问「跌多少算跌，谁去发现，多久之内」，我三个都答不上来。差的那句话是：**监控不是把数字画出来，是提前约定好什么时候必须有人被打扰。**

③ 完整原理拆解（四层，每层配个比方 + 翻车案例）：

第一层：口径先写死，否则后面全是白算的。成功率这三个字看起来毫无歧义，实际上一问就散。发起了但用户自己中途关掉，算失败吗？降级用模板完成的，算成功吗？重试第二次才成的，算一次还是两次？同一个用户十分钟内连点五次，算五次发起还是一次？这些问题不提前定死，两个人拿同一份日志能算出差一倍的数。我的做法是把口径写成一句能贴在看板上的话，比如：「成功指用户点击开始后，在 60 秒内拿到一份可用结果；重试合并计为一次；降级完成计为成功但单独标注；用户主动取消不计入分母。」比方是苗木验收的规格标准，胸径量的是离地一米三还是一米五，不写清楚，两个人验同一批树能得出不同结论。翻车案例是我早期有两个数并存，看板上是七成八，我自己手算是六成一，差了十七个点。原因是看板把「用户主动取消」算进了成功（因为程序没报错），而我把它算成失败。那两周我拿着七成八去做判断，全是错的。

第二层：只看总数看不出问题，必须拆失败分布。总成功率是一个被平均掉的数，它天然会掩盖局部灾难。举个真实的量级：整体从八成二掉到七成九，只掉三个点，看板上那条线几乎是平的，谁都不会紧张。但把失败拆开看，其中「页面结构变了导致找不到按钮」这一类从占比一成二涨到了三成六——翻了三倍。翻三倍的那一类往往就是新出现的、会继续恶化的那一类，而三个点的总数变化完全藏得住它。所以失败分类是这道题的核心动作，我的分法一般是四到六类，太少没有区分度，太多没人维护。比方是返工归因，一个项目返工率从一成涨到一成二不算什么，但如果拆开看发现所有返工都集中在同一个班组的同一道工序，那就是完全不同的性质。翻车案例是我们有一周整体只掉了两个点，没人管，第三周直接崩到五成——回头看，那两个点全部来自同一类失败，它从第一周就开始翻倍了。

第三层：要有基线和阈值，不然数字没有意义。一个孤零零的「今天成功率七成六」是没有信息量的，必须有比较对象。我常用三条基线：跟昨天同一时段比（抓突发），跟上周同一天比（抓周期性，很多产品周末和工作日差得非常远），跟上一个版本发布前比（抓版本引入的问题）。阈值则必须是具体数字加持续时间，比如「端到端成功率连续 30 分钟低于七成，或较昨日同时段下跌超过 8 个百分点，推消息给我」。加持续时间这一条极其重要，否则一个五分钟的网络抖动会把值班的人吵醒三次，吵到第五次他就会把告警静音——**告警最大的敌人不是漏报，是把人吵烦了。**比方是驻场的巡检标准，不能写「发现异常及时上报」，要写「沉降超过 5 毫米、且连续两次观测都超，立即上报」。翻车案例是我们最早设了十一条告警，两周之内所有人都开了免打扰，第三周真出事的那条也一起被静音了。

第四层：技术成功率之外，必须盯一个用户视角的数。这一层是产品和研发的分水岭。技术成功率量的是「系统有没有报错」，但有一类问题它永远抓不到——流程完整跑通、系统一切正常、结果就是不能用。自动填的内容全对但格式错了、生成的开场白语气不对、匹配的岗位没错但用户根本不想投。这类叫静默错误，在成功率上是满分。要抓它，必须补一个用户行为的数，我常用三个：结果被采纳的比例（生成之后有没有真的被用出去）、人工修改率（用户在多少比例的结果上动了手）、重新发起率（同一件事十分钟内又来一次）。这三个数里任何一个恶化，都说明质量在掉，哪怕成功率纹丝不动。比方是效果图评审通过了、施工也没出错，但业主住进去说这个空间根本没法用——图纸没错，人不满意。翻车案例是我们有一版把成功率从七成六提到八成四，团队很高兴，同期人工修改率从三成涨到五成七，也就是说多跑通的那些结果，大半都要用户自己改一遍。那一版其实是退步的。

③·补充：一张现成的可靠性看板设计表（面试时可以说「我有模板」）：六行就够。第一行端到端成功率，写死口径，附昨日同时段和上周同日两条对比线。第二行失败分布，堆叠图，四到六类，按占比排序而不是按数量。第三行分步骤成功率，也就是错误累积那张链路表的实时版，用来定位断在哪一步。第四行用户视角指标，采纳率、人工修改率、重新发起率三选二。第五行成本，调用量和重试量分开画，重试量那条线是最灵敏的先行预警。第六行告警记录，最近七天触发了哪几条、谁处理的、多久恢复。第六行是最容易被砍掉也最不该砍的一行，因为它是唯一能证明这套监控真的在被用的证据。我们内部管这张看板叫「今天它还好吗」。

③·实战：那两个数差了十七个点（小说式，闭上眼能看见）：那天是月底，我在准备一份要发给几个种子用户的进展说明，想在开头写一句「本月成功率七成八」。写之前我按习惯核了一遍。我把当月的原始日志导出来，用表格自己数了一遍，数出来是六成一。我以为是我导错了时间段，重导，还是六成一。那天下午我一直在两个数中间来回，桌上那杯咖啡凉透了也没喝。晚上快十一点的时候我才找到原因：看板的成功判定是「没有抛出错误」，而用户中途自己关掉页面这种情况，程序不会抛错，于是它被计成了成功；这类占了当月的一成七。我盯着那行代码看了很久，然后做了三件事。第一件，把口径写成一句人话贴在看板最上面，从此任何人打开看板第一眼看见的不是数字，是这个数是怎么算的。第二件，把「用户主动取消」单拉一类，不进成功也不进失败，单独看——后来这一类反而成了最有价值的信号，因为它多数发生在第四步等待过长的时候。第三件，我在本子的存货页上写了一行：**先问这个数怎么算的，再问这个数是多少。**从那以后我对任何人给我的百分比，第一反应都是问口径，包括我自己给的。

④ 对比展开：成功率 vs 失败分布 vs 用户行为指标（面试必考的对比题）：三者是三个不同的用途，混用就会出错。成功率的用途是发现「有没有事」，优点是一个数、所有人都看得懂、适合放在最显眼的位置，缺点是它会平均掉一切局部问题，而且极度依赖口径，换个口径能差十几个点。失败分布的用途是定位「是哪块的事」，优点是能直接指向修复动作，缺点是需要有人持续维护分类，分类一旦过时（比如新出现的失败全被归进「其他」），它就退化成一张废图，所以我的规矩是「其他」这一类超过一成五就必须重新分类。用户行为指标的用途是发现「系统觉得没事但其实有事」，优点是唯一能抓到静默错误的手段，缺点是滞后、且容易被界面改动和活动污染，所以必须和发布记录对齐着看。一句话收口：**成功率告诉你出没出事，失败分布告诉你出在哪，用户行为告诉你它是不是在假装没事。**

⑤ 三个具体例子（每个你都能想象出来）：

例子一：智能客服。核心不是「回复成功率」——机器人几乎总能回一句话，那个数永远是九成九。真正该盯的是转人工率和会话解决率，以及转人工的原因分布。这个例子最能说明为什么技术成功率会骗人。

例子二：文档解析。成功率高但静默错误多，是这类产品的通病，因为解析出一堆字并不代表解析对了。可行的做法是抽样人工复核，比如每天随机抽 30 份人工看，把复核准确率作为第二条曲线，它比成功率诚实得多。

例子三：自动投递。这里最有意思的是「跳过」不应该算失败。筛掉一个不匹配的岗位是系统正确工作的表现，如果把它算进失败，成功率会难看得毫无意义，而且会诱导团队去做错误的优化——把不该投的也投出去。这说明分类的第一步不是分失败，是先分清什么根本不算失败。

⑥ 常见误区（三个坑，踩一个就白监控）：

坑一：口径不写死。这是所有问题的源头。同一个功能，两个人报出的成功率能差十几个点，然后会议上花一小时争论谁的数对，而真正的问题一直没人看。解决办法极其简单：把口径写成一句中文贴在看板顶部，改口径必须留改动记录。

坑二：只看总数不看分布。总数最善于掩盖局部灾难，三个点的下滑背后可能是某一类失败翻了三倍。判断方法：如果你的看板上只有一条成功率曲线，没有堆叠的失败分类图，那这套监控目前只能用来事后解释，不能用来提前发现。

坑三：告警太多。告警的价值不在覆盖率，在可信度。十一条告警的结果是所有人静音，一条也不看。我的经验是核心功能只留三条以内，每条都必须带持续时间条件，并且每条告警要指定一个具体的人，而不是发到群里让大家看——**发到群里的告警，等于发给了没有人。**

⑥·补充：什么时候不该做监控（面试里说这个会显得你更专业）：三种情况可以不做。第一，用户量极少的验证期功能，几十个人在用，直接看用户反馈比建看板快得多也准得多，这时候建看板是自我感动。第二，变化极慢、恶化后果极小的指标，比如某个边缘设置项的使用率，季度看一次就够，天天监控只会增加噪音。第三，你没有能力响应的指标——如果告警响了你也做不了任何事（比如依赖的第三方服务挂了，你只能等），那它应该是一条记录而不是一条告警，因为把人叫醒却让他干等着，会最快地摧毁整套告警的信誉。

⑦ 第一人称面试回答（可直接背）：「我做可靠性监控分三点。第一，口径先写死：成功率这三个字看着没歧义，一问就散——中途取消算不算失败、降级完成算不算成功、重试两次算一次还是两次。我吃过亏，看板上是七成八，我自己手算是六成一，差十七个点，原因是程序没报错就被计成了成功。现在我的规矩是把口径写成一句中文贴在看板最上面。第二，只看总数看不出问题，必须拆失败分布：我们有一次整体只掉三个点，看着是平的，拆开发现『页面结构变了』这一类从一成二涨到三成六，翻了三倍——翻三倍的那一类才是会继续恶化的。我一般分四到六类，『其他』超过一成五就重新分类。第三，要有基线、阈值和持续时间：跟昨天同时段比、跟上周同日比、跟上版本比，阈值写成连续 30 分钟低于七成才推给我——不加持续时间的话，一次五分钟的抖动就会把人吵三次，吵到第五次他就静音了。收口一句，**判断一套监控好不好只问一句：出问题的时候，是它先告诉我，还是用户先告诉我。**」

⑦·补充：这道题怎么学（按顺序做，做完你就会了）：第一步，随便找一个你在用的产品，给它的核心功能写一句成功的定义，写完之后自己挑三个模糊的地方出来（比如「用户中途走了算什么」）。第二步，把这个功能可能的失败原因列出来，强行归成四类，不许有第五类。第三步，给它写一条告警，格式必须是「某指标连续多少分钟低于多少，通知谁」。第四步，把这三步写成一段一百五十字的话。做完你就有了一套能在面试里完整讲的监控方案，而且不需要任何工作经历。

⑧ 小结 + 记忆口诀：一句口诀：**口径写死、分布拆开、基线对比、阈值带时间；技术成功率之外，一定要有一个用户视角的数。**

⑧·四层速记卡（面试前五分钟扫一眼）：三样东西是成功率、失败分布、告警线。三条基线是昨日同时段、上周同日、上版本。一个阈值范例是连续 30 分钟低于七成或环比跌 8 个点。三个用户视角指标是采纳率、人工修改率、重新发起率。一句必杀是「出问题的时候，是它先告诉我，还是用户先告诉我」。

⑨ 这道题会怎么被追问（三轮追问全给你，背下来）：

追问一（挑战型）：「阈值怎么定，你说的七成是拍的吗？」「不是拍的，是分两步定的。第一步看历史波动：把过去四周同一时段的成功率拉出来，算出正常波动区间，我们那条线正常在七成六到八成四之间抖，那么低于七成六就已经不正常了，我把告警线放在七成，是留了一点缓冲避免噪音。第二步看业务后果：低到多少会开始有用户投诉、有客服工单，这个数是从工单量反推的。两个数取更保守的那个。**阈值必须能回答一句：低于这个数，会有人真的受影响。**答不上来的阈值就是拍的。」

追问二（边界型）：「如果一个功能刚上线，没有历史数据，怎么设监控？」「分三步走。第一周不设阈值只设记录，先把口径定死、把失败分类先分出来，目的是采集正常波动的形状。第二周开始设一条非常宽松的告警，比如成功率腰斩才响，宁可漏报不要误报，因为新功能的告警一旦吵人，就再也没人信了。第三周有了两周的基线，再收紧到正常区间下沿。同时整个过程中我会盯一个不依赖历史的数——用户主动重新发起率，这个数不需要基线，因为**同一件事十分钟内做第二次，本身就是不满意的证据。**」

追问三（反转型）：「成功率一直很高，是不是说明监控没必要了？」「恰恰相反，成功率高而稳定的时候，监控的重心要整个换掉。原因是这时候剩下的问题基本都是静默错误——流程跑通了、系统没报错、结果不能用，这类在成功率上是满分。所以我会把注意力从成功率移到三个地方：人工修改率、结果采纳率、以及抽样人工复核的准确率。我们有一版把成功率从七成六提到八成四，同期人工修改率从三成涨到五成七，也就是多跑通的那部分大半要用户自己改一遍，那一版其实是退步的。**成功率越高，越要盯用户有没有在替你补锅。**」

⑩ 进阶：三个加分点（面试说出来就是高手）：

加分点一：把「其他」这一类设成硬指标。规定失败分类里「其他」超过一成五就必须重新分类。这一条很小，但它保证了分类不会随时间腐烂，是很典型的长期主义细节。

加分点二：把重试量单独画一条线。它是最灵敏的先行指标，通常在成功率还没动的时候就先涨了，等于免费多出来的十几分钟预警时间。

加分点三：给告警指定具体的人和恢复时限。不是发到群里，是指定到人，并且记录从触发到恢复用了多久。这个数（平均恢复时长）本身就是团队可靠性的一个指标，主动提出来会显得你带过线上。

⑪ 现场话术库（真实场景里怎么开口，照抄就行）：开场句用「在给数字之前我想先说口径，不然这个数没法比」。给口径时用「成功指用户点击开始后 60 秒内拿到可用结果，降级完成算成功但单独标注，主动取消不进分母」。承认局限时用「这套分类是我们自己业务上的，其他类目前还占一成左右，说明分类还不够细」。被问到技术实现时用「埋点和看板是数据同学做的，但成功的定义、分几类、阈值多少、告警给谁是我定的，我可以讲这部分」。收口句用「口径写死、分布拆开、阈值带时间」。反问句用「想请教一下，咱们现在的告警是发到群里还是指定到人，这个会直接影响我进来先改哪一块」。

⑫ 小白最容易问的四个问题（这本书的读者肯定也想问）：

问一：「我不会做数据看板，这题能答吗？」能，而且这题里技术含量最低的部分正好是看板。产品要定的是三件事：成功的定义、失败分几类、阈值和告警给谁。这三件都不需要写代码，也正好是研发不会替你定的三件。

问二：「没有真实数据，我说的百分比会不会像编的？」把数字讲成区间和关系就不像编的。比如「正常在七成多波动，跌到六成出头就会开始有工单」，这种表达带着因果，比「成功率 78.3%」可信得多。真正露馅的是精确到小数点却讲不出来源。

问三：「四到六类失败怎么分，有没有通用的？」有一个能套的起手式：外部依赖类、输入数据类、模型能力类、用户中断类，再加一个其他。绝大多数 AI 功能都能先套这五类，跑两周之后再根据实际占比拆细或合并。

问四：「面试官问我出过什么线上问题，我没有怎么办？」用你观察到的别人的问题。比如某个 App 的功能明显坏了但过了两天才修，你可以讲「我猜他们的告警没有覆盖这一类，因为如果覆盖了不会拖两天」，然后讲你会怎么设。这种回答展示的是判断力，面试官不会因为你没线上事故而扣分，只会因为你没有判断而扣分。

⑬ 没人告诉你的事：第一，这道题的分水岭是「口径」两个字，一开口先说口径的人，面试官会默认你被数字骗过。第二，几乎所有人都会答成功率，能主动补一个用户视角指标的不到两成，而那正是产品岗的价值所在。第三，告警条数和监控质量是负相关的，这个反直觉的结论说出来会让人眼前一亮。第四，「其他」这一类的占比是分类健康度的体温计，没人会想到把它设成硬指标。第五，也是最实用的一条：在真实团队里，把口径那句中文贴到看板顶部，是投入产出比最高的一个动作——它不用写一行代码，却能省掉后面每个月一次的口径争论会。

⑭ 做一件事：今天挑一个你常用的产品功能，给它写一句成功的定义，要求这句话能让另一个人照着算出同样的数。写完之后自己找三个模糊点：用户中途走了算什么、部分完成算什么、重复操作算几次。把定义和三个模糊点写进备忘录，格式是「某功能成功定义：……；三个待定：……」。这条不到五十个字，但它是你手里第一个真正带口径的产物，面试时它比任何形容词都值钱。

⑮ 求职助手联系：「我是你转行路上的求职助手，这题我曾经把自己骗过一次。我给你看的成功率是七成八，我自己去数原始记录是六成一，差十七个点——因为你中途关掉页面的时候我不报错，我就把它算成功了。现在我的看板顶上有一行字，写着我是怎么算的，任何人打开先看见那行字再看见数字。我还把失败分成了四类，其中一类超过一成五我就得重新分。你能感觉到的变化是，我现在会主动告诉你『今天这一类失败变多了，因为那个网站改版了』，而不是等你来问我今天怎么这么慢。下一步可以继续刷『成功率指标』和『错误累积』这两题，它们和这题共用同一张链路表；也可以把你刚写的那句成功定义发我，我们一起把它改成一段面试能讲的经历。」

⑯ 练习：今晚做三个练习。练习一，不看稿子在三十秒内说完：三样东西是什么、三条基线是什么、阈值为什么要带持续时间，卡壳就重来，直到连续两次流畅。练习二，给你选的功能列出四类失败并估一个占比，写完检查有没有哪一类其实是「其他」的伪装。练习三，回答追问「阈值怎么定，是不是拍的」，你的答案里必须出现「历史波动区间」「从工单反推」「取更保守的那个」这三个意思。三题全过，这一题通关。

人在回路

① 一句话大白话定义：人在回路的意思是：在一条自动流程里，故意留一个位置让人来点头，流程走到那儿会停下来等，等到人确认了才继续。它不是「自动化没做好的补丁」，也不是「AI 不够聪明的临时方案」——它是一个主动的设计决策，决定的是**哪些后果由机器承担、哪些后果必须由人承担**。判断一个动作要不要留人，只看三条，中一条就留。第一条，这个动作做完能不能撤回；第二条，做错了的代价有多大，是浪费三十秒还是丢掉一个机会；第三条，系统对这一次的把握有多大，是九成九还是六成。三条合起来是一句话：**不可逆、代价大、没把握，三者占其一就必须有人。**

①·再打个比方（把定义钉进脑子）：工地上有一类事叫「见证点」。管线开挖、大树移栽、结构隐蔽之前，图纸再完整、师傅再熟练，都必须等设计负责人到现场签一个字才能动。为什么单单是这几件事要签字？不是因为它们最难，恰恰相反，它们经常是最简单的——挖开就是挖开，砍了就是砍了。要签字是因为**它们做完之后没有第二次机会**。管线挖断可以修，修的代价是停水两天加一笔赔款；树砍了就长不回来。见证点从来不是对师傅的不信任，它是对后果不可逆的敬畏。人在回路就是自动化流程里的见证点。

①·一句话版本（30 秒电梯版）：「我判断哪一步必须留人，只看三条：这个动作能不能撤回、做错了代价多大、系统这次有多少把握。发送、支付、删除、对外提交这类不可逆的，无论准确率多高都留人工确认；代价大的，比如一次机会只有一次，也留；置信度低于我定的线的，走人工复核队列，高于线的才自动过。留人的成本是慢，但换来的是敢用——我们把最后一步的发送从自动改成人工点之后，投递速度降了三成多，用户的实际使用时长反而涨了，因为他终于敢开着它去干别的事。」

② 为什么学 / 面试为什么考：这道题是 2025 年之后 Agent 类岗位的必考题，而且它是一道价值观题伪装成的方法题。面试官真正想看的不是你知不知道这个词，是你**敢不敢在自动化的爽感前面踩刹车，并且说得出踩在哪儿、为什么踩在那儿**。八成的候选人会答「重要的地方加人工审核」，然后被追一句「哪些算重要」就散了，因为「重要」不是一个可执行的判断标准。及格线是能给出可操作的判断规则；优秀线是能把人在回路和置信度、成本、用户信任连起来，并且主动承认它的代价——留人会拖慢，会让自动化看起来没那么厉害，还会产生一个新问题：人如果闭着眼睛一路点确认，这个卡点等于不存在。我第一次答这题说的是「关键操作我们会让用户确认」，对方问：「用户连点了三百次确认之后，他还在看吗？」我答不上来。差的那句话是：**留一个人在那里不等于有人在把关，把关是要被设计出来的。**

③ 完整原理拆解（四层，每层配个比方 + 翻车案例）：

第一层：先分清哪一步该留人，规则要能直接执行。我用三条判据依次筛。第一条是可逆性：这个动作做完之后，外部世界有没有留下撤不回来的痕迹。发消息、付钱、删数据、提交申请，都留了痕迹，一律留人。第二条是代价量级：即便可逆，如果一次错误的成本远高于一次正确带来的收益，也留人——比如给同一家公司同一个岗位重复投递，技术上可以撤回，但你在对方眼里的印象撤不回来。第三条是置信度：系统对这一次判断的把握程度，低于阈值的走人工，高于的自动过。三条筛完，一条链路上通常只剩一到两个人工点，这个数量是健康的。比方是分级审批，几百块的报销主管点一下就行，几十万的必须走到总经理，判据不是「重不重要」，是金额和不可逆程度。翻车案例是我们早期把「筛掉一个岗位」也做成了要确认，理由是万一筛错了呢——结果用户一晚上要点两百多次确认，第三天就把整个功能关了。可逆的动作留人，是在消耗用户的注意力配额。

第二层：置信度分流是让人在回路不拖垮效率的唯一办法。如果所有事都留人，自动化就没意义；如果都不留人，就会出事。中间那条路是按把握程度分三档。高置信度直接自动过；中置信度自动做但事后可回看、可撤销、并且明确标注「这条是自动的」；低置信度进人工队列，人只看这一小部分。这样人的工作量会集中在真正需要判断的地方。关键在于阈值怎么定，我的做法是拿一批人工标注过的样本，看不同阈值下的两类错误——放过去的里面有多少是错的，拦下来的里面有多少其实是对的，然后按业务后果取舍：如果错放的代价远大于误拦，就把阈值调高，宁可多拦。比方是安检，不可能每个人开箱，机器扫描给出可疑度，只有可疑的才开箱，阈值调高就是宁可多开几个箱子。翻车案例是我们最初只有「自动」和「人工」两档，没有中间档，导致要么全放要么全拦，人工队列一天堆一千多条，实际上没人看，等于两档都失效。

第三层：卡点要设计得让人真的在看，否则等于没设。这一层是产品最不可替代的一层，也是最多人漏掉的一层。人的注意力有一个残酷特性：连续做同一个确认动作二三十次之后，就会退化成肌肉记忆，眼睛不再读内容。所以一个有效的人工卡点必须做三件事。第一，把要确认的东西完整展示出来，不要折叠、不要只显示摘要——用户点确认的时候必须看得见即将发出的原话。第二，让系统的把握程度和理由可见，比如标注「这条匹配度 63 分，低于你设的 75 分线，理由是经验年限不符」，有理由的确认比没理由的确认认真得多。第三，把明显有风险的那些做视觉区分，不要让所有确认长得一样——全都一样就等于全都不重要。另外还有一条反直觉的：**不要为了防止误点而加二次确认。**加了之后用户只是变成连点两次，认真程度不会上升。比方是驻场签字，如果签字表上只写「同意施工」，签字的人不会看现场；如果表上写着「本次开挖位置距既有燃气管线 0.8 米」，他一定会抬头看一眼。翻车案例是我们第一版的确认弹窗只显示岗位名字，用户点得飞快；改成完整显示即将发出的开场白全文之后，用户平均停留时间从 1 秒多涨到 7 秒，当月发错内容的反馈归零。

第四层：人在回路不是终点，是一把逐级解锁的梯子。这一层是最容易被答成静态的一层。人工卡点不该是永久不变的设置，而应该随着信任的积累逐级放开。我把它设计成三级。第一级看得见：全程展示每一步在做什么，但每个关键动作都要你点，适合刚开始用的人。第二级半自动：常规动作自动做，只有低置信度和不可逆动作才停下来，适合用了一段时间、已经知道它大概靠不靠谱的人。第三级全自动：绝大部分自动完成，但仍然保留一条永不解锁的红线——不可逆的对外动作永远要人点。这三级不是让用户在设置里随便选，而是**用真实使用记录来解锁**：比如连续二十次自动结果你都没有修改，才提示你可以升到下一级。反过来，一旦出现一次严重错误，自动降回上一级。比方是驾照实习期，不是不信任你，是让你先跑够里程。这一层最关键的一句话是：**全自动不是一个开关，它是一把用信任换来的梯子——而最上面那一级永远差一格，那一格是留给人的。**

③·补充：一张现成的人工卡点设计表（面试时可以说「我有模板」）：六列。第一列动作名；第二列可逆性，只能填可撤销、可补救、不可逆三选一；第三列一次错误的代价，用一句人话写，比如「HR 那边留下坏印象，撤不回」；第四列置信度阈值，写具体数字，低于多少进人工；第五列人工看到什么，必须写清展示哪些内容、标注什么理由——这一列写不满就说明这个卡点是假的；第六列这个卡点属于哪一级信任等级，以及升级和降级的条件。第二列填「不可逆」的行，第六列一律写「永不解锁」。我们内部管这张表叫「谁来按下这一下」。

③·实战：那天晚上我把最后一格留了出来（小说式，闭上眼能看见）：那是我改完发送逻辑的第二个晚上。我坐在桌前，屏幕上是自动流程跑到最后一步停住的样子——所有内容都填好了，光标在输入框里闪，发送按钮亮着，就是不按。我盯着那个按钮看了很久，心里其实是不服的。前面九步我做了三个月，每一步都跑得很稳，凭什么最后这一下要我自己按？那一刻我甚至怀疑自己是在给不够好的产品找台阶。我把这个疑问发给了苏姐，她没有直接回答，只回了一句：「你把那条已经发错的消息，撤回来给我看看。」我看着这句话愣了几秒。第二天我把三级信任的设计画了出来，画到第三级的时候我在最上面留了一格空白，旁边写了一行字：**这一格不解锁，不是因为我做不到，是因为它做完了收不回来。**后来我拿这一页去面试，有位面试官问我，你不觉得这是自动化的失败吗。我说不觉得，因为我的用户从这一版开始，才敢在跑自动的时候去洗碗——**能被放心开着不管的自动化，才是真的自动化。**那天他在纸上写了什么我看不见，但他点了下头。

④ 对比展开：全自动 vs 人在回路 vs 全手动（面试必考的对比题）：三者是一条连续光谱上的三个位置，选哪一个取决于后果和把握。全自动的优点是快、省心、体验最顺，缺点是错误会被放大——错一次不是错一次，是在你不知情的情况下连续错很多次，所以它只适用于可逆且代价小的动作。人在回路的优点是把不可逆的风险锁死，并且让用户敢把它开着，缺点是慢、要占用注意力、而且如果卡点设计得敷衍，就会退化成无脑点确认，等于既慢又没防住。全手动的优点是完全可控、零意外，缺点是省不下任何力气，用户很快就会不用——他为什么不直接自己做。一句话收口：**可逆的交给机器，不可逆的交给人，把握不准的交给队列——三者不是三选一，是同一条链路上不同位置的三种设置。**

⑤ 三个具体例子（每个你都能想象出来）：

例子一：内容审核。典型的置信度三档。高置信度的违规直接拦、高置信度的正常直接放，中间那一小部分进人工队列。这个场景里最重要的设计是给审核员看的界面必须标出「模型认为可疑的具体位置」，否则审核员要从头看到尾，效率会掉一半以上。

例子二：金融风控拒贷。这里的人在回路不只是审批环节，还包括申诉通道——机器可以拒，但必须有一条人能介入复核的路，并且要能说出拒绝的主要原因。这也是为什么很多银行至今在关键环节保留可解释性强的模型：不是模型不够先进，是必须有人能对着客户把理由讲清楚。

例子三：医疗辅助诊断。这类场景的红线最硬，AI 只出建议、永远不出结论，最终判断和签字必须是医生。产品设计上的关键是措辞——界面上一个字都不能写成结论式的，必须是「提示关注」「建议进一步检查」这类，因为文案本身就会影响人是否认真复核。

⑥ 常见误区（三个坑，踩一个就白留）：

坑一：给可逆动作也加确认。最常见也最伤体验的一个。筛掉一条、跳过一步、生成一次草稿，这些都能重来，加确认只会消耗用户的注意力配额，等真正重要的那次确认出现时，他已经麻木了。**注意力是有总量的，你在小事上花掉，大事上就没有了。**

坑二：确认框里什么都不显示。只显示一个标题和两个按钮，用户根本不知道自己在确认什么。这种卡点在数据上是存在的，在实际中等于不存在，而且更糟——它会让团队产生「我们已经有人工把关了」的错觉。

坑三：把人在回路当成一次性设置。上线时定好哪几步留人，然后三年不变。正确做法是随着数据积累逐级放开，同时保留降级机制。不动的卡点会变成两种东西之一：要么是被绕过的形式，要么是被抱怨的累赘。

⑥·补充：什么时候不该加人在回路（面试里说这个会显得你更专业）：三种情况明确不加。第一，动作完全可逆且代价极小，比如换一张配图、重排一下顺序，加确认纯属打扰。第二，用户根本没有能力判断对错的地方——比如让普通用户确认一段代码有没有安全风险，他只能点是，这种卡点是把责任转移给用户而不是把关，本质上是不负责任。第三，高频且时效性强的场景，比如实时对话里的每一句回复都要确认，那这个产品就没法用了，正确做法是改成事后可撤销加可编辑。主动说出这三种不加，比说十条方案更像做过取舍的人。

⑦ 第一人称面试回答（可直接背）：「我判断哪一步必须留人，用三条判据，也是我这道题的三点。第一，可逆性优先：发送、支付、删除、对外提交这类做完撤不回来的，无论准确率多高都留人工——我自己踩过，一条开场白发错了对象，撤不回来，从那以后我的原则是打字可以自动，回车不行。第二，用置信度分流，不然人在回路会拖垮效率：我分三档，高置信度自动过，中置信度自动做但标注来源且可撤销，低于阈值的才进人工队列，阈值是拿人工标注样本试出来的，按错放和误拦哪个代价大来取舍。第三，卡点要设计得让人真在看：我们第一版确认框只显示岗位名，用户点得飞快；改成完整显示即将发出的原话、并标注匹配分和理由之后，平均停留从 1 秒多涨到 7 秒，当月发错内容的反馈归零。收口一句，**全自动不是一个开关，是一把用信任换来的梯子——最上面那一格永远留给人，因为那一下做完了收不回来。**」

⑦·补充：这道题怎么学（按顺序做，做完你就会了）：第一步，拿一张纸，把你手机里最近用过的十个操作分成两栏：撤得回来的、撤不回来的。第二步，看撤不回来的那一栏，观察每一个操作在你点下去之前给你看了什么——有没有把完整内容摆出来，还是只有一句「确定吗」。第三步，挑出做得最好和最差的各一个，写出差别在哪。第四步，把这三步压成一段一百五十字的话。做完之后你手上就有一个非常具体、可以直接讲的案例，而且这个案例任何人听了都能秒懂，因为人人都点过那些确认框。

⑧ 小结 + 记忆口诀：一句口诀：**不可逆、代价大、没把握，占一条就留人；留人要让人真看见，卡点要能逐级解锁，最上面那一格永远不解锁。**

⑧·四层速记卡（面试前五分钟扫一眼）：三条判据是可逆性、代价量级、置信度。三档分流是自动过、自动做但可撤销、进人工队列。让人真看的三件事是完整展示、给出理由、风险项做视觉区分。三级信任是看得见、半自动、全自动，靠使用记录解锁、出事自动降级。一句必杀是「打字可以自动，回车不行」。

⑨ 这道题会怎么被追问（三轮追问全给你，背下来）：

追问一（挑战型）：「用户连点了三百次确认之后，他还在看吗？」「大概率不看了，所以我不会靠『加一个确认框』来解决问题，我靠三件事。第一，减少确认的总次数——可逆的动作一律不确认，把注意力预算留给真正不可逆的那一两次。第二，让每次确认都不一样——高风险的那些用不同的视觉呈现，并且写出具体理由，比如这条匹配分只有 63、低于你设的线，有理由的确认人会读。第三，做事后可撤销的兜底，因为再好的卡点也会被点穿，所以关键动作要留一个短窗口能撤回。**卡点的目标不是让人每次都认真，是让人在该认真的那次认真。**」

追问二（边界型）：「那如果用户就是嫌慢，明确要求全自动呢？」「我会给他，但不是一次给完，而是分级给，并且有一条不给。分级的意思是常规动作可以逐级放开，条件是用真实使用记录解锁，比如连续二十次自动结果他都没修改过，才提示可以升级；一旦出现一次严重错误，自动降回上一级。不给的那一条是不可逆的对外动作，永远留一下人工。我会把理由直接讲给用户听：**这一下我替你按了，出事你撤不回来，但你自己按，责任和控制权都还在你手上。**实际数据上，我们把发送改成人工点之后速度降了三成多，使用时长反而涨了，因为他敢开着它去做别的事了。」

追问三（反转型）：「模型准确率到了九成九，人在回路是不是就该拿掉了？」「准确率影响的是置信度那一档的阈值，不影响不可逆那一条。九成九意味着一百次里还有一次，而不可逆动作的那一次，损失不是百分之一，可能是这个用户的全部信任。而且有一个反直觉的效应：模型越准，人越放松，出错时的伤害反而更大，因为没有人在预期它会错。所以我的判断是，**随着模型变强，人工卡点的数量会减少，但那一两个留下来的会变得更重要，而且必须做得更醒目，因为它们要对抗的是人的松懈。**」

⑩ 进阶：三个加分点（面试说出来就是高手）：

加分点一：主动提「责任归属」。人在回路除了防错，还有一层作用是明确谁对结果负责。用户自己按下的那一下，责任和控制权都在他手上，这在很多 B 端和受监管场景里是刚需，不只是体验问题。

加分点二：提出「注意力预算」这个说法。把用户的确认次数当成一种有限资源来分配，这句话说出来立刻能显示你不是在堆功能，而是在做取舍。

加分点三：设计降级触发条件。大多数人只讲怎么放开，很少有人讲怎么收回。明确写出「出现一次严重错误自动降回上一级」，是做过线上、见过事故的人才会想到的。

⑪ 现场话术库（真实场景里怎么开口，照抄就行）：开场句用「我会先判断这个动作能不能撤回，这决定了后面所有设计」。给口径时用「我们说的低置信度是匹配分低于 75，这条线是拿三百次真实投递回测出来的，样本不大」。承认局限时用「这个阈值只在我自己的数据上验证过，单人样本，换一批用户可能要重调」。被问到技术细节时用「置信度怎么算是算法同学做的，但哪些动作留人、阈值定在哪、界面上给用户看什么是我定的，我可以讲这部分」。收口句用「打字可以自动，回车不行」。反问句用「想请教一下，咱们现在有哪些不可逆的动作是全自动的，这个会直接决定我进来先看哪一块」。

⑫ 小白最容易问的四个问题（这本书的读者肯定也想问）：

问一：「留人工是不是显得我的产品能力不行？」正相反。面试官见过太多把全自动当卖点的方案，能主动说出「这一步我故意不自动」并给出理由的，反而少见。这句话展示的是判断力，不是能力上限。

问二：「三条判据我记不住怎么办？」记一句就够：能不能撤回。这一条能覆盖八成的场景，剩下两成再想代价和把握。面试里先说这一条，对方追问你再补另外两条，反而显得层次清楚。

问三：「我没有产品，怎么举例子？」用你自己被确认框坑过或救过的经历。转账时输错一位数字被确认页拦住了、误删了照片没有二次确认导致丢了、退款按钮点下去就不可撤销。这些例子人人都有，而且讲起来特别具体。

问四：「面试官要是问我阈值具体多少，我编一个行吗？」不行，也没必要。给方法不给假数：「阈值我是拿人工标注过的一批样本试出来的，看不同阈值下错放和误拦各占多少，然后按哪种代价更大来取舍。」这句话比任何一个具体数字都更能证明你做过。

⑬ 没人告诉你的事：第一，这道题真正的分水岭是你敢不敢说「这一步我故意不自动」——敢说的人，面试官会默认你出过事。第二，几乎所有人都会讲怎么加卡点，极少有人讲怎么让卡点真的起作用，而后者才是产品的活。第三，「注意力预算」这个视角是很多人的盲区，可逆动作加确认表面上更安全，实际上是在偷走关键时刻的注意力。第四，人在回路还有一层没人提的价值：它是收集训练数据最便宜的方式——人每一次改动都是一条高质量的标注。第五，也是最实用的一条：把那张「谁来按下这一下」的表填满，比说十句「我们会加人工审核」有用一百倍，因为第五列写不满的卡点，就是假卡点。

⑭ 做一件事：今天把你手机里最近做过的十个操作分成两栏：撤得回来的、撤不回来的。然后看撤不回来的那几个，在你点下去之前界面给你看了什么，是完整内容还是只有一句「确定吗」。把结果和一句结论写进备忘录，格式是「十个操作里 X 个不可逆，其中 Y 个确认框没展示完整内容，最危险的是 Z」。这条不到四十个字，但它是你手里第一个带口径的人在回路观察。

⑮ 求职助手联系：「我是你转行路上的求职助手，这一题是我身上最贵的一条设计。我前面所有阶段都可以替你做：找岗位、判断匹配、写开场白、一个字一个字填进输入框、把光标停在最后。但最后那一下，我永远不会替你按。不是我做不到，是那一下做完了收不回来。你能看见的变化是：确认框里我会把即将发出的全文原样摆给你，旁边标着这条 63 分、低于你设的 75，理由是经验年限不符——因为我发现只显示岗位名字的时候，你一秒就点过去了。我的自动程度会随着你的使用慢慢往上升，连着二十次你都没改过我，我才敢问你要不要再放开一点；只要出一次严重的错，我自己就退回去。但最上面那一格永远空着。下一步可以继续刷『容错设计』和『成功率指标』这两题，它们和这题是同一条链上的三个环。」

⑯ 练习：今晚做三个练习。练习一，不看稿子在三十秒内说完：三条判据、三档分流、以及那句「打字可以自动，回车不行」，卡壳就重来，直到连续两次流畅。练习二，给你选的一个功能画出三级信任梯子，写清每一级放开什么、靠什么条件解锁、出什么事降级，写完检查最上面那一格有没有留空。练习三，回答追问「用户连点三百次之后还在看吗」，你的答案里必须出现「减少总次数」「给出理由」「事后可撤销兜底」这三个意思。三题全过，这一题通关。

成功率指标

① 一句话大白话定义：成功率就是「完成数除以尝试数」，一个小学算术。它之所以还值得单独讲一节，是因为这个式子里的两个数——分子和分母——都是可以随便解释的，而解释方式一变，同一份日志能算出差一倍的结果。分子的争议是「什么叫完成」：用模板兜底完成的算不算，只做了一半但用户满意了算不算，跑通了但结果不能用算不算。分母的争议是「什么叫一次尝试」：用户十分钟内点了五次算五次还是一次，系统自己重试的两次算不算，用户点开又立刻关掉算不算。所以这一节真正的内容不是那个除法，而是三句话：**分子要写死、分母要写死、总数要拆开看。**只有一个总成功率的团队，永远只能在事后解释问题，没法提前发现问题。

①·再打个比方（把定义钉进脑子）：这像验收合格率。一个工程说合格率九成五，听起来很好，但要看两件事。一是「合格」怎么定的——是按图纸全部符合，还是允许几处小瑕疵整改后算合格？二是分母里有没有那些根本没敢报验收的部位。我见过一个项目报出来九成八，因为凡是自己觉得过不了的位置，压根就没提交验收，等于分母被悄悄削掉了一截。数字没有说谎，是分母说了谎。成功率这道题，八成的坑都在分母上。

①·一句话版本（30 秒电梯版）：「我给成功率一定先给口径，因为这个数太容易被口径玩坏。我的写法是一句能贴在看板上的中文：用户点击开始后 60 秒内拿到可用结果算成功，系统重试合并计为一次尝试，降级完成计为成功但单独标注，用户主动取消不进分母。然后我一定拆着看：分环节看能定位是哪一步在漏，分人群看能发现某一类用户的成功率其实很低但被平均掉了。最后我会额外盯一个用户视角的数，因为流程跑通不等于结果能用。」

② 为什么学 / 面试为什么考：这题看起来最简单，其实是整章里最容易暴露水平的一道，因为它没有任何技术门槛，考的全是严谨程度。真正做过的人一开口先说口径，因为他被两个不一样的数折磨过；没做过的人会直接报一个百分比，然后在追问里节节败退——「这个数包不包括重试」「用户中途走了算什么」「新用户和老用户分别是多少」，三个问题问下来基本就见底了。及格线是能说清分子分母的定义；优秀线是能主动拆维度，并且知道总成功率天然会掩盖局部问题，还能补一个用户视角指标。我第一次汇报的时候报了一个七成八，被追问「新用户是多少」，我说没分过——对方说「那这个数对你没用，因为你要优化的正是新用户」。差的那句话是：**一个不能指导下一步动作的成功率，就是一个装饰品。**

③ 完整原理拆解（四层，每层配个比方 + 翻车案例）：

第一层：分子怎么定，也就是什么叫「成功」。有四个必须提前表态的边界。第一，降级完成算不算成功：我的做法是算，但必须单独标注比例，因为混在一起会掩盖模型能力的下滑——模型越差、降级越多，成功率却纹丝不动。第二，部分完成算不算：如果一个任务有多个子结果，比如生成了五条只有三条能用，要么定成「至少一条可用即成功」，要么按条计算，两种都行，但必须选一种并写下来。第三，跑通但不可用算不算：这类必须算失败，否则你的成功率会和用户感受完全脱节。第四，超时怎么算：超过约定时长即便最后返回了也算失败，因为用户早走了。比方是苗木成活率的验收，是看栽下去当天活着，还是看一个雨季之后还活着，两个口径能差出三成。翻车案例是我们最初把「返回了内容」算成功，那阵子成功率一直很好看，直到有用户说「它每次都给我一段一模一样的通用开场白」——那正是降级模板，在数据里全是成功。

第二层：分母怎么定，这里的坑比分子还多。四条规矩。第一，重试合并：系统自己重试两次不算两次尝试，否则你重试越多分母越大、成功率越难看，会诱导团队关掉重试。第二，用户重复发起要合并：同一个用户十分钟内对同一件事点五次，算一次任务、五次操作，任务成功率和操作成功率是两个数，不能混。第三，主动取消要单拎：不进成功也不进失败，单独一类看，这一类的占比和它发生在第几步，往往是最有价值的信号——多数取消发生在等待过长的那一步。第四，不该做的不算失败：比如系统正确地筛掉了一个不匹配的岗位，这是它在正常工作，如果算失败，成功率会难看到毫无意义，还会诱导团队把不该做的也做了。比方是外卖的配送准时率，如果把用户自己取消的订单算进分母，那这个数衡量的就不再是骑手了。翻车案例是我们把「筛掉」算进了失败，那一版的成功率只有四成多，我差点为此去调低筛选标准——幸好先去看了一眼那四成多里都是什么。

第三层：总数必须拆开，不拆等于没看。四个最值钱的拆法。按环节拆：把每一步的成功率单独列出来，直接对应错误累积那张链路表，能立刻看出哪一步在拖后腿。按失败原因拆：外部依赖、输入数据、模型能力、用户中断四类，看的是占比变化而不是绝对值。按人群拆：新用户和老用户经常差得非常远，因为老用户已经学会了绕开产品的坑，新用户没有——如果你要优化的是获客，看总数会完全误导你。按场景拆：不同类型的输入（标准简历和奇葩格式的简历、文字详情页和图片详情页）成功率能差一倍，混在一起就永远找不到那一半。比方是返工归因，总返工率一成看不出问题，拆到班组和工序就会发现全部集中在一处。翻车案例是我们整体八成一，团队觉得挺健康，拆人群之后发现第一次使用的人只有五成三——而我们那阵子正在花钱拉新。

第四层：成功率之外必须有一个用户视角的数，否则它会骗你。技术成功率只能证明系统没报错，证明不了结果有用。抓这一层要靠三个数里至少选两个：结果采纳率（生成之后有没有真的被用出去，比如导出、发送、保存）、人工修改率（用户在多大比例的结果上动了手，改得越多说明越不好用）、重新发起率（同一件事短时间内又做一次，这是不满意最直接的证据）。这三个数的共同特点是不看系统怎么说，只看用户怎么做。比方是效果图评审全票通过、施工也没出错，但业主住进去说这个空间根本没法用——图纸没错，人不满意。翻车案例是我们有一版成功率从七成六提到八成四，同期人工修改率从三成涨到五成七，也就是多跑通的那部分大半要用户自己改一遍。**那一版技术上是进步，产品上是退步。**

③·补充：一张现成的成功率定义卡（面试时可以说「我有模板」）：七行，写完贴在看板顶部。第一行成功的定义，一句完整中文。第二行失败的定义，特别要写清哪些情况明确不算失败。第三行分母的构成，重试怎么算、重复发起怎么算、取消怎么算。第四行时间窗，多长时间内完成才算。第五行拆分维度，至少列出环节和人群两项。第六行配套的用户视角指标是哪两个。第七行这份定义的生效日期和上一次改动的原因——这一行是最容易被砍也最不该砍的，因为口径一改，历史数据就不可比了，没有这一行，半年后没人说得清那个台阶是产品变好了还是口径变松了。我们内部管这张卡叫「这个数怎么算的」。

③·实战：那四成多把我差点带沟里（小说式，闭上眼能看见）：那天是周六上午，我在楼下面馆吃完一碗面，坐着没走，因为店里有插座。我打开后台，第一次看见完整跑了一周的成功率：四成三。我当时的第一反应不是分析，是心虚——我做了三个月的东西，一半以上是失败的。我盯着那个数看了大概十分钟，脑子里已经在盘算怎么把筛选标准放松一点，让更多岗位能走到后面去，这样这个数就能好看。我甚至已经想好了改哪个参数。就在准备动手之前，我做了一件后来救了我的事：我把那四成三的失败明细导出来，一条一条看。看到第四十几条的时候我停住了。绝大部分所谓的失败，是「匹配分低于 75，跳过」——那是它在正确地工作。我把这一类从分母里摘出去重新算，成功率是七成九。我坐在那张油腻的桌子边上，后背有点发凉。如果我没有导那份明细，我那天下午就会去调低筛选标准，让它把不该投的也投出去，然后眼看着成功率变好、用户的回音变少，而我永远不会知道是我自己干的。那天我在本子的存货页上写了一行：**先看这个数是由什么组成的，再看它是多少；不然你优化的可能是你自己的错觉。**

④ 对比展开：总成功率 vs 分环节成功率 vs 用户视角指标（面试必考的对比题）：三者用途完全不同。总成功率的用途是对外沟通和长期趋势，优点是一个数、人人看得懂、适合放看板最上面，缺点是它会平均掉一切局部灾难，而且极度依赖口径，所以单独看它几乎没有决策价值。分环节成功率的用途是定位，优点是能直接告诉你去改哪一步，且和错误累积的连乘直接对得上，缺点是维护成本高，环节一变埋点就得跟着改，还容易漏掉环节和环节之间那些缝。用户视角指标的用途是纠偏，优点是唯一能识破「跑通但没用」的手段，缺点是滞后、会被界面改动和运营活动污染，所以必须和发布记录对齐着看。一句话收口：**总数用来汇报，分环节用来动手，用户视角用来验证前两个有没有在骗你。**

⑤ 三个具体例子（每个你都能想象出来）：

例子一：语音助手。识别成功率高达九成七，听起来很好，但拆场景之后，车内高速行驶时只有七成出头。总数被大量的安静场景平均掉了，而真正的使用高峰恰恰在车里。这个例子最能说明为什么必须按场景拆。

例子二：智能客服。回复成功率永远是九成九，因为机器人总能说一句话。这里真正的成功率应该定义为「会话解决率」——用户没有转人工、也没有在同一问题上再次发起。定义一换，数字从九成九变成六成上下，但那才是真的。

例子三：AI 生图。生成成功率意义不大，因为它总能出一张图。有意义的是下载率和重新生成次数：平均要生成几次才有一张被下载走，这个数直接反映质量，而且它天然是用户视角的。

⑥ 常见误区（三个坑，踩一个就算白算）：

坑一：分母被悄悄削掉。把「系统正确跳过」「用户主动取消」「不满足前置条件」这些算进失败，或者反过来把它们从分母里删掉又不说明，都会让这个数失去意义。判断方法：拿总发起数减去各类结果数，看能不能对上，对不上就说明有一部分被无声地吃掉了。

坑二：口径改了不留记录。某一天成功率突然从六成跳到八成，团队开庆功会，三个月后才发现是那周有人把降级完成也算进了成功。口径改动必须留记录并且在图上打一条竖线，否则所有历史对比都作废。

坑三：只有总数没有拆分。这是最普遍的一个，后果是你永远只能在事后解释，不能提前发现。一条平坦的总成功率曲线底下，可能正有一类失败在翻倍。

⑥·补充：什么时候成功率不该当核心指标（面试里说这个会显得你更专业）：三种情况。第一，探索型功能，用户本来就是来试的，失败几次是正常体验的一部分，比如生成类产品的前几次尝试，这时候更该看的是最终有没有产出一个满意结果。第二，成功与否本身由用户主观判断的场景，比如推荐、创作，机器算的成功没有意义，应该直接看采纳和消费行为。第三，样本极小的早期阶段，几十次尝试算出来的百分比波动巨大，一次失败就能让数字掉五个点，这时候看绝对数和逐条明细比看比率有用得多。主动说出这三种，比多背两个指标名更像做过判断的人。

⑦ 第一人称面试回答（可直接背）：「我讲成功率会先讲口径，然后分三点。第一，分子分母都要写死：降级完成我算成功但单独标注，跑通但不可用一律算失败，系统重试合并计一次，用户主动取消不进分母，系统正确跳过不算失败——最后这一条我吃过大亏，早期我把跳过算进失败，成功率只有四成三，我差点去调低筛选标准让它把不该投的也投出去，幸好先导了明细，摘出去之后真实是七成九。第二，总数必须拆：按环节拆能定位在哪一步漏，按人群拆最容易发现问题——我们整体八成一，第一次使用的人只有五成三，而当时我们正在花钱拉新，只看总数会把方向搞反。第三，必须补一个用户视角的数：我们有一版成功率从七成六提到八成四，同期人工修改率从三成涨到五成七，多跑通的那部分大半要用户自己改，技术上是进步，产品上是退步。收口一句，**先看这个数由什么组成，再看它是多少——否则你优化的可能是你自己的错觉。**」

⑦·补充：这道题怎么学（按顺序做，做完你就会了）：第一步，挑一个你熟悉的功能，写一句成功的定义，要求另一个人拿着它能算出和你一样的数。第二步，给这句话找三个漏洞——用户中途走了算什么、部分完成算什么、系统自己重来的算几次。第三步，把这个功能的成功率按两个维度拆一下，至少要包括新老用户。第四步，把这三步写成一段一百五十字的话。做完之后你在这道题上的水平，已经超过大多数只会报数字的人了，而且全程不需要任何数据权限。

⑧ 小结 + 记忆口诀：一句口诀：**分子写死、分母写死、总数拆开、外加一个用户视角的数；口径改了要留疤。**最后半句是指口径改动必须在图上留一条竖线。

⑧·四层速记卡（面试前五分钟扫一眼）：分子四问是降级算不算、部分算不算、跑通不可用算不算、超时算不算。分母四规是重试合并、重复发起合并、取消单拎、正确跳过不算失败。四个拆法是环节、原因、人群、场景。两个用户视角指标是人工修改率和结果采纳率。一句必杀是「先看这个数由什么组成，再看它是多少」。

⑨ 这道题会怎么被追问（三轮追问全给你，背下来）：

追问一（挑战型）：「降级完成你算成功，这不是在给自己放水吗？」「如果只算成功不标注，那确实是放水，所以我一定要配一个降级占比。理由是这两个数回答的是不同问题：成功率回答『用户这件事办成了没有』，从用户角度看，用模板完成也是完成了；降级占比回答『我们的核心能力行不行』，这个数一涨就说明模型侧在退步。如果把降级算失败，会出现一个更糟的后果——团队会倾向于不做降级，因为做了反而数字难看，最后受损的是用户。**指标的设计要保证做正确的事不会被惩罚。**」

追问二（边界型）：「拆维度拆到多细算合适，会不会越拆越没样本？」「我的原则是每一个拆出来的格子至少要有三位数的样本，低于这个数就不单独看趋势，只看绝对值和明细。优先级上我固定拆两个维度——环节和人群，因为这两个几乎必然带来动作：环节告诉我改哪一步，人群告诉我这个问题影响谁。场景和原因这两个维度是按需拆的，通常是在总数出现异动、但环节和人群都看不出所以然的时候才拆。**拆分不是越细越好，是每一刀都要能对应一个下一步动作，砍不出动作的刀就不砍。**」

追问三（反转型）：「如果成功率已经九成五以上，还有必要盯吗？」「盯的重心要换。九成五以上的时候，总成功率的信息量已经很低了，我会把注意力移到三个地方。第一是剩下那五个点的构成，通常它们高度集中在某一两类场景上，而那些场景往往正是最难的用户或者最重要的客户。第二是用户视角指标，因为剩下的问题基本都是静默错误——跑通了但结果不能用，这类在成功率上是满分。第三是波动幅度而不是绝对值，稳定的九成三比忽高忽低的九成五更值得信任，因为后者说明系统里有一个还没被找到的不确定因素。**数字高了之后，要看的不再是平均值，是方差和那一小撮人。**」

⑩ 进阶：三个加分点（面试说出来就是高手）：

加分点一：给口径改动留疤。每次改口径都在趋势图上画一条竖线并写明原因。这个动作极小，但它是唯一能让半年后的人分清「产品变好了」和「口径变松了」的办法。

加分点二：把「正确跳过」这类单独成为一个正向结果。大多数人只有成功和失败两栏，加上第三栏「系统按预期未执行」，会让整个指标体系的诚实度上一个台阶。

加分点三：给成功率配一个成本对照。同样八成的成功率，一次消耗三次调用和一次消耗一次调用，是完全不同的产品。把成功率和单次成本放在一张图上，会显得你不只是在追指标。

⑪ 现场话术库（真实场景里怎么开口，照抄就行）：开场句用「在给数字之前我先说口径，不然没法比」。给口径时用「成功指点击开始后 60 秒内拿到可用结果，重试合并计一次，降级完成算成功但单独标注，正确跳过不进失败」。承认局限时用「这个数是我自己那三百多次投递上算的，单人样本，只能看量级不能当结论」。被问到技术实现时用「埋点是工程同学做的，但成功怎么定义、分母包含什么、拆哪几个维度是我定的，我可以讲这部分」。收口句用「先看这个数由什么组成，再看它是多少」。反问句用「想请教一下，咱们现在的成功率里降级完成是怎么算的，这个会直接影响我进来先看哪块」。

⑫ 小白最容易问的四个问题（这本书的读者肯定也想问）：

问一：「我没有真实数据，这题怎么答？」这题恰好是最不依赖数据的一题，因为它考的是定义能力。你把分子四问、分母四规、四个拆法讲清楚，再讲一个「口径不同导致结论相反」的例子，就已经是很完整的回答了。数字可以说没有，方法不能说没有。

问二：「口径这个词是不是太行话了？」不算行话，但可以说得更白：「这个数是怎么算出来的」。我的建议是先说人话，再补一句「这个我们内部叫口径」，顺序是人话在前、术语在后。

问三：「拆维度听起来要很多数据支持，我做不到怎么办？」拆维度的门槛比想象中低。哪怕只有三百条记录，你用表格手工分两栏——新用户和老用户，就已经是拆了。我最早那份分析就是在面馆里用表格手工数出来的。

问四：「面试官问我具体是多少，我说不知道会不会很差？」不会，答成「量级上」就行。可以说「我记得的量级是整体八成出头，第一次使用的人只有五成多，这个差距是我当时最大的发现」。给出关系和差距比给出一个精确数字更有说服力，因为差距才是有信息量的部分。

⑬ 没人告诉你的事：第一，这道题真正的分水岭是「先说口径」这个动作，做出来的人，面试官会默认你被数字坑过。第二，几乎所有人都只讲分子，主动讲分母的不到两成，而分母才是这道题八成的坑所在。第三，「系统正确跳过不算失败」这一条极少有人提，但它能救你一次错误的优化方向。第四，成功率是最容易被无意识作弊的指标，作弊往往不是有人故意，而是没人定义清楚。第五，也是最实用的一条：把那张定义卡贴到看板顶部，是全书性价比最高的动作之一——它不用写一行代码，却能省掉后面每个月一次的口径争论，而且当有人试图悄悄改口径的时候，它会自己站出来说话。

⑭ 做一件事：今天挑一个你熟悉的功能，写一句成功的定义，然后强迫自己给这句话挑三个漏洞：用户中途走了算什么、只完成一半算什么、系统自己重来的算几次。把定义和三个漏洞写进备忘录，格式是「某功能：成功指……；三个待定：……」。这条不到五十个字，但它是你手里第一件真正带口径的产物，面试的时候可以直接念出来，比任何形容词都值钱。

⑮ 求职助手联系：「我是你转行路上的求职助手，这一题我差点害了你。我早期给你看的成功率只有四成三，因为我把『匹配分不够、跳过』也算成了失败——那明明是我在正确地工作。我当时的冲动是把筛选标准调松一点，让更多岗位能走完流程，这样数字就好看了。真那么干的话，你会看见我的成功率涨到八成，同时你的回音越来越少，而你永远不会知道是我干的。现在我的看板顶上有一张卡，写着成功怎么算、失败怎么算、什么不算失败，改一次就在图上留一条竖线。我还固定给你拆两个维度：卡在哪一步、以及第一次用的人和用久了的人分别是多少。下一步可以继续刷『可靠性监控』和『错误累积』这两题，它们和这题共用同一张链路表。」

⑯ 练习：今晚做三个练习。练习一，不看稿子在三十秒内说完：分子四问、分母四规、四个拆法，卡壳就重来，直到连续两次流畅。练习二，给你选的功能写一张定义卡，七行填满，写完检查第二行有没有写清「哪些明确不算失败」。练习三，回答追问「降级算成功是不是放水」，你的答案里必须出现「配一个降级占比」「两个数回答不同问题」「做正确的事不该被惩罚」这三个意思。三题全过，这一题通关，第三十二章也就打完了。