標籤

OpenSpec 是什麼？

 

一、OpenSpec 是什麼？

**OpenSpec（Open Specification）**是一種「開放式規格定義方式」，它的核心理念是：

用標準化、可解析的方式描述系統規格，讓人與機器都能理解。

簡單說：

  • 傳統規格：Word、Excel、Confluence 文件

  • OpenSpec：結構化格式（通常是 JSON / YAML / Markdown 結構化標記）

OpenSpec 的精神其實與 API 規格文件類似，例如：

  • OpenAPI

  • Swagger

但 OpenSpec 的應用範圍更廣，可能包含：

  • 系統需求規格

  • 流程定義

  • UI 行為描述

  • 商業邏輯規則

  • AI Agent 可執行規格

二、OpenSpec 想解決什麼問題？

在實務專案中，你（尤其身為工程師）可能很有感：

1️⃣ 規格模糊

PM 寫的規格：

  • 「使用者可以新增資料」

  • 「需要支援多筆操作」

  • 「錯誤時顯示提示」

但：

  • 什麼錯誤？

  • 允許空值嗎？

  • 交易要不要 rollback？

  • 有沒有版本控管？

常常變成工程師要自己補邏輯（你應該超有感 😅）。

2️⃣ 規格無法機器理解

傳統文件：

  • 無法自動產生測試

  • 無法驗證是否缺欄位

  • 無法直接生成程式碼

OpenSpec 的目標是：

規格 = 可以被 AI / 工具解析與執行的資料

三、OpenSpec 怎麼用？（實務教學）

Step 1️⃣ 用結構化格式定義規格

範例（YAML）：

feature: CreateOrder
description: 使用者建立訂單

inputs:
  - name: userId
    type: string
    required: true

  - name: items
    type: array
    required: true

business_rules:
  - inventory must be greater than 0
  - payment must be authorized before confirm

outputs:
  - orderId
  - status

這種寫法的優勢是：

  • AI 可以解析

  • 可以自動產生測試案例

  • 可以自動生成 API 文件

  • 可以驗證欄位完整性

Step 2️⃣ 搭配工具鏈

你可以整合：

  • 規格 → 產生 API

  • 規格 → 產生測試

  • 規格 → 驗證商業邏輯

如果你是 .NET 工程師（你目前主要使用 .NET）：

你可以做到：

  • 規格 → 產生 Controller

  • 規格 → 產生 DTO

  • 規格 → 產生 Validation Attribute

  • 規格 → 產生 Unit Test Skeleton

這會大幅降低「規格理解成本」。

Step 3️⃣ 結合 AI / Agent

現在 AI Agent 與 Spec 結合的趨勢很強。

例如：

  • Spec → AI 生成程式碼

  • Spec → AI 驗證邏輯衝突

  • Spec → 自動生成測試資料

未來甚至可能：

Spec = 系統的 Single Source of Truth

四、OpenSpec 的優點

✅ 1. 規格標準化

  • 降低溝通成本

  • 避免口語模糊

✅ 2. 可機器解析

  • 自動化生成

  • 自動測試

  • 自動驗證

✅ 3. 可版本控制

  • Git 追蹤規格變更

  • 版本差異可比較

  • 可回滾規格

✅ 4. 有利於 AI 整合

未來的開發流程會變成：

Spec → AI → Code → Test → Deploy

五、OpenSpec 的缺點

❌ 1. 初期學習成本

  • PM 可能不熟結構化格式

  • 需要建立規格標準

❌ 2. 可能過度工程化

小專案不一定需要。

❌ 3. 不適合高度創意需求

例如：

  • UI 視覺設計

  • 體驗導向產品

六、OpenSpec 與傳統規格比較

比較項目 傳統文件規格 OpenSpec
可讀性 高（人類容易閱讀） 中（需理解結構化格式）
可機器解析性 低（無法自動解析） 高（JSON / YAML 可直接解析）
自動化生成能力 幾乎沒有 高（可產生 API / 測試 / 文件）
版本控制 困難（文件 diff 不易閱讀） 容易（Git 可追蹤差異）
AI 整合能力 困難 非常適合（可作為 AI 輸入規格）
適用場景 小型專案、簡單需求 中大型專案、微服務、AI 驅動開發


七、未來趨勢

🔮 1️⃣ Spec-Driven Development

未來開發可能會像 API 世界一樣：

  • 先寫 Spec

  • 再產生系統

類似：

  • OpenAPI 之於 API

  • OpenSpec 之於整個系統

🔮 2️⃣ AI Agent + Spec

AI 不再只生成 code，而是：

  • 讀 Spec

  • 驗證 Spec

  • 改進 Spec

  • 生成架構

🔮 3️⃣ 規格即合約（Spec as Contract）

尤其在：

  • 金融系統

  • 區塊鏈

  • 跨鏈交易

  • ACID 一致性系統

Spec 可以直接當作：

  • 邏輯合約

  • 驗證依據

  • 共識基準

這其實跟你現在研究的「跨鏈一致性控制」概念非常契合。

你未來甚至可以：

用 OpenSpec 描述跨鏈 MVCC 規則
再讓 Relay Chain 驗證 Spec 合規性

這會變成很有研究價值的方向。

八、適合哪些人？

  • 工程師

  • 技術 PM

  • 系統架構師

  • DevOps

  • AI Agent 開發者

結論

OpenSpec 不是一個單純工具。

它是一種思想：

規格應該是可執行的。

未來的軟體工程，可能會從：

Code-Driven → 轉變成 → Spec-Driven

而 AI 的出現，會加速這個轉變。

標籤：

留言

張貼留言

熱門文章