整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

如果你上周有關注，想必都聽說其發(fā)布了一個最新的智能體——GitHub Copilot Coding Agent。官方給它的定位，是讓 Copilot 從“對話式編程助手”升級為真正的“協(xié)作開發(fā)搭子”，開發(fā)者可以將 GitHub Issue 直接分配給 Copilot，由其嘗試自動解決，自己負責審核即可，像是手底下多了一名“實習生”。

目前這個智能體已經進入公測階段，甚至有網(wǎng)友發(fā)現(xiàn)它已經開始在 GitHub 上“實戰(zhàn)演練”了，比如跑到微軟自家的 .NET runtime 倉庫里幫忙。不過，真用起來大家發(fā)現(xiàn)……情況有點一言難盡。

在 Reddit 上，一篇題為《我的新愛好：看 AI 把微軟員工逼瘋》的帖子迅速引發(fā)熱議。不少網(wǎng)友調侃：“微軟到底是想提升開發(fā)效率，還是想給自己人添堵？”更開發(fā)者直言：“說實話，我還真有點替那些被分配來審這些 PR 的員工感到難過。但如果這就是我們行業(yè)的未來，那我可能不想坐這趟車了?！?/p>

在這之中，到底發(fā)生了什么？

Coding Agent 是什么？

時下， 已正式面向 iOS 和 Android 上的 GitHub 移動端用戶、以及命令行工具 GitHub CLI 用戶開放試用。

簡單來說，這是一個可以“自動寫代碼、修 Bug、改功能、提 PR”的 AI 編程代理工具。程序員只需要把任務像“派活”一樣交給它，它就能自己去看代碼、理解項目、寫代碼、跑測試，最后把結果交回來。

你只需要像對待一個新同事一樣，審一下它干得怎么樣，對要進一步優(yōu)化的部分進行評論讓它再繼續(xù)做。

聽上去是不是很省心？確實，Copilot Agent 設計的初衷就是為了解放程序員的時間，讓他們別再被小任務纏住，而能去搞點更有創(chuàng)意、更復雜、也更有成就感的活兒。

上線之際，一位自稱是 GitHub Coding Agent 產品負責人的 timrogers 在 HN 上表示：

「我們在 GitHub 和微軟內部，其實已經用 Copilot Coding Agent 差不多三個月了。這段“吃自己狗糧”的過程非常有價值，收到了大量反饋（也修了不少 bug），對我們今天正式發(fā)布幫助很大。到目前為止，大約有 400 位 GitHub 員工在 300 多個項目里試用了這款智能體，Copilot 貢獻的 PR 有近 1000 個已經合并。

而且，在我們構建 Coding Agent 的那個代碼倉里，Copilot Coding Agent 本身已經是第五活躍的貢獻者了——所以可以說，我們確實是“用 Copilot 來造 Copilot”了 」

聽起來前景一片光明。但現(xiàn)實呢？

微軟工程師與 Copilot 的“斗爭”

Copilot Coding Agent 目前已經在微軟的 .NET runtime 倉庫中上線，但實際使用中暴露出了不少問題。比如，它聲稱“已解決”的某些 Issue，結果實際上根本沒解決。

來看一個實戰(zhàn)例子——一個 PR 的標題是“為混合全球化實現(xiàn) CompareInfo.Version”，Copilot 被指派來修復相關問題。

這條 PR（https://github.com/dotnet/runtime/pull/115762）中，Copilot 自動識別并描述了一個具體問題：

在 iOS 或 macCatalyst 環(huán)境下，運行使用 hybrid globalization 模式的應用時，CompareInfo.Version 會拋出 PlatformNotSupportedException 異常。這個屬性本應提供 Apple 使用的 Unicode 版本信息，以取代拋出異常的行為。

它隨后提交了一套解決方案：

• 在 pal_collation.m 中新增了一個原生方法 GlobalizationNative_GetUIUnicodeVersion()，用于將 iOS/macOS 版本映射到對應的 Unicode 版本；

• 在 Interop.Collation.iOS.cs 中添加 interop 方法，供托管代碼調用；

• 在 CompareInfo.iOS.cs 中新增 GetAppleSortVersion() 方法；

• 修改 CompareInfo.cs 的 Version 屬性，使其調用新方法；

• 同步更新相關測試用例，確保在包括 iOS 混合全球化在內的所有平臺上都能正確運行。

乍一看似乎有板有眼，但很快問題來了。

這條 PR 下面，微軟內部開發(fā)者 Matous Kozak 稱這修復有問題，請 @Copilot 修復蘋果平臺上的構建錯誤。

Copilot 很快回應，稱已修復兩個語法問題：一個是 CompareInfo.cs 中的縮進錯誤，另一個是 CompareInfoTests.cs 中的多余括號。

但 Matous Kozak 檢查后發(fā)現(xiàn)，錯誤依然存在。他貼出構建日志指出具體問題。

Copilot 隨后再次提交代碼，修復了 pal_collation.h 中的函數(shù)聲明，將空括號改為 (void)，同時更新 pal_collation.m 保持一致。

盡管 Copilot 連續(xù)提交幾輪，還是沒能解決關鍵 Bug。

Kozak 無奈指出：Copilot 實現(xiàn)中調用的 ucol_getVersion 實際返回的是排序器版本，而非 Unicode 版本，提醒它應調整實現(xiàn)邏輯，以確保行為一致。

Copilot 隨即更新了實現(xiàn)，聲稱現(xiàn)在返回的是排序器版本，并按 ICU 的格式構造了主版本號、次版本號、補丁號和構建號，以確保跨平臺一致性。

沒多久，微軟的另一位工程師 Tarek Mahmoud Sayed 接棒。他指出 Copilot 使用的 GlobalizationNative_GetUIUnicodeVersion 實現(xiàn)“看起來不太對勁”，原因是不同的排序規(guī)則（如“en”和“fr”）會返回不同的版本號，而 Copilot 的實現(xiàn)無法區(qū)分這些。

Copilot 積極回應稱已做修正，新實現(xiàn)會根據(jù) Apple 版本映射到可能對應的 Unicode 標準排序器版本。

但 Sayed 繼續(xù)質疑其行為一致性，指出：在 C# 中使用 LCID（地區(qū)標識符）是不夠的，因為很多文化會共享同一個 LCID，比如 0x1000。Objective-C 中是否有更合適的 API 來處理這個問題？

緊接著又有微軟工程師 jkotas 出現(xiàn)，對 Copilot 的注釋提出質疑：

// 用于根據(jù)操作系統(tǒng)版本計算主版本號的簡單公式

// 加上偏移量 3 是為了與 Apple 在 Unicode 版本支持上的模式保持一致

// 例如：iOS/macOS 17 -> Unicode 14，iOS/macOS 16 -> Unicode 13，依此類推

這條評論是錯誤的。iOS 和 macOS 版本不是這樣對齊的。例如，當前 macOS 版本是 15，而當前 iOS 版本是 18。

在他的提醒下，Copilot 先是只需改了錯誤的注釋，并未調整代碼的相關邏輯。再次被提醒之后，Copilot 才去改了代碼。

接連換人之后，這個 PR 之下，代碼審查人員有長長的一列：

遺憾的是，盡管 Copilot 被輪番“教育”，仍多次提交失敗、邏輯不通，修復方案生硬，關鍵問題沒有解決。

一名叫 lloydjatkinson 的開發(fā)者忍不住發(fā)聲：「作為一名外部觀察者、同時也是 .NET 的開發(fā)者，我到底該對這些被放任在代碼庫中“撒野”的 AI 草率代理感到多擔憂？在未來的 .NET 版本中，我們將運行多少由 AI 編寫、而非真正程序員寫的代碼，而自己卻毫不知情？

這對安全性、開源許可、代碼質量、整體一致性、公共 API、性能等方面會有什么影響？AI 模型中到底有多少是基于 15 年前的 Stack Overflow 回答訓練出來的，那些答案早已不再符合當前的開發(fā)模式或最佳實踐了吧？

一波又一波的問題 PR，會不會最終耗盡 .NET 維護者的耐心？有沒有人真的想要這個功能，還是只是為了迎合 AI 熱潮、取悅股東而推動的企業(yè)命令？

此外，就在兩周前，還有人隨意往 .NET 官方文檔中添加了一段內容，鼓勵使用 AI 只是為了給 JSON 屬性改個名字——那段文檔毫無意義。到底有多少工程師的時間和精力，正在被用來幫 AI“擦屁股”？」

“不如實習生？”

當然，除了這個 PR 之外，還有多個 PR 里面都有微軟工程師和 Copilot 斗爭、最終這款 AI 代理還是沒有解決實際問題的實例。

一些 PR 的評論區(qū)也逐漸被開發(fā)者的質疑聲所淹沒：

• “我喜歡這種互動：AI 說‘我修好了’，人類說‘沒有，你搞砸了’，AI 再說‘我又修好了’，然后繼續(xù)重復?！?/p>

• “可悲的是，我現(xiàn)實中還真遇到過照這流程干活的程序員?！?/p>

• “問題在于，沒有證據(jù)能證明這種模型在未來十年內真的會變得可靠。測試和研究是一回事，真正投入生產又是另一回事。畢竟大型軟件公司是為股東利益服務的?！?/p>

更有用戶 diggan 指出：

有趣的是，每條評論后面都自動加了“通過使用 或 按鈕為 Copilot 提供反饋”這樣的提示，但實際上這些評論都沒收到過任何正面或負面的反饋。

這看起來像是在修補表象，而沒有解決根本問題？

我也有類似的體驗——如果沒有為 LLM 設置一個完善的 system prompt 來指導它整體行為，它就會反復犯這種錯。最搞笑的 PR 是那種通過刪除/注釋掉測試用例或直接修改斷言的方式來“解決”測試失敗的。Google 和 Microsoft 的模型似乎更容易這么干，相比之下 OpenAI 和 Anthropic 的模型則少見。我很好奇這是否反映了它們內部流程上的一些差異？

剛才引用的那個 PR 后面還有三條信息，最后看起來是人類開發(fā)者徹底放棄了：

請檢查一下

你新增的測試沒有被執(zhí)行，因為你沒有把新文件添加到 csproj 中

你加的測試失敗了

我簡直無法想象那些必須處理這些東西的開發(fā)者是什么心情。這就像帶一個完全不聽你說話、也毫無理解能力的初級程序員。

另一個 PR 鏈接：https://github.com/dotnet/runtime/pull/115732/files 。這東西到底怎么評審？頁面 90% 的高度都被“Check failure”占據(jù)了，代碼和 diff 根本看不清。而更諷刺的是，單元測試里還寫著注釋：“測試 issue 中提到的表達式”。如果不是我太同情那些要處理這些 PR 的人，這一切簡直好笑到爆。

雖然 Copilot Agent 的愿景很美——自動寫代碼、省下時間、提升效率，但從目前的公測表現(xiàn)來看，它還遠未達到“靠譜搭子”的程度。很多開發(fā)者擔心的，不只是代碼質量問題，更是安全性與開源合規(guī)、未來維護成本、對初學者的誤導、AI 寫代碼但沒人能讀懂的風險。

當然，也不是全無亮點——作為一個實驗性工具，它已經能自動完成不少繁瑣任務，對于有經驗的工程師來說，作為輔助工具還是有價值的。但要說“代替程序員”？還早。

你體驗過 Copilot Coding Agent 嗎？你覺得它是效率提升的新利器，還是未來幾年要靠人類開發(fā)者不斷“善后”的工具？

參考：

https://old.reddit.com/r/ExperiencedDevs/comments/1krttqo/my_new_hobby_watching_ai_slowly_drive_microsoft/

https://news.ycombinator.com/item?id=44050152

https://github.blog/changelog/2025-05-19-github-copilot-coding-agent-in-public-preview/

2025 全球產品經理大會

2025 年 8 月 15–16 日

北京·威斯汀酒店

2025 全球產品經理大會將匯聚互聯(lián)網(wǎng)大廠、AI 創(chuàng)業(yè)公司、ToB/ToC 實戰(zhàn)一線的產品人，圍繞產品設計、用戶體驗、增長運營、智能落地等核心議題，展開 12 大專題分享，洞察趨勢、拆解路徑、對話未來。

更多詳情與報名，請掃碼下方二維碼。