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