📼 Rewatch VS Code Live at MS Build 2026

How Prompt Tuning Improved GPT-5.5 in VS Code如何通过提示词调优，令 GPT-5.5 在 VS Code 中如虎添翼

July 6, 2026 by VS Code Team, @code2026 年 7 月 6 日，由 VS Code 团队发布，@code

In our previous post, we introduced the VS Code coding harness, the layer that connects the model to tools, context, instructions, and the agent loop, giving the model the ability to perform coding tasks.在前文中，我们曾介绍过 VS Code 的编码框架。这套框架好比中枢，将模型与各类工具、上下文、指令及智能体循环联通，使模型得以施展拳脚，完成编码任务。

Each model responds to tool calls and instructions differently, and the harness can adapt to improve results. This post walks through a two-week experiment we ran in partnership with OpenAI to tune the GPT-5.5 system prompt in VS Code. The question was simple: if we nudge the agent to explore less and validate sooner, can it get faster and cheaper without getting worse? With OpenAI's model expertise and our harness data, we tested two small prompt changes, measured them against a control on live traffic, and shipped the winner.各家模型对工具调用与指令的领悟各有千秋，而框架的妙处，便在于能因势利导，精进表现。本文将带诸位回顾我们与 OpenAI 携手开展的一场为期两周的实验，旨在调优 VS Code 中 GPT-5.5 的系统提示词。道理很简单：若能引导智能体少走弯路、早做决断，是否便能既省时又省力，且不损其功力？我们结合 OpenAI 的模型造诣与自身框架的数据，设下两套方案进行微调，并以线上流量作为试金石，最终择优而用。

This matters more with usage-based billing in place. Token efficiency isn't only an infrastructure metric: every token the agent spends wandering is a token you pay for and wait on. An agent that reaches a grounded edit sooner is both a better experience and a smaller bill.在按量计费的当下，此事尤为紧要。Token 的消耗不仅是基础设施的账单，更是智能体徘徊时虚掷的光阴。智能体若能早一步切中肯綮，完成编辑，既是用户之幸，亦能省下不少开支。

The hypothesis: explore less, validate sooner核心构想：少些徘徊，早做决断

Following the launch of GPT-5.5, we looked at how the model spent tokens inside the VS Code agent harness, as part of the work described in Improving token efficiency in GitHub Copilot. Two patterns stood out: where the model spent tokens, and where it over-explored before acting. Agents can spend a lot of effort searching, rereading, and comparing nearby paths before making a useful edit.GPT-5.5 发布后，我们审视了其在 VS Code 智能体框架内的 Token 消耗情况。正如我们在《提升 GitHub Copilot 的 Token 效率》一文中所述，两类现象颇为显眼：一是 Token 的去向，二是智能体在动手前往往过度探寻。智能体在做出一次有效的编辑前，常耗费大量心力在周边路径上反复搜索、研读与比对。

That pointed to a single, testable idea: the agent should spend less effort wandering and more effort moving through a deliberate loop of evidence, action, and validation.这指向了一个可供验证的思路：智能体应减少无谓的游走，转而磨练一套更为干练的循环：搜集证据、果断行动、即刻校验。

Diagram contrasting an agent that over-explores with many scattered search and read steps before its first edit, versus a Treatment B agent that moves through a deliberate anchor, gather minimal context, edit, and validate loop.

After testing different hypotheses and running offline evaluations, we turned that idea into two variants of the GPT-5.5 system prompt, both were promising in offline evals, and we tested them against the current default on live traffic.经多番推演与离线评估，我们将此构想化作两套 GPT-5.5 系统提示词方案。两者在离线测试中表现皆是不俗，于是我们将其与默认方案一同投向线上流量，一较高下。

Inside the experiment实验内幕

We ran the experiment in VS Code over a two-week window, splitting GPT-5.5 agent traffic across two treatment groups and one control group with a 25/25/25 split. Both treatments test the same hypothesis but differ in how much structure they add to the prompt.实验为期两周，我们将 VS Code 的 GPT-5.5 流量一分为四，两组用于测试方案，一组作为对照，各占四分之一。两套方案虽殊途同归，但在提示词的结构严谨度上各有侧重。

Group Variant name Description Traffic allocation
Control PRPT_CTRL Current default prompt 25%
Treatment A PRPT_SRCH Economical search and edit: single, compact reminder to limit exploration before acting 25%
Treatment B PRPT_LRG Large prompt sections: broader restructure covering the full edit-and-validate loop 25%

Note: The allocations add up to 75% because the experiment scorecard compares evenly sized groups. The remaining GPT-5.5 traffic continued to use the default prompt outside this scorecard slice, so we could compare the treatments and control across the same kind of user traffic.注：各组分配加总为 75%，因实验评分表仅对比规模相当的组别。其余 GPT-5.5 流量仍沿用默认提示词，以确保在相同的用户场景下，能公平地衡量各方案的优劣。

Treatment A: economical search and edit方案 A：精简搜索与编辑

Treatment A makes a small, focused change: a single, compact reminder that nudges the model to reduce unnecessary exploration.方案 A 采取了点到即止的策略：仅加入一段精炼的叮嘱，引导模型克制不必要的探索。

The <economical_search_and_edit> section in the prompt instructs the agent to start from a concrete anchor, gather only enough local context, avoid broad exploration, act once there is a cheap discriminating check, and avoid rereading unchanged context.提示词中新增的 <economical_search_and_edit> 模块，要求智能体以确凿的锚点为基，仅搜集必要的局部上下文，避开大范围的漫无目的搜索；一旦有了低成本的甄别手段便即刻行动，且不再重复研读未变动的上下文。

You can find the complete implementation details in gpt55BasePrompt.tsx:具体实现细节，可参阅 gpt55BasePrompt.tsx：

TsxTsx
{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>}

Treatment B: large prompt sections方案 B：结构化提示词

Treatment B tested a broader version of the same idea of limiting exploration. Instead of adding a single, compact reminder about economical search, it reorganizes the agent workflow into explicit <Before_the_first_edit> and <After_the_first_edit> sections. Unlike Treatment A, these additions make the system prompt itself larger, so a key question was whether the added structure would still improve efficiency, not just agent behavior.方案 B 则对“限制探索”这一构想进行了更为宏观的布局。它未止步于简单的叮嘱，而是将智能体的工作流重构为 <Before_the_first_edit> 与 <After_the_first_edit> 两个明确的阶段。与方案 A 不同，这些新增内容加长了系统提示词，因此关键在于：这般严谨的结构，究竟是能提升效率，还是反成了累赘？

The goal was to solve the full loop and not only the search step: form a local hypothesis before editing, avoid broad exploration, make a grounded first edit, and validate immediately after the first substantive edit.其目标是解决整个闭环，而非仅仅优化搜索：在编辑前先形成局部假设，避免广撒网，确保首次编辑便切中要害，并在实质性编辑后立即校验。

You can find the complete implementation details in gpt55BasePrompt.tsx:

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>
</>}

What the two-week scorecard showed两周战报

We tracked the treatments across three dimensions: quality (does the code stick), latency (how fast the first edit lands), and efficiency (tokens and tool calls). Each treatment is compared with the control group in the table below.我们从质量（代码留存率）、延迟（首次编辑耗时）与效率（Token 与工具调用量）三个维度进行追踪。下表展示了各方案与对照组的较量。

What each metric measures指标释义
  • 10-minute survival rate (by user): Of the code the model wrote, how much is still in the file 10 minutes later (not deleted or rewritten). It's our proxy for "did the AI's code actually stick." Measured as surviving characters ÷ total characters written, as a %. E.g. ~90% — roughly 9 of every 10 characters the model added are kept.10 分钟留存率（按用户计）：模型产出的代码，在 10 分钟后仍存在于文件中的比例（未被删除或重写）。这是衡量“AI 代码是否被采纳”的准绳。计算方式为：留存字符数 ÷ 总写入字符数。例如 90% 意味着每 10 个字符中有 9 个被保留。
  • Commit survival rate (by user): Narrower and stricter: of the AI-written code, how much survives all the way into a git commit. This is "did it make it into real, saved work." Same character-ratio calculation, but only counting code present at commit time. E.g. ~87%.提交留存率（按用户计）：更为严苛的指标，衡量 AI 代码最终进入 Git 提交的比例。即“是否真正成为了工作成果”。计算方式同上，但仅统计提交时刻存在的代码。例如 87%。
  • p50 Time to First Edit (by turn): For a typical request, how long from hitting enter until the first actual change lands in your code — not just the model talking, but real work appearing. Measured in seconds. E.g. ~74s for the median turn.p50 首次编辑耗时（按轮次计）：对于常规请求，从按下回车到代码产生实质变动的时长（以秒计）。例如中位数为 74 秒。
  • p95 Time to First Edit (by turn): The same clock, but for the worst 5% of requests — the "why is this taking so long?" cases. A key tail-latency guardrail. E.g. ~6.4 min (383K ms), where hard tasks or lots of exploration delay the first edit.p95 首次编辑耗时（按轮次计）：针对最慢的 5% 请求，即用户感到“为何如此之慢”的极端情况。这是衡量延迟的关键防线。例如 6.4 分钟，通常因任务复杂或过度搜索所致。
  • p50 total tokens (by user): How much the model reads + writes for a typical user across their day — a proxy for cost and context load per person. Sum of tokens per user, median across users. E.g. ~12.9M tokens/user/day.p50 总 Token 量（按用户计）：用户全天读写 Token 的中位数，反映了成本与上下文负载。例如每天每人约 1290 万 Token。
  • p95 total tokens (by turn): The token weight of the heaviest 5% of individual turns — the big, sprawling requests that drive cost spikes and hit context limits. E.g. a single turn running into the millions of tokens, vs a ~500K–900K median.p95 总 Token 量（按轮次计）：最耗资源的 5% 请求，即导致成本激增与触及上限的庞大请求。例如单轮请求高达数百万 Token，远超 50 万至 90 万的中位数。
  • Average tool calls (by turn): How many actions (read file, search, run terminal, edit…) the agent takes per request to get the job done. Lower can mean more efficient; too low can mean less thorough. Mean tool calls per turn. E.g. ~24 per turn.平均工具调用次数（按轮次计）：智能体为完成请求所采取的动作（读文件、搜索、终端操作、编辑等）平均次数。过低可能不够周全，过高则显冗余。

Signal legend: ● favorable and highly significant (p < 0.001), ○ favorable and statistically significant (p < 0.05), ● unfavorable and highly significant, ○ unfavorable and statistically significant, - not statistically significant.图例：● 显著优于对照组 (p < 0.001)，○ 优于对照组 (p < 0.05)，● 显著劣于对照组，○ 劣于对照组，- 无统计学意义。

Metric Treatment A (PRPT_SRCH) impact P-value Signal Treatment B (PRPT_LRG) impact P-value Signal
10-minute survival rate (by user) -0.40% (-0.37 pp) 0.0707 - -0.44% (-0.41 pp) 0.0493 ○
Commit survival rate (by user) -0.48% (-0.41 pp) 0.3200 - +0.68% (+0.57 pp) 0.1533 -
p50 Time to First Edit (by turn) -2.88% (2.0s faster) 0.0271 ○ -5.68% (3.9s faster) 2e-5 ●
p95 Time to First Edit (by turn) -1.93% (8.0s faster) 0.1928 - -9.30% (38.8s faster) 1e-10 ●
p50 total tokens (by user) -2.54% (0.2M fewer tokens) 0.3429 - -3.25% (0.3M fewer tokens) 0.2094 -
p95 total tokens (by turn) -5.19% (0.3M fewer tokens) 0.0157 ○ -7.64% (0.5M fewer tokens) 0.0003 ●
Average tool calls (by turn) -3.19% (0.77 fewer tool calls) 0.0091 ○ -8.54% (2.04 fewer tool calls) 1e-12 ●

Grouped bar chart comparing the percentage impact of Treatment A and Treatment B against the control baseline across seven metrics, showing that Treatment B produces the largest reductions in latency, token usage, and tool calls.

  • Quality: the guardrail metrics stayed mostly healthy. Commit survival rate moved slightly up for Treatment B (+0.68%) and slightly down for Treatment A (-0.48%), neither statistically significant. The 10-minute survival rate moved slightly down for both treatments: -0.44% for Treatment B and -0.40% for Treatment A. Only the Treatment B movement crossed the statistical significance threshold, and just barely (p=0.0493), unlike the highly significant efficiency wins. We treated that as a real tradeoff to weigh, but the movement was small and the other quality guardrail did not regress.质量方面：作为防线的指标大体稳健。提交留存率在方案 B 中微升（+0.68%），方案 A 中微降（-0.48%），皆无统计学显著差异。10 分钟留存率两方案均有轻微下滑，仅方案 B 的下滑触及了统计显著性边缘 (p=0.0493)，且幅度极小，远不及效率提升那般显著。我们将其视为合理的权衡，且另一项质量指标并未退化。

  • Latency: Treatment B delivered the strongest edit-latency wins, and both were highly statistically significant: p50 Time to First Edit improved -5.68% (3.9s faster, p=2e-5), and p95 Time to First Edit improved -9.30% (38.8s faster, p=1e-10). Treatment A moved in the right direction, but the edit-latency effects were weaker: p50 Time to First Edit -2.88% (2.0s faster, p=0.0271), and p95 Time to First Edit -1.93% (not significant).延迟方面：方案 B 表现最为亮眼，两项指标均有显著提升：p50 首次编辑耗时缩短 5.68% (3.9 秒, p=2e-5)，p95 缩短 9.30% (38.8 秒, p=1e-10)。方案 A 亦有改善，但幅度稍逊：p50 缩短 2.88% (2.0 秒, p=0.0271)，p95 无显著变化。

  • Token efficiency: both treatments reduced median total tokens per user, but those p50 movements were not statistically significant: -3.25% for Treatment B and -2.54% for Treatment A. At the upper tail, Treatment B reduced p95 total tokens by -7.64%, highly statistically significant (p=0.0003). Treatment A also reduced p95 total tokens by -5.19%, statistically significant (p=0.0157). Both variants reduced average tool calls per turn: -8.54% (2.04 fewer tool calls) for Treatment B, highly statistically significant (p=1e-12), and -3.19% (0.77 fewer tool calls) for Treatment A, statistically significant (p=0.0091).Token 效率方面：两方案均降低了人均 Token 中位数，虽未达显著水平，但在极端值上，方案 B 将 p95 总 Token 量显著降低了 7.64% (p=0.0003)，方案 A 亦降低了 5.19% (p=0.0157)。两方案均显著减少了平均工具调用次数：方案 B 减少 8.54% (p=1e-12)，方案 A 减少 3.19% (p=0.0091)。

Treatment B had the strongest overall profile: clear latency wins, significant upper-tail token reductions, fewer tool calls, and mostly stable quality guardrails. The one movement worth watching, the small drop in 10-minute survival, was only lightly significant (p=0.0493), while the latency, token, and tool-call gains were larger and far more robust. Treatment A moved several metrics in the right direction, but Treatment B was more consistent across the measures that matter most for VS Code.综上，方案 B 胜出：它在延迟优化、极端 Token 消耗控制、工具调用精简及质量稳定性上，都展现出了最佳的综合素质。虽 10 分钟留存率有轻微波动，但与其带来的巨大性能增益相比，瑕不掩瑜。方案 A 虽有进步，但方案 B 在 VS Code 最看重的指标上更为稳健。

So we shipped it: Treatment B, LargePromptSections, is now the default GPT-5.5 system prompt.于是我们拍板：方案 B (LargePromptSections) 正式成为 GPT-5.5 的默认系统提示词。

The takeaway isn't only that the numbers moved. The movement was tied to a specific, testable harness hypothesis from provider feedback, validated offline first and then confirmed online over a two-week production window. That's the loop we want to keep running.此番结晶，不仅在于数据的更迭，更在于我们从开发者反馈中提炼出可验证的假设，先离线评估，再线上实战，终成闭环。这正是我们所追求的优化之道。

Continuous optimization持续精进

This experiment is one example of how we work with model providers beyond launch day. A model release is not the end of the tuning loop. It is another chance to look at real VS Code behavior, test focused improvements, and find new ways to make the experience faster, more reliable, and more efficient.此实验仅是我们在模型发布后持续深耕的一个缩影。模型发布绝非调优的终点，而是审视其实际表现、精准施策、寻求更高效能的新起点。

We'll keep looking for those improvements across models, prompts, tools, and the VS Code coding harness, so more of each agent's budget goes to the work that matters instead of unnecessary exploration.我们将继续在模型、提示词、工具及编码框架上深耕，确保每一分算力都用在刀刃上，而非虚耗于无谓的探索。

Try agents in VS Code, switch between models, and compare how different models approach the same task. Share your feedback in our GitHub repo. It helps us keep improving the experience.欢迎在 VS Code 中体验智能体，切换不同模型，感受它们的差异。若有心得，请在我们的 GitHub 仓库中畅所欲言，这正是我们不断改进的动力。

Happy coding! 💙编码愉快！💙