1. 先說(shuō)結(jié)論vibe coding 的本質(zhì)是什么vibe coding 這個(gè)詞最近的討論度很高但它不是什么玄學(xué)也不是完全讓 AI 寫(xiě)代碼、自己躺平。我自己的理解是進(jìn)入一種流暢的、幾乎不需要打斷思路的編碼狀態(tài)讓 Copilot 這類(lèi)工具承接重復(fù)性、機(jī)械性、中間銜接的工作把注意力留給系統(tǒng)設(shè)計(jì)和邏輯判斷。我用 Copilot 加 VS Code 的組合已經(jīng)超過(guò)兩年從最初把它當(dāng)成高級(jí)自動(dòng)補(bǔ)全到后面形成一套相對(duì)穩(wěn)定的協(xié)作流程確實(shí)踩過(guò)不少坑也總結(jié)出一些值得復(fù)用的套路。這套組合最大的價(jià)值不是代碼寫(xiě)得快而是把寫(xiě)代碼的狀態(tài)從逐字符敲擊變成描述意圖、審查產(chǎn)出、快速修正的循環(huán)整個(gè)節(jié)奏舒服很多。很多人以為 vibe coding 等于全自動(dòng)開(kāi)發(fā)其實(shí)它更接近飛行員和自動(dòng)駕駛的關(guān)系你負(fù)責(zé)航向、判斷和兜底AI 負(fù)責(zé)大部分平穩(wěn)飛行。核心是信任邊界——你要知道什么時(shí)候可以大膽讓它跑什么時(shí)候必須手動(dòng)接管。這個(gè)邊界拿捏得好效率可以翻倍拿捏不好就是在給自己埋雷。這篇文章不做概念復(fù)述直接從我自己的實(shí)戰(zhàn)經(jīng)驗(yàn)出發(fā)聊清楚三件事怎么配置一套趁手的 Copilot 環(huán)境怎么把描述想法—生成代碼—驗(yàn)證結(jié)果—重構(gòu)細(xì)節(jié)做成肌肉記憶以及哪些場(chǎng)景我建議你繞過(guò) AI、老老實(shí)實(shí)自己寫(xiě)。2. 環(huán)境配置別小看那些默認(rèn)設(shè)置它們決定了一半體驗(yàn)2.1 插件與賬號(hào)初始化Copilot 在 VS Code 里的安裝本身沒(méi)什么好說(shuō)的擴(kuò)展市場(chǎng)搜 GitHub Copilot 安裝即可。但有幾個(gè)初始化細(xì)節(jié)容易被忽略直接影響使用質(zhì)量賬號(hào)登錄走的是 GitHub 身份如果公司網(wǎng)絡(luò)有自定義代理需要在 VS Code 的 settings.json 里提前配置http.proxy否則插件裝好但請(qǐng)求一直超時(shí)很容易誤判為AI 不行。建議把 GitHub Copilot Chat 和主插件一起裝因?yàn)榧兛啃袃?nèi)補(bǔ)全做 vibe coding 是不夠的對(duì)話(huà)式生成和代碼解釋必須配合使用。安裝完以后先花兩分鐘跑一下官方示例確認(rèn)補(bǔ)全和聊天面板都能正常響應(yīng)這個(gè)時(shí)候再進(jìn)項(xiàng)目不然你很難判斷是配置問(wèn)題還是 prompt 問(wèn)題。我給團(tuán)隊(duì)內(nèi)部做分享的時(shí)候經(jīng)常打一個(gè)比方Copilot 的能力上限是模型決定的但能力下限是配置決定的。默認(rèn)配置可以用但想讓補(bǔ)全更貼合自己項(xiàng)目的風(fēng)格必須改兩處地方。2.2 核心配置文件逐項(xiàng)說(shuō)明VS Code 對(duì) Copilot 有專(zhuān)門(mén)配置項(xiàng)我現(xiàn)在的 settings.json 里長(zhǎng)期保留以下幾行{ github.copilot.enable: { *: true, markdown: false }, github.copilot.editor.enableAutoCompletions: true, github.copilot.chat.codeGeneration.instructions: [ { file: .github/copilot-instructions.md } ], editor.inlineSuggest.enabled: true, editor.suggestSelection: first }逐個(gè)說(shuō)原因github.copilot.enable里我單獨(dú)關(guān)閉了 markdown 文件的補(bǔ)全因?yàn)閷?xiě)文檔時(shí) AI 總喜歡接一些正確的廢話(huà)打斷思路。instructions 指向一個(gè)倉(cāng)庫(kù)內(nèi)的指令文件這是給 Copilot 定團(tuán)隊(duì)規(guī)矩的地方比如要求注釋用中文還是英文、變量命名風(fēng)格、禁止使用某些不安全的 API。這個(gè)文件寫(xiě)好以后所有協(xié)作者共享同一套生成標(biāo)準(zhǔn)。editor.inlineSuggest.enabled一定要為 true這是行內(nèi)補(bǔ)全的總開(kāi)關(guān)。editor.suggestSelection改 first 是避免在補(bǔ)全和本地提示之間來(lái)回混淆。.github/copilot-instructions.md是目前很多人沒(méi)用起來(lái)但價(jià)值最高的功能。我在這份文件里的內(nèi)容大致包含項(xiàng)目技術(shù)棧說(shuō)明、模塊劃分思路、命名約束、注釋語(yǔ)言、異常處理風(fēng)格、測(cè)試框架要求。每次讓 Copilot 生成代碼時(shí)它都會(huì)參考這些約束。這比你在對(duì)話(huà)里反復(fù)強(qiáng)調(diào)省事得多。2.3 快捷鍵改造讓雙手不用離開(kāi)鍵盤(pán)vibe coding 強(qiáng)調(diào)狀態(tài)流暢所以快捷鍵值得花一點(diǎn)時(shí)間定制。我個(gè)人最常用的幾個(gè)CtrlEnter接受行內(nèi)補(bǔ)全的整段建議默認(rèn)是 Tab但 Tab 在縮進(jìn)和跳轉(zhuǎn)時(shí)容易誤觸。CtrlRight逐詞接受補(bǔ)全內(nèi)容。CtrlL快速把當(dāng)前選中代碼帶入聊天窗口自定義的。AltC讓 Copilot 對(duì)當(dāng)前文件做一次快速 review 建議。重點(diǎn)不是照搬快捷鍵而是找到一套你不容易按錯(cuò)的方案。很多人覺(jué)得接受補(bǔ)全按 Tab 就行實(shí)際用下來(lái)在循環(huán)生成多個(gè)連續(xù)片段時(shí)Tab 經(jīng)常會(huì)被編輯器其他功能攔截導(dǎo)致接受了一半、停住了。我改成CtrlEnter以后順暢很多。3. 從自動(dòng)補(bǔ)全到描述式編碼的四個(gè)階段3.1 階段一讓它學(xué)會(huì)你的項(xiàng)目上下文vibe coding 的第一個(gè)階段不是急著寫(xiě)業(yè)務(wù)而是先讓 Copilot 熟悉項(xiàng)目。我通常按這個(gè)順序操作打開(kāi)項(xiàng)目根目錄下最核心的入口文件比如main.py、index.ts讓插件加載上下文。打開(kāi)項(xiàng)目文檔或 README如果里面有架構(gòu)說(shuō)明Copilot 會(huì)把它當(dāng)作重要參考。寫(xiě)完一個(gè)基礎(chǔ)類(lèi)型定義或接口簽名觀察補(bǔ)全是否貼合你預(yù)期的命名風(fēng)格。如果補(bǔ)全明顯離譜優(yōu)先檢查.github/copilot-instructions.md里的約束是否寫(xiě)清楚了。這里有個(gè)容易被忽略的細(xì)節(jié)Copilot 的上下文不是整個(gè)項(xiàng)目都理解而是基于當(dāng)前打開(kāi)文件和相鄰文件推斷上下文。所以別一口氣開(kāi)幾十個(gè)標(biāo)簽頁(yè)這反而會(huì)讓它的注意力分散。我通常只保留當(dāng)前正在改的文件、它依賴(lài)的模塊文件、以及一個(gè)參考文檔標(biāo)簽一共三四個(gè)文件生成質(zhì)量最穩(wěn)定。3.2 階段二用注釋描述意圖讓補(bǔ)全幫你搭骨架這是我的主力工作方式先寫(xiě)注釋不寫(xiě)代碼。比如我需要一個(gè)從數(shù)據(jù)庫(kù)讀取配置并解析成 Python 字典的工具函數(shù)我會(huì)先敲這段注釋# 連接 SQLite 數(shù)據(jù)庫(kù)讀取 config 表中的所有鍵值對(duì) # 返回 dict鍵為 config_key值為 config_value # 如果表不存在返回空 dict不要拋異常然后等待 Copilot 生成函數(shù)體。大部分時(shí)候它能一次給出正確的實(shí)現(xiàn)包括建表判斷和異常吞噬邏輯。這個(gè)方式的威力在于注釋本身逼我先想清楚邊界條件而實(shí)現(xiàn)細(xì)節(jié)交給 Copilot正好符合 vibe coding 的精神——你負(fù)責(zé)穩(wěn)定航道它負(fù)責(zé)平穩(wěn)飛行。從實(shí)踐效果看注釋里寫(xiě)得最清楚的是輸入是什么、輸出是什么、異常情況怎么處理這三件事只要寫(xiě)明白生成結(jié)果基本靠譜。相反如果注釋只寫(xiě)獲取配置生成結(jié)果就飄得很它不知道你要什么數(shù)據(jù)結(jié)構(gòu)、要不要默認(rèn)值、要不要緩存最后生成了一個(gè)看起來(lái)能用但實(shí)際處處別扭的函數(shù)。3.3 階段三用 Copilot Chat 做局部功能塊生成行內(nèi)補(bǔ)全之外Chat 模式用于一整塊功能的生成比如完整的一個(gè) REST API 端點(diǎn)、一條數(shù)據(jù)遷移腳本、一個(gè)復(fù)雜的查詢(xún)邏輯。我給 Chat 的 prompt 通常會(huì)這樣組織當(dāng)前項(xiàng)目技術(shù)棧Python FastAPI SQLAlchemy。 需求新增一個(gè) /api/v1/report/summary 接口接收日期范圍參數(shù) 返回該范圍內(nèi)按類(lèi)型分組的統(tǒng)計(jì)結(jié)果格式為 JSON。 約束使用異步方式查詢(xún)只涉及 report 表參數(shù)校驗(yàn)失敗時(shí)返回 400。 請(qǐng)先生成接口函數(shù)再補(bǔ)充 Pydantic schema 定義。這個(gè) prompt 包含了五類(lèi)信息技術(shù)棧、需求描述、約束條件、輸出類(lèi)型、補(bǔ)充要求。少一個(gè)都可能導(dǎo)致生成結(jié)果跑偏。技術(shù)棧信息尤其重要因?yàn)?Chat 默認(rèn)只知道你當(dāng)前文件的語(yǔ)言不清楚項(xiàng)目中用沒(méi)用 ORM、用沒(méi)用異步框架。你顯式告訴它它就不會(huì)給你一段 Flask 風(fēng)格代碼。3.4 階段四生成之后的主動(dòng)重構(gòu)我剛用 Copilot 的時(shí)候有個(gè)壞習(xí)慣看到生成代碼能跑就直接用導(dǎo)致大量函數(shù)越堆越長(zhǎng)因?yàn)?AI 傾向于在一個(gè)連續(xù)代碼塊里把所有邏輯寫(xiě)完。后來(lái)我形成一條鐵規(guī)矩凡是 AI 生成的函數(shù)必須檢查是否可以拆分。典型信號(hào)是一個(gè)函數(shù)超過(guò) 40 行函數(shù)縮進(jìn)超過(guò) 3 層或者函數(shù)里同時(shí)做了數(shù)據(jù)獲取、邏輯判斷、結(jié)果格式化三件事。只要命中其一我就會(huì)選中代碼塊讓 Copilot 提出拆分方案然后手動(dòng)調(diào)整。拆分不是讓 AI 隨便拆而是讓它按職責(zé)拆。比如上面提到的獲取數(shù)據(jù)、判斷、格式化三個(gè)步驟拆成三個(gè)私有函數(shù)每個(gè)函數(shù)保持單一職責(zé)。這一步做完代碼的可維護(hù)性和可讀性才有保障。vibe coding 真正的分水嶺就在這里有人用 AI 生成了能跑的一坨有人用 AI 生成了能維護(hù)的代碼。4. Prompt 寫(xiě)法與常見(jiàn)生成陷阱4.1 讓 Copilot 理解需求的四段式描述法很多人覺(jué)得 Copilot 生成質(zhì)量不穩(wěn)定其實(shí)是 prompt 寫(xiě)得太籠統(tǒng)。我總結(jié)出一個(gè)四段式模板適配 Chat 模式場(chǎng)景在什么環(huán)境、什么上下文里工作。任務(wù)要做出的具體產(chǎn)出。邊界哪些事情不要做、哪些情況如何處理。驗(yàn)收怎么判斷結(jié)果正確。給一個(gè)實(shí)際例子比如生成一個(gè)數(shù)據(jù)處理函數(shù)場(chǎng)景一份 CSV 文件包含 user_id, purchase_time, amount 三列。 任務(wù)讀取并統(tǒng)計(jì)每位用戶(hù)的消費(fèi)次數(shù)和總金額返回字典。 邊界amount 列有空值時(shí)跳過(guò)該行purchase_time 不需要解析成分離的時(shí)間對(duì)象。 驗(yàn)收寫(xiě)一個(gè)單元測(cè)試驗(yàn)證輸入三條記錄時(shí)輸出符合預(yù)期。前兩步保證 AI 知道做什么后兩步控制它不做多余的事。很多人漏掉的就是邊界和驗(yàn)收。沒(méi)有邊界AI 會(huì)自作主張地把時(shí)間字符串解析成 datetime 甚至加上時(shí)區(qū)處理沒(méi)有驗(yàn)收你拿到的代碼可能沒(méi)有測(cè)試還得自己補(bǔ)。4.2 行內(nèi)補(bǔ)全被帶偏的主要原因行內(nèi)補(bǔ)全的生成質(zhì)量直接受光標(biāo)之前代碼上下文影響常見(jiàn)的帶偏情況有幾種項(xiàng)目里存在大量重復(fù)風(fēng)格的代碼Copilot 會(huì)模仿當(dāng)前文件里已有的寫(xiě)法。如果舊代碼很亂它生成的新代碼也會(huì)很亂。解決辦法是在 instructions 文件里寫(xiě)明風(fēng)格要求。類(lèi)型不明確如果函數(shù)參數(shù)沒(méi)有類(lèi)型注解它無(wú)法確定該參數(shù)支持的方法很容易給出一個(gè)錯(cuò)誤的屬性調(diào)用?？s進(jìn)或語(yǔ)法錯(cuò)誤如果當(dāng)前代碼本身有語(yǔ)法錯(cuò)誤補(bǔ)全會(huì)進(jìn)入試圖修復(fù)的模式生成一堆奇怪內(nèi)容。對(duì)付這些帶偏情況最好的辦法不是刪掉重寫(xiě)而是先修上下文再讓補(bǔ)全重新建議。我習(xí)慣把光標(biāo)往前移動(dòng)幾行刪掉可能造成誤導(dǎo)的變量命名字符然后重新觸發(fā)CtrlEnter。大部分時(shí)候第二次建議會(huì)比第一次準(zhǔn)很多。4.3 指令文件里必須寫(xiě)清楚的三件事.github/copilot-instructions.md不是什么宏大文檔我最核心的內(nèi)容很短大概十幾行只包含三件事架構(gòu)約束比如所有數(shù)據(jù)庫(kù)訪問(wèn)必須通過(guò) repository 層禁止在 service 層直接執(zhí)行 SQL。風(fēng)格約定比如變量命名使用 snake_case私有函數(shù)以下劃線開(kāi)頭注釋使用中文但代碼命名使用英文。禁忌清單比如禁止使用eval()禁止把except Exception寫(xiě)成pass禁止在循環(huán)內(nèi)執(zhí)行耗時(shí)請(qǐng)求。這些約束不必字字句句是法律但至少保證生成結(jié)果不會(huì)犯低級(jí)結(jié)構(gòu)性錯(cuò)誤。Copilot 生成代碼時(shí)確實(shí)會(huì)參考這份文件如果你發(fā)現(xiàn)它沒(méi)遵守大概率是文件內(nèi)容寫(xiě)得太抽象。寫(xiě)代碼質(zhì)量要高沒(méi)有用要寫(xiě)函數(shù)行數(shù)不超過(guò) 50 行超過(guò)必須拆分這種可以檢查的具體要求。5. 一套可落地的 vibe coding 工作流5.1 從需求到代碼的完整流程示例下面是我近幾個(gè)月做某內(nèi)部工具時(shí)實(shí)際用過(guò)的一個(gè)完整流程。需求是一個(gè)批量導(dǎo)入用戶(hù)數(shù)據(jù)的腳本輸入 Excel 文件路徑讀取指定工作表校驗(yàn)數(shù)據(jù)并把合法記錄寫(xiě)入數(shù)據(jù)庫(kù)。第一步我不寫(xiě)代碼而是用自然語(yǔ)言在 Chat 里描述要解決的問(wèn)題并要求它給出大致的實(shí)現(xiàn)方案。Copilot 給出一個(gè)三步方案用pandas讀取、用 Pydantic 校驗(yàn)、用 SQLAlchemy 批量插入。第二步我把方案拆成兩個(gè)可以逐步驗(yàn)證的片段先實(shí)現(xiàn)讀取和校驗(yàn)部分運(yùn)行一下確認(rèn)數(shù)據(jù)沒(méi)讀錯(cuò)再實(shí)現(xiàn)批量插入部分。分步生成有個(gè)好處每段代碼都經(jīng)過(guò)實(shí)際運(yùn)行驗(yàn)證不會(huì)出現(xiàn)整個(gè)腳本跑完才發(fā)現(xiàn)前置步驟全錯(cuò)。第三步對(duì)于校驗(yàn)邏輯里有一處復(fù)雜的字段轉(zhuǎn)換我自己寫(xiě)不讓 Copilot 碰。原因是這個(gè)轉(zhuǎn)換規(guī)則業(yè)務(wù)性太強(qiáng)涉及一堆模糊匹配邏輯AI 沒(méi)法從上下文推出來(lái)讓它生成只會(huì)制造幻覺(jué)。最終這個(gè)需求從開(kāi)始到完成用了大概四十分鐘其中寫(xiě)代碼的時(shí)間只有十分鐘其他時(shí)間在跑測(cè)試和數(shù)據(jù)核對(duì)。這個(gè)比例對(duì) vibe coding 來(lái)說(shuō)是正常的——AI 幫你壓縮的是打字時(shí)間不是思考時(shí)間。5.2 先寫(xiě)測(cè)試再讓 Copilot 補(bǔ)實(shí)現(xiàn)想讓 vibe coding 不失控我強(qiáng)烈建議在關(guān)鍵模塊上使用測(cè)試先行。不是讓你寫(xiě) TDD 全套流程而是讓 Copilot 先生成測(cè)試用例再生成實(shí)現(xiàn)。比如我需要一個(gè)函數(shù)判斷某個(gè)用戶(hù)是否滿(mǎn)足優(yōu)惠活動(dòng)條件。我先讓 Copilot 基于需求描述生成一組測(cè)試用例用例里包含了正常滿(mǎn)足條件、條件缺一個(gè)、數(shù)據(jù)為空等場(chǎng)景。測(cè)試用例本身就是需求規(guī)格的具象化看完測(cè)試用例你就能確認(rèn) AI 有沒(méi)有理解對(duì)需求。然后讓 Copilot 實(shí)現(xiàn)該函數(shù)跑一遍測(cè)試。測(cè)試全綠就收工有紅的就根據(jù)具體報(bào)錯(cuò)去調(diào)整實(shí)現(xiàn)。這種方式比生成代碼—人工目測(cè)—打包上線可靠得多因?yàn)?AI 生成的代碼在語(yǔ)法上幾乎不出錯(cuò)真正出錯(cuò)的是業(yè)務(wù)邏輯而業(yè)務(wù)邏輯錯(cuò)誤只能靠具體的輸入輸出暴露出來(lái)。很多人嫌寫(xiě)測(cè)試麻煩我的實(shí)際體驗(yàn)是AI 生成測(cè)試和生成業(yè)務(wù)代碼一樣快麻煩的不是寫(xiě)測(cè)試而是把測(cè)試場(chǎng)景想全。而想測(cè)試場(chǎng)景這個(gè)事恰恰是 AI 不懂業(yè)務(wù)、無(wú)法替代你的地方。5.3 讓 Copilot 做代碼審查的隱藏玩法除了生成代碼Copilot 還能充當(dāng)初級(jí)代碼審查者。我每寫(xiě)完一個(gè)模塊會(huì)選中這段代碼在 Chat 里輸入請(qǐng)審查這段代碼重點(diǎn)尋找潛在的異常路徑、類(lèi)型問(wèn)題、性能問(wèn)題 用簡(jiǎn)短列表返回問(wèn)題位置和修改建議不要重寫(xiě)整段代碼。這個(gè)用法在生成代碼后特別有價(jià)值。因?yàn)?Copilot 生成代碼時(shí)往往只盯著自己要完成的那一小塊容易忽視全局性的問(wèn)題比如重復(fù)連接數(shù)據(jù)庫(kù)、重復(fù)計(jì)算相同值、異常處理過(guò)于寬泛。讓它回頭審視一遍確實(shí)能揪出不少問(wèn)題。不過(guò)要注意Copilot 的審查能力有限它不太能發(fā)現(xiàn)這個(gè)功能不該這么做這種架構(gòu)級(jí)問(wèn)題更多是發(fā)現(xiàn)局部代碼質(zhì)量問(wèn)題。這跟它的定位一致——它是結(jié)對(duì)編程的 junior 搭檔不是架構(gòu)師。6. 翻車(chē)現(xiàn)場(chǎng)實(shí)錄與排查方法6.1 最典型的三類(lèi)失敗場(chǎng)景我在實(shí)際使用中總結(jié)出三類(lèi)最常踩的坑分享出來(lái)省得大家再走彎路第一類(lèi)生成的代碼在語(yǔ)法上完美但在當(dāng)前項(xiàng)目環(huán)境里無(wú)法運(yùn)行。最典型的是依賴(lài)缺失、函數(shù)簽名變了、或用了項(xiàng)目里還沒(méi)有的庫(kù)。解決方法是在 prompt 里顯式說(shuō)明只使用 requirements.txt 中已有的依賴(lài)或者基于項(xiàng)目現(xiàn)有工具庫(kù)實(shí)現(xiàn)。第二類(lèi)Copilot 給自己編造了 API。比如它給你生成了一段調(diào)用某個(gè)第三方庫(kù)的方法但這個(gè)方法在文檔里根本不存在。這種幻覺(jué)尤其愛(ài)出現(xiàn)在小眾庫(kù)或者新版本庫(kù)里。排查方法是看見(jiàn)它引用 API 后立刻跳轉(zhuǎn)到定義處確認(rèn)如果跳不進(jìn)去就搜索確認(rèn)。不要輕信它信誓旦旦的代碼。第三類(lèi)生成的代碼沒(méi)有考慮并發(fā)場(chǎng)景。如果項(xiàng)目是多個(gè) worker 同時(shí)跑任務(wù)而 Copilot 生成的代碼用了模塊級(jí)變量緩存數(shù)據(jù)就會(huì)引發(fā)數(shù)據(jù)錯(cuò)亂。這類(lèi)問(wèn)題不運(yùn)行特定場(chǎng)景很難發(fā)現(xiàn)所以處理辦法就是在 prompt 的邊界部分寫(xiě)明 該代碼可能被多線程并發(fā)調(diào)用注意線程安全。6.2 上下文污染時(shí)如何快速止損上下文污染是 vibe coding 最隱蔽的殺手。典型癥狀是明明聊的是 A 模塊Copilot 生成的代碼卻參考了之前在 B 模塊里的討論內(nèi)容導(dǎo)致出現(xiàn)奇怪的變量名或者多余的參數(shù)。這時(shí)候不要繼續(xù)在同一個(gè)會(huì)話(huà)里糾正它因?yàn)榧m正本身就是一種輸入它會(huì)繼續(xù)結(jié)合之前聊過(guò)的上下文生成更加四不像的結(jié)果。正確做法是開(kāi)一個(gè)新會(huì)話(huà)重新貼上下文重新描述需求。這個(gè)動(dòng)作成本很低但很多人不舍得放棄當(dāng)前會(huì)話(huà)結(jié)果反復(fù)糾正了二十分鐘還沒(méi)效果。另外一個(gè)止損技巧如果某個(gè)文件里有一大段錯(cuò)誤代碼不要試圖讓 Copilot 在原基礎(chǔ)上改對(duì)直接讓它基于需求重寫(xiě)這一段并且選中完整替換范圍。局部 patch 在簡(jiǎn)單改動(dòng)時(shí)有效但在結(jié)構(gòu)性問(wèn)題時(shí)重寫(xiě)比修補(bǔ)靠譜得多。6.3 排查流程速查表我把自己遇到問(wèn)題時(shí)的排查順序做成一個(gè)小清單現(xiàn)在固定用這套流程基本能在幾分鐘內(nèi)定位到問(wèn)題源頭癥狀先檢查什么再檢查什么最后選擇補(bǔ)全突然變蠢當(dāng)前文件是否有語(yǔ)法錯(cuò)誤是否多個(gè)標(biāo)簽頁(yè)上下文沖突關(guān)掉無(wú)關(guān)標(biāo)簽頁(yè)后重新觸發(fā)補(bǔ)全生成代碼無(wú)法運(yùn)行是否用了項(xiàng)目沒(méi)有的依賴(lài)API 簽名是否真實(shí)存在補(bǔ)全依賴(lài)或讓 Copilot 換實(shí)現(xiàn)方案聊天結(jié)果跑偏prompt 是否缺少邊界描述是否在舊會(huì)話(huà)里反復(fù)糾正新開(kāi)會(huì)話(huà)重寫(xiě) prompt樣式與項(xiàng)目不一致instructions 文件是否提到風(fēng)格當(dāng)前文件里是否已有亂碼風(fēng)格代碼在指令文件里補(bǔ)充風(fēng)格約定這個(gè)表不是萬(wàn)能的但它能避免一個(gè)常見(jiàn)問(wèn)題很多人一遇到生成結(jié)果不對(duì)就怪 AI 能力不行其實(shí)大部分問(wèn)題出在上下文和 prompt 上。6.4 四十行以上的生成代碼必須拆開(kāi)檢查前面提過(guò)函數(shù)拆分的原則這里展開(kāi)聊聊為什么要專(zhuān)門(mén)強(qiáng)調(diào)四十行這個(gè)數(shù)字。行內(nèi)補(bǔ)全的生成邏輯傾向于沿著當(dāng)前函數(shù)繼續(xù)往下寫(xiě)也就是說(shuō)只要你不打斷它它可以把一個(gè)函數(shù)越寫(xiě)越長(zhǎng)把所有邏輯都揉進(jìn)去。Copilot 能維持較強(qiáng)的局部一致性但代價(jià)是函數(shù)的橫向復(fù)雜度膨脹。我的經(jīng)驗(yàn)是一次生成的函數(shù)超過(guò)四十行時(shí)不太可能只有單一職責(zé)。拆分的信號(hào)包括函數(shù)內(nèi)出現(xiàn)兩個(gè)以上如果...就...的分支、出現(xiàn)連續(xù)三個(gè)以上步驟操作同一個(gè)對(duì)象、或者出現(xiàn)注釋分段標(biāo)記。碰到這些情況我會(huì)主動(dòng)在注釋里寫(xiě)拆分點(diǎn)比如# 第一步解析輸入?yún)?shù) # 第二步組裝查詢(xún)條件 # 第三步執(zhí)行查詢(xún)并格式化結(jié)果然后讓 Copilot 把每個(gè)步驟寫(xiě)成一個(gè)獨(dú)立函數(shù)。這樣既保留了 vibe coding 的速度又不會(huì)產(chǎn)生一個(gè)需要花二十分鐘讀懂的怪物函數(shù)。這個(gè)習(xí)慣養(yǎng)成以后回頭再看之前直接生成的代碼確實(shí)會(huì)有種當(dāng)時(shí)怎么能這么寫(xiě)的感覺(jué)。7. 一些反直覺(jué)但實(shí)際有效的建議不要盯著 AI 寫(xiě)代碼。很多人在 Copilot 生成代碼時(shí)會(huì)盯著屏幕等它蹦字這樣反而會(huì)把你的注意力鎖在低層次的代碼細(xì)節(jié)上。我的習(xí)慣是把大塊任務(wù)交給 Chat 生成時(shí)切出去看文檔或整理思路過(guò)一會(huì)兒回來(lái)看結(jié)果。行內(nèi)補(bǔ)全也不盯著逐字看而是等它給出推薦的整段代碼后用快捷鍵接受。減少注視 AI 動(dòng)作的時(shí)間是進(jìn)入 vibe 狀態(tài)的重要方法。不要把所有功能都交給 Copilot。有些代碼自帶高風(fēng)險(xiǎn)標(biāo)簽我會(huì)手動(dòng)寫(xiě)涉及數(shù)據(jù)遷移和刪除的腳本、涉及金額計(jì)算邏輯、涉及權(quán)限判斷的核心代碼。這類(lèi)代碼未必復(fù)雜但其正確性至關(guān)重要而且出錯(cuò)后的排查成本遠(yuǎn)高于手寫(xiě)成本。vibe coding 不是把所有代碼都甩給 AI而是把合適的那部分交給 AI。盡量把文件控制在百行以?xún)?nèi)。Copilot 的上下文理解能力和文件長(zhǎng)度成反比在超長(zhǎng)文件里它的補(bǔ)全準(zhǔn)確率明顯下降。如果你的功能需要堆到四五百行先別急著寫(xiě)拆成多個(gè)模塊、多個(gè)文件。這個(gè)建議不只是為了 Copilot也是為長(zhǎng)期可維護(hù)性考慮。文件短了AI 給出的建議天然就更準(zhǔn)這是一個(gè)正反饋循環(huán)。給指令文件定期做維護(hù)。我之前把 instructions 文件寫(xiě)好后就不管了直到有一次發(fā)現(xiàn) Copilot 還在用幾個(gè)月前某個(gè)已經(jīng)廢棄的庫(kù)的導(dǎo)入方式才意識(shí)到約束需要跟隨項(xiàng)目演進(jìn)?，F(xiàn)在每次一次重構(gòu)技術(shù)?；蚪y(tǒng)一風(fēng)格時(shí)我都會(huì)順手更新指令文件里的對(duì)應(yīng)條款。這個(gè)維護(hù)成本幾乎為零但能保證生成質(zhì)量不隨時(shí)間衰減。8. 關(guān)于 vibe coding 的邊界感回到開(kāi)頭說(shuō)的飛行員比喻。這一整套實(shí)踐走下來(lái)我最大的體會(huì)是vibe coding 并不存在一個(gè)用對(duì)了就起飛、用錯(cuò)了就完蛋的開(kāi)關(guān)它是一場(chǎng)持續(xù)在做的判斷練習(xí)。你判斷的核心問(wèn)題永遠(yuǎn)只有一個(gè)這段代碼的正確性容易驗(yàn)證嗎如果容易驗(yàn)證比如純工具函數(shù)、數(shù)據(jù)轉(zhuǎn)換、接口模板那就放心交給 AI它的效率遠(yuǎn)勝于手動(dòng)寫(xiě)。如果正確性很難驗(yàn)證比如涉及資金、權(quán)限、狀態(tài)變更的關(guān)鍵邏輯那就算 AI 能寫(xiě)得更快我也會(huì)選擇自己來(lái)。Copilot 加 VS Code 是我目前用下來(lái)順手程度最高的組合但工具會(huì)迭代、模型會(huì)升級(jí)真正值錢(qián)的不是某一款工具而是你圍繞工具建立的那套流程。流程可以讓一個(gè)普通工具產(chǎn)出穩(wěn)定可用代碼也可以讓最強(qiáng)工具產(chǎn)出一堆不可維護(hù)的垃圾。希望上面這些實(shí)踐對(duì)你建立自己的流程有幫助。如果再有人問(wèn) vibe coding 有什么用我的回答是它能把你從鍵盤(pán)前解放出來(lái)讓你更像一個(gè)設(shè)計(jì)師而不是一個(gè)打字員。但前提是你要知道自己在設(shè)計(jì)什么。