破解智能體編程"末日論"的五大誤區

關于"氛圍編程"（vibe coding），目前存在兩種截然對立的說法。一種認為，只需輸入一句話，AI就能交付一款價值百萬的應用；另一種則認為，既然代碼全由AI來寫，人類根本不知道里面是什么，遲早會釀成大規模的技術災難。

這兩種說法都是對現實的極端夸大。本文將深入探討將編程控制權交給機器后，隨之而來的維護性與可持續性問題，并逐一拆解圍繞智能體編程的幾大常見誤區。

智能體編程就像去一家口碑不錯的餐廳，你知道廚師水平過關，但端上來的究竟是什么，完全無從預料。當智能體負責編寫你的代碼時，本質上和管理一批外包團隊或下屬開發者沒有太大區別——在你親自測試和評估之前，無法確知產出的質量。一切的基礎都在于你的提示詞（prompt）。提示不清晰，缺乏足夠的監督和跟進，AI交回的代碼就很難讓人滿意。

工程管理者面對外包團隊的挑戰由來已久，分配任務、評估成果、把控質量，本就是軟件工程管理的核心所在。下面，我們來逐一剖析智能體編程中流傳的幾大誤區，以及能幫助你真正掌控AI輸出的最佳實踐。

誤區一：詳盡的需求文檔等于高質量代碼

許多AI編程倡導者建議為AI提供詳盡豐富的需求文檔。但實際經驗告訴我，AI有時會誤解文檔中某一個細節，進而完全跑偏，而你根本無從追溯。

更有效的做法是：每次只給AI一個簡單、明確的任務，完成后再交付下一個。這樣既能減少AI跑偏的機會，也能幫助你始終掌握整體進展。

誤區二：自動化測試能保證代碼質量

我有一位朋友，每次一看我的軟件項目，我就頭疼。無論我設計和測試得多么仔細，代碼一到他手里就會出問題。原因在于他沒有我對項目的"內部認知"——他不知道程序應該怎么用，總會做出我從未預想到的操作，代碼隨即崩潰。

這正是自動化測試體系脆弱性的典型體現。自動化測試能幫你發現某次修復是否引入了新問題，但因為測試是預先設計的，必然會遺漏那些"局外人"才會觸發的邊界情況。AI在構建單元測試時，同樣會繼承人類開發者測試中的盲區。

測試環境也不等同于真實環境。我的安全軟件在超過兩萬個網站上運行，用戶反饋的問題五花八門，遠超任何測試場景的覆蓋范圍。

解決方案是：像局外人一樣去測試。在提示詞中明確要求覆蓋邊界情況、故障模式和誤用場景；安排人員或AI在沒有任何內部背景的情況下對代碼進行故意破壞性測試；在代碼中內置異常行為監控機制，并將容錯和錯誤修正設計進每一處邏輯。

誤區三：AI生成的代碼是可理解的黑盒

AI生成的代碼，從本質上就是一個黑盒。這和接手通過IP收購獲得的代碼沒什么兩樣，里面藏著各種秘密——就像買了一套房，入住后才發現墻里面有故障線路和破損管道。

AI并非人類，其設計決策和代碼結構并不以人類的可讀性為前提。一旦出現問題，調試往往需要對AI的工作進行逆向工程，再設法引導AI修復一個它當初可能就沒完全理解的問題。

AI生成的代碼往往缺乏一致的設計意圖、結構和架構連貫性，命名規范和模式也可能因組件而異。這導致任何修改都可能在意想不到的地方引發連鎖bug。

以我用Claude開發一款iPhone應用為例：幾天后查看文件結構，發現完全混亂——文件隨意放置、命名隨意、毫無分組邏輯，所有內容堆在同一個主目錄下。后來我指示AI整理文件結構，雖然反復調整了幾次才找到合理的組織方式，但最終將其固化為啟動指令。像管理者一樣思考，才能真正駕馭這個"數字下屬"。

此外，建議在智能體編程實踐中同時使用基于不同大語言模型的多個AI，讓一個模型編寫代碼，讓另一個模型審查代碼，交叉互檢，能有效提升代碼質量。

誤區四：AI編程不會帶來安全隱患

測試脆弱性與維護技術債疊加，幾乎必然產生安全盲區。編寫質量差、存在固有缺陷的代碼，是滋生安全問題的溫床。

AI編程模型基于公開互聯網數據訓練，其中包含大量有缺陷的代碼和錯誤建議。模型因此可能復現從公開數據中學到的不安全編程模式，例如輸入驗證和過濾缺失，從而留下潛在的利用漏洞。

我曾發現，我使用的AI在為安全產品編寫代碼時，完全沒有做任何輸入驗證，完全違背了最基本的安全實踐。在我明確要求后，AI生成的驗證邏輯反而比我自己寫的更加完善——但前提是我必須主動、明確地提出這一要求。

AI還可能引入看似合適、實則存在供應鏈漏洞的第三方庫。加之AI生成代碼的速度遠超人類審查速度，錯誤很容易在人工核驗到達之前就已悄然混入。

好消息是，AI同樣可以成為安全修復的有效工具。我曾讓AI分析一個存在嚴重漏洞的開源模塊，識別漏洞后重新生成了不含這些漏洞的代碼模塊；再用另一個AI對前者的輸出進行驗證，發現了更多需要修復的問題，如此循環，直到不再報錯。安裝至今已數月，服務器托管商未再標記任何安全異常。

誤區五：調試和維護成本會徹底抵消AI編程的效率收益

許多對氛圍編程持警惕態度的文章認為，雖然AI大幅壓縮了編碼階段的時間，但調試和維護的時間成本也隨之膨脹，往往是在代碼交付用戶后才暴露出亂象。

這種擔憂并非空穴來風，但其實和接手收購來的代碼、或管理外包團隊產出的代碼并無本質區別。工程管理者與這類問題打交道已有幾十年，良好的軟件工程規范、項目規劃和管理實踐，本就是為了克服外包透明度不足的問題，所需要的只是紀律、訓練和經驗。

這一切都指向同一個核心前提：AI不是萬能的銀彈。你不可能靠一行提示詞創造出一款價值百萬的產品。你必須投入真正的工作。你可以利用AI縮短上市時間，利用AI輔助維護，利用AI發現并修復安全漏洞，也可以享受與AI協作的樂趣。

但請始終記住：AI是工具，你才是專業人員。你需要主動管理、有意識地委派任務、并進行大量測試。只要做到這些，所謂的智能體編程"末日"完全可以避免，真正扎實的成果也完全可以實現。

Q&A

Q1：智能體編程（agentic coding）和普通AI輔助編程有什么區別？

A：智能體編程是指讓AI智能體自主完成整段代碼的編寫，類似于將任務交給外包團隊，開發者充當工程管理者的角色，負責分配任務、檢查成果和把控質量。而普通AI輔助編程更多是開發者主導、AI提供建議或補全片段。智能體編程效率更高，但代碼透明度更低，需要更嚴格的測試和管理機制。

Q2：AI生成的代碼安全性如何保障？

A：AI編程模型基于公開互聯網數據訓練，可能復現不安全的編程模式，例如缺乏輸入驗證。保障安全的方法包括：明確在提示詞中要求安全實踐（如輸入驗證）；使用第二個AI模型對生成代碼進行交叉審查；關注引入的第三方庫是否存在供應鏈漏洞；并在發現漏洞后讓AI協助重新生成安全版本，循環驗證直到無誤。

Q3：如何有效管理AI生成代碼的質量和可維護性？

A：核心方法是像管理外包團隊一樣管理AI：每次只分配一個簡單明確的任務；在每個階段設置檢查點，逐步驗證集成；要求AI在測試中覆蓋邊界情況和故障模式；要求AI保持一致的文件結構和命名規范，并將規范固化為啟動指令；同時使用多個基于不同大語言模型的AI互相審查代碼，提升整體質量。