进阶 11 分钟IDE

Twinny：100%代码自动补全 locale

直接回答

Twinny 是一个免费且开源的 VS Code 扩展（MIT 许可证），可通过 Ollama、LM Studio 或 llama.cpp 在您自己的机器上运行代码补全。补全当前行时，像 qwen2.5-coder:1.5b-base 这样经过中间填充训练的小型基础模型，可在不到一秒内响应。个人使用无需订阅；只有超过五名开发者的团队才涉及收费。

Twinny 是一款在本地进行代码补全的编辑器扩展：它利用由您自己的机器提供服务的模型，为您正在编写的内容建议后续代码。这是整个生态系统中对延迟要求最严格的一类工具——等两秒才出现的建议就没有用了——因此，这种场景下的模型选择遵循与其他场景相反的规则。本指南详细介绍了哪些设置能带来明显区别，以及该扩展自推出以来有哪些改进。

作者： Mohamed Meguedmi·更新于 2026-09-29·已在 Windows、macOS 和 Linux 上测试

#Twinny 的功能

该扩展一直同时提供两种功能：行内补全，在输入时显示灰色建议；以及聊天侧边栏，用于针对选中的代码提问。两者都依赖本地模型，由 Ollama、LM Studio 或 llama.cpp 提供服务，默认情况下没有任何数据离开本机。

在代码不得外传的场景中，例如专业事务所、行政机构，或受保密协议约束的客户代码，其价值显而易见。关键不在于成本，而在于「我的代码会被发送到哪里」这个问题有可核实的答案。该项目将自己定位为始终运行在您网络内部的 VS Code AI 助手。

#决定性细节：中间填充

本地编程副驾驶套件

本指南带你上手模型。工具包则帮你用上能在你的编辑器中编写代码的编程助手。

  • 在线空间，终身可用
  • PDF + 文件
  • 终身更新
本地编程副驾驶套件 →或 所有套件终身使用权 — 49 € →

补全代码不等于续写文本。当您在函数中间编写代码时，模型必须同时考虑前面的内容和后面的内容。这种能力称为“中间填充”，即 FIM（fill-in-the-middle），并非所有模型都具备。官方文档对此有明确说明：补全服务提供程序必须使用经过 FIM 训练的模型，而且不同模型家族使用各自不同的 token 来标识前缀、后缀和待补全区域。

这是最常导致失望的原因。即使是优秀的代码对话模型，如果不具备这项能力，也会给出忽略文件后续内容的补全建议，并添加文件中已经存在的右花括号。另一个很多人忽略的要点是：文档建议使用基础模型，而非指令微调版本，因为基础模型续写原始文本时的可靠性高于处理空后缀时的可靠性，尤其是在光标后没有任何内容的情况下。

→
文档推荐的模型
“使用体积小、在 GPU 上运行的基础模型。qwen2.5-coder:1.5b-base 在大多数机器上的响应时间远低于一秒。”——这是官方针对行内补全的建议。

#使体验流畅的设置

项目文档介绍的四项设置带来了大部分用户感知到的延迟改善。它们位于扩展的设置中（前缀为 twinny.），均可在不重启 Ollama 的情况下调整。

控制感知延迟的四个参数
参数默认值效果
twinny.debounceWait300 毫秒最后一次按键后、发起请求前的等待时间；增加该值可减少调用次数
twinny.numPredictFim512 tokens每次建议生成的最大标记数；减少该数值可加快响应速度
twinny.contextLength100 行光标周围传输的代码量；减少该量可降低延迟
twinny.fileContextEnabled默认关闭发送其他已打开且相关的文件中的片段（最多涉及 3 个文件）；对大型项目有帮助，但会增加延迟
  1. 01
    限制生成令牌数量
    有用的代码补全只需一两行。文档也证实了这一点：如果补全建议出现得太慢，首先应调低 numPredictFim，而不是减小模型规模。
  2. 02
    调整触发延迟
    每次输入触发都会导致服务器过载；默认 300 毫秒的延迟（debounceWait）在大多数情况下已足够，可显著减少调用次数。
  3. 03
    让 Ollama 中的模型保持加载状态
    如果服务器在几分钟无操作后卸载模型，暂停后的第一条补全建议就会来得太晚。因此，需要在 Ollama 端延长模型驻留内存的时间（keep_alive）。
  4. 04
    缩小发送的上下文窗口
    文档明确指出：如果建议内容响应延迟，可降低contextLength（默认值为光标前后各100行），或保持fileContextEnabled关闭（默认状态）。该参数仅在手动开启时才会加载其他已打开文件的片段。

#模型真正看到的内容

补全建议不仅基于光标前后的前缀和后缀。文档详细说明了 Twinny 在构建提示词之前汇集的上下文来源：周围的代码行（contextLength）；文件中最近的修改，以小型差异片段（diff）呈现（recentEditsEnabled，默认启用，最多 6 处修改）；语言服务器提供的符号和当前调用的签名（lspContextEnabled，默认启用）；以及可选的、其他已打开且相关的文件中的片段（fileContextEnabled，默认禁用）。

最近更新
尚未完成的重命名，或在一个文件中手动应用的修改模式，会延续到后续建议中，就像它理解了您正在做什么一样。
IntelliSense 上下文
模型会接收光标所在调用的名称和签名，这些信息由编辑器的语言服务器提供。
相邻文件
默认关闭：仅在大型项目中启用，因为它会增加延迟，而收益并不固定。

实践中还有一个有用的小技巧：先写一行注释，描述接下来要写的内容，然后稍作停顿，就能为多行代码建议提供明确的目标——文档本身也建议这样做，以获得更好的建议。在调整任何设置之前，给变量和函数起清晰的名称，仍然是提升建议相关性最有效的方法。

i
在您其他设备上运行该模型
除了在本地使用 Ollama、LM Studio 和 llama.cpp，Twinny 还提供设备间的直接配对功能（“Devices”）：工作电脑可通过加密的点对点连接，使用您另一台机器的 GPU，无需账户或中继。

#模型有哪些，为什么规模这么小

这里的规则与对话场景正好相反
用途推荐模型规模为什么
行内补全（FIM）15 亿至 30 亿，基础模型延迟优先：根据官方文档，qwen2.5-coder:1.5b-base 在大多数设备上响应时间低于一秒
在大型显卡上进行代码补全70亿如果显卡速度快且上下文较短（contextLength 较低），可以考虑
聊天侧边栏70 亿至 140 亿参数，指令微调模型在这种情况下，可以接受等待一份组织完善的回答；基础模型不适合对话。

这种不对称总是令人惊讶：人们习惯于认为模型越大越好。在补全任务中，一个拥有 15 亿参数、经过中间填充训练并以基础版本提供服务的模型，在实际使用中会胜过一个 140 亿参数的通用模型，因为它在您还没想完时就已经给出了回答。该扩展允许为每项功能配置一个模型——一个用于 FIM，另一个用于对话——这是合适的配置：两者的规模和训练方式都不同。

i
测量延迟，而非质量
评估补全配置时，合适的指标是建议出现前的延迟。一旦超过约半秒，无论建议内容有多切题，工具带来的干扰都会大于帮助。

#不止代码补全：Twinny 在 2026 年能做什么

该扩展最初只是一个补全插件，如今功能已大幅增加。其官方页面目前列出的功能包括：行内编辑（描述一项修改，并在编辑器中以 diff 形式审阅）；结合关键词搜索和向量搜索的工作站索引；针对工作树、分支或 GitHub pull request 的代码审查；根据暂存的修改生成提交消息；以及生成终端命令并自动纠正错误。

所有这些功能仍对应着可重新分配的 VS Code 命令和可自定义的提示词模板。在服务提供方方面，除了本地引擎（Ollama、LM Studio、llama.cpp、Oobabooga、LiteLLM、Open WebUI），支持列表还扩展到了托管 API（OpenAI、Anthropic、Mistral、DeepSeek、OpenRouter、Gemini、Groq、Cohere、Perplexity）——但并不强制使用任何托管 API：100% 本地使用仍是默认配置。

#单人免费，团队付费

个人使用时，Twinny 仍然和以往一样：它是一款采用 MIT 许可证的扩展，没有遥测，也不要求登录。只有共享团队网关（twinny-server）的开发者超过五人时才会产生费用。该网关为整个组织集中管理对各服务提供商的访问：最多五个账户免费，超过后按每个席位每月收费，并提供无需银行卡的 30 天试用。对于独自使用本地 Ollama 的开发者，上述条件均不适用，无需创建任何账户即可完整使用该扩展。

#Twinny 或编辑智能体

三类编程辅助工具
需求工具
完成当前行，无需思考Twinny — 行内补全（FIM）
按要求修改多个文件集成在编辑器中的编辑智能体（Roo Code、Cline）
无需监督即可完成一项任务在终端或容器中运行的自主智能体
在 commit 前审查代码Twinny 的代码审查功能，或一个专用的对话助手

这两种用法并不互斥。许多开发者会始终启用 Twinny 来进行行内补全——不显眼、速度快，使用专用的小模型——而在处理涉及多个文件的任务时，则切换到 Roo Code 或 Cline 这样的编辑智能体，使用更大的模型，并愿意为它的响应等待几秒钟。

#FAQ

Twinny 免费吗？+
个人使用是免费的：该扩展采用MIT许可证，开源，没有遥测，也不强制要求注册账户，所使用的模型都在您自己的设备上运行。收费仅针对由超过五名开发者共享的团队网关，30天免费试用结束后，每个席位每月6美元起。
哪种模型适合行内代码补全？+
选择经过中间填充（FIM）训练的小型基础模型，而不是对话模型。官方文档推荐 qwen2.5-coder:1.5b-base，它在大多数机器上的响应时间不到一秒，并能为接下来的几行代码提供切合上下文的补全。经过指令微调的模型或更大的模型往往响应太晚，无法在输入过程中发挥作用，即使它们在回答较长的问题时表现更好。
为什么我的补全建议会忽略文件的后续内容？+
所选模型可能不支持中间填充，或为指令微调模型而非基础模型：文档明确指出，基础模型在处理空后缀方面优于指令微调模型。请检查模型详情页及扩展程序中配置的FIM模板。
如何降低建议的延迟？+
先调低 twinny.numPredictFim（默认为 512 个 token），再调低 twinny.contextLength（默认为光标前后各 100 行）；如果项目较大，请保持 twinny.fileContextEnabled 禁用，并让模型在两次建议之间仍驻留于 Ollama 端的内存中。这些是官方文档针对用户感知延迟优先提及的设置。
需要高性能显卡吗？+
不需要，这正是好消息：一个15亿参数的补全模型只需几GB显存，即使在配置不高的硬件上也能快速响应，前提是选用专门用于FIM的基础模型，而不是通用模型。
选择 Twinny，还是 Roo Code 或 Cline 这样的代码编辑智能体？+
这两类工具并不相同。Twinny 使用小型快速模型补全当前代码行；编辑智能体则使用更大的模型，按照指令修改多个文件。许多开发者会同时使用两者，并为每种用途选择不同的模型。
Twinny 除了代码补全，还具备其他功能吗？+
是的：在最近几个版本中，该扩展新增了基于 diff 的行内编辑、工作区索引（关键词搜索和向量搜索）、对工作树或拉取请求进行代码审查，以及生成提交消息和终端命令的功能。
这份指南对您有帮助吗？

有反馈、发现了错误，或想补充说明？请告诉我们，让这份指南对每个人都更有帮助。