動開發(fā)的實戰(zhàn)與避坑指南)
1. vibe coding到底是個啥以及我為什么開始關(guān)注它1.1 從玄學(xué)寫代碼到正經(jīng)工作流vibe coding的來龍去脈最近圈子里到處都在聊vibe coding有人把它當(dāng)玩笑說這是對著電腦吟唱讓代碼自己長出來也有人真的靠它一天從零搭完了一個能跑的工具站。最早這個概念指的是完全靠自然語言描述需求讓大模型直接生成代碼開發(fā)者只負(fù)責(zé)輸入感覺、審查結(jié)果。沒錯說的直白點就是你說人話AI寫代碼你負(fù)責(zé)看好它別把項目搞崩。讓我真正對這個詞上心的是Google面向零基礎(chǔ)用戶推出的那批vibe coding學(xué)習(xí)資源。你沒看錯零基礎(chǔ)。以前我們覺得編程是門手藝得從變量、函數(shù)、指針一步步啃但現(xiàn)在你完全可以先有一個想法然后通過自然語言驅(qū)動開發(fā)讓AI幫你把架子搭出來。這套流程已經(jīng)不只是技術(shù)圈的段子而是被正經(jīng)當(dāng)作一條學(xué)習(xí)路線在推廣。但問題也隨之而來vibe coding聽起來很美落地的時候你會發(fā)現(xiàn)工具多得離譜。Cursor、GitHub Copilot、Windsurf、Cline、通義靈碼、Codex CLI……每個都說自己是最強(qiáng)自然語言驅(qū)動開發(fā)工具可真上手試一圈體驗天差地別。有的把代碼寫好了還順手把配置文件改了有的連你讓它改個函數(shù)簽名都能裝死半天。所以我今天想把這陣子實際用過、折騰過、踩過坑的工具做個系統(tǒng)性對比聊聊各自的脾氣、適用場景和坑在哪。無論你是剛聽說vibe coding想試試水還是已經(jīng)在用但糾結(jié)要不要換工具這篇都應(yīng)該能給你點參考。1.2 自然語言驅(qū)動開發(fā)的底層邏輯一句話能說清嗎我用最樸素的話拆解一下。傳統(tǒng)開發(fā)是你對著IDE寫代碼遇到問題去Stack Overflow搜索然后把別人的代碼片段改吧改吧粘進(jìn)來。自然語言驅(qū)動開發(fā)的思路完全反過來你只需要用自然語言把我要做什么、做到什么程度、有什么約束說清楚AI在底層幫你完成拆解需求、寫代碼、甚至跑測試修bug的流程。這套邏輯能跑通靠的是大模型對代碼語義的理解能力足夠強(qiáng)了。以前代碼補全工具只能根據(jù)你上一行猜下一行現(xiàn)在的大模型能看整個項目上下文理解你文件夾里一堆文件之間的關(guān)系然后生成一整套能協(xié)同工作的代碼。關(guān)鍵詞是理解上下文這也是后面所有工具對比的核心分水嶺。能看懂項目上下文的工具寫出來的代碼才是能用的代碼只會盯著當(dāng)前文件發(fā)揮的生成的只是看起來很專業(yè)的垃圾。不過我必須潑一盆冷水vibe coding不是躺著讓AI替你賺錢。它的真實工作流應(yīng)該是你負(fù)責(zé)定義問題、拆解邊界、審查結(jié)果、兜底修錯AI負(fù)責(zé)把那些耗時但固定的臟活累活快速干掉。如果你連代碼的基本語法都看不懂讓AI生成的代碼出了問題你連從哪查起都不知道那這不叫vibe coding這叫開盲盒。1.3 哪種人最適合吃這波紅利我實際用下來有編程基礎(chǔ)想提效的開發(fā)者、需要快速做原型驗證的產(chǎn)品經(jīng)理、以及獨立開發(fā)者是vibe coding最大的受益群體。我剛?cè)胄袔н^的一個前端同事屬于那種能看懂代碼但寫得慢的類型他拿vibe coding工具做頁面切圖效率直接翻倍。原因很簡單寫重復(fù)性的CRUD接口、拼頁面模板、配置構(gòu)建腳本這類活A(yù)I做得比人快得多而真正需要動腦子的架構(gòu)設(shè)計、數(shù)據(jù)結(jié)構(gòu)選型最后還是得人來拍板。完全零基礎(chǔ)的小白能不能玩能但你要做好翻車概率極高的心理準(zhǔn)備。我的建議是零基礎(chǔ)用戶用vibe coding學(xué)編程重點不是讓AI幫你把功能做出來而是盯著AI生成的代碼一行行讀不懂就問它為什么這么寫。這個過程比看教程學(xué)得快因為你是在解決真實問題自然語言驅(qū)動開發(fā)的輸入輸出對你來說就是個教學(xué)循環(huán)。但如果你只是想讓AI幫你把東西做出來然后直接上線那出事了真沒人能幫你兜底。2. 主流vibe coding工具橫評從IDE到Agent方案2.1 工具選型的五個評判維度先列清楚聊具體工具之前我想先把評判標(biāo)準(zhǔn)定下來不然對比就是耍流氓。我拆了五個維度自然語言理解能力它能不能準(zhǔn)確理解你那些含糊的表達(dá)比如你說把按鈕挪到右邊再好看一點它是只動了margin還是順手幫你把布局邏輯重寫了上下文感知能力它是只看著當(dāng)前文件干活還是能看懂整個項目結(jié)構(gòu)、依賴關(guān)系、歷史改動記錄這個直接決定生成代碼的可用度。自主操作權(quán)限是只給你生成代碼讓你自己粘貼還是能直接改文件、跑命令、裝依賴、執(zhí)行測試交互體驗與學(xué)習(xí)成本是在你熟悉的VS Code里開個插件就行還是得換一套IDE重新適應(yīng)快捷鍵費用與限制免費額度有多少付費值不值國內(nèi)用起來穩(wěn)不穩(wěn)2.2 六款主流工具逐一拆解說說我的真實感受Cursor這應(yīng)該是目前公認(rèn)的vibe coding天花板級選手。它本質(zhì)是一個基于VS Code改了底層的獨立IDE所以快捷鍵、插件生態(tài)、主題配置都能無縫繼承遷移成本很低。最核心的是它那個Tab補全和Composer界面你選中一段代碼然后輸入把這個接口改成異步調(diào)用錯誤處理統(tǒng)一用try-catch它不光改你選中的部分還會主動問你其他調(diào)用點要不要同步更新。這種理解意圖并主動關(guān)聯(lián)修改的能力目前其他工具還沒完全追上。我實際在Cursor上跑過一個小的數(shù)據(jù)清洗任務(wù)需求是解析一個CSV文件把日期列標(biāo)準(zhǔn)化去掉重復(fù)項輸出新的CSV就用一句自然語言描述它自動選型了pandas還是csv模塊、寫了測試數(shù)據(jù)驗證邊界情況最后連輸出路徑都給我列好了。全程我只需要點接受和拒絕。不過Cursor也有個問題它把太多能力塞進(jìn)了一個IDE里啟動內(nèi)存占用跑到1.5GB是常事老一點的電腦帶起來吃力。GitHub CopilotCopilot是老牌選手了但它的定位和Cursor不太一樣。Copilot更偏向行級/函數(shù)級補全你在寫代碼的時候它幫你續(xù)寫下一行或下一個函數(shù)。Copilot也有Agent模式和Workspace模式能在pr側(cè)自動提出修改建議但交互方式是你來問、它去改、然后提交MR節(jié)奏比Cursor慢半拍。Copilot最大的優(yōu)勢是與IDE集成度極高無論是VS Code還是Visual Studio甚至JetBrains全家桶插件裝上就能用不會干擾你現(xiàn)有工作流。用Copilot vibe coding的體驗更接近有個高級開發(fā)者在旁邊幫你打字而不是有個外包團(tuán)隊幫你把整個項目做完。英文csgo的操作方式、視覺復(fù)雜度也更高一些。如果你的需求是給已有項目添磚加瓦而不是從零起新項目Copilot特別好用。WindsurfWindsurf是原Codeium團(tuán)隊出的產(chǎn)品它的賣點是Agent式IDE核心是Cascade模塊它真的會主動思考下一步該干什么。你給它一個任務(wù)它會列出執(zhí)行計劃然后開始逐個文件創(chuàng)建、修改變更并且在每個關(guān)鍵步驟停下來跟你確認(rèn)。比如我要做一個帶登錄功能的todolist它會先問你使用哪種存儲方案本地localStorage還是后端數(shù)據(jù)庫。這種互動比Cursor的Composer更結(jié)構(gòu)化能逼著你在動手前把需求想清楚。我的體驗是Windsurf在長鏈路任務(wù)上表現(xiàn)最好比如幫我創(chuàng)建一個完整的前端項目包含表單校驗、請求封裝、頁面路由這種多步驟任務(wù)。它不會跑著跑著就忘了前面干了啥。缺點是有時候計劃列得太細(xì)一個半小時前就能干完的活你得花十幾分鐘在對話流里點確認(rèn)下一步急性子會想砸鍵盤。ClineCline是開源的名字一直在變但本質(zhì)是VS Code里的一個插件主打自主執(zhí)行。它的開放程度非常高可以讓你接入不同的模型API像Claude、通義、DeepSeek都能塞進(jìn)去可定制性極強(qiáng)。它是直接給你操作終端和文件系統(tǒng)的權(quán)限你說幫我在項目里初始化git倉庫并創(chuàng)建README它就真的去跑git init和echo寫文件。這種感覺很爽但也意味著風(fēng)險極高它要是理解錯了需求可能給你改出一堆不該改的東西所以強(qiáng)烈建議配合git使用隨時回滾。Cline對模型的要求也高有時候模型理解能力差了你會看著它在文件里反復(fù)改來改去最后改出一坨屎。這時候你要做好人工干預(yù)的準(zhǔn)備。通義靈碼國內(nèi)選手阿里出品免費額度給得很大方。它在中文自然語言理解上確實有天然優(yōu)勢你說幫我寫個函數(shù)把金額轉(zhuǎn)成中文大寫它能直接給你一個靠譜的實現(xiàn)中文注釋和變量命名完全不用你操心。這點比老外工具舒服不少它們的模型對中文需求的處理經(jīng)常繞圈子。但通義靈碼在自主操作上偏保守它更傾向于給你生成的代碼展示出來然后你自己手動點復(fù)制粘貼不太會直接改你項目里的文件。這在一定程度上降低了風(fēng)險但也拖慢了vibe coding的效率。如果你是剛學(xué)編程想用中文描述需求入門通義靈碼非常友好。Codex CLI這個大家可能相對陌生一點它是命令行下基于agent模式工作的工具依賴OpenAI系模型。它的形態(tài)比較極客你在終端里啟動一個會話把需求用自然語言描述出來它會自主地進(jìn)行代碼編寫、命令執(zhí)行、錯誤修復(fù)的循環(huán)。整個交互都在終端里沒有圖形界面但結(jié)果非常硬核。Codex CLI讓我覺得有趣的點是它真的很適合基礎(chǔ)設(shè)施類任務(wù)比如幫我寫一個Dockerfile來容器化這個Node.js項目、幫我批量壓縮這個目錄下的圖片。這種任務(wù)不需要你盯著IDE給它下個指令就完了。不過它對模型質(zhì)量要求高免費額度基本不夠用而且純命令行交互對新手很不友好。2.3 一句話選型表直接拿去用我把上面六款工具的核心特點匯總成一張表方便你快速對照工具形態(tài)自然語言理解上下文感知自主操作權(quán)限適合場景Cursor獨立IDE強(qiáng)強(qiáng)高全場景從零起項目GitHub CopilotIDE插件中上中中已有項目補全Windsurf獨立IDE強(qiáng)強(qiáng)高多步驟長鏈路任務(wù)ClineVS Code插件中中極高可自定義模型的重活通義靈碼IDE插件中上中文尤其好中低中文需求、新手學(xué)習(xí)Codex CLI命令行強(qiáng)中極高基礎(chǔ)設(shè)施類任務(wù)一個很現(xiàn)實的說法是沒有一個工具能通吃所有場景。你最終大概率是主用一個工具 備選一個工具的組合。我用得最多的是Cursor遇到長鏈路多步任務(wù)我會切到Windsurf處理基礎(chǔ)設(shè)施類腳本直接甩給Codex CLI。3. 實操細(xì)節(jié)用vibe coding工具跑通一個小功能3.1 準(zhǔn)備工作與項目初始化光說不練假把式下面我拿做一個帶熱點的微信公眾號長圖這種非典型開發(fā)需求來說就扯遠(yuǎn)了咱還是落到一個最常見的場景用自然語言從零生成一個帶后端接口的待辦事項管理界面。這個需求足夠小但涵蓋了前端頁面、后端接口、數(shù)據(jù)存儲三個核心部分非常適合走一遍完整流程。實操第一步是選工具。我這邊演示用的主工具是Cursor因為它的獨立IDE環(huán)境對新手最友好你不需要額外配置VS Code插件。安裝好Cursor之后先建一個空文件夾作為項目根目錄然后用Cursor打開這個文件夾。這里有個小細(xì)節(jié)首次啟動時一定要選中Trust the authors否則插件和AI功能會受限體驗直接打?qū)φ?。接下來需要考慮項目腳手架的問題。你可以讓AI幫你決定也可以自己先搭好一個空項目。我的習(xí)慣是讓AI拿到主導(dǎo)權(quán)因為vibe coding的核心思路就是把選擇權(quán)交出去你只負(fù)責(zé)定義邊界。我在Cursor的對話窗口里輸入了這樣一段描述創(chuàng)建一個基于React Node.js Express的全棧項目前端用Vite構(gòu)建后端提供RESTful接口。實現(xiàn)一個待辦事項管理功能數(shù)據(jù)保存在JSON文件中不需要數(shù)據(jù)庫。前端頁面要簡潔美觀支持添加、標(biāo)記完成、刪除待辦事項。這里有個關(guān)鍵點需求描述不要太發(fā)散。你越是給AI一個明確的、封閉的邊界它的輸出越是可控。如果你說幫我做個待辦清單AI會面臨無數(shù)種選擇最后選啥全看運氣但如果你說用React Express JSON文件存儲實現(xiàn)增刪改查它的選擇空間被大幅壓縮生成結(jié)果的可預(yù)測性就高多了。3.2 Prompt怎么寫才靠譜三個原則我總結(jié)好了很多第一次玩vibe coding的人上來就一句話幫我寫個QQ空間然后看著AI生成一個四不像的東西一臉懵。其實問題不在AI而在你的描述方式。我踩了無數(shù)次坑之后總結(jié)出三條實用的prompt原則原則一先給全景再給細(xì)節(jié)。不要一上來就貼一堆代碼讓AI優(yōu)化一下或者改個顏色它沒有你的上下文。正確做法是先告訴它項目是干嘛的、技術(shù)棧是什么、文件結(jié)構(gòu)大概怎么組織然后再讓它具體改造。就像你新入職一家公司先得看項目文檔不能直接上手改生產(chǎn)代碼。原則二把要什么講清楚把不要什么也講清楚。AI在生成代碼的時候經(jīng)常過度發(fā)揮。比如你讓它加個按鈕它順手給你加了一圈動畫效果和一堆沒用的事件監(jiān)聽。這時候你就得在需求里寫明白樣式保持簡潔不要添加多余依賴包。負(fù)面約束和正面需求同等重要這叫劃紅線。原則三技術(shù)棧和關(guān)鍵約束一定要點名。你想用Python寫后端就說清楚用FastAPI而不是Flask你想數(shù)據(jù)存內(nèi)存就說重啟后不用保留數(shù)據(jù)。你點名得越具體AI跑偏的概率越低。這事聽起來像廢話但實際操作中真有太多人忽略了因為大家默認(rèn)AI應(yīng)該懂可它恰恰真的不懂你沒說的東西。3.3 審查與迭代vibe coding的核心從來不是生成而是改對AI把第一版代碼生成出來之后真正考驗?zāi)愕臅r刻到了。我第一次用Cursor生成全棧項目看著屏幕上瞬間多了30多個文件說實話又爽又慌。爽的是效率慌的是我不知道這些代碼能不能真跑起來。我的習(xí)慣是第一件事不是review每一行代碼而是直接啟動項目試試能不能跑通。你讓前端跑起來、后端啟動起來頁面能打開、接口能通再去審視代碼質(zhì)量這是最高效的路徑。如果真的跑不起來報錯信息就是你的第二份prompt。把終端里那一坨報錯信息原樣貼給AI再加上一句幫我分析報錯原因并給出修復(fù)方案它能幫你快速定位。這個方法我稱之為報錯驅(qū)動開發(fā)在vibe coding場景下極其管用。但注意一次只修一個問題。如果你一口氣貼三個報錯AI往往會在修第一個的時候引入更多問題多步調(diào)試變成連環(huán)翻車。等代碼跑通了才是真正的審查環(huán)節(jié)。我審查AI代碼重點關(guān)注三塊有沒有安全隱患比如接口沒做參數(shù)校驗、數(shù)據(jù)庫操作有注入風(fēng)險、業(yè)務(wù)邏輯是否符合描述比如標(biāo)記完成到底改沒改數(shù)據(jù)庫、代碼風(fēng)格是否統(tǒng)一。這三個沒問題這活就算過了。說實話AI寫代碼的質(zhì)量進(jìn)步非常大我審一遍的工作量比兩年前審應(yīng)屆生的代碼還輕松。但我依然堅持每一步都看因為AI的幻覺問題至今還客觀存在它可能一本正經(jīng)地引用一個不存在的函數(shù)。3.4 一個真實案例我讓AI修掉了一個我都不想查的bug有一次我在開發(fā)一個小工具后端有個接口要讀取用戶上傳的Excel文件并解析前端需要展示一個進(jìn)度條。我把需求描述給AI后它很快把代碼生成出來了。跑的時候發(fā)現(xiàn)文件大點就報內(nèi)存溢出前端進(jìn)度條直接卡死在99%。我一開始懷疑是后端解析庫的問題于是把報錯信息貼給AI它看了一眼告訴我問題不在解析邏輯而在接口設(shè)計上它把整個文件都讀進(jìn)內(nèi)存再解析遇到大文件自然就爆炸。正確的做法是流式讀取或者加一個文件大小校驗。它建議我在上傳接口里加一個50MB的大小限制并且用流式解析方式處理。整個修復(fù)過程非常流暢AI自動改了后端代碼、加了前端提示文案甚至幫我在README里補了接口說明。但這里我要說個關(guān)鍵細(xì)節(jié)它能發(fā)現(xiàn)問題是因為我在需求里描述了用戶會上傳Excel文件這個場景它據(jù)此推理出了文件可能很大這個潛在問題。如果你只寫實現(xiàn)Excel解析接口它可能壓根不會考慮體積問題。所以你看還是那句話自然語言驅(qū)動的質(zhì)量上限很大程度取決于你描述的顆粒度。4. 踩坑實錄我用vibe coding翻過的車和總結(jié)的經(jīng)驗4.1 高頻翻車現(xiàn)場你肯定也會遇到用了這么久vibe coding工具我翻車的次數(shù)比很多新手估計還多因為我什么都敢讓它干。下面這幾個坑我打包票你早晚會遇到。第一個坑上下文丟失。你和一個AI會話聊了50輪突然讓它改前面第10輪提到的一個功能它往往失憶。不是真失憶是上下文窗口塞滿了被擠掉了。你讓它在第10輪的代碼基礎(chǔ)上改它會按照最新對話狀態(tài)理解結(jié)果改得牛頭不對馬嘴。應(yīng)對辦法是盡早新建會話給新會話一個完整的項目背景描述讓它重新讀一遍關(guān)鍵代碼。不要試圖在超長對話里延續(xù)記憶不存在的。第二個坑災(zāi)難式的連環(huán)優(yōu)化。你讓AI優(yōu)化某段代碼性能它確實把性能優(yōu)化了但順帶重構(gòu)了整個文件結(jié)構(gòu)導(dǎo)致其他模塊的引用全斷了。這種超范圍改動是vibe coding最危險的行為因為AI的理解里沒有最小化改動這個原則它傾向于給你一個漂亮的完整方案而不是穩(wěn)妥的局部修補。我現(xiàn)在對付它的辦法是在prompt里明確寫只修改指定部分不得改動其他代碼每次這么說翻車率至少降一半。第三個坑AI編造幻覺依賴。它可能在代碼里引用某個根本不存在或版本對不上號的第三方庫然后你去裝依賴的時候就各種報錯。最離譜的一次它給我寫了個用Python的某個冷門庫的爬蟲我按它給的pip命令裝了半天結(jié)果發(fā)現(xiàn)那個庫在官網(wǎng)上壓根不存在是它基于訓(xùn)練數(shù)據(jù)拼出來的記憶錯誤。從那以后我讓AI引入新依賴之前都會要求它明確說明這個庫是干什么的、為什么要用然后我再手動搜一下確認(rèn)多花一分鐘能省兩個小時。4.2 問題排查技法如何讓AI自己打自己vibe coding好用但報錯排查這個環(huán)節(jié)往往比寫代碼更耗時。我摸索出一套讓AI自己打自己的排查方法分享給你們。第一步最小化復(fù)現(xiàn)。當(dāng)系統(tǒng)出bug時不要拿整個項目去問AI哪里出錯了它面對一個大型unknown codebase會無從下手。正確做法是把這個bug限定到最小范圍比如后端這個POST接口返回500請求參數(shù)是{...}相關(guān)代碼是這幾行把上下文范圍縮到最小。就像醫(yī)生看病你不能說我渾身難受你得說我肚子疼而且吃了辣的東西之后更疼。第二步反向描述法。如果你連問題在哪都搞不清楚可以換一種問法我期望這段代碼做X但它實際做了Y為什么這種期望vs實際的對比描述比代碼是不是有問題這種開放式提問有效得多因為AI更擅長做差異分析而不是全量代碼審查。第三步讓AI寫單元測試。這個方法很反直覺但極其好用。當(dāng)你想知道一個函數(shù)是否可靠與其自己蹲在代碼里逐行debug不如讓AI幫你寫幾個邊界情況的單元測試用例跑一下。測試用例寫出來了函數(shù)的問題往往也就暴露了。我在用vibe coding開發(fā)時習(xí)慣每個核心函數(shù)都附帶生成一個簡單測試腳本省了大量的手動排查時間。4.3 避坑清單這些紅線我用真金白銀換來的永遠(yuǎn)在git分支里用vibe coding不要直接在主分支上讓AI改。AI的改動是不可預(yù)測的一個好習(xí)慣是開個feature分支讓它折騰滿意了再合并。生產(chǎn)環(huán)境的部署命令不要授權(quán)給AI自動執(zhí)行。它可以在你的本地項目里亂改但讓它把代碼部署到線上你就賭得太大了。AI生成的配置文件Dockerfile、CI腳本、package.json必須人工確認(rèn)關(guān)鍵版本號。它會給你寫一個看起來很新的版本號但那個版本可能剛發(fā)布三天和你的運行環(huán)境根本不兼容。凡是涉及刪除操作刪文件、刪表、刪數(shù)據(jù)的需求一條條確認(rèn)后再讓它動手。AI的刪和人類的刪往往不是一個概念它可能順手把無關(guān)文件也刪了。5. 場景化決策建議你的下一個項目可以怎么選工具5.1 不同場景的工具搭配方案前面對比了一堆最后落到具體場景給你幾個可以直接抄的方案。場景一快速搭建Web應(yīng)用原型比如你有個創(chuàng)業(yè)想法想做MVP驗證。首選Cursor配上Claude模型把需求描述清楚基本一天內(nèi)能出一個帶前后端和數(shù)據(jù)庫的完整可演示項目。Windsurf的Cascade模式在需求拆解階段特別加分它會逼你想清楚數(shù)據(jù)模型和用戶交互流程。場景二給已有項目添磚加瓦比如維護(hù)一個老舊的Spring Boot項目要加個新接口。首選GitHub Copilot它的行級補全能力強(qiáng)不會像Cursor那樣動不動就給你重構(gòu)整個controller層整體改動面可控得多。Copilot的Workspace功能還能幫你理解陌生codebase的結(jié)構(gòu)這個對接手舊項目來說太重要了。場景三寫腳本和基礎(chǔ)設(shè)施工具比如寫個定時任務(wù)、批量文件處理腳本、搭個Docker容器。直接上Codex CLI或者其他類似命令行agent工具它在終端場景下的自主操作能力是圖形IDE比不了的。你把需求往終端里一甩它自己跑命令自己修正你就等著看結(jié)果。場景四純零基礎(chǔ)學(xué)編程想用中文入門。從通義靈碼或者國內(nèi)其他的大模型輔助編程插件開始更合適它們的中文理解能力明顯更強(qiáng)免費額度也夠?qū)W習(xí)用到年底。學(xué)習(xí)路徑應(yīng)該是讓AI生成代碼、逐行讀代碼、遇到不懂的術(shù)語直接追問AI解釋相當(dāng)于找了個隨叫隨到的私教。5.2 從工具選擇談開去vibe coding的能力邊界在哪最后聊點軟件工具之外的東西。很多人問過我vibe coding會不會讓程序員失業(yè)。我的觀點特別樸素它淘汰的不是程序員而是那些只寫重復(fù)代碼、不思考架構(gòu)和需求的代碼搬運工。vibe coding真正讓你從怎么用代碼實現(xiàn)這個執(zhí)行層解放出來把你推到了更高的決策層你要決定做還是不做、用哪種方案做、做到什么程度算好。這些決策能力恰恰是自然語言本身表達(dá)不出來的。比如你沒法用自然語言告訴AI這里應(yīng)該用事件驅(qū)動架構(gòu)因為未來這個模塊的擴(kuò)展性很重要——你可以說但AI能理解你的業(yè)務(wù)域環(huán)境嗎很難。這種業(yè)務(wù)理解和架構(gòu)權(quán)衡依然是人類的護(hù)城河。另外很重要的一點是審查能力。你玩vibe coding的體驗好壞智商稅交多少完全取決于你的代碼審查能力有多強(qiáng)。你看得懂AI代碼你就是在駕馭它你看不懂你就是在它面前裸奔。所以我強(qiáng)烈建議玩vibe coding的同時不要丟掉手寫代碼的基本功。練手的方式很簡單每個星期選一天不用任何AI輔助純手寫一個小功能模塊。這個習(xí)慣能讓你在AI的海洋里始終保持能上岸的能力。在做這個工具對比項目的過程中我自己最大的收獲不是學(xué)會了用哪些工具而是更清楚地認(rèn)識到了自然語言驅(qū)動開發(fā)的節(jié)奏它會讓把事情做出來變得越來越便宜讓把事情想清楚變得越來越值錢。工具怎么選真的不重要因為下個月還會出新的重要的是你在用這些工具的每一個小時里有沒有比不用工具的時候多往前走了幾步。