Vibe Coding 這個(gè)詞火起來(lái)之后我身邊不少朋友把它理解成“用嘴寫代碼”需求往對(duì)話框里一扔AI 啪一下把代碼甩出來(lái)復(fù)制粘貼收工。我第一次嘗試的時(shí)候也是這么想的結(jié)果前三個(gè)項(xiàng)目里有兩個(gè)在上線之前就崩了。崩的原因不是 AI 不夠聰明而是我自己根本沒(méi)想清楚該怎么和它配合。后來(lái)把大半年時(shí)間花在 Cursor、Claude 這類工具上陸陸續(xù)續(xù)跑通了幾個(gè)實(shí)際項(xiàng)目才慢慢摸到門道Vibe Coding 不是放棄思考而是把思考的焦點(diǎn)從“怎么寫”轉(zhuǎn)移到了“怎么說(shuō)清楚”。這篇文章想聊的是 Vibe Coding 到底怎么用重點(diǎn)放在兩塊工具選擇和實(shí)戰(zhàn)方法。里面會(huì)有工具類型的對(duì)比、一個(gè)完整需求的跑通過(guò)程還會(huì)把我踩過(guò)的坑和排查思路一并放出來(lái)。如果你剛開始用 AI 寫代碼或者已經(jīng)在用但經(jīng)常翻車這篇應(yīng)該能幫上忙。1. Vibe Coding 的本質(zhì)從“寫代碼”變成“寫需求規(guī)格說(shuō)明”1.1 先別急著開聊Vibe Coding 的“Vibe”到底指什么Vibe Coding 是 2025 年流行起來(lái)的概念最早被用來(lái)描述“開發(fā)者用自然語(yǔ)言描述意圖交給大模型生成代碼并即時(shí)反饋”的開發(fā)方式。很多人一聽到“Vibe”就覺(jué)得是隨意、憑感覺(jué)仿佛只要情緒到位代碼自然會(huì)出來(lái)。這個(gè)理解其實(shí)偏了?！癡ibe”在這里指向的是你對(duì)最終產(chǎn)物的一種直覺(jué)和方向感是你在寫 prompt 時(shí)帶出來(lái)的語(yǔ)境和意圖而不是隨意瞎聊。我見過(guò)一個(gè)特別典型的對(duì)比。同一個(gè)需求“做一個(gè)待辦事項(xiàng)網(wǎng)頁(yè)”有人第一句寫的是“給我做一個(gè)待辦事項(xiàng)網(wǎng)頁(yè)”AI 返回的是一坨純 HTML 的靜態(tài)列表沒(méi)有添加功能、沒(méi)有刪除按鈕、刷新之后數(shù)據(jù)全部消失這人立刻得出結(jié)論AI 編程不行。另一個(gè)用戶的描述是“要一個(gè)能添加待辦、勾選完成、刪除、刷新后還能保留數(shù)據(jù)的單頁(yè)應(yīng)用數(shù)據(jù)保存在 localStorage”AI 返回的東西第一天就能用。差距不在模型能力而在需求描述的顆粒度。真正用得好的人并不是在那里零散對(duì)話而是把需求說(shuō)得越來(lái)越像一份需求規(guī)格說(shuō)明書輸入是什么、輸出是什么、邊界條件是什么、用什么技術(shù)棧、要不要兼容舊數(shù)據(jù)。這些信息越完整模型生成的代碼越接近可用狀態(tài)。我覺(jué)得 Vibe Coding 的本質(zhì)是編程抽象層級(jí)的一次上移以前我們面對(duì)的是函數(shù)、類、模塊、接口現(xiàn)在面對(duì)的是意圖、約束、驗(yàn)收標(biāo)準(zhǔn)。寫代碼的手藝并沒(méi)有消失只是變成了“提出高質(zhì)量問(wèn)題并驗(yàn)證答案”的能力。1.2 為什么 Vibe Coding 能成立上下文、工具鏈和反饋閉環(huán)其實(shí) AI 編程助手不是這一兩年才出現(xiàn)的。早年的代碼補(bǔ)全工具最多只能幫你猜下一個(gè) token本質(zhì)上是高級(jí)版的自動(dòng)完成。Vibe Coding 能流行起來(lái)靠的是三個(gè)變化疊在一起。第一個(gè)變化是上下文窗口。模型能處理的內(nèi)容從幾千 token 一路漲到十幾萬(wàn)甚至更多這意味著一個(gè)完整項(xiàng)目的核心文件可以被塞進(jìn)對(duì)話里AI 不再是“盲人摸象”而是能看到項(xiàng)目全貌再動(dòng)手。第二個(gè)變化是工具鏈打通。現(xiàn)在的 AI 編程工具能直接讀寫文件、執(zhí)行終端命令、查看報(bào)錯(cuò)日志甚至操作瀏覽器Coding Agent 可以自己列任務(wù)清單、逐個(gè)執(zhí)行、根據(jù)反饋修正。第三個(gè)變化是交互方式。從單輪問(wèn)答變成了多輪協(xié)作AI 可以基于上一次的運(yùn)行結(jié)果自我修正形成“我說(shuō)需求、它寫代碼、我跑、它改”的閉環(huán)。這三個(gè)變化合在一起才讓 Vibe Coding 真正成立。我一直覺(jué)得可以用“結(jié)對(duì)程序員”而不是“搜索引擎”來(lái)理解它。搜索引擎需要你精確知道問(wèn)題是什么才搜得到答案結(jié)對(duì)程序員則是你給它一個(gè)大方向它能跟你一起把一個(gè)東西從零壘起來(lái)。AI 到這里已經(jīng)具備連續(xù)工作的能力但它是不是靠譜很大程度取決于你怎么指揮。1.3 Vibe Coding 的邊界它能做什么不能做什么再?gòu)?qiáng)的工具也有邊界。我用下來(lái)總結(jié)出三條比較清晰的經(jīng)驗(yàn)。第一它擅長(zhǎng)模塊化的功能實(shí)現(xiàn)。寫腳本、寫接口、做 CRUD、寫單元測(cè)試、改樣式、批量處理數(shù)據(jù)這些任務(wù)在開源代碼里出現(xiàn)過(guò)太多次AI 見過(guò)大量相似樣本完成度非常高。第二它不擅長(zhǎng)從頭設(shè)計(jì)復(fù)雜系統(tǒng)架構(gòu)。如果你連模塊邊界、數(shù)據(jù)結(jié)構(gòu)、核心流程都想不清楚AI 生成的所謂“架構(gòu)”大概率看起來(lái)很專業(yè)實(shí)際一跑就露餡。它會(huì)把幾個(gè)常見架構(gòu)模式拼在一起表面完整內(nèi)里卻缺少真實(shí)的業(yè)務(wù)邏輯支撐。第三它會(huì)在冷門領(lǐng)域里一本正經(jīng)地編造。比如編一個(gè)并不存在的庫(kù)函數(shù)或者把兩個(gè)版本混亂的 API 縫在一起。尤其是那些訓(xùn)練數(shù)據(jù)里出現(xiàn)頻率很低的框架、內(nèi)部系統(tǒng)、舊版本庫(kù)AI 經(jīng)常會(huì)用“仿佛合理”的代碼填補(bǔ)它的知識(shí)空白。所以我的結(jié)論是Vibe Coding 的正確使用姿勢(shì)不是把思考外包而是把它當(dāng)成一個(gè)執(zhí)行能力很強(qiáng)但偶爾會(huì)“自由發(fā)揮”的實(shí)習(xí)生。你負(fù)責(zé)拆解方向、定義驗(yàn)收標(biāo)準(zhǔn)、控制質(zhì)量哪怕代碼是 AI 寫的最終責(zé)任還是你的。先把這層認(rèn)知立起來(lái)后面所有方法才有意義。2. 工具選型先想清楚項(xiàng)目場(chǎng)景再選模型和殼子2.1 當(dāng)下主流的 Vibe Coding 工具其實(shí)只分三類市面上工具五花八門但歸納起來(lái)只有三類。第一類是通用對(duì)話式 AI典型代表有 ChatGPT、Claude、Gemini 這類。它們勝在知識(shí)面廣適合問(wèn)思路、生成一段獨(dú)立代碼、做代碼解釋。但它的工作模式是生成一段代碼你自己復(fù)制粘貼到本地它看不到你的報(bào)錯(cuò)也讀不了你項(xiàng)目里其它文件遇到問(wèn)題重新描述一遍成本很高。第二類是 IDE 內(nèi)嵌助手代表是 GitHub Copilot、Cursor 的內(nèi)置聊天、JetBrains AI Assistant。它們長(zhǎng)在編輯器里能讀取當(dāng)前打開的文件、項(xiàng)目結(jié)構(gòu)和運(yùn)行報(bào)錯(cuò)體驗(yàn)比“復(fù)制粘貼”前進(jìn)了一大步。這種工具適合在已有項(xiàng)目里加功能、修 bug因?yàn)槟悴挥冒颜麄€(gè)項(xiàng)目背景都描述給 AI它自己看得到。第三類是自主 Agent 工具比如 Cursor 的 Agent 模式、Claude Code以及一些開源方案。它們能自己列任務(wù)清單、讀取文件、執(zhí)行命令、循環(huán)修復(fù)報(bào)錯(cuò)是目前最能體現(xiàn) Vibe Coding 閉環(huán)體驗(yàn)的一檔。我給新人的建議是不要一上來(lái)就選第三類。自動(dòng)化程度越高翻車之后排查越難。你還沒(méi)搞清楚“需求怎么描述”的時(shí)候就讓它自己跑出問(wèn)題你連問(wèn)題出在哪一步都看不見。另外提一句資源上的補(bǔ)充Google 最近放出了一套面向零基礎(chǔ)的 Vibe Coding 學(xué)習(xí)資源從搭建網(wǎng)頁(yè)到做小工具都有循序漸進(jìn)的項(xiàng)目式課程。我翻過(guò)一遍里面最值得學(xué)的是它把“需求拆解、prompt 編寫、代碼驗(yàn)證”這條鏈路講得很細(xì)零基礎(chǔ)用戶照著做基本就能跑通比自己在各種零散帖子里找教程要系統(tǒng)得多。2.2 用一張表做選型對(duì)比這里給一張按實(shí)際使用場(chǎng)景劃分的選型參考表不一定絕對(duì)但能幫你快速定位場(chǎng)景推薦工具類型理由快速寫一個(gè)獨(dú)立腳本通用對(duì)話式 AI上下文集中拿到代碼直接跑改造成本低在現(xiàn)有項(xiàng)目里加功能、改 bugIDE 內(nèi)嵌助手能感知當(dāng)前文件和相關(guān)代碼修改更準(zhǔn)確新項(xiàng)目整體搭建、多文件重構(gòu)Agent 類工具可以批量建文件、運(yùn)行命令、自動(dòng)修復(fù)錯(cuò)誤日常學(xué)習(xí)、代碼解釋任意類型關(guān)鍵是讓 AI 邊解釋邊寫例子別只給結(jié)論對(duì)穩(wěn)定性要求高的生產(chǎn)代碼多工具交叉 人工 review別讓同一個(gè)模型一條道走到黑容易犯集體錯(cuò)誤這張表的核心邏輯是工具沒(méi)有絕對(duì)好壞只有適合不適合。你要先判斷當(dāng)前任務(wù)的復(fù)雜度再?zèng)Q定用哪種形態(tài)。2.3 選型中的三個(gè)爭(zhēng)議點(diǎn)我說(shuō)說(shuō)個(gè)人看法很多人會(huì)糾結(jié)一些看起來(lái)很重要的問(wèn)題我用實(shí)際體驗(yàn)聊聊自己的結(jié)論。第一個(gè)爭(zhēng)議是“到底該選最強(qiáng)模型還是選順手工具”。長(zhǎng)期用下來(lái)我的答案是一半一半。模型的推理能力決定代碼質(zhì)量上限但工具的工作流決定你能不能用得下去。哪怕模型稍微弱一點(diǎn)只要它能讀取上下文、快速跑起來(lái)、容易回滾實(shí)際產(chǎn)出往往高于一個(gè)“對(duì)話很強(qiáng)但每輪都在復(fù)制粘貼”的方案。我見過(guò)太多人訂閱了最強(qiáng)模型最后因?yàn)閬?lái)回倒騰太麻煩又回到了 IDE 里。第二個(gè)爭(zhēng)議是“本地模型還是云端模型”。本地模型在隱私性和離線場(chǎng)景確實(shí)有優(yōu)勢(shì)但如果你只是做普通項(xiàng)目云端模型的能力領(lǐng)先太明顯沒(méi)必要為了所謂的“隱私潔癖”犧牲大部分體驗(yàn)。當(dāng)然前提是在自己可用且合規(guī)的使用范圍內(nèi)。第三個(gè)爭(zhēng)議偏實(shí)戰(zhàn)選 Agent 工具時(shí)不要只看它幫你寫了多少代碼要看它幫你省了多少重復(fù)勞動(dòng)。好的 Agent 應(yīng)該是“代碼改了測(cè)試跑了只把關(guān)鍵決策報(bào)給你”。如果兩個(gè) Agent 工具在你手上用起來(lái)感覺(jué)都差不多大概率是你的需求還沒(méi)定義清楚工具好壞根本體現(xiàn)不出來(lái)。2.4 環(huán)境準(zhǔn)備里最容易忽略的四個(gè)細(xì)節(jié)工具選好了環(huán)境沒(méi)鋪好照樣跑不起來(lái)。我第一次用 Cursor 的時(shí)候AI 生成的代碼一直報(bào)錯(cuò)排查半天發(fā)現(xiàn)是本地 Python 版本和依賴環(huán)境的問(wèn)題跟 AI 一點(diǎn)關(guān)系都沒(méi)有。這個(gè)經(jīng)歷讓我養(yǎng)成了四個(gè)習(xí)慣把項(xiàng)目需要的解釋器、包管理器、Node 版本這些基礎(chǔ)工具提前安裝好并且清楚知道怎么用命令行運(yùn)行一個(gè)腳本。每個(gè)項(xiàng)目盡量用虛擬環(huán)境或依賴鎖文件避免系統(tǒng)級(jí)依賴污染。AI 生成的 requirements.txt 不代表可以無(wú)腦安裝經(jīng)常需要人工整理。API Key 和各類憑據(jù)不要直接寫在代碼里更不要在 prompt 里把密鑰發(fā)給模型否則你的密鑰可能被下次會(huì)話記住。如果項(xiàng)目要調(diào)用外部服務(wù)先確認(rèn)服務(wù)可用性再讓 AI 寫接口代碼否則所有報(bào)錯(cuò)都會(huì)指向“AI 寫錯(cuò)了”這個(gè)假象。這些細(xì)節(jié)看著基礎(chǔ)但 Vibe Coding 的坑很多時(shí)候不在代碼本身而在代碼背后的運(yùn)行環(huán)境。3. 實(shí)戰(zhàn)把一個(gè)模糊需求變成能跑的程序3.1 實(shí)戰(zhàn)目標(biāo)一個(gè)批量重命名工具說(shuō)再多理論不如完整跑一個(gè)需求。選一個(gè)很容易復(fù)制的場(chǎng)景我有一堆文件命名混亂需要按拍攝日期批量重命名并處理重名、跳過(guò)非圖片、可預(yù)覽、可回滾。如果直接和 AI 說(shuō)“幫我把圖片按日期重命名”它大概率只會(huì)處理最簡(jiǎn)單的情況一遇到重名就覆蓋。這恰恰是 Vibe Coding 里“Vibe”和“靠譜”之間最大的差距AI 不知道你的隱藏約束你得自己把約束說(shuō)清楚。我通常會(huì)先寫這樣一段需求描述我需要一個(gè) Python 腳本批量重命名一個(gè)文件夾里的圖片文件。 輸入文件夾路徑。 處理規(guī)則只處理 jpg、jpeg、png、heic 這幾種擴(kuò)展名從 EXIF 中讀取拍攝時(shí)間如果沒(méi)有 EXIF按文件修改時(shí)間目標(biāo)名格式為 YYYY-MM-DD_HHMM_序號(hào).jpg如果目標(biāo)名已存在自動(dòng)加序號(hào)不能覆蓋原文件運(yùn)行前先輸出將要執(zhí)行的操作清單讓我確認(rèn)后再執(zhí)行取消操作時(shí)不留下任何改動(dòng)。 請(qǐng)用 Python 實(shí)現(xiàn)并告訴我用哪個(gè)依賴庫(kù)。注意這里面的關(guān)鍵信息輸入是什么、處理規(guī)則是什么、邊界條件是什么、異常情況怎么處理、運(yùn)行時(shí)要給用戶什么反饋。這些信息每多一條AI 生成結(jié)果的可用性就上一個(gè)臺(tái)階。3.2 AI 生成結(jié)果后的“雕塑”過(guò)程AI 通常會(huì)先給出一個(gè)方案比如用 os、PIL、exifread 讀取 EXIF再寫主邏輯。第一版代碼大概率能處理 80% 的情況。但我拿到代碼后不會(huì)直接跑而是先做三件事。第一件事是“跑前審查”?？从袥](méi)有明顯的路徑拼接錯(cuò)誤、有沒(méi)有處理 None 值、有沒(méi)有覆蓋風(fēng)險(xiǎn)。這些是 AI 最愛(ài)犯的邏輯失誤不值得讓它在運(yùn)行時(shí)炸出來(lái)。第二件事是“小范圍試跑”。在只有 5 張圖片的臨時(shí)文件夾里執(zhí)行腳本確認(rèn)輸出符合預(yù)期。如果結(jié)果不對(duì)可以快速調(diào)整不用在 5000 張圖片上燒時(shí)間。第三件事是“邊界注入”。自己構(gòu)造幾個(gè)特殊情況讓腳本去撞比如文件名叫“123.jpg”、EXIF 為空、帶中文名、文件夾里還混著 .txt 文件。實(shí)際跑的過(guò)程中立刻會(huì)遇到幾個(gè)真實(shí)坑。比如 HEIC 格式的文件在 macOS 和 iOS 上很常見但很多 Python 庫(kù)默認(rèn)不讀取 HEIC 的 EXIF必須在依賴?yán)镱~外加 pillow-heif。又比如某些系統(tǒng)下中文文件名會(huì)亂碼需要顯式用 os.listdir 枚舉文件而不是依賴路徑字符串拼接。這些經(jīng)驗(yàn)如果不是親手跑一遍AI 幾乎不可能提前幫你考慮到。3.3 讓 AI 持續(xù)“進(jìn)化”的上下文管理技巧很多人和 AI 協(xié)作時(shí)最常遇到的問(wèn)題就是“改了三輪之后AI 把第一版的好功能改丟了”或者“越改越亂”。問(wèn)題通常出在上下文管理上。我常用的方法有幾個(gè)。第一把需求寫成一個(gè)“規(guī)格說(shuō)明”段落放在對(duì)話最前面每次要求修改時(shí)都強(qiáng)調(diào)“請(qǐng)沿用之前的整體需求不要改變 XX 規(guī)則”。第二當(dāng)某次修改引入回歸時(shí)不要只說(shuō)“把剛才那個(gè)功能加回來(lái)”而是明確寫“請(qǐng)加回 XX 規(guī)則這是我之前需求里的第 4 條不要破壞它”。第三超過(guò) 8 到 10 輪修改后如果發(fā)現(xiàn) AI 經(jīng)常遺忘或混淆就新建一個(gè)對(duì)話把規(guī)格說(shuō)明、最新代碼、當(dāng)前報(bào)錯(cuò)一起粘進(jìn)去重新開始。“重開對(duì)話”這個(gè)操作幾乎每一次都能讓質(zhì)量明顯回升。原因不復(fù)雜長(zhǎng)對(duì)話對(duì)上下文窗口是一種消耗模型記不住之前的所有細(xì)節(jié)這時(shí)候繼續(xù)在原對(duì)話里打轉(zhuǎn)更像是在和模型的記憶缺陷較勁。3.4 從腳本到小工具加命令行參數(shù)和錯(cuò)誤處理腳本跑通之后很多人就停了。但我會(huì)讓 AI 多走一步工程化收尾把輸入文件夾路徑改成命令行參數(shù)默認(rèn)值取當(dāng)前目錄加 --dry-run 參數(shù)預(yù)覽但不執(zhí)行加 --log 參數(shù)把每次改動(dòng)記錄到日志文件把主要函數(shù)抽出來(lái)加上類型標(biāo)注。這一步看起來(lái)是加代碼其實(shí)是在把“一次性腳本”變成“可以反復(fù)使用的工具”。方式很簡(jiǎn)單直接在 prompt 里追加“請(qǐng)把腳本改造成支持命令行參數(shù)的方式保持已有邏輯不變?cè)黾?--dry-run 和 --log 選項(xiàng)并添加清晰的錯(cuò)誤提示?！盇I 對(duì)這種結(jié)構(gòu)化改造的處理能力相當(dāng)強(qiáng)但前提是你已經(jīng)給它一個(gè)穩(wěn)定運(yùn)行的基礎(chǔ)版本讓它在平面上加結(jié)構(gòu)而不是在沙子上重新畫圖。這個(gè)順序一旦搞反后面所有修改都會(huì)變成災(zāi)難。4. 最容易翻車的地方以及我的排查鏈路4.1 四類高頻翻車現(xiàn)場(chǎng)用 Vibe Coding 半年多我發(fā)現(xiàn)翻車不是偶發(fā)事件而是有規(guī)律的高頻現(xiàn)象。第一類是“不存在或誤配的 API”。AI 會(huì)基于訓(xùn)練數(shù)據(jù)“覺(jué)得”某個(gè)庫(kù)應(yīng)該有某個(gè)方法但實(shí)際版本里根本沒(méi)有或者方法簽名完全不同。第二類是“依賴地獄”。AI 生成的 requirements.txt 經(jīng)常把不相容的版本寫在一起四個(gè)庫(kù)都需要某個(gè)核心包結(jié)果四個(gè)都要不同版本一安裝就沖突。第三類是“對(duì)話失控”。連續(xù)改十輪之后AI 開始重復(fù)造輪子把原來(lái)正確的部分也改錯(cuò)了整個(gè)項(xiàng)目狀態(tài)變得混亂。第四類是“過(guò)度工程”。一個(gè)十幾行的腳本AI 會(huì)給你生成帶抽象類、配置文件的迷你框架看著專業(yè)實(shí)則是負(fù)擔(dān)。這四類翻車各有特點(diǎn)但有一個(gè)共同點(diǎn)問(wèn)題都不是 AI 單方面造成的而是人沒(méi)有在過(guò)程中設(shè)置檢查點(diǎn)。4.2 一次典型報(bào)錯(cuò)的完整排查鏈路拿我實(shí)際遇到的“PDF 合并工具”舉例。需求是“把多個(gè) PDF 按指定順序合并成一個(gè)”這是一個(gè)非常經(jīng)典的需求。AI 很快給了我代碼用的是 PyPDF2第一版運(yùn)行很正常。但在我換一個(gè)環(huán)境跑時(shí)直接報(bào)錯(cuò)AttributeError: PdfMerger object has no attribute append。我當(dāng)時(shí)的第一反應(yīng)也是“AI 寫錯(cuò)了”但冷靜下來(lái)后我按下面這條鏈路一步步排查第一步把完整報(bào)錯(cuò)文本原樣貼回給 AI而不是只說(shuō)“報(bào)錯(cuò)了”。完整堆棧會(huì)讓 AI 看到具體調(diào)用鏈通常能直接定位到問(wèn)題函數(shù)。第二步讓 AI 告訴我“這段代碼運(yùn)行時(shí)需要的環(huán)境版本”拿它提供的信息去對(duì)比本機(jī)實(shí)際安裝的版本果然發(fā)現(xiàn) PyPDF2 版本不一致。老版本用 PdfFileMerger新版本改成了 PdfWriter.appendAPI 不兼容。第三步在隔離的虛擬環(huán)境里重新創(chuàng)建項(xiàng)目用 AI 提供的依賴列表安裝后再次運(yùn)行確認(rèn)報(bào)錯(cuò)是否復(fù)現(xiàn)。第四步讓 AI 給我一個(gè) 5 行以內(nèi)的最小復(fù)現(xiàn)腳本只測(cè)試那一個(gè)失敗的方法避免大段代碼干擾判斷。第五步定位到根因后讓 AI 改為兼容兩個(gè)版本寫法的代碼并增加版本判斷邏輯。這條鏈路其實(shí)和傳統(tǒng)開發(fā)里“二分定位、隔離變量”的思路完全一致。AI 在這里扮演的是“熟悉 API 的工具人”真正處理問(wèn)題的邏輯還是得你自己來(lái)定。4.3 什么時(shí)候不該繼續(xù)對(duì)話而應(yīng)該“重開”在第一節(jié)提過(guò)“重開對(duì)話”的價(jià)值這里再展開講一個(gè)判斷標(biāo)準(zhǔn)。如果連續(xù)修了三個(gè) bug每個(gè)修完都冒出一個(gè)新的AI 開始重復(fù)詢問(wèn)同樣的問(wèn)題或者它開始用“把整個(gè)文件重寫一遍”來(lái)回應(yīng)一個(gè)小改動(dòng)這時(shí)候繼續(xù)讓它改下去基本是在原地打轉(zhuǎn)。我的做法是停下來(lái)把當(dāng)前狀態(tài)整理成一份“交接文檔”包含需求規(guī)格、當(dāng)前代碼、已解決的問(wèn)題、當(dāng)前報(bào)錯(cuò)、自己已經(jīng)嘗試過(guò)的方向然后新建對(duì)話把這份文檔粘給 AI讓它基于新上下文重新給方案。實(shí)測(cè)下來(lái)重開對(duì)話后解決問(wèn)題的概率通常比在原對(duì)話里糾纏要高得多。這不是玄學(xué)而是長(zhǎng)對(duì)話對(duì)上下文窗口是一種消耗模型記不住也不一定有錯(cuò)維護(hù)上下文本來(lái)就是人該做的事。5. 讓 Vibe Coding 真正可靠的幾個(gè)習(xí)慣5.1 把“驗(yàn)收標(biāo)準(zhǔn)”寫在需求最前面一個(gè)高效的 Vibe Coding 工作流第一步不是“幫我寫一個(gè) XX”而是“我要一個(gè) XX成功條件是第一……第二……第三……”。驗(yàn)收標(biāo)準(zhǔn)寫清楚了AI 在生成和自檢的時(shí)候才會(huì)有方向。這一點(diǎn)經(jīng)常被忽略但它可能是我覺(jué)得性價(jià)比最高的一個(gè)提升手段。你花十秒鐘列幾條驗(yàn)收標(biāo)準(zhǔn)省下的可能是幾個(gè)小時(shí)的來(lái)回修改。5.2 小步提交讓 AI 只做“一個(gè)原子修改”項(xiàng)目變大之后我會(huì)特別注意每次 prompt 的顆粒度。不要一次要求 AI 完成“重構(gòu) 加新功能 修 bug”三件事把它拆成三個(gè)獨(dú)立請(qǐng)求。每完成一個(gè)本地跑一次測(cè)試再進(jìn)下一個(gè)。這樣做的好處是萬(wàn)一出錯(cuò)你清楚知道是哪一步引入的。這和 git 的小步提交理念完全一樣只不過(guò)從代碼層面升級(jí)到了需求層面。5.3 讓 AI 自己生成測(cè)試而不是只生成實(shí)現(xiàn)我發(fā)現(xiàn)一個(gè)特別簡(jiǎn)單有效的習(xí)慣每次讓 AI 寫功能代碼時(shí)同時(shí)加一句“為這個(gè)功能寫一組測(cè)試用例包含正常情況和異常情況”。AI 在生成測(cè)試的時(shí)候其實(shí)會(huì)主動(dòng)反思實(shí)現(xiàn)里的邊界很多 bug 在這一步就會(huì)被提前暴露。這也等于給后續(xù)修改留了一張安全網(wǎng)。后續(xù)讓 AI 改功能時(shí)可以明確要求“改完以后跑一遍測(cè)試確認(rèn)沒(méi)有破壞原有行為”。5.4 要求代碼有注釋、有類型標(biāo)注、有日志AI 生成的代碼往往“能用但很難維護(hù)”。讓 AI 產(chǎn)出帶注釋、類型標(biāo)注和日志的代碼看起來(lái)只是格式要求實(shí)際上能顯著提升后續(xù)協(xié)作效率。因?yàn)槟忝扛魞扇熳?AI 改一次代碼它自己都要重新讀一遍。注釋越清楚它自己的理解也越準(zhǔn)確。這是一種“現(xiàn)在省事、以后也省事”的雙贏選擇。5.5 定期做 Code Review把 AI 當(dāng)成結(jié)對(duì)搭檔我最后的習(xí)慣是不管 AI 寫的代碼多漂亮每過(guò)一周我會(huì)挑一個(gè)模塊做 code review重點(diǎn)看異常處理是否合理、有沒(méi)有隱藏的副作用、有沒(méi)有不必要的復(fù)雜設(shè)計(jì)。我的經(jīng)驗(yàn)是AI 生成的代碼在正常路徑上通常很順但在異常路徑上有時(shí)表現(xiàn)得很隨意。review 不是為了否定 AI而是守住“最終責(zé)任在自己”這條底線。把 AI 當(dāng)成一個(gè)高效但偶爾固執(zhí)的結(jié)對(duì)搭檔你負(fù)責(zé)方向它負(fù)責(zé)執(zhí)行這個(gè)協(xié)作關(guān)系才能穩(wěn)定長(zhǎng)期跑下去。最后再說(shuō)一個(gè)我一直在用的擴(kuò)展玩法建一個(gè)自己的工作臺(tái)文件夾把常用的項(xiàng)目規(guī)格模板、prompt 模板、已完成項(xiàng)目的復(fù)盤放進(jìn)去每次新需求就從模板開始。Vibe Coding 不是讓人變成甩手掌柜而是把大量重復(fù)的編碼工作交給 AI讓自己騰出精力去思考更值得想的問(wèn)題。我個(gè)人最近最大的感受是AI 代碼能力還在快速變化今天的最優(yōu)工具可能三個(gè)月后就過(guò)時(shí)了真正可以長(zhǎng)期積累的是“把需求說(shuō)清楚”和“用工程方法驗(yàn)證產(chǎn)出”這兩項(xiàng)能力。如果你也剛開始嘗試別追求一次性寫出完美程序先讓 AI 幫你跑通一個(gè)最小的模塊然后認(rèn)真做一輪驗(yàn)證你會(huì)慢慢找到那種人機(jī)配合的感覺(jué)。