1. 先看清瓶颈到底长什么样：代码助手不是不够聪明，是太“重”了
我接手过一个内部代码助手的性能优化任务，不是从零训练模型，而是把已经能用的助手调得足够快、足够便宜、足够让人愿意天天开着用。一开始团队反馈的痛点非常统一：提示词一长，转圈的时间就明显拉长；补全倒是能出结果，但经常要等三四秒才出第一个token；多轮对话聊到后面，模型开始答非所问，甚至直接丢上下文。当时我做了第一轮链路打点，发现绝大多数延迟和错误并不是模型本身“变笨了”，而是输入侧和推断侧在工程层面拖了后腿。
具体来说，代码助手的请求路径大概是这样的：用户输入一个请求，服务端组装 prompt，把项目文件内容、当前文件上下文、多轮历史消息按某种顺序拼到一起，交给大模型推理。这个环节有两个硬约束，一个叫上下文窗口（context window），一个叫自回归解码速度。前者决定了你一次能往里塞多少东西，后者决定了模型每个 token 是串行生成的，前一个 token 不生成完，后一个 token 永远出不来。这两个约束叠加起来，就是把代码助手从“能用”拖回“难用”的核心原因。
更要命的是，代码场景跟普通聊天场景完全不同。普通聊天每条消息短，上下文窗口的压力没那么大；代码场景里一个文件动辄几百行，用户一聊就是十几轮，再加上系统提示词、工具返回结果，几万 token 很轻松就出去了。窗口一旦塞满，工程上最朴素的处理方式就是“从前往后丢”，结果模型把用户正在改的那个函数给忘了，生成的代码跟当前文件内容对不上，这几乎是我在用户反馈里看到频率最高的一类问题。
所以这篇想把整个优化链路完整讲一遍：从上下文窗口的管理策略，到推断侧的缓存、投机解码、量化落地，再附上一套可以照做的打点、评测、灰度流程和避坑清单。这不是一篇空谈理论的文章，所有方案我都按真实落地过的方式写，涉及的数据和步骤也以可复现为主。
2. 上下文窗口优化：把模型“该看的”和“不用看的”分开
2.1 先做Token预算拆分，不然窗口永远不够用
上下文窗口优化的第一课不是“怎么压缩”，而是“先算账”。无论模型支持 32K 还是 128K 窗口，你都不可能把整个仓库塞进去，也不该塞。正确做法是把每次请求的输入分成几个固定通道，给每个通道设置硬性预算，然后把预算的执行逻辑写死在服务端。
我当时给内部助手设定的预算大致是这样（以 32K 窗口为例）：
| 输入通道 | 预算分配 | 说明 |
|---|---|---|
| 系统提示词与工具说明 | 2K | 固定不变，写死后基本不占优化空间 |
| 当前文件上下文 | 8K | 以光标所在函数/类为主，而不是整个文件 |
| 代码检索相关片段 | 6K | RAG 召回结果，按相关性排序截断 |
| 多轮对话历史 | 10K | 超长时压缩或摘要化，不能直接丢弃 |
| 用户当前请求 | 2K | 原始请求原样保留 |
| 预留缓冲 | 4K | 应对超长函数、diff 内容等意外情况 |
这个预算不是一次定死就完的。关键在于优先级：当前正在编辑的代码永远最高，用户原始请求次之，对话历史排第三，RAG 碎片最低。当总长度超限时，先砍检索片段，再压缩历史，最后才动当前文件上下文。很多团队优化失败，就是顺序反了，先砍了当前文件的关键部分，模型失去了最核心的参照物，生成的代码自然质量崩塌。
这套预算机制上线后，我们针对高频场景做了一次抽样，发现原本大量“答非所问”的请求，其实绝大多数是因为历史消息把窗口撑爆，早期文件内容被粗暴截断造成的。预算拆分之后，模型看到的始终是结构化、有优先级的输入，回答质量肉眼可见地回升。所以不要一上来就想着 128K 窗口能包治百病——窗口再大也有填满的时候，预算管理是底线工程。
2.2 代码文件先做“结构化压缩”，而不是直接贴全文
这是第二个关键决策：代码文件不能当成普通文本对待。直接按文件路径读取全文塞给模型，是最浪费token的做法，因为文件里大量内容是模型当前任务根本不需要的——比如 import 列表、与当前修改无关的公共类、大段注释和文档字符串。
我的做法是对文件做一次轻量解析，生成结构化候选块，再根据当前操作位置动态拼接。最粗粒度是两段：符号级上下文和函数级上下文。
- 符号级上下文：文件路径、语言类型、关键 import、公开类/函数签名列表、当前光标附近的符号依赖关系。这段信息量小而全，适合让模型理解代码结构。
- 函数级上下文：当前光标所在函数或类的完整实现，最多再带上直接调用它的相邻函数的前 20 到 30 行。这段是模型生成代码时最需要参考的“现场”。
举个例子，用户在utils/format.ts里改一个formatDate函数，我拼给模型的可能是：
当前文件：utils/format.ts 语言：TypeScript 依赖：dayjs, Intl.DateTimeFormat 公开符号：formatNumber, formatDate, parseDateStr 当前函数：formatDate（完整实现，约40行） 相邻调用：formatDate 被 formatDateTime 调用，后者签名如下...这一整套下来通常控制在 1.5K 到 3K token 之间，而整个文件贴进去可能是 8K 到 15K。省下来的窗口空间全留给对话历史和检索片段，链路整体的语义连续性好了一个量级。我看到不少团队在优化上下文时花大力气搞摘要模型、微调压缩网络，却连“不要在 prompt 里贴全文”这步都没做，实在可惜。
结构化压缩的落地并不复杂，树状语法解析（AST）就行。代码仓库里一般都有现成的解析器，按语言选好即可，解析失败就退回按行截断的普通方案。值得注意的是：对 Markdown、配置文件这类非代码内容，结构化压缩效果有限，直接按长度截断也能接受。
2.3 多轮历史的“摘要树”和“关键消息复活”
对话历史是上下文窗口的吞金兽。普通聊天助手可以不加区分地保留最近 N 轮，因为每条消息就几百 token；代码助手的对话里经常夹着大段代码、报错堆栈、diff 片段，一轮上千 token 很常见，十几轮就把预算吃光了。
我采用了一套摘要树 + 关键消息复活的机制，三层结构：
- 第一层：全部历史消息按时间顺序倒排，只保留最近 2 到 3 轮的原貌，这是模型生成时最直接的参考。
- 第二层：更早的历史消息划分为若干段落，每段预先离线生成一段文本摘要，存起来。摘要要包含用户意图、涉及的关键文件、最后结论，不包含太多代码细节。
- 第三层：当检测到用户当前请求与某个旧摘要涉及的文件或函数高度相关时，把对应的原始消息片段“复活”出来，放进上下文，而不是只给摘要。
这个设计前后花了不少时间调优。最开始的版本是简单的滚动摘要，就是每聊几轮把前面的内容总结一下扔掉原文，结果发现用户说“刚才那个 bug 修复改成处理空指针了”的时候，模型只能从摘要里得到“讨论了一个 bug”，具体改法全丢了。后来加了相关性判断和消息复活，这个问题才算真正解掉。
摘要生成这块我建议单独做成一个异步队列任务，在模型空闲时预生成，不要塞进用户请求的关键路径，否则摘要本身就会成为新的延迟瓶颈。用一个小型本地模型跑摘要就够，主打便宜和快，质量差一点没关系——反正摘要只是降级后的参考信息，真正兜底的是原文复活机制。
2.4 RAG检索片段：相关性排序和按需扩充
RAG在代码助手里承担的是“窗口之外的仓库记忆”，但召回结果同样要花窗口预算。我刚落地RAG时的第一版方案是把 Top 10 个片段全拼进去，结果几个无关片段占了 2K 到 3K token，真正有用的片段反而被淹没，模型整体表现不升反降。
后来改成了两步：先粗召回 Top 20，再按语义相关性做重排序，只保留 Top 3 到 5，每段上限控制在 500 到 800 token 内。片段长度不够时，再按“就近扩充”原则把同一文件的相邻函数代码拼进来，否则模型只看到一个函数签名却不知道实现，等于白搭。
另外一个细节是：RAG 片段必须带来源路径，并在 prompt 里明确标注“这段来自 src/xxx.ts，可作为参考”。代码补全模型对来源感知比很多人想象中敏感，标明路径后，生成的代码在命名风格上会自然向对应文件的风格靠拢。
如果预算还有富余，可以考虑在检索时把当前 git diff 的信息一起送进去。用户改到一半的文件，diff 内容是最新意图的直接体现，比任何静态上下文都更准确。Git diff 和 RAG 片段配合使用，是我在上下文优化里收益最明显的一组组合。
3. 推断加速三板斧：缓存、投机解码、量化
3.1 先分清 TTFT 和 TPOT，才能定位该优化哪里
上下文窗口解决的是“输入侧”的问题，推断加速解决的是“输出侧”的问题。但推断侧的优化必须先拆指标，不然很容易白忙活。
- TTFT（Time To First Token）：从发出请求到收到第一个 token 的时间。
- TPOT（Time Per Output Token）：生成单个 token 的平均耗时。
这两个指标由完全不同的环节决定。TTFT 主要被 prefill 阶段支配：模型需要对所有输入 token 做一次完整的前向计算，输入越长，TTFT 越线性上涨。TPOT 则取决于 decode 阶段的带宽和计算量，每个 token 都要读取完整的 KV Cache，显存带宽通常是主瓶颈。
我实测过一个 7B 规模的模型，输入 4K token 时 TTFT 大约在 900ms 到 1.2s 之间，输入拉到 16K 时会膨胀到 3s 以上。而 TPOT 在 7B 规模下大概是 30ms 到 60ms 每 token，一次补全生成 200 个 token，光在 decode 阶段就要 6s 到 12s。
所以优化推断侧要“双线作战”：用缓存和 prefill 优化压 TTFT，用投机解码和量化压 TPOT。只优化任何一侧，用户体验都不会有质的改变。
3.2 Prefix Caching 和语义缓存：两条完全不同的缓存路线
先说明一下，这里有两个“缓存”，别搞混。
Prefix Caching（前缀缓存），也叫 KV Cache 复用。核心想法是：如果请求 A 的前半段和请求 B 的前半段完全相同，那这一段算出来的 KV 向量可以直接复用，省掉 prefill 阶段一大半计算。代码助手场景下，用户的系统提示词、常用工具说明、甚至同一个项目的静态文件骨架，本来就是重复出现的，非常契合前缀缓存。
技术落地上不同框架叫法不一样。我以本地部署时最常用的方案举例，vLLM 的 automatic prefix caching 开一个开关就能启用，原理是把 KV Block 按前缀树组织，命中后直接跳过 prefill。实测在我们的场景里，命中率能到 40% 左右，TTFT 直接下降 50% 到 60%。前缀缓存的价值怎么强调都不过分，而且它是所有优化项里性价比最高的一项，几乎零风险。
语义缓存则完全不同，它缓存的是最终结果，而不是中间状态。流程是：新请求进来，先做一次向量化，和历史请求做语义相似度比对，如果足够相似，直接返回缓存的历史回答，压根不进模型。
语义缓存在聊天类助手场景效果很好，但在代码助手里要非常谨慎。代码生成请求的相似度高往往不代表结果可用——用户问“帮我写一个合并两个列表的函数”和“帮我写一个合并两个字典的函数”，语义相似，但回答绝不能一样。我做语义缓存时限定了一个很苛刻的前提：只缓存涉及内容完全确定、不依赖当前文件的通用请求，比如“解释一下这段代码的算法复杂度”“列出这个 shell 命令的常用参数”。即便如此，命中率也不算高。我的建议是：语义缓存可以上，但别指望它是主力优化手段，更多的收益还是来自前缀缓存。
3.3 投机解码：用便宜模型猜，用大模型验
投机解码（Speculative Decoding）的思路听上去有点像“作弊”：先用一个又快又便宜的小模型一口气生成一批候选 token，然后再让大模型一次性验证这些 token 的对错。验证的过程和生成是同一套计算，但因为把 N 次串行解码变成了 1 次并行验证，时间就省下来了。
为什么这个方案对代码场景特别友好？因为代码有很强的局部规律性——缩进风格、变量命名、常见 API 调用序列、函数结尾的括号，都是高度可预测的。便宜模型在这种“顺理成章”的位置往往表现不错，接受率就高；即使预测错了，大模型也能立刻纠正，不会出现错误累积的问题。
我在项目里用的是 “一个小模型 + 一个大模型” 的组合：小模型 1B 到 3B 规模，大模型 7B 到 13B 规模。小模型每次生成 5 到 8 个候选 token，大模型并行验证。实测在补全任务上，端到端 TPOT 提速 1.8 到 2.3 倍，且生成质量基本无损。
不过扰动点也很明显：候选长度设太长会浪费算力，设太短提速有限。这个参数需要针对你的模型组合做网格搜索。另外有一点容易忽略——投机解码在 batch 场景下不一定能提速。当一批里同时有几十个请求时，大模型本来就被塞得很满，小模型多出来的那点候选生成反而成了负担。所以我会建议：单请求或小并发场景果断开投机解码，高并发场景要实测后决定开关。这个取舍必须写清楚。
3.4 量化：INT8 和 INT4 在代码生成上的真实体感
量化是给模型权重减肥。7B 模型 FP16 权重大概占 14GB 显存，INT8 能降一半左右，INT4 再降一半。显存小了，能装进同一个显卡的模型就大了，或者同一张卡能塞的并发请求就多了，而且 INT4 在部分架构上有专门的低精度算力单元，推理速度也会有收益。
但代码生成是 NLP 任务里对量化相对敏感的场景。代码对 token 的精度要求很高：一个符号错了，编译器就报错；缩进错了，整个块就乱了。我在一个 7B 代码模型上做过对比，INT8 量化后补全结果的编译通过率下降大概 1%，可以接受；INT4 量化后编译通过率下降 3% 到 5%，而且生成的代码经常在函数定义边界处出现“似是而非”的残缺结构。
所以我的判断是：如果目标只是降低显存占用、提升并发能力，优先上 INT8，并且要跑一遍你们自己的评测任务集来确认质量损失在容忍范围内。如果追求极致 TPOT，INT4 可以试，但必须设置一个质量和速度的权衡阈值，不能无脑启用。
量化还有一个容易踩的坑：它本质上是在模型推理服务里做的，和训练、微调是两条线。如果你提前对模型做了 LoRA 微调，量化操作要在微调后的模型上进行，不能拿基础模型量化的结果直接套用，否则 LoRA 权重和量化权重不匹配，输出会彻底崩掉。
4. 落地实战：从链路打点到评测集再到灰度下线
4.1 第一步：全链路插桩，没有指标就没有优化
我在做性能优化之前先花了整整两天做打点插桩，覆盖的链路节点包括：请求进入网关时间、prompt 组装完成时间、送入推理引擎时间、prefill 结束时间、首个 token 返回时间、最后一个 token 返回时间。每个节点都记录模型名、输入 token 数、输出 token 数和耗时。
插桩之后才能回答几个基本问题：当前 p50/p95 的 TTFT 是多少？TPOT 是多少？输入长度分布长什么样？输出长度分布长什么样？哪里占的时间最多？没有这些数据，后面的每一个优化决策都是拍脑袋。
实际数据给了我不少意外。比如我们原本以为输入太长是 TTFT 慢的主因，打点后发现 p95 的输入长度的确很高，但真正拖垮用户体感的恰恰是那批输入特别长、RAG 还召回了一堆无用片段的请求——全链路跟着这些“重量级请求”一起变慢。后来做了上下文预算收紧和前缀缓存，p95 的 TTFT 直接从 4.2s 降到了 1.5s，这个数据对比让我意识到：优化的优先级必须由数据来指挥。
4.2 第二步：搭一个贴着自己业务场景的评测集
性能优化最怕的就是没有对照。我在项目里搭了一套 500 条真实编码任务的评测集，覆盖补全、解释、重构、写单测、修复 bug 五类高频操作。每条任务都记录文件路径、当前光标位置、代码 snippet、应有的行为描述。
这套评测集的用法有三个：
- 优化前后跑一遍，看生成质量有没有回退；
- 量化开关、投机解码开关分别开和关，横向对比速度和质量；
- 上线前作为门槛卡点，质量不达标就不准发。
质量评估不能只看人眼。我加了几个机器指标辅助判断：生成结果的编译通过率、单测通过率、是否可以自动格式化。这些指标比“看起来像不像”要硬得多。尤其对量化这种可能悄悄损伤质量的优化项，评测集是唯一能拦住你犯错的防线。
4.3 第三步：灰度发布和开关设计
性能优化跟功能开发有一个很大区别：性能优化的影响是全局的，一旦出问题，所有用户一起受影响。所以我坚持所有优化都做成配置开关，通过配置中心动态下发，灰度比例从 1%、10%、50% 逐步提升，每一步都观察核心指标。
灰度期间重点观察的不只是延迟指标，还有几个容易忽略的副作用：
- 摘要树切到新的压缩策略后，多轮对话的生成质量有没有下降；
- 投机解码在 batch 高峰期是否变成负优化；
- 前缀缓存在不同输入长度分布下命中率是否稳定。
每一个优化项我都设定了回滚条件。比如投机解码如果发现 p95 TPOT 不降反升超过 20%，立即全量关闭；语义缓存如果发现类似请求的回答准确率低于阈值，立刻降低相似度匹配门槛或者干脆下线。性能优化不是“上了就一直开着”，它是一组可以被随时验证和撤下的开关。
4.4 第四步：服务端容量和成本测算
性能优化不只是体验，还得算账。我整理了优化前后的成本对比，给大家一个参考维度：
| 优化项 | 主要收益 | 额外成本与风险 |
|---|---|---|
| 上下文预算拆分 | 输入 token 减少 40% 到 60% | 需做文件结构化解析，增加少量 CPU 开销 |
| 摘要树压缩历史 | 长对话输入减少 30% 到 50% | 需维护摘要生成队列，可能造成短延迟 |
| RAG 相关片段截断 | 无关 token 减少，质量上升 | 重排序模型增加部分耗时，需要控制 |
| 前缀缓存 | TTFT 下降 50% 到 60% | 命中率依赖请求前缀相似度，需监控 |
| 投机解码 | TPOT 提升 1.8 到 2.3 倍 | 批量高并发时可能拖慢整体，需开关控制 |
| INT8 量化 | 显存减半，并发能力提升 | 可能带来 1% 左右质量回退，需评测集把关 |
输入 token 少的直接效果是成本下降。按 token 计费的商用模型，输入侧节约 50%，意味着同样的预算可以服务几乎两倍的请求量，这对任何想把代码助手规模化的团队都很重要。推理侧的优化则直接反映在延迟的体感上，用户从“等得烦躁”变成“流畅跟手”，愿意把助手真正嵌入日常开发流程的比例也会明显上升。
5. 实测数据与调参经验：什么值得做，什么需要谨慎
5.1 我们的一组真实对比数据
为了不让文章停留在推演，我贴一组我们内部测试的典型数据。测试环境是单张 24G 显存的消费级显卡，模型为 7B 代码模型，输入长度平均 6K token，输出平均 150 token：
| 配置 | TTFT (p50) | TTFT (p95) | TPOT (p50) | 备注 |
|---|---|---|---|---|
| 基线（无任何优化） | 960ms | 4.2s | 42ms | 输入长时 TTFT 严重恶化 |
| 上下文结构化 + 预算限制 | 780ms | 2.3s | 42ms | 输入 token 下降 40%，TTFT 改善明显 |
| 加上前缀缓存 | 380ms | 1.5s | 42ms | 前缀命中场景 TTFT 下降约 60% |
| 加上投机解码 | 380ms | 1.5s | 22ms | 补全类任务 TPOT 提升 1.9 倍 |
| 加上 INT8 量化 | 360ms | 1.4s | 20ms | 编译通过率下降约 1%，可接受 |
从这组数据能明显看到，优化收益最大的是前两步：上下文结构化压缩和前缀缓存。它们一个减少了输入量，一个省掉了重复计算，双管齐下把 TTFT 从 960ms 压到了 380ms。投机解码在单请求低并发的补全场景表现非常漂亮，但 batch 到 8 个并发以上时收益就开始打折，batch 到 16 时基本持平，甚至略差。这在选型时要注意场景差异。
5.2 调参过程中最有价值的几个经验
上下文预算的比例不是固定的。我一开始把当前文件上下文给到了 12K，结果发现用户真正密集修改的文件平均只有 3K 到 5K token，余量全被浪费了。后来改成 8K 预算、按需扩充，反而让模型在关键函数上更专注。预算不是越大越好，而是越精准越好。
摘要树的相关性复活阈值我调了很多轮。阈值设高了，旧消息复活太少，长对话还是要丢上下文；阈值设低了，每次请求都带出一堆旧片段，预算形同虚设。最后确定了一个比较稳的策略：只有当当前请求与旧消息涉及相同文件路径、并且意图动词有重合时才复活，这个条件比单纯算语义相似度精准得多。
投机解码的候选长度我也做过一系列对比：候选长度 4 时，接受率高但提速有限；候选长度 8 时，端到端提速最大；再往上到 16，小模型预测的“幻觉”增多，大模型否决率上升，收益反而下降。实测下来 6 到 8 是甜点区间，不同模型组合需要重新扫一遍。这类参数没有一劳永逸的答案，但值得你在自己的环境里花半天做一次网格搜索。
5.3 哪些做法看似合理但实测不靠谱
我踩过几个坑，写出来帮大家避雷。
第一个是过度压缩当前文件上下文。有段时间为了省 token，我把当前文件上下文只保留函数签名，不保留实现。结果模型生成的代码到处调用不存在的变量，因为这些变量明明定义在函数体里。后来调整为“函数签名 + 当前函数完整实现 + 相邻依赖签名”，质量才正常。上下文管理要在“信息完整”和“token 有限”之间找平衡，不能一味求省。
第二个是对话历史整段摘要化。早期我图省事，把一个长对话的历史一次性压成 500 token 的摘要。表面看没问题，但用户一旦追问“你刚才说的那个 XX 函数改动怎么处理”，模型完全对不上号，因为摘要里根本没有具体的函数名。后来加了关键词索引和原文复活才解决。摘要适合压缩讨论过程，不适合替代关键结论和具体符号。
第三个是对量化过于乐观。我之前写过一个 13B 模型，量化到 INT4 后显存够用了，速度也好看了，但实测代码逻辑错误率升高，尤其涉及多层嵌套和类型判断的场景经常出现语法残缺。用户不一定能说出具体哪里错了，但能明显感觉“生成的东西不如以前聪明”。所以量化一定要跑一遍评测集，而且要跑你们自己的代码场景，不能拿通用数据集当结论。
第四个是忽略多轮对话的 token 超时。代码助手很多时候是常驻工具，用户会连续提问十几分钟甚至更久。如果服务端对长连接请求设置了超时，性能优化做得再好，用户也会在长对话后端起遇到“请求超时，请重试”。我在灰度阶段专门压测了 30 分钟以上的持续交互，确认超时阈值足够大，并且对超长请求做了分段处理，才敢放开全量。
5.4 边界情况：这些场景必须单独处理
有一类很麻烦的边界情况：用户请求里夹着超长的代码块、日志输出或者终端返回。这类内容既占窗口又难压缩，直接截断又可能截在关键位置。我的处理方式是先按语法结构分段，标记出“疑似完整段落”，再按 token 预算从后往前填充；如果一段太长，就只保留它的头尾各几行，中间标上省略标记。这样模型至少能看到关键上下文，不会因为整段丢失而完全跑偏。
另一个边界是并发高峰期的降级预案。性能优化做完了，服务资源还是有限的，总会有某一瞬间请求量超过承载能力。我在服务端设计了弹性降级：当排队长度超过阈值时，自动关闭投机解码、降低检索片段数量、切换到更小规模的模型。这些降级策略的优先级要提前排好，避免高峰期出现“所有请求都卡住”的最坏情况。
6. 写在最后的实操建议
整个项目做下来，我对代码助手性能优化最大的体感是：大部分收益来自工程侧的“瘦身”和“复用”，而不是模型本身的升级。
上下文窗口优化的本质，是让每次请求都更“干净”——不相关的全文、多余的历史、无用的检索结果，统统尽量避免进入模型眼里。推断加速的本质，是让模型算得更“省”——缓存已经算过的、让便宜模型先猜、用量化压缩权重。这些工作没有一项需要重训模型，也没有一项依赖特定硬件，任何做代码助手的团队都可以按同样的思路推进。
如果只能选两件事先做，我的建议是：先做上下文预算拆分，再做前缀缓存。前者让整个链路的输入结构变健康，后者用最小的改动换来 TTFT 最明显的下降。这两步做完，你的代码助手很可能已经从“难用”变成了“大部分时候能用”。之后再按需上投机解码、量化、摘要树，每一步都带着评测集去验证，稳扎稳打，大概率不会翻车。
最后分享一个小技巧：我把所有优化项的参数都做成了配置中心的动态配置，线上随时可调。有一次灰度后发现某个场景的补全质量异常，我直接在配置中心把摘要树的相关性阈值调低一档，两分钟内就恢复了正常，完全不需要重新发版。性能优化不是一次性的项目，而是一套可持续迭代的机制。把开关、指标、评测集这三样东西搭好，后续的每一次优化都会变得越来越轻松。
