VS Code 如何利用 AI 進行開發

2026年3月13日 由 Pierce Boggan 撰寫

我們每天都使用 AI 來發布 VS Code。這讓我們快了非常多，在經歷了十年的每月發布後，我們剛剛改成了每週發布。AI 代理（Agents）是解鎖這一切的關鍵，不僅是用於寫程式碼，還涵蓋了團隊運作的每一個環節。

為了拉開 Agent Sessions Day 的序幕，我與 VS Code 團隊的工程經理呂鵬坐下來聊聊，深入探討 VS Code 團隊實際上是如何在日常工作中使用 AI 的。不僅是用於實作功能（這點不證自明），還包括圍繞著功能建構的方方面面：問題分類（triage）、程式碼審查（code review）、版本資訊（release notes）、驗證，以及在充滿會議的日程中保持高生產力。

在那場對談中，我們可能只涵蓋了團隊在任何一天中使用 AI 代理所做事情的 5%。但這代表了數百萬開發者使用的產品是如何被建構出來的。因此，我們希望能分享更多關於最近工作流程的這些重大變革，以及我們認為接下來要前往的方向。

在經歷十年的每月發布後，我們改為每週發布

我們以每月為週期發布 VS Code 長達十年。每個月我們都會經歷一套運作順暢的循環：計劃、建構、測試、收尾（endgame）、發布。隨著團隊中每個成員輪流擔任不同的角色，這種節奏已成為團隊文化的一部分。

最近，我們決定開始以每週的節奏發布 VS Code。同時，我們希望對嚴謹度和品質的要求保持一樣高。每月的週期能給你喘息的空間，有時間去計劃、有時間進行一整週的完整收尾，讓團隊互相交叉測試彼此的功能，以及有時間撰寫詳盡的版本資訊。轉向每週的節奏意味著所有這些都必須加快速度或實現自動化。這是一個巨大的改變，就在一年前，我們還做不到這一點。這種轉變之所以可能，完全是因為 AI 代理改變了我們的工作方式。

每週發布的節奏並不是為了快而快，而是為了更早將改進交付給開發者。過去需要等上三週才能進入下一個穩定版的錯誤修復，現在幾天內就能發布。週一合併的功能，當週就能送到開發者的編輯器中。這種 發布 > 學習 > 迭代 的回饋迴圈變得快得驚人。

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

隨著我們不斷學習與適應，我們的工作流程與程序每天都在演變。但有一些關鍵的學習心得依然適用：

1. 將你自己平行化。 養成在切換上下文之前啟動多個 AI 代理行程的習慣。工作樹（Worktrees）、雲端代理、多個 VS Code 工作階段……全部都用上。
2. 略過中繼產出物。 過去的流程是：會議記錄 → 問題（issues） → 規格書 → 程式碼；現在實際上變成了：會議 → AI 代理行程 → 程式碼 → PR。
3. 自動化隨著速度擴展而增加的額外負擔。 我們建構了由 AI 代理驅動的管道來處理問題分類、提交摘要（commit summarization）、版本資訊、程式碼審查，全都使用了 Copilot CLI、Copilot SDK 和 GitHub Actions。工程師仍然是這些工作流程的另一端，但 AI 代理能更快地將正確的事物呈現給正確的人。
4. 在追求速度之前投資防護網（harnesses）。 測試、黃金情境（golden scenarios）與程式碼審查關卡可以防止由 AI 代理驅動的速度變成由 AI 代理驅動的迴歸（regression）。
5. 所有權正在演變。 當產品經理（PM）、其他領域的工程師、社群貢獻者和 AI 代理都能對任何元件做出貢獻時，傳統的所有權模型需要隨之調整。對成果的當責仍然落在工程師身上。
6. 將人類保留在迴圈中以把關品味。 AI 代理檢查正確性；人類評估愉悅感（delight）。

讓我們更詳細地看看這些原則如何在我們團隊中實踐。

平行運作

有一篇著名的 Paul Graham 文章，探討了製作者行程（maker schedule）與管理者行程（manager schedule）本質上是如何的不相容。直到最近，這大部分都還是真的。但 AI 代理正在改變這點。

以下是典型的一天可能看起來的樣子：

• 在進入會議之前，啟動 3 到 4 個 AI 代理行程來修復錯誤、製作功能原型或分類問題。
• 在會議期間，AI 代理會在多個 VS Code 工作階段、工作樹或雲端中平行執行。
• 會議結束後，檢視 AI 代理的輸出、進行本地驗證、合併或重新給予提示詞（re-prompt），然後再次啟動。

管理者仍然需要參加會議和其他管理任務，但他們可以使用 AI 代理來承擔部分製作者的工作，而這些工作在充滿會議的日程中過去是不可能完成的。

讓我舉一個真實的例子。彭每早都會從更新 VS Code Insiders 開始。大多數日子裡，我們一天會發布兩次 Insiders 建置版本，以便對我們正在開發的東西獲得早期回饋。接著，他會執行一個自訂的 AI 代理，透過 Work IQ 擷取他的會議記錄，並產出他手頭工作清單的快照。

從那裡開始，彭決定什麼需要他的關注、什麼要委派給 AI 代理，以及為團隊優先處理什麼。AI 代理處理了收集上下文的繁瑣工作，讓他能直接切入有趣的問題。當他進入第一次通話時，任務已經在平行執行了。

「以前，你總是按順序工作。你寫筆記、把它們變成問題（issues），然後其他人或你自己稍後會接手處理。現在你被賦權並能夠平行處理事情。這是一個你必須建立的習慣。所以，我不再寫會議記錄了。我直接啟動 AI 代理。」 — 呂鵬

這確實是一項新的肌肉記憶。會議中的某個人提到我們需要去做的事，我當場就會啟動 AI 代理。我們也在 Teams 中為大部分會議啟用了逐字稿轉錄功能，因此事後獲取上下文非常容易。過去變成問題再變成工作的會議記錄，現在只是當下啟動的一個提示詞。

自動化額外負擔

更高的速度固然很好，但它也會帶來自身的額外負擔：更多需要分類的問題、更多需要追蹤的提交（commits）、更多需要撰寫的版本資訊。以下是我們如何將隨著速度擴展的部分進行自動化。

提交摘要。 我們建構了一個自訂的斜線指令（slash command），可以從多個儲存庫（repos）中擷取過去 24 小時的所有提交，並使用快速模型進行摘要。過去你執行 `git fetch` 時可能會有 20 或 30 個提交。現在，可能會有一百多個提交在等著你。整個功能區域可以在一天之內落地。同一個管道會餵入我們的 Insiders 變更日誌（changelog），並驅動我們的自動化 X 帳號來發布每日更新。全部都基於 Copilot CLI 與 Copilot SDK 建構，並作為由提交至 main 分支觸發的 GitHub Actions 運行。

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

現在，每當開啟一個問題時，它就會觸發 GitHub Actions 中的一個 AI 代理循環，該循環會檢測重複項（附帶信心分數）、決定正確的擁有者，並建議標籤。AI 代理會讀取我們的所有權文件並查看歷史分配模式，因為所有權會隨著時間而轉移。

你可以從儲存庫的公開資料中看到這點：比較 1 月到 3 月的年對年數據，提交量已經增加了一倍以上，團隊關閉的問題數量幾乎是之前的 3 倍。更好的分類有助於工程師更快地找到並修復正確的問題，從而為實際的軟體開發釋放更多時間。

「現在那段程式碼是由 Copilot 寫的，誰才是它的正確擁有者？我會說，對成果負責的仍然是我們的工程師。但你確實需要適當的防護網，來歡迎其他人對你的元件做出貢獻。」 — 呂鵬

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

我們已經看到團隊的發布速度有了實質的提升。而且，隨著這些工作流程趨於成熟，我們仍有大量的事情可以繼續自動化、簡化並從中學習。

每個人都在發布程式碼

這是讓我最興奮的部分，因為它比其他任何事情都更改變了我的工作方式。

傳統的 PM 迴圈看起來是這樣的：撰寫規格書或產品需求文件（PRD） → 建立問題 → 交給工程部門。沒有人喜歡閱讀這些規格書，而根本的問題在於它們是基於假設。你寫的是你認為體驗應該是什麼樣子，但在建構完成之前，你其實並不知道。因此，功能驗證的週轉時間可能會很長。

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

透過 VS Code 中的 AI 代理，我可以從某人在 X 或 Reddit 上給我們的回饋，轉變為一個可用的原型，在 Insiders 上自我託管（self-host）並體驗它，然後繼續迭代。我上個月合併了一個 PR，它在 Copilot Chat 中實現了對話分叉（forking conversations）。我和我們的工程師之一 Justin 一起審查了這個 PR，在辦公室一起處理了一些 CSS 變更並將其合併。現在這個功能已經在 VS Code 裡了。

這並不意味著所有這些原型最終都會進入產品中。工程師仍然對程式碼品質和架構負有責任。如果彭看了我的 PR 並說「這沒有正確的架構」，那很公平，我完全可以接受我的 PR 被丟棄並重新建構。但 PR 推動對話前進的速度，比任何文件都還要快。第一個 PR 不一定需要完美。它能推動進展，並與擁有該功能區域的工程師展開對話。

這個工作流程也是檢驗你的程式碼基底（codebase）是否為 AI 代理就緒（agent-ready）的試金石。AI 代理能找到正確的元件嗎？它能發現迴歸（regressions）嗎？它能找到正確的修復方案嗎？如果一個 PM 可以把問題丟給 AI 代理並獲得一個合理的 PR，這說明了該程式碼基底的結構、文件和測試覆蓋率都有不錯的表現。如果 AI 代理掙扎得很辛苦，那也是一個訊號。

在速度提升的同時保持高品質

更快的速度意味著更高的迴歸風險。

「如果沒有適當的防護網，在前一兩週你的生產力會非常高。然後你會很快遇到瓶頸，不斷發生迴歸。」 — 呂鵬

如果新的元件沒有良好的護欄（guardrails），由 AI 代理驅動的開發會一開始表現強勁，然後品質快速下滑。基礎仍然很重要，而有了 AI，我們實際上可以對其進行改進：

• 自動化驗證。 當你同時執行 5 到 10 個 AI 代理時，手動驗證每一個代理是否都交付了正確的體驗（而不僅僅是能編譯的程式碼）成本是很高的。我們的團隊建構了一個自訂的 AI 代理，它使用 Playwright MCP 伺服器來啟動 VS Code、導覽至受測功能、截圖，並評估變更是否符合預期的行為。因為它在 AI 代理循環內運行，如果截圖顯示某些東西壞了，AI 代理就會去修復它。截圖會被儲存以供人類審查。

• 測試。 全面的測試套件、單元測試、整合測試以及執行它們的基礎設施，都是基本門檻。除此之外，我們記錄了黃金情境（golden scenarios）：核心使用者流程的預期行為規格。我們傳統上在每月的收尾週期間手動測試這些項目。我們現在將這些情境交給 AI 代理，作為自動化的合併後驗證來執行。我們也在探索使用這個管道來自動產生展示錄影：一個 PR 落地，就會產生一部展示影片，而這會成為變更日誌或推文（tweet）的內容。

• 程式碼審查。 每個 PR 都會自動獲得 Copilot 程式碼審查，工程師會在請求人類審查之前解決 Copilot 的意見。六個月前，我們沒有強制執行這點，因為回饋的雜訊太多了。在過去幾個月裡，模型品質顯著提升，通常能在第一輪就抓出安全性、效能和程式碼品質問題。在請求人類審查之前解決這些意見，已成為我們工作流程中自然的一部分。我們透過一個 Slack 頻道進行協調，機器人會在其中發布帶有 CI 和 Copilot 程式碼審查狀態指示器的 PR，兩者會在檢查完成時就地更新。我們的文化是「給予一個，接受一個」：提交一個 PR，接下一則審查。

• 品味評估。 人類審查並不會消失，甚至變得更加重要。當 AI 代理編寫更多程式碼且 PR 落地速度更快時，人類審查員會檢查該變更對產品來說是否真的合理。這符合長期的架構嗎？用起來感覺對嗎？AI 代理可以抓出錯誤，但它們無法告訴你某個功能是否會讓開發者感到驚豔。

傳統上，我們會有收尾週，由工程師、PM 和設計師互相測試彼此的功能。我們並不是要取消這項做法，而是將其時間壓縮。在 PM 方面，我一直在探索我所認為的「基於品味的評分」：寫下我希望某個功能具備的定性體驗，然後使用 AI 代理來評估實作是否符合。也許 AI 代理 80% 的觀察是有用的、20% 我會忽略，但那 80% 已經能讓你走得很遠了。例如：我們的模型選擇器是只顯示模型名稱和倍率，還是有使用者實際上會想要更多的資訊？

我們認為這種相同的方法可以幫助我們檢查已發布的文件是否真正符合使用該產品的實際體驗。我們所有的 VS Code 文件幾乎都是由一個人撰寫的，考慮到我們的開發步調，這相當令人驚嘆，但當產品變化如此之快時，文件很容易過時。我們正在探索 AI 代理如何幫助我們自動捕捉這種落差（drift）。

接下來是什麼

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

我們真心很好奇：你們團隊的版本看起來是怎麼樣的？有沒有什麼我們漏掉的工作流程？有哪些是你自動化了而我們沒想到的？在 VS Code 儲存庫中為我們開一個 issue，或在 X 上找到我們——我們正與你一同建構這一切，你的回饋將形塑接下來的發展。

我們在 Agent Sessions Day 上也有許多其他精彩的對談，如果你還沒看過，記得去看看。

祝開發愉快！ 💙