做刷题助手时延迟和成本要按同一条请求链路看刷题助手的体验很容易被两个数字误导平均响应时间看起来正常用户却抱怨偶尔要等很久总调用量没变账单却慢慢上涨。原因通常是统计口径太粗。一次请求从进入队列到用户看到第一个字、再到完整答案结束期间还可能有检索、代码执行和取消这些阶段不能只用一个平均值盖过去。延迟与成本也不能分开讨论。让模型生成更长的解释也许提高了某些题目的可读性却会同时增加生成时间和用量缓存命中虽然节省调用若答错了题节省没有意义。先把链路和目标划清后面的优化才不会互相抵消。按任务类型记录而不是混成一个平均数短题解释、完整题解、代码审阅、带工具调用的调试请求天然有不同的输入长度和完成条件。把它们混在一张平均耗时图上长任务的退化会被掩盖短任务的小改善也可能只是样本比例变化。至少区分排队时间、首个可见输出时间和完整完成时间。流式回答中用户通常先感知首字等待对需要复制完整代码或查看结论的场景尾部完成时间同样重要。记录模型、提示版本、上下文长度和是否使用工具才能在一次调整后判断变化来自哪里。分位数通常比均值更能发现问题。少量超慢请求可能正好落在网络较差、题目较复杂或上游限流时而这些请求对用户印象影响最大。指标不需要做得花哨但必须能回到单次任务找到它在何处排队、调用了什么、最终是否成功。缩短输入前先确认哪些上下文真的有用刷题场景容易把题面、历史对话、用户全部代码、检索资料和系统说明一并塞进提示。上下文越长不一定越能帮助回答反而会抬高首字延迟和费用。可以按任务需要保留最相关的题目版本、用户当前代码片段、报错信息和必要约束其余历史内容做摘要或按需检索。摘要本身也要有边界。把关键条件总结丢了模型可能对另一道题给出看似流畅却错误的建议。针对典型题型准备固定评测集比较不同上下文策略下的答案质量、输入用量和完成时间比凭感觉删文本可靠。模型配置同样会影响成本。输出上限、温度、工具调用轮数都应按任务设定。要求一句提示时不必允许生成一大段泛泛讲解需要完整解题思路时也不应因为害怕成本把输出截到无法使用。目标是给每种任务合适的上限而不是对所有请求一刀切。缓存要命中正确的问题语义缓存可以减少重复解释但“语义相近”不等于答案可以复用。题目版本、语言、输入约束、用户权限、模型配置和提示版本都可能改变正确答案。缓存键至少要携带这些会影响结果的条件包含用户代码、成绩或私有资料的内容更不能未经脱敏和权限判断进入共享缓存。命中后也不应假装这是一次新生成。可以标注内容来自已验证答案或最近结果并保留刷新路径。若知识来源或题目发生更新旧缓存应自然失效。为了提高命中率把相似度阈值设得过宽会导致用户收到另一道题的解释这比一次慢响应更伤信任。缓存评估除了命中率还要抽样检查命中内容是否仍然适用。缓存节省的请求数只是手段正确性才是底线。流式输出和取消需要成对设计流式传输可以降低等待感但不保证总生成更快。前端若对每个很小的 chunk 都立即渲染也可能造成界面频繁更新可以按短时间窗口合并显示同时保留足够快的首字反馈。更容易遗漏的是取消。用户换题、关闭页面或明确停止后客户端、服务端和模型读取链路都应收到取消信号。只停止浏览器显示而继续让下游生成会产生没有用户会看到的 Token 成本。取消后的任务状态要可区分不能把它计作普通错误或成功回答。工具调用同理。模型准备执行代码或查询资料时用户可能已离开当前问题。任务系统需要判断执行是否仍有必要并让可取消步骤响应终止。对不可取消的外部动作要有幂等和结果查询策略。用固定样本验证取舍每次改提示、缓存、模型或流式策略都在同一组代表性题目上重跑。比较端到端延迟、首字时间、输入输出用量、缓存命中质量和用户可见错误。还要模拟断连、缓存失效和上游限流确认降级后界面仍能说明发生了什么。刷题助手没有一个独立最优的延迟或成本数字。不同任务的取舍不同但它们都需要一条稳定的观察链路回答是否有用、用户等了多久、系统为此花了什么。把这三件事放在一起优化才会真的改善产品而不是只让某张报表更好看。