VS Code 如何利用 AI 進行開發

2026 年 3 月 13 日，作者：Pierce Boggan

我們每天都使用 AI 來發布 VS Code。它讓我們的工作效率大幅提升，在維持了十年的每月發布週期後，我們剛改為每週發布一次。AI 智能體（Agents）是實現這一轉變的關鍵，不僅僅是在編寫程式碼方面，而是貫穿了我們團隊運作的每一個環節。

為了啟動智能體交流日（Agent Sessions Day），我與 VS Code 團隊的工程經理 Peng Lyu 進行了對談，深入探討 VS Code 團隊實際上是如何在日常工作中運用 AI 的。這不僅限於功能實作（這部分已無需多言），還涵蓋了功能開發的「周邊」一切事務：分類處理（triage）、程式碼審查、發布說明、驗證，以及在會議繁多的日程中保持高生產力。

在那次交流中，我們所涵蓋的內容可能還不到團隊日常使用智能體工作量的 5%。但這正是成千上萬開發者所使用的產品是如何被打造出來的縮影。因此，我們希望分享更多關於近期工作流程的重大變革，以及我們認為接下來的發展方向。

在維持十年每月發布後，我們轉為每週發布

我們以每月一次的頻率發布 VS Code 長達十年。每個月我們都會經歷一套運作純熟的週期：規劃、構建、測試、最後衝刺（endgame）、發布。團隊成員輪流擔任不同角色，這種節奏已成為我們團隊文化的一部分。

最近，我們決定開始改採每週發布的節奏。我們希望維持同樣嚴謹且高品質的標準。每月週期提供了緩衝空間，有時間進行規劃、執行為期一週的「最後衝刺」（讓團隊交叉測試彼此的功能），並撰寫詳盡的發布說明。改為每週發布意味著所有這些環節都必須加速或自動化。這是一個巨大的轉變，如果是一年前，我們根本做不到。這次調整完全歸功於智能體改變了我們的作業方式。

改為每週發布並非為了快而快，而是為了能更早將改進交付給開發者。以前需要等待三週才能納入下一個穩定版本的錯誤修復，現在幾天內就能發布。週一合併的功能，當週就能出現在開發者的編輯器中。那種「發布 > 學習 > 迭代」的回饋迴圈變得快多了。

從這次轉變中我們學到了什麼

隨著我們不斷學習與適應，我們的工作流程和程序也在每日進化。但以下幾點核心體會始終不變：

1. 自我平行處理（Parallelize yourself）。 養成在切換情境前先啟動多個智能體會話的習慣。善用 Worktrees、雲端智能體、多個 VS Code 工作區……將它們全部利用起來。
2. 跳過中間產物。 過去的「會議紀錄 → 問題單 → 規格書 → 程式碼」流程，現在正轉變為「會議 → 智能體會話 → 程式碼 → PR（拉取請求）」。
3. 自動化隨速度擴展的行政負擔。 我們利用 Copilot CLI、Copilot SDK 和 GitHub Actions，為問題分類、提交摘要、發布說明和程式碼審查建立了智能體驅動的管線。工程師仍然是這些流程的把關者，但智能體能更快地將正確的事項呈現給正確的人。
4. 在追求速度前先投資於防護措施。 測試、黃金案例（golden scenarios）和程式碼審查機制，能防止「智能體驅動的速度」變成「智能體驅動的退化」。
5. 所有權概念正在演變。 當 PM、其他領域的工程師、社群貢獻者以及智能體都能為任何組件做出貢獻時，傳統的所有權模式必須做出調整。但對結果的當責仍落在工程師身上。
6. 讓人保持在迴圈中進行品味判斷。 智能體負責檢查正確性，人類則負責評估體驗是否令人滿意。

讓我們更深入地看看這些在我們團隊中是如何落實的。

平行運作

有一篇關於「製造者時間表」與「管理者時間表」本質上互不相容的著名文章（作者為 Paul Graham）。直到最近這大多還是真的，但智能體正在改變這一點。

我們典型的一天可能是這樣的：

• 進入會議前，先啟動 3-4 個智能體會話來修復錯誤、建立功能原型或進行問題分類。
• 會議期間，智能體在多個 VS Code 工作區、Worktrees 或雲端中並行運作。
• 會議後，審查智能體的產出、進行本地驗證、合併或重新提示，然後再次啟動。

管理者仍然需要參加會議並處理管理事務，但他們可以利用智能體分擔一些以前在會議繁多的行程中無法完成的「製造者」工作。

讓我舉個真實例子。Peng 每天早上都會先更新 VS Code Insiders。大多數日子裡，我們每天會發布兩次 Insiders 版本，以便對我們正在進行的工作進行早期回饋。接著，他會執行一個自定義智能體，透過 Work IQ 抓取他的會議行程，並產生一份他手頭工作的快照。

從那裡開始，Peng 決定哪些需要他專注、哪些可以委派給智能體、哪些需要優先處理給團隊。智能體處理了收集情境的雜務，讓他能直接切入有趣的問題。當他參加第一次會議時，任務已經在背景平行運作了。

「以前，你總是順序作業。你寫筆記，把它變成問題單，然後其他人或你自己稍後再接手。現在，你有能力並能平行處理事務。這是一種你必須培養的習慣。所以，我不再撰寫會議記錄了。我直接啟動智能體。」 — Peng Lyu

這真的是一項新的技能。當會議中有人提到我們需要執行的事項時，我會當場發送指令給智能體。我們也為 Teams 中的大多數會議啟用了轉錄功能，因此事後抓取情境變得很容易。過去那種「會議記錄轉為問題單，再轉為工作」的流程，現在變成了當下直接啟動的一個提示詞（Prompt）。

自動化行政負擔

速度提升很好，但也會帶來額外的負擔：更多需要分類的問題、更多需要追蹤的提交、更多需要撰寫的發布說明。以下是我們如何將那些隨速度擴展的瑣事自動化：

提交摘要。 我們建立了一個自定義斜線指令（slash command），它會抓取多個儲存庫中過去 24 小時的所有提交，並利用快速模型進行總結。過去你 git fetch 可能會有 20 或 30 個提交；現在，可能有超過 100 個在等你。一個完整的功能區塊可以在一天內完成。同一個管線也會匯入我們的 Insiders 變更紀錄，並驅動我們發布每日更新的自動化 X 帳號。這一切都建立在 Copilot CLI 和 Copilot SDK 上，以 GitHub Actions 形式隨著對主分支的提交觸發。

問題分類。 VS Code 是 GitHub 上最大的開源專案之一。我們熱愛我們的社群，問題的數量反映了有多少人關心這個產品：每天都有數百個問題湧入。我們過去有一個輪替的「收件匣追蹤者」角色，一個人負責分類一週的所有事項。這已經無法負荷了。

現在，每當開啟一個問題，它都會觸發 GitHub Actions 中的一個智能體迴圈，偵測重複項目（帶有信心分數）、判定正確的負責人並建議標籤。智能體會讀取我們的所有權文件並觀察歷史分配模式，因為所有權會隨時間改變。

從儲存庫的公開數據中可以看出端倪：比較 1 月到 3 月的年增率，提交量翻了一倍多，且團隊關閉問題的速度接近過去的 3 倍。更好的分類有助於工程師更快找到並解決正確的問題，從而騰出更多時間進行真正的軟體開發。

「現在那段程式碼是 Copilot 寫的，誰是合適的負責人？我認為仍然是我們的工程師對結果負責任。但你確實需要正確的機制，來歡迎其他人為你的組件做出貢獻。」 — Peng Lyu

團隊還製作了一個 Chrome 擴充功能，可以直接在 GitHub 問題上顯示分類建議，如重複項目、負責人和標籤。它包含一個顯示整個團隊問題狀態的儀表板。在 VS Code 內部，自定義斜線指令讓工程師無需離開編輯器就能整理問題並尋找重複項。

我們已經看到團隊的發布速度有了顯著提升。隨著這些工作流程的成熟，我們仍有許多可以持續自動化、簡化並從中學習的地方。

人人皆可發布程式碼

這是最讓我興奮的部分，因為它改變了我工作的方式，勝過其他任何改變。

傳統的 PM 迴圈是這樣的：撰寫規格書或 PRD → 建立問題單 → 移交給工程部。沒人喜歡讀那些規格書，且根本問題在於它們是基於假設。你寫的是你認為體驗應該是什麼樣子，但在實際構建出來之前，你並不真正知道。因此，功能驗證的周轉時間可能很長。

改變的是，我不再創建規格書，而是創建一個原型——一個真實的 Pull Request！

有了 VS Code 中的智能體，我可以從 X 或 Reddit 上收到的使用者回饋出發，直接做出一個可運作的原型，並在 Insiders 自行託管並體驗它，然後持續迭代。上個月我合併了一個 PR，實作了 Copilot Chat 中的對話分支（forking conversations）。我和我們的工程師之一 Justin 一起審查了該 PR，在辦公室一起調整了幾個 CSS 變更後就合併了。現在那個功能已經在 VS Code 裡了。

這並不代表所有原型最終都會進入產品中。工程師仍然對程式碼品質和架構負責。如果 Peng 看我的 PR 並說「這架構不對」，那很公平，我不介意我的 PR 被丟棄重寫。但該 PR 比任何文件都能更快推動對話進展。第一個 PR 不需要完美，它能解決痛點，並與負責該功能領域的工程師展開對話。

這個工作流程也是檢驗你的程式碼庫是否「智能體就緒」的試金石。智能體能找到正確的組件嗎？它能找到回歸測試問題嗎？它能找到正確的修復方案嗎？如果 PM 可以拋出一個問題給智能體並得到一個合理的 PR，這說明你的程式碼庫結構、文件和測試覆蓋率都很不錯。如果智能體感到困難，那也是一個訊號。

在加速的同時維持高品質

更高的速度意味著更高的回歸測試風險。

「如果沒有正確的防護措施，最初的一兩週你的生產力會很高。然後你很快會達到一個天花板，接著不斷出現回歸問題。」 — Peng Lyu

如果一個新組件缺乏良好的護欄，智能體驅動的開發一開始很強勁，但隨後品質會迅速下降。基礎工程依然重要，而透過 AI，我們甚至可以進一步加強這些基礎。

• 自動化驗證。 當你同時運行 5-10 個智能體時，手動驗證每一個是否提供了正確的體驗（而不僅僅是能編譯的程式碼）成本太高。我們的團隊建立了一個自定義智能體，利用 Playwright MCP 伺服器啟動 VS Code，導航到被測功能，擷取螢幕截圖，並評估變更是否符合預期行為。因為它運行在智能體迴圈中，如果截圖顯示有損壞，智能體會自動修復它。螢幕截圖會儲存供人工審查。

• 測試。 全面的測試套件、單元測試、整合測試以及執行它們的基礎設施是基本門檻。除此之外，我們記錄了黃金案例（golden scenarios）：核心使用者流程中預期行為的規範。我們傳統上會在每個月的「最後衝刺」週進行手動測試。現在，我們將這些案例交給智能體，作為合併後的自動化驗證執行。我們也在探索使用此管線自動產生展示錄影：一個 PR 合併後，自動生成展示影片，成為變更紀錄的內容或一則推文。

• 程式碼審查。 每個 PR 都會自動進行 Copilot 程式碼審查，工程師在請求人工審查前，必須先處理 Copilot 的評論。六個月前，我們沒有強制執行此項，因為回饋太吵雜。過去幾個月裡，模型品質顯著提升，通常在第一輪就能捕捉到安全性、效能和程式碼品質問題。在請求人工審查前處理這些評論已成為我們工作流程的自然組成部分。我們透過 Slack 頻道協調，機器人會發布帶有 CI 和 Copilot 程式碼審查狀態指示器的 PR，隨著檢查完成，兩者都會原地更新。我們的文化是「給予一次，接受一次」：提交一個 PR，就負責審查另一個。

• 評估品味。 人工審查不會消失，甚至變得更加重要。當智能體撰寫更多程式碼且 PR 合併得更快時，人類審查者必須確認這些變更是否對產品有意義。這是否符合長期的架構？使用起來感覺對嗎？智能體可以找出錯誤，但它們無法告訴你一個功能是否能讓開發者感到驚喜。

傳統上，我們有「最後衝刺」週，工程師、PM 和設計師會互相測試彼此的功能。我們並沒有取消這個環節，而是壓縮了時間。在 PM 方面，我一直在探索所謂的「基於品味的評分」：寫下我希望一個功能具備的定性體驗，然後使用智能體評估實作是否符合。也許智能體 80% 的觀察是有用的，20% 我可以忽略，但那 80% 已經能讓你走得很遠。例如：我們的模型選擇器只顯示模型名稱和倍率，還是還有使用者真正想要看到的更多資訊？

我們認為同樣的方法可以幫助我們檢查已發布的文件是否真正符合產品的使用體驗。我們所有的 VS Code 文件幾乎都是由一個人編寫的，考慮到我們的開發步調，這非常驚人，但當產品變化如此之快時，文件很快就會過時。我們正在探索智能體如何協助我們自動捕獲這種偏差。

下一步是什麼

更廣泛地說，這一切都回歸到我們所認為的「智能體就緒」程式碼庫評估：你的程式碼庫是否具備智能體有效貢獻所需的結構、文件和測試覆蓋率？

我們真的很好奇：你們團隊的版本長什麼樣子？是否有我們忽略的工作流程？有哪些我們沒想到的自動化項目？歡迎在 VS Code 儲存庫提交 Issue 給我們，或在 X 上找到我們 — 我們正與你們並肩打造這一切，而你們的回饋將形塑未來的樣貌。

我們在智能體交流日還有許多精彩的討論，如果還沒看過，歡迎去觀看。

祝開發愉快！ 💙