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