从 v1 到 v2：一年磨一“码”的进化路径
一年前，原 Windsurf 团队在 Wave 5 版本中推出了 Tab 功能。当时的系统包含四种核心预测能力，在用户每次按键时并行运行：
- 自动补全边打字边给代码建议
- 超级补全预测接下来的多行代码编辑
- Tab 跳转按 Tab 键在文件间快速切换
- Tab 导入自动补全 import 语句
这个初版功能当时反响很好，但后续维护因团队资源转移而停滞。现在，基于过去积累的海量预测数据，该团队对底层 Tab 模型和上下文工程/数据工程流程做了大幅重构。结果是所有指标都出现了帕累托改进（即在不牺牲接受率的前提下全面提升），其中最亮眼的数字是：每次预测平均多接受 54% 的字符。
不过，在客户测试中，团队发现一个关键问题：不同用户对“更好的补全行为”偏好截然不同。有人喜欢保守简短，有人喜欢大胆预测整段代码。没人能统一标准。
核心突破：引入“激进度”参数
为此，该团队率先在 Tab 功能中加入了可调节的“激进度”（Aggression）。这个名字有点反直觉，但在 Windsurf 右下角设置面板里就能调。这个参数直接控制模型预测代码的“胆量”——是只补全一个单词，还是直接预测整个函数体。
结合帕累托改进的模型和激进度调节，Tab 2.0 在过去几个月已完成内部测试并正式发布。下文拆解其技术实现。
上下文工程：清理“提示词毒药”
专用代码补全模型的历史可以追溯到 Kite 和 Tabnine 时代，但 GPT-3 之后，大语言模型也挤进了这个领域。Windsurf 团队在接手 Tab 代码库时，发现了一些基础但关键的优化空间。
最直接的改动是系统提示词（system prompt）。早期版本里，团队直接照搬了已停用的 Cascade 模型提示词，其中包含大量工具调用示例和冗余描述。通过提示词工程，系统提示词前缀长度直接缩减了 76%。这不涉及高深算法，但直接降低了成本、缩短了首 token 响应时间，并提升了模型性能——因为去掉了无关内容。
行业内把这种现象叫“上下文投毒”（context poisoning），但这是最表层的问题。更深层的优化需要逐 token 审视数据。团队利用 Cognition 内部工具做了大规模数据分析，修正了用户光标位置的表达方式，并增加了相关文件上下文，让模型更准确理解用户意图。
重新定义目标：从“接受率”到“激进度”
过去，代码补全模型的市场宣传几乎都盯着接受率（Accept Rate）：预测被采纳的比例。接受率高=预测准=好模型。但这个指标有个盲区：接受率可以被人造得“虚高”。
隐藏的变量是预测频率。如果把模型信心阈值调得极高，让它一小时只预测一次，那每次预测几乎必被接受，接受率接近 100%——但用户体验是灾难。Tab 必须“常开”，所以团队坚持保持预测频率不变（除防抖逻辑外）。
真正衡量补全模型价值的指标，是它帮用户总共写了多少代码（或删了无效代码）。这取决于两个变量：接受率 × 每次预测的字符量。这就引入了一个优化难题：预测更多代码（“更激进”）会增加被拒绝的风险，但如果风险踩得准，存在一条“黄金路径”——既预测更多代码，又保持甚至提升接受率。团队的目标是帮用户节省尽可能多的按键，而不是玩接受率数字游戏。
“激进度”这个名字来自用户访谈中描述“坏行为”时的自然用语。太激进的模型会“过度聪明”，比如用户输入 def，它直接预测完整函数体以让代码“可运行”。这是大多数代码大模型在强化学习阶段被训练出的偏好——假设代码必须能跑。但补全场景里，用户可能只想要一个函数名。这个奖励欺骗（reward hack）在 Tab 模型中必须被约束。
训练 Tab v2：强化学习中的试错循环
上下文管道的修复直接影响了数据管道的搭建方式，让训练过程能更精准捕捉用户编码模式。随后，团队启动了针对新 Tab 模型的强化学习（RL）训练——这其实是后来 SWE 1.5 所用的 RL 基础设施的首次实战。
训练初期就暴露了“激进度”训练的难题：模型容易学会“为预测而预测”，输出大量用户不需要的代码。团队进入了一个迭代循环：不断调整奖励函数和训练回路，同时在评估数据中加入“高品味开发者直觉”指标，即：一个有经验的工程师看到这段补全，会不会觉得“这就是我想写的”？
经过多轮 A/B 测试，团队验证了 Tab v2 在用户成功率上对 v1 实现了帕累托改进。激进度参数让用户能自行选择“保守”或“大胆”，最终接受率提升 25%-75%，具体取决于用户偏好和场景。
这次更新不是简单的模型升级，而是把“补全行为”从单一指标转向了可调节的体验维度。对于不同编程习惯的开发者，现在能找到更贴合自己的默认行为。
