北京
我第一次用 AI Agent 時很受震撼。它能比開發者描述需求還快地搭出一個 RESTful 的概念驗證應用。架構談不上多精巧，但跑起來沒問題，有時甚至穩定得出奇。但奇怪的是，這種從零搭出來的應用，只要交給 Agent 做幾次“小修改”，質量就開始崩塌。改得越多，代碼庫腐化越快。
起初我把這歸結為 Agent 的能力天花板。后來我發現，當開發者能把期望的改動說得很精確時，Agent 是能做對的。所以問題不在于 Agent 能不能完成，而在于——為了把任務說清楚，開發者得付出什么代價。
核心癥結出在更前一步：開發者把“選什么方案”這件事也委托出去了，然后試圖在代碼審查時重新奪回控制權。但如果沒有一個自己心中的預期方案，就只能憑“看起來合理”“測試通過”“沒明顯 bug”來判斷，根本無法確認架構、依賴和切入點的選擇是否恰當。工程決策一旦放手給 AI，就別指望在審代碼時突然恢復掌控。
如果審查時發現嚴重問題，開發者就面臨兩難：繼續在那坨代碼上修，還是推翻重寫。每一輪迭代都讓審查變得更吃力，因為新改動要同時對照原代碼和 Agent 之前的修改。而放棄的成本也越來越高——已經在提示、生成、審查上花了時間，每個局部問題看起來都像是“再修一下就好了”，很難下決心全扔。有時能救回來，更多時候，拉鋸多輪之后，最終還是得自己動手重新實現。
這就是為什么面對復雜任務，很多開發者寧愿選擇最穩妥的方式：自己寫。不是因為 Agent 沒能力完成，而是因為沒有預先定義好解法時，和 Agent 協作的成本完全不可控。像原始人一樣手寫代碼的確既慢又痛苦，但它至少可預期。要讓 AI 在復雜任務上真正發揮威力，關鍵不在于 Agent 更強，而在于開發者先在腦子里把解法想清楚——獨立地，或者借助 AI——然后告訴它要改什么、保留什么，以及用什么標準來判斷結果。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
