AI 补全（或行内建议）最迷人的地方，是它常常「猜对你下一句」。最烦人的地方也是这个——它猜对下一句时，也可能把你带离本来要开的那条路。
我不是补全黑名单派。体力活、重复模式、测试样板，我开着很香。但这篇文章想写清楚：哪些时刻我会主动关掉或忽略它，以及为什么「一直开着」会偷偷伤到设计质量。写给那些已经习惯 Tab，却说不清「这段到底是我想的还是它推的」的人。
抢方向盘是什么感觉
典型场景：
你正要抽一个接口，光标停在名字上，它已经按旧习惯补出一个「很大很全」的方法签名
你在探索两种方案，它持续把你推向仓库里更常见的那一种
你想写个丑但明确的临时实现，它不停建议「更优雅」的抽象
命名还没想清，它已经用空心词把名字钉死了
你只是停顿两秒想逻辑，灰色建议已经铺满半屏，注意力被撕成两半
单独一次接受建议，成本很低。连续接受，你会发现：路线是它用局部最优拼出来的，不是你用全局判断选出来的。
图：补全抢方向盘：局部下一句最优 vs 全局路径选择（原创示意图）
我什么时候会关（或全力忽略）
1. 设计关键路径时
涉及边界、一致性、失败语义、权限模型时，我需要慢思考。补全的节奏是「快确认」，和「慢设计」冲突。
做法：关掉行内补全，或改成只在显式触发时出现。让光标安静一会儿，比让它替你填完三个方法更值。关键路径上的错误建议，修正成本远高于多敲几分钟。
2. 命名关键决策时
公开 API、模块名、核心领域词，一旦补全带着你走，后续全仓库都会跟着错名扩散。命名阶段我宁可自己敲，或单独开对话要「候选」，而不是接受行内第一个建议。
行内补全给名字时特别危险：它优化的是「像不像常见代码」，不是「像不像你们领域的准确词」。
3. 探索期 / 方案未定时
探索的价值是保留分叉。补全喜欢把分叉收束到「最像训练分布」的那条。探索期我常关补全，先把两种丑实现都写出来对比，再决定。
4. 在读代码而不是写代码时
有些工具在只读浏览时也会弹建议，挺干扰。读的时候我要的是注意力在已有逻辑上，不是「你还可以这样改」。
一句话：方向未定，先关；方向已定，再开。
什么时候我反而会打开
补全真正赚到时间的地方：
写测试样板、构造数据、重复断言
按已有模式补对称代码（左边有
if，右边该有对应分支）填明显的样板：日志字段、DTO 映射、枚举分支
你已经想清楚，只是手慢
在非常一致的代码风格里做机械扩展
这时补全像一个打字员，不是一个产品经理。我欢迎打字员，警惕擅自做产品决策的打字员。
图：开关策略：关键路径关、体力活开、探索期关（原创示意图）
「开着但不当真」为什么不够
有人说：我不关，我不接受就行。理论上对，实际上难。
原因很土：
建议一直闪，会占工作记忆
灰色文字会诱使你「顺手 Tab」
连续顺手之后，你事后很难回忆「哪一段是我想的」
评审时说不清设计动机，因为动机被建议稀释了
我试过「开着但严格不 Tab」，两小时后发现自己还是点了好几次。不是意志薄弱，是界面在训练你的反射。真正关键的段落，物理上关掉更省事。
还有一个隐蔽成本：你为了「不接受建议」而额外消耗的抑制力，本来可以用来想问题。关了之后，抑制力解放回来，设计反而更顺。
和心流的关系
写代码的心流有两种：
实现心流：目标清晰，手在追想法
设计心流：目标还在成形，需要空白
补全对第一种往往是助推，对第二种常常是噪音。很多人把「写不快」怪在自己头上，其实是第二种心流被第一种工具打断了。
我的做法是按任务切模式：开设计文档/草图时关补全；进入「按清单实现」时再开。像开车换挡，不是道德问题。
一个可操作信号：如果你发现自己在「等建议出现再决定写什么」，说明已经从驾驶变成副驾了。这时候关五分钟，通常能把主语找回来。
团队里怎么谈这件事
如果你是团队里唯一关补全的人，有时会被问「是不是不信任 AI」。我会这样说：
信任的是它在样板上的速度
不信任的是它在未定设计上的自信
关工具是为了保护决策质量，不是复古
也可以在规范里写清楚：公共 API、安全相关、钱相关路径，建议关闭自动补全或必须人工命名。把「何时关」变成团队习惯，比靠个人意志稳定。
新人培训里我也会提一句：先学会在关键处关掉，再追求处处加速。速度建立在方向正确上，不是建立在 Tab 次数上。
图：两种心流：设计要空白，实现要加速（原创示意图）
几个可执行的小设置（经验向）
不同编辑器名字不一样，原则可共用：
默认关行内建议，用快捷键按需触发
或：只在注释/字符串外延迟更久再弹出
对
*.md设计笔记、ADR 文件直接禁用接受建议后立刻看 diff 高亮，确认不是「顺手整段」
大型重构分支上，可以阶段性全局关闭，完成关键提交后再开
我不追求统一配置，只追求：关键文件的默认态是安静。
另外还有一个心理技巧：把「Tab」从肌肉记忆里拿掉一段时间。哪怕只坚持三天，你会重新感觉到「我想写什么」和「它想让我写什么」的差别。差别一旦可感，开关策略就不再抽象。
关补全不等于拒绝 AI
澄清一下：关行内补全，不等于不用 AI。
我仍然会：
把难题丢到侧边对话里讨论
让它生成候选实现，我挑选
让它写测试草稿，我删改
让它做代码搜索与解释（带着证据要求）
差别是控制权在谁手里。对话里我提问、我筛选；行内补全则是它持续抢答。关键时刻，我需要提问权，不需要抢答器。
也可以说：对话是拉出建议，补全是推进建议。拉出可以比较；推进更容易绑架。
一次我被带偏的复盘
有次做权限校验重构，我开着补全一路 Tab。它很勤奋地把「角色校验」补成了仓库里更常见的「角色 + 资源 + 动作」三元组风格。本地看着很统一，也更能展示「完整」。
评审时同事问：这个动作维度产品定义了吗？没有。于是我们撤回，回到「先只做角色」。补全把「常见设计」当成了「当前需求」。局部下一句确实更像成熟系统；全局却提前引入了未决议的概念。
复盘后我给自己加了一条：涉及领域模型扩展时，先关补全，先写最小可合并，再考虑完整。完整感应来自需求，不应来自建议引擎的热情。
另一次更小：写临时脚本，它不停建议我抽工具类、加配置层、写漂亮的 CLI。我当时要的只是跑通一次数据修复。接受了两段建议后，脚本变「像样」了，也变难删了。临时东西被补全劝成半永久组件——这也是抢方向盘。
收尾：方向盘还是你的
AI 补全是很好的副驾驶，但副驾驶不该在路口替你打满方向。
我的总原则很短：
命名、边界、方案分叉：关
样板、对称、测试体力：开
拿不准时：先关，想清再开
工具默认开启，不代表你的大脑也要默认出让。下次当你发现自己连续 Tab 却说不清为什么这样设计，试着关掉五分钟。安静有时不是效率损失，是把方向盘拿回来。
如果你只记住一句：补全擅长续写，不擅长替你决定「该不该开这条路」。路还是你选，它最多帮你把油门踩稳。
2026-10-15鱼鱼