1. 從一句模糊的想法到能跑起來的原型到底要跨過哪些坎很多人腦子里都閃過做點東西的念頭可能是一個小工具、一個自動化腳本、一個桌面小應(yīng)用甚至只是一個“要是有個東西能幫我干這件事就好了”的模糊感覺。問題從來不是沒有想法而是想法到能看見、能點、能跑起來的東西之間橫著一條讓人望而生畏的溝。傳統(tǒng)開發(fā)路徑要求你先學語言、再搭環(huán)境、再理解框架、再處理依賴等你好不容易把環(huán)境配好當初那個想法帶來的興奮勁已經(jīng)涼了一半。vibe coding 這個詞最近被聊得很多它描述的其實是一種狀態(tài)你跟著感覺走把注意力放在“我想要什么”上而不是“這個語法該怎么寫”上。工具替你處理掉大量機械性的細節(jié)你負責判斷方向、描述意圖、驗收結(jié)果。從 idea 到 demo 這個階段恰恰是 vibe coding 最能發(fā)揮價值的地方因為 demo 不需要完美不需要考慮并發(fā)量、不需要處理邊界情況、不需要寫測試它只需要證明“這件事能成”。這篇內(nèi)容適合幾類人看。第一類是有想法但沒系統(tǒng)學過編程的人想知道自己能不能借助現(xiàn)在的工具把東西做出來。第二類是有編程基礎(chǔ)但沒怎么接觸過 AI 輔助開發(fā)的人想看看這套流程跟自己習慣的方式有什么不同。第三類是已經(jīng)用過一些工具但總覺得“差點意思”的人想從別人的實操路徑里找到自己卡住的那個環(huán)節(jié)。我會把從 idea 到 demo 的完整過程拆開講清楚每一步在干什么、為什么這么干、容易在哪里翻車以及我實際踩過的坑。需要提前說明的是vibe coding 不是魔法它不會讓你完全不懂任何東西就憑空變出一個產(chǎn)品。它降低的是“實現(xiàn)成本”不是“思考成本”。你仍然需要想清楚自己要什么仍然需要能判斷生成的結(jié)果對不對仍然需要在出問題的時候有排查的思路。但它確實把門檻拉低了一大截讓更多人可以先把東西做出來再決定要不要深入。2. 動手之前先把想法捏成一個能驗收的形態(tài)2.1 為什么不能直接對著工具說“幫我做個好東西”我見過太多人打開 AI 工具輸入一句“幫我做一個記賬軟件”然后對著生成的一堆代碼發(fā)呆不知道從哪看起也不知道對不對。問題出在“記賬軟件”這四個字太寬了。它可以是手機 App可以是網(wǎng)頁可以是命令行工具可以是 Excel 插件。功能上可以只記流水也可以帶預算、帶圖表、帶多賬戶、帶導出。你腦子里的“記賬軟件”和工具理解的“記賬軟件”大概率不是同一個東西。從 idea 到 demo 的第一步不是打開工具而是把想法捏成一個具體的、可驗收的形態(tài)。我習慣用一個很土但很管用的方法用一句話說清楚“誰在什么情況下用它來干什么”。比如“我自己在月底想快速知道這個月錢花在哪了打開一個網(wǎng)頁就能看到按類別分的餅圖”。這句話里包含了用戶我自己、場景月底、動作打開網(wǎng)頁看餅圖、結(jié)果知道錢花在哪。有了這句話后面所有的決策都有了依據(jù)。2.2 把 demo 的邊界畫出來明確不做什么demo 的核心特征是“能跑通一條最小路徑”。很多人做 demo 失敗不是因為做不出來而是因為想做的太多每個功能都做了一半最后沒有一個能完整跑起來。我在動手之前會強制自己列一個“不做清單”把那些“以后再說”的功能明確排除掉。拿剛才的記賬例子來說不做清單可能包括不做用戶注冊登錄、不做多設(shè)備同步、不做數(shù)據(jù)加密、不做移動端適配、不做歷史數(shù)據(jù)導入。這些功能每一個單獨拎出來都能耗掉大量時間而且它們跟“驗證這個想法能不能讓我看清錢花在哪”這個核心目標沒有直接關(guān)系。把它們排除掉demo 的范圍就收縮到“一個網(wǎng)頁能手動輸入幾筆賬能按類別顯示餅圖”。這個收縮過程本身就是一種設(shè)計。你在決定不做什么的時候其實是在確認什么最重要。我自己的經(jīng)驗是一個 demo 如果不能在半天到一天內(nèi)跑通核心路徑那它的范圍就還是太大了需要繼續(xù)砍。2.3 選一個跟自己關(guān)系最近的入口形態(tài)入口形態(tài)指的是用戶從哪里接觸到你做的東西。網(wǎng)頁、桌面應(yīng)用、命令行工具、瀏覽器插件、手機 App這些都是入口形態(tài)。對于 demo 階段來說選擇的標準只有一個哪個形態(tài)離你的使用場景最近同時實現(xiàn)成本最低。網(wǎng)頁的優(yōu)勢是跨平臺、不需要安裝、分享方便缺點是涉及前端后端一堆東西對新手來說概念比較多。桌面應(yīng)用的優(yōu)勢是可以直接操作本地文件、不需要服務(wù)器缺點是打包和分發(fā)麻煩。命令行工具的優(yōu)勢是實現(xiàn)極簡、不需要界面缺點是交互體驗差、不適合展示。瀏覽器插件的優(yōu)勢是能嵌入現(xiàn)有工作流缺點是受限于瀏覽器環(huán)境。我個人的偏好是如果這個東西主要是給自己用、跟本地文件打交道多優(yōu)先考慮桌面應(yīng)用或者命令行如果是要給別人看、要展示優(yōu)先考慮網(wǎng)頁?，F(xiàn)在有一些工具可以讓網(wǎng)頁開發(fā)變得非常簡單甚至不需要自己配服務(wù)器這部分后面會展開講。3. 工具鏈的選擇決定了你是在順風走還是逆風爬3.1 AI 輔助編程工具的實際能力邊界在哪現(xiàn)在市面上能用的 AI 輔助編程工具大致分幾類。一類是集成在編輯器里的補全和對話工具你在寫代碼的時候它給你建議你遇到問題的時候可以問它。一類是獨立的對話式工具你描述需求它給你完整代碼你復制出來自己跑。還有一類是專門針對某個平臺或框架的生成工具比如專門生成網(wǎng)頁的、專門生成小程序的。這些工具的能力邊界其實很清楚它們非常擅長處理“有明確輸入輸出、有大量相似案例、不需要復雜架構(gòu)設(shè)計”的任務(wù)。比如“寫一個函數(shù)輸入一個日期字符串輸出這個日期是星期幾”這種任務(wù)它們幾乎不會出錯。但它們不擅長處理“需要理解業(yè)務(wù)上下文、需要在多個方案之間權(quán)衡、需要跟現(xiàn)有系統(tǒng)集成”的任務(wù)。比如“幫我設(shè)計一個數(shù)據(jù)庫表結(jié)構(gòu)來支持多用戶多角色的權(quán)限系統(tǒng)”這種任務(wù)它們給出的結(jié)果往往需要大量調(diào)整。理解這個邊界很重要因為它決定了你應(yīng)該把什么任務(wù)交給工具、什么任務(wù)自己扛。我的做法是把“怎么寫”交給工具把“寫什么”和“為什么這么寫”留給自己。具體來說我會自己想清楚數(shù)據(jù)長什么樣、頁面有幾個、每個頁面干什么然后讓工具去寫具體的代碼。工具寫出來的代碼我會看但不會逐行摳主要看結(jié)構(gòu)對不對、邏輯有沒有明顯問題。3.2 環(huán)境配置這件事能省則省傳統(tǒng)開發(fā)里環(huán)境配置能占掉新手一半以上的時間。裝語言運行時、配環(huán)境變量、裝包管理器、處理版本沖突每一步都可能卡住。vibe coding 的思路是盡量繞開這些用那些“打開就能用”的工具。如果你做的是網(wǎng)頁類的東西現(xiàn)在有一些在線開發(fā)環(huán)境可以直接在瀏覽器里寫代碼、跑代碼、預覽效果不需要在本地裝任何東西。這類工具的好處是你換一臺電腦、換一個系統(tǒng)打開瀏覽器就能繼續(xù)不存在“在我電腦上能跑”的問題。缺點是依賴網(wǎng)絡(luò)而且免費版通常有資源限制。如果你做的是桌面類的東西可以考慮那些自帶運行時的方案。比如有些工具可以把你的代碼打包成一個獨立的可執(zhí)行文件用戶不需要裝任何依賴就能運行。這類方案在 demo 階段特別省心因為你不需要教別人怎么配環(huán)境。如果你做的是命令行工具那環(huán)境配置反而簡單因為命令行工具通常只依賴語言本身不需要額外的圖形庫或者瀏覽器引擎。Python 和 Node.js 在這類場景下都很合適裝一個運行時就能跑。我自己的習慣是demo 階段能用在線環(huán)境就用在線環(huán)境能不用數(shù)據(jù)庫就不用數(shù)據(jù)庫數(shù)據(jù)先存在本地文件里。等 demo 跑通了、確認要繼續(xù)做了再考慮把東西搬到更正式的環(huán)境里。3.3 版本管理從第一天就要有很多人覺得 demo 階段不需要版本管理代碼就幾十行改壞了重寫就行。這個想法在代碼量小的時候沒問題但一旦你開始讓 AI 幫你改代碼情況就變了。AI 改代碼有時候會改出你意想不到的結(jié)果如果你沒有存之前的版本想退回去都退不了。我的做法是從寫第一行代碼開始就用 Git哪怕只是在本地建一個倉庫不推到任何遠程平臺。每次讓 AI 做一次比較大的改動之前先提交一次。這樣改壞了隨時可以回退成本幾乎為零。Git 的基本操作就幾個命令學起來不超過半小時但它帶來的安全感是巨大的。如果你完全沒用過 Git可以先用最簡單的方式每次改動之前把整個文件夾復制一份改個名字加個日期。這個方法很土但在 demo 階段完全夠用而且零學習成本。等你有精力了再學 Git 也不遲。4. 把想法翻譯成工具能聽懂的話4.1 描述需求的時候要像在給實習生派活跟 AI 工具描述需求最忌諱的是說“你懂的”或者“就那個”。工具不會讀心它只能根據(jù)你給的信息做判斷。你給的信息越具體它給出的結(jié)果越接近你想要的。我總結(jié)了一個描述需求的模板基本上套進去就不會出大問題。模板分四塊第一塊說清楚這個東西是什么、給誰用第二塊說清楚核心流程是什么用戶從進入到完成目標要經(jīng)過哪幾步第三塊說清楚數(shù)據(jù)長什么樣有哪些字段、什么類型第四塊說清楚界面大概長什么樣有幾個區(qū)域、每個區(qū)域放什么。這四塊不需要寫得很正式用大白話寫就行但每塊都要有。舉個例子還是記賬那個東西。我會這么寫這是一個給自己用的網(wǎng)頁記賬工具打開就能看到這個月的支出餅圖。流程是打開頁面看到餅圖和總支出下面有一個輸入框可以記一筆賬輸入金額和類別點添加餅圖和總支出實時更新。數(shù)據(jù)就是每一筆賬有金額和類別兩個字段金額是數(shù)字類別是從吃飯、交通、購物、其他里選一個。界面分上下兩塊上面是餅圖和總支出下面是輸入框和添加按鈕。這段描述不到兩百字但包含了工具需要的所有關(guān)鍵信息。它知道要做網(wǎng)頁、知道要有餅圖、知道數(shù)據(jù)只有兩個字段、知道界面怎么分區(qū)。基于這段描述工具生成的代碼大概率能直接跑起來而且跑起來的樣子跟我想的差不多。4.2 分步走比一步到位靠譜得多很多人喜歡一次性把需求全說完然后期待工具一次性生成完整的東西。這個做法在需求簡單的時候可行但稍微復雜一點就容易翻車。因為工具生成的內(nèi)容越多你越難判斷哪里出了問題而且一旦方向偏了改起來成本很高。我的做法是把整個 demo 拆成幾個可以獨立驗證的小步驟每一步只讓工具做一件事做完之后我跑一下、看一眼確認沒問題再進行下一步。還是記賬那個例子我會拆成這么幾步第一步生成一個靜態(tài)頁面上面有一個寫死的餅圖和一個寫死的總支出先確認頁面能打開、圖表能顯示。第二步加上輸入框和按鈕點擊按鈕能把輸入的內(nèi)容顯示在頁面上先不接圖表。第三步把輸入的數(shù)據(jù)跟圖表連起來輸入一筆賬圖表和總支出跟著變。第四步加上本地存儲刷新頁面數(shù)據(jù)不丟。每一步做完都是一個能跑的東西每一步的改動都不大出了問題很容易定位。這種節(jié)奏感是 vibe coding 里很重要的東西它讓你始終處于“知道自己在哪、知道下一步去哪”的狀態(tài)而不是被一大堆代碼淹沒。4.3 遇到報錯的時候怎么跟工具溝通報錯是必然會遇到的不管工具多聰明。遇到報錯的時候最有效的做法是把報錯信息完整地貼給工具同時說清楚你剛才做了什么操作。不要只說“報錯了”也不要說“你寫的代碼有問題”這些信息對解決問題沒有幫助。我一般的格式是我剛才點了添加按鈕然后頁面變成空白了控制臺里看到這段報錯然后把報錯信息貼上去。如果報錯信息很長我會把最關(guān)鍵的那幾行貼上去通常是包含 Error 或者 Exception 的那幾行。工具看到這些信息通常能很快定位到問題。如果工具改了一次沒改好不要一直讓它改同一個地方。改了兩三次還不行就換個思路要么把相關(guān)代碼貼出來讓它重新寫要么自己看看代碼里有沒有明顯的問題。有時候工具會陷入一個死循環(huán)反復改同一個地方但就是改不對這時候人的判斷就很重要了。5. 一個完整 demo 的實操過程記錄5.1 從空白文件夾到能跑的第一版我拿一個真實做過的小東西來演示整個過程。需求是我想有一個網(wǎng)頁能記錄我每天喝了幾杯水并且用柱狀圖顯示最近七天的喝水情況。這個需求足夠簡單適合用來演示完整流程。第一步是建一個文件夾在里面建一個 index.html 文件。然后我把需求描述寫出來這是一個給自己用的喝水記錄網(wǎng)頁打開能看到最近七天的柱狀圖每天一根柱子高度代表喝了幾杯水。下面有一個按鈕點一下今天的杯數(shù)加一柱狀圖實時更新。數(shù)據(jù)存在瀏覽器本地刷新不丟。界面就上下兩塊上面是柱狀圖下面是按鈕和今天的杯數(shù)。把這段描述和 index.html 的內(nèi)容一起發(fā)給工具讓它生成完整代碼。工具返回了一段 HTML 加 JavaScript 的代碼我直接覆蓋到 index.html 里用瀏覽器打開柱狀圖出來了按鈕也能點點一下柱子長高一點。第一版跑通了整個過程不到十分鐘。這里有個細節(jié)值得說我讓工具把所有的代碼都寫在一個 HTML 文件里包括樣式和腳本。這樣做的好處是文件少、好管理、好分享壞處是代碼多了之后會亂。但在 demo 階段文件少比代碼整潔更重要因為你的目標是快速驗證不是長期維護。5.2 數(shù)據(jù)持久化這一步為什么容易卡住第一版跑通之后我發(fā)現(xiàn)刷新頁面數(shù)據(jù)就沒了。這是因為數(shù)據(jù)只存在內(nèi)存里頁面一刷新就清空了。要解決這個問題需要用瀏覽器的本地存儲功能。我把這個需求告訴工具把數(shù)據(jù)存到 localStorage 里頁面加載的時候先讀出來每次更新的時候?qū)懟厝?。工具改了代碼我刷新頁面測試發(fā)現(xiàn)數(shù)據(jù)確實不丟了。但緊接著出現(xiàn)了一個新問題如果某一天沒有記錄柱狀圖里那一天的柱子是缺失的看起來很奇怪。我希望沒有記錄的天數(shù)顯示為零。這個問題我也交給了工具它改完之后柱狀圖就正常了。這一步卡住的地方通常不是技術(shù)本身而是你一開始沒想到會有這個問題。demo 階段就是這樣你一邊做一邊發(fā)現(xiàn)新的問題然后一個一個解決。關(guān)鍵是要保持每一步的改動都小小到出了問題你能一眼看出來是哪次改動導致的。5.3 讓 demo 看起來不那么像 demo功能跑通之后如果想讓 demo 拿得出手可以花一點時間在視覺上。不需要很復雜改改顏色、調(diào)調(diào)間距、加個標題整體觀感就會好很多。這些改動同樣可以交給工具你只需要說“把背景改成淺灰色柱子改成藍色標題字號大一點”這種具體的描述。我自己的習慣是功能全部跑通之后再統(tǒng)一調(diào)樣式而不是一邊做功能一邊調(diào)樣式。因為功能沒定下來的時候樣式改了也可能要重改浪費精力。等功能穩(wěn)定了一次性把樣式調(diào)到位效率更高。還有一個小技巧如果你不知道怎么配色可以讓工具給你幾個方案你選一個順眼的。工具在這類事情上比人快得多而且給出的方案通常不會太難看。demo 階段不需要追求設(shè)計感干凈、清楚、能用就行。6. 那些沒人告訴你但一定會遇到的問題6.1 工具生成的代碼跑不起來怎么辦這是最常見的問題原因通常有幾類。一類是依賴沒裝工具生成的代碼引用了某個庫但你沒有安裝。這種情況報錯信息里通常會提到找不到某個模塊解決辦法就是按照提示把依賴裝上。另一類是版本不兼容工具用的語法或者 API 跟你本地的版本對不上。這種情況要么升級本地版本要么讓工具改用兼容的寫法。還有一類是工具理解錯了你的需求生成的代碼邏輯就是不對的。這種情況需要你把需求描述得更清楚然后讓它重寫。排查的順序是先看報錯信息報錯信息里通常有線索如果報錯信息看不懂把報錯信息貼給工具讓它解釋如果工具也解釋不清楚就把相關(guān)代碼貼出來讓它重寫。大部分問題都能在這個流程里解決。6.2 改著改著改亂了怎么回退這就是為什么前面強調(diào)要從第一天就用版本管理。如果你用了 Git直接回退到上一個提交就行。如果你用的是復制文件夾的方法把之前的文件夾找出來重新打開就行。如果你什么都沒做那就只能讓工具幫你把代碼改回去但這個過程可能很痛苦因為工具不一定記得之前是什么樣。我自己的做法是每次讓工具做比較大的改動之前先手動提交一次。改動之后如果發(fā)現(xiàn)不對直接回退然后換一種方式重新描述需求。這樣試錯的成本很低不會因為一次改壞就前功盡棄。6.3 demo 做出來了然后呢demo 跑通之后你有幾個選擇。一個是繼續(xù)打磨把它變成一個真正能日常使用的東西。這意味著要處理更多的邊界情況、要考慮數(shù)據(jù)備份、要優(yōu)化性能、要適配不同的設(shè)備。另一個是把它放一邊去做下一個想法。demo 的價值在于驗證驗證完了它的使命就完成了不一定非要繼續(xù)做下去。我個人的經(jīng)驗是如果一個 demo 做出來之后我自己用了超過一周那它就值得繼續(xù)投入。如果做出來之后我自己都懶得打開那說明這個想法本身可能就沒那么吸引我不如把精力放到下一個想法上。這個判斷標準很主觀但很有效因為它直接反映了這個東西對你的真實價值。7. 關(guān)于 vibe coding 的一些個人體會我用了挺長時間這套流程最大的感受是它改變了我對待想法的態(tài)度。以前有一個想法我會先評估“做這個要多久”“值不值得”很多時候評估完就放棄了?，F(xiàn)在我會直接動手做一個最小版本可能一兩個小時就有一個能跑的東西然后根據(jù)實際體驗來決定要不要繼續(xù)。這個轉(zhuǎn)變讓我嘗試了更多東西也放棄了很多東西但整體上浪費的時間反而更少了因為我不再在“想”的階段消耗太多精力。另一個體會是vibe coding 做出來的東西代碼質(zhì)量通常不如手寫的。這很正常因為工具不知道你的長期規(guī)劃它只是根據(jù)當前需求生成代碼。所以如果你確定一個東西要長期維護還是需要在某個階段把代碼整理一遍該拆的拆、該改的改。但這是 demo 之后的事情了demo 階段不用操心這個。還有一個很實際的建議把你做過的每一個 demo 都留下來哪怕代碼很亂、哪怕功能很簡單。它們是你以后做更大東西的素材庫。很多時候你會在新的項目里用到舊項目里的某段代碼、某個思路、某個踩過的坑。這些東西積累下來比任何教程都有價值。