Prompt 必備六元素
Vibe Coding 場景下,給 Claude 的 prompt 必含的 6 元素。對應 Be Claude’s PM 法則 的 5 必備 context 但更實作面。
六元素
| # | 元素 | 內容 |
|---|---|---|
| 1 | 目標 | 要解決什麼問題、誰會用 |
| 2 | 範圍 | 可以動哪些檔案、不可以動哪些 |
| 3 | 既有模式 | 請參考 xxx.ts 的寫法 |
| 4 | 約束 | 效能 / 相容性 / 不可引入新依賴 |
| 5 | 驗證標準 | 完成後跑哪些測試應該通過 |
| 6 | Done 的定義 | 什麼狀態才算結案 |
範例:好 Prompt
[目標]
我要在後台新增一個「使用者活躍度報表」endpoint,給內部營運團隊使用。
[範圍]
- 可動:src/reports/、src/routes/admin.ts、tests/reports/
- 不可動:src/auth/、src/db/schema.ts、src/core/
[既有模式]
請參考 src/reports/revenue.ts 的結構:
- 一個 service 檔負責查詢
- 一個 route handler 負責驗證權限與序列化
- 一個 *.test.ts 跑 integration
[約束]
- 不引入新套件
- 查詢需在 500ms 內完成(DB 已有 index on users.last_seen_at)
- 必須走現有 admin auth middleware
[驗證]
- 新增 tests/reports/activity.test.ts
- 至少涵蓋:未授權 401、空資料、有資料、分頁
- npm run test:reports 必須全綠
[Done]
- PR 描述標示 AI 產出範圍
- 跑一次 stress test:1000 reqs / 60s對照糟糕版本
「幫我加一個活躍度報表 API」
缺:範圍、模式、約束、驗證、Done。AI 只能自由發揮,產出風險極高:
- 可能改到 src/auth/
- 可能寫法跟既有 reports 不一致
- 可能引入新套件
- 可能沒測試
- 可能「能跑就好」交差,沒涵蓋 401 / 分頁 / stress
不是越多越好
⚠️ 注意:六元素是必備,不是「越詳細越好」。詳見 過度約束反效應。
規範要求:六元素都到位
最佳化空間:每個元素內部寫得簡潔,留 AI 發揮空間
譬如「既有模式」段——指定參考檔即可,不要把每個變數命名都寫死。
跟其他 prompt 框架對比
| 框架 | 重疊度 | 差異 |
|---|---|---|
| Anthropic 官方「XML structured prompt」 | 高 | 六元素是內容軸;XML 是結構軸,互補 |
| OpenAI Function Calling spec | 中 | Function Calling 強調 schema;六元素強調 context |
| LangChain prompt template | 低 | LangChain 強調可組合;六元素強調人類書寫 |
落地工具
- Skills 九種類型 — 把六元素 template 包成 skill
- CLAUDE.md 4 層機制 — 把長期不變的「範圍 + 既有模式」寫進 CLAUDE.md,prompt 不必每次重講
- VS Code snippet / Claude Code custom prompt template
跟法則的關係
| 元素 | 對應法則 |
|---|---|
| 目標 / Done | Be Claude’s PM 法則(提供完整 context) |
| 範圍 | 聚焦 Leaf Nodes 法則(限制 blast radius) |
| 既有模式 | Be Claude’s PM 法則 |
| 約束 | Be Claude’s PM 法則 |
| 驗證標準 | 建立可驗證檢查點 法則 |
相關
- Vibe Coding / 四大黃金法則 (Vibe Coding)
- Be Claude’s PM 法則
- Plan-then-Execute SOP — Step 4 餵入 prompt 時用六元素
- 過度約束反效應 — 六元素也不能塞滿到綁手綁腳
- Vibe Coding TDD 三條 e2e 測試 — 「驗證標準」元素的具體實作