Simon Martinelli - Lessons from Spec-driven Development - AI Native DevCon June 2026
三句話摘要
規範驅動開發（Specification-Driven Development）如何結合 AI 加速軟體交付，核心是用 SysML 用例與實體模型定義規範，讓 AI 精準生成程式碼。 規範驅動開發透過 SysML 用例與垂直模組化架構，讓 AI 從精確定義直接生成可靠程式碼，但成功的關鍵不在 AI 的聰明，而在於規範工程的紮實投入與架構設計的合理性。 SysML 用例優於用戶故事的精確性
重點整理
重點- 1
SysML 用例優於用戶故事的精確性
- 2
Ivar Jacobson 於 1987 年創建的 SysML 用例已歷經驗證，包含前置條件、主流程、備選流程、後置條件等結構化元素。相比模糊的用戶故事，用例定義明確且 AI 已能理解此格式，使規範既能滿足人類溝通需求，又能直接驅動程式碼生成。
- 3
自包含系統架構的必要性
- 4
傳統微服務易導致上下文爆炸（如 500 個微服務配 500 個微前端形成 N2M 關係），讓 AI 難以獲得足夠資訊進行程式碼生成。自包含系統將功能垂直整合——UI、業務邏輯、資料庫位於同一模組，讓 AI 能在有界上下文內精準工作。
- 5
技能（Skills）是程式碼品質的決定因素
- 6
不同技術堆棧（React+Spring Boot、Vaadin+Spring Boot、Angular+Quarkus）需要不同的程式碼生成策略。講者為 6 位客戶管理多組技能，避免在龐大 Prompt 中堆砌所有規則（ETH 研究表明系統提示越大幻覺越多），而是按需組合技能並持續迭代改進。
- 7
工作重心向規範工程前移
- 8
AI 自動化了實現層，導致時間成本從「寫程式碼」轉移到「定義規範」。講者在政府議會案例中，自己編寫程式碼花時間少，但需求工程師定義規範花時間反而更多，宣告開發工作的重心已徹底轉向需求工程。
實用技巧與重點
乾貨- 規範定義方式
- SysML 用例組成：前置條件、主要成功場景、備選流程、後置條件、API 規格
- 實體模型（Entity Model）或領域模型（Domain Model）
- 用例圖用 PlantUML 生成
- Markdown 格式詳細文字規範
- 架構與組織模式
- 自包含系統（Self-Contained Systems）—— 垂直模組化
- 主幹開發（Trunk-based Development）
- 持續流而非迭代迴圈
- 看板追蹤用例進度
- 持續審查而非 Pull Request 機制
- 團隊規模：每模組 1-2 人（原 5-7 人）
- 技術棧與工具
- Spring Pet Clinic（示範專案）
- Figma（UI 設計，可通過 MCP 伺服器整合與 AI 互動）
- arc42（架構文件格式）
- start.spring.io 或 CLI（初始專案建立，不交由 AI）
- MCP 伺服器（向量搜尋內部文件）
- Confluence、Jira（規範管理）
- 防護措施
- 不讓 AI 創建專案結構（浪費 token，易過時）
- Claude.md 與 Agents.md 應精簡（避免系統提示過大）
- 根據風險等級決定審查深度（訂單系統 > 庫存系統）
- 技能應與結果對應（生成程式碼方式與測試方式配合）
- 具體案例數據
- 瑞士鐵路公司：2000 年初即使用 SysML 用例成功溝通
- 保險公司現代化：500 微服務、500 微前端、N2M 關係
- 醫生名單用例實現時間：約 1.5 分鐘
- 政府議會商業案例管理系統：1 位開發人員 vs 2 位需求工程師（PoC 階段）
- 現代化專案：從 5-7 人團隊縮至 1-2 人／模組
結論
結論“規範驅動開發透過 SysML 用例與垂直模組化架構，讓 AI 從精確定義直接生成可靠程式碼，但成功的關鍵不在 AI 的聰明，而在於規範工程的紮實投入與架構設計的合理性。”
完整解析
詳細Simon Martinelli 從一個實際問題開場：他在瑞士運動俱樂部開發志工管理系統時，遇到音樂節也提出相同需求卻不同細節的情況。這個困境觸發他思考：如何系統化地讓 AI 參與軟體開發，而不只是讓 AI 胡亂補題。他的答案是「規範驅動開發」。
規範驅動開發的核心論點是：與其讓 AI 直接從自然語言產生程式碼，不如先用機器與人都能理解的中間語言——規範——來橋接。具體工具是 SysML 用例，這是 Ivar Jacobson 在 1987 年確立的標準。用例由前置條件、主流程、備選流程、後置條件組成，定義明確且已有 30 年歷史。相比模糊的用戶故事，用例更全面：一個用例通常對應多個用戶故事，用例包含邊界條件、異常處理、成功定義。AI 已被訓練理解此格式，人類也習慣用此方式溝通，因此規範一旦定義，就能成為機器與人的共同語言。
架構選擇對規範驅動開發的成功至關重要。Simon 警告傳統微服務架構的危害：他見過保險公司有 500 個微服務配 500 個微前端，導致前後端呈 N2M 關係，系統變成分散化的大泥球。此時 AI 無法獲得足夠上下文進行可靠的程式碼生成。解決方案是採用「自包含系統」（Self-Contained Systems）架構——將應用按業務功能垂直拆分，每個模組自行包含 UI、業務邏輯、資料庫，位於同一程式碼庫內。這樣每個模組上下文有限且完整，AI 能精準工作。在 ERP 現代化改造中，不同模組可使用不同技術棧（庫存系統用 Vaadin，訂單系統用 React），同時規範保持一致——證明規範的獨立性與可遷移性。
工作組織也隨之根本轉變。團隊規模從傳統的 5-7 人縮至每模組 1-2 人；開發節奏從兩週迭代改為持續流，用看板追蹤用例進度而非 Sprint；程式碼審查改為主幹開發配同儕審查。最關鍵的轉移是時間成本的重新分配：AI 解放了「實現」層，但「定義規範」的成本不變甚至上升。在政府議會的商業案例管理系統 PoC 中，Simon 一人編寫程式碼不到半天，但兩位需求工程師定義規範花的時間遠多得多。這宣告了軟體開發工作重心的徹底轉向——從技術實現能力轉向需求分析能力。規範的長期價值在持續性：規範一旦確立，業務人員可直接修改 Markdown 規範而無需開發人員參與，系統可更換技術棧、改變 UI 形式（從網頁到聊天介面），實現真正的技術無關性。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
