Vibe coding 指的是把 AI 當(dāng)搭檔來寫軟件：工具可能是 Claude Code、Windsurf、Copilot、Cursor，模型可能是 Claude、Gemini、GPT。想要穩(wěn)定產(chǎn)出好代碼，關(guān)鍵不是“有沒有 AI”，而是“你怎么用 AI”。這本身就是一門手藝。

下面這 10 個實戰(zhàn)招，是我每天都在用、也確實有效的——你也能立刻上手。

1）用 AI 自己來“打磨”你的需求說明（Prompt）

假設(shè)我想讓 Windsurf 做一個用戶與工單列表頁面。很多人會隨手丟一句含糊的請求，比如：

新增一個頁面展示全部用戶；點擊用戶能看到他的請求及 ID；點開請求可以關(guān)閉或回復(fù)，同時看到全部對話；用 React 組件劃分結(jié)構(gòu)；服務(wù)層請求 API，API 再調(diào) Supabase SDK……

這對人和 AI 都不夠清晰。更好的做法是——就讓 AI 來優(yōu)化 Prompt，把任務(wù)拆清楚：

• ?? 任務(wù)：用戶請求管理頁（Angular + Supabase）
• ?? 頁面目標(biāo)：新建一個頁面，展示并管理用戶請求
• ?? 用戶列表

a.組件：UserListComponent

b.點擊用戶：加載該用戶的請求，展示請求 ID 列表

• ?? 請求詳情
• 組件：RequestDetailComponent
• 展示整段會話歷史
• 支持兩類操作：回復(fù)、關(guān)閉
• ?? 架構(gòu)
• 組件模塊化：UserListComponent 發(fā)出選中事件 → RequestListComponent 渲染請求 → RequestDetailComponent 處理會話與操作
• 統(tǒng)一的 UserRequestService 負(fù)責(zé) API
• ?? API（例如 /api/user-requests）
• 能力：獲取用戶列表 / 按用戶取請求 / 按請求取消息 / 提交回復(fù) / 關(guān)閉請求
• ?? Supabase 集成
• 用 Supabase JS SDK 查詢 users、requests、messages
• insert 新回復(fù)、update 請求狀態(tài)（如 closed=true）

這樣做的好處是：你能先驗證 AI 是否真正理解你的目標(biāo)，再讓它開工。一個好的 Prompt，應(yīng)該做到：

• 拆分任務(wù)與分層，前后端職責(zé)清楚
• 命名具體（組件、服務(wù)、路由、表結(jié)構(gòu)）
• 動作明確（允許操作、觸發(fā)條件、狀態(tài)變更）
• 技術(shù)棧落地（Angular/Supabase/接口路徑）
• UI 行為與數(shù)據(jù)模型都有交代
• 語言簡短、祈使、避免長復(fù)合句

2）讓 AI 記錄“經(jīng)驗庫”

我給 AI 設(shè)了一條規(guī)則：

# LEARNING做任務(wù)時，識別能讓下次更快完成的關(guān)鍵信息（例如項目結(jié)構(gòu)、文件位置、常見坑），寫進(jìn)項目里的 ai-learnings.md，并在后續(xù)任務(wù)引用。

如果它沒寫，我會顯式要求：請把剛才任務(wù)的要點補(bǔ)充到 ai-learnings.md。久而久之，你會得到一份專屬于項目的“AI 工作手冊”。比如某個項目里，它總結(jié)了：

• 前端：Angular 17+（Standalone Components；@if/@for）
• 服務(wù)層負(fù)責(zé) API 與狀態(tài)；組件只與服務(wù)通信
• 注入統(tǒng)一用 inject()，不用構(gòu)造器注入
• 系統(tǒng)消息統(tǒng)一走 SystemMessageService.showMessage()
• 默認(rèn)不展示成功提示，除非明確要求

隨著迭代，模式、服務(wù)、組件職責(zé)都會被梳理得越來越清楚，AI 下次就能更快對齊。

3）保留一份“團(tuán)隊規(guī)則”，隨用隨更

有些規(guī)則靠你來定更快——我會維護(hù)一份“規(guī)則清單”，項目里通常有 30～500 條，也會附帶數(shù)據(jù)庫 Schema。示例：

• 用 pnpm，不要用 npm
• 不在生成代碼中寫“贅余注釋”
• 使用 Standalone 組件
• 服務(wù)注入用 **inject()**，不要構(gòu)造器
• 需要提示用戶或輸出信息，統(tǒng)一用 system-message.service.ts 的 showMessage()；除非明確要求，不用 console
• 新建接口文件：IMySpecialInterface.ts
• ESLint 為 flat config，在 eslint.config.js
• 一次性數(shù)據(jù)獲取**優(yōu)先 async/await**，少用訂閱

團(tuán)隊規(guī)范越明確，AI 的產(chǎn)出就越貼近你的口味。把人類的共識寫清楚，是讓 AI 穩(wěn)定產(chǎn)出的核心。

4）行內(nèi)指令做快速修改

一個很實用的小技巧：別只在聊天窗口下指令，把修改請求直接寫到代碼里作為行內(nèi)注釋（Windsurf/Cascade 等都支持）。提交“更改建議”后，AI 會按注釋執(zhí)行并順手刪除注釋，效率很高。

5）避免“否定表達(dá)”，改用正向指令

我曾寫過這樣的規(guī)則：

Don’t add comments to generated code.

否定句對 AI 來說容易誤解。換成正向表達(dá)更清晰：

• 避免冗余/顯而易見的注釋
• 只有在解釋意圖、約束或復(fù)雜邏輯時才寫注釋

這樣 AI 既知道何時不寫，也知道何時該寫，效果更好。

6）別“情緒化”對話

有人覺得“調(diào)侃/施壓 AI”很好玩。我的經(jīng)驗是：情緒化語言只會降低代碼質(zhì)量。AI 會把對話語境切到一種過度謹(jǐn)慎、過度收縮的狀態(tài)，結(jié)果就是更容易出錯、更難推進(jìn)。保持客觀、明確、禮貌，反而更高效。

7）小步快跑地改

AI 改動的東西，你都得審一遍。哪怕規(guī)則很完善，它也可能出現(xiàn)意料之外的壞味道。因此：

• 避免“一鍋端”的大改動（跨多文件、上千行）
• 改成小批量、可回滾的提交
• 每次進(jìn)展都能快速 review / revert

8）常回滾，別在壞代碼上“疊羅漢”

一旦發(fā)現(xiàn)實現(xiàn)方向走偏，立刻回滾，然后改進(jìn) Prompt/規(guī)則，再來一輪。否則 AI 會在“壞基礎(chǔ)”上繼續(xù)生成更多壞代碼，越積越爛。

9）先搭架子，AI 才不“糊成一團(tuán)”

不加引導(dǎo)，AI 很容易把所有東西堆進(jìn)一個 1 萬行文件里。你需要給出清晰的架構(gòu)骨架：

• 要哪些組件、哪些服務(wù)、哪些層
• 哪些文件該復(fù)用、哪些該新建
• 某些區(qū)域已有約定，就讓它沿用，別“另起爐灶”

否則它不是全塞一處，就是過度拆分。你的指揮棒，決定了可維護(hù)性。

10）越簡單越友好

今天的 AI 還不擅長“高層抽象”。想用好它，就需要讓實現(xiàn)盡量簡單：

• 在 Angular 中，更偏向 BehaviorSubject/signals + 簡單服務(wù)
• 不要在沒有足夠規(guī)則與人類監(jiān)督下，復(fù)制一套 Redux 式 Store
• 文件結(jié)構(gòu)要直白：像 shared 這種“語義不清”的目錄，會讓它不知該放啥
• 避免“運(yùn)行期動態(tài)生成、字符串拼接注入”的黑魔法——AI 很難跟蹤

總之：明確、顯式、易跟蹤。復(fù)雜度越低，AI 越穩(wěn)定。

小結(jié)

Vibe coding 對專業(yè)工程師也很有用；但沒有方法論，AI 產(chǎn)出的代碼往往不可維護(hù)。反過來，只要你設(shè)好規(guī)則、清晰分工、收緊復(fù)雜度，它就能成為可靠的生產(chǎn)力加速器，幫你更快、更穩(wěn)地把應(yīng)用落地。