Microsoft Copilot Cowork 開發：九名工程師、1,211 個拉取請求與驗證瓶頸

Microsoft 表示，在 10 月 21 日的 Copilot Cowork 開發期間，九名工程師合併了 1,211 個拉取請求，而大部分程式碼由代理撰寫。拉取請求是在整合前提出修改建議供審查。這個分別相當重要：標題量度的是已合併的修改，但生產力亦取決於其實用性、可靠性及維護負擔。

這篇於 11 月 2 日發布的工程文章，描述一支團隊如何改變其指定需求、審查及營運軟件的方式。其核心張力在於，實作能力不斷擴張，驗證能力卻有限。只有當組織能判斷哪些修改值得交付予用戶時，產生更多修改才會創造價值。

Anthropic 的代理研究及 Google 的軟件交付研究提供了有用的參考點，但並未獨立驗證 Microsoft 的結果。兩者都將焦點引向 AI 工具周邊的系統。隨着程式碼產出愈來愈容易擴張，工程領導者面對的壓力將落在審查實務、架構及問責上。

Copilot Cowork 開發里程碑實際量度的是甚麼

根據 Microsoft 的 Copilot Cowork engineering 文章，後端團隊自 1 月開始工作後，達到這個單日總數。工程師仍負責需求及較高風險的決策。自動化檢查及代理審查者會檢視修改。Microsoft 亦描述了一項敏感修改，人類審查者發現了四個代理審查者漏掉、足以阻止合併的問題。

已合併的拉取請求記錄的是獲接納的活動；其商業價值仍需要獨立證據。

一個組織可以把功能拆分為許多修改，亦可以把相關工作合併成較大的提交。兩種做法都會改變計數，但都無法證明工作帶來了多少客戶價值。因此，只以總數比較團隊，可能會獎勵封裝方式的差異，而非工程表現的差異。

較小的修改可以令審查更容易，因為每項建議只提出較狹窄的問題。然而，一組各自易於理解的修改，仍可能產生意料之外的綜合影響。相關的評估單位有時會變成發布、客戶工作流程，或服務長時間的表現。

試想一個假設的排程助理：它讀取請求、檢查可用時段，並準備會議邀請。每個元件都可以通過各自的測試，但完整工作流程仍可能錯誤處理取消安排。若只計算成功的元件修改，便會忽略客戶真正遇到的問題。

這個例子說明，這項里程碑值得關注，但不應成為普遍目標。該計數顯示了一個異常繁忙的整合流程，卻沒有披露功能複雜度、客戶效益或維護最終系統所需工作量的標準化衡量方式。

時機同樣重要。這篇文章描述的是透過持續開發逐漸形成的營運模式，而不是生成程式碼的短暫示範。讀者應把其主張視為一間公司的生產環境個案研究，並考慮此形式固有的所有背景及選擇限制。

因此，Copilot Cowork engineering 提出了一個超越編碼速度的管理問題：應以甚麼證據來支持接納一項修改？不同答案意味著不同的人手需求。重視局部測試結果的團隊，會與要求安全審查、營運證據及客戶成果檢查的團隊採取不同組織方式。

單日總數無法為另一個組織回答這個問題，但它令問題更難再被拖延。一旦實作能力擴張，薄弱的接納準則便會成為營運限制，而不再只是偶爾的不便。

對買家而言，這個分別同樣實際。供應商的開發速度描述其改變產品的能力；買家仍需要證據，證明這些修改改善了員工所依賴的工作流程。

工程領導者面對驗證能力問題

當實作能力擴張時，稀缺資源便成為對已發布內容具備充分依據的信心。

信心有多個來源：精確的需求、有意義的測試、具備資訊的審查，以及來自運行中服務的證據。這些來源回答不同問題。測試可以證明某些選定輸入下的預期行為，卻不能證明需求本身是否服務客戶。

Google 的 AI-assisted software development 研究提供了更廣泛的比較。其 2025 年 DORA 結果將 AI 採用與交付吞吐量上升聯繫起來，同時強調周邊組織的重要性。該研究將 AI 描述為會放大既有優勢及弱點的工具。

這個角度支持對 Microsoft 里程碑作出審慎解讀。擁有清晰責任歸屬及可靠發布控制的團隊，有地方可以導向新增的實作能力。責任未釐清的團隊，反而可能累積更多沒有人能夠有信心批准的建議。

因此，壓力首先落在工程經理及平台團隊身上。他們決定誰擁有接納準則、哪些修改需要專家關注，以及如何撤回一項發布。當建議更快湧現時，這些決定變得更重要。

安全專家面對相關的資源分配問題。以同等強度審查每項修改，無論風險高低都會消耗注意力；只審查明顯與安全相關的檔案，則可能錯過在其他地方引入的行為。困難之處在於，把修改與其影響的權限、資料及客戶操作連繫起來。

產品經理亦承擔更多責任。當分歧浮現前便可以產出軟件時，模糊的請求會變得昂貴。一個看似完善的實作可能為被誤解的需求帶來推動力，即使從技術上看修改程式碼仍然直接，要修正也會在政治上更困難。

這正是組織應區分等待與必要審議之處。有些延遲反映資訊不足或審查者超負荷，另一些延遲則保護一項不可逆轉的決定。把兩者都視為浪費，會鼓勵團隊只因保障措施拖慢儀表板，就將之移除。

一項有用的管理回應，是檢視不確定性從何處進入流程。如果審查者反覆詢問功能應如何運作，需求便需要改善；如果他們反覆質疑部署影響，發布流程便需要更佳的可見度。

這些是組織診斷，而不是主張無限增加流程。每項額外控制都有成本。標準應是它是否回答了另一項控制仍未解決的重要問題。

Copilot Cowork 開發的故事以異常明顯的形式呈現了這項取捨。工程領導者現在需要說明，他們將如何在擴展實作能力的同時擴展驗證能力。購買編碼代理的存取權，並不能解決這項營運決策。

對企業買家而言，相應的問題在於修改質素。當員工遇到更少中斷、更清晰權限及更可靠的任務完成效果時，更快的發布才會帶來價值。單靠發布頻率，無法確定這些結果。

Copilot Cowork Rust 遷移將程式語言與架構分開看待

Microsoft 報告稱，Copilot Cowork Rust 遷移在一個比較時段內，將首次回應的中位時間由 7.9 秒降至 2.7 秒。它亦將部分改善歸因於遷移代理迴圈，並未就每輪成本作出聲稱。

遷移可以改善服務，卻不能證明程式語言造成了每一項改善。

執行環境是執行應用程式工作的軟件機制。在語言之間遷移該機制，可能改變記憶體管理、排程、部署及啟動行為。如果多個元素同時改變，所得量度便會反映其綜合效果。

這個分別很重要，因為程式語言辯論往往把架構項目壓縮成簡單競賽。這種框架能產生清晰標題，卻難以為其他團隊的投資決策提供良好基礎。真正相關的問題是，哪種機制能解決其自身的瓶頸。

Rust 的 concurrency guarantees 提供了具體的技術參考。並行是指程式的不同部分可以獨立取得進展。Rust 使用所有權規則及型別檢查，在執行前捕捉許多記憶體及並行錯誤。

這些保證有其限制。它們不能證明回應包含正確的商業資訊、某項操作獲得許可，或用戶按預期次序收到事件。語言安全與應用程式正確性只在部分範圍重疊。

排程服務說明了這個差異。其程式碼可以安全處理記憶體，卻選錯日曆；其工作可以在沒有資料競爭的情況下執行，卻在獲批前發出邀請。語言層面的保證無法補足缺失的產品規則。

因此，遷移證據需要多個層次。其中一層關乎資源使用及回應時間，另一層關乎真實流量下的行為，還有一層關乎替代方案是否保留了原本隱含的責任。

受控比較理想上會在維持工作負載及基礎設施條件不變的情況下，記錄正被評估的修改。生產環境遷移很少能提供完美的實驗分離。這個限制應影響歸因方式，而不是抹去有用的營運量度。

對閱讀 Copilot Cowork Rust 遷移文章的開發者而言，實際含意是採取分析角度。在概括結果前，應先確定相關問題涉及執行排程、啟動開銷、記憶體行為，還是應用程式設計。

對買家而言，程式語言本身通常不如服務結果重要。更快的初始回應很有價值，但不能證明整項任務完成得更快。系統可以更早開始回答，卻仍需要更長時間才能產出正確的交付成果。

同一分別亦適用於經濟效益。延遲改善不會自動證明營運成本較低。基礎設施使用量、模型呼叫、重試及支援工作都會影響計算。

這使這次遷移成為一項有用的歸因個案研究。它說明當工程成果成為公開效能聲稱時，為何應保留其架構背景。

代理審查需要獨立的信任基礎

只有當其檢查提供有用且足夠獨立的證據時，增加審查者才會提高信心。

AI agent 是一種由模型驅動的系統，會朝向目標選擇行動並使用工具。Agent reviewer 可以檢視擬議的變更、指出疑慮，並要求修正。其判斷本身仍是需要評估的輸出，尤其當編寫內容的 agent 已提供了大量周邊說明時。

Anthropic 的 agent workflow patterns 描述了將生成與評估分開的系統。該公司建議採用簡單設計、明確的評估準則，並僅在能改善成果時才增加複雜度。這為日益重要的自動化審查角色提供了有用的對照。

當成功與否能被直接觀察時，評估者的工作會較容易。數值計算可以透過獨立運算核對。涉及權限的工作流程則需要另一類證據，因為正確行動取決於身分、政策和情境。

核心風險在於共同誤解。作者與審查者可能會達成一致，因為兩者以相同方式理解了含糊的要求。他們的共識並不能消除歧義。只有當另一個模型或提示帶來相關且不同的證據或推理時，才會有所幫助。

測試也有類似限制。與實作一同撰寫的測試，可能重現實作本身的假設。測試通過只證明這些產物之間一致，未必證明它們與預期行為一致。

獨立證據可以來自現有合約、觀察到的行為、已批准的要求，或精心挑選的失敗案例。合適的來源取決於變更內容。重要的區別在於，這些證據能否反駁實作。

設想一項自動檢查在未收到任何相關輸入時仍回報成功。其結果看似一次成功檢查，但其實不包含有關擬議變更的任何資訊。當使用者無法得知檢查實際檢視了甚麼時，可見的通過符號便會造成誤導。

這正是為何審查質素不能簡化為分配了多少個 agent。一小組目的各異的檢查，能比重複進行的大範圍審查帶來更高信心。目標是在不製造難以閱讀的評論洪流下，涵蓋重要的失敗模式。

人手參與也需要有明確角色。要求某人於沒有時間或背景資料下批准一項變更，只會形成名義上的監督。有效審查需要明確決定、相關證據，以及否決提案的權限。

就 Copilot Cowork 開發而言，更廣泛的教訓涉及自動化與問責之間的關係。更快的自動化回饋可支援人類判斷，但組織仍需要明確依據來接受風險。

即使原作者離開討論，這個依據仍應可被理解。可搜尋的要求與決策紀錄，可協助日後的審查者重建原意。管理這類背景資料的團隊可探索可搜尋的知識庫，但不應將已儲存的文件視為軟件行為正確的證明。

生產力研究令 pull request 的標題變得更複雜

Microsoft 的個案研究與獨立生產力研究衡量的是不同事物，因此兩者的發現不能互相替代。

METR 的 developer productivity experiment 提供了有用的平衡觀點。在其 2025 年初的研究中，16 名經驗豐富的開源開發者完成了 246 項工作。儘管參與者相信工具有所幫助，使用 AI 在該情境下仍令完成時間增加了 19%。

該結果涉及特定的開發者、程式碼庫、工作項目及工具，並不代表 AI 會拖慢每一個工程團隊。它同樣無法直接評估其後圍繞大量並行 agent 所組織的工作流程。

METR 其後進一步補充了這個情況。其 2026 年 2 月的 productivity experiment update 描述了樣本選擇問題，以及開發者並行使用 agent 時難以衡量時間的情況。研究人員認為較新的結果不足以可靠地精確估計目前的影響。

綜合而言，這些來源揭示的是衡量問題，而非普遍結論。工作完成時間、已合併的變更數量與自行報告的有用程度，可能朝不同方向變動。可靠的評估應先說明哪一種結果最重要，才解讀結果。

對個別開發者而言，工具可能減少令人不快的工作，卻未必縮短所需時間。對組織而言，工具可能擴闊可行項目的範圍，卻未必降低維護成本。這些好處值得考慮，但需要準確標示。

團隊也可能因為選擇較小的工作項目而完成更多工作。這可能透過減少等待與不確定性來改善交付，亦可能令活動指標膨脹，但重大客戶問題仍未解決。單靠數量無法區分這些解釋。

反事實情境同樣重要。評估生產力需要交代：若沒有工具或流程，本來會發生甚麼。一次成功發佈證明團隊交付了某些成果，但不能獨立證明 AI 帶來了多少加速效果。

Microsoft 的公開說明提供的是運作層面的例子，而非隨機比較。這種格式可揭示有用的機制和失敗模式，卻無法分離開發者專業知識、基礎設施、組織支援和模型能力各自的貢獻。

同樣的謹慎亦適用於競爭對手。Anthropic 的架構指引說明一種設計方法，而 Google 的研究則描述較廣泛的模式。兩者都不能證明哪一家供應商能為特定企業工作負載帶來最佳結果。

對工程主管而言，含意是不要將一個令人印象深刻的數字變成編制公式。人手決策需要有關持續交付、質素、支援負擔，以及仍在衡量流程以外的工作的證據。

這個故事也留下了一個尚未解答的經濟問題。獲接納工作的總成本包括生成、評估、基礎設施、人力注意力，以及發佈後的修正。更多實作活動可以同時伴隨更佳或更差的經濟效益。

因此，Copilot Cowork 工程應被評估為經重新組織的工作的具體例子。其最強的貢獻，是促使人們就證據提出更好的問題，而非提供工程師與 agent 之間的通用換算率。

三個訊號將令這種開發模式更容易判斷

下一批有用證據將關乎持續成果、可重複的驗證，以及獲接納工作的完整成本。

第一個訊號，是將開發活動與生產環境可靠性連結起來的後續資料。在未來數月，如披露發佈失敗、回退或反覆出現的客戶問題，將有助讀者解讀已合併變更的數量。

如果可靠性在持續交付的同時改善，將會加強這種營運模式的論據。若修復工作上升，情況則會變得更複雜。無論結果如何，其決策價值都高於另一份孤立的活動紀錄。

比較應採用一致的定義。報告方式的改變可令服務看起來更健康，卻未有改變其行為。讀者應留意穩定的衡量期間，以及對何謂失敗的清晰說明。

第二個訊號，是驗證實務能否轉移至原有團隊以外的證據。有文件記錄的評估、可重現的測試設置，或可比較的生產環境案例，有助區分廣泛適用的方法與依賴特殊條件的結果。

複現不要求另一個團隊達到相同的每日總量。它要求證明額外的實作能力能產生獲接納的成果，而不會壓垮審查及營運。不同工作負載合理地應有不同活動水平。

若其他團隊能在不同限制下重現效益，這個案例便會更具普遍性。若成功高度依賴專門基礎設施或集中的專業知識，其適用性便會較窄。對買家和工程主管而言，這仍會是有用資訊。

第三個訊號，是可信的經濟成本交代。每項成功完成的客戶工作成本，可將工程變更連結至產品的營運現實，亦可揭示重試和修正工作是否消耗了表面上的效率收益。

有用的披露應說明計算包含哪些成本。若排除審查或基礎設施，回答的是較狹窄的問題；若將它們納入，則可協助組織把這種方法與現有流程比較。

這些是觀察重點，而非已宣布的報告承諾。Microsoft 並未承諾提供本文討論的每一項衡量資料。缺少這些資料只會令個案部分仍未解決，而非自動證明失敗。

對企業買家而言，眼前行動是要求供應商提供與實際工作流程相關的證據。選擇員工實際執行的一項工作，定義可接受的結果，並檢視系統如何處理例外情況。把開發活動與客戶成功分開看待。

對正在評估 Copilot Cowork 開發的工程主管而言，應利用這個里程碑來釐清自身採用決策背後的問題。找出團隊難以驗證的事項、原意在哪裏流失，以及哪些成果值得增加自動化。比較一段有意義期間內獲接納的工作，包括修正所需的投入。閱讀原始工程說明時，也應同時參考生產力研究，因為兩者回答的是不同問題。然後檢視你的組織能否說明，為何一項變更值得發佈。當實作變得更容易擴展，這種說明便成為核心工程責任。甚麼證據會令你的團隊相信，更多生成的程式碼已成為更可靠的軟件？