魔改 claude-mem

發佈於 2026年2月6日約 6 分鐘閱讀3 views

文章朗讀

繁體中文

魔改 claude-mem

00:0000:00

當 SDD 遇上 TDD：為 Spec-Driven Development 補上測試這塊拼圖

SDD（Spec-Driven Development）是什麼

Spec-Driven Development 是 2025 年 AI 輔助軟體工程中最重要的新興實踐之一。它的核心理念是：規格（Specification）才是軟體開發的主要產物，程式碼只是從規格生成的輸出。

SDD 的標準生命週期：

spec-init — 初始化功能規格
spec-requirements — 產出結構化的需求文件（通常是 EARS 格式）
spec-design — 架構設計文件，包含系統結構圖
spec-tasks — 將設計分解為帶有依賴關係的實作任務
spec-impl — AI Agent 從規格生成程式碼

SDD 解決了一個真實的問題：讓 AI 從「有用的自動補全」變成「可追溯的開發夥伴」。每一行 AI 生成的程式碼都能追溯回版本化的規格文件，這對審計、合規和團隊協作意義重大。

但在實際研究多個 SDD 框架（cc-sdd、OpenSpec、Kiro）和權威分析（ThoughtWorks、Martin Fowler）後，我們發現一個共同的缺口：測試在 SDD 的標準流程中並沒有被定義為獨立的階段。測試被隱含在實作階段中，缺少系統性的測試規格、測試執行策略和測試品質把關。ThoughtWorks 在其分析中也坦承：「我們仍然需要高度確定性的 CI/CD 實踐來確保軟體品質」— 這暗示 SDD 本身並沒有完整解決品質保證的問題。

我們的 make-plan + do 組合拳是什麼

我們在 claude-mem 的 make-plan 和 do 兩個 Skill 基礎上做了擴展，目標是補上 SDD 缺少的測試維度，同時保留規格驅動的精神。

make-plan 的流程：

Phase -1A 需求清晰度檢查 — 如果需求模糊，自動引導進入 brainstorming 環節或請使用者補充細節
Phase -1B 風險評估 — 根據資料敏感度、影響範圍、可逆性、複雜度、現有測試覆蓋率五個維度，自動判定執行模式
Phase 0 文件探索 — 搜尋並閱讀相關文件和 API
Phase 0.5 測試基礎設施探索 — 發現專案的測試框架、命名慣例、工具鏈
每個實作階段 — 同時包含實作規格和測試規格，測試案例以 GIVEN/WHEN/THEN 格式定義
Test Plan Consolidation — 產出完整測試矩陣，包含跨階段整合測試和驗收場景

do 根據風險評估結果分為三種執行模式：

LIGHT 模式（低風險）— 逐模組實作後測試，流程最輕
STANDARD 模式（中風險）— 逐階段 TDD，先寫測試再實作，獨立的 Test Agent 執行驗證
FULL 模式（高風險）— 完整平行 TDD 流程，包含依賴分析、背景並行測試、test-tracker.md 追蹤檔案、人工檢閱門禁

兩者的關鍵差異

SDD 有完整的「從需求到程式碼」流程，但測試是隱含的。我們有完整的「從規格到測試到驗證」流程。

規格層面的差異：

SDD 產出 requirements.md、design.md、tasks.md — 聚焦在「建什麼」和「怎麼建」
我們的 make-plan 在每個實作階段強制包含 Test Specification — 除了定義「建什麼」，還定義「怎麼證明它是對的」
SDD 沒有測試基礎設施發現步驟，我們的 Phase 0.5 會自動偵測專案的測試框架和慣例

執行層面的差異：

SDD 的 spec-impl 由 Agent 直接從規格生成程式碼，測試是實作過程中順帶處理的
我們的 do 將實作和測試拆成兩個獨立角色：Implementation Agent 負責寫程式碼和測試檔案，Test Agent 負責執行測試和撰寫失敗診斷
Test Agent 是嚴格唯讀的 — 它只跑測試、記錄結果、分析失敗原因，絕不修改任何原始碼。這確保了寫程式碼的 Agent 和驗證程式碼的 Agent 之間存在認知隔離

失敗處理的差異：

SDD 沒有定義測試失敗後的標準處理流程
我們的流程中，Test Agent 對每個失敗的測試記錄完整的診斷：錯在哪個檔案的哪一行、為什麼錯、建議怎麼改。所有失敗彙整後交由人工檢閱，人工決定修復策略後才由專門的 Fix Agent 逐一修復

追蹤與產物的差異：

SDD 的產物是規格文件和程式碼
我們額外產出 test-tracker.md（記錄每個測試案例在每個階段的狀態變化）和 test-report.md（最終測試報告，含合規矩陣和修復歷史），這些文件隨程式碼一起提交，成為可追溯的品質證據

結論：在規格驅動的基礎上，把測試變成一級公民

SDD 建立了一條從需求到程式碼的結構化管道，讓 AI 生成的每一行程式碼都能追溯回版本化的規格。我們的架構包含了這個核心理念，並在它的基礎上將測試從隱含步驟提升為獨立的一級流程 —
測試規格與實作規格並行產出、獨立的唯讀 Test Agent 執行驗證、持久化的追蹤紀錄記錄每個測試案例的生命週期。

SDD 保證了「程式碼可以追溯回規格」。我們進一步保證了「程式碼行為符合規格」。

但必須誠實地說，這些額外的保障是有代價的。SDD 的流程清晰簡潔 — 五個步驟，直線推進，AI Agent 容易正確執行。我們的流程加入了風險評估、測試基礎設施發現、TDD
循環、角色分離、背景平行測試、人工檢閱門禁，整體複雜度高出許多。一個更完美但更難正確執行的流程，不一定比一個簡單但穩定的流程更好。

這也是我們設計風險自適應模式的原因。在計劃階段，系統會根據資料敏感度、影響範圍、可逆性、複雜度、現有測試覆蓋率五個維度自動評估風險等級，然後選擇對應的執行強度：

LIGHT 模式（低風險）— 接近 SDD 的原始簡潔度。逐模組實作完成後生成測試、執行一次、回報結果。沒有額外的角色分離，沒有追蹤檔案。適用於內部工具、原型、一次性腳本
STANDARD 模式（中風險）— 逐階段 TDD。先從規格寫測試，再寫實作，由獨立的唯讀 Test Agent 執行驗證。失敗時呈報人工決定。沒有背景平行測試，沒有追蹤檔案。適用於一般功能開發、非關鍵 API
FULL 模式（高風險）— 完整流程。依賴分析後獨立任務的測試在背景平行執行，test-tracker.md 記錄每個測試案例的完整生命週期，所有失敗彙整後經人工檢閱門禁，Fix Agent 逐一修復，最終產出 test-report.md 作為品質證據。適用於核心 API、資料處理管線、認證系統、金流相關功能

低風險任務用最輕的流程，只有在高風險場景才啟動全部機制，避免為了品質而犧牲所有的效率。使用者也可以隨時覆蓋系統的判斷 — 如果系統判定 LIGHT 但你覺得應該用 FULL，你的選擇永遠優先。

#SDD #TDD #claude-mem #let time tell

留言

留言載入中...

魔改 claude-mem

<span className="text-emerald-500"> 當 SDD 遇上 TDD：為 Spec-Driven Development 補上測試這塊拼圖 </span>

<span className="text-accent">我們的 make-plan + do 組合拳是什麼</span>

<span className="text-sky-500">兩者的關鍵差異</span>

<span className="text-amber-500">結論：在規格驅動的基礎上，把測試變成一級公民</span>

留言