Prompt 設計與 Instructions——讓 AI 聽懂你的話
一句話總結：Prompt engineering 不是神秘的技能。它就是「清楚地表達你的需求」。如果你能寫出清楚的技術 spec，你就能寫出好的 prompt。
結論先講：給 context 不只給指令。迭代式 prompting 比一次性超長 prompt 更有效。重複的 prompt 要模板化。Instructions 檔案要跟 code 一起版本控制。
原則一：給 Context，不要只給指令
## 差的 prompt
「寫一個 React component 顯示用戶列表」
## 好的 prompt
「在我們的 Next.js 14 專案中（App Router），
寫一個 Server Component 顯示用戶列表。
用 Tailwind CSS + shadcn/ui。
資料來源是 Prisma ORM 的 User model。
需要分頁（每頁 20 筆）和按 name 搜尋。
現有類似元件可以參考 src/components/ProductList.tsx」第二個 prompt 提供了技術棧（Next.js 14, App Router, Server Component）、設計規範（Tailwind, shadcn/ui）、資料來源（Prisma User model）、功能需求（分頁、搜尋）、參考範本（ProductList）。AI 拿到這些才能給你有用的東西。
原則二：說「我們在做什麼」而不是「你是什麼」
很多 prompt guide 建議「tell the AI its role」——「你是一個資深 React 開發者」。有用但不是最好的方式。
## 一般的做法
「你是資深前端工程師，幫我 review 這段 code」
## 更好的做法
「我們在重構 legacy jQuery 前端到 React 18。
目前處理表單驗證的遷移。
以下是原本的 jQuery 驗證邏輯和新的 React 版本。
比較兩者，確認新版沒遺漏任何驗證規則，
並指出改進方向。」為什麼第二種更好？它給了 AI 足夠 context 去理解「什麼算好」。光說「你是資深工程師」，AI 不知道你的 context 是 startup 快速迭代還是銀行嚴謹規範。
原則三：迭代式 Prompting
不要嘗試一次 prompt 就得到完美結果。正確的方式是迭代：
第一輪：「我想在 API gateway 加 request validation middleware」——看 AI 的理解對不對。
第二輪：「方向對了，但我們用 Fastify 不是 Express。validation schema 從 OpenAPI spec 自動生成」——修正方向。
第三輪：「validation 失敗回傳 RFC 7807 Problem Details 格式。schema 要支援 custom format validator」——細化需求。
第四輪：「把 validation 邏輯抽成獨立模組，加單元測試。測試覆蓋這些邊界條件：[列出]」——請求改進。
每輪都在根據 AI 產出調整方向。比一次性寫超長 prompt 更有效，因為你可以及時修正偏差。
原則四：Prompt 模板化
反覆寫類似的 prompt？模板化：
## Code Review Prompt Template
我需要你 review 以下 code：
- **語言/框架：** [填入]
- **功能描述：** [填入]
- **重點關注：** [效能 / 安全 / 可讀性 / 正確性]
- **Context：** [相關業務邏輯或限制]
請從以下角度 review：
1. 邏輯正確性（邊界條件）
2. 安全性（注入、未授權存取）
3. 效能（N+1, 不必要計算, memory leak）
4. 可維護性（命名、複雜度）
5. 測試建議
[貼上 code]存在筆記系統裡，需要時直接套用。
Instructions / Skills：讓 AI 自動遵守規範
現代 AI coding 工具支援 instructions 機制——預定義的指令集，讓 AI 在每次對話中自動遵循。
# CLAUDE.md 範例
## 專案資訊
- Next.js 14，App Router
- TypeScript (strict mode)
- pnpm / Vitest + Testing Library / Tailwind + shadcn/ui
## Coding Standards
- functional components，不用 class
- named export，不用 default export
- Result pattern 做錯誤處理（不用 try-catch 當流程控制）
- API 回應用 standardized format（見 src/lib/api-response.ts）
## 禁止事項
- 不用 any type
- 不用 console.log（用 src/lib/logger.ts）
- 不直接存取 process.env（用 src/config/env.ts）
- 不用 relative import（用 @/ alias）
## 測試要求
- 每個功能都要有測試
- 最少覆蓋：happy path、error path、邊界條件
- Mock 只 mock 外部相依怎麼寫有效的 Instructions
好的 instruction 特徵：
- 具體不抽象： 「使用 camelCase」而非「使用合適的命名」
- 有範例： 正確和錯誤的例子都給
- 可驗證： AI 和 reviewer 都能檢查
- 有理由： 解釋為什麼（AI 理解 why 後更容易正確遵循）
## 差的 instruction
「寫好的 code」
## 好的 instruction
「所有 async function 必須有 error handling。
使用 Result<T, E> pattern。
正確：
const result = await getUserById(id);
if (result.isErr()) return ApiResponse.error(result.error);
錯誤：
try { const user = await getUserById(id); } catch (e) { ... }
原因：Result pattern 讓錯誤處理 type-safe，
compiler 強制你處理所有錯誤路徑。」Instructions 的版本控制
Instructions 跟 code 一起版本控制：
project-root/
├── CLAUDE.md # AI 行為規範
├── .cursorrules # Cursor 專用
├── prompts/ # 可重用的 prompt 模板
│ ├── code-review.md
│ ├── bug-fix.md
│ └── new-feature.md
└── ...
好處：團隊共享同一套標準、變更有 history、新人加入自動套用、可以在 PR 中 review instruction 的變更。
這篇的重點回顧
Prompt 設計四原則：給 context、說場景不說角色、迭代式 prompting、模板化。Instructions 是 AI 的行為規範檔案——具體、有範例、可驗證、有理由。Instructions 跟 code 一起版本控制，團隊共享。
系列文章：
- AI 工具選型（一）：AI 是力量放大器
- AI 工具選型（二）：Code Agent 與工具選型
- AI 工具選型（三）：工作流整合實務
- 你在這裡 → AI 工具選型（四）：Prompt 與 Instructions 設計
- AI 工具選型（五）：領域知識、團隊策略與風險
「好的 prompt 跟好的技術 spec 一樣——看起來不花俏，但什麼該有的都有。」