成功率从 85% 掉到 61%，先别急着修超时

旅行 Agent 的行程规划，内测成功率 85%，线上六周后 61%。抽 200 条失败会话，初步归类：接口超时 35%、需求理解偏差 28%、不满足隐性约束 22%、用户中途放弃 15%。工程只有两周，且不能换底座模型。

多数人会直接按占比排优先级，先修 35% 的超时。我出这道题，等的就是有人反问一句：这四类是怎么标出来的，它们互斥吗？

本系列第 6/10 篇 · 上一篇：任务完成率 68%，可 40% 的初稿被推翻重写 · 下一篇：搜索能查、推荐能逛、客服能办，Agent 增量在哪

四类归因不足以排优先级

它至少有四个问题：

• 按现象分类，不按发生位置。「超时」发生在第 2 步和第 7 步，用户感受完全不同；后者往往已经等了半分钟。
• 不互斥，也没写优先级规则。一条会话既超时又放弃，标成哪类？如果标读者习惯取最后一个现象，35% 和 15% 就是两个人标出来的两套数。
• 「中途放弃」多半是果不是因。用户为什么放弃？常见正是前三类中某一类拖太久。把它当独立的一类去优化，会去改按钮和文案，白费两周。
• 缺严重度和可挽回性。低价值用户的一次超时，和已选好酒店、准备下单的高意图用户的一次超时，损失不是一个量级。

我要求补的维度：用户分层（新客 / 复访 / 高意图）、任务复杂度（天数、同行人数、约束条数）、失败发生在第几步及是否在不可逆动作之前、是否已产生订单或投诉、时间分布与版本变更对齐、以及线上与内测的样本分布差异。

最后一条是 85 → 61 最可能的解释。内测样本通常是同事写的、约束干净、接口有 mock；线上会有老人同行、预算口头补充、第三方接口限流。落差常常不是模型退步，是输入分布换了。不查这个就修模型，两周会白花。

两周三项迭代，按「可挽回 × 可控 × 验证快」排

优先级	改动	预期挽回	验证方式	负向影响
P0	隐性约束显式化：规划前把预算、同行人、作息偏好做成一张可确认的结构化约束卡	22% 中的约一半，≈ 8–10pt	约束满足率 + 分组成功率 A/B	多一步交互，放弃率可能升
P1	超时与缺口的体验兜底：不再返回空白，给「已确认的部分行程 + 明确缺口 + 稍后补齐 / 转人工」	35% 中的一部分，≈ 5–8pt	超时场景下的任务完成率与放弃率	不完整结果被误当最终方案，需醒目标记
P2	关键槽位低置信时只问一句澄清	28% 中一小部分，≈ 3–5pt	澄清率、澄清后成功率、平均轮次	轮次增加，问多了惹烦

P0 排在超时前面，不是因为它占比大，而是因为它完全在产品侧可控、不需要工程排期、且能用一张卡片验证。P1 甚至不修接口，只改「失败时长什么样」——超时里相当一部分用户不是不能接受部分结果，是接受不了等了半分钟得到一片空白。真正修第三方接口的那件事，我会列进工程 backlog，但不放进这两周的产品迭代里赌。

预期收益我一律写成区间并标注假设，不写「预计提升 20 个点」。面试官追问时，能说清这个区间怎么估、哪条假设最可能错，比给一个精确数字更可信。

哪些是产品可解的

需求理解偏差里，模型能力不足的那部分产品改不动；但「用户没说清楚」那部分可以——把关键槽位前置、把模糊词转成可选值，就是产品可解。接口超时本身不可解，但超时后的等待体验、部分结果、预期管理、转人工出口全是产品可解。

我给团队的一条原则是：不可解的问题，至少要给用户一个明确的下一步。空白页、无限转圈、静默重试，这三种是把工程故障翻译成了产品事故。转人工也不丢人，但要带着已完成的上下文转，别让用户从头讲一遍。

别再靠每周抽 200 条

失败会话回收要自动化，靠的是链路结构化埋点而不是人工看日志：

• 每个失败自动带标签：失败节点、失败类型（重试可解 / 参数不成立 / 能力缺失 / 用户放弃）、当时的约束卡快照、用户分层、损失量级；标签由链路节点产生，不靠人读对话判。
• 叠加用户显式信号（点踩、重问、转人工），日终自动进 bad case 库并按「失败节点 + 触发条件」聚类。
• 每周固定时间看 Top 3 聚类，改动依据必须引用具体样本 id；改完把代表样本回灌固定评测集，防止这次修好、下次改别的地方又坏回去。
• 这套机制自己的指标是自动归因覆盖率（有结构化标签的失败会话占比）和 Top 3 聚类的周变化。覆盖率上不去，说明还是在靠人肉。

追问：超时修好只涨 3pt

这题考复盘能力，不是考运气。我的第一反应是归因标签错了，按三个方向查：

1. 标签是否互斥：那 35% 里是不是大量会话同时被算进了「放弃」，修好超时后它们仍然因为别的原因失败，所以净增只有 3pt。
2. 路径是否已流失：用户在超时前就走了，修好也回不来；这类只能靠入口预期管理救，不能靠接口。
3. 分母有没有变：同期是否上了别的改动、用户结构是否变了。

然后回到最初那个被跳过的假设：85 → 61 的主因可能压根不是超时，而是线上分布与内测不同。修超时只是让一类失败看起来不那么难看，成功率自然不动。归因错了，修得再对也没用——这句话我会直接写进复盘，不去给那 3pt 找补。

我会怎么看答案

及格：按占比排序，说先修超时、再优化提示词。良好：会补分层维度、会给三项带验证方式的迭代、会区分产品与工程边界。优秀：质疑四类标签本身的互斥性、把「分布变化」列为首要假设、预期收益写成带假设的区间、能把「只涨 3pt」变成一次归因复盘。

一个常见的失分是「加大样本量再看」。两周就是两周，产品岗要在信息不全时给出可回滚的决定，而不是把决定推给下一次抽样。

优先级不是按失败次数排的，是按「这一改能挽回多少、多久能知道有没有挽回」排的。

归因做完了，还有一道更前置的题：这个功能本来该不该由 Agent 来做。