提示词调优如何改进了 VS Code 中的 GPT-5.5

2026年7月6日 由 VS Code 团队发布，@code

在我们先前的文章中，我们介绍了 VS Code 编码框架（harness），这是一个将模型连接到工具、上下文、指令和智能体循环的层，赋予了模型执行编码任务的能力。

每个模型对工具调用和指令的响应方式各不相同，而框架可以进行调整以改善结果。本文将详细介绍我们与 OpenAI 合作进行的一项为期两周的实验，旨在调优 VS Code 中的 GPT-5.5 系统提示词。问题很简单：如果我们促使智能体减少探索、更快地进行验证，它能否在不降低质量的前提下变得更快、成本更低？借助 OpenAI 的模型专业知识和我们的框架数据，我们测试了两个小的提示词更改，在生产流量中对照控制组进行了测量，并发布了优胜者。

在实行按使用量计费的机制下，这一点尤为重要。Token 效率不仅是一个基础设施指标：智能体用于漫无目的游荡的每一个 Token 都是你需要付费并等待的 Token。一个能更快得到有依据的编辑的智能体，不仅体验更好，账单也会更少。

假设：减少探索，及早验证

继 GPT-5.5 发布之后，我们研究了模型如何在 VS Code 智能体框架内消耗 Token，这也是 GitHub Copilot 中的 Token 效率提升一文中所述工作的一部分。有两种模式脱颖而出：模型在何处消耗 Token，以及它在采取行动之前进行了哪些过度探索。在做出有用的编辑之前，智能体可能会花费大量精力来搜索、重新阅读和比较附近的路径。

这指向了一个单一且可测试的想法：智能体应该减少无谓的游荡，花更多精力在一个由证据、行动和验证组成的审慎循环中推进。

在测试了不同的假设并运行离线评估后，我们将这个想法转化为了 GPT-5.5 系统提示词的两个变体。这两者在离线评估中都表现出了良好的前景，随后我们在生产流量中将它们与当前默认版本进行了对比测试。

实验内部

我们在两周的时间窗口内在 VS Code 中运行了该实验，将 GPT-5.5 智能体流量按 25/25/25 的比例分流到两个处理组和一个控制组中。这两个处理组测试的是同一个假设，但它们在向提示词中添加的结构化程度上有区别。

注意： 分配比例加起来是 75%因为实验计分卡比较的是规模相等的组。其余的 GPT-5.5 流量在该计分卡切片之外继续使用默认提示词，这样我们就可以在同类用户流量中比较处理组和控制组。

处理组 A：经济的搜索与编辑

处理组 A 做了一个小而专注的改动：一个单一、紧凑的提醒，促使模型减少不必要的探索。

提示词中的 <economical_search_and_edit> 部分指示智能体从具体的锚点出发，仅收集足够的局部上下文，避免广泛的探索，一旦有低成本的区分性检查就立即行动，并避免重新阅读未更改的上下文。

您可以在 gpt55BasePrompt.tsx 中找到完整的实现细节

{economicalSearchAndEditEnabled && <Tag name='economical_search_and_edit'>
    - Start from the most concrete available anchor: a file, symbol, failing behavior, failing command, or nearby implementation surface.<br />
    - Gather only enough nearby context to choose one plausible local hypothesis and one cheap check that could disconfirm it.<br />
    - Prefer one targeted search or nearby read over broad repo exploration.<br />
    - Once the cheapest discriminating check is known, act.<br />
    - Do not re-read unchanged context unless a new result makes it relevant.<br />
</Tag>}

处理组 B：大型提示词部分

处理组 B 测试了限制探索这一想法的更广泛版本。它没有添加关于经济搜索的单一、紧凑提醒，而是将智能体的工作流重构为明确的 <Before_the_first_edit> 和 <After_the_first_edit> 部分。与处理组 A 不同，这些新增内容使系统提示词本身变得更大，因此一个关键问题是增加的结构是否仍能提高效率，而不仅仅是改善智能体行为。

其目标是解决整个循环而不仅仅是搜索步骤：在编辑前形成局部假设、避免广泛探索、进行有依据的首次编辑以及在第一次实质性编辑后立即进行验证。

您可以在 gpt55BasePrompt.tsx 中找到完整的实现细节

{largePromptSectionsEnabled && <>
    <Tag name='Before_the_first_edit'>
        - Start from the most concrete anchor available: a file, symbol, failing behavior, failing command, test, or nearby implementation surface. If the request does not name one explicitly, use the first targeted search or nearby read to identify that anchor, then continue locally from there.<br />
        - Before the first edit, gather only enough nearby evidence to state one falsifiable local hypothesis about how the requested behavior should work or why it is failing, and one cheap check that could disconfirm it.<br />
        [...]
        - Once you can state one falsifiable local hypothesis, the nearby code path it depends on, one cheap check that could disconfirm it, and one small edit that would test it, the next action must be a grounded edit.<br />
        - If confidence is incomplete, the first edit may be a small reversible probe that exposes missing types, behavior mismatches, control-flow gaps, or validation failures.<br />
        - If you find yourself still searching after that local-routing budget, treat that as drift. Recover by choosing the best current hypothesis and the best available nearby check, then make the smallest plausible edit that will let that check discriminate.<br />
    </Tag>
    <Tag name='After_the_first_edit'>
        - Prefer this order for that first validation action:<br />
        - the cheapest behavior-scoped or failing check that can falsify the current hypothesis<br />
        - a narrow test for the touched slice<br />
        - a narrow compile, lint, or typecheck command for the touched slice<br />
        [...]
        - Finish with at least one post-edit executable validation step whenever the environment provides one. Only fall back to diff-only validation when no focused command exists or commands are unavailable.<br />
    </Tag>
</>}

两周的计分卡显示了什么

我们从三个维度追踪了处理效果：质量（代码是否被采纳留存）、延迟（首次编辑落地有多快）以及效率（Token 和工具调用）。下表中将每个处理组与控制组进行了对比。

信号图例：● 有利且高度显著 (p < 0.001)，○ 有利且统计显著 (p < 0.05)，● 不利且高度显著，○ 不利且统计显著，- 统计不显著。

• 质量：护栏指标大体保持健康。处理组 B 的 Commit 留存率略有上升（+0.68%），处理组 A 略有下降（-0.48%），两者均在统计学上不显著。10分钟留存率在两个处理组中均略有下降：处理组 B 为 -0.44%，处理组 A 为 -0.40%。只有处理组 B 的变化越过了统计显著性阈值，且非常勉强（p=0.0493），这与高度显著的效率提升形成了对比。我们将其视为需要权衡的实际折衷，但变动很小，且另一个质量护栏并未退化。

• 延迟：处理组 B 带来了最显著的编辑延迟改善，且两项指标都高度统计显著：p50 首次编辑时间提升了 -5.68%（快 3.9s，p=2e-5），p95 首次编辑时间提升了 -9.30%（快 38.8s，p=1e-10）。处理组 A 朝着正确的方向发展，但编辑延迟效果较弱：p50 首次编辑时间为 -2.88%（快 2.0s，p=0.0271），p95 首次编辑时间为 -1.93%（不显著）。

• Token 效率：两个处理组都降低了每个用户的平均总 Token 数，但这些 p50 变动在统计学上并不显著：处理组 B 为 -3.25%，处理组 A 为 -2.54%。在上尾方面，处理组 B 将 p95 总 Token 数降低了 -7.64%，高度统计显著（p=0.0003）。处理组 A 也将 p95 总 Token 数降低了 -5.19%，统计显著（p=0.0157）。两个变体都减少了每轮的平均工具调用次数：处理组 B 减少了 -8.54%（少 2.04 次工具调用），高度统计显著（p=1e-12），处理组 A 减少了 -3.19%（少 0.77 次工具调用），统计显著（p=0.0091）。

处理组 B 具有最强的整体表现：明显的延迟改善、显著的上尾 Token 减少、更少的工具调用以及大体稳定的质量护栏。唯一值得关注的变化是 10 分钟留存率的小幅下降，其显著性很低（p=0.0493），而延迟、Token 和工具调用的收益更大且更为稳健。处理组 A 使多项指标朝着正确的方向发展，但在对 VS Code 最重要的衡量标准上，处理组 B 表现得更为一致。

因此我们发布了它：处理组 B，即 LargePromptSections，现在已成为默认的 GPT-5.5 系统提示词。

结论不仅在于数据发生了变动。这些变动与来自提供商反馈的特定、可测试的框架假设息息相关，它们首先在离线状态下得到验证，随后在为期两周的生产环境中得到确认。这就是我们希望不断运行的循环。

持续优化

本次实验展示了我们在发布日之后如何与模型提供商合作的一个示例。模型的发布并不是调优循环的终点。它是审视真实的 VS Code 行为、测试有针对性的改进以及寻找新方法让体验变得更快、更可靠、更高效的又一次机会。

我们将继续跨模型、提示词、工具和 VS Code 编码框架寻找这些改进，以便将智能体的更多预算花在重要的工作上，而不是用于不必要的探索。

尝试在 VS Code 中使用智能体，在不同模型之间切换，并比较不同模型如何处理相同的任务。在 我们的 GitHub 仓库中分享您的反馈。这有助于我们不断改善体验。

编码愉快！ 💙