隨著 LLM 越來越成熟，近半年以來在公司開發業務邏輯幾乎都是用 vibe coding 的方式，下指令叫 AI 寫 code ，而自己只負責 review 及微調的模式進行。
vibe coding 這種開發模式真的又快又好用。以往以前要花三五天寫出來的功能，現在透過 AI 的協助大概半天就可以把功能做出來，然後再花半天 review、小調整，自己驗證測試確保所有細節都沒漏掉，基本上功能就是 production-ready 的 level 了。AI 問世後真的是軟體工程師的一大福音 XD。
本篇想分享這半年 vibe coding 以來，自己常用的一些下 prompt 的技巧，讓 AI 產出來的 code 盡量一次到位，避免品質時好時壞差異過大。
- 只屬於人類的前置作業：系統分析
- 小技巧 1：開頭描述這次 prompt 行為的目的
- 小技巧 2：附上其他能參考的頁面讓 AI 抄
- 小技巧 3：告訴 AI 指定使用的 package 或 library 樣式
- 小技巧 4：指定期望修改的檔案
- 小技巧 5：先列出 implementation plan 讓我 review 還不要開始改 code
- 番外篇：生出不同版本讓我挑選
- 總結
只屬於人類的前置作業：系統分析
需求進來後，這 part 我還是會先自己釐清內容、判斷要怎麼動 code base。畢竟做久了，對自家 code base 的理解還是比 AI 從零開始爬整個 repo 更準確。在和 PM、stakeholder 討論的過程中，心裡其實就會浮現哪些能做、會動到哪些模組、哪些應該直接推掉，也會順便查看現有的設計與共用 function，之後下 prompt 時就能直接丟給 AI 參考。
我也試過只給 AI 需求讓他自己分析，但這只適合處理局部功能；要盤整整個 code base 的異動還是會漏，連 sonnet 4.5 偶爾都會偷懶，盤一盤就裝死說盤完了...。所以在 2025 年的今天，在這個階段 AI 依然只能當輔助，真正的判斷與架構設計還是得由人來主導。
當盤好異動範圍後，才正式進入 vibe coding，把工作交給 AI 去執行。
小技巧 1：開頭描述這次 prompt 行為的目的
基本上第一句話我會先簡單描述這次想讓 AI 完成的事情、這次 change 的目的。這樣 AI 比較不會失焦或雞婆去修改不必要的部分。因為改完後如果滿意就會是一個 git commit，盡量讓 commit 保持單一職責，這樣未來要 revert 或 cherry-pick 時也比較不會 conflict。
通常 prompt 第一句話我會這樣寫：
I am developing an IM web app, and I need to implement auto-closing for conversations that become idle on the customer support side.
或：
Now, our current task is to enable drag-and-drop reordering for the quick-reply items.
類似這樣一句話描述這次需求的目的。
小技巧 2：附上其他能參考的頁面讓 AI 抄
由於公司的 code base 都會有既定的 pattern 要 follow，因此在描述完後我習慣附上希望 AI 遵照的寫法讓他去參考。這這樣可以讓 AI 產出來的 code 更貼近既有風格，避免功能雖然正常但 coding style 很難整進 code base 的狀況。
以下是我在這一段的 prompt 範例：
Here are some existing functions for you to reference:
- The backend API for querying the list of open conversations is located here: /XXX/internal/app/cs/handlers/active_tickets_list.go
- The backend API for closing a conversation is here: /XXX/internal/app/cs/handlers/ticket_finish.go
- The close-conversation logic for real users on the frontend is located here: /XXX/src/pages/customer-service/agent/agent-conversation-check.tsx.
- Also, there is similar frontend logic here: /XXX/pkg/req.js
公司的 code base 經過歷史共業迭代通常已經很肥大了，直接告訴 AI 去參考某處寫法可以降低 AI 自己逛 repo 、浪費一堆 token 數跟等待的時間。而且如果有共用 function 預期要讓 AI 直接使用也可以附上，這樣也能避免 AI 又自幹了一套一模一樣的邏輯出來。
小技巧 3：告訴 AI 指定使用的 package 或 library 樣式
在業務邏輯上要達到相同目的通常有很多寫法，例如後端如果要撈 DB 可以寫 raw SQL 或用 ORM 的方式撈。前端要達到相同樣式能寫 style、下 TailwindCSS 語法或直接用現成 component library。為了不讓 AI 自己創意發想他的寫法，通常我會再補充說明一次目前專案用到的 tech stack，希望他遵守。例如：
For the backend, use GORM to query the database. Also, don't hard-code the table name like this: `db.Table("XXX")`. Instead, use `db.Model(&models.ServiceTicket{})`.
或：
For the frontend, use Shadcn components instead of manually coding `<div>` elements. Use TailwindCSS, and never write inline styles.
小技巧 4：指定期望修改的檔案
當修改目的、參考寫法與技術規範都說明後，prompt 的下一段我會列出預期 AI 應該修改的檔案位置，這樣 AI 就不用再猜測或搜尋，直接定位到正確的檔案進行修改，也能避免 AI 把檔案內容塞到奇怪的地方。例如：
This is where I want to implement the new function: /XXX/pkg/conversations.js
或：
Put the new API in this package, and follow RESTful principles and snake_case conventions: /XXX/internal/app/cs/handlers/
另外，如果有多個類似的檔案需要套用相同的改動，也可以一次列出來讓 AI 在同個 conversation 一起處理。這樣不但省問 AI 的次數，也能確保這些檔案的風格一致。
小技巧 5：先列出 implementation plan 讓我 review 還不要開始改 code
如果是自己的 side project 或是小專案，到這邊其實差不多就可以讓 AI 下去改 code 了，出來的效果不會跟預期差太多。但是我自己還是習慣先讓 AI 跑一遍 dry run，確定沒問題了才真的動 code。
這是我通常下 prompt 的最後一句：
Now analyze the code base and tell me your implementation plan. Don't start coding yet.
到這邊就是一段完整的小需求 prompt 了。AI 分析完改動後會列出他的改法，如果 review 完沒問題我就會正式讓 AI 真實下去動 code 了。然後我就會站起身來去廁所或茶水間休息一下，泡杯咖啡、順便從公司零食櫃幹點食物回到座位上，看 AI 寫 code 替我效勞，而我只需要在 AI 提示要權限時介入，以及整份需求改完後幫 AI 做一次完整的 code review。這大概就是 vibe coding 問世後的全新上班模式 XD。
番外篇：生出不同版本讓我挑選
剛剛的 prompt 適用於需求明確時的下法。如果今天的情境是需求或 UI 設計還模糊，我會先讓 AI 用 mock data 產出不同版本的畫面 layout，然後 commit 到不同的 branch 讓我挑選一個符合情境樣式的，最後再把 mock 拔掉改串真實 backend。
Create 5 different UI layouts and commit each to a separate branch so I can choose the most suitable one. For now, just use mock data in the `queryFn` within `useQuery`. Let's finish the frontend UI first before moving on to the backend API.
總結
AI vibe coding 的出現讓工程師不用再全職專注在寫 CRUD 或 boilerplate code。以現在的 vibe coding 模式，半天就能產出過去要三五天的功能，接著再花半天 review 跟微調就可以做到 production-ready 的水準。身為 senior 工程師能把更多時間放在貼近 stakeholder、PM 那端釐清需求、以及思考設計系統架構上面。