AI 编程工具上线后，出现过一个问题：早上的补全响应快，随后逐渐变慢。用户看到的都是补全迟迟没有出现，但仅凭这个现象，还不能判断时间花在了哪里。

我用链路遥测追踪请求，定位到请求依赖注入时的数据库写入耗时。在涉及 FastAPI、MongoDB 和 Redis 的服务中，通过分表、索引优化及调整 aiohttp 请求方式，恢复了响应速度。

用户等待的是整条链路

这套工具包括上下文引擎、推理服务、语言服务器和多个 IDE 插件。一次补全要经过这些组件，模型生成只是其中一段。系统还可能在准备请求或记录数据时消耗时间。

所以我更关心从键盘输入到补全文本出现的端到端延迟。完整简历记录的 P99 约 490 ms，主要运行条件是 RTX 3090／4090 与 7B 级及以下代码模型。这个数字描述运行表现；它并不是这次排障的前后对照实验。

先找到时间，再决定改哪里

这次经历给我的提醒是，把一条请求拆开，通常比先挑一个组件优化更有帮助。用户能感知的等待要有对应指标，内部各阶段也要能解释这段等待。

回头看，可观测系统本身就是产品的一部分。它帮助我把“越来越慢”这样模糊的反馈，变成可以定位、修改和再次观察的问题。