When Not to Vibe

從 Chat-driven coding 到 Spec-driven AI Engineering

Che-Chia Chang

寫扣使用 coding agent 有標準流程嗎？

可以多人開發，驗證，協作

如果還沒有，通常是

  • 流程不固定
  • 產出品質不穩
  • 不知如何進行分工與驗證
今天只講一件事

如果 Chat-driven coding 是團隊目前的方式

Try Spec-driven coding 的標準化流程

本議程會告訴你

  1. Chat-driven coding 的邊界
  2. SDD 的核心概念
  3. Spec-kit 落地流程
  4. 何時切換與如何起步

關於我

Chat-driven coding 的價值

  • 快速探索，驗證想法，PoC
  • 在短週期任務，Chat-driven 很有價值

Chat-driven Coding 的挑戰

  • 輸出不穩定
  • 團隊協作難追蹤
  • 複雜需求 + 多輪對話，容易產生 long context
user: 幫我做一個功能，需求是...
user: 修這個錯誤
user: 新的需求...
user: 剛剛沒想到，現在改成這樣...
long context 可能造成 LLM 效能下降
# https://www.alphaxiv.org/abs/2404.06654v3
┌───────┬─────────────┬──────────────┬───────────────┬─────────────────┐
│ Model │ 4K Accuracy │ 32K Accuracy │ 128K Accuracy │ Claimed Context │
├───────┼─────────────┼──────────────┼───────────────┼─────────────────┤
│ GPT-4 │       ~90%+ │        ~85%+ │          ~75% │            128K │
└───────┴─────────────┴──────────────┴───────────────┴─────────────────┘
Chat-driven Coding 的挑戰總結

實務上應盡力控制 context

  • Spec-kit 流程（specify, plan, tasks）實際上是不斷整理 context 的過程
  • 有完整 spec 實作時對於模型的能力要求不高
  • 用 mini 就能達到 90% 效果，因此成本也大幅降低

Chat-driven Coding vs SDD

假設需求寫出來是十萬字

  • Chat-driven 是透過多輪對話，一萬字分散一段一段給模型
  • SDD 是 Plan 時把一萬字整理一個結構化的 Spec
    • 實作時讓模型一次讀進結構化的 Spec

When Not to Chat-driven

當任務符合以下條件

  • 有明確規格或可定義規格
  • 需要可驗證交付品質
  • 需要多人分工與可追蹤
  • 需要持續迭代與維護

What is SDD

Spec-driven development

  • Spec > source of truth
  • Spec > Implementation
  • Feedback > Spec
  • 模糊需求 > 可執行規格

從 Chat-driven 到工程化

  • Chat-driven：Prompt 主導
  • SDD：Spec 主導
  • Prompt 是畫一張水墨畫
    • Spec 是給你一張直角座標工程圖(template)，挖洞填坑

AI Engineering 需要可驗收任務

驗收標準明確

  • SOP/Runbook 步驟完成率 -> %
  • CI/CD Pipeline 成功率 -> %
  • Lead Time -> 分鐘
  • Infra / Cloud 成本 -> 每月金額
  • SLO 達成率 -> %

找第一個切換題目

  • 高人工成本
  • 流程固定（SOP/Runbook）
  • 低風險
  • 被依賴性低
情境分享：跨平台帳號與權限稽核
  • 平台：aws, azure, gcp, github, jenkins…
  • 需求清楚：列出帳號、檢查條件、輸出報告
  • 高人工、重複性高、容易漏

實際導入流程

  • 挑題目：低風險、高人工、需求清楚
  • 規格化：把需求寫成 Spec 與驗收條件
  • 拆任務：Spec -> Plan -> Task
  • 實作：Task 具體可驗收，agent 才能穩定交付

What is Spec-kit

  • Spec-kit 是 GitHub 的 SDD toolkit
  • 是一個 SDD 流程框架
  • 不是 prompt 技巧，是可重複工程流程
  • 把需求、驗收、交付串成同一條線

Spec-kit 核心流程

/speckit.specify 列出所有內部平台帳號...
/speckit.specify 根據條件檢查帳號狀態...權限...

/speckit.clarify
/speckit.plan
/speckit.plan    修改先後順序...

/speckit.tasks   拆成獨立子任務，可分配給 subagent...
/speckit.analyze 檢查 Task 依賴性

/speckit.implement

情境落地：帳號稽核自動化

  • ✅挑題目
  • ✅規格化
  • ✅驗收標準
  • 拆任務：每個平台一組 task，平行實作
  • 實作：subagent 分工，主流程整合

人類手動很痛苦 -> 變成可持續自動化

常見誤解

用了 Spec-kit 就會自動得到高品質？

答案：不一定

如果 Spec 中包含 test, lint, review 等驗收標準，且實作時有遵守，那麼品質會比較穩定

Spec-kit 解決了什麼，沒解決什麼

  • 解決：需求結構化、任務拆解、協作流程
  • 未完全解決：品質評估、回歸驗證、持續收斂

外部 agent 做 PR Evaluation

  • 不只測試有沒有過
  • 還要看是否符合 Spec
  • 還要看可維護性與可讀性

Automation Pipeline

把流程 script 化、pipeline 化

  • Spec
  • Plan
  • Tasks
  • Implement
  • Test + Eval + Loop

完整心智模型

Chat-driven (探索) -> Spec (定義) -> Build (交付) -> Eval/Loop (收斂)

你可以帶走的重點

  • Chat-driven 適合探索，不適合所有正式交付
  • When Not to Chat-driven：高風險、可驗收、多人協作場景
  • SDD + Spec-kit 讓 AI 開發流程可工程化
  • 加上 Eval + Loop，才能穩定落地

Q&A

Thank you.