Vibe Coding：從 Prompt Engineering 到 Harness Engineering 的工程方式轉變

最近一直在嘗試 Vibe Coding 的各種 SDD 開發方式，比如 OpenSpec、SpecKit、oh-my-openagent 的 Prometheus。

Andrej Karpathy 在 2025 年 2 月提出了 Vibe Coding 這個概念——用自然語言描述意圖，讓 LLM 生成程式碼，「Accept All」不看 diffs，錯了直接複製錯誤訊息讓 AI 修復。

但真正上手後，我發現一個致命問題：AI老是胡亂發揮。

尤其在維護舊專案時，你給它一個需求，它能給你整出三套實作方案，每個都「看起來合理」，但哪個才是你真正想要的？

什麼是 Spec-Driven Development (SDD)

規約驅動開發（Spec-Driven Development，SDD），或者說「契約優先開發」（Contract-First Development），核心思想很簡單：

先定義規範，再讓 AI執行。

不是傳統的「先寫程式碼，文件是腳手架」，而是把規範作為唯一事實來源（Single Source of Truth）。

GitHub Spec Kit 提出了六階段工作流：

/constitution - 定義專案級原則（品質標準、架構約束）
/specify - 描述功能「是什麼」，不涉及「怎麼做」
/clarify - 消除歧義、識別邊界條件
/plan - 技術選型、架構決策
/tasks - 分解為可執行單元
/implement - 按規約編寫程式碼

這個流程讓我意識到：Vibe Coding 的終極目標不是讓模型發揮多強，而是確保意圖能被 100% 理解和實作。

Harness Engineering：給模型套上缰繩

Anthropic 有個經典隱喻：

1
2


LLM = 強大的馬，強大的力量，但沒有方向感，不理解邊界
Harness = 缰繩 + 馬鞍，引導力量，設定邊界，防止失控

Harness Engineering 就是設計、構建和運營 AI Agent 基礎設施的學科——約束、引導、驗證、糾正生產環境中的 AI。

這跟 Prompt Engineering 完全不同：

對比維度	Prompt Engineering	Harness Engineering
範圍	傳送給 Model 的指令文字	圍繞 Model 的整個基礎設施
焦點	讓 Model 理解任務	系統如何約束、驗證、糾正 Model
可靠性提升	5-15%	50-80%

有个真實案例讓我印象深刻：某金融公司的 Agent 在凌晨 3 點失控，連續 11 分鐘瘋狂重試一個失敗的 API，累計重試 847 次，消耗了 2200 美元的 API費用，還給同一個客戶發了 14 封重複郵件。

事後復盤發現：Model運行正常，Prompt 也精心設計了，但問題出在基礎設施層面——缺少三個硬性控制：重試上限、執行超時、熔断機制。

這件事讓我真正理解了 Harness 的核心價值：寫在 Prompt 裡的「請勿超过 10 次重試」，只是建議，AI可以忽略，可以被其他指令覆蓋。但在 Harness 層強制執行的重試上限，才是真正的治理——Agent 无法繞過，必須遵守。

工程範式發生了徹底的改變

從對話交互到嚴格約束

過去我們：

不斷和 AI對話交互
寫更好的 prompt
用更强的單一模型（GPT-4 → GPT-4o → Claude Opus）

現在的 Harness Engineering：

嚴格約束：哪些要做，哪些不能做
人類意圖的理解：面試式訪談，消除歧義
全流程把控：從規約 →計劃 →執行 →驗證
多 Agent 多模型協作（oh-my-openagent插件）：Sisyphus + Prometheus + Metis + Momus

核心组件

Harness Engineering 有五大組件：

Context Engineering - 决定 Agent 每一步看到什麼資訊
Tool Orchestration - 工具選擇、參數驗證、執行沙箱
Verification Loops - 每步驗證輸出（83% → 96% 任務完成率）
Cost Envelope Management - Per-task 預算上限（median × 3）
Observability - 結構化執行追蹤，因果關係記錄

我的 Harness Engineering 實踐：DDD + gRPC專案

第一步：定義 gRPC輸入輸出規範

DDD架構的專案，必須先人工定義 gRPC的輸入輸出規範。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


service UserService {
  rpc CreateUser(CreateUserRequest) returns (CreateUserResponse);
}

message CreateUserRequest {
  string name = 1;      // 2-100 字元
  string email = 2;     // 必須是有效郵箱格式
  string role = 3;      //只允许 "admin", "user", "guest"
}

message CreateUserResponse {
  string user_id = 1;   // UUID格式
  int64 created_at = 2;
}

這個 .proto 文件就是契約——AI不能超出這個範圍胡亂發揮。

第二步：讓 AI全量探索專案

專案中有很多 repo層的可復用資源，需要讓 AI做全局探索（唯讀），產出專案概要 markdown。

使用 oh-my-openagent 的 /init-deep ，並行啟動多個 Agent：

搜索現有資料模型
分析 repo層介面
提炼可復用組件

第三步：編寫業務細節 markdown

切記：不要貪圖一個文件囊括大量業務細節。

小顆粒度拆分：

1
2
3
4
5
6
7
8


specs/
├── 001-user-auth/
│   ├── spec.md         # 使用者場景、驗收標準
│   ├── data-model.md   # 資料模型定義
│   ├── contracts/      # API契約
│   └── tasks.md        # 可執行任務
├── 002-payment-flow/
│   └── ...

原則：盡量讓主 Agent每次任務不佔用過多上下文。就算壓縮上下文，也是資訊準確度的丢失。

第四步：調研階段——絕不能直接寫程式碼

這是最關鍵的一步：一定要告訴 AI，不要一開始就寫程式碼。

尤其在上下文累積越長的時候，模型越容易產生幻觉，自以为是地開始執行。我們要利用單個 AI session 的上下文空間，先讓 AI進行嚴格的調研，提出疑問，我們一起完善我之前編寫的規約規範。

模擬對話的場景：

1
2
3
4
5
6
7
8


AI: 「我看到專案中已有 UserRepository，但缺少 OAuthToken實體。
     需要新建表還是復用現有的 user_tokens表？」
     
我: 「復用 user_tokens表，但需要添加 provider字段。」

AI: 「provider字段是否需要枚舉約束？支援的 provider有哪些？」

我: 「目前只支援 google 和 github，用枚舉約束。」

上面的對話場景，只是我模擬舉出的案例。這種迭代式澄清，比直接讓 AI寫程式碼效果好太多。

第五步：調研結束後，使用 OpenSpec或 Prometheus建立 Tasks/Plans

我常用的兩種方式：

OpenSpec 的 /opsx:propose：

1
2
3
4
5
6


/opsx:propose 添加 OAuth 2.0認證支援，請讀取xxx.md開始調查並制定計劃，但不要執行計劃
# 自動生成：
#   proposal.md - 意圖、範圍、方案
#   specs/auth/spec.md - Delta Specs (ADDED/MODIFIED/REMOVED)
#   design.md - 技術架構決策
#   tasks.md -實施清單

oh-my-openagent 的 Prometheus：

1
2
3
4
5
6
7
8


請讀取 xxx.md開始調查並制定計劃，不要執行計劃
# 面試式訪談：
#   - 先迁移哪些端點？
#   - REST保留還是廢棄？
#   - OAuth provider選擇？
#   - 是否使用TDD測試驅動開發？
# 
# 生成計劃 → Oracle調研 → Metis分析 → Momus驗證

當然我個人而言，我更喜歡omo插件的「訪談式」，或者說是「對話式」的確認很多細節。

第六步：Plans/Tasks創建後，新建 session執行

當 Plans或 Tasks的 markdown文件創建好后，我会新創建一個 AI session，讓它專一地執行這次任務。

使用 omo 的 /start-work，或者 OpenSpec的 /opsx-apply xxxxx：

讀取已驗證的計劃
委托給專業 Agent（程式碼生成、測試、整合）
獨立驗證結果
主 Agent協調

題外話：oh-my-openagent 的多 agent、多 category的方式，似乎在使用 OpenSpec的 skills時，無法正常啟用，它只會讓你當前主模型去執行。

總結：實踐後的真實感受

用了2個多月 Harness Engineering的方式做 Vibe Coding，最大的感受不是資料提升了多少，而是心態變了。

以前用 AI寫程式碼，每一步都提心吊膽——它會不會理解錯了？會不會自作主張加一堆不需要的功能？會不會把簡單的事情搞複雜？

現在有了規約約束，這些問題基本消失了。不是因為我用了更强的模型，而是因為我在 AI執行之前，先把意圖「钉死」了。

幾個明顯的改變：

返工少了。以前一個功能平均要來回改三四次，現在大部份一次就過。不是因為 AI突然變聪明了，是因為規範把「怎麼做」提前定清楚了。

成本降了。同樣的任務，Token消耗大概省了三分之一。因為 AI不需要反覆嘗試、反覆修正了。

模型要求没那么高了。以前覺得必須用 Claude Opus才能幹好活，現用 Sonnet配合完善的規約，效果差不多。

Vibe Coding的本質不是「讓 AI更聪明」，而是「讓 AI更听话」。

听话的前提是：你先把話說清楚。

這才是 Harness Engineering的核心——它不是讓模型發揮更强的能力，而是確保你的意圖被準確理解、嚴格執行。

搭這套基礎設施確實費時間，反覆探索這2個多月時間，才用順手。但一旦搭好了，AI編碼就從「猜谜遊戲」變成了「按圖施工」——你可以真正享受 Vibe Coding的樂趣，而不是每次都要盯著它有沒有跑偏。

如果你對規約驅動開發感興趣，可以看看我在 OpenCode 中嘗試 OpenSpec 的體驗。對於 AI agent 模型配置，可以參考我的 oh-my-opencode 配置優化歷程。