自动补全（Autocomplete）是在你打字的过程中，系统实时给出后续内容候选、按一个键就能接受的功能。
很多人把它理解成“预测下一个词”，其实它预测的是一段：半个词、一整句，甚至一段函数体。做法通常是用语言模型（Language Model）根据已输入的前缀（prefix）和上下文算出候选。
打个比方，它像一位熟悉你工作习惯的助理：你刚说“帮我把这份”，他已经把“周报模板调出来”写在便签上递过来。递得早不如递得巧——想太久，你话已经说完；总猜错，你就不看他递的便签了。
体验由三件事共同决定：
- 延迟（Latency）：候选要在你思路没走远时出现，通常在几十到一两百毫秒这个量级；超过“等一下也无妨”的阈值，提示就从帮助变成了干扰。工程上靠小模型、缓存、增量推理来压缩。
- 上下文截断（Context Truncation）：模型能看到的上下文有限，编辑器往往只截取光标附近的若干行。截得太短，会漏掉文件顶部的类型定义、import，或前面刚说过的约束，补出来通顺却与项目不符。
- 接受率（Acceptance Rate）：候选被采纳的比例，比“准确率”更贴近真实价值。每次都弹三个选项、你每次都要按 Esc 取消的补全，再准也是负收益。产品会据此调整候选长度和触发时机。
| 维度 | 自动补全 | 对话式助手 |
|---|---|---|
| 触发 | 被动，跟随输入 | 主动提问 |
| 输出 | 短，就地插入 | 长，可结构化 |
| 关键指标 | 延迟、接受率 | 正确性、完整性 |
它和搜索建议（Search Suggestions）也不是一回事：后者多基于历史查询做统计排序，补全更依赖当前上下文的语义。
对从业者，优化目标不是“模型更聪明”，而是“用户更少被打断”：看延迟分布、接受率，以及用户接受后又改了多少。对普通人，补全越顺手，越容易把判断权交出去——在你不熟悉的领域，接受一个通顺但事实错误的补全，比留空更危险。具体模型能力与计费方式，以官方页面为准。