GitHub 官方開源的「規格驅動開發(Spec-Driven Development)」工具,用 /speckit.specify → /plan → /tasks → /implement 一條龍把模糊需求變成可執行規格,再由 AI 照規格產碼,治好「憑感覺寫(vibe coding)」的失控問題。
# Spec-Driven Development 工作流(改寫自 GitHub Spec Kit)
你是一位嚴守「規格先於程式」紀律的開發代理。請依下列階段依序執行,每一階段都先產出文件、與我確認後才進下一階段,禁止跳階直接寫 code。
## 階段 0|憲法 constitution
為本專案建立一份治理原則文件(命名慣例、架構分層、測試門檻、不可違反的底線)。
專案名稱:{{PROJECT_NAME}}
團隊既有規範 / 技術偏好:{{TEAM_PRINCIPLES}}
## 階段 1|規格 specify
把下列需求展開成一份「使用者導向」的規格:描述「要做什麼、為誰、解決什麼」,用使用者故事 + 驗收情境表達,**不要**寫任何技術選型或實作細節。
要建的功能:{{FEATURE_DESCRIPTION}}
## 階段 2|釐清 clarify
主動找出規格中所有「未明確 / 有歧義 / 邊界未定義」之處,逐條向我提問並標記為待決議。我回答後更新規格。
## 階段 3|計畫 plan
依規格產出技術實作計畫:技術棧、模組切分、資料模型、對外介面、相依與風險。
指定技術棧 / 限制:{{TECH_STACK}}
## 階段 4|一致性分析 analyze
交叉檢查 憲法 ↔ 規格 ↔ 計畫 三份文件是否一致、有無覆蓋缺口或互相矛盾,列出問題清單。
## 階段 5|拆任務 tasks
把計畫拆成可逐項勾選、有明確完成定義(DoD)的任務清單,標出相依順序與可平行項。
## 階段 6|實作 implement
依任務清單逐項實作,每完成一項就回報並對照規格驗收,全部做完前不要宣稱完成。
---
📎 來源:github/spec-kit(作者 GitHub, Inc.,MIT 授權)— 本篇為繁中改寫整理,原始指令名稱與完整 CLI 見上方連結。實際使用時,安裝官方 CLI(uv tool install specify-cli)後在支援的 AI 代理中輸入 /speckit.specify、/speckit.plan、/speckit.tasks、/speckit.implement 等指令即可。把方括號 [ ] 內的變數換成你的內容,丟進 Claude Code。
不用離開網站,直接看這組 prompt 跑出來長怎樣(AI 即時生成,扣 1 點)。
不只複製貼上 — 下載後放到 ~/.claude/skills/spec-kit-spec-driven-development-workflow/SKILL.md,之後每個 session 自動可用(觸發時自動載入)。
mkdir -p ~/.claude/skills/spec-kit-spec-driven-development-workflow && mv ~/Downloads/SKILL.md ~/.claude/skills/spec-kit-spec-driven-development-workflow/SKILL.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills\spec-kit-spec-driven-development-workflow" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\SKILL.md" "$env:USERPROFILE\.claude\skills\spec-kit-spec-driven-development-workflow\SKILL.md"## 這是什麼/解決什麼痛點 大多數人用 AI 寫程式是「丟一句話 → 看它生一坨 → 不對再罵它改」,GitHub 把這種做法稱為 vibe coding(憑感覺寫),後果是需求漂移、產出不可預期、回頭很難維護。**Spec Kit** 是 GitHub 官方開源的解法,主張 Spec-Driven Development(規格驅動開發):先把「要做什麼」寫成一份結構化、可執行的規格,再讓 AI 照規格產出實作——規格不只是參考文件,而是真正驅動程式生成的源頭。 ## 為什麼這個來源值得用 它是 **GitHub 官方專案**(不是個人 side project),MIT 授權可商用,並宣稱整合 30+ 個 AI 編碼代理(GitHub Copilot、Claude Code、Cursor、Gemini、Codex CLI 等),是目前「規格驅動」這個流派最有份量的參考實作。 ## 怎麼用(要點) 官方流程是一連串斜線指令(實際指令前綴為 /speckit.): 1. `/speckit.constitution`:建立專案治理原則。 2. `/speckit.specify`:定義「要建什麼」(需求與使用者故事,不碰技術)。 3. `/speckit.clarify`:釐清規格中未明確之處(建議做)。 4. `/speckit.plan`:用你選的技術棧產出技術實作計畫。 5. `/speckit.analyze`:交叉檢查各文件一致性與覆蓋缺口(選用)。 6. `/speckit.tasks`:把計畫拆成可執行任務清單。 7. `/speckit.implement`:照任務清單逐步把功能做出來。 另有 `/speckit.taskstoissues`(任務轉 GitHub issue)與 `/speckit.checklist`(產品質檢查表)。 安裝:需 Python 3.11+、Git 與 uv,先 `uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@<版本>`,再 `specify init <專案> --integration <代理>` 初始化。 ## 何時用 當功能有一定複雜度、需要多步驟、且你希望「過程可追、結果可預期、規格可交接」時最適合;對一次性小腳本則屬殺雞用牛刀。上方 full_prompt 是把這套六階段紀律濃縮成一份可直接貼進任何 AI 代理對話的版本,不裝 CLI 也能照著跑。 📎 來源:github/spec-kit(作者 GitHub, Inc.,MIT 授權)— 本篇為繁中改寫整理,原始內容見 source_url。
[PROJECT_NAME]專案名稱,用於憲法階段建立治理原則
[FEATURE_DESCRIPTION]你要建的功能描述(規格階段的輸入,講清楚要什麼、為誰、解決什麼)
[TEAM_PRINCIPLES]團隊既有規範或技術偏好(命名、分層、測試門檻等底線)
[TECH_STACK]指定的技術棧或限制(如 Next.js + Postgres、必須相容某現有系統等)
填下面的欄位,上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
# Spec-Driven Development 工作流(改寫自 GitHub Spec Kit)
你是一位嚴守「規格先於程式」紀律的開發代理。請依下列階段依序執行,每一階段都先產出文件、與我確認後才進下一階段,禁止跳階直接寫 code。
## 階段 0|憲法 constitution
為本專案建立一份治理原則文件(命名慣例、架構分層、測試門檻、不可違反的底線)。
專案名稱:{{PROJECT_NAME}}
團隊既有規範 / 技術偏好:{{TEAM_PRINCIPLES}}
## 階段 1|規格 specify
把下列需求展開成一份「使用者導向」的規格:描述「要做什麼、為誰、解決什麼」,用使用者故事 + 驗收情境表達,**不要**寫任何技術選型或實作細節。
要建的功能:{{FEATURE_DESCRIPTION}}
## 階段 2|釐清 clarify
主動找出規格中所有「未明確 / 有歧義 / 邊界未定義」之處,逐條向我提問並標記為待決議。我回答後更新規格。
## 階段 3|計畫 plan
依規格產出技術實作計畫:技術棧、模組切分、資料模型、對外介面、相依與風險。
指定技術棧 / 限制:{{TECH_STACK}}
## 階段 4|一致性分析 analyze
交叉檢查 憲法 ↔ 規格 ↔ 計畫 三份文件是否一致、有無覆蓋缺口或互相矛盾,列出問題清單。
## 階段 5|拆任務 tasks
把計畫拆成可逐項勾選、有明確完成定義(DoD)的任務清單,標出相依順序與可平行項。
## 階段 6|實作 implement
依任務清單逐項實作,每完成一項就回報並對照規格驗收,全部做完前不要宣稱完成。
---
📎 來源:github/spec-kit(作者 GitHub, Inc.,MIT 授權)— 本篇為繁中改寫整理,原始指令名稱與完整 CLI 見上方連結。實際使用時,安裝官方 CLI(uv tool install specify-cli)後在支援的 AI 代理中輸入 /speckit.specify、/speckit.plan、/speckit.tasks、/speckit.implement 等指令即可。這組 prompt 專為 Claude Code 設計。把 prompt 內 4 個方括號 [變數] 換成你自己的內容,貼進 Claude Code 執行即可。難度中等,照變數說明填好後即可上手。
完整 prompt 免費開放閱讀,不用註冊;登入後可一鍵複製、收藏與留言。
prompt 文字本身你可自由使用與修改。但 AI 生成物(圖/音樂/影片/文字)的商用授權,取決於你在 Claude Code 使用的方案與其官方服務條款,請以該工具的授權規範為準。
Studio engineer 視角拆解 Suno 致命弱點(油炸 vocals、高頻 artifact)+ 4 步驟 DAW workflow + Suno Studio 修音 prompt
提案產生器 / 會議處理器 / 內容再利用 / 週五回顧 / 收工 reset — 試了 40 個只有這 5 個沒被丟掉、各省 30+ 分鐘 / 次。
適合:部落格、Medium、Notion 公開頁、Substack — 任何支援 iframe / HTML 嵌入的地方。對方點「看完整」會回到本站、是 prompt 庫的免費 backlink。
<iframe src="https://prompt.luvai.net/embed/spec-kit-spec-driven-development-workflow" width="100%" height="380" frameborder="0" style="border:1px solid #e0dcd0;border-radius:4px;" loading="lazy" title="PromptCraft Embed"></iframe>
六個月在 Claude / GPT-4 / Gemini 上用人工 rater A/B 測 200+ prompt 後寫的。包含 persona+constraint stacking / anti-example / role reversal QA / cognitive scaffold / emotional priming / uncertainty CoT / steelman first。
一年的 role-play system prompt + 14-step framework 後總結:真正改變品質的是 5 個單行 prompt。沒有 role、沒有 markdown、沒有「you are an expert」。