标准回答
一、先给出结论和背景
- 需求与指标：先澄清形态：行内补全、对话式问答还是自主修改代码的 Agent？核心指标是补全接受率、端到端延迟（行内补全通常要求 <300ms）、以及隐私合规。延迟是体验生死线。
- 整体架构：IDE 插件采集上下文 → 上下文构建（裁剪 + 仓库检索）→ 补全/对话模型 → 排序过滤 → 返回插件展示。Agent 形态另接工具调用与沙箱执行。
二、拆开关键步骤和判断点
- 上下文采集：采集光标前后文、当前文件、最近打开的 Tab、以及通过 LSP/符号定位的相关定义。仓库级用 RAG：对代码切块做 embedding 建索引，按当前光标语义召回跨文件片段，拼进 Prompt。
- 补全模型：用 FIM（Fill-in-the-Middle）训练的代码模型，输入前缀 + 后缀预测中间，天然契合补全场景。低延迟优先：选中等规模模型 + 量化 + KV Cache，必要时投机解码。可在企业私有代码上做 微调 提升仓库贴合度。
三、补上落地边界和取舍
- 排序与过滤：对候选补全按模型置信度排序，过滤语法错误、重复、空补全；做安全与许可证过滤，剔除与公开代码高度雷同的输出以规避版权风险。
- 隐私与安全：代码默认不留存、支持私有化/VPC 部署；Agent 动作（改文件、跑命令）必须在沙箱执行并经用户确认。线上以接受率、延迟分位、撤销率驱动迭代。
常见误区
⚠️ 常见踩坑
误区一：容易答偏的地方：只追模型能力而忽视延迟与上下文工程：行内补全慢于几百毫秒就没人用；同时别忽略代码隐私与许可证合规，企业场景这是硬门槛。
追问
追问 1：为什么补全要用 FIM 而不是普通自回归续写？如何构造训练数据？
补全场景光标后还有代码，普通续写只看前文会忽略后缀约束。FIM 把样本拆成 prefix/middle/suffix，用特殊 token 重排成「prefix + suffix + middle」让模型学会在给定上下文中间填空。数据可从代码库随机切分文档构造大量 FIM 样本，注意保持文档级别切分避免泄漏跨文件信息。
追问 2：行内补全要求 <300ms，如何在工程上达成？
选中等规模模型并量化；用 KV Cache 与前缀缓存复用文件上下文；限制生成长度（单行/少量行）并设早停；用投机解码加速；上下文检索与构建异步预取、随光标移动增量更新；就近部署降低网络往返，必要时端侧小模型兜底首屏。
追问 3：如何评估代码助手质量，光看接受率够吗？
接受率会被低质高接受场景误导。需补充：补全后短时间内被修改/删除的「留存率」、单元测试通过率、对 HumanEval/SWE-bench 等离线基准的功能正确率、以及对话/Agent 形态的任务完成率。线上做 A/B，关注开发者的端到端编码效率而非单点接受。
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
