前后文都给，模型只补 name 一个 token，命中率高、可自动测试接受。
AI 与提示 · 模型与输出
补全Completion
补全会根据已有上下文预测接下来的 token；光标在代码中间时，让模型同时看到前后文（FIM），候选更短，也更不容易重复闭合符号。
代码编辑器：光标处该补多少
补全会从已知上下文预测接下来的 token。先看编辑器里的真实候选，再比较只给前缀和同时给前后文（FIM）会怎样改变候选与测试结果。
模型看到光标前 ✓光标后 ✓
1
function greet(name) {2 return `hello, nameTab`;3}greet.test.ts等待接受候选
候选只填中间：name。接受后仍要让测试决定能否保留。
灰绿色文字是尚未写入的候选；先比较模型是否看见光标后的代码。
知识点总结
面板已经把核心关系演示出来，这里只做命名和收口。
- 补全 = 上下文 → 后续 token：候选先作为编辑器里的预览出现，接受后才真正写入代码。
- FIM 填空：前缀和后缀都给，模型只填中间；代码编辑器光标在中间时用它，输出最短最准。
- 后缀补全：只给后缀反推前面，信息最少、最不确定，实际很少单独用。
- 采样档位：低温通常更稳定；提高温度或请求多次采样可得到更多样的候选，但仍需测试筛选。
- 对话生成也逐 token 预测：chat API 会把角色、指令和消息组织成模型上下文；接口更结构化，底层仍在生成后续 token。
什么时候用补全
从你想让模型在哪儿接着写出发，决定要不要给后缀。
- 写到一半要 autocomplete：代码编辑器光标在中间——用 FIM，前后文都给，输出最短。
- 给一段开头续写正文：文章、注释、提交信息——前缀补全 + 低温，要稳定就用停止序列卡住结尾。
- 要多个点子挑一个：前缀补全 + 高温，多条候选并列，自己挑。
- 不适用：需要严格结构（JSON、函数签名）时，裸补全不可靠，应改用约束解码或结构化输出；要稳定对话体验时直接用 chat API，别自己拼 special tokens。
怎么用
从前缀走到可接受续写的最短路径。
准备前缀选模式定档位补全校验输出
- 给前缀（必要时给后缀），用停止序列和最大 token 数框住输出范围。
- 按场景选档位：确定性任务低温、创意任务高温。
- 拿到续写后先解析 / 编译 / 测试，再决定接受或重跑；不要凭「看起来像」放行。
正反例：同一个光标，模式选错结果差很多
目标都是补完 greet 函数，只改补全模式和档位。
模型不知道后面已经有闭合符号，还续出一堆右括号；高温又让它每次都不一样，无法收敛，得人工逐条筛。
快速自测
你在写一个代码补全插件，光标在函数体中间，希望模型只补当前那一行、命中率高。该怎么配？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。