最近好幾個(gè)朋友來(lái)找我聊vibe coding聊到最后都會(huì)冒出同一個(gè)問(wèn)題AI寫(xiě)代碼確實(shí)快但為什么項(xiàng)目越寫(xiě)越亂甚至到了自己都不敢改代碼的地步如果你也有這種感受那這篇內(nèi)容大概率對(duì)你有用。我過(guò)去半年一直在折騰vibe coding的各種玩法把AI當(dāng)作結(jié)對(duì)編程搭檔也踩了不少坑后來(lái)逐漸把重心轉(zhuǎn)向spec-driven的方案也就是“先寫(xiě)規(guī)格再讓AI照著實(shí)現(xiàn)”。這篇文章會(huì)把vibe coding的典型痛點(diǎn)、spec-driven的核心思路、完整實(shí)操流程以及我記錄下的問(wèn)題排查經(jīng)驗(yàn)一次性講清楚適合正在用AI輔助開(kāi)發(fā)、又苦于代碼失控的開(kāi)發(fā)者參考。1. 先搞清楚vibe coding到底哪里讓人又愛(ài)又恨1.1 vibe coding的真實(shí)體驗(yàn)爽是爽翻車(chē)也是真的快所謂的vibe coding簡(jiǎn)單說(shuō)就是讓AI進(jìn)入高比例自主生成代碼的狀態(tài)開(kāi)發(fā)者更多負(fù)責(zé)描述想法、審查結(jié)果、修正方向而不是逐行手寫(xiě)邏輯。你給一句“幫我寫(xiě)個(gè)讀取溫濕度傳感器的驅(qū)動(dòng)”AI能立刻給你吐出一套完整實(shí)現(xiàn)包括寄存器配置、數(shù)據(jù)解析、錯(cuò)誤重試機(jī)制乍一看還挺像模像樣。我最初用的時(shí)候確實(shí)是爽尤其是做嵌入式原型驗(yàn)證原來(lái)寫(xiě)一個(gè)外設(shè)驅(qū)動(dòng)至少要半天現(xiàn)在十分鐘就能跑起來(lái)樂(lè)高一樣的拼接體驗(yàn)讓人上癮。但問(wèn)題也隨之而來(lái)AI生成代碼的“舒適區(qū)”是模式化邏輯一旦項(xiàng)目涉及復(fù)雜狀態(tài)機(jī)、并發(fā)控制、硬件時(shí)序約束它就開(kāi)始出現(xiàn)各種想當(dāng)然的假設(shè)而這些假設(shè)往往是事后才暴露的因?yàn)樵趯?xiě)代碼的那一刻你根本不會(huì)去逐行校驗(yàn)它到底為什么這么寫(xiě)。我統(tǒng)計(jì)過(guò)自己一個(gè)月的實(shí)際工作流用vibe coding寫(xiě)的代碼里大概有三分之一的時(shí)間花在了“修AI生成代碼產(chǎn)生的邊界問(wèn)題”上而不是在推進(jìn)功能本身?！翱臁弊兂闪隋e(cuò)覺(jué)因?yàn)槟阍诒鎰e哪些代碼是能用的、哪些是幻覺(jué)出來(lái)的反而消耗了大量精力。1.2 痛點(diǎn)的本質(zhì)代碼有“感覺(jué)”產(chǎn)品沒(méi)“共識(shí)”再往深一層看vibe coding最大的問(wèn)題其實(shí)是缺少一個(gè)穩(wěn)定的約束錨點(diǎn)。普通開(kāi)發(fā)流程里需求文檔、接口定義、驗(yàn)收標(biāo)準(zhǔn)這些產(chǎn)物天然就是約束你按著文檔寫(xiě)代碼再怎么跑偏也能拉回來(lái)。但vibe coding里對(duì)話記錄和AI的記憶就是全部的上下文而它們都是會(huì)漂移的。你今天下午和AI說(shuō)“這個(gè)字段表示毫秒”隔兩天再開(kāi)話題它可能就默認(rèn)是秒了這種上下文丟失幾乎每隔幾次迭代就要出現(xiàn)一次。更麻煩的是多人協(xié)作的時(shí)候“感覺(jué)”是無(wú)法同步的。你用vibe coding寫(xiě)了一個(gè)模塊同事拿到代碼根本不知道原始需求是什么AI當(dāng)初為什么選這個(gè)方案、什么邊界條件是特意處理的全都藏在對(duì)話歷史里他要完整考古一遍才能動(dòng)手改。所以我把vibe coding從小項(xiàng)目延展到稍大一點(diǎn)的項(xiàng)目之后發(fā)現(xiàn)自己真正缺的不是寫(xiě)代碼的速度而是一個(gè)能把“我要什么”講清楚、并且能被機(jī)器和人都確認(rèn)的中間層。1.3 不是要放棄vibe coding而是要給它戴上“籠頭”先說(shuō)結(jié)論vibe coding本身沒(méi)有錯(cuò)錯(cuò)的是裸奔式使用。AI需要被約束而spec-driven正是目前我用下來(lái)最靠譜的約束方式。它不要求你回到傳統(tǒng)開(kāi)發(fā)那種“萬(wàn)事寫(xiě)文檔”的重流程而是要求你在讓AI動(dòng)手生成代碼之前先把行為契約、輸入輸出、異常情況、驗(yàn)收標(biāo)準(zhǔn)這些關(guān)鍵要素寫(xiě)清楚。我現(xiàn)在的開(kāi)發(fā)習(xí)慣已經(jīng)固定成兩步走第一步用一份spec把需求和邊界定義清楚第二步再把spec喂給vibe coding工具讓它嚴(yán)格按照規(guī)格實(shí)現(xiàn)。這么做之后AI的自由發(fā)揮被限制在了一個(gè)合理的范圍里而我和同事之間的溝通成本也大幅下降因?yàn)榇蠹矣懻摰氖且?guī)格而不是“AI怎么想的”。2. spec-driven的核心思路與方案設(shè)計(jì)2.1 一句話講清spec-driven到底是什么簡(jiǎn)單來(lái)說(shuō)spec-driven就是“先寫(xiě)規(guī)格說(shuō)明書(shū)再寫(xiě)實(shí)現(xiàn)代碼”但這里的規(guī)格不是那種幾百頁(yè)的傳統(tǒng)需求文檔而是面向行為、可驗(yàn)證、無(wú)歧義的技術(shù)契約。傳統(tǒng)的需求文檔關(guān)注“業(yè)務(wù)上要什么”比如“用戶(hù)能查看設(shè)備實(shí)時(shí)溫度”而spec-driven的規(guī)格更接近工程設(shè)計(jì)里的接口定義要寫(xiě)清楚輸入是什么、輸出是什么、什么情況下會(huì)報(bào)錯(cuò)、錯(cuò)誤處理路徑是怎樣的。它的讀者有兩類(lèi)一類(lèi)是AI用來(lái)生成符合規(guī)格的代碼一類(lèi)是人用來(lái)評(píng)審、驗(yàn)收、維護(hù)。我經(jīng)常拿做菜打比方。傳統(tǒng)需求文檔像是告訴廚師“做一道好吃的魚(yú)”而spec是“準(zhǔn)備一條500克左右的鱸魚(yú)蒸8分鐘出鍋淋上熱油和蒸魚(yú)豉油要求魚(yú)肉不散、無(wú)腥味”。后者才是可執(zhí)行、可檢驗(yàn)的標(biāo)準(zhǔn)。2.2 spec-driven方案選型背后我為什么選它當(dāng)初在糾結(jié)要不要引入spec-driven時(shí)我對(duì)比過(guò)三個(gè)方向一是繼續(xù)裸用vibe coding靠對(duì)話約束二是回到傳統(tǒng)的測(cè)試驅(qū)動(dòng)開(kāi)發(fā)先寫(xiě)測(cè)試再實(shí)現(xiàn)三才是spec-driven。裸用vibe coding的問(wèn)題前面已經(jīng)說(shuō)了上下文漂移、無(wú)法協(xié)作、邊界失控。傳統(tǒng)TDD其實(shí)是個(gè)好方案但對(duì)AI開(kāi)發(fā)有個(gè)尷尬的地方測(cè)試本身也要人來(lái)寫(xiě)而且寫(xiě)測(cè)試的過(guò)程往往比寫(xiě)實(shí)現(xiàn)還費(fèi)腦很多人根本堅(jiān)持不下去。spec-driven正好卡在兩者之間它的規(guī)格文檔既可以當(dāng)作生成代碼的輸入又可以當(dāng)作寫(xiě)測(cè)試的依據(jù)一舉兩得。從實(shí)操效率看寫(xiě)一份規(guī)格的時(shí)間成本大概是我直接寫(xiě)代碼的三分之一但能把返工率從百分之六十降到百分之二十左右。這個(gè)投資回報(bào)率非?？捎^尤其是對(duì)于需要迭代的項(xiàng)目省下來(lái)的是后期調(diào)試和重構(gòu)的時(shí)間。2.3 spec-driven方案的核心構(gòu)成模塊一個(gè)完整的spec-driven開(kāi)發(fā)閉環(huán)由四部分構(gòu)成行為規(guī)格定義功能的輸入、輸出、異常處理、邊界條件這是核心部分。AI生成代碼時(shí)主要依賴(lài)這部分內(nèi)容。驗(yàn)收標(biāo)準(zhǔn)明確什么樣的實(shí)現(xiàn)算是完成通常用可量化的指標(biāo)描述比如“解析結(jié)果誤差不超過(guò)0.5攝氏度”“超過(guò)3次重試后返回超時(shí)錯(cuò)誤”等。非功能約束寫(xiě)下性能要求、內(nèi)存限制、依賴(lài)限制等防止AI在實(shí)現(xiàn)時(shí)引入你不需要的東西比如嵌入式場(chǎng)景常見(jiàn)的實(shí)時(shí)性要求。變更記錄維護(hù)規(guī)格的版本歷史每次需求變化時(shí)先改規(guī)格再改代碼這樣項(xiàng)目的演進(jìn)過(guò)程完全可追溯。這四部分不是要都寫(xiě)到最細(xì)而是根據(jù)項(xiàng)目復(fù)雜程度靈活取舍。我自己做嵌入式小項(xiàng)目時(shí)重點(diǎn)寫(xiě)行為規(guī)格和驗(yàn)收標(biāo)準(zhǔn)非功能約束只寫(xiě)硬指標(biāo)變更記錄用最簡(jiǎn)單的Changelog形式。2.4 什么樣的項(xiàng)目最適合用spec-driven根據(jù)我這半年的實(shí)踐有幾種項(xiàng)目類(lèi)型用spec-driven收益特別大硬件相關(guān)開(kāi)發(fā)尤其是嵌入式固件。因?yàn)橛布壿嬕坏?xiě)錯(cuò)輕則數(shù)據(jù)不對(duì)重則燒板子必須前置定義清楚。接口封裝類(lèi)工作。比如給你的代碼庫(kù)設(shè)計(jì)對(duì)外API或者驅(qū)動(dòng)模塊給上層提供接口規(guī)格就等于接口文檔一舉兩得。多人協(xié)作的AI輔助開(kāi)發(fā)。規(guī)格是大家共同的基準(zhǔn)線誰(shuí)改了什么、為什么改看規(guī)格歷史一清二楚。需要長(zhǎng)期維護(hù)的模塊。AI生成的代碼如果不做約束三個(gè)月后回頭看跟天書(shū)一樣有規(guī)格至少能幫你快速理解設(shè)計(jì)意圖。反之如果只是臨時(shí)腳本、一次性原型驗(yàn)證、極其簡(jiǎn)單的工具函數(shù)那直接用vibe coding裸寫(xiě)就行了引入spec反而是過(guò)度設(shè)計(jì)。3. 從零搭建一套spec-driven的完整實(shí)操流程3.1 第一步先寫(xiě)一個(gè)麻雀雖小五臟俱全的spec模板直接把我用到的mini版規(guī)格模板放出來(lái)大家可以照著改格式不需要花哨重點(diǎn)是把該鎖死的信息鎖死。# 功能規(guī)格溫濕度傳感器數(shù)據(jù)讀取模塊 ## 1. 功能概述 本模塊負(fù)責(zé)通過(guò) I2C 接口讀取 SHT30 溫濕度傳感器數(shù)據(jù) 轉(zhuǎn)換為物理量后通過(guò)回調(diào)上報(bào)。 ## 2. 接口定義 - 初始化函數(shù)void sht30_init(I2C_HandleTypeDef *hi2c) - 讀取函數(shù)int sht30_read_temperature(float *temp, float *humidity) - 輸入無(wú) - 輸出temp 為溫度值(攝氏度)humidity 為濕度值(百分比) - 返回0 表示成功-1 表示 I2C 通信失敗-2 表示數(shù)據(jù)校驗(yàn)失敗 ## 3. 行為規(guī)則 - 讀取超時(shí)時(shí)間固定為 100ms - I2C 連續(xù)失敗 3 次后返回 -1 - 校驗(yàn)失敗時(shí)不修改輸出參數(shù)的值 - 溫度計(jì)算誤差不超過(guò) ±0.5 攝氏度 ## 4. 邊界與異常處理 - 傳感器未應(yīng)答返回 -1 - 校驗(yàn)和錯(cuò)誤丟棄本次數(shù)據(jù)返回 -2 - 參數(shù)為空指針直接返回 -3 ## 5. 驗(yàn)收標(biāo)準(zhǔn) - 使用模擬 I2C 數(shù)據(jù)驗(yàn)證時(shí)正確解析溫度、濕度數(shù)值 - 模擬斷線場(chǎng)景能穩(wěn)定返回 -1 - 連續(xù)讀取 1000 次無(wú)死鎖或異常崩潰這份模板看著簡(jiǎn)單但實(shí)際寫(xiě)的時(shí)候有幾個(gè)坑要注意。一是輸出參數(shù)別寫(xiě)“成功時(shí)賦值”要把失敗場(chǎng)景下參數(shù)的行為也定義清楚因?yàn)檫@個(gè)直接決定調(diào)用方如何防御性編程。二是錯(cuò)誤碼最好統(tǒng)一規(guī)劃別讓AI自己發(fā)明錯(cuò)誤碼否則不同的模塊之間錯(cuò)誤碼糾纏在一起排錯(cuò)會(huì)讓人崩潰。3.2 第二步把spec喂給vibe coding工具的正確話術(shù)寫(xiě)好了spec接下來(lái)就是讓AI干活。我試過(guò)直接丟整篇markdown給AI也試過(guò)拆成片段逐步喂實(shí)測(cè)下來(lái)拆成功能點(diǎn)逐步喂的效果最穩(wěn)。比如上面的規(guī)格文件我不會(huì)一次性全都給AI而是先給“接口定義”部分讓它寫(xiě)出函數(shù)簽名和基礎(chǔ)框架然后追加“行為規(guī)則”讓它填充重試邏輯和錯(cuò)誤處理最后給“邊界與異常處理”讓它補(bǔ)齊防御性代碼。這個(gè)過(guò)程用一句話引導(dǎo)就行“請(qǐng)按照附錄spec實(shí)現(xiàn)以下內(nèi)容嚴(yán)格遵守接口定義和錯(cuò)誤碼約定。不確定的地方先提出疑問(wèn)不要自行假設(shè)?！碧貏e強(qiáng)調(diào)“不確定的地方先提出疑問(wèn)”這半句因?yàn)锳I最容易犯的毛病就是遇到規(guī)格沒(méi)寫(xiě)清楚的地方自動(dòng)腦補(bǔ)一個(gè)合理值。它腦補(bǔ)的時(shí)候往往會(huì)跟你的真實(shí)需求發(fā)生偏差與其事后返工不如讓它先開(kāi)口問(wèn)。還有一個(gè)細(xì)節(jié)寫(xiě)spec的時(shí)候要刻意留一部分內(nèi)容不寫(xiě)比如具體用什么校準(zhǔn)算法把這個(gè)留給AI去發(fā)揮。規(guī)格不是要把AI當(dāng)無(wú)腦打字機(jī)恰恰相反要給它留一點(diǎn)可選空間這樣它能給出的方案往往比你預(yù)設(shè)的更好。3.3 第三步規(guī)格驅(qū)動(dòng)的驗(yàn)證閉環(huán)代碼生成完不等于閉環(huán)結(jié)束還需要驗(yàn)證。我現(xiàn)在的驗(yàn)證流程分三層第一層是讓AI自己對(duì)照規(guī)格做一次審查具體做法是把spec和代碼一起發(fā)回去請(qǐng)它對(duì)每一項(xiàng)行為規(guī)則核查實(shí)現(xiàn)是否一致輸出一張對(duì)照表。這個(gè)方法很實(shí)用能把大部分明顯漂移抓出來(lái)。第二層是拿規(guī)格寫(xiě)測(cè)試。怎么從規(guī)格快速生成測(cè)試我一般用兩種方式一是讓AI按照驗(yàn)收標(biāo)準(zhǔn)生成單元測(cè)試二是自己手動(dòng)覆蓋幾個(gè)關(guān)鍵邊界。比如在上面的例子里“參數(shù)為空指針?lè)祷?3”這條就是必測(cè)項(xiàng)幾乎是白送的測(cè)試用例。第三層是代碼評(píng)審。評(píng)審時(shí)不用去摳AI生成了什么代碼而是看它有沒(méi)有偏離規(guī)格。我們有句口頭禪“不帶規(guī)格看代碼就是耍牛氓?！蓖轮g評(píng)審時(shí)手里一定要握著最新的規(guī)格文檔逐條比對(duì)這個(gè)習(xí)慣建立之后評(píng)審質(zhì)量提升極快。3.4 規(guī)格與代碼的同步演進(jìn)策略實(shí)際操作中需求變更是家常便飯。我強(qiáng)烈建議定一個(gè)死規(guī)矩任何需求變更先改spec再談改代碼。哪怕只是把一個(gè)字段名從temp改成temperature都應(yīng)該先更新規(guī)格再用“請(qǐng)根據(jù)最新spec更新實(shí)現(xiàn)”的指令讓AI做同步。這么做的原因很簡(jiǎn)單規(guī)格是唯一的真相源。如果反過(guò)來(lái)先在對(duì)話里改了需求AI改了代碼然后你忘了更新規(guī)格那下次任何人包括AI自己再讀這個(gè)模塊看到的分裂狀態(tài)會(huì)直接讓上下文混亂。一次兩次可能無(wú)所謂積累多了代碼庫(kù)就變成了一個(gè)思路上的“縫合怪”。我在Git項(xiàng)目里會(huì)把spec文件放在docs/specs目錄下每個(gè)模塊對(duì)應(yīng)一份markdown和源碼一起提交這樣規(guī)格和代碼始終在同一個(gè)提交記錄里追溯起來(lái)一目了然。3.5 工具鏈搭配markdown就夠了別盲目上重型平臺(tái)關(guān)于spec-driven的工具選型我先把結(jié)論放在前面不要一上來(lái)就上一堆平臺(tái)化工具最樸素的markdown加Git版本控制已經(jīng)能覆蓋大多數(shù)項(xiàng)目需求了。我試過(guò)用Notion管理規(guī)格也試過(guò)用專(zhuān)門(mén)的API設(shè)計(jì)工具但最后都回到了本地markdown文件。原因是規(guī)格文檔最重要的是貼近代碼、便于diff、方便AI讀取這三樣是云端文檔工具很難同時(shí)滿足的。markdown文件天然滿足這些要求可以放在代碼庫(kù)里面可以查看歷史變更可以直接被AI讀取。如果你的項(xiàng)目確實(shí)需要更結(jié)構(gòu)化的規(guī)格管理可以考慮給markdown增加一些約定比如固定模板、統(tǒng)一字段命名、用表格寫(xiě)接口參數(shù)而不是引入新工具。工具越多維護(hù)負(fù)擔(dān)越重最終結(jié)果往往是規(guī)格文檔沒(méi)人更新又回到了裸code的狀態(tài)。3.6 嵌入式場(chǎng)景下的spec-driven實(shí)踐補(bǔ)充因?yàn)闊嵩~里有嵌入式vibe coding這里補(bǔ)充一下我在這類(lèi)項(xiàng)目里整理出來(lái)的特殊經(jīng)驗(yàn)。嵌入式項(xiàng)目最棘手的是硬件約束比如寄存器時(shí)序、DMA通道分配、Flash大小限制。這些信息光靠AI的理解往往是模糊的必須在規(guī)格里明確寫(xiě)清楚硬限制。例如“本芯片F(xiàn)lash共64KB固件當(dāng)前占用約40KB新模塊不得超過(guò)8KB”這類(lèi)信息AI看到之后就不會(huì)寫(xiě)出奢侈的查表算法。另外嵌入式開(kāi)發(fā)里中斷上下文和主循環(huán)上下文的區(qū)別也是AI重災(zāi)區(qū)。AI經(jīng)常默認(rèn)所有代碼運(yùn)行在同一個(gè)上下文中拿memset、printf直接放進(jìn)中斷服務(wù)函數(shù)里。為了規(guī)避這個(gè)問(wèn)題我通常在規(guī)格里加一條“中斷服務(wù)函數(shù)中禁止調(diào)用阻塞函數(shù)和動(dòng)態(tài)內(nèi)存分配”效果非常顯著。硬件相關(guān)的調(diào)試往往是規(guī)格寫(xiě)不全面的地方所以嵌入式領(lǐng)域用spec-driven時(shí)還需要特別注意“硬件行為不確定的地方要先跑最小驗(yàn)證代碼確認(rèn)后再寫(xiě)進(jìn)規(guī)格”。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 問(wèn)題一AI無(wú)視規(guī)格依舊自行發(fā)揮怎么辦這是我最開(kāi)始遇到、也是幾乎每個(gè)轉(zhuǎn)spec-driven的人都會(huì)撞上的問(wèn)題。明明規(guī)格里寫(xiě)了“超時(shí)100ms”AI生成的代碼里卻變成了“超時(shí)500ms”而且注釋還寫(xiě)得理直氣壯。排查思路大概是這樣的一是檢查喂給AI的上下文是否太長(zhǎng)導(dǎo)致它遺漏了規(guī)格細(xì)節(jié)。對(duì)話窗口內(nèi)容一大AI的局部注意力容易集中在最后幾段text前面的設(shè)定就容易丟。處理辦法是把規(guī)格拆小一次只喂一個(gè)模塊的規(guī)格。二是試試在代碼塊注釋里直接嵌入關(guān)鍵約定比如在函數(shù)定義的注釋里重復(fù)一遍“讀取超時(shí)固定為100ms”讓AI在生成代碼的時(shí)候就近看到約束。三是用“請(qǐng)逐條對(duì)比規(guī)格并指出不一致之處”的指令做二次審查強(qiáng)制AI自己檢查矛盾點(diǎn)。這三板斧下來(lái)九成以上的無(wú)視規(guī)格問(wèn)題都能解決。4.2 問(wèn)題二規(guī)格寫(xiě)太細(xì)AI變得束手束腳反而低效另一條很容易走的極端是規(guī)格寫(xiě)得事無(wú)巨細(xì)連循環(huán)用什么變量名、函數(shù)內(nèi)部先做什么后做什么都規(guī)定清楚結(jié)果AI從“生成器”變成了“翻譯器”生成的代碼質(zhì)量反而更差。后來(lái)我把規(guī)格分成兩個(gè)等級(jí)一級(jí)是“契約級(jí)”比如接口定義、錯(cuò)誤碼、邊界行為必須嚴(yán)格遵循二級(jí)是“建議級(jí)”比如用什么排序算法、怎么組織文件結(jié)構(gòu)允許AI自由選擇。遇到“建議級(jí)”內(nèi)容我會(huì)在規(guī)格里用“可以”“建議”之類(lèi)的措辭遇到“契約級(jí)”內(nèi)容用“必須”“禁止”之類(lèi)的強(qiáng)約束詞。AI對(duì)這兩類(lèi)詞的分辨能力比我預(yù)想中強(qiáng)值得充分利用。4.3 問(wèn)題三規(guī)格和代碼不一致該信誰(shuí)項(xiàng)目進(jìn)行到中后期常常會(huì)出現(xiàn)“規(guī)格是舊的代碼是新的”這種分裂狀態(tài)。這時(shí)候最忌諱的是直接改代碼去湊規(guī)格正確做法是先確認(rèn)哪個(gè)版本的意圖才是你真實(shí)的意圖。我的操作習(xí)慣是當(dāng)發(fā)現(xiàn)不一致的時(shí)候先翻Git提交記錄看規(guī)格和代碼誰(shuí)先被修改。如果代碼先改了說(shuō)明當(dāng)時(shí)肯定有一個(gè)未記錄的需求變更需要補(bǔ)進(jìn)規(guī)格如果規(guī)格先改了說(shuō)明AI或人工實(shí)現(xiàn)沒(méi)跟上需要催代碼更新。等到規(guī)格和代碼重新對(duì)齊之后再?zèng)Q定下一步動(dòng)作。這個(gè)流程雖然聽(tīng)起來(lái)繞了一下但能避免很多拍腦袋決策導(dǎo)致的反復(fù)。4.4 問(wèn)題四怎么判斷規(guī)格寫(xiě)得“夠了”不少朋友問(wèn)我到底寫(xiě)到什么程度算“夠了”能開(kāi)始動(dòng)工了。我自己的標(biāo)準(zhǔn)是當(dāng)看到這份規(guī)格的人或AI能在不看其他任何資料的條件下獨(dú)立做出符合預(yù)期的實(shí)現(xiàn)就算夠了。這里又得回到我前面的觀點(diǎn)規(guī)格不是要準(zhǔn)確到每個(gè)if語(yǔ)句的分支而是要準(zhǔn)確到“無(wú)法產(chǎn)生第二種理解”。一個(gè)實(shí)用的判斷方法是“角色扮演法”假裝自己完全不懂項(xiàng)目背景只拿規(guī)格問(wèn)自己幾個(gè)問(wèn)題——輸入合法嗎非法輸入怎么處理網(wǎng)絡(luò)中斷怎么辦數(shù)據(jù)異常怎么辦如果每一個(gè)問(wèn)題都能從規(guī)格里找到明確答案那就可以放心交給AI去實(shí)現(xiàn)了。4.5 v2個(gè)進(jìn)度難解的坑額外補(bǔ)充再記錄一個(gè)我剛開(kāi)始實(shí)踐時(shí)踩的比較深的坑寫(xiě)spec往往沒(méi)有寫(xiě)代碼有成就感容易寫(xiě)著寫(xiě)著偷懶想跳過(guò)步驟直接讓AI干。這種時(shí)候強(qiáng)烈建議把“spec先行的原則”當(dāng)作紀(jì)律來(lái)執(zhí)行哪怕只寫(xiě)一個(gè)十五分鐘的迷你規(guī)格也不要直接裸聊需求。一旦允許了“這次先不寫(xiě)spec直接改吧”的例外接下來(lái)就會(huì)有一有二最后整個(gè)規(guī)范就名存實(shí)亡了。我自己的辦法是給每個(gè)項(xiàng)目的spec文件設(shè)置一個(gè)“未完成禁止輸入”的紅線檢查spec沒(méi)有更新完就絕不把新需求發(fā)給AI這種“強(qiáng)制儀式感”把產(chǎn)出規(guī)范和實(shí)際使用了硬綁定起來(lái)。5. 關(guān)于工具選型和擴(kuò)展的一些個(gè)人心得5.1 用AI輔助寫(xiě)spec本身的效率就很驚人其實(shí)spec文檔的撰寫(xiě)也可以交給AI來(lái)輔助生成。我長(zhǎng)期用的一套手法是先用vibe coding的方式跟AI聊一遍需求讓它生成一份draft spec然后我再人工逐個(gè)字段調(diào)整、補(bǔ)邊界、加約束。畢竟人對(duì)硬件限制和業(yè)務(wù)規(guī)則的敏感度是AI比不了的但AI比人強(qiáng)的是語(yǔ)法組織能力和查漏補(bǔ)缺的速度兩者結(jié)合效率最高。舉個(gè)例子有一次我要寫(xiě)一個(gè)串口協(xié)議解析模塊的規(guī)格如果自己從零寫(xiě)至少要一個(gè)小時(shí)。我先讓AI根據(jù)我口述的協(xié)議幀格式生成草案然后我再花二十分鐘把邊界條件、錯(cuò)誤碼、校驗(yàn)方式補(bǔ)充完整整體半小時(shí)搞定而且覆蓋到的細(xì)節(jié)比純手寫(xiě)更全。5.2 spec-driven和AI工具的未來(lái)組合潛力我目前正在嘗試的一個(gè)方向是把spec文件本身作為項(xiàng)目全局上下文的“錨點(diǎn)”讓AI在每次會(huì)話開(kāi)始時(shí)自動(dòng)加載對(duì)應(yīng)模塊的規(guī)格文件然后基于規(guī)格展開(kāi)工作。現(xiàn)在很多AI編碼工具已經(jīng)支持項(xiàng)目級(jí)上下文綁定把規(guī)范掛進(jìn)去之后即使隔了很長(zhǎng)一段時(shí)間再回來(lái)繼續(xù)做AI也保持著對(duì)模塊結(jié)構(gòu)的正確認(rèn)知。在嵌入式這種對(duì)正確性要求高的領(lǐng)域我進(jìn)一步在嘗試把spec轉(zhuǎn)成機(jī)器可校驗(yàn)的格式例如直接轉(zhuǎn)成頭文件里的靜態(tài)斷言、寄存器定義等讓規(guī)范直接進(jìn)入編譯期檢查。這個(gè)方向目前還在實(shí)驗(yàn)但效果已經(jīng)讓我堅(jiān)定了spec-driven路線值得持續(xù)投入。6. 最后分享幾條實(shí)操中養(yǎng)成的硬規(guī)矩第一永遠(yuǎn)讓規(guī)格先走一步。哪怕要改一行代碼也先在規(guī)格里改掉對(duì)應(yīng)的描述。第二不要信任AI的“我覺(jué)得應(yīng)該”。只要規(guī)格里沒(méi)有明確規(guī)定的內(nèi)容AI自作主張的實(shí)現(xiàn)一律視為bug要么改代碼要么改規(guī)格并做好記錄。第三定時(shí)把規(guī)格文件當(dāng)作rebase基準(zhǔn)。每次代碼經(jīng)過(guò)較多增刪之后我會(huì)專(zhuān)門(mén)安排一次“規(guī)格對(duì)齊日”把spec和當(dāng)前實(shí)現(xiàn)徹底核對(duì)一遍消除隱形漂移。第四在團(tuán)隊(duì)協(xié)作中評(píng)審任何AI生成的代碼前先問(wèn)一句“這代碼對(duì)應(yīng)的spec是哪個(gè)版本”。答不上來(lái)的評(píng)審直接駁回流程到目前為止運(yùn)轉(zhuǎn)得還算順暢。踩過(guò)這么多坑之后我的切身體會(huì)就是vibe coding更像是開(kāi)一輛動(dòng)力強(qiáng)悍的車(chē)跑賽道是爽但沒(méi)有路標(biāo)和護(hù)欄很快就得翻。spec不是用來(lái)限制AI的枷鎖而是給AI和人都劃清了路線的導(dǎo)航它在保住速度的同時(shí)讓你知道自己正在往哪里去。