企业级代码助手（补全、问答、重构）怎么落地？除了模型能力还要解决什么？

先这样答

三类任务的技术重心不同。代码补全求快：开发者敲完字符到建议出现，超过几百毫秒就开始打断心流，所以补全走小模型加激进缓存，牺牲一点准确率换延迟。代码问答求准：答错一个 API 用法比不答更糟，问答要挂检索增强，把企业内部代码规范、依赖版本的真实信息检索进来再回答。代码重构求稳：改错一行代码的代价远大于少改一处，重构任务用 Agent 循环跑「理解、修改、跑测试、修失败」的闭环，测试不过不交付。

落地要解决五件事。代码语料：把企业的私有代码库、内部框架文档、历史工单组织成检索库，通用模型对企业自研框架一无所知。安全：生成代码要过依赖漏洞扫描和密钥检测，不能把内部代码片段泄漏到公网模型，私有化或专有实例是刚需。权限：问答结果不能越权暴露用户无权访问的仓库内容，检索层要做权限过滤。延迟：补全的延迟预算最紧，架构上要区分快慢通道。度量：接受率、采纳后的留存编辑距离、开发者自评提效比例，没有度量就没有迭代方向。

面试官会怎么追问

• 「补全的接受率怎么提升？」 上下文要喂对：当前文件的光标前缀、同仓库相似文件的实现、import 过的内部 API 签名，比堆更多通用代码有效。再按语言和项目微调。接受率统计要区分「显示了、被忽略」和「显示即接受」，看漏斗。
• 「怎么防止内部代码泄漏？」 私有化部署是底线方案；用云 API 时走企业专线加零保留协议，代码分片脱敏。权限上，检索索引按仓库权限分片，问答时带用户身份过滤。
• 「重构 Agent 怎么验证没改坏？」 测试闭环兜底：改动后必须跑项目测试套件，失败回到修改步骤重试，连续失败上报人工。没有测试的项目先补特征测试再动重构，宁可不改也不能盲改。

回答的坑

• 只谈模型代码能力，不谈检索、安全、度量。企业采购问的全是后三样。
• 把三类任务混为一谈。补全和重构的延迟预算、准确率要求差着一个量级，分开设计。