新世代 SDLC 白皮書整理，與我的開發成熟度評估（Rails / TDD / SDD / Spectra / Kamal）

來源：〈The New SDLC with Vibe Coding〉白皮書（doggy8088）
連結：https://doggy8088.github.io/the-new-sdlc-with-vibe-coding/
擷取：2026-06-17

摘要

這篇白皮書主張軟體開發正從「寫程式」轉向「表達意圖」——人描述「要什麼」，AI 翻成「怎麼做」。它最有價值的部分是一條成熟度光譜：從 Vibe Coding（低結構） → Structured AI Assistance（中結構） → Agentic Engineering（高結構），並指出 production 級開發必須走到右端：用正式規格、TDD、CI/CD 評估、guardrail、harness 把 AI 從「會跑就好」拉到「可靠可規模化」。

本頁先整理白皮書骨架，再把你已導入的開發模式（Rails、TDD、SDD、Spectra、Kamal deploy）逐項對照這套框架，做出成熟度評估與補強建議。

一句話結論：你在「規格驅動 + 部署自動化」兩端已站上 Agentic Engineering 階；真正待補的是中段的「自動化評估閉環（output + trajectory evaluation）」與「可觀測性/成本治理」。

一、白皮書骨架

1. 六階段 SDLC

2. 成熟度光譜（全篇核心）

flowchart LR
    A["Vibe Coding<br/>低結構<br/>模糊提示 / 看起來會跑<br/>適合: 原型 PoC"]
      --> B["Structured AI Assistance<br/>中結構<br/>含約束的提示 / 手動測試<br/>適合: 既有 codebase 擴充"]
      --> C["Agentic Engineering<br/>高結構<br/>正式規格 + 自動化測試 + CI 評估<br/>適合: production / 團隊"]

3. Harness Engineering：Agent = Model + Harness

白皮書強調「真正的工程發生在模型之外」，harness 六件套：
① Rulefiles（AGENTS.md/skill）② Tools（MCP/API）③ Sandbox ④ Orchestration（sub-agent/model routing）⑤ Guardrails/Hooks（pre-commit 攔截）⑥ Observability（log/trace/eval/成本）

4. 兩個提醒

• 80% 問題：agent 快速做完 80%，剩 20%（邊界、整合、細微正確性）最難，需領域知識。新錯誤類別＝conceptual drift（看似對、過基本單測、實際崩潰）。
• CapEx vs OpEx：Vibe Coding 低前期高維護（token 燃燒、維護債、安全補救）；Agentic Engineering 高前期低維護。Context engineering 是財務槓桿。

名詞說明｜CapEx 與 OpEx
兩個原本來自會計／財務的詞，白皮書借來描述「成本花在前期還是攤在日常」：
- CapEx（Capital Expenditure，資本支出）：一次性的前期投資，買下日後能持續產生效益的資產。對應到 AI 開發＝先建好的 API 設計、測試套件、規格、脈絡文件（AGENTS.md）、guardrail。花在前面、之後一直受惠。
- OpEx（Operating Expenditure，營運支出）：維持日常運作的經常性開銷。對應到 AI 開發＝每天的 token 花費、retry loop、修 bug、補安全漏洞、清理沒人看懂的程式碼（維護債）。
- 白皮書的論點：Vibe Coding 看似省事（低 CapEx），但把成本推到日後變成高 OpEx（一直燒 token、一直補破洞）；Agentic Engineering 願意先付 CapEx（規格/測試/脈絡），換來低 OpEx（agent 在治理好的「工廠」裡產出結構化、已測試的程式碼，邊際維護成本低）。這跟蓋廠房一樣——前期投資設備（CapEx），長期壓低單位生產成本（OpEx）。

二、我的開發成熟度評估

以下把你已導入的五個模式，逐項對照白皮書框架。評分用三階：Vibe / Structured / Agentic。

總覽記分卡

逐項細評

① Spectra＝你的 SDD 引擎（成熟度最高）
spectra-propose 產出含工件的變更提案、spectra-apply 實作、spectra-audit 稽核安全 sharp edges、spectra-debug 四階段除錯、spectra-archive 收尾——這整套對應白皮書的「正式規格取代隨意提示」「memory artifacts」「guardrails」。這是你最領先的部分：多數人停在「詳細提示」（Structured），你已用結構化變更流程把意圖固化成可版本控管的工件。

實務升級（2026-06-17）：現在不論變更力度大小，一律走完整的 Spectra 循環 discuss → propose → apply → archive——不再因「改一點點」就跳過規格流程。這正是白皮書「結構帶來規模，隨機不能」與「不分大小都先表達意圖」的徹底落實，把 Vibe Coding 的隨手改完全排除在 production 路徑之外。

這套紀律已產出 prod 級產品為證：
- 個人部落格 nicklecheng.turbos.tw（本 wiki 的發布目標站）
- 火線超人 fhirlinebot.turbos.tw（FHIR / LINE bot 服務）
- 醫院官方網站（對外營運系統）

換言之，「Spectra 達 Agentic 階」不只是工具具備，而是已有對外營運的 production 系統實際跑在這套流程上——這比白皮書要求的「formal specs + 自動化防護」更進一步：你已用它交付真實上線產品。

② TDD：方向對，差在「自動 gate」
白皮書把 TDD 拉高到「先寫測試與 eval set 再生成程式碼，測試比自然語言更精確傳達意圖」。你已做 TDD。要從 Structured 推到 Agentic，關鍵不是寫更多測試，而是讓測試成為 CI 的強制 gate：agent 產出 → CI 自動跑 → 不過不准 merge。若已接 CI 即達標。

③ Rails＝天然的 Agentic 友善地基
Rails 的 convention over config 讓 agent 不必發明新模式、照既有慣例生成骨架——正是白皮書「agents conform to established patterns」。低 churn 後端讓 agent 產出長期穩定（呼應 DHH 訪談）。Rails 本身就把你墊到光譜的右端。

④ Kamal＝部署端已 Agentic
零停機、kamal-proxy 切換、可 rollback，對應「Deployment：automated monitoring and rollback」。部署成熟度足夠。唯一可加分：把「部署後的健康檢查/監控」也納入自動回饋（目前多為部署本身自動化，部署後觀測未必閉環）。

⑤ Harness：基礎齊、缺右半
你有 Rulefiles（CLAUDE.md/skills）、Tools（MCP/OneCLI proxy）、Sandbox（容器）、Orchestration（sub-agent/teams）。缺口在第 6 件 Observability：agent run 的 logging/tracing、每次成本指標、跨模型稽核，以及第 4 件的 model routing（複雜任務給大模型、確定任務給便宜模型省 token）。

成熟度雷達（六維評分）

把成熟度量化成一張六維雷達圖——六個維度正好對齊白皮書的 六階段 SDLC——並沿用一套比白皮書三階更細的 五級成熟度模型：

六個評估維度（對齊六階段 SDLC）與你的得分：

整體成熟度：Level 4.2（Agentic Engineer）——已達 Agentic Engineering 階段、環境落地能力強、持續朝 Level 5（Agentic Architect）邁進。六維均落在 4.0 以上、沒有明顯短板，其中「設計與架構」「開發與實作」「程式審查與部署」靠 Rails 慣例 + AI 協作 + Kamal 各拿下 4.5 為最強項群。

距離 Level 5（Agentic Architect）還差什麼？ 對照前面的補強建議，缺口集中在三個落在 4.0 的維度——「需求與規劃 / 測試與品質 / 維運與演進」——要再往上推的那 0.5～1 分：把 TDD 接成 CI 強制 gate、補上 trajectory evaluation 與 agent run 可觀測性、深化維運期的自動優化閉環。換句話說，雷達圖的「未滿格」處，正好就是第三節列的補強項。

下圖再把六維歸成「已達」與「待補強」兩堆，方便聚焦施力點：

flowchart TD
    subgraph G1["已達 Agentic"]
        S["規格驅動 (Spectra/SDD)"]
        D["部署自動化 (Kamal)"]
        A["架構慣例 (Rails)"]
    end
    subgraph G2["待補強：推向 Level 5"]
        T["TDD 接成 CI 強制 gate"]
        E["自動化評估閉環<br/>output + trajectory evaluation"]
        O["可觀測性 + 成本治理<br/>log / trace / model routing"]
    end

三、補強建議（依投報率排序）

1. 把測試接成 CI 強制 gate（若尚未）——TDD 已有，補上「不過不准 merge」即從 Structured 跳 Agentic。投報最高。
2. 加入 trajectory evaluation——白皮書特別點出：不只看「結果對不對」（output eval），還要看「agent 有沒有用對工具/邏輯」（trajectory eval）。可在 Spectra 流程加一道「agent 行為審核」工件。
3. 建立 agent run 可觀測性——記錄每次 agent 執行的 log、token 成本、成功率。Context engineering 是財務槓桿，先量測才能優化。
4. Model routing——確定性任務（lint、格式、簡單 CRUD）走便宜模型，複雜架構/除錯走大模型，降 OpEx。
5. 明確劃分 vibe vs agentic 邊界——哪些分支/環境允許隨手 vibe code（原型），哪些必須走 Spectra 全規格流程（production）。對應你 wiki 既有的「臨界性光譜」觀念。

四、補充：DHH 的開發哲學如何撐起這套成熟度

白皮書講的是「方法論」，但要讓一個人（或一個人 + AI agent）真的走到 Agentic Engineering 階，背後得有一套讓複雜度可被一個人掌握的工程哲學。這正是 DHH／Rails 過去二十年在做的事，也是為什麼你的 stack 能用很少人力站上光譜的右端。

1. The One Person Framework（一個人的 web framework）

DHH 替 Rails 下的定位：「一個人的框架」——一套工具齊全到讓單一開發者也能打造完整的現代應用，不必先湊出一支大團隊。它的底層信念：

• Omakase（主廚精選）：框架替你選好一整套預設（ORM、前端、測試、佈署），你不必自己拼裝十幾個套件、也不必為每個決策開會。減少決策＝減少 AI agent 要理解與發明的表面積。
• Convention over Configuration（慣例優於設定）：照慣例走就有合理預設。對 AI 開發是關鍵——agent 不必發明新模式，照既有慣例生成骨架（白皮書的「conform to established patterns」）。
• Majestic Monolith（雄偉單體）+ Conceptual Compression（概念壓縮）：把整個系統收斂成少數可一眼掌握的概念，而非散落成數十個微服務。一個人能扛、AI 也更容易 reason。
• Integrated Systems（整合系統）：從 ORM 到佈署都同一套人馬設計、彼此咬合。Hotwire、Solid Queue、Kamal 都是「不外包給第三方 SaaS」的整合件。

把這條哲學接回白皮書：One Person Framework 等於替個人開發者預先做好了 harness 的一半——Rulefiles（慣例本身就是規則）、整合好的 Tools、壓低的概念複雜度。所以你「一個人 + Spectra + AI」才跑得動 production 級流程。

2. Kamal local deploy 值得特別講

你的部署是 Kamal 從本機（local）直接佈署，這在白皮書的脈絡裡是個被低估、但很關鍵的選擇。

它特別在哪？

• 從你的筆電就能佈署：kamal deploy 在本機 CLI 跑——build / push image → SSH 到目標主機 → 用 kamal-proxy 做零停機切換。不需要一條複雜的雲端 CI/CD 流水線當前置條件。
• 直接打 bare metal / VPS，跳過 Kubernetes：用 Docker + SSH 就達成零停機、健康檢查、可 rollback，省掉 K8s 那層巨大的維運複雜度。
• 背景是 37signals 的「離開雲端（Cloud Exit）」：把應用搬回自有硬體，年省數百萬美元；呼應 DHH 訪談的「硬體紅利翻轉」（開發機比雲端伺服器還快）。擁有自己的工具與基礎設施，而非把命脈外包。

為什麼這對「成熟度」很重要？

白皮書把「automated monitoring + rollback」列為 Agentic 階的佈署要求，但沒說一定要昂貴複雜的雲端流水線。Kamal 的價值就是：用一個人可掌握的複雜度，達成 production 級的零停機佈署能力。

• 對照白皮書的 CapEx/OpEx：Kamal local deploy 是「低 CapEx（不必養一支 platform team）+ 低 OpEx（自有硬體、可預測成本）」的甜蜜點——這在白皮書裡屬罕見組合，靠的正是「整合 + 擁有」的哲學。
• 對照 80% 問題：佈署這一段的複雜度被壓到很低，讓你（與 agent）能把稀缺的注意力留給真正難的 20%（領域邏輯、邊界正確性），而不是耗在維運。

一句話：Kamal local deploy 是 One Person Framework 哲學在「佈署」這一格的具體實現——把原本需要整支 DevOps 團隊的能力，壓縮成一個人在本機就能可靠執行的指令。

3. 串起來：哲學 → 你的成熟度

這張圖把整條脈絡視覺化，由左到右三段：

• 左欄｜DHH 的五根哲學支柱：Omakase（主廚精選）、Convention over Configuration（慣例優於設定）、Majestic Monolith（雄偉單體）、Integrated Systems（整合系統）、One Person Framework（一個人的框架）。它們是這套開發方式的「價值觀地基」。
• 中欄｜哲學落地成 harness：五根支柱往中間匯流，預先做好了 agent 所需的 harness 構件——這也呼應底部那條流程帶 Rulefiles（慣例＝規則）→ Tools（整合工具鍊）→ Low Complexity（概念壓縮）→ Guardrails（安全護欄）→ Agentic Engineering。接著進到核心的 人 + AI + SPECTRA：你用 Spectra 的 discuss→propose→apply→archive，把意圖固化成可版控的規格工件。
• 右欄｜輸出 prod 級成果：程式、資料庫、測試、佈署、監控、成長——也就是部落格、火線超人、醫院官網這些實際上線系統。

換句話說：DHH 哲學壓低了複雜度與決策表面積 → Spectra 把流程結構化 → 一個人（＋AI）就能穩定產出 Agentic Engineering 級的 production 系統。下面的 Mermaid 是同一條脈絡的精簡文字版：

flowchart LR
    P["DHH 哲學<br/>Omakase / 慣例 / 整合 / 擁有"]
      --> F["One Person Framework<br/>把複雜度壓到一個人可掌握"]
    F --> R["Rails 慣例<br/>agent 照既有模式生成"]
    F --> K["Kamal local deploy<br/>一個人達成零停機佈署"]
    R --> M["你 + Spectra + AI<br/>跑得動 Agentic 級流程"]
    K --> M
    M --> G["from prompt to IPO<br/>(白皮書終局)"]

結論：白皮書告訴你「要走到 Agentic Engineering」，DHH 的哲學告訴你「一個人怎麼走得到」。你已導入的 Rails + Kamal local deploy，本質就是把 harness 與佈署的複雜度預先壓縮——這是你能以極小人力站上成熟度右端的真正底氣。

重點速覽

• 你的強項：Spectra（SDD，不分變更大小全程 discuss→propose→apply→archive）、Rails（架構慣例）、Kamal（部署）三項已在 Agentic Engineering 階，且已交付部落格、火線超人、醫院官網等 prod 級產品——多數團隊到不了這裡。
• 你的缺口：自動化評估閉環（output + trajectory eval）與可觀測性/成本治理，這是「中段」而非兩端。
• 一個心法：白皮書的「結構帶來規模、AI 放大組織文化」——你既有的結構（規格/測試/部署）會被 AI 正向放大，補上評估與觀測就能安全擴規模。

延伸閱讀（站內）

• 〈Vibe Coding 的臨界性光譜：什麼時候可以放手，什麼時候得有人把關〉——白皮書「劃分 vibe vs agentic 邊界」的在地對照
• 〈DHH 談 Basecamp 5、Vibe Coding 與 Rails 的未來〉——Rails 低 churn 後端＝agent 友善地基的論據
• 〈Kamal Deploy 全流程拆解：從本機 build 到零停機切換〉——你部署端達 Agentic 階的實作細節
• 〈Vibe Coding 各語言 Token 使用量比較：為什麼 Ruby 特別省〉——對應白皮書 model routing / context 即財務槓桿

來源連結

• 白皮書：https://doggy8088.github.io/the-new-sdlc-with-vibe-coding/

分類：tech｜標籤：vibe-coding, sdlc, agentic-engineering, sdd, tdd, spectra, kamal, rails, harness, maturity-model, dhh, one-person-framework