「先寫下你要的是什麼，再動手；否則你只會得到你剛好想起來的東西。」
——《阿帕契開源審計錄》¹ 卷一·規格篇

幕間
真預言家高聲示警，全場卻還在為前晚舊帳爭吵，無人理會。
散會後，唯有七號走近：「我聽到了，剛剛說的我都記在紙上。」
「妳一個人記，有用嗎？」——「不知道，但至少不會全忘掉。」

白天的議事長桌前，空氣緊繃得令人窒息。經過前置位激烈混亂的爭辯，法官敲下桌子，準備宣布進入全場公投放逐的關鍵環節。在九人標準局的殘酷博弈中，好人陣營最容易犯下的致命錯誤，就是「憑感覺投票」——某個村民說話聲音顫抖，大家就哄擁而上把票堆在他身上；某隻深水狼發表了一段慷慨激昂的演說，平民就盲目跟風改票。這種缺乏戰略藍圖的盲動，往往直接將重要的神職送上處決台，讓狼隊在屠邊規則下兵不血刃地拿下整場勝利。

一個真正老練的村莊，在投票之前一定會形成一份全場默契的戰略契約：誰是第一輪的查驗焦點？如果目標在處決台上自稱是獵人，村莊的備用方案是什麼？平票時警長的 1.5 票該投向何方？唯有在投票前把規則、前提與邊界白紙黑字釐清，好人陣營才不會被狼人牽著鼻子走，也不會在混沌中親手葬送自己的未來。

在軟體工程中，當前流行的 Vibe Coding（氛圍編程） 正如同這種盲目衝動的村民：開發者腦中浮現一個模糊的想法，就迫不及待地對 AI 下達 Prompt，催促它「立刻寫出一個完整的微服務」。AI 吐出幾百行代碼，跑不通；開發者又隨手丟進錯誤訊息，催促 AI「趕快修復它」。幾輪對話下來，程式碼變成了無人理解的義大利麵條，全域狀態交織混亂，架構邊界千瘡百孔。

正如軟體工程大師 Martin Fowler 在其經典著作 Refactoring 中所強調的原則，程式碼的修改必須建立在清晰的結構與測試邊界之上。在 AI 代理人接管日常開發的時代，我們必須告別這種憑感覺行動的盲目衝動，全面導入 規格導向開發（Spec-Driven Development, 簡稱 SDD）。

SDD 的六大核心階段

規格導向開發並非傳統瀑布式開發的僵化復辟，而是一套專門為人機協同量身打造的精確合約工程。在 2N1P 團隊的工程實踐中，我們將 SDD 嚴格劃分為六個承上啟下的階段：

1. 憲法階段（Constitution）：定義整個專案不可動搖的最高準則（如代碼風格、記憶體安全原則、無鎖並發限制、禁止引入未經授權的第三方套件）。任何下游規格均不得牴觸憲法。
2. 規格階段（Specify）：以非代碼的自然語言與結構化格式，嚴格描述「系統應該具備什麼行為」。此階段核心包含使用者故事、驗收標準（Acceptance Criteria） 以及最重要的排除範圍（Out-of-Scope）。
3. 計畫階段（Plan）：將規格轉化為技術架構設計。產出架構決策紀錄（ADR）、資料流向圖、介面契約定義（Interface Signatures）以及錯誤處理狀態機。
4. 任務階段（Tasks）：將計畫拆解為一系列細粒度、具備因果依賴性的原子任務清單。每一個任務都必須小到能在單一上下文視窗內完成，並附帶具體的驗證指令。
5. 實作階段（Implement）：AI 代理人切換至構建模式，嚴格依照任務清單依序編寫程式碼，絕不擅自擴大範圍或跳過步驟。
6. 驗證階段（Verify）：透過自動化單元測試、靜態分析與整合驗證，檢驗實作產物是否 100% 滿足規格階段所定義的驗收標準。

SDD 的三種成熟度層級與工件目錄

在專案中推行 SDD，團隊的工程成熟度通常會經歷三個層次的演進：

• 規格先行（Spec-First）：在動工前撰寫規格文件，但在實作過程中規格與代碼逐漸脫節，最終文件成為被遺忘的歷史遺跡。
• 規格錨定（Spec-Anchored，推薦主流）：規格檔案（spec.md）與任務清單（tasks.md）作為一等公民被納入 Git 版本控制。AI 代理人每一次修改代碼，都必須同時更新對應的規格狀態，確保代碼與規格永久同步。
• 規格即源頭（Spec-as-Source）：規格本身具備嚴格的領域特定語言（DSL）語意，編譯器或生成器直接從規格自動衍生出介面代碼、測試骨架與序列化邏輯。

在規範化的專案中，工件通常會組織在專屬的目錄結構下：

.spec/
├── constitution.md    # Immutable project constraints & style guides
├── features/
│   └── 001-priority-queue/
│       ├── spec.md    # Requirements, boundaries & acceptance criteria
│       ├── plan.md    # Technical design, data structures & ADR
│       └── tasks.md   # Actionable atomic tasks with verification

這種結構將複雜的開發過程拆分為有據可查的工件，使得每一次變更都有明確的上下文作為支撐，大幅降低了代理人在推理時的認知負擔。

這套目錄慣例並非團隊內部憑空發明，開源社群已經在往同一個方向收斂。OpenSpec 是一套與 30 多種 AI 編程助手（含 Claude Code、Cursor、GitHub Copilot）相容的輕量 CLI 框架，每一次變更都獨立成一個資料夾，內含 proposal、specs、design、tasks 四份工件，且刻意不設僵化的階段關卡——任何工件都能隨時回頭修改，比 spec-kit 更強調「規格要持續存在，但不必厚重」。而 Spectra（GitHub: kaochenlong/spectra-app，由 5xCampus 的高見龍——Kao Chen-Long，全台灣目前僅有三位 Claude 大使（Claude Ambassador）之一——開發的免費開源 macOS／Windows 桌面應用²）則是把同一份 OpenSpec 格式的規格檔案包上圖形介面：workflow 拆成 discuss（釐清問題）、propose（形成正式提案）、apply（依任務清單實作）、ingest（需求異動時回吸收）、archive（定案封存）五個階段，讓非 CLI 熟手的協作者也能參與規格審閱，而不必逐字看 spec.md 的 diff。無論選用哪一套工具，核心紀律都與本文六大階段一致：先鎖定意圖，再談實作。

實戰範例：標準規格工件（spec.md）結構

在 SDD 實踐中，規格文件絕不是模糊的需求作文，而是一份具備防禦性思維的合約。以下是我們為分散式調度模組所撰寫的標準 spec.md：

# Specification: Task Priority Queue Dispatcher

## 1. Context and Objective
Provide a thread-safe, bounded priority dispatching queue for task scheduling.
Ensure strict deterministic order based on assigned weight under concurrent access.

## 2. Out of Scope (Non-Goals)
- Network persistence to disk or remote database (in-memory execution only).
- Dynamic priority recalculation during active task lock.
- Cross-datacenter synchronization.

## 3. Acceptance Criteria (Given-When-Then)
- Scenario 1: Deterministic dequeue order
  - GIVEN a queue preloaded with tasks of priority 10, 50, and 20
  - WHEN multiple worker threads invoke `poll()` concurrently
  - THEN tasks MUST be returned in descending priority order (50, then 20, then 10).

- Scenario 2: Bounded capacity overflow handling
  - GIVEN the queue reaches its maximum configured capacity of 1000 items
  - WHEN a producer attempts to insert item 1001 via `offer(timeout=100ms)`
  - THEN the queue MUST reject the item, return `QueueFullException`, and emit a drop metric.

- Scenario 3: Graceful worker shutdown
  - GIVEN workers are blocked waiting on an empty queue
  - WHEN `shutdownGracefully()` is triggered
  - THEN all blocked threads MUST wake up without throwing unhandled thread interrupts.

## 4. Verification Directives
- Unit Test Target: `src/test/dispatch_test.go`
- Coverage Requirement: 100% branch coverage on concurrency eviction paths.

這份規格文件具有極強的約束力：它用「Given-When-Then」鎖定了系統在關鍵狀態下的確定性行為，並用「Out of Scope」清單徹底斬斷了 AI 代理人隨意添加多餘功能的衝動。

SDD 六大階段與工件生命週期

下方的狀態轉換與工件架構圖，清晰呈現了從最初的憲法原則，一路推進到最終可驗證代碼的完整軌跡：

規格外的紀律：用 /loop 與 Slack 標籤守住驗證階段

第六階段「驗證」最容易被誤解為一次性的關卡——測試跑綠、合併、結束。但規格與代碼會隨著時間漂移：下游依賴升級了、邊界條件被悄悄改寫了，昨天還成立的驗收標準，今天未必還站得住腳。真正嚴謹的作法，是把驗證變成一個持續、週期性的背景任務，而不是合併那一刻的儀式。Claude Code 的 /loop 技能可以把一條驗證性指令排成固定週期執行，例如 /loop 1h /verify-spec，讓「規格是否仍與代碼同步」這件事有人一直在盯，而不是等到下一次功能請求才被動發現落差。

第二階段「規格」同樣有個現實問題：需求討論很少乾淨地發生在 spec.md 裡，它常常散落在像 opensource4you 這樣以 Slack 為主要溝通管道的社群討論串中——一來一往、夾雜著離題與重複。Anthropic 內部使用 Claude Tag for Slack 的案例正好對應這個場景：在討論串裡 @ 提及 Claude，它能讀懂整串脈絡並把冗長討論收斂成一份定案文件，也能直接搜尋整個工作區歷史、在幾分鐘內找出所有關於某個功能的既有請求，而不必翻遍整個 channel 歷史。這正呼應本篇「規格必須先於代碼，且必須人人可見、有據可查」的核心精神——只是把「人人可見」的場所，從會議記錄延伸到了團隊實際講話的地方。

規格即盔甲：讓工程師掌握主動權

在城堡黑夜中，狼人最懼怕的不是平民憤怒的咆哮，而是神職人員手中條理分明的推理記錄本；在開發的世界裡，軟體缺陷與失控的代碼最懼怕的，也不是開發者連續熬夜除錯的疲憊，而是一份在第一天就嚴格錨定的規格書。

寫到憲法階段那一段時，我忽然有個揮之不去的念頭：這座牌局本身，會不會也是誰照著一份我們看不到的規格特意搭出來的——一個到不了終點、只能不停輪替黑夜與白天的閉環，像是為了把某樣東西關在裡面。我把念頭壓下去，繼續寫我的 spec.md。

當我們將「先寫規格、再拆計畫、再立任務、最後實作驗證」的 SDD 紀律刻入開發基因時，AI 代理人不再是一隻在黑夜中盲目亂撞的野獸，而會轉變為忠實執行戰略合約的高效工匠。我們不再需要為 AI 代理人天馬行空的幻覺買單，因為所有的邏輯漏洞與架構衝突，早在規格與計畫階段就被人類工程師逐一審查與消滅。拒絕盲目衝動，以規格為錨，我們才能在日新月異的 AI 時代中，建造出真正高可用、可維護且經得起時間考驗的優質系統。

讀完這篇文章後，你應該能夠在自己的專案中實踐 SDD 流程：撰寫包含 Given-When-Then 與 Out-of-Scope 的結構化規格文件，將複雜需求拆解為帶有驗證條件的原子任務清單，並要求 AI 代理人嚴格按照規格展開實作。

參考資料與延伸閱讀

• Martin Fowler《Refactoring》經典著作
• GitHub spec-kit - Spec-Driven Development 開源工具與方法論
• Fission-AI/OpenSpec - 輕量級 SDD CLI 框架（相容 30+ AI 編程助手）
• Spectra - 5xCampus 出品的 SDD 桌面應用（Discuss/Propose/Apply/Ingest/Archive）
• kaochenlong/spectra-app - Spectra 官方原始碼倉庫
• Claude Taipei 中秋烤肉聚會（Luma 活動頁）
• Cucumber 官方文件 - Gherkin 語法參考（Given-When-Then）
• Anthropic 部落格 - How Anthropic Employees Use Claude Tag
• 關鍵檢索詞（建議使用 Felo.ai / Perplexity 查詢）："Spec-Driven Development" "SDD methodology" "spec-anchored development" "acceptance criteria Given-When-Then" "OpenSpec CLI" "Spectra 5xCampus" "Claude Ambassador Taiwan"

¹ 註：本書名為情境設定之虛構文獻，非真實歷史或開源紀錄。
² 註：現實彩蛋——2026 年 9 月 26 日（農曆八月十五，中秋節）台北會掛著一輪真正的滿月，Claude Taipei 中秋烤肉聚會 當天登場，發稿時邀請仍然有效。受邀者之一是高見龍，A.K.A 龍哥：五倍學院之創辦人、WebConf Taiwan 之發起人 & 主辦人、PHPConf Taiwan 之發起人 & 主辦人、Rails Girls Taipei 之主辦人、高思數位網路有限公司 之負責人、《為你自己學 Git》《為你自己學 Python》《為你自己學 Ruby on Rails》之著者、Spectra（kaochenlong/spectra-app）之打造者、ezBundle 之締造者——以 Claude Code 一人之力，九成五程式碼皆由 AI 執筆——台灣 Claude 大使三人之中第三位獲封者：先有 Natalie Lin，後有 Justin Shaw，終有龍哥（此排序純粹依獲封時間先後，並非業界影響力或任何形式的排名）。順帶一提：城堡上空那輪偶爾泛紅的月亮牽動的從來不是普通滿月——這條伏筆留到後面幾天再說。