GitHub Copilot补全不准主因是上下文局限，仅依赖当前文件和光标附近代码，不自动读取未打开的import或类型定义；Tabnine则提供本地与云端双模式，本地模型响应快、隐私高但能力较弱，云端模型能力强但需联网。
GitHub Copilot 和 Tabnine 是目前最能直接提升代码生成速度的两个插件，但它们触发方式、响应逻辑和上下文理解深度差异明显——选错一个，补全结果可能从“省三行”变成“删五行”。
为什么 GitHub Copilot 有时补全不准？
它依赖整个文件+光标附近几十行的上下文，但默认不读取未打开的 import 文件或类型定义。常见现象包括：
- 写
fetchUser()时补全成axios.get()，但项目实际用的是swr或RTK Query - 在 TypeScript 中补全函数体，但参数类型推导错误（比如把
string | null当作string） - 注释写 “// get user by id”，补全却返回带硬编码 ID 的
fetch('/api/user/123')
解决办法不是关掉它，而是加一句明确约束：
/** @param id: number */
或者在函数签名后立刻写一行空注释再按 Tab，强制它聚焦当前 scope。
Tabnine 的本地模型 vs 云端模型怎么选？
它提供两种模式，影响延迟和隐私：
- 本地模型（
Tabnine Local）：仅基于你当前项目代码训练，响应快（ - 云端模型（
Tabnine Cloud）：调用远程大模型，支持多文件上下文、自然语言指令（如 “add error boundary for this React component”），但首次请求有 200–400ms 延迟
推荐配置：日常开发开本地模型；遇到复杂逻辑（比如重构旧模块）时，临时切换到云端模式，用快捷键 Ctrl+Shift+P → “Tabnine: Toggle Cloud Mode” 切换。
自定义 snippet 和 AI 补全冲突怎么办？
比如你写了 log + Tab 触发自定义日志片段，但 GitHub Copilot 同时弹出整段 console.log(JSON.stringify(...)) 建议，光标卡住。
这不是 bug，是优先级问题。VSCode 默认让 AI 补全排在 snippet 前面。解决方法只有两个：
- 禁用 AI 插件的 inline suggestion（设置里搜
editor.inlineSuggest.enabled，设为false） - 给 snippet 加前缀避免歧义，比如把
log改成zzlog，AI 模型极少匹配这种非语义前缀
后者更实用——既保留 AI 补全能力，又不让常用 snippet 失效。
真正卡住效率的，往往不是“有没有 AI”，而是补全建议出现时机和光标位置不匹配。比如你在写 JSX 时，AI 把 className 补全成 Tailwind 类名，但你项目用的是 CSS Modules —— 这时候模型没读你 webpack.config.js，你得靠 import 语句或注释主动喂它上下文。
