Prompt Tuning 如何改善 VS Code 中的 GPT-5.5

2026年7月6日 由 VS Code 團隊發表，@code

在我們的上一篇文章中，我們介紹了 VS Code 編碼執行環境（coding harness），這是將模型連接至工具、上下文、指令和代理程式迴圈（agent loop）的層級，賦予模型執行編碼任務的能力。

每個模型對工具呼叫和指令的反應都不盡相同，而執行環境可以進行調整以改善結果。這篇文章將介紹我們與 OpenAI 合作進行的為期兩週實驗，旨在微調 VS Code 中的 GPT-5.5 系統提示詞。問題很簡單：如果我們引導代理程式減少探索並更快進行驗證，它是否能在不降低品質的情況下變得更快、更具成本效益？結合 OpenAI 的模型專業知識與我們的執行環境數據，我們測試了兩個微小的提示詞變更，在實際流量中與對照組進行評估，並推出了表現最佳的方案。

隨著採用依使用量計費的模式，這點變得更加重要。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.9 秒，p=2e-5），p95 首次編輯時間改善了 -9.30%（快 38.8 秒，p=1e-10）。實驗組 A 朝著正確的方向發展，但編輯延遲的效果較弱：p50 首次編輯時間為 -2.88%（快 2.0 秒，p=0.0271），p95 首次編輯時間則為 -1.93%（不具顯著性）。

• Token 效率：兩個實驗組都降低了每個使用者的中位數總 Token 量，但這些 p50 的變動不具統計顯著性：實驗組 B 為 -3.25%，實驗組 A 為 -2.54%。在分位數上端（upper tail），實驗組 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 讓多項指標朝著正確的方向發展，但實驗組 B 在對 VS Code 最重要的衡量標準上表現得更為一致。

因此我們正式推出了它：實驗組 B（LargePromptSections）現已成為預設的 GPT-5.5 系統提示詞。

這次的重點不只是數字有所變動。這些變動與來自提供者回饋的特定、可測試的執行環境假設息息相關，並先經過離線驗證，隨後在為期兩週的正式環境窗口中線上確認。這正是我們希望持續運作的迴圈。

持續最佳化

這項實驗是我們如何在發表日之後與模型提供者合作的一個範例。模型的發布並非微調迴圈的終點。這是另一個機會，讓我們得以檢視真實的 VS Code 行為、測試有針對性的改善措施，並尋找讓體驗更快、更可靠且更有效率的新方法。

我們將繼續在各個模型、提示詞、工具和 VS Code 編碼執行環境中尋找這些改善之處，好讓每個代理程式的預算能花在真正重要的工作上，而不是用在不必要的探索。

立即試用 VS Code 中的代理程式、在不同模型間切換，並比較不同模型如何處理相同的任務。歡迎在我們的 GitHub 儲存庫中分享您的意見回饋。這有助於我們持續改善使用體驗。

祝開發愉快！ 💙