規格驅動的 AI 強化 DevOps

篩選適合的情境，SDD 成為你的平台開發神器

Che-Chia Chang

公司有做 DevOps Platform Engineering 的舉手

DevOps 要求 Coding skill 的手放下

需要開發，但許多 DevOps 職缺並不要求 Coding skill 🤔

用 SDD 可以解部分的 DevOps 開發需求

本議程會告訴你

  1. 什麼是 Spec-kit，跑起來是什麼樣子
  2. SSD 為何適合 DevOps
  3. 適合導入的情境

關於我

平台工程需求

ex. 所有內部平台帳號定期稽核，確保沒有過期或離職的帳號存在

如果有工具直接用工具，不用閉門造車

需求不符合的話，現在閉門造車非常的快與便宜

後續維護是否好維護 🤔

實際 Spec-kit 會長怎樣

產生 Spec > 修 Spec 到滿意 > 產生 Plan > 拆成 Task

agent 根據 Task 實作，直到達成 Spec

# specify init --integration copilot

/speckit.specify    寫一個工具，列出所有內部平台帳號
                    1. 根據條件檢查帳號狀態權限
                    2. 有單元測試，模擬帳號整合測試

/speckit.plan       根據 Spec 產生 Plan，列出實作步驟，檢查相依性，準備 checklist
/speckit.tasks      拆成獨立子任務，可分配給 subagent...
/speckit.implement

What is Spec-kit

  • Spec-kit 是 GitHub 的 SDD toolkit
  • 是一個 SDD 流程框架
  • 不是 prompt 技巧，是可重複工程流程
  • 核心價值：把需求、驗收、交付串成同一條線
更多資訊與細節請參考
What is Spec-driven development
  • 模糊需求 > 可執行規格 Spec
  • Spec > Implementation
    • 能滿足 Spec 就是好的實作
  • Feedback > 修改 Spec > (loop)

Spec-kit 是 SDD 的工具，提供標準流程與格式

產出可驗證、可協作的規格。agent 根據規格實作

SDD vs Chat Coding
面向SDDChat Coding
方式先寫需求/設計，再實作先寫程式，邊聊邊修
短期較慢很快
長期通常更穩，返工少累積技術債後期變慢
一致性高，有明確規格看操作者，波動大
維護性高，文件、決策、邊界清楚中低，脈絡常散在聊天紀錄
協作好，可 review spec較難，知識偏個人化
風險好，先定義約束與測試較弱，容易漏邊界條件
適合中大型專案、多人協作PoC、腳本、小功能

SSD 為何適合 DevOps

任務驗收標準明確，流程固定，重複性高

  • SOP/Runbook 步驟完成率 -> %
  • CI/CD Pipeline / 工具串接成功率 -> %

完成步驟就達成需求，這類任務非常適合 SDD

因為驗收標準明確，流程固定

llm 產出是一個機率分布

需要釐清規格，邊界條件寫清楚，agent 實作結果才會收斂

未來改需求，甚至產生矛盾的需求，會讓 agent 產出偏離預期

Drift (Context Drift)

找到第一個適合的任務

  • 人工例行事務
  • 固定流程/SOP/Runbook
  • 低風險
  • 沒有被其他服務依賴

實際導入流程

  • 挑題目：低風險，高人工，需求清楚
  • 規格化：Spec-kit 需求寫成 Spec，確定驗收標準
  • 拆任務：Spec-kit Spec -> Plan -> Task
  • 實作：Task 已定義驗收條件，agent 會努力達成
情境分享：所有內部平台帳號定期稽核
  • ✅挑題目
  • 規格化
    • 平台列表 aws, github, jenkins…
    • /user /permission api 規格
  • 驗收標準
    • 測試：單元測試，模擬帳號整合測試
    • 結果：帳號總數，帳號權限，違反條件的帳號數量
    • 格式：符合稽核格式
情境分享：所有內部平台帳號定期稽核
  • ✅挑題目
  • ✅規格化
  • ✅驗收標準
  • 拆任務：agent 準備平台 task，檢查相依性與 checklist
  • 實作：發包 subagent 負責一個平台，平行實作
  • 成果：人類做到很痛苦 -> 變成全自動化

其他情境分享

  • 除錯 Runbook：在多個內部維服務上來回收集資訊，分析問題
  • 服務的 sidecar：提供業務邏輯的 API，讓 ops 對服務進行操作，或提供額外功能

Spec-kit 帶來的痛點

  • 工作習慣改變
    • 痛點左移，寫扣時的痛苦提前到寫需求時
  • Spec-kit tax：Spec-kit 產生 Spec，會消耗額外 token
    • 用貴模型寫 Spec，便宜模型實作，降低成本
  • 不適合舊專案：Greenfield vs. Brownfield
    • 無法從舊程式碼逆向產生 Spec
    • 從頭寫 Spec，燒時間跟token

改需求的成本變高

  • Spec 寫好 Code，結果改需求，改 Spec、Plan、Task，agent 也要重跑
  • 小改動可以像 git commit 一樣，疊上去 Spec
  • 大改動或需求矛盾，就要重寫 Spec
    • Spec-kit 會幫你掃出 conflict，但不會幫你解決
    • Code 都不能用，要重零開始
  • 需求變動頻繁的任務不適合 Spec-kit，反而會變得笨重

Spec-kit 的盡頭是組合拳

  • 新功能新 pkg 用 Spec-kit 開發
  • 舊專案舊 pkg：補 Test 保護既有功能，再疊 Spec 上去
  • 卡住的半成品重新分析問題，重寫 Spec，讓 agent 從頭實作
  • 關鍵 pkg 重構，用 Spec-kit 把舊 Code 當成 Spec reference，全部重寫成 v2

其實是在用各種方法，捕捉虛幻的 Spec 讓他落地

這不是 Best Practice，而是 Working Practice

你可以帶走的重點

  • DevOps 任務，許多已有明確的 Spec
  • 選對題目：高人工、低風險，跨平台，被依賴性低的任務
  • 從 vibe/chat coding 走向 Spec-kit
    • 標準化流程，分工協作

Speckit 不是終點，同志仍須努力

Q&A 不是演講的終點

下週 Cloud Summit 會有一場 Workshop，會帶大家實際操作 Spec-kit，歡迎來玩！

Thank you.