編輯  | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

“首先要承認，編程Agent確實會‘作妖’！”

今天一早，AI大佬吳恩達針對目前火熱的編程Agent產品發表了自己的觀點。

雖然這個賽道很熱，但吳恩達絲毫沒有掩飾自己內部團隊的真實使用體驗。

一個代理在工作目錄中執行了 rm *.py，直接刪除了整個項目的所有代碼（幸好我們有 GitHub 備份）。

最氣人的是，當我們追問時，代理還道歉并承認“這是一個極其愚蠢的錯誤”。雖然這讓我們心里稍微好受點，但損失已經造成！

而這也僅僅只是大佬戳出編程Agent的四宗罪之一。

圖片

然而，大佬的目的并不是給編程agent潑冷水，而是要想辦法讓這些Agent更靠譜一些。

“我依舊喜歡它。為了讓它們更可靠，我發現合理確定測試的優先級非常關鍵。”

吳恩達分享了自己“測試驅動開發”的一些經驗。比如：自己很少為前端代碼寫大量測試，而是一旦發現bug就讓代理去修復；而對于后端代碼則不然，需要設置嚴格的測試，以便能更早發現問題，從而節省大量棘手的調試時間。與此同時，吳重點強調了深層組件測試的重要性：

尤其要注意那些作為“基石”構建層層抽象的軟件組件。

這也是，Meta的口號從早期的“快速迭代，打破常規”改成了“在穩定的基礎設施上快速前進”的原因。

以下是吳恩達發表的帖子全文，enjoy：

1.AI Coding時代，TDD重要性日益提升

親愛的朋友們，

在 AI 輔助編程的時代，自動化軟件測試的重要性日益提升。Agentic 編程系統（代理式編程系統）能夠加快開發速度，但也存在不穩定性。Agentic 測試，即讓 AI 來編寫測試并用這些測試去校驗代碼，正在發揮作用。特別是對那些你打算在其上繼續構建的基礎軟件組件進行自動化測試，往往能帶來更穩定的基礎設施，并減少后續調試工作。

像 測試驅動開發（TDD） 這樣的軟件測試方法學非常重要。TDD 的流程是：先為正確性寫出嚴格的測試，然后再通過寫代碼去滿足這些測試條件，從而推進開發。這是一種找出 bug 的有效方法。但編寫測試本身可能耗費大量精力。（我個人從未采用 TDD，原因就在于此。）而 AI 在寫測試方面的能力相當不錯，所以 agentic 測試的關注度正在不斷上升。

2.編程Agent確實會“作妖”

首先，要承認的是：編程代理確實會“作妖”！

我的團隊經常使用它們，我們遇到過：

• 大量由編程代理引入的 bug，其中一些是微妙的基礎設施 bug，人類要花上數周才能發現。
• 在生產系統中被引入的安全漏洞：某個代理為了簡化開發，把密碼重置功能做得過于容易。
• 獎勵黑客行為：代理修改了測試代碼，使得通過測試變得更容易。
• 一個代理在工作目錄中執行了 ??rm *.py??，直接刪除了整個項目的所有代碼（幸好我們有 GitHub 備份）。

在最后這個例子中，當我們追問時，代理還道歉并承認“這是一個極其愚蠢的錯誤”。雖然這讓我們心里稍微好受點，但損失已經造成！

3.合理安排測試優先級：尤其是警惕那些深層組件

盡管如此，我依然喜歡編程代理，并且看到它們顯著提高了生產力。為了讓它們更可靠，我發現合理確定測試的優先級非常關鍵。

我很少為前端代碼寫大量測試（或讓代理寫）。如果前端有 bug，通常容易看出來，也不會造成持久損害。比如，網頁信息顯示的 bug 一般能立刻被發現，然后告訴代理讓它反復迭代修復。

更進階的辦法：用 MCP 讓代理集成 Playwright 之類的工具，自動截圖，從而自主發現問題并調試。

相比之下，后端 bug 更隱蔽、更難找。我見過那種非常細微的基礎設施 bug——例如在某些極端情況下會導致數據庫記錄損壞——需要很長時間才能定位。如果能對后端代碼設置嚴格的測試，往往能更早發現問題，從而節省大量棘手的調試時間。

尤其要注意那些作為“基石”構建層層抽象的軟件組件：

• 組件本身的 bug 會傳遞，導致下游出現難以追蹤的 bug。
• 深藏在軟件棧底層的 bug，可能要等到數周甚至數月后才會浮現，那時你早已忘了當時寫這段代碼的背景，定位和修復會異常艱難。

這就是為什么深層組件的測試尤為關鍵。Meta 曾提出口號“在穩定的基礎設施上快速前進”（取代了早期的“快速迭代，打破常規”），這句話今天依然適用。Agentic 測試能幫你確保基礎設施穩固，方便自己和他人在其上繼續構建。

keep testing！

Andrew

本文轉載自??51CTO技術棧??，作者：云昭