Twinny 4.3.6 & 4.3.7：智能补全与架构优化双管齐下
Twinny 团队在 2026 年 10 月连续发布了 4.3.6 和 4.3.7 两个版本。虽然更新日志简短，但这两次发布分别解决了开发者日常使用中遇到的两个痛点：代码输入的流畅度与多仓库协作的 Token 管理效率。
核心突破：本地化与 LLM 混合的智能补全
在 4.3.7 版本中，Twinny 的 Chat Composer 引入了全新的“幽灵文本”（Ghost Text）功能，灵感源自现代代码编辑器。
混合驱动机制
该功能由两部分组成，分别处理不同层级的预测：
- 本地词库预测：基于用户历史 Prompt 构建的词表，运行在客户端本地，不上传任何数据。它利用大五子棋算法（Bigram）预测下一个词，并保留大小写格式。
- LLM 辅助预测：仅在对话产生回复后介入。当用户输入特定标点（空格、逗号等）并停顿 500ms 后，系统会将草稿截断（400 字符）连同上下文发送给 Chat Provider。
隐私优先的设计
这是一个关键的隐私边界：
- 本地部分：完全离线，仅使用本地存储。
- 云端部分：仅发送截断后的草稿片段，且请求中明确关闭了
thinking和temperature，确保生成的是纯文本补全而非完整回答。
交互体验升级
- Tab：补全整行。
- Ctrl+→：补全单个单词。
- Esc：收起补全（首次按下不计入清除草稿的两次按键限制）。
架构优化：认证与 Token 管理重构
1. 开发者认证防滥用 (4.3.6)
原版本中，网关对每个代理 IP 限制 5 次认证请求，导致团队共享 IP 时容易触发限制。4.3.6 通过引入 clientAddress() 函数，精准识别反向代理（如 Nginx/Caddy）后的真实用户 IP，而非代理本身的回环地址，从而解决了团队内多人同时认证被限流的问题。
2. 单 Token 多仓库复用
在 4.3.7 中，Twinny 的 Pull Request 插件进行了重大架构调整：
- 旧模式：每个仓库独立保存一份 Token，Token 过期需逐个重新添加，维护成本高。
- 新模式：引入“Tokens”面板，支持保存一个通用 Token。插件在读取权限列时自动关联该 Token，实现“一次粘贴，多仓库生效”。
实际价值
对于依赖 Twinny 进行代码审查和协作的团队，此次更新意味着：输入更流畅，隐私更安全，多项目协作的运维成本大幅降低。特别是对于使用本地 LLM（如 Ollama）的开发者，补全功能的数据完全留在本地，消除了对公有云 API 的额外依赖。
“这两次更新虽然不大，但都触及了每天使用的核心功能。我们致力于让工具变得更顺手，同时保护开发者的数据隐私。” —— Twinny 官方团队
