“先寫代碼，問題以后再說！”AI初創CTO戳破氛圍編程陷阱：快速出原型還可以，復雜度一上來就失靈！ 原創
編輯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
“氛圍編碼剝奪了你對其生成的代碼的深入理解！”
近期，關于討論氛圍編程的討論多得一塌糊涂。隨著各種編程代理產品的使用增多，越來越多有關“AI編碼導致人類程序員思維惰性”的討論引起了業內關注。
近期，英國一位初創企業的CTO和聯合創始人，認真對比了傳統編程和AI輔助編程的流程變化，同時警告，AI編碼存在一個魔力陷阱：
AI 編碼代理的確效率驚人，但他們對你的業務、代碼庫或路線圖一無所知。
這位大牛認為，歸根結底，還是人們如何看待“寫代碼” 。他認為，軟件開發，其實大部分時間是在思考，然后小部分時間是coding。而現在的AI輔助編程工具則是反過來的，“先寫代碼，問題以后再說！”這就導致了一種怪象：
大模型飛快地完成了有趣的coding環節，而程序員則開始處理AI留給的、無窮無盡的“爛攤子”。
這一點也引起了圈內人士的熱烈討論。一位網友表示非常認同——
在大多數領域里，代碼并不是最終產品，數據才是。代碼只是記錄、修改和刪除數據的方式。但最終有意義、有價值的是數據。
這就是為什么有句話說：“別告訴我代碼寫了什么——把數據給我看，我就能告訴你代碼在做什么。”
也有網友表示反對：
大模型生成的代碼跟上一任已離職的代碼作者所寫的混亂代碼有什么區別呢？
很快就有人回應了：區別大了！區別在于心智模型的建立！
區別在于擺脫困境的希望。如果你接手了一個混亂不連貫的代碼庫，你會意識到這是一個問題，并努力修復它。你可以通過先閱讀代碼，然后可能重寫其中的一部分來建立對代碼的理解。隨著時間的推移，這會提高你對代碼的推理能力。
如果你不斷地把自己置于那種境地，把代碼推理交給代碼代理，那么你就無法建立起心智模型。你總是回到必須“擁有”別人代碼的第一天。
這一點，小編非常認同。
話說回來，那么我們如何避免AI編程陷阱呢？如何讓AI在處理高復雜度的軟件交付過程中，能夠實現高效、高質的人機合作？
這位CTO給出了自己的一個方案：在開發生命周期的每個環節引入 AI，并建立一套團隊實踐，讓AI這位初級工程師在最小化返工的框架下高效協作，同時獲得成長與學習機會。
邏輯非常順暢，分析得非常到位，值得大家收藏細看。
軟件開發的本質，不是寫代碼
如果你曾經看過有人在“寫代碼”，你可能會發現他們花在發呆上的時間遠比敲鍵盤多。別誤會，他們（大概率）不是在摸魚。
軟件開發本質上是一種解決問題的實踐，就像解復雜的填字游戲一樣，大部分工作其實都發生在腦子里。
在軟件開發生命周期中，編碼就像是把填字游戲的答案填到格子里——它只占據了很小一部分精力，真正的工作往往伴隨著編碼展開：開發者要熟悉領域知識、細化需求、構建合適的抽象、考慮副作用、逐步測試功能，并最終修復那些在嚴格流程中漏網的 bug。
流程大概是這樣的：
圖片
但在 AI 驅動的編碼里，情況完全不一樣。
“先寫代碼，問題以后再說”
像 Claude Code 這樣的 AI 編碼代理，可以在孤立場景中驚人地快地寫出代碼。但絕大多數軟件都存在于復雜系統中，而大模型還無法一次性記住整個應用的上下文，所以人工的審查、測試和集成仍然不可或缺。
可問題是，當代碼是 AI 寫的，而人類并沒有在寫之前思考過，那么后續理解就會變得異常困難。結果就是，在復雜軟件開發中，開發者會花大量時間事后搞清楚 AI 究竟寫了些什么。
圖片
這就是 AI 寫代碼的宣傳話術（號稱“10 倍提速”）與真實交付可用軟件時的效率提升（通常只有 10% 左右）的差別所在。
圖片
更令人沮喪的是，開發者會發現自己花在“修 AI 爛攤子”上的時間越來越多。大模型飛快搞定了有趣、輕松的部分，我們卻被留給了那些吃力不討好的任務：測試以確保舊功能沒被破壞、清理重復代碼、寫文檔、處理部署和基礎設施等等。真正能沉浸在寫代碼本身的時間反而越來越少。
不過，別急——這并不是一個全新的問題。事實上，它不過是一個老掉牙難題的極端版本：
技術負責人的兩難
當工程師的職業生涯發展到一定階段，就會進入 tech lead（技術負責人）的角色。他們可能要管理團隊，也可能只是作為首席工程師推動技術交付。但無論哪種情況，他們既要為團隊交付負責，又往往是團隊里經驗最豐富的人。
軟件交付是團隊合作，但經驗差異會極大拉開成員的產出效率。因此，tech lead 常常在兩種交付方式中掙扎：
- 公平分工：把任務平均分配給所有人，讓新人有學習和成長機會，但交付速度會受限于最慢的成員。
- 包辦大部分核心任務：把簡單或無關痛癢的工作丟給新人，自己扛起最難的部分，以此保證交付速度。
可惜的是，雖然“包辦”模式對團隊長期健康運作極其有害，卻在短期內確實能顯著提速。于是，經驗被集中在 tech lead 一人身上，結果就是：團隊變脆弱、支持成本增加、負責人壓力倍增，最終的結局可想而知：倦怠、離職、團隊危機。
圖片
解決辦法通常在第三種路徑里：既避免極端分工，又兼顧交付與成長。換句話說：
建立一套團隊實踐，讓工程師在最小化返工的框架下高效協作，同時獲得成長與學習機會。
圖片
在我擔任 Datasine CTO 時，我們團隊的座右銘是：
學習、交付、享受過程。
優秀的 tech lead 會讓工程師不斷觸碰自己能力的邊界，同時用合理的流程和實踐來降低風險、確保交付。這正是優秀技術領導力的本質。
常見的方法包括：
代碼評審、增量交付、模塊化設計、測試驅動開發、結對編程、高質量文檔、持續集成
問題是：在 AI 驅動的編碼世界里，如何把這些實踐延續下去？
閃電般的“初級工程師”
到了 2025 年，許多工程師第一次體會到 tech lead 的感受：你要帶的是一個聰明絕頂但不可預測的“新人”。不同的是，AI 的生產力和成長方式與人類完全不同。
人類工程師隨著經驗積累，會在兩個維度同時提升：
- 質量：能寫出更復雜、更高性能、更易維護的代碼
- 速度：能更快寫出 bug 更少的可用代碼
圖片
早期的大模型寫代碼很快，但 bug 一堆，修復拖慢了進度。現在的 AI 編碼代理通過更強的模型和上下文技巧，已經能“一次寫對”不少代碼，甚至能媲美中級工程師。但他們依舊無法達到高級工程師的水平。
所以我們可以把 AI 編碼代理類比為初級工程師，但有兩點重大差異：
- 他們寫代碼的速度遠超人類新人；
- 他們沒有真正的學習能力，只能靠更好的上下文工程或更強的新模型升級。
于是，AI 的使用方式也分兩種：
- AI 驅動工程：重視實踐與理解，慢速推進，確保可持續開發；
- “Vibe Coding”：靠直覺亂沖，追求短期速度，犧牲理解，最終撞上混亂不堪的墻。
圖片
短期來看，“Vibe Coding”很適合小項目或一次性原型。它能夠交付足夠簡單的應用程序，而無需任何人工思考。通過限制項目的復雜性并充分利用工具的功能，我們可以立即交付端到端的可運行軟件。
但一旦復雜度上來，AI 就會失靈。
如果我們想要有效地利用 LLM 來加速交付真實、復雜、安全且可運行的軟件，并實現超越邊際的效率提升，我們就需要編寫一套全新的工程實踐手冊，以最大限度地促進包括人類和 LLM 在內的工程團隊之間的協作。
圖片
如何避免 AI 編碼陷阱
AI 編碼代理的確效率驚人，但他們對你的業務、代碼庫或路線圖一無所知。如果沒人約束，他們會毫無顧忌地產出成千上萬行缺乏設計感、風格一致性和可維護性的代碼。
這時候，工程師的工作，就像是這些“天才新兵”的技術負責人：提供結構、標準和流程，把原始的速度轉化為可持續的交付能力。
所以，我們需要一本全新的行動手冊，來指導如何高效交付可用軟件。而要做到這一點，回顧過去的經驗同樣有價值。
把大模型當作“閃電般高效的初級工程師”，我們就能借鑒軟件開發生命周期的最佳實踐，來構建可擴展的系統。
通過結構、標準和流程，把原始的速度優勢轉化為可持續的交付。
圖片
這意味著要在開發生命周期的每個環節引入 AI：
- 需求：探索、分析和細化需求，覆蓋邊界情況。
- 文檔：提前生成和審查文檔，作為復用和證據。
- 模塊化設計：搭建可擴展架構，縮小上下文范圍。
- 測試驅動開發：在實現前生成測試用例，防止回歸。
- 編碼規范：通過上下文工程讓代碼符合團隊標準。
- 監控與分析：利用 AI 快速分析日志并提煉洞察。
只有認識到“寫代碼 ≠ 軟件交付”，我們才能避免 AI 編碼陷阱，讓人機協作真正放大交付能力。
參考鏈接：https://news.ycombinator.com/item?id=45405177
本文轉載自??51CTO技術棧??，作者：云昭
