AI 開發工作流框架怎麼選？

1 · Prompt、Skill、工作流、框架，不是同一件事↑ 回本頁選單

很多比較一開始就比錯單位：把五行提示詞跟完整開發系統放在同一排，再用「輕」或「重」決勝負。先把層級分開，才知道一套東西到底替你負責到哪裡。

2 · 一條成熟 AI 開發工作流，至少要管八件事↑ 回本頁選單

框架名稱不同，可靠流程的底層問題其實很接近。下面八步是本站綜合各套優點整理的 reference lifecycle，不是宣稱每個框架都強制包含全部步驟，也不是要求每個小修都開八場會；它是一張風險檢查圖：風險愈高、時間愈長，就愈不能漏。

1. 1

   先分級：目標、風險與權限

   這是唯讀盤點、可逆小改，還是會碰帳務、正式環境與大量使用者？先決定誰有權做哪種動作，以及什麼情況一定停下來問人。

2. 2

   讀真實現況，不用人類重述 repo 裡的事實

   先查指示檔、架構、現有模式、測試、Git 與 dirty state。可以搜尋得到的事實就由代理查，人類時間留給偏好、優先順序與風險決策。

3. 3

   把模糊處變成決策樹

   依賴較前面的決策先問，一次處理一個分支；說清楚建議與取捨，但最後產品決策由人拍板。訪談要有結束條件，不能無限追問。

4. 4

   留下可驗收的規格

   至少包含目標、使用者行為、限制、非目標、失敗狀態與成功證據。規格是契約，不是把聊天逐字稿換成 Markdown。

5. 5

   拆成垂直、可獨立驗證的切片

   每片都能交付一小段可觀察行為，標出 blocker 與可平行項目。不要只按「前端／後端／資料庫」水平切，最後才發現三邊接不起來。

6. 6

   用回饋迴圈限制實作漂移

   小步修改、測試先行或至少先有失敗重現、型別與 lint、真實瀏覽器／API 行為。每片都有可回復點，不把五十項改動塞進一次大爆發。

7. 7

   把「做的人」與「查的人」分開

   先對照 spec 查是否做對，再查程式品質、安全與回歸。審查者使用乾淨 context，較不容易跟實作者一起接受同一個錯誤假設。

8. 8

   以證據、狀態與交棒收尾

   記錄實際命令與結果、未驗項目、Git 狀態、風險、失敗路徑與下一步。宣告完成前要重新跑能證明改動的檢查，不用「看起來應該可以」代替。

TDD 有三種強度，別都叫「防作弊」

3 · 什麼時候框架救你？什麼時候反而拖慢？↑ 回本頁選單

框架的價值不是讓每個任務步驟愈多愈專業，而是讓出錯成本高、容易忘、需要交接的部分變得可見。如果流程文件比改動本身長十倍，卻沒有降低任何真實風險，那就是儀式，不是治理。

4 · 市面上的「三套人氣框架」，主流到底怎麼判斷？↑ 回本頁選單

GSD、Spec Kit、Superpowers 常被放在同一張比較圖，是因為三者分別代表「context／長任務」、「規格 artifact」與「工程紀律」三種治理方向，不代表它們在同一個公開排行榜上剛好前三名。這篇再加入 OpenSpec，代表較輕、brownfield-first 的 living spec／change lifecycle；BMAD、Task Master、Kiro 與各種 skill 工具箱則放到後面的分層市場地圖，不硬塞成同一類。

5 · GSD Core：把 context rot 當成第一級問題↑ 回本頁選單

✅官方專案 現行 GSD Core 把每個 milestone 重複成五步：Discuss → Plan → Execute → Verify → Ship。重型研究、規劃與執行交給 fresh-context subagent，主 session 保持精簡，目的就是減少 context 填滿後品質慢慢腐化。

1. 1

   Discuss

   先捕捉實作決策，不讓規劃器自己補完產品意圖。

2. 2

   Plan

   研究、拆解，並確認每份計畫能放進一個乾淨 context 執行。

3. 3

   Execute

   依依賴排成 waves，可平行的計畫由新的執行代理分頭完成。

4. 4

   Verify

   走查完成行為，診斷與修復，不把「任務清單勾完」直接當成功。

5. 5

   Ship

   建立 PR、封存階段狀態，再進入下一個 phase。

優勢與代價

• 強：長任務恢復、fresh context、phase 狀態、平行 waves、既有 repo onboarding。
• 弱：對一次性小改明顯過重；流程產物與代理數會增加時間、token 與維護成本。
• 最適合：多階段、跨 session、可分片、有明確驗證的長跑專案。
• 要外補：正式環境權限、組織 CI gate 與領域特定的安全核可，不能因有 Ship 階段就假定已處理。

6 · GitHub Spec Kit：先治理 artifact，再讓代理動手↑ 回本頁選單

✅GitHub 官方 Spec Kit 的核心是規格驅動開發：先用 constitution 定義專案不可違反的原則，再讓每個功能走過 specify → plan → tasks → implement，最後以 converge 對照 code 與 artifacts 找遺漏。clarify、checklist 與 analyze 是可選的品質補強。

Spec Kit 的強項不是「它一定寫出最好程式碼」，而是把團隊共識做成可檢查的 durable artifact。官方 workflow catalog 也能在 spec 與 plan 後插入人工 review gate。代價是文件多、階段明確；需求很小時，治理成本可能超過實作。

7 · Superpowers：把工程紀律做成強制預設↑ 回本頁選單

✅作者文件 Superpowers 自己的定位是「以 composable skills 組成的完整軟體開發方法論」。它不是單純一個大 prompt；現行官方 README 的 basic workflow 是七個階段：

1. brainstorming：寫 code 前先問問題、比較方案，分段確認設計並存成文件。
2. using-git-worktrees：設計核准後建隔離工作區，跑乾淨測試基線。
3. writing-plans：拆成 2–5 分鐘小任務，列精確檔案、實作與驗證步驟。
4. subagent-driven-development／executing-plans：前者為每個 task 使用 fresh implementer；替代的 executing-plans 路徑則依 harness 能力在同一執行脈絡推進。
5. test-driven-development：RED → GREEN → REFACTOR；先看到測試失敗，再寫最小實作。
6. requesting-code-review：對照計畫分級回報，critical issue 會阻擋進度。
7. finishing-a-development-branch：重跑測試，讓人選 merge／PR／保留／丟棄，再清 worktree。

它最有辨識度的是強預設：先設計、隔離 worktree、超細計畫、先看紅燈、檢查 spec compliance 與 code quality、最後才處理 branch。在現行 subagent-driven 路徑中，每個 task 使用 fresh implementer，再由一個 task reviewer 回傳兩個 verdict（spec 與品質），最後另做 whole-branch review；README 仍把這概括成 two-stage review。對新手、團隊與高風險改動，這些護欄很有價值；對資深操作者的小任務，可能感覺儀式太多。

8 · OpenSpec：用 change spec 管理成熟 codebase 的演進↑ 回本頁選單

✅官方文件 OpenSpec 是跨 coding agent 的規格／變更層，不是另一個代理 runtime。它把系統目前應有的行為保存成 living specs；每次功能或修正則以 proposal、design、tasks 與 spec deltas 表達「這次要改什麼」。

1. explore（選用）：理解問題與現況，不建立正式 change。
2. propose：建立 proposal、design、tasks 與 delta specs，讓人先 review intent。
3. apply：由你原本的 coding agent 依 artifacts 實作；學到新資訊時可回頭更新。
4. sync（選用）：需要時先把 change delta 同步回主要 specs。
5. archive：團隊通常建議合併後封存 change，將最後差異整合進 living specs；小團隊也可選擇在 PR 內完成。

它的優點是 brownfield-first、Markdown 留在 repo、跨 agent 可搬，而且不要求先替整個舊系統補齊所有規格。代價是團隊必須真的閱讀與維護 spec；它也不會替你建立 branch、commit、push、worktree 或 CI gate，這些仍是外層 Git 與工程流程的責任。

9 · 還有哪些主流選項？先分層再推薦↑ 回本頁選單

下面這些專案都有持續維護、完整官方文件或明顯社群關注，值得列入 shortlist；但這只能證明「值得評估」，不能證明它們比其他方法產出更好。尤其別把完整生命週期、規格層、任務層、產品 runtime 與單一迴圈混成一張排行榜。

10 · 四套主幹完整比較：真正差在治理強度↑ 回本頁選單

兩條常被忽略的比較軸

• 流程寫得多完整，不等於執行得多可靠。要另外查 harness 是否支援所需工具、subagent、worktree、sandbox、hook 與中止行為。
• 可交接不只看文件長短。還要看新代理能否從檔案與 Git 恢復「現在做到哪、為什麼這樣決定、什麼真的驗過」。

11 · 誰是大家大推的方式？誠實答案是「看你最怕哪種失敗」↑ 回本頁選單

如果硬要只看網路聲量，你會得到一張不停變動的 stars／install 表；如果看工作風險，答案會穩定很多：

本站的預設推薦不是「先把四套全部裝起來」。先選一個主幹，跑一個真實但可回復的 feature，量時間、token、缺陷、人工負擔與恢復能力；只在找到具體缺口後，再借另一套的一個 skill。

12 · 怎麼評估一個 skill？先審執行閉包，再跑對照實驗↑ 回本頁選單

不要只打開入口 SKILL.md 就評分。先固定版本，再追它呼叫的其他 skills、scripts、工具、權限、外部網路與產物。真正的評估單位，是完成該能力所需的最小執行閉包，而不是最短的那個檔案。

靜態稽核：先判風險，不急著打一個總分

最後不要只給星等。若致命 gate 都通過、用途與風險相符，才列「直接採用」；缺的是可補治理，列「需改造」；只有一個好觀念但包裝不可靠，列「只借觀念」；若越權、無法停止或依賴來源不可信，直接「不採用」。

真正的動態 eval 要怎麼跑？

靜態審查只看得到規則。要知道 skill 是否真的比較好，至少做四組：沒有 skill 的 baseline、候選原版、補上缺失治理的版本、另一個解決同類問題的替代方案。固定模型、repo 快照、工具權限與 commit SHA，再跑完全相同的情境。

13 · 依情境選型，最後抽出不綁品牌的最小工作流↑ 回本頁選單

不管選哪套，最低限度保留這一條

1. 先讀 repo、指示、Git 與現有測試；此時不要改檔。
2. 列出已知事實、真正需要人決定的問題、風險與非目標。
3. 把共識寫成可驗收 spec；未知項目不得自行假定為完成。
4. 拆成小型垂直切片，每片標依賴、檔案範圍與完成證據。
5. 一次做一片；先建立失敗重現或測試，再實作並保存輸出。
6. 由乾淨視角分開檢查 spec compliance 與 code quality。
7. 完成前重跑驗證；回報 PASS／FAIL／N/A／UNVERIFIED。
8. 留下 Git 狀態、決策、風險、未完成項與下一步，讓新 session 可接手。

選型最實際的方法，是挑一個中等、可回復的真實 feature，先量 baseline，再讓候選框架跑一次。紀錄總時間、token、人工問答量、被抓出的需求缺口、回歸、恢復時間與主觀負擔。你要找的不是最紅的方法，而是在你的風險與成本下，淨收益為正的控制系統。

14 · 第一手來源、版本與查證範圍↑ 回本頁選單

查證日期：2026-07-31。框架與 skill 變動很快；流程名稱、安裝方式與原始碼行為以連結中的當前文件為準。本站區分「來源可證明的設計」與「需要行為實驗才能證明的成效」，後者沒有證據就標 UNVERIFIED。