🌿教你怎麼裝 SDD 規格驅動開發套件與更新教學：用 PowerShell 建立 Spec Kit 環境
[!NOTE] 關於這篇文章 這篇文章重新整理了原本分散的 Windows 安裝說明，把焦點收回到 SDD 規格驅動開發真正要用到的工具鏈。PowerShell 在這裡很重要，但它比較像入口與操作介面；真正的主角，是 Spec Kit 與它背後那套可以落地的工作流程。
前言
有些夜裡，terminal 視窗一個一個亮起來，桌面像被切成很多小房間。你本來只是想裝一套開發工具，後來卻碰到 PowerShell、uv、pipx、Node.js、Git、AI coding agent，最後還多出一個叫 specify 的命令。每一個名字都像是真的有用，可是它們靠得太近時，反而會讓人分不清楚誰在開門，誰在搬東西，誰才是那把真正要拿在手上的工具。
所以這篇文章想做的事情不是再多給你一份指令清單，而是把畫面重新拉開。把 PowerShell 放回它該在的位置，把 uv 與 pipx 放回它們的角色，再把 Spec Kit 放回整套 SDD 規格驅動開發流程的中心。等這些位置安靜下來之後，安裝與升級這件事就不會再像深夜裡一堆門牌發亮卻沒有路名的街區。
如果你先前是因為 PowerShell 而走進來，本文仍然會教你幾個剛好足夠的 PowerShell 指令。但主軸已經換了：這是一篇 SDD 規格驅動開發套件安裝與更新教學。PowerShell 只是順手要學會的語言，不是整篇文章的重心。若你想更完整地補 PowerShell 7 本身，文末我也會把你帶回另一篇同標籤的延伸閱讀。
目錄
- 這篇文章真正的主角是什麼
- Windows 上安裝 SDD 與 Spec Kit 工具鏈
- Spec Kit 安裝後到底多了什麼
- 以前裝過的人怎麼升級
- 順手先學會的 PowerShell 指令
- uv、pipx、PowerShell 到底誰是誰
- 最後驗證與延伸閱讀
- 如果 CLI 真的卡住：改走 Release 壓縮檔手動更新
這篇文章真正的主角是什麼
真正的主角不是 PowerShell，而是 SDD 規格驅動開發要用到的工具鏈。
這裡的 SDD，指的是 Spec-Driven Development。它不是單純叫 AI 幫你多寫一點程式，而是先把規格、原則、計畫、任務與實作整理成一條比較可追蹤的路。GitHub 的 Spec Kit，就是把這條路做成開源工具包的那一套東西。
也因此，當你在 Windows 上準備環境時，真正要處理的不是「我會不會打一個 PowerShell 指令」而已，而是下面這幾個層次：
- 你要有一個夠新的 shell，可以穩定執行現代語法與相關腳本。
- 你要有能安裝 Python CLI 的工具，像
uv或pipx。 - 你要有 Git、Node.js 與對應的 AI coding agent，讓
specify check能通過。 - 你要知道
specifyCLI 裝完之後，會對 repo 做什麼，以及升級時哪些地方可能被覆蓋。
所以本文後面的順序也會跟著調整：先把 SDD / Spec Kit 這條主線安裝好，再補幾個剛好用得到的 PowerShell 指令。這樣讀起來會比較像一條走得完的路，而不是一張看似熱鬧、其實方向不清的工具清單。
Windows 上安裝 SDD 與 Spec Kit 工具鏈
這一段是本文真正的核心。目標不是泛泛地安裝一台 Windows 開發機，而是把 Spec Kit 在 Windows 上運作所需要的最小完整環境 一次就位。
第一步：先選你要走的安裝路線
Spec Kit 並沒有規定你一定要用 Scoop。
GitHub 官方真正列出的前置條件，是 uv 或 pipx、Python 3.11+、Git，以及你要搭配的 AI coding agent。Scoop 只是 Windows 上很順手的一條路，因為它剛好能把 pwsh、git、uv、ripgrep、nvm 和 Windows Terminal 一次整理好。但如果你比較偏好 Windows 內建的套件管理器，或者你公司的環境不喜歡再加一層 Scoop，完全可以改走 WinGet 或既有環境增量安裝。
如果你想快一點做決定，可以這樣選：
- 第一次整理一台 Windows 開發機，而且想一次裝齊很多工具：選 Scoop。
- 想盡量走 Windows 原生工具、少一層第三方套件管理器：選 WinGet。
- 你本來就已經有 PowerShell 7、Git、Python 3.11：只補
uv或直接用既有的pipx就夠了。
路線 A：用 Scoop 一次把工作台整理好
如果你喜歡一次把桌面收乾淨，Scoop 仍然是很省力的路。請先開啟 Windows PowerShell，然後貼上：
# 先讓目前使用者可以執行本機 script
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
# 安裝 Scoop 套件管理器
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression
# 補上安裝來源與核心工具
scoop bucket add extras
scoop install pwsh git uv ripgrep nvm
scoop install extras/windows-terminal
# 更新 uv 的 shell 路徑，並讓 PATH 比較快生效
uv tool update-shell
Stop-Process -Name explorer -Force; Start-Process explorer
這條路的好處是節奏很整齊。你幾乎可以把本文後面會用到的大部分工具，在同一個地方裝完。
路線 B：用 WinGet 與官方套件
如果你比較想留在 Windows 內建生態裡，可以直接用 WinGet。這一條路少了 Scoop，但對 Spec Kit 來說沒有本質差別，因為真正重要的是你最後拿到 uv、Git、PowerShell 7 與一個可用的 terminal。
# 用 Windows 內建套件管理器安裝核心工具
winget install --id Microsoft.PowerShell -e
winget install --id Git.Git -e
winget install --id astral-sh.uv -e
winget install --id Microsoft.WindowsTerminal -e
winget install --id OpenJS.NodeJS.LTS -e
如果你很在意 Node.js 版本切換，而不是只需要一個穩定版，也可以把最後一行改成安裝 nvm for Windows：
winget install --id CoreyButler.NVMforWindows -e
路線 C：你已經有基礎環境，只想補最少的東西
如果你的機器本來就已經有 PowerShell 7、Git、Python 3.11，而且平常也用得順，那其實不需要為了 Spec Kit 硬把整套工具重裝一次。你只要補上 uv，或者直接沿用已經在用的 pipx 即可。
# 只補 uv，然後直接安裝 Spec Kit CLI
winget install --id astral-sh.uv -e
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.8.1
如果你本來就有 pipx，那也可以直接走這條：
pipx install git+https://github.com/github/spec-kit.git@v0.8.1
另外，uv 官方本身也提供 standalone installer 與 GitHub Releases 二進位檔下載。所以如果你所在的環境對 Scoop 或 WinGet 都有限制，也不是沒有別的門，只是那條路比較像自己拿著手電筒慢慢走。
第二步：不管你走哪條路，都切進 PowerShell 7
關掉舊視窗，打開 Windows Terminal，輸入：
pwsh
然後先確認你已經不在 5.1：
$PSVersionTable.PSVersion
pwsh --version
這一步很關鍵。Spec Kit 官方文件已經明確提到，在 Windows 上某些流程依賴 PowerShell 7+，不是舊版 Windows PowerShell 5.x。你如果還站在舊房間裡，後面有些語法和腳手架行為就是會不太對。
第三步：視你的路線決定 Node.js 怎麼裝
因為許多 AI coding agent 或輔助工具會碰到 Node.js，所以這裡還是建議你準備一個穩定版本。但要不要用 nvm，其實取決於你前面選哪一條路。
如果你走的是 Scoop 路線，或者你很確定自己之後會切換不同 Node 版本，那就繼續用 nvm：
nvm install lts
nvm use lts
如果你剛才走的是 WinGet 路線，而且你只需要一個穩定可用的 Node.js LTS，其實前一步的 winget install --id OpenJS.NodeJS.LTS -e 就已經足夠，不一定還要再補 nvm。
第四步：安裝你要使用的 AI coding agent CLI
如果你會用 GitHub Copilot CLI：
npm install -g @github/copilot
如果你會用 Claude Code：
npm install -g @anthropic-ai/claude-code
這兩個不是都必裝，但 specify check 至少要能看見你打算搭配使用的 agent。
第五步：安裝 Spec Kit 的 specify CLI
這裡請特別注意來源。Spec Kit 官方 README 已經說得很明白：真正官方維護的安裝來源，是 GitHub repository 本身，不是隨便在 PyPI 找同名套件。
也順手把前面那個容易混淆的點釐清：Scoop 不是用來安裝 Spec Kit 本身的必要條件，它只是你在 Windows 上取得 uv 的其中一種方法。 真正把 Spec Kit CLI 裝進來的，仍然是下面這條 uv tool install ... 或 pipx install ...。
以本文撰寫時的穩定版 v0.8.1 為例，建議安裝方式如下：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.8.1
如果你比較習慣 pipx，也可以這樣裝：
pipx install git+https://github.com/github/spec-kit.git@v0.8.1
如果你只是想一次性執行，不想常駐安裝 CLI，也可以使用 uvx：
uvx --from git+https://github.com/github/spec-kit.git@v0.8.1 specify init --here --integration copilot
第六步：驗證環境
specify version
specify check
當你看到 Git version control 是綠燈，而且至少一個你打算搭配的 AI coding 工具也是綠燈，通常就代表這條安裝路已經站穩了。
Spec Kit 安裝後到底多了什麼
很多人第一次看到 uv tool install specify-cli ... 時，會以為自己只是替 PATH 多裝了一個命令。其實不是。你裝進來的是一個 CLI 入口，而真正有感的變化，會在你對 repo 執行 specify init 之後出現。
建立新專案
specify init my-project --integration copilot
在既有 repo 裡初始化
specify init --here --integration copilot
安裝後常見會看到什麼
| 路徑或能力 | 用途 |
|---|---|
.specify/ |
Spec Kit 的核心目錄，包含模板、腳本與 shared memory |
.github/prompts/、.claude/commands/ 等 |
對應 agent 的命令或提示檔 |
/speckit.constitution |
建立專案原則與治理規範 |
/speckit.specify |
把需求寫成規格 |
/speckit.plan |
根據規格產出技術實作計畫 |
/speckit.tasks |
把計畫拆成任務 |
/speckit.implement |
依任務執行實作 |
如果你想知道自己版本支援哪些整合，可以先查：
specify integration list
這裡要抓住的重點是：Spec Kit 不是單純安裝一個命令列工具，而是把一套可重複使用的 SDD 工作骨架帶進你的 repo。
以前裝過的人怎麼升級
如果你以前已經裝過 Spec Kit，而 GitHub 官方後來持續更新，請先把兩件事分開看：
- 升級你機器上的
specifyCLI。 - 更新既有 repo 裡的
.specify/、agent 指令與模板。
這兩件事不是同一件事，也不應該混成一條命令去想。
情境一：我只想升級 CLI
如果你原本是用 uv tool install 裝的：
uv tool install specify-cli --force --from git+https://github.com/github/spec-kit.git@v0.8.1
specify check
如果你原本是用 pipx：
pipx install --force git+https://github.com/github/spec-kit.git@v0.8.1
specify check
如果你一直都是一次性 uvx 用法，那就沒有常駐 CLI 要升級。你只要在下一次使用時改成新版 tag：
uvx --from git+https://github.com/github/spec-kit.git@v0.8.1 specify init --here --integration copilot
情境二：我要更新既有 repo 的 Spec Kit 基礎檔案
官方 upgrade guide 特別提醒，specify init --here --force 會更新模板、腳本與命令檔，而且目前有個已知風險：.specify/memory/constitution.md 可能會被預設模板覆蓋。 如果你客製過 constitution、templates 或 scripts，請先備份。
先備份：
Copy-Item .specify/memory/constitution.md .specify/memory/constitution-backup.md
Copy-Item .specify/templates .specify/templates-backup -Recurse
Copy-Item .specify/scripts .specify/scripts-backup -Recurse
再更新：
specify init --here --force --integration copilot
如果你只想先把 constitution 還原回自己的版本：
Move-Item .specify/memory/constitution-backup.md .specify/memory/constitution.md -Force
如果你的 repo 有 Git，而且你之前有把 constitution 納入版本控制，也可以直接還原：
git restore .specify/memory/constitution.md
哪些東西通常安全，哪些東西要先小心
根據官方 upgrade guide，下面這些通常是安全的：
specs/裡的spec.md、plan.md、tasks.md。- 你的 source code。
- 你的 Git history。
真正要先防守的是這些共享基礎檔：
.specify/memory/constitution.md.specify/templates/.specify/scripts/
把升級想成換骨架，不是重寫人生。這樣你比較不會在一個按鍵之後，才發現自己最熟的那部分被蓋掉了。
順手先學會的 PowerShell 指令
既然 PowerShell 在這篇文章裡只是輔助角色，那就不需要一下子學太多。先會下面這幾組，已經足夠支撐本文的安裝與升級流程。
1. 看版本
$PSVersionTable.PSVersion
node --version
uv --version
git --version
2. 看某個命令到底在不在
Get-Command specify
Get-Command pwsh
Get-Command uv
3. 看某個路徑或檔案存不存在
Test-Path .specify
Test-Path .specify/memory/constitution.md
4. 管線與挑欄位
Get-Command pwsh, git, uv, node |
Select-Object Name, Source
5. 查幫助
Get-Help Test-Path
Get-Help Copy-Item
如果你想更完整地學 PowerShell 7 的版本差異、Profile 設定、三元運算子與更多現代語法，我還是建議你接著去讀同樣掛著 PowerShell 標籤的另一篇文章。這篇先求夠用，先求把 SDD 工具鏈裝好。
uv、pipx、PowerShell 到底誰是誰
走到這裡，很多人腦中還是會有一個小問題：我明明一直在 PowerShell 裡打字，為什麼又跑出 uv、pipx、specify？這些不都是 PowerShell 的一部分嗎？
不是。
如果用一個比較有畫面的說法，PowerShell 是你站著說話的房間，uv 和 pipx 是把工具搬進房間的人，specify 則是你真正要用來工作的那件工具。房間不是搬運工，搬運工也不是工具。只是它們剛好在同一個晚上同時出現。
精確一點可以這樣分：
| 名稱 | 身分 | 在本文裡的角色 |
|---|---|---|
PowerShell |
Shell / 命令列環境 | 你輸入命令與執行腳本的地方 |
uv |
Python 套件、專案與工具管理器 | 本文主路徑中用來安裝與執行 specify-cli |
pipx |
Python CLI 安裝器 | uv 之外的替代方案，把 CLI 裝進隔離環境後暴露到 PATH |
specify |
Spec Kit CLI | 負責 init、check、version 與整體 SDD 初始化 |
uv 的範圍比 pipx 大很多。它不只會安裝 CLI，也能處理 Python 版本、虛擬環境、專案依賴與一次性工具執行。pipx 則更聚焦，它的強項就是把終端使用者要跑的 Python 應用乾淨地裝進隔離環境。
在 Spec Kit 的脈絡裡，我會比較推薦把 uv 放在主線，因為官方文件也是這樣引導。但知道 pipx 的位置仍然很重要，因為一旦你搞懂它們的角色，很多指令看起來就不再那麼擁擠。
最後驗證與延伸閱讀
到了這裡，你真正需要的不是再多裝幾個工具，而是停下來看一下環境有沒有安靜下來。下面這一組命令，就是最後那道燈：
pwsh --version
git --version
uv --version
node --version
rg --version
specify version
specify check
如果它們都能穩定回應，你的 Windows 上那條 SDD 工具鏈就已經有了骨架。之後不管你是要在新 repo 內跑 specify init，還是回頭更新既有專案的 .specify/ 基礎檔案，至少路是清楚的。
而如果你讀完這篇，發現自己其實更想深入 PowerShell 7 本身，例如版本差異、Profile Hijacking、更多現代運算子與 shell 思維，那就很適合接著看同標籤的〈PowerShell 7 全方位升級指南：環境建置、AI 設定與現代語法〉。這篇文章像是先把深夜裡要走的路燈一盞一盞點起來；那篇則比較像沿著那些燈，慢慢把每一個房間打開。
如果 CLI 真的卡住：改走 Release 壓縮檔手動更新
如果你遇到的不是 repo 本身壞掉，而是 CLI 語法、release tag，或本機安裝環境出了岔，那最務實的做法通常不是硬猜指令，而是直接回到 Spec Kit 官方 repository 與 release 頁面。先看 github/spec-kit，再打開 Releases 確認最新版本，例如 v0.8.5。如果你只是懷疑本文裡示範的 tag 已經舊了，先把命令中的版本號換成最新 release，再試一次，往往就夠了。
如果 CLI 還是跑不動，release 的壓縮檔仍然很有價值。它不一定是重裝 Python CLI 最乾淨的方法，但很適合拿來手動刷新 repo 內的 shared scaffold。若你真正需要的是完全離線的 CLI 安裝，官方 installation guide 裡的 wheel bundle / air-gapped 路線仍然比較正式；但若你此刻只是想把專案裡的 Spec Kit 骨架補回來，下面這個順序最實用：
- 到 release 頁面下載
Source code (zip)，解壓縮到一個暫存資料夾。 - 先備份你 repo 裡已經客製過的內容，特別是
.specify/memory/constitution.md、.specify/templates/、.specify/scripts/，以及你正在用的 agent 命令資料夾。 - 把解壓後的
templates/複製到.specify/templates/，再把解壓後的scripts/複製到.specify/scripts/。這一層最接近specify init --here --force平常會替你刷新的 shared scaffold。
Expand-Archive .\spec-kit-0.8.5.zip -DestinationPath .\spec-kit-0.8.5
New-Item -ItemType Directory -Force -Path .\.specify\templates, .\.specify\scripts | Out-Null
Copy-Item .\spec-kit-0.8.5\templates\* .\.specify\templates\ -Recurse -Force
Copy-Item .\spec-kit-0.8.5\scripts\* .\.specify\scripts\ -Recurse -Force
- 如果連 agent 命令檔也壞掉，就把解壓後的
templates/commands/當成來源，補回你現在使用的整合格式。以常見情境來說，Copilot 預設模式會讀.github/agents/speckit.<command>.agent.md，而且還要保留同名的.github/prompts/speckit.<command>.prompt.md；Claude 會讀.claude/commands/speckit.<command>.md；Gemini 會讀.gemini/commands/speckit.<command>.toml。 - 手動複製 command template 時，要記得把檔案裡原本指向
templates/與scripts/的路徑，改成.specify/templates/與.specify/scripts/。原因很簡單：release 壓縮檔裡放的是原始模板，不一定就是 editor 最後直接讀取的成品檔。 - 如果你用的是 Copilot，別漏掉
.prompt.md這一層。它本質上只是對應到同名 agent 的小型 frontmatter 檔；如果遺失，也可以手動用對應的agent: speckit.<command>補回來。 - 完成後重開 IDE / editor，重新檢查 agent 命令資料夾是否真的更新；若先前備份過 constitution，再把自己的版本覆蓋回去。
這條路是備援方案，不是第一順位。但當 release 已經往前走、文章裡固定的 tag 一時沒有同步，或你眼前的 CLI 就是不肯配合時，直接從 release 壓縮檔刷新 scaffold，通常是把 repo 先拉回正軌的最快方法。