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

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

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

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

新增一個頁面展示全部用戶；點擊用戶能看到他的請求及 ID；點開請求可以關閉或回復，同時看到全部對話；用 React 組件劃分結構；服務層請求 API，API 再調 Supabase SDK……

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

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

a.組件：UserListComponent

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

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

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

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

2）讓 AI 記錄“經驗庫”

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

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

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

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

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

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

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

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

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

4）行內指令做快速修改

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

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

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

Don’t add comments to generated code.

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

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

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

6）別“情緒化”對話

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

7）小步快跑地改

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

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

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

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

9）先搭架子，AI 才不“糊成一團”

不加引導，AI 很容易把所有東西堆進一個 1 萬行文件里。你需要給出清晰的架構骨架：

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

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

10）越簡單越友好

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

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

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

小結

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