Copilot應用科學中的智慧體驅動開發

我可能剛剛把自己自動化到了一個完全不同的工作……這是軟體工程師中常見的模式——出於靈感、挫折，甚至有時是懶惰，他們構建系統來消除繁瑣工作，從而專注於更創造性的任務。隨後，我們最終擁有並維護這些系統，將自動化的好處帶給周圍的人。

作為一名AI研究員，我最近將這一理念推向了新的高度，自動化了我的腦力勞動。現在，我發現自己正在維護這個工具，以便Copilot應用科學團隊的所有同事都能做到同樣的事情。在此過程中，我學到了很多關於如何有效建立和協作使用GitHub Copilot的知識。應用這些經驗，不僅為我解鎖了極其快速的開發迴圈，還使我的隊友能夠構建適合他們需求的解決方案。

在我解釋如何實現這一點之前，讓我先介紹一下這個專案的背景，以便你更好地理解GitHub Copilot的能力範圍。

動因

我的工作很大一部分涉及分析編碼智慧體在標準化評估基準（如TerminalBench2或SWEBench-Pro）上的表現。這通常需要仔細審查大量的所謂“軌跡”——即智慧體在執行任務時採取的思維過程和行動列表。評估資料集中的每個任務都會產生自己的軌跡，顯示智慧體如何嘗試解決該任務。這些軌跡通常是包含數百行程式碼的JSON檔案。將基準集中的數十個任務乘以每天需要分析的大量基準執行，我們面對的是數十萬行程式碼需要分析。

這是一項不可能獨自完成的任務，因此我通常求助於AI。在分析新的基準執行時，我發現自己在重複同樣的迴圈：使用GitHub Copilot發現軌跡中的模式，然後親自調查——將需要閱讀的程式碼行數從數十萬減少到幾百行。然而，我內心的工程師看到了這項重複性任務，並說：“我想自動化它。”智慧體為我們提供了自動化這類智力勞動的手段，於是eval-agents誕生了。

計劃

工程和科學團隊更好地合作。這是我解決這個新挑戰時的指導原則。因此，我在設計並實施該專案時牢記幾個目標：

• 使這些智慧體易於共享和使用
• 便於編寫新的智慧體
• 使編碼智慧體成為貢獻的主要載體

前兩個目標深植於GitHub的基因中，也是我在整個職業生涯中（尤其是在維護GitHub CLI開源專案期間）積累的價值觀和技能。然而，第三個目標對專案的塑造最大。我注意到，當我設定GitHub Copilot來幫助我有效構建工具時，它也使專案更容易使用和協作。這一經歷教會了我一些關鍵經驗，最終以我意想不到的方式推動了第一和第二個目標的實現。

讓編碼智慧體成為你的主要貢獻者

首先描述我的智慧體編碼設定：

• 編碼智慧體：Copilot CLI
• 使用的模型：Claude Opus 4.6
• IDE：VSCode

值得注意的是，我利用了Copilot SDK來加速智慧體建立，該SDK在底層由Copilot CLI驅動。這使我可以訪問現有工具和MCP伺服器，註冊新工具和技能的方法，以及許多其他開箱即用的智慧體特性，無需重新發明輪子。

有了這些，我可以透過遵循幾個核心原則非常快速地簡化整個開發過程：

提示策略：智慧體在你採用對話式、詳細描述、並在進入智慧體模式之前使用規劃模式時表現最佳。

架構策略：經常重構、經常更新文件、經常清理。

迭代策略：“信任但驗證”現在變成了“歸咎於流程，而非智慧體”。

發現並遵循這些策略引發了一個令人難以置信的現象：新增新智慧體和功能變得快速而簡單。我們有五個人首次加入該專案，在不到三天的時間內，我們總共建立了11個新智慧體、4項新技能以及eval-agent工作流的概念（可以看作是科學家的推理流）。這相當於在345個檔案中增加了+28,858/-2,884行程式碼。

太棒了！

下面我將詳細介紹這三個原則以及它們如何實現了這一令人驚歎的協作與創新。

提示策略

我們知道，AI編碼智慧體非常擅長解決範圍明確的問題，但對於更復雜的問題（你只願意委託給高階工程師的那種），它們還需要手把手的指導。因此，如果你希望智慧體像工程師一樣工作，就要像對待工程師一樣對待它。引導它的思維，過度解釋你的假設，利用它的研究速度在跳入更改之前進行規劃。我發現，將一些關於我正在思考的問題的意識流思考放入提示中，並與Copilot在規劃模式下合作，比給它一個簡短的問題陳述或解決方案要有效得多。

以下是我編寫的一個提示示例，用於為工具新增更健壯的迴歸測試：

> /plan 我最近觀察到Copilot愉快地更新測試以適應其新正規化，即使這些測試不應該被更新。如何建立一個保留的測試空間，讓Copilot無法觸及或必須保留以防止迴歸？

這引發了一系列來回討論，最終形成了一系列類似於契約測試的護欄，只能由人類更新。我對想要的東西有一個想法，透過對話，Copilot幫助我找到了正確的解決方案。

事實證明，使人類工程師工作最有效的因素，同樣也使這些智慧體工作有效。

架構策略

工程師們，歡呼吧！還記得那些你想做但沒時間做的重構嗎？那些你從未有時間編寫的測試？那些你希望在入職時就存在的文件？現在，在構建智慧體優先的倉庫時，它們成為你可以做的最重要的事情。

那些將這類工作優先於新功能開發的時光一去不復返了，因為當你擁有一個維護良好的智慧體優先專案時，藉助Copilot交付功能變得輕而易舉。

在這個專案中，我大部分時間都在重構名稱和檔案結構，記錄新功能或模式，以及為我發現的問題新增測試用例。我甚至花了一些時間來清理智慧體（就像你的初級工程師）在實現所有新功能和更改時可能遺留的廢棄程式碼。這項工作使Copilot能夠輕鬆瀏覽程式碼庫並理解模式，就像對其他任何工程師一樣。

我甚至可以問：“以我現在所知，我會如何不同地設計？”然後我可以證明實際上回過頭來重新架構整個專案（當然是在Copilot的幫助下）。

夢想成真！

這引出了我最後一條建議。

迭代策略

隨著智慧體和模型的改進，我已經從“信任但驗證”的心態轉向了更加信任而非懷疑的心態。這反映了行業如何對待團隊：“歸咎於流程，而非人。”這是最高效團隊的運作方式，因為人都會犯錯，所以我們圍繞這一現實構建系統。

這種無指責文化為團隊提供了心理安全感，使他們能夠迭代和創新，知道即使犯錯也不會被責備。核心原則是我們實施流程和護欄來防止錯誤，如果錯誤確實發生，我們從中學到東西並引入新的流程和護欄，這樣我們的團隊就不會再犯同樣的錯誤。

將同樣的哲學應用於智慧體驅動開發，對於解鎖這個極其快速的迭代管道至關重要。這意味著我們新增流程和護欄來幫助防止智慧體犯錯，但當它犯錯時，我們新增額外的護欄和流程——如更健壯的測試和更好的提示——這樣智慧體就不能再犯同樣的錯誤。更進一步，這意味著實踐良好的CI/CD原則是必須的。

像嚴格型別這樣的實踐確保智慧體符合介面。健壯的linter為智慧體施加實現規則，使其遵循良好的模式和做法。而整合測試、端到端測試和契約測試——這些手工構建可能很昂貴——在智慧體輔助下變得便宜得多，同時讓你有信心新更改不會破壞現有功能。

當Copilot在其開發迴圈中擁有這些工具時，它可以檢查自己的工作。你正在為其成功創造條件，就像你在專案中為初級工程師創造條件一樣。

整合

當你的程式碼庫為智慧體驅動開發設定好後，你的開發迴圈將如下所示：

1. 使用/plan與Copilot規劃新功能。
2. 迭代規劃。
3. 確保計劃中包含測試。
4. 確保在實現程式碼之前，計劃中包含文件更新。這些可以作為額外的指南，與你的計劃並存。
5. 讓Copilot在/autopilot上實現功能。
6. 提示Copilot啟動與Copilot程式碼審查智慧體的審查迴圈。對我而言，通常是：請求Copilot程式碼審查，等待審查完成，處理相關評論，然後重新請求審查。繼續此迴圈直到沒有更多相關評論。
7. 人工審查。這是我在前幾節中強調模式的地方。

此外，在功能迴圈之外，確保你還經常提示Copilot以下內容：

• /plan 審查程式碼中缺失的測試、可能損壞的測試和廢棄程式碼。
• /plan 審查程式碼中的重複或抽象機會。
• /plan 審查文件和程式碼，找出文件缺口。確保更新copilot-instructions.md以反映相關更改。

我每週自動執行這些一次，但我也經常在整週中執行它們，因為新功能和修復不斷進入，以維護我的智慧體驅動開發環境。

帶走的經驗

最初是對一個極其重複的分析任務的挫敗感，最終變成了更有趣的東西：一種關於我們如何構建軟體、如何協作以及如何作為工程師成長的新思維方式。

以編碼智慧體優先的心態構建智慧體，從根本上改變了我的工作方式。這不僅僅是自動化的勝利——儘管觀看四位科學家在不到三天內交付11個智慧體、4項技能和一個全新概念，令人驚歎。更重要的是，這種開發風格迫使你優先考慮：乾淨的架構、全面的文件、有意義的測試和深思熟慮的設計——這些我們一直知道很重要但從未有時間做的事情。

與初級工程師的類比不斷得到驗證。你很好地引導他們，給予清晰的上下文，建立護欄使他們的錯誤不會成為災難，然後信任他們成長。如果出現問題，你歸咎於流程，而不是智慧體。如果有一件事我希望你從中帶走，那就是使你成為偉大工程師和優秀隊友的技能，也是使你擅長與Copilot構建的技能。技術是新的，但原則不是。

所以，去清理你的程式碼庫，編寫你一直推遲的文件，並開始將你的Copilot視為團隊的最新成員。你可能會自動將自己帶入職業生涯中最有趣的工作。

覺得我瘋了？那就試試這個：

• 下載Copilot CLI
• 在任何倉庫中啟用Copilot CLI：cd && copilot
• 貼上以下提示：/plan 閱讀並幫助我規劃如何最好地改進此倉庫以進行智慧體優先開發。