協議驅動開發：軟體工程的未來

如果你向 90 年代的開發者展示我們今天如何構建軟體——React 元件、微服務、GraphQL——他們會對工具感到驚訝。但他們也會感到困惑：

“你寫 10,000 行 TypeScript 只是為了把一個表單連線到資料庫？Schema 在哪裡？宣告式邏輯在哪裡？為什麼所有東西都是命令式程式碼？”

他們說得有道理。

軟體開發的下一次進化不是更好的框架。而是更少的框架。

這就是協議驅動開發 (Protocol-Driven Development)：將意圖表達為結構化資料 (Schema, 清單, 協議)，並讓編譯器、執行時和 AI 助手生成實現。

這不僅僅是理論。它正在發生。ObjectStack 正是為此未來而設計。

問題：程式碼太多，意圖太少

現代軟體開發有一個訊雜比問題：

例子：構建一個 CRUD API

意圖 (你想要的):

  • 一個 Customer 實體，包含欄位：name, email, phone
  • REST 端點：GET /customers, POST /customers, PUT /customers/:id, DELETE /customers/:id
  • 驗證：email 必須有效，phone 可選
  • 安全：只有擁有 customer-read 角色的認證使用者可以訪問

實現 (你寫的):

  • TypeScript 型別 (50 行): 介面, DTO, 驗證 Schema
  • 資料庫模型 (30 行): ORM 實體, 遷移
  • 控制器 (80 行): 路由處理程序, 請求解析, 響應格式化
  • 服務層 (60 行): 業務邏輯, 資料庫呼叫
  • 中介軟體 (40 行): 認證, 授權
  • 測試 (150 行): 單元測試, 整合測試
  • API 文件 (70 行): OpenAPI 規範

總計：~480 行程式碼來表達 4 句話的意圖。

低效之處

90% 的程式碼是樣板程式碼：

  • 將路由連線到控制器
  • 解析請求體
  • 驗證輸入
  • 處理錯誤
  • 檢查許可權
  • 格式化響應
  • 編寫重複的測試

只有 10% 是獨特的業務邏輯。

這種低效帶來了巨大的成本：

  • 更長的開發時間 (數週而不是數小時)
  • 更多的 Bug (480 行 = 480 個犯錯機會)
  • 維護負擔 (每次框架更新都會破壞某些東西)
  • 知識孤島 (初級開發者淹沒在樣板程式碼中)

洞見：分離意圖與實現

如果你能只表達一次意圖，並讓編譯器生成實現會怎樣？

# customer.objectql.yml (30 行意圖)
entity:
  name: Customer
  fields:
    - name: name
      type: text
      required: true
    
    - name: email
      type: text
      validation: email
      required: true
    
    - name: phone
      type: text
      required: false
  
  permissions:
    read: ["customer-read"]
    write: ["customer-write"]
  
  endpoints:
    - GET /customers
    - POST /customers
    - PUT /customers/:id
    - DELETE /customers/:id

這就夠了。30 行 YAML 替代了 480 行 TypeScript。

ObjectQL 編譯器：

  1. 生成資料庫 Schema (Postgres/SQL)
  2. 生成 API 路由 (Node.js/Serverless)
  3. 生成驗證邏輯 (Zod/Joi)
  4. 生成 TypeScript 型別 (給前端使用)
  5. 生成 OpenAPI 文件

為什麼現在？AI 因素

協議驅動開發不僅僅是關於效率。它是關於 AI 就緒性。

LLM (大型語言模型) 擅長編寫程式碼，但它們非常擅長理解結構化意圖。

  • 讓 AI 生成 480 行能夠完美工作的 NestJS 程式碼是很困難的（上下文視窗限制，幻覺，細微的 Bug）。
  • 讓 AI 生成 30 行有效的 YAML Schema 是微不足道的。

基於協議的架構為 AI 提供了完美的介面。

AI 輔助的工作流

  1. 你提示 AI： “我需要一個用於牙科診所的 CRM 系統，包含病人預約和保險記錄。”
  2. AI 生成： 5 個 ObjectQL Schema (Patient, Appointment, Insurance) 和 2 個 ObjectOS 工作流 (AppointmentReminder, InsuranceClaim)。
  3. 你審查： 你閱讀 YAML。它易於閱讀。你修正了一個欄位。
  4. 你部署： ObjectStack 編譯器接管並構建全棧應用。

程式碼成為了組合語言。協議成為了高階語言。

ObjectStack 的協議套件

我們設計 ObjectStack 作為這套新原語的標準庫：

  1. ObjectQL (資料協議): 定義資料、關係和驗證。
  2. ObjectOS (控制協議): 定義工作流、許可權和作業。
  3. ObjectUI (檢視協議): 定義佈局、元件和互動。

例子：ObjectUI

不用寫 React 元件：

# view.yml
type: page
title: Customer Details
layout: split
left:
  - type: card
    source: Customer
right:
  - type: list
    source: Customer.orders

如果明天 React 死了，我們更新 ObjectUI 編譯器以輸出 Vue、Svelte 或 iOS SwiftUI。你的意圖依然有效。

結論：未來是宣告式的

軟體開發正在進化：

  • 1980s-1990s: 彙編 → C (低階命令式)
  • 2000s-2010s: Java, Python, JavaScript (高階命令式)
  • 2020s-2030s: 協議, Schema, AI 生成 (宣告式)

趨勢很明顯： 我們正在抽象掉實現細節並專注於意圖。

ObjectStack 通過提供以下內容加速這一轉變：

  • ObjectQL (資料協議)
  • ObjectOS (控制協議)
  • ObjectUI (檢視協議)

問題不在於協議驅動開發是否會發生。而在於你是否準備好了。

開始設計協議。讓編譯器處理實現。構建比框架更長壽的系統。

軟體工程的未來是宣告式的。未來是協議驅動的。

準備好進行協議優先構建了嗎？ 探索 ObjectQL 或 檢視完整架構。