1. vibe coding 到底是什么從一個(gè)周末原型說起大概每個(gè)程序員都有過這樣的周六早起泡了杯咖啡腦子里突然冒出一個(gè)工具需求——把同事們散落在飛書文檔里的周報(bào)自動(dòng)匯總成一份 Markdown 報(bào)表省得每周五下午手動(dòng)復(fù)制黏貼。放到兩年前我得先搭個(gè) Python 腳本、處理鑒權(quán)、寫解析邏輯、再做個(gè)簡(jiǎn)陋的 web 頁(yè)面一套搞下來一整天沒了。而在 2025 年初我打開終端把需求用大白話敲給 AI 編程助手十分鐘后一個(gè)可運(yùn)行的版本就躺在屏幕上。這就是 vibe coding——一種用自然語(yǔ)言做產(chǎn)品經(jīng)理讓 AI 當(dāng)主力打工人的編程方式。vibe coding 這個(gè)詞最早是 Andrej Karpathy 提的。他當(dāng)時(shí)的原話大意是你不再逐行思考代碼而是描述需求、讓模型生成、再把生成的代碼當(dāng)作真實(shí)代碼一樣運(yùn)行和調(diào)試全程跟著感覺走。這個(gè)描述很精準(zhǔn)因?yàn)樗暮诵牟皇亲?AI 補(bǔ)全幾行代碼而是把整個(gè)開發(fā)節(jié)奏從手寫變成對(duì)話—運(yùn)行—反饋的循環(huán)。聽上去很輕松實(shí)際操作起來卻沒那么簡(jiǎn)單——很多抱著玩一玩心態(tài)上手的人第一周就會(huì)碰上一堆AI 看起來很自信、跑起來全是坑的情況。這篇文章就圍繞我連續(xù)三個(gè)月用 vibe coding 做真實(shí)項(xiàng)目的經(jīng)驗(yàn)來寫。它適合三類人想給團(tuán)隊(duì)引入 AI 輔助編程的 Tech Lead需要快速出原型又不想從零造輪子的獨(dú)立開發(fā)者以及剛接觸 AI 編程、想知道該從哪入手和避坑的新手。我會(huì)把工具選型、實(shí)操流程、踩過的坑和總結(jié)出的治理手段一次講清保證不是那種Copy 一段提示詞就完事的速食內(nèi)容。2. 工具鏈選型為什么我最終留下的是這兩個(gè)組合2.1 編輯器內(nèi)置助手 vs 獨(dú)立 Agent 工具現(xiàn)在市面上的 AI 編程工具大致分兩類。一類是 IDE 內(nèi)嵌的補(bǔ)全和對(duì)話面板典型代表是GitHub Copilot、Trae、PyCharm / VS Code 里的 AI 插件另一類是能自己讀倉(cāng)庫(kù)、改文件、跑命令、看報(bào)錯(cuò)的獨(dú)立 Agent典型代表是Claude Code、Cursor 的 Agent 模式、開源的AI Agent 框架。兩者不是替代關(guān)系我的使用感受是日常小改動(dòng)用內(nèi)置助手效率和順手程度最高涉及多文件重構(gòu)、跨模塊排查、從零搭項(xiàng)目時(shí)獨(dú)立 Agent 的上下文理解能力和連續(xù)操作能力明顯更強(qiáng)。我一開始只用 Copilot 做行級(jí)補(bǔ)全后來切到 Trae 和 Claude Code 做項(xiàng)目級(jí)生成體驗(yàn)是質(zhì)的飛躍。原因很簡(jiǎn)單行級(jí)補(bǔ)全幫你省掉的是打字時(shí)間而 vibe coding 幫你省掉的是查找—閱讀—修改—驗(yàn)證整個(gè)循環(huán)。這個(gè)循環(huán)占開發(fā)時(shí)間的比重通常在七成以上所以工具的上下文能力比生成速度更重要。選型時(shí)不光要看它寫代碼多快還要看它對(duì)項(xiàng)目結(jié)構(gòu)理解多深、能不能自己發(fā)現(xiàn)問題并修復(fù)。2.2 我測(cè)試過的幾套方案與最終組合這一節(jié)直接上結(jié)論。我拿同一個(gè)內(nèi)部項(xiàng)目周報(bào)匯總工具分別跑了以下組合記錄項(xiàng)目從零到可以實(shí)際使用的時(shí)間方案環(huán)境從零到可用耗時(shí)跑通率我的評(píng)價(jià)Copilot VSCode本機(jī)約 2.5 小時(shí)60%可靠但偏保守適合做傳統(tǒng)輔助Trae AI 對(duì)話本機(jī)約 40 分鐘75%對(duì)中文需求理解好內(nèi)置模型集成省心Claude Code Claude 模型本機(jī) / 遠(yuǎn)程約 25 分鐘85%上下文最長(zhǎng)復(fù)雜重構(gòu)最穩(wěn)但需要配好 APICursor 的 Agent 模式本機(jī)約 35 分鐘80%交互友好評(píng)審界面我在用適合做 Code Review自建 URL 網(wǎng)關(guān) 開源模型服務(wù)器一天起步60%數(shù)據(jù)安全可控但折騰性能一般不推薦新手最終我日常用的組合是Claude Code 做主力開發(fā) Cursor 做人工評(píng)審 Trae 做小修補(bǔ)。特別說明一點(diǎn)工具體驗(yàn)迭代非?？焐厦孢@個(gè)組合只是我個(gè)人在穩(wěn)定使用三個(gè)月后的偏好不代表我用過的工具里誰(shuí)最厲害——你在選擇時(shí)關(guān)鍵是確認(rèn)自己的卡點(diǎn)在哪里是跨文件理解能力是人類可讀性還是安全合規(guī)2.3 本地部署的糾結(jié)與取舍有些團(tuán)隊(duì)因?yàn)閿?shù)據(jù)管控要求問我要不要本地部署 7B、14B 的模型做輔助編程。我的實(shí)測(cè)結(jié)論很直接目前本地小模型寫業(yè)務(wù)代碼還差一口氣。比如一個(gè)簡(jiǎn)單的 CRUD 接口本地 14B 模型勉強(qiáng)能搭出骨架但遇到根據(jù)登錄用戶角色動(dòng)態(tài)過濾數(shù)據(jù)權(quán)限這類稍有業(yè)務(wù)語(yǔ)義的需求生成結(jié)果的可用率就斷崖式下跌。而云端商用模型的上下文窗口大、理解力強(qiáng)綜合下來還是香得多。如果確實(shí)有數(shù)據(jù)合規(guī)壓力我建議采用折中方案對(duì)不含敏感信息的公共模塊代碼走云端模型涉敏模塊走人工寫框架 AI 單點(diǎn)補(bǔ)全的半輔助模式同時(shí)把項(xiàng)目里的密鑰、內(nèi)部域名、用戶信息全部用占位符替換后再交給 AI 處理。這個(gè)實(shí)操思路比死磕本地部署靠譜得多既拿到了 AI 的提效又守住了底線。3. 一個(gè)完整的 vibe coding 實(shí)操流程從需求句到可運(yùn)行項(xiàng)目3.1 先把需求喂成 AI 能理解的樣子很多人上手 vibe coding 的第一個(gè)失敗點(diǎn)是對(duì)著 AI 只說一句幫我寫個(gè)周報(bào)匯總工具然后抱怨 AI 寫得不對(duì)。真實(shí)項(xiàng)目里的需求從來不會(huì)這么簡(jiǎn)單——用戶用 Excel 還是飛書每人每周交幾篇匯總后按什么排序異常格式怎么處理你不想清楚AI 就替你隨便想那結(jié)果必然不是你要的。我在實(shí)踐中養(yǎng)成了需求五要素的提示詞模板每次喂給 AI 之前先自己填充目標(biāo)項(xiàng)目要解決什么問題面向誰(shuí)使用輸入數(shù)據(jù)的來源、格式、文件位置、字段示例輸出最終給到用戶的界面/文件/接口長(zhǎng)什么樣約束技術(shù)棧要求、運(yùn)行環(huán)境、性能指標(biāo)、代碼規(guī)范邊界明確不做哪些事哪些場(chǎng)景不接受。拿周報(bào)匯總舉例我的提示詞開頭部分是這么寫的這是一個(gè) Python Streamlit 的內(nèi)部工具目標(biāo)是把 /data/reports 目錄下所有 Markdown 周報(bào)合并成一份總覽頁(yè)面。每份周報(bào)有固定的 YAML 頭作者、日期、項(xiàng)目名正文里有本周完成下周計(jì)劃阻塞事項(xiàng)三個(gè)二級(jí)標(biāo)題。輸出頁(yè)面需要按項(xiàng)目分組并標(biāo)記每個(gè)作者是否包含本周完成部分。暫不支持圖片和表格直接在頁(yè)面上渲染 Markdown 文本即可。這五要素看起來笨重但實(shí)際上 AI 幫你省的是實(shí)現(xiàn)細(xì)節(jié)絕不是需求分析。需求寫得越清楚后面迭代的輪次越少體驗(yàn)越接近神話里的一鍵生成。3.2 對(duì)話式生成的正確節(jié)奏小步快跑vibe coding 里最容易走偏的做法是想一次性讓 AI 生成一個(gè)完整系統(tǒng)。比如給我做一個(gè)帶用戶系統(tǒng)、權(quán)限管理、數(shù)據(jù)庫(kù)、后臺(tái)管理、通知服務(wù)、報(bào)表模塊的 CMS這種提示詞扔給任何模型都只會(huì)得到一堆華麗的垃圾——因?yàn)樾枨罅６忍竽Ｐ椭荒馨唇炭茣０迤礈愐坏I(yè)務(wù)細(xì)節(jié)和你想象的不一樣返工成本極高。正確做法是把項(xiàng)目拆成10~30 分鐘內(nèi)能驗(yàn)證的一個(gè)個(gè)獨(dú)立功能逐個(gè)對(duì)話生成、逐個(gè)運(yùn)行驗(yàn)證。以我的周報(bào)匯總工具為例實(shí)踐中的開發(fā)順序是先用一個(gè)腳本遍歷目錄、讀取 YAML 頭、輸出結(jié)構(gòu)化 JSON把 JSON 轉(zhuǎn)成 Streamlit 頁(yè)面先能顯示本周完成部分加項(xiàng)目分組和統(tǒng)計(jì)計(jì)數(shù)處理異常文件格式和空?qǐng)?bào)告最后加導(dǎo)出 Markdown 的功能。每一步的對(duì)話都非常短。第二步的提示詞可能是上一步輸出的 JSON 結(jié)構(gòu)是 [{author, date, project, done, plan, blockers}]現(xiàn)在幫我把這個(gè) JSON 用 Streamlit 渲染成一張卡片列表卡片按 project 分組每個(gè)作者顯示 done 和 blockers頁(yè)面頂部顯示總報(bào)告數(shù)和缺失報(bào)告數(shù)。每輪對(duì)話只解決一個(gè)具體問題AI 的表現(xiàn)會(huì)穩(wěn)定得多你也能在每輪之間快速判斷方向是否對(duì)。3.3 讓 AI 自己跑起來運(yùn)行、報(bào)錯(cuò)、修復(fù)的閉環(huán)vibe coding 和傳統(tǒng)用 AI 查代碼最大的不同是AI 要能自己運(yùn)行項(xiàng)目并讀取報(bào)錯(cuò)。我在用 Claude Code 時(shí)會(huì)直接把報(bào)錯(cuò)信息貼回對(duì)話或者讓 Agent 自己執(zhí)行 pytest。這個(gè)環(huán)節(jié)對(duì)工具的 Agent 能力要求最高——它得能從報(bào)錯(cuò)堆棧里定位是邏輯問題、環(huán)境問題還是依賴問題然后自己修改。舉個(gè)例子我有個(gè)項(xiàng)目在 Windows 上跑得好好的放 Linux 服務(wù)器上就報(bào)PermissionError。傳統(tǒng)做法可能是查半天文檔而 vibe coding 的做法就是把報(bào)錯(cuò)原文丟給 AI這是 Linux 部署時(shí)遇到的報(bào)錯(cuò)幫我分析是不是文件權(quán)限或路徑分隔符的問題并直接修復(fù)。模型會(huì)從五六個(gè)候選原因里快速篩選給出補(bǔ)丁并解釋為什么改。老實(shí)說這種AI 幫你白盒化排錯(cuò)的效率提升比代碼生成本身更讓我上癮。跑通之后還有一件很多人忽略的小事讓 AI 順手寫一個(gè)README和若干單元測(cè)試。AI 在項(xiàng)目上下文清晰時(shí)寫的測(cè)試覆蓋率遠(yuǎn)超大部分開發(fā)者的日常水平這些測(cè)試在后面迭代時(shí)就是你的安全網(wǎng)——AI 不會(huì)記得它昨天給你生成過什么但測(cè)試代碼會(huì)。4. 踩坑實(shí)錄AI 寫代碼時(shí)有四種看起來很對(duì)的坑4.1 幻覺型依賴裝了個(gè)不存在的 Python 包我踩過最經(jīng)典的一個(gè)坑是讓 AI 寫一個(gè)解析 PDF 表格的腳本它在代碼里引入了pdf-table-extractor。結(jié)果一跑報(bào)錯(cuò)ModuleNotFoundError。我順手查了 PyPI發(fā)現(xiàn)這個(gè)包根本不存在——典型的模型幻覺。它不只是編包名還會(huì)編 API 簽名、編函數(shù)參數(shù)、編返回結(jié)構(gòu)。后來我養(yǎng)成了兩個(gè)習(xí)慣。第一每輪 AI 生成代碼后我不急著直接跑先掃一眼 import 部分對(duì)照產(chǎn)品實(shí)際 API 確認(rèn)關(guān)鍵依賴存在第二實(shí)在拿不準(zhǔn)就用pip index versions 包名驗(yàn)證版本讓命令幫我把關(guān)。這個(gè)習(xí)慣幫我避免了很多看似是代碼問題、實(shí)則是假依賴的深夜排錯(cuò)。4.2 隱性依賴污染AI 覺得這樣很合理但項(xiàng)目不這么想如果說幻覺型依賴是明坑那隱性依賴就是暗坑。AI 在處理代碼時(shí)往往傾向于使用它記憶里最常見的庫(kù)和范式而不是你項(xiàng)目里既有的范式。比如我有一個(gè)倉(cāng)庫(kù)用的 FastAPI Pydantic v2結(jié)果 AI 在一段獨(dú)立腳本里默默用了 Pydantic v1 的validator寫法代碼單獨(dú)跑沒問題一合進(jìn)項(xiàng)目就直接報(bào)類型校驗(yàn)錯(cuò)誤。這種坑的可怕之處在于你光看代碼根本發(fā)現(xiàn)不了問題只有測(cè)試或者運(yùn)行時(shí)才會(huì)炸。我的對(duì)策是兩條一是項(xiàng)目根目錄放一個(gè)PROJECT_CONTEXT.md把技術(shù)棧、關(guān)鍵依賴版本、目錄結(jié)構(gòu)、常見約定寫得清清楚楚每次開新會(huì)話先在提示詞里讓 AI 讀它二是常備一把git diff的評(píng)審習(xí)慣AI 改動(dòng)的代碼必須人工過一眼重點(diǎn)不是語(yǔ)法而是它有沒有引入項(xiàng)目中沒有的新模式。4.3 高智商低判斷對(duì)不存在的需求過度設(shè)計(jì)AI 的另一個(gè)毛病是需求有一點(diǎn)模糊它就自動(dòng)往完整企業(yè)級(jí)方案上靠。我讓它給內(nèi)部小工具加按項(xiàng)目篩選結(jié)果它順手引入了完整的前端路由、狀態(tài)管理、數(shù)據(jù)庫(kù)遷移腳本。這不是能力問題而是它在訓(xùn)練數(shù)據(jù)里見過太多大型項(xiàng)目對(duì)過度的默認(rèn)偏好根深蒂固。對(duì)付這個(gè)問題我在提示詞里現(xiàn)在固定加一句只做需求描述的功能不要做任何額外擴(kuò)展不要引入數(shù)據(jù)庫(kù)或框架除非我明確要求。另外我會(huì)在需求描述里帶上內(nèi)部小工具一次性腳本僅限單用戶使用這樣的定性詞讓模型明白這次不是在做千萬(wàn)級(jí)用戶產(chǎn)品。4.4 重復(fù)代碼的漂移AI 不會(huì)記得它寫過的歷史用 vibe coding 做項(xiàng)目有個(gè)特性你很快就會(huì)意識(shí)到AI 每次對(duì)話都在重新生成新的它。它不會(huì)記得上一個(gè)問題里給出的代碼細(xì)節(jié)除非你把上下文喂給它或者讓它在同一會(huì)話里連續(xù)改。所以項(xiàng)目做到第五輪時(shí)同一個(gè)分頁(yè)邏輯可能會(huì)出現(xiàn)三個(gè)不同寫法分布在三個(gè)文件里。解決方法是分層的第一步堅(jiān)持同一個(gè)會(huì)話內(nèi)做完整功能不要頻繁新開會(huì)話繼續(xù)開發(fā)第二步重要公共邏輯主動(dòng)抽到utils/模塊并在項(xiàng)目上下文文檔里注明分頁(yè)請(qǐng)使用 utils/pagination.py不要新寫第三步代碼評(píng)審時(shí)帶一個(gè)查重的視角簡(jiǎn)單的grep關(guān)鍵詞就能發(fā)現(xiàn)有沒有第二個(gè)def paginate出現(xiàn)。這套方法我用下來把 AI 帶來的重復(fù)代碼量降低了至少一半。5. 讓 vibe coding 的產(chǎn)物真正可用的治理手段5.1 強(qiáng)制提交前評(píng)審清單沒有任何護(hù)城河的 vibe coding 等于裸奔。我在項(xiàng)目里給自己定了一個(gè)提交前五連問清單每次 AI 完成一段功能、準(zhǔn)備提交代碼前我都會(huì)過一遍依賴是否真實(shí)存在且版本可鎖定是否引用了項(xiàng)目上下文文檔之外的新框架或新路徑是否修改了與本次需求無(wú)關(guān)的文件是否處理了異常輸入和明顯邊界條件單元測(cè)試是否通過新增的關(guān)鍵路徑有沒有測(cè)試覆蓋。這五項(xiàng)看著基礎(chǔ)但作用極大。因?yàn)?AI 生成的代碼最薄弱的地方不是正常流程而是異常處理和副作用控制。一個(gè)能跑通 happy path 的 AI 代碼可能完全沒有想過如果上傳的文件是空文件怎么辦如果用戶傳的參數(shù)包含引號(hào)怎么辦。把這些問題放進(jìn)評(píng)審清單等于給 AI 的樂觀加了點(diǎn)悲觀。5.2 用 AI 做 AI 的評(píng)審人機(jī)交叉驗(yàn)證用 vibe coding 一段時(shí)間后我的評(píng)審流程也升級(jí)了當(dāng)代碼量較大時(shí)我會(huì)讓 Cursor 的 Agent 模式通讀整包改動(dòng)專門挑AI 生成代碼常見問題。這輪評(píng)審只審查不修改輸出問題清單我再逐條決策便宜行事。交叉驗(yàn)證的邏輯很簡(jiǎn)單不同模型訓(xùn)練數(shù)據(jù)不同、偏好不同A 模型生產(chǎn)代碼時(shí)容易犯的錯(cuò)B 模型往往能一眼識(shí)破因?yàn)樗鼈兛创a的偏見不一樣。我見到效果最明顯的一次是 A 模型寫了一個(gè)定時(shí)任務(wù)模塊B 模型在評(píng)審時(shí)指出任務(wù)函數(shù)里用了默認(rèn)的cron表達(dá)式但這個(gè)表達(dá)式在同一會(huì)話里已經(jīng)被前面某個(gè)功能占用過——如果兩個(gè)任務(wù)同時(shí)調(diào)度后注冊(cè)的那個(gè)會(huì)覆蓋前一個(gè)。這個(gè)坑如果不是交叉評(píng)審我大概要到月底看調(diào)度日志才能發(fā)現(xiàn)。所以我的實(shí)際建議是讓兩個(gè)不同廠商的模型互相審代碼比讓任何單一模型的自我評(píng)價(jià)都靠譜得多。5.3 項(xiàng)目上下文文檔就是你的定海神針剛才好幾次提到PROJECT_CONTEXT.md這個(gè)文件的價(jià)值我再展開說。vibe coding 面臨的一個(gè)殘酷事實(shí)是AI 對(duì)話有長(zhǎng)度限制項(xiàng)目一復(fù)雜前面的約定和決策就超出上下文窗口了。此時(shí)能讓 AI 在這個(gè)窗口內(nèi)保持項(xiàng)目一致性的只有外部文檔。我的項(xiàng)目上下文文檔通常包含項(xiàng)目目錄結(jié)構(gòu)和各模塊職責(zé)技術(shù)棧和關(guān)鍵依賴版本包括禁止使用 XXX的清單代碼風(fēng)格約定命名、格式化、注釋語(yǔ)言已知的坑和規(guī)避方法常用操作的典型做法比如新增 API 時(shí)先查詢數(shù)據(jù)庫(kù)再更新緩存順序不能反。每次和 AI 建立新會(huì)話時(shí)我第一句話就是請(qǐng)先閱讀根目錄的 PROJECT_CONTEXT.md然后基于此文檔完成以下任務(wù)。這個(gè)動(dòng)作的成本幾乎為零但防止 AI 在項(xiàng)目認(rèn)識(shí)上的漂移非常有效。如果你還在抱怨AI 每次都不按套路出牌先檢查一下自己的項(xiàng)目有沒有這么一份讓 AI 學(xué)規(guī)矩的文件。6. 關(guān)于團(tuán)隊(duì)協(xié)作和AI 是否取代程序員的一點(diǎn)現(xiàn)實(shí)思考6.1 不同經(jīng)驗(yàn)水平的開發(fā)者用 vibe coding 的效果完全不同我觀察過團(tuán)隊(duì)里不同成員用 AI 編程輔助的結(jié)果差異大得很。老手用 AI是把它當(dāng)高速實(shí)習(xí)生先拆需求、定驗(yàn)收標(biāo)準(zhǔn)、審代碼、寫邊界測(cè)試AI 負(fù)責(zé)干體力活產(chǎn)出物質(zhì)量穩(wěn)定。新手用 AI則很容易被生成結(jié)果帶著走——AI 說我改了 A 文件解決這個(gè)問題新手可能連 A 文件在哪、改了什么都說不清更不用說判斷 AI 是不是在一個(gè)隱藏的 B 文件里又動(dòng)了手腳。結(jié)論其實(shí)很樸素vibe coding 不是降低編程門檻而是降低編程阻力。它把打字、查找、接口銜接等體力活變輕了但判斷方向、評(píng)估風(fēng)險(xiǎn)、定位問題根因的能力依然是決定項(xiàng)目成敗的核心。我問過自己一個(gè)問題如果完全不懂代碼的人用 AI 能不能做出生產(chǎn)級(jí)項(xiàng)目目前我的答案是否定的。因?yàn)樗陧?xiàng)目第三周遇到一個(gè)詭異的并發(fā)問題時(shí)AI 遞過來的十個(gè)方案他一個(gè)都判斷不了——而真正的編程功夫恰恰就體現(xiàn)在這種選一個(gè)方案并承擔(dān)后果的時(shí)刻。6.2 我個(gè)人的工程紀(jì)律與工作邊界最后聊聊我現(xiàn)在的日常習(xí)慣。我用 vibe coding 做所有能做的活但有個(gè)明確邊界涉及金錢、權(quán)限、數(shù)據(jù)安全的代碼AI 只負(fù)責(zé)生成框架最終合并必須由我逐行審查并補(bǔ)全測(cè)試。沒有例外。另外我會(huì)給 AI 生成的重要代碼打上// AI-GENERATED的標(biāo)記這不是歧視而是為三個(gè)月后的自己著想——等出問題時(shí)能快速知道這段代碼的上下文來源排查路徑會(huì)短很多。我不追求AI 寫 100% 的代碼這種極端狀態(tài)更不追求全程零人工。真正的節(jié)奏是人和 AI 在一個(gè)循環(huán)里互相糾偏人負(fù)責(zé)判斷該往哪走AI 負(fù)責(zé)大踏步趕路。每折騰完一個(gè)新功能我都會(huì)花十分鐘讓 AI 順手把相關(guān)文檔和變更記錄更新一下這件事在傳統(tǒng)開發(fā)里最磨人在 vibe coding 里反而成了最輕松的收尾動(dòng)作。6.3 下一步我可以往哪個(gè)方向擴(kuò)展就我當(dāng)前手上的項(xiàng)目來說接下來想讓 AI 輔助的包括自動(dòng)化生成更多模塊的單元測(cè)試用 AI 定期掃描代碼庫(kù)里的重復(fù)實(shí)現(xiàn)并用重構(gòu)建議拉一次分支以及把之前驗(yàn)證過的提示詞模板沉淀成團(tuán)隊(duì)內(nèi)部可復(fù)用的規(guī)則集。這類擴(kuò)展會(huì)讓我離AI 輔助的工程化更近一步而不是停留在個(gè)人玩具項(xiàng)目階段。如果你剛開始嘗試我的建議是別急著把整套工具都上齊先挑一個(gè)你每天都用的編輯器裝好 AI 插件然后選一個(gè)真實(shí)但低風(fēng)險(xiǎn)的小需求走一遍提示詞 → 生成 → 運(yùn)行反饋 → 修錯(cuò)的循環(huán)。試過一次完整閉環(huán)之后你對(duì) vibe coding 適合做什么、不適合做什么會(huì)有遠(yuǎn)比看文章多得多的體會(huì)。畢竟這是一種只要上手五分鐘就能直觀感受到生產(chǎn)力的技術(shù)而它的深水區(qū)也正是從你真正用它寫完第一個(gè)完整功能那一刻才剛開始的。