代码补全 模型 和 对话模型 怎么分工

很多团队接完 API 之后会卡在一个具体问题上：编辑器里那个自动补全的模型，和聊天窗口、Agent 里那个模型，到底该用同一个还是分开用？用同一个省钱但体验别扭，分开用又怕维护两套配置。这篇不讲模型能力排名，只讲工程上怎么划边界：哪些活必须交给补全模型、哪些必须交给对话模型、什么时候可以合并、怎么验证分工有没有效果。

接完 API 之后，很多团队会卡在一个很具体的问题上：编辑器里那个自动补全的模型，和聊天窗口、Agent 里跑的那个模型，到底用同一个还是分开用？用同一个省钱但体验别扭，分开用又怕维护两套配置、两套 key、两套监控。

这篇不评模型能力，只讲工程上怎么划边界：哪些活必须交补全模型、哪些必须交对话模型、什么条件下可以合并、合并之后怎么验证有没有翻车。判断标准比结论重要，因为每个团队的代码库和节奏都不一样。

先按任务类型划一条线：谁适合补全，谁适合对话

最省事的划分方式是看「用户有没有提问」。用户没提问，只是手在键盘上敲，那基本都是补全模型的活；用户明确打了一句问题，期待一段成体系的输出，那基本是对话模型的活。这条线看着糙，但能挡掉八成争议。

中间地带是纠纷最多的地方。行内改写、给一段代码补注释、变量重命名建议，这类活补全和对话都能干。如果团队更怕编辑器卡顿，就丢给补全；如果更怕改错语义，就丢给对话，哪怕多等两秒。

• 只有一套 key 时，优先保证对话通道可用，补全降级成对话模型的低配调用；
• 反过来把对话丢给补全模型的参数，体验会明显别扭，回答短、不追问、解释不清；
• 两端不要共用同一套超时和 max_tokens，改一端会误伤另一端；
• 把「是不是有提问动作」做成路由判断的第一条件，比按工具来源判断更稳。

延迟和成本是第二条线：补全吃频次，对话吃长度

补全请求一天可能上千次，单次输出就几十 token，对首字延迟极敏感，但对单价没那么敏感——因为每次都很小。对话请求一天几十次，单次几千 token，对单价敏感，但对首字延迟容忍度高，用户愿意等它想清楚。

所以两家别拿同一个模型档位去扛。补全用快而小的一档，对话用你能接受的最强一档。具体哪一档、当时单价多少，去 AI 模型库（/models） 和 官方 API 价格（/official-api） 核对当时的数字，本文不写死任何价格。

怎么把分工落到配置里：路由、参数和降级

分工不能只写在文档里，要落到调用层的场景路由上。按请求来源打标：编辑器来的走补全通道，聊天窗和 Agent 来的走对话通道。别让两端共用一套超时和 max_tokens，否则改一端就会误伤另一端。

1. 在调用层加场景标记每个请求带上 source 字段（editor / chat / agent），日志和账单都按这个字段聚合，后面拆账才拆得动。
2. 分开设参数补全一般要短超时、小 max_tokens、低温度；对话要长超时、大 max_tokens、按任务调温度。具体数值按 接口测速（/tools/speed-test） 量出的基线定，不要拍脑袋。
3. 写清降级顺序补全通道挂了就静默降级到对话通道的小档，宁可慢一点也不能让编辑器卡住；对话通道挂了要么排队要么明确报错，不要偷偷换弱模型交付一个看着对、实际错的答案。
4. 验证路由生效故意断掉补全通道，看编辑器是否还能用；再断掉对话通道，看聊天窗是否明确报错而不是静默变傻。

用中转站的团队，可以多看看是否支持多模型路由和自动降级，在 中转站目录（/sites） 里筛带路由能力的方案。接之前先把 base url 和鉴权按客户端配置流程跑通，再谈分工，否则基础都没通，分工是空话。

分工有没有效，用这几个观察点验证

分工不是拍完就完，要能验证。别只看调用量，调用量高不代表用得好，可能只是白烧钱。下面几个点比调用量更能说明问题。

• 看采纳率：补全的采纳率长期偏低，说明模型和你们代码风格不合，换档位比加频次有用；
• 看返工率：对话模型给出的改动被 reviewer 打回的比例高，往往是任务分错了，本该拆成补全加人工确认；
• 看延迟分布：补全首字延迟如果经常超过敲键盘的节奏，再准也没人用，定期去 接口测速（/tools/speed-test） 量基线；
• 看失败表现：补全失败是静默降级还是卡死，对话失败是排队还是给错答案，这两种失败模式的处理优先级不一样。

把这些指标和用量一起放到一个面板上，用量口径参考 真实用量榜（/usage） 的统计方式，别只盯单次价格。单次价格低的通道如果采纳率差，实际总成本反而更高。

什么情况下这套分工不适用？如果团队人数很少、代码库很小、编辑器插件本身就把补全和对话打包在一起，那强行拆两套反而增加维护负担，可以先共用一条通道，但保留场景标记，等用量上来再拆。