こんにちは、とまだです。

大家有試過 AWS Kiro 的規格驅動開發（Spec-Driven Development）嗎？

規格驅動開發是「需求定義→設計→實現」的順序中，與 AI 協作推進的開發風格。

不過，Kiro 需要註冊等待名單才能使用，而且可用的模型也有限。

這次，我將實際使用這個規格驅動開發的國產工具「cc-sdd」，從導入到實踐都詳細解釋一遍。

忙碌人的摘要

• cc-sdd 是實現規格驅動開發的國產工具，使用 Claude Code
• 與 AWS Kiro 風格相容，完全支援日文
• 透過需求→設計→任務分解→實現的逐步審核流程提升質量
• 可透過單指令 npx cc-sdd@latest --lang ja 進行導入
• 在現有專案中也能順利導入
• 亦可支援 Cursor IDE 和 Gemini CLI

影片中也有解說喔！

什麼是規格驅動開發（Spec-Driven Development）？

傳統開發模式的挑戰

大家在用 Claude Code 開發時，都是以什麼樣的風格進行的呢？

隨意進行 vibe coding 時，是否在隨心所欲下實現，導致需求或完成品變得模糊的經驗呢？

因為 AI 的優秀性，當告訴它「暫時製作」時，AI 便會自行判斷並進行。

若其判斷符合專案方向還好，但 AI 並不總是理解所有的上下文。

結果，完成後可能會有「與預期不符」的情況。

這不僅浪費時間，還可能因為返工而降低動力。

規格驅動開發的流程

規格驅動開發按照以下順序進行：

1. 需求定義：明確該製作什麼
2. 設計：計畫如何製作
3. 實現計畫：分解為任務
4. 實現：實際撰寫代碼

這個流程的重點在於各階段彼此獨立。

在確定需求後再進行設計，設計完成後再分解任務，依此類推，必須在前一階段結束後再繼續下一步。

重要的是，每個階段都需人員進行審核。

有了這個審核流程，可以防止 AI 獨斷行事，能夠準確反映人類的意圖。

因為 AI 無法隨意推進，因此事先的理想狀態（清晰條件）變得明確。

這樣一來，人類和 AI 均可進行不迷路的開發，有這樣的優勢。

此外，因為留存為規格書，事後回顧「為什麼會這樣實現」也變得容易。

cc-sdd 的特點

國產工具的強項

cc-sdd 是由日本開發者製作的工具。

它在設計時考慮了日本工程師的需求。

具體特點如下：

• 完全日文支持：文檔、指令、錯誤信息均為日文
• 隨時可用：不需要等候名單，通過 npm 一鍵導入
• 支持現有專案：透過 steering 功能瞭解現有代碼後開始

日文支持不僅僅是翻譯，還是自然的日文表達。

錯誤信息也清楚地說明了「問題是什麼，該如何解決」。

無需處理英文的錯誤信息翻譯工作。

因為是日本的開發者，所以文檔都支援日文。

在 Zenn 等技術平台上也開始出現興起的情況。

與 AWS Kiro 的比較

下面的表格總結了 AWS Kiro 與 cc-sdd 的差異。

透過比較各自的特點，可以明確其優勢。

cc-sdd 的顯著優點是可以立即開始使用。

無需註冊 Kiro 的等候名單，即可立即嘗試規格驅動開發。

此外，由於沒有對使用的 LLM 模型的限制，可以使用最新的 Claude 3.5 Sonnet 等自己喜歡的模型。

在好的意義上，二者相似。

能夠在不等待 Kiro 的情況下進行相似的開發，令人感到高興。

生成的規格書格式也與 Kiro 兼容，因此在將來過渡到 Kiro 時也會很順利。

一般公認的 Kiro 規格驅動開發流程也是一樣的，因此能夠毫無違和感地使用。

若曾閱讀過 Kiro 文件或文章的人，應該能立即理解。

安裝與初始設定

基本的安裝步驟

安裝十分簡單。

只需在專案的根目錄執行以下命令。

npx cc-sdd@latest --lang ja

此命令將默認安裝與 Claude Code 兼容的設定。

--lang ja 選項可啟用日文模式。

執行時的注意事項如下：

• 會出現 CLAUDE.md 的覆蓋確認，如果存在現有的 CLAUDE.md，建議備份。
• 默認支援 Claude Code，因此若要使用其他工具，需另外指定選項。

安裝完成後，所需的命令文件和設定文件將自動放置。

其他平台支持

cc-sdd 也支援除了 Claude Code 以外的 AI 工具。

透過為各工具指定合適的選項，將安裝適當的設置。

# Cursor IDE 用
npx cc-sdd@latest --cursor --lang ja

# Gemini CLI 用
npx cc-sdd@latest --gemini-cli --lang ja

# 自訂目錄指定
npx cc-sdd@latest --kiro-dir docs/specs

※雖然也有 Codex CLI 類似的自定義命令文件，但在 README 中沒有說明，所以省略。

使用 Cursor IDE 的人請指定 --cursor 選項。

使用 Gemini CLI 的人請指定 --gemini-cli 選項。

如果希望自訂規格書的保存位置，可以通過 --kiro-dir 選項來指定。

默認情況下會保存在 .kiro 目錄中，但可根據專案結構進行更改。

生成的文件結構

安裝後，專案中將新增以下的目錄結構。

.claude/
├── commands/
│   └── kiro/  # 存放斜線命令
docs/
├── steering/  # 專案上下文
│   ├── product.md  # 產品概要
│   ├── tech.md     # 技術信息
│   └── structure.md # 目錄結構
└── specs/     # 功能規格

每個目錄都有明確的角色。

• .claude/commands/kiro/：存放規格驅動開發用的斜線命令
• docs/steering/：保存專案整體的上下文信息
• docs/specs/：管理各功能的規格書

透過這個結構，規格書與代碼可以在同一個倉庫中進行管理。

使用 Git 進行版本管理也變得更加容易。

實踐：在現有專案中的開發流程

我實際上在個人正在開發的應用中使用了它。

實際的開發流程，將透過具體的指令和生成的文件來解釋。

這次，我將介紹在記錄身體狀況的應用中新增「預測接下來幾小時的身體狀況」功能的流程。

步驟1：Steering（專案理解）

首先，必須讓 AI 理解現有專案的整體畫面。

這稱為 Steering（舵導）階段。

/kiro:steering

執行此命令時，Claude Code 將分析現有的專案文件。

具體而言，它將讀取 README、package.json、tsconfig.json、目錄結構等等。

結果將掌握專案的整體畫面。

分析完成後，將自動生成以下三個文件。

• product.md：開發中的產品信息（功能、用戶價值、商業邏輯）
• tech.md：技術堆棧信息（框架、庫、架構）
• structure.md：目錄結構與文件配置

這些文件將成為未來開發中 AI 查閱的「專案記憶」。

生成的 product.md（部分）

讓我們來看一下實際生成的 product.md。

AI 精準理解了現有代碼和 README 中的產品本質。

# 產品概覽 - ADHD Body Check

## 產品概覽
ADHD Body Check 是一款專為 ADHD 使用者設計的簡易健康追蹤應用。
核心原則是 **在三秒內完成情緒記錄，並無認知負荷**。
應用擁有黑色背景與霓虹色調，以增強視覺衝擊力並適應感官需求。

## 核心功能
- **三秒情緒記錄**：簡單的表情符號情緒選擇 (😊😐😣)，並立即回饋慶祝效果
- **今日顏色條**：動態寬度的視覺化，顯示全天的情緒模式
- **每週模式網格**：顯示七天情緒模式的高級功能

有了此文件，在增加新功能時也能依照現有的設計思路來實現。

「三秒內操作完成」「零認知負荷」的設計理念變得明確。

當方向感迷失時，這也成為很好的回顧機會。

專案變得龐大時，容易忘記最初的理念。

若以這樣的方式文件化後，便能夠重新回到最初的思考。

步驟2：功能初始化

了解了專案後，開始撰寫新功能的規格。

/kiro:spec-init "在 forecast 標籤中顯示接下來幾小時的身體狀況預測功能"

這條命令的一大特點是接受模糊的要求。

上述範例中使用了「幾小時」這個模糊的表達，但沒有問題。

因為後面的階段會進行具體化。

一開始不需要撰寫完美的規格。

與 AI 討論後決定Optimal 的規格即可。

執行後，名為 docs/specs/forecast-mood-prediction/ 的目錄將被創建。

spec.json 文件會被生成。

步驟3：需求定義

功能概要確定後，進行具體的需求定義。

/kiro:spec-requirements forecast-mood-prediction

這條命令將引用現有代碼和 Steering 文件。

結果會生成詳細的需求定義書。

生成的需求定義書的特點是，「接受標準」被明確記載。

這樣可防止開發完成的定義變得模糊。

生成的 requirements.md（部分）

# 需求定義書

## 需求1: 顯示體能預測畫面
**目的:** 作為用戶，我希望在 Forecast 標籤中視覺地確認接下來幾小時的體能預測。
這樣可以幫助我制定未來的活動計劃。

#### 接受標準
1. 當用戶點擊 Forecast 標籤時，則 Forecast 應用應顯示接下來幾小時的體能預測畫面
2. 當預測畫面顯示時，則 Forecast 應用顯示從當前時間到活動時間結束（最多 8 小時）的時間預測
3. 如果用戶已設定活動時間，則 Forecast 應用僅顯示設定活動時間內的預測

何種情況下能算作通過的標準被明確定義。

這對開發者及審核者來說，都是判斷完成的重要依據。

需求定義書中還會記載數據不足時的對應、效能需求、錯誤處理等內容。

步驟4：設計

需求穩定後，進入技術設計階段。

/kiro:spec-design forecast-mood-prediction

這一階段的好處在於可以分析現有代碼的模式。

能夠避免重新發明輪子，生成合適的設計。

例如，如果已有現有的倉庫模式，它將相應提出設計建議。

命名規則和目錄結構也會與現有的一致。

能保持專案整體的一致性。

生成的 design.md（部分）

設計書中還包含系統架構的圖解。

# 技術設計書: 預測功能

## 2. 架構設計

### 2.1 系統整體圖

┌─────────────────────────────────────────────────────────────┐
│                    Forecast 標籤畫面                         │
│  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐  │
│  │ 下個時間預測    │  │ 幾小時預測     │  │ 信任度顯示  │  │
│  │ NextSlotPred.   │  │ HourlyForecast   │  │ Confidence   │  │
│  └─────────────────┘  └─────────────────┘  └──────────────┘  │
└─────────────────────────────────────────────────────────────┘
                           ↓ 數據要求
┌─────────────────────────────────────────────────────────────┐
│                 ForecastRepository                          │
│  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐  │
│  │ 預測算法        │  │ 模式解析        │  │ 信任度計算  │  │
│  │ PredictionCore  │  │ PatternAnalysis  │  │ Confidence   │  │
│  └─────────────────┘  └─────────────────┘  └──────────────┘  │
└─────────────────────────────────────────────────────────────┘

包含了算法設計。

使用加權平均的預測邏輯設計，已利用現有的 yabaDetection 功能。

## 預測算法
// 主預測函數
static async generatePrediction(targetHour: number): Promise<PredictedMood | null> {
    // 加權預測計算
    const weights = {
      weekly: 0.4,    // 每週模式
      hourly: 0.3,    // 時段傾向
      recent: 0.3     // 近期趨勢
    };

有了這個設計書，實施者能順利推進開發。

步驟5：任務分解

設計完成後，將其分解為可實現的單位任務。

/kiro:spec-tasks forecast-mood-prediction

生成與 AWS Kiro 相似的任務表。

這是一個清單格式，方便進行進度管理。

生成的 tasks.md（部分）

# 實現計劃
- [ ] 1. 實現數據訪問基礎設施和預測算法
- [x] 1.1 創建預測功能所需的類型定義
  - 定義預測結果、每小時的預測和模式分析結果的類型
  - 創建設定值和信任度計算的介面
  - _Requirements: 要求2, 要求3, 要求4_
- [x] 1.2 建立預測數據訪問層
  - 實現 MoodRecordRepository 利用的過去數據獲取功能
  - 建立按時間段查詢歷史數據的功能
  - _Requirements: 要求2, 要求5_

每個任務都包含以下信息。

• 有勾選的任務列表（進度管理）
• 具體的實現內容說明
• 對應的需求編號（確保可追溯性）

以能夠逐步實現（在確認動作的同時進行）的方式，考量依賴關係，合理安排順序。

對優化措施的安排也是實現性強的結構。

步驟6：實現

即將進入實現階段。

/kiro:spec-impl forecast-mood-prediction 1

數字指定任務編號。

可以逐步從任務1開始實施，也可以同時實施多個任務。

這條命令的特點在於，遵循 TDD（測試驅動開發）的形式進行。

首先寫測試，確保測試通過後進行實現的流程。

這樣生成的代碼質量會更高。

在實現時，參考設計書及任務列表來推進。

不會偏離規範。

步驟7：進度確認

在開發過程中，隨時都可以確認進度。

/kiro:spec-status forecast-mood-prediction

這條命令會進行可視化的進度顯示。

可以一目了然哪些階段已完成，哪些任務仍待完成。

將顯示各階段的審核狀況和任務的完成情況。

專案經理和團隊成員之間也能輕鬆地共享進度。

透過 spec.json 進行狀態管理

cc-sdd 的聰明之處在於，各階段的狀態是透過 spec.json 文件來管理的。

{
  "feature_name": "forecast-mood-prediction",
  "created_at": "2025-09-14T00:00:00Z",
  "updated_at": "2025-09-15T00:00:00Z",
  "language": "ja",
  "phase": "tasks-generated",
  "approvals": {
    "requirements": {
      "generated": true,
      "approved": true
    },
    "design": {
      "generated": true,
      "approved": true
    },
    "tasks": {
      "generated": true,
      "approved": true
    }
  },
  "ready_for_implementation": true
}

透過這個文件進行管理具有以下優點：

• 狀態持久化：即便 Claude Code 的會話中斷，也能知道進度到哪裡
• 審核管理：記錄各階段的審核狀況
• 團隊共享：透過 Git 管理，使得團隊成員共享進度

requirements、design、tasks 的狀態會以布林值記錄。

即便上下文重置後也能維持狀態。

使長期專案也能安心使用。

最佳實踐

推薦的使用方式

為了有效使用 cc-sdd，建議遵循以下最佳實踐。

• 始終在 Steering 階段理解專案：在現有專案中首次執行後，若有大變更即時更新
• 不跳過階段：遵循需求→設計→任務的順序以防止返工
• 定期確認進度：透過 /kiro:spec-status 了解狀態，避免迷失方向
• 重大變更後更新 Steering：若專案結構變更，再次執行以更新 AI 的理解

每次執行的命令都會顯示出來。

日文的顯示令人感到非常愉快。

即使是第一次使用的人，也能夠僅依照畫面的指示進行規格驅動開發。

實務上的應用想像

cc-sdd 所用的規格驅動開發不僅適合個人開發，也能在團隊開發中大放異彩。

• 和商業側或設計師進行需求審核：一起審查 requirements.md，避免認知差異
• 與技術領導一同進行技術設計審核：一同檢視 design.md，驗證架構的合理性
• 在 Git 中管理團隊開發：提交規格書並共享，透過拉請求進行審查
• 在日常 Scrum 中共享進度：共享 spec-status 的結果，早期發現阻礙

有了規格書，其他非工程師成員也能更容易了解開發狀況。

給初學者的訊息

AWS Kiro 中受到熱議的規格驅動開發。

如果覺得難度高但又想嘗試的人，不妨先從 CC-SDD 開始挑戰如何？

以下幾點讓初學者也可輕鬆上手：

• 用日文完全解決：無需閱讀英文文檔
• 顯示下一步指令：不會迷惘，不知道該做什麼
• 錯誤信息也為日文：即便出問題也容易處理
• 在現有專案中迅速開始：無需從零開始重建

最初可先從小功能試驗開始。

熟悉後再挑戰大型功能更為理想。

總結

透過使用 cc-sdd 的規格驅動開發，順利嘗試了新的功能開發。

我個人也希望在各種方面支援這個方便的工具。

對於等待 AWS Kiro 而無法自拔的人，或者對規格驅動開發感興趣的朋友，建議從 cc-sdd 開始探索吧！

希望大家能從小功能試驗中，感受到它的效果。

Claude Code 的相關文章

我還寫了其他有關 Claude Code 或 AI 驅動開發的文章，若有興趣可參考：

• SuperClaude 是什麼？Claude Code 的代碼質量改善 30% 的神工具完整指南！
• 【驗證】Claude Code vs Codex：做同樣應用並比較代碼質量
• 在 Claude Code 中自動化 E2E 測試！透過 Playwright MCP 實現對話型瀏覽器測試

原文出處：https://qiita.com/tomada/items/6a04114fc41d0b86ffee