編輯  | 云昭

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

“氛圍編碼剝奪了你對其生成的代碼的深入理解！”

近期，關(guān)于討論氛圍編程的討論多得一塌糊涂。隨著各種編程代理產(chǎn)品的使用增多，越來越多有關(guān)“AI編碼導(dǎo)致人類程序員思維惰性”的討論引起了業(yè)內(nèi)關(guān)注。

近期，英國一位初創(chuàng)企業(yè)的CTO和聯(lián)合創(chuàng)始人，認(rèn)真對比了傳統(tǒng)編程和AI輔助編程的流程變化，同時(shí)警告，AI編碼存在一個(gè)魔力陷阱：

AI 編碼代理的確效率驚人，但他們對你的業(yè)務(wù)、代碼庫或路線圖一無所知。

這位大牛認(rèn)為，歸根結(jié)底，還是人們?nèi)绾慰创皩懘a” 。他認(rèn)為，軟件開發(fā)，其實(shí)大部分時(shí)間是在思考，然后小部分時(shí)間是coding。而現(xiàn)在的AI輔助編程工具則是反過來的，“先寫代碼，問題以后再說！”這就導(dǎo)致了一種怪象：

大模型飛快地完成了有趣的coding環(huán)節(jié)，而程序員則開始處理AI留給的、無窮無盡的“爛攤子”。

這一點(diǎn)也引起了圈內(nèi)人士的熱烈討論。一位網(wǎng)友表示非常認(rèn)同——

在大多數(shù)領(lǐng)域里，代碼并不是最終產(chǎn)品，數(shù)據(jù)才是。代碼只是記錄、修改和刪除數(shù)據(jù)的方式。但最終有意義、有價(jià)值的是數(shù)據(jù)。

這就是為什么有句話說：“別告訴我代碼寫了什么——把數(shù)據(jù)給我看，我就能告訴你代碼在做什么。”

也有網(wǎng)友表示反對：

大模型生成的代碼跟上一任已離職的代碼作者所寫的混亂代碼有什么區(qū)別呢？

很快就有人回應(yīng)了：區(qū)別大了！區(qū)別在于心智模型的建立！

區(qū)別在于擺脫困境的希望。如果你接手了一個(gè)混亂不連貫的代碼庫，你會(huì)意識到這是一個(gè)問題，并努力修復(fù)它。你可以通過先閱讀代碼，然后可能重寫其中的一部分來建立對代碼的理解。隨著時(shí)間的推移，這會(huì)提高你對代碼的推理能力。

如果你不斷地把自己置于那種境地，把代碼推理交給代碼代理，那么你就無法建立起心智模型。你總是回到必須“擁有”別人代碼的第一天。

這一點(diǎn)，小編非常認(rèn)同。

話說回來，那么我們?nèi)绾伪苊釧I編程陷阱呢？如何讓AI在處理高復(fù)雜度的軟件交付過程中，能夠?qū)崿F(xiàn)高效、高質(zhì)的人機(jī)合作？

這位CTO給出了自己的一個(gè)方案：在開發(fā)生命周期的每個(gè)環(huán)節(jié)引入 AI，并建立一套團(tuán)隊(duì)實(shí)踐，讓AI這位初級工程師在最小化返工的框架下高效協(xié)作，同時(shí)獲得成長與學(xué)習(xí)機(jī)會(huì)。

邏輯非常順暢，分析得非常到位，值得大家收藏細(xì)看。

軟件開發(fā)的本質(zhì)，不是寫代碼

如果你曾經(jīng)看過有人在“寫代碼”，你可能會(huì)發(fā)現(xiàn)他們花在發(fā)呆上的時(shí)間遠(yuǎn)比敲鍵盤多。別誤會(huì)，他們（大概率）不是在摸魚。

軟件開發(fā)本質(zhì)上是一種解決問題的實(shí)踐，就像解復(fù)雜的填字游戲一樣，大部分工作其實(shí)都發(fā)生在腦子里。

在軟件開發(fā)生命周期中，編碼就像是把填字游戲的答案填到格子里——它只占據(jù)了很小一部分精力，真正的工作往往伴隨著編碼展開：開發(fā)者要熟悉領(lǐng)域知識、細(xì)化需求、構(gòu)建合適的抽象、考慮副作用、逐步測試功能，并最終修復(fù)那些在嚴(yán)格流程中漏網(wǎng)的 bug。

流程大概是這樣的：

圖片

但在 AI 驅(qū)動(dòng)的編碼里，情況完全不一樣。

“先寫代碼，問題以后再說”

像 Claude Code 這樣的 AI 編碼代理，可以在孤立場景中驚人地快地寫出代碼。但絕大多數(shù)軟件都存在于復(fù)雜系統(tǒng)中，而大模型還無法一次性記住整個(gè)應(yīng)用的上下文，所以人工的審查、測試和集成仍然不可或缺。

可問題是，當(dāng)代碼是 AI 寫的，而人類并沒有在寫之前思考過，那么后續(xù)理解就會(huì)變得異常困難。結(jié)果就是，在復(fù)雜軟件開發(fā)中，開發(fā)者會(huì)花大量時(shí)間事后搞清楚 AI 究竟寫了些什么。

圖片

這就是 AI 寫代碼的宣傳話術(shù)（號稱“10 倍提速”）與真實(shí)交付可用軟件時(shí)的效率提升（通常只有 10% 左右）的差別所在。

圖片

更令人沮喪的是，開發(fā)者會(huì)發(fā)現(xiàn)自己花在“修 AI 爛攤子”上的時(shí)間越來越多。大模型飛快搞定了有趣、輕松的部分，我們卻被留給了那些吃力不討好的任務(wù)：測試以確保舊功能沒被破壞、清理重復(fù)代碼、寫文檔、處理部署和基礎(chǔ)設(shè)施等等。真正能沉浸在寫代碼本身的時(shí)間反而越來越少。

不過，別急——這并不是一個(gè)全新的問題。事實(shí)上，它不過是一個(gè)老掉牙難題的極端版本：

技術(shù)負(fù)責(zé)人的兩難

當(dāng)工程師的職業(yè)生涯發(fā)展到一定階段，就會(huì)進(jìn)入 tech lead（技術(shù)負(fù)責(zé)人）的角色。他們可能要管理團(tuán)隊(duì)，也可能只是作為首席工程師推動(dòng)技術(shù)交付。但無論哪種情況，他們既要為團(tuán)隊(duì)交付負(fù)責(zé)，又往往是團(tuán)隊(duì)里經(jīng)驗(yàn)最豐富的人。

軟件交付是團(tuán)隊(duì)合作，但經(jīng)驗(yàn)差異會(huì)極大拉開成員的產(chǎn)出效率。因此，tech lead 常常在兩種交付方式中掙扎：

• 公平分工：把任務(wù)平均分配給所有人，讓新人有學(xué)習(xí)和成長機(jī)會(huì)，但交付速度會(huì)受限于最慢的成員。
• 包辦大部分核心任務(wù)：把簡單或無關(guān)痛癢的工作丟給新人，自己扛起最難的部分，以此保證交付速度。

可惜的是，雖然“包辦”模式對團(tuán)隊(duì)長期健康運(yùn)作極其有害，卻在短期內(nèi)確實(shí)能顯著提速。于是，經(jīng)驗(yàn)被集中在 tech lead 一人身上，結(jié)果就是：團(tuán)隊(duì)變脆弱、支持成本增加、負(fù)責(zé)人壓力倍增，最終的結(jié)局可想而知：倦怠、離職、團(tuán)隊(duì)危機(jī)。

圖片

解決辦法通常在第三種路徑里：既避免極端分工，又兼顧交付與成長。換句話說：

建立一套團(tuán)隊(duì)實(shí)踐，讓工程師在最小化返工的框架下高效協(xié)作，同時(shí)獲得成長與學(xué)習(xí)機(jī)會(huì)。

圖片

在我擔(dān)任 Datasine CTO 時(shí)，我們團(tuán)隊(duì)的座右銘是：

學(xué)習(xí)、交付、享受過程。

優(yōu)秀的 tech lead 會(huì)讓工程師不斷觸碰自己能力的邊界，同時(shí)用合理的流程和實(shí)踐來降低風(fēng)險(xiǎn)、確保交付。這正是優(yōu)秀技術(shù)領(lǐng)導(dǎo)力的本質(zhì)。

常見的方法包括：

代碼評審、增量交付、模塊化設(shè)計(jì)、測試驅(qū)動(dòng)開發(fā)、結(jié)對編程、高質(zhì)量文檔、持續(xù)集成

問題是：在 AI 驅(qū)動(dòng)的編碼世界里，如何把這些實(shí)踐延續(xù)下去？

閃電般的“初級工程師”

到了 2025 年，許多工程師第一次體會(huì)到 tech lead 的感受：你要帶的是一個(gè)聰明絕頂?shù)豢深A(yù)測的“新人”。不同的是，AI 的生產(chǎn)力和成長方式與人類完全不同。

人類工程師隨著經(jīng)驗(yàn)積累，會(huì)在兩個(gè)維度同時(shí)提升：

• 質(zhì)量：能寫出更復(fù)雜、更高性能、更易維護(hù)的代碼
• 速度：能更快寫出 bug 更少的可用代碼

圖片

早期的大模型寫代碼很快，但 bug 一堆，修復(fù)拖慢了進(jìn)度。現(xiàn)在的 AI 編碼代理通過更強(qiáng)的模型和上下文技巧，已經(jīng)能“一次寫對”不少代碼，甚至能媲美中級工程師。但他們依舊無法達(dá)到高級工程師的水平。

所以我們可以把 AI 編碼代理類比為初級工程師，但有兩點(diǎn)重大差異：

1. 他們寫代碼的速度遠(yuǎn)超人類新人；
2. 他們沒有真正的學(xué)習(xí)能力，只能靠更好的上下文工程或更強(qiáng)的新模型升級。

于是，AI 的使用方式也分兩種：

• AI 驅(qū)動(dòng)工程：重視實(shí)踐與理解，慢速推進(jìn)，確保可持續(xù)開發(fā)；
• “Vibe Coding”：靠直覺亂沖，追求短期速度，犧牲理解，最終撞上混亂不堪的墻。

圖片

短期來看，“Vibe Coding”很適合小項(xiàng)目或一次性原型。它能夠交付足夠簡單的應(yīng)用程序，而無需任何人工思考。通過限制項(xiàng)目的復(fù)雜性并充分利用工具的功能，我們可以立即交付端到端的可運(yùn)行軟件。

但一旦復(fù)雜度上來，AI 就會(huì)失靈。

如果我們想要有效地利用 LLM 來加速交付真實(shí)、復(fù)雜、安全且可運(yùn)行的軟件，并實(shí)現(xiàn)超越邊際的效率提升，我們就需要編寫一套全新的工程實(shí)踐手冊，以最大限度地促進(jìn)包括人類和 LLM 在內(nèi)的工程團(tuán)隊(duì)之間的協(xié)作。

圖片

如何避免 AI 編碼陷阱

AI 編碼代理的確效率驚人，但他們對你的業(yè)務(wù)、代碼庫或路線圖一無所知。如果沒人約束，他們會(huì)毫無顧忌地產(chǎn)出成千上萬行缺乏設(shè)計(jì)感、風(fēng)格一致性和可維護(hù)性的代碼。

這時(shí)候，工程師的工作，就像是這些“天才新兵”的技術(shù)負(fù)責(zé)人：提供結(jié)構(gòu)、標(biāo)準(zhǔn)和流程，把原始的速度轉(zhuǎn)化為可持續(xù)的交付能力。

所以，我們需要一本全新的行動(dòng)手冊，來指導(dǎo)如何高效交付可用軟件。而要做到這一點(diǎn)，回顧過去的經(jīng)驗(yàn)同樣有價(jià)值。

把大模型當(dāng)作“閃電般高效的初級工程師”，我們就能借鑒軟件開發(fā)生命周期的最佳實(shí)踐，來構(gòu)建可擴(kuò)展的系統(tǒng)。

通過結(jié)構(gòu)、標(biāo)準(zhǔn)和流程，把原始的速度優(yōu)勢轉(zhuǎn)化為可持續(xù)的交付。

圖片

這意味著要在開發(fā)生命周期的每個(gè)環(huán)節(jié)引入 AI：

• 需求：探索、分析和細(xì)化需求，覆蓋邊界情況。
• 文檔：提前生成和審查文檔，作為復(fù)用和證據(jù)。
• 模塊化設(shè)計(jì)：搭建可擴(kuò)展架構(gòu)，縮小上下文范圍。
• 測試驅(qū)動(dòng)開發(fā)：在實(shí)現(xiàn)前生成測試用例，防止回歸。
• 編碼規(guī)范：通過上下文工程讓代碼符合團(tuán)隊(duì)標(biāo)準(zhǔn)。
• 監(jiān)控與分析：利用 AI 快速分析日志并提煉洞察。

只有認(rèn)識到“寫代碼 ≠ 軟件交付”，我們才能避免 AI 編碼陷阱，讓人機(jī)協(xié)作真正放大交付能力。

參考鏈接：https://news.ycombinator.com/item?id=45405177

本文轉(zhuǎn)載自??51CTO技術(shù)棧??，作者：云昭