我的知識庫

AI-Native Engineering 五支柱：超越 Vibe Coding 的方法論

閱讀時間約 7 分鐘

「Vibe coding」——純粹跟著感覺讓 AI 生程式碼——在個人快速原型可能足夠，但在需要品質和可維護性的工程情境就會出問題。 Thoughtworks 的 Sunit Parekh 在 2026 年提出五支柱框架，把 AI-native engineering 從感覺導向升級為可操作的工程紀律。

五支柱框架

來源：Sunit Parekh（Thoughtworks），Beyond vibe coding: The five building blocks of AI-native engineering，2026-03-18

Parekh 的核心主張：「專業 AI 驅動的軟體開發需要刻意編排這五個組件，而不是無結構的 vibe coding，以確保企業級的品質和可靠性。」

支柱一：選對 Agent

Agent 是「超越基本反應式助手的自主執行層」，核心能力：

  • 導航檔案系統、執行終端指令
  • 自動化測試
  • 多檔案編輯
  • 在人類監督下操作

2026 年主要選項：Claude Code、OpenCode、Cline；IDE 整合型：Cursor、Windsurf。選擇標準不只是功能清單，而是與你的 context 設計和 harness 架構的相容性——一個功能強大但 context 設計差的 agent，不如一個功能適中但 harness 整合佳的。

支柱二：選對模型（Model Routing）

業界已從「一模型通吃」轉向高度專業化模型組合：

專門化方向用途
程式碼生成模型主要實作
架構推理模型系統設計決策
測試與 QA 模型測試生成與評估
文件與知識合成模型文件、README、ADR
安全與漏洞分析模型安全審查

選模型是架構決策，不是品味問題——不同任務的 cost / quality / speed 取捨差異很大。這個支柱對應 AI 成本工程與 Model Routing 的論述。

支柱三：選對方法論（防止 Agent Thrashing）

「Agent thrashing」是指 agent 在循環中做重複無效工作的現象，通常由不清晰的 spec 或缺乏測試觸發。

防止 thrashing 的實踐：

  • 有結構的 prompt（清晰的規格先於生成）
  • CI/CD 整合做即時驗證
  • Test-Driven AI Development（測試先於實作）
  • 版本控制 + 稽核軌跡
  • 強制人工審查閘門（不因速度快就跳過）

Thoughtworks 推薦框架：AI/works™ 的 3/3/3 交付模型（細節尚未完全公開文件化）；以及 BMAD Method。

支柱四：用 Spec 提示（Prompt Using Specs）

「自主編碼 agent 的有效性，與輸入規格的品質直接成正比。」

spec-to-code pipeline 的工具：

這個支柱直接呼應 Problem Framing ＋ Spec-Driven Development——spec 既是人類的共識文件，也是 AI 的執行 prompt。Parekh 和 Spec-Driven 的論述完全吻合：模糊的 prompt 是 agent thrashing 的主因。

支柱五：提供 Context（Context Engineering）

透過以下機制策略性地整理機構知識，讓 agent 能取用：

  • Agent Skills：打包的領域特定專業知識
  • Rules 檔案（.cursorrules、AGENTS.md）
  • 安全護欄和政策
  • 設計系統引導
  • 企業程式碼庫整合

這個支柱直接對應 Context Engineering 框架——知識不是被動地存在，而是被主動設計到 agent 能取用的形式。Tech Radar Vol.34 把 Context Engineering 和 Curated Shared Instructions 都列為 Adopt。

Böckeler 的六分類 AI 工具圖譜（選工具前先定位）

來源：Birgitta Böckeler（Thoughtworks），Navigating the landscape of AI tools for software delivery，2024-04-24

在採購任何 AI 工具之前，先用這個分類定位你在買什麼：

  1. 既有工具的 AI 延伸：整合進 Figma、Jira、雲端控制台的 AI 加強版
  2. GenAI 原生工具：以 AI 為核心的新獨立工具
  3. Coding assistants：GitHub Copilot、Tabnine、Continue、aider
  4. Chatbot 與 Prompt 共享：有內建護欄和共享 prompt 庫的對話介面（如 Dify）
  5. 團隊協助 Portal：輕量內部工具，供跨職能實驗用
  6. 基礎模型與搜尋：雲端 LLM 存取和 RAG 能力

Böckeler 的策略建議：

  • 先強化既有工具的 AI 延伸，再引入全新工具（降低導入摩擦）
  • 先限定團隊做小規模試驗
  • 技術採用要和工程實踐的提升同步——工具快、紀律慢，會出問題

主張 vs 可佐證

  • 可佐證：五支柱框架是 Parekh 從 Thoughtworks 實際交付案例提煉的；Böckeler 的六分類發表於 2024 年，Thoughtworks 持續在客戶工作中使用；Tech Radar Vol.34 把 Context Engineering（Adopt）和 Agent Skills（Trial）列入，直接支持支柱四、五；Claude Code 和 Cursor 在 Vol.34 均升至 Adopt。
  • 主張：「vibe coding 在企業環境不可行」是工程意見，有案例支撐但沒有系統性對照數據；「自主 agent 的效果與 spec 品質直接成正比」是直覺合理的主張，但 spec 品質本身難以客觀量化。
  • 收斂結論：五支柱不是清單，是一個整體——缺少任何一柱都會讓其他柱的投資打折扣。 Agent 再好，沒有 spec 就會 thrash；Spec 再好，沒有 context 就會失去機構知識；方法論再嚴謹，沒有人工審查閘門就無法保住品質底線。

來源：

反向連結