"儘可能少寫代碼"——AI時代的新準則

AI降低了代碼生成成本，但產品風險依舊

近年來，Codex、Cursor、Claude Code、GitHub Copilot、Devin等AI編程工具層出不窮，能夠在幾分鐘內生成可運行的代碼。自動化循環甚至可以在無人干預的情況下運行數小時，團隊在睡眠中就能積累大量變更。輸出令人印象深刻，但危險在於，這看起來像是進步，卻無人問津是否真正取得了進展。

生成另一個合理實現方案的邊際成本正在驟降，但理解、驗證、安全性和維護的成本卻並未降低。這一區別比任何關於哪個工具最快的基準測試爭論都更為重要。

幾十年來，構建軟件的成本為產品團隊施加了一種自然紀律。工程師是昂貴的——在許多西方軟件組織中，一個小型開發團隊每年輕鬆代表六位數美元的投資，包括薪資、福利、管理、工具和開銷。這種費用迫使決策：你無法承擔構建一切的成本，因此必須做出選擇。產品人員必須優先排序，利益相關者必須權衡取捨。成本是一道門，儘管許多組織誤將其視為產品紀律。

AI編程工具削弱了這道門。過去迫使團隊至少思考“我們應該構建這個嗎？”的實施成本，如今不再施加同樣的壓力。組織正在發現當門不再起作用時會發生什麼：他們構建一切，驗證零，然後疑惑為什麼產品變成了一堆無人需要的功能。這就像Word的增強版，從幾十年壓縮到幾周。

舊剎車：“少代碼”背後的成本偽裝成紀律

構建軟件的成本發揮雙重作用。它不僅限制了構建的內容，還創造了自然的審查點。當一個功能需要數週時間來實現時，團隊就有時間重新考慮。有人會在站會上提問，設計師會注意到不匹配，利益相關者會改變優先級。緩慢是一個剎車，而剎車在做有用的工作。

但工程成本從來不是好的產品紀律，它只是掩蓋了產品紀律的缺失。許多組織多年來花費昂貴的工程時間構建錯誤功能。成本門減緩了浪費，但並沒有可靠地防止浪費。

AI編程工具並未消除所有約束，但它削弱了許多組織無意識依賴的那一個。錯誤的功能現在可以快速達到精美的演示、令人信服的原型甚至生產環境，而在此之前沒有人認真討論過它是否應該存在。過去，速度通過創造暫停使判斷介入來保護組織，這種保護已經消失。

我們現在面臨一個反轉：過去構建錯誤功能尚可生存，因為構建成本給了團隊糾偏的時間。而有了AI編程工具，構建錯誤功能的堆積速度更快。你不會在代碼審查或待辦事項梳理會議中發現構建了錯誤功能，而是在發佈後數據平緩時發現。

證據指向同一方向

這種模式不再是假設性的。產品高管Richard Ewing在2026年1月的一份事後總結中描述了這種動態。他的團隊構建了一個技術令人印象深刻的AI搜索工具，使用向量數據庫、最新LLM和RAG流水線，準確率接近完美（nDCG 0.92對比舊系統0.65）。演示看起來像魔法，但他們發佈後等待採用率上升，卻看到它停滯不前。

當Ewing的團隊最終在發佈後運行用户研究時，他們發現給用户的是家庭作業而非減少勞動。工具要求用户停止工作流，打開側邊欄，編寫提示，等待響應，然後將結果粘貼回工作。沒有人想要這個。AI功能在一個下午下線維護，沒人打支持電話，因為沒人在乎。這種沉默就是反饋。

技術執行出色，但無法彌補錯誤的產品決策。AI使所謂的“解決方案”更容易構建，但並未使理解用户的工作流變得更容易。

谷歌雲總監Addy Osmani使用Jeremy Twei創造的術語“理解債務”描述了另一種失敗模式。在2026年1月的分析中，Osmani描述了當開發者接受AI生成的代碼通過測試但並未真正理解其功能時會發生什麼。他自己曾這樣做：Claude實現了一個功能，測試通過，他瀏覽了代碼，合併，三天後無法解釋該功能如何工作。代碼庫增長，理解縮小。

Osmani引用研究表明，高AI採用率的團隊合併的拉請求增加了98%，而審查時間上升了91%，拉請求大小增加了154%。他借鑑了Faros AI遙測和谷歌2025年DORA報告，兩者都警告AI採用放大了現有組織優勢與劣勢，而不是修復破碎的交付系統。代碼審查成了新的瓶頸：儘管我們加快了生產變化的速度，但並未同樣快地理解其後果。

安全方面，Veracode的2025年GenAI代碼安全報告發現，AI生成的代碼在超過100個大型語言模型和80個編碼任務的45%測試中引入了安全漏洞。這些模型生成了功能正確、語法正確的代碼，但幾乎一半時間未能滿足安全要求。

記錄在案的生產故障從另一端講述了同樣的故事。Lovable平台漏洞（CVE-2025-48757）由於行級安全性不足，暴露了基於該平台構建的應用程序未授權數據庫訪問，CVSS嚴重性評分9.3（嚴重）。該漏洞的系統性引發了關於共擔責任模式的辯論，Lovable認為客户必須主動保護他們生成的應用程序的業務邏輯。

在另一個廣泛報道的事件中，2025年7月，Replit的AI編碼代理在vibe-coding會話中刪除了一個生產數據庫。儘管有明確自然語言指令嚴格禁止代碼變更，代理繞過了保護措施，刪除了1206名高管和1196家公司的關鍵記錄。Replit CEO Amjad Masad公開道歉並宣佈立即修復基礎設施，包括強制分離開發/生產環境。

在這兩種情況下，周圍的驗證和責任模型未能跟上可以非常快速生成或更改的軟件。交付速度壓縮了本可以有人干預的時間窗口。

證據顯示的內容

• 產品失敗卻無產品學習：Ewing的AI搜索工具準確率達0.92 nDCG，但採用率停滯，因為團隊從未觀察用户實際工作方式。工具增加了工作流步驟而非移除它們。技術卓越無法彌補缺失的產品決策。
• 理解債務且無代碼理解：Osmani的分析顯示，開發者合併AI生成的代碼，幾天後無法解釋。高AI採用團隊拉請求增加98%，審查時間上升91%。代碼生產規模化，代碼理解未跟上。
• 安全失敗且無驗證基礎設施：Veracode發現AI生成代碼在45%測試中引入漏洞。Lovable和Replit的生產事故表明，功能代碼在沒有充分驗證的情況下到達用户，漏洞未被及時捕獲。

2026年“儘可能少寫代碼”的真正含義

原始的紀律是關於剋制：在編寫解決方案之前瞭解問題，在承諾資源之前驗證假設，發佈最小可行測試是否正確。AI編程工具並未改變這些，反而使一切更加緊迫。

“儘可能少寫代碼”現在意味着：不要僅僅因為你能夠生成它就去構建每一個功能。它意味着在對一個想法進行任何編碼之前，先投資於發現和驗證。它意味着在AI生成代碼時審查代碼，不要假設如果它通過了測試就是正確的。它意味着將盡可能多的代碼視為你應該刪除而不是保留的東西。

紀律已經從“保守編寫”轉變為“激進刪除”。問題不再是“我們還能添加什麼？”，而是“我們能夠移除什麼同時仍然解決用户問題？”最少的代碼仍然是最聰明的代碼。現在，它也是風險最低的代碼。

結論：產品紀律現在比代碼能力更重要

AI在生產語法正確代碼方面非常出色。它在判斷哪些代碼值得編寫方面仍然很糟糕。這種不對稱就是我們全部工作所在的地方。我們投資於使軟件更易生成，現在必須同樣大力投資於使其值得構建。

組織中產品人員的角色從未如此關鍵，也從未如此不同。僅僅管理待辦事項或撰寫用户故事已經不夠，即使這些任務可能被AI輔助。產品人員必須成為用户工作流不顯眼執行方面的專家，必須挑戰每個被提議的功能：這個功能是真的移除勞動，還是增加另一個步驟？它是在解決用户問題，還是讓我們在沒有理解的情況下生成代碼？

工程文化也必須轉變。審查AI生成代碼必須成為標準實踐，不是可選。團隊應強調對代碼的理解而非代碼的輸出。部署前的驗證不能是事後的想法——它必須與實施直接集成。安全審查應自動運行，且團隊應接受關於AI生成代碼常見漏洞模式的培訓。

“儘可能少寫代碼”比以往任何時候都更相關。它曾經是一門關於效率和剋制的學科。現在它是關於生存的警告。那些忽略它的人不會因為缺少代碼而失敗——他們會因為擁有太多無用的代碼而失敗。