微軟AI公開「折磨」微軟員工,修復Bug唯一貢獻是改了PR標題,GitHub評論區成吃瓜現場

夢晨 發自 凹非寺 量子位 | 公眾號 QbitAI

微軟著名開源專案.NET Runtime成了吃瓜現場,全球程式設計師在GitHub評論區圍觀嘲笑:

微軟用垃圾AI「折磨」微軟員工,真是可悲又可笑。

圖片

發生什麼事?

原來是新出的Copilot程式碼智能體在嘗試幫忙自動修復Bug,但那叫一個越幫越亂。

Bug本身只是一個正規表達式的小問題,被分配給一位微軟員工斯蒂芬和Copilot合作解決。

圖片

Copilot在方案描述中說的頭頭是道,什麼「這確保了一致性」,「改動很小」等等。

圖片

結果程式碼直接檢查不通過,錯誤報告了一長串。

圖片

合著這AI忙活了半天,唯一的「貢獻」其實是把標題給改了,也是學會摸魚的精髓了。

圖片

還好其實只是程式碼規範的小問題,斯蒂芬老哥也沒當回事,直接請Copilot修復樣式問題,並把測試挪到之前的文件中。

沒過多久Copilot就回報:我已修復樣式問題,並把測試移動到現有文件中。

斯蒂芬老哥一檢查,很無奈,許多正規表達式測試現在都失敗了。

正是從這開始這條PR引起了程式設計師們的注意,幾百人點了「好笑」。

圖片

AI闖的禍還得AI自己收拾,Copilot嘗試修復錯誤,還總結到「最初的修復方案過於激進」。

圖片

結果這位先進的AI智能體,直接被更原始的程式Bot打臉了:此操作被取消,後續步驟可能不包含預期的日誌。

圖片

這下圍觀的網友直接崩不住了,跳出來陰陽怪氣「我真的看到了這個方案的潛力」。

與其讓真人花時間編寫無法運行的程式碼,不如讓電腦自己去編寫無法運行的程式碼,至少提高了寫無效程式碼的效率。

圖片

最終這條PR被斯蒂芬老哥手動關閉,他認為是由於配置問題,智能體無法訪問所需的依賴項。

圖片

而像這樣微軟員工和Copilot搭檔,最終失敗的PR還有……這麼多。

圖片

被折磨的也不是只有斯蒂芬一人,另一位員工埃瑞克還遇到手動關閉PR、刪除分支之後,一回頭Copilot又把分支恢復了,還改個標題請求老哥再審核。

圖片

不過既然都關閉了,埃瑞克後來直接就沒搭理它。

AI修復Bug,沒修好還狡辯

在另一個有關正規表達式的PR中,bug是由於堆棧回溯時陣列越界出現異常。

Copilot給的方案居然是添加一個邊界檢查,當超出陣列長度時返回「不匹配」,避免拋出異常。

圖片

這個方案被斯蒂芬評價為「治標不治本」,那到底為什麼會出現越界,還是沒有解決。

這回Copilot直接沒有反應,還要老哥再@一遍才動。

圖片

Copilot有反應了,但沒有給出新的解決方案,而是說了一大套理由論證自己的方案已經有效解決了問題,還是「優雅地」。

圖片

斯蒂芬也沒法說服AI,而是指出新的問題,又是測試程式碼沒放對位置所以沒執行。

圖片

放對了位置之後,不出意外地又出了意外,AI添加的測試都失敗了。

圖片

到這裡圍觀網友已經看不下去了,認為微軟員工應該自己動手解決問題,而不是浪費時間指導AI。

畢竟這可是.NET運行時的程式碼,多少雲端運算、醫療、金融等行業的重要系統要依賴它運行。

圖片

混亂中還有人嘗試越獄提示詞,想讓AI用PHP語言把整個專案重寫一遍。

不過還好微軟做了權限管理,非專案參與者的指令對Copilot不起作用。

圖片

斯蒂芬老哥還是堅持智能體的配置問題正在修復,還將繼續進行實驗。

圖片

而大家的意見是:還是別繼續了,趕緊取消這個實驗吧。

圖片圖片

微軟員工回應:不是強制性要求

Copilot智能體的糟糕表現,圍觀的程式設計師一開始只是覺得好笑,但慢慢也開始思考對於整個行業來說意味著什麼。

結合微軟剛剛大裁員3%,還披露公司20%-30%的程式碼由AI生成這一消息,讓人懷疑Copilot就是用來替代被裁掉的6000人的。

圖片

這樣繼續下去,讓人無法再繼續信任.NET這個平台了,總有一天AI寫的糟糕程式碼會進入生產環境。

圖片

有人從更大的視角,認為這也違背了人類開發AI的初衷。

本來應該是機器輔助人類工作的,現在倒過來成了人類被迫輔助機器。

圖片

一位.NET開發者提出,有多少AI是基於15年前的Stack Overflow答案進行訓練的,而這些答案已經不再代表目前的模式或推薦方法。

如果AI持續不斷的失敗,會消磨掉專案維護者的耐心麼?

或者這只是微軟做給熱衷於AI的股東看,而下的命令?

圖片

不過斯蒂芬老哥回復,使用Copilot不是公司強制性的要求,團隊一直在實驗AI工具以了解在當前和未來的局限性。

並且他認為:

任何不考慮如何利用這些AI工具的人,將來都會被淘汰。

圖片

One More Thing

整個.NET運行時程式碼庫中,Copilot自動修復Bug成功合併程式碼的案例只找到兩個,也都是合作的人類程式設計師反覆提示修改後才成功。

圖片

不過Copilot還在很多PR中當輔助程式碼審核員,這些比較順利,基本都成功了。

圖片

這款Copilot智能體看來目前還是只能幹幹自動補全,總結程式碼內容的活。

真修Bug,還得靠人。

圖片

吃瓜現場:https://github.com/dotnet/runtime/pull/115743https://github.com/dotnet/runtime/pull/115743https://github.com/dotnet/runtime/pull/115733https://github.com/dotnet/runtime/pull/115732https://github.com/dotnet/runtime/pull/115822

— 完 —

量子位AI主題策劃正在徵集中!歡迎參與專題365行AI落地方案,一千零一個AI應用,或與我們分享你在尋找的AI產品,或發現的AI新動向。

💬 也歡迎你加入量子位每日AI交流群,一起來暢聊AI吧~

圖片

一鍵關注 👇 點亮星標 科技前沿進展每日見

一鍵三連「點讚」「轉發」「小心心」歡迎在評論區留下你的想法!

主標籤:人工智慧

次標籤:微軟Copilot(智慧助理)GitHub錯誤修復軟體開發


上一篇:打破思維鏈推理瓶頸!“軟推理”讓大模型學會人類抽象能力,token使用量還更少了

下一篇:AI越聰明越不聽話!新研究:最強推理模型指令遵循率僅50%

分享短網址