自动补全心智模型与接受策略
一句话定义
自动补全是模型基于当前文件与光标上下文做的「高概率续写」，正确用法是把它当打字加速器而非正确性来源，用显式的接受策略控制采纳。
为什么重要
补全是多数人接触 AI 编程的第一个入口，也最容易建立错误习惯：无脑连按 Tab、整段接受不读、被灰影文本牵着走。补全的速度优势只在「你本来就会写、它帮你写得快」时成立；一旦你不假思索接受，审查成本被推迟到调试期，总成本反而上升。建立正确心智模型能让补全命中率高的场景吃到红利，同时保住代码质量。
前置知识
kp-001（AI 辅助编程的版图与核心术语）。
核心概念
- 概率续写本质：模型预测「下一个最像的 token」。它没有「理解你的需求」只有「统计上最可能的续写」。
- 强先验场景：重复模式（循环体、getter/setter）、约定俗成结构（测试断言、JSON 解析）、紧邻上文已有的模式复制——命中率高。
- 弱先验场景：业务规则、架构选择、边界条件、安全逻辑——模型只能猜，命中后也需逐行验证。
- 上下文敏感性：补全质量主要取决于光标周围的「可见材料」：已打开文件、函数签名、命名风格、注释。
原理与机制
模型每次补全都重新基于当前上下文计算，因此「先给结构再要血肉」能显著提升命中：先写函数签名和 docstring，再让补全填实现；先写空测试骨架，断言体更容易被补全猜中。反之，在空文件里等待「整个功能」的补全，等于让模型无据可猜。理解这一点后，你就掌握了引导补全的主动权：上下文是你写的，补全是你引出来的。
实例或案例
Before（差上下文）：新建空文件，光标停第一行，等补全出整个导出功能——模型只能产出泛泛的模板，变量名、错误处理全靠猜。
After（好上下文）：先手写骨架再触发补全：
def export_orders(orders: list[Order], path: str) -> ExportResult:
"""导出订单为 CSV；金额分转元保留两位；失败返回 ExportResult(ok=False, error)。"""
# 校验 orders 非空且每条含 id/amount_cents签名 + docstring + 起始注释给出强约束，后续实现大概率被正确补全。
操作步骤（接受三问，每次多行接受前过一遍）：
- 方向对吗——这段补全在解决我当前的问题吗？
- 名字对吗——变量、函数、字段名与项目既有命名一致吗？
- 边界对吗——空输入、异常路径、越界情况处理了吗？
- 任何一问答不上来，只接受首行或手写。
排错清单（补全质量差时逐项检查）：
- 相关文件没打开 → 打开 2-3 个最相关的上下游文件再试。
- 函数签名太含糊 → 补全类型标注与 docstring。
- 命名风格混乱 → 先统一命名，模型会跟随你的风格。
- 上下文里全是无关代码 → 关掉无关标签页，减少干扰。
- 等整段功能 → 改为先写骨架再补实现。
公式或模型
本节不适用：补全质量目前没有可靠的闭式度量，用主观命中率记录即可（kp-026 的采纳率可作粗代理）。
图示
本节不适用：概率续写机制已用文字说清，图示无增量信息。
直观类比
补全像一位极快的听写下一位：你说上半句它抢答下半句，熟人口吻（强先验）猜得很准，新话题（弱先验）就是瞎接话——你要么给足上下文，要么自己说。
常见误区
- 把补全当正确性来源：它对「像不像」负责，不对「对不对」负责。
- 整段接受不读：审查成本不会消失只会延后，且延后时代价更高。
- 用补全做架构决策：弱先验场景应切换到对话层（kp-003）讨论后再落地。
与其他知识点的关系
kp-003 是补全失效后的正确升级路径；kp-004 解释为什么上下文决定补全质量。
自测题
要点：重复模式与紧邻上文可复制的结构；因为概率续写依赖上下文中的强先验。
要点：方向对吗、名字对吗、边界对吗；任一存疑只接受首行。
- 哪些场景补全命中率高？为什么？
- 「接受三问」是哪三问？
延伸阅读
《The Pragmatic Programmer（20 周年版）》Hunt & Thomas——「把关你提交的每一行」的原则同样适用于 AI 产出。