FIM 代码补全

FIM（Fill-In-the-Middle）补全会同时读取光标前后的代码上下文，以灰色 Ghost Text 在光标处给出续写建议，首字延迟低于 50ms，输入过程零打扰。与整块代码生成不同，FIM 专为「在已有代码中间插入片段」的场景设计。

触发方式

• 自动触发：输入停顿约 150ms 后自动发起请求（防抖间隔可通过 ide.completion_debounce_ms 调整），连续输入不会被打断。
• 手动触发：在光标处主动唤起补全，适合需要立即获取建议的场景。

每个请求都会标记触发类型（自动 / 手动），并携带当前文件路径与语言信息，模型据此给出符合语法与项目风格的建议。补全使用当前选中模型的凭据发起请求，每次最多返回 3 条候选，按评分排序后展示最优建议。

接受与拒绝

候选建议区分行内与多行两种形态，多行建议同样通过 Tab 一次性接受。

接受后的代码与手动输入无异，可以正常撤销。

工作原理

1. 编辑器提取光标处的 prefix（前文）与 suffix（后文），连同文件路径、语言一起发送给内核补全接口。
2. 内核先查询项目级缓存；未命中时按配置顺序逐个调用声明了 FIM 能力的模型服务，直到拿到候选结果。
3. 候选结果带回延迟与评分信息，最优建议以 Ghost Text 渲染在光标之后。

光标移动或继续输入时，未完成的请求会被立即中止，避免无效开销。

提供方与模型

FIM 引擎支持配置多个模型服务作为补全提供方，每个提供方都带有 supports_fim 能力标记——只有声明支持 FIM 的模型才会被用于补全。提供方配置包含名称、接口地址、模型与单次补全的最大 Token 数，多个提供方互不影响。请求按配置顺序逐个尝试，任一提供方成功即返回结果，失败自动降级到下一个。

提供方的 API Key 由内核按供应商配置在服务端解析，前端不持有明文。

性能与缓存

每个项目拥有独立的本地补全缓存（.lxz/cache/fim_cache.db）：

• 双层结构：SQLite 持久化存储 + 内存 LRU 索引，启动时自动预热最多 500 条高频记录。
• 命中零成本：缓存命中的补全不消耗任何 Token，几乎瞬时返回。
• 按频排序：缓存记录使用频率与最近使用时间，高频补全优先保留。
• 用量可见：每次补全请求都会返回延迟与 Token 用量，便于观察不同模型的实际表现；缓存命中的结果来源标记为 cache。
• 自动回写：模型返回的新结果会自动写入缓存，相同情境下次直接命中。

除自动补全外，内联编辑在不选中代码时也会以 Ghost Text 形式给出续写建议，接受与拒绝的按键完全一致。

补全质量与所选模型直接相关，详见模型与上下文；防抖等参数见配置项，完整的按键清单见快捷键。FIM 补全属于编辑器基础能力，不占用每日 Agent 运行次数。