氣氛編程崩了：AI寫代碼的隱藏天花板

你試過讓AI寫一個完整項目嗎？前三句對話像魔法，第十句開始像吵架。

上個月，作者用Claude（一款人工智能助手）寫了個網址縮短服務。第一版代碼完美運行，第五版開始數據庫結構被改來改去，第十版時AI已經忘了二十分鐘前定好的接口規范。這不是AI不行，是用法錯了。

氣氛編程的甜蜜陷阱

「氣氛編程」（Vibe Coding）這個詞最近很火——隨手丟給AI幾句需求，看它像變魔術一樣吐代碼。作者的經歷很多人熟悉：

第一輪："建個網址縮短API。" 代碼出來了，測試通過，感覺自己成了巫師。

第二輪："加個統計功能，看每個短鏈被點了多少次。" 沒問題，兩個功能搞定。

第三輪："加上用戶系統，讓人能管理自己的鏈接。" 這時候開始崩。第一輪的數據庫結構跟第三輪的用戶認證打架，第二輪的統計查詢跟第三輪的權限邏輯沖突。AI試圖修復，卻引入了新bug。你拼命解釋，但上下文窗口（AI能記住的對話長度）滿了，AI早忘了之前的約定。

你不再是寫代碼，是在用鍵盤趕貓。

這種「小腳本神器、大項目災難」的模式有個結構性原因，不是技術問題，是工作方法的問題。

那個你沒命名但一定感受過的隱藏限制

作者做了組對比實驗。

任務A：寫一個Python函數，判斷字符串是不是有效網址。AI幾秒給出干凈、正確、帶注釋的代碼。質量：優秀。

任務B：用Python建完整的網址縮短服務，含網頁界面、接口、用戶系統、點擊統計、數據庫。AI也給出了東西，但結果脆弱——認證模塊跟統計模塊接不上，數據庫結構可能支持不了后續擴展。

核心差異：任務A的輸出是單一、自包含的代碼塊；任務B的輸出是多個必須協作的代碼塊，而AI沒有真正的「系統記憶」。

每次你發新提示，AI都在重新解讀整個項目。它不會記得「我們上次說好用PostgreSQL」——它只是在猜測當前上下文里最可能的答案。當項目超過一定復雜度，這種猜測的誤差會累積成災難。

作者的原話很直白：「這不是AI的失敗，是方法的失敗。」

為什么更好的提示詞救不了你

很多人第一反應：那我寫更詳細的提示詞？加更多約束？

作者試過。更長的提示詞確實能讓單次輸出更精準，但解決不了根本問題——AI的「記憶」是模擬的，不是真正的狀態保持。你可以讓它「假裝記得」，但它不會真的記得二十輪對話前的一個字段命名約定。

更隱蔽的問題是：AI會擅自加戲。作者的經驗里，AI會在第五輪左右開始添加「你沒要的功能」，修改「你沒讓改的結構」。這不是惡意，是概率模型的副作用——當上下文變得模糊，AI會傾向于生成「看起來合理」的代碼，而不是「嚴格遵循之前約定」的代碼。

提示詞工程（Prompt Engineering）的極限就在這里。你可以優化單次對話，但無法優化一個持續演進的系統。

真正的問題：我們把AI當搜索引擎用

作者點出了一個習慣誤區：大多數人用AI像用搜索引擎——問個問題，拿個答案，走人。查菜譜、問 trivia（冷知識），這招好使。

但寫軟件不是查資料。軟件是活的系統，需要一致性、可追溯的決策、模塊間的契約。搜索引擎模式（單次問答）和系統工程模式（持續演進）天生沖突。

作者的原話：「AI有一個隱藏限制。不是技術限制——是結構性限制。一旦你看見它，就再也看不見了。」

這個系列的后文會展示解法。但核心思路已經透露：不是更好的提示詞，是不同的工作思維方式。

作者拋了個反問：「如果問題從來不在AI身上呢？」

言下之意：我們可能一直在錯誤的地方找答案。AI能生成代碼塊，但我們需要的是把代碼塊放進一個「工作系統」的方法——讓AI的輸出成為可積累、可追蹤、可協作的構件，而不是一次次獨立的魔術表演。

氣氛編程的崩潰，本質是「即興創作」和「系統工程」的沖突。AI擅長前者，后者需要人的結構設計。作者的經歷說明：當項目復雜度超過某個閾值，缺乏結構的氣氛編程必然失控。

這個閾值在哪？因人而異，因項目而異。但癥狀是統一的：你開始花更多時間「跟AI解釋之前說過什么」，而不是「推進新功能」。一旦出現這個信號，氣氛編程就已經從加速器變成拖油瓶了。

作者的解法還沒完全展開，但方向很明確：把AI生成的代碼塊，嵌入一個有記憶、有結構的工作系統。不是讓AI記住一切，是讓人工設計的系統來承載記憶和一致性。

這聽起來像回到了傳統軟件工程？某種程度上是。但作者暗示的可能是某種混合模式——AI負責生成構件，人負責設計構件如何組合，系統負責記錄組合規則。

具體怎么做，原文留到了系列后續。但單就這篇的診斷而言，已經足夠讓氣氛編程的實踐者警醒：魔法有邊界，知道邊界在哪，比假裝魔法萬能更務實。

畢竟，跟一臺二十分鐘后就失憶的機器談判，算不上愉快的工作體驗。