业务给出目标
不同业务对等待的容忍度不同，需要业务方明确目标分位与降级可接受度。为什么必须业务定：技术只能给出能力，不能判断体验底线。做法是把目标写进需求文档并区分核心与非核心；边界是目标要随业务阶段调整，不能一次定死。
产品的等待设计
流式输出、进度提示、异步通知与骨架屏都会改变感知延迟。为什么重要：同样的端到端耗时，有反馈与无反馈的体验差别很大。做法是在需求阶段就把等待状态设计进去；边界是提示不能掩盖失败，超时要有明确出口与后续路径。
运维的容量保障
要有容量水位、扩容触发与告警分级，才能在高负载时守住尾部延迟。怎么做：按峰值与拐点设阈值，定期演练扩容；边界是扩容有物理上限与时间成本，突发流量仍需限流兜底，不能把扩容当成万能方案。
检索链路的配合
检索增强场景中，召回、重排与上下文长度常是延迟大头。为什么容易失控：这部分由数据团队维护，优化目标不一致。做法是把检索耗时纳入同一张看板；边界是压缩召回会影响答案质量，需要联合评测后再定参数。
统一口径与回归
测量方法、样本与统计口径要统一，并做版本回归。怎么做：把延迟测试纳入发布流程；边界是回归会占用环境与时间，可按版本节奏执行，但核心业务每次都要跑，否则退化往往在几周后才被发现。
适用与不适用
适合谁
- 要把延迟目标写进需求与验收的产品团队
- 跨算法、数据与运维协作的交付负责人
- 被反馈慢但说不清责任环节的业务线
不适合谁
- 没有稳定流量、也无人负责体验的探索型项目
- 只由单一团队闭环、不需要跨方协作的小工具
典型场景
某运营商的智能工单助手在试点时被反馈慢。复盘发现业务没有定目标、前端没有等待提示、检索召回条数由数据团队按准确率单独调高。三方对齐后，业务定了核心场景的目标分位，前端加了流式与进度提示，检索改为按场景配置条数，延迟问题才真正收敛。
可执行步骤
- 由业务明确核心场景的目标分位，以及可接受的降级方式、范围与边界条件
- 在需求阶段就设计等待、进度与超时提示，写进交互原型文档与说明里
- 为容量设置水位与扩容触发线，并定期演练扩容流程、回退动作步骤与分工
- 把检索耗时纳入同一张看板，与模型耗时并列展示，便于归因、对比与追责范围
- 将延迟回归纳入发布流程，核心业务每次发布前都必须跑一遍基线测试用例
常见坑
- 没有业务目标，技术团队只能按跑分优化，上线仍被嫌慢，返工没有方向，一整轮预算容易白花。
- 前端没有等待提示，实际并不慢也会被用户感知为卡死，投诉照样会来，解释成本很高，还影响口碑评价与续费。
- 检索团队只对准确率负责，召回条数越调越高，延迟逐渐失控却无人认领责任，排查也要跨部门，周期很长且反复。
- 延迟测试只在项目初期做过一次，版本迭代之后性能悄悄退化，往往是用户先发现，处理很被动，口碑受损明显且难挽回。
自检与验收清单
- 核心场景的目标分位是否已经过业务方的书面确认与签字
- 等待、进度与超时的提示是否已设计完成，是否进入原型
- 容量与排队水位是否已设置告警阈值、扩容触发线与责任人
- 检索耗时是否与模型耗时放在同一张看板，是否便于对比
- 发布流程是否包含延迟回归测试，是否有基线核对环节
常见问题
目标分位由谁定？
由业务方定，技术团队提供可选的区间与代价说明。业务更清楚用户能等多久、失败一次的影响有多大。定完后写进需求与验收条款，后续调整要有记录，避免目标随讨论反复变化。
检索慢算谁的问题？
算共同问题。检索团队对召回质量负责，延迟由使用方提出目标并共同评测。建议把检索耗时纳入同一张看板，明确各段的预算，出现超支时按预算追溯，而不是等到用户投诉再互相推。
回归要跑到什么程度？
核心业务每次发布都跑固定样本，非核心可按版本周期跑。重点是同口径对比，记录版本与参数，出现退化能定位到具体改动。回归不必追求全量场景，但样本要稳定，否则数据无法比较。