「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 的工具：
- SpecKit（GitHub）
- OpenSpec（Fission-AI）
- BMAD Quick Flow
這個支柱直接呼應 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 工具之前，先用這個分類定位你在買什麼：
- 既有工具的 AI 延伸：整合進 Figma、Jira、雲端控制台的 AI 加強版
- GenAI 原生工具：以 AI 為核心的新獨立工具
- Coding assistants：GitHub Copilot、Tabnine、Continue、aider
- Chatbot 與 Prompt 共享：有內建護欄和共享 prompt 庫的對話介面（如 Dify）
- 團隊協助 Portal：輕量內部工具，供跨職能實驗用
- 基礎模型與搜尋：雲端 LLM 存取和 RAG 能力
Böckeler 的策略建議：
- 先強化既有工具的 AI 延伸，再引入全新工具（降低導入摩擦）
- 先限定團隊做小規模試驗
- 技術採用要和工程實踐的提升同步——工具快、紀律慢，會出問題
Vol.35 更新：支柱二（選模型）被整個翻新
來源：Technology Radar Vol.35（2026-11-04）。完整判讀見 Vol.35 判讀。
Parekh 的五支柱在 Vol.35 大致維持，但支柱二「選對模型」從一個分工表變成了雷達的四大主題之一：「Beyond frontier models」。
| Vol.35 blip | 環級 | 對支柱的影響 |
|---|---|---|
| Open-weight models | Trial | Thoughtworks 說這類模型已到「顯著的轉折點」，點名 DeepSeek、GLM、Kimi 三個家族，並強調要把它們當作廣泛企業工作負載的候選，而不只是省錢方案。除成本外，理由包括部署彈性、免於廠商鎖定、資料主權 |
| Blanket frontier model usage | Caution | 支柱二的反面教材：每個任務都丟給最強的模型。關鍵實務細節是每個模型有各自的 prompt cache，所以切換要放在自然邊界（新 session、子代理、規劃轉實作的交接），逐請求切換反而更貴。另一個反直覺點：更強的模型有時用更少 token 就完成任務，所以要用 context profiling 確認你的「優化」真的有效 |
| Small language models | Assess → Trial | 探索、簡單編輯、摘要這類例行工作，小模型往往就夠 |
| Local coding models | Assess | 本地端編碼模型開始進入視野 |
| Coding harness for general-purpose agents | Trial | 對支柱一（選 agent）的修正：非編碼的 agent 也可以直接站在 coding agent 的 runtime 上（Claude Agent SDK、Codex SDK、OpenCode server、Pi），省下自建 agent loop 的工 |
| OpenAI Codex、OpenCode | Adopt（工具） | 支柱一的可選清單更新；OpenCode 同時是企業自建 agent 的常見底座 |
| OpenSpec | Assess → Trial（工具） | 支柱四（用 spec 提示）的工具鏈，第一個被推上 Trial |
| AI-driven documentation sprawl | Caution | 支柱四的反面：Spec-kit、BMAD 產出大量 Markdown，造成品質與進度的假象。文件不經過 CI 與品質閘門，repo 累積出「a big ball of documentation mud」，agent 讀到過期 ADR 與矛盾 spec，既吃 context 又餵錯資訊 |
對本篇結論的修正：原文說「缺少任何一柱都會讓其他柱的投資打折扣」。Vol.35 補上一個更尖銳的版本——支柱四（spec）做過頭會反噬。寫更多 spec 不等於更好的 context；沒有人工修剪的 spec 會變成 agent 的噪音來源。Thoughtworks 的處方是把 Markdown 當作第一級工件看待，刻意投入人力去修剪、精煉與整併。
主張 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 就會失去機構知識；方法論再嚴謹，沒有人工審查閘門就無法保住品質底線。
🕒 更新紀錄
- 2026-11-09 — 補 Vol.35（2026-11-04）：支柱二升格為雷達主題「Beyond frontier models」；新增 open-weight models、blanket frontier model usage、coding harness for general-purpose agents、AI-driven documentation sprawl 等對照，並修正「spec 越多越好」的隱含假設。
- 2026-07-04 — 建立本篇。
來源：
- Beyond vibe coding: The five building blocks of AI-native engineering — Sunit Parekh (Thoughtworks), 2026-03-18
- Navigating the landscape of AI tools for software delivery — Birgitta Böckeler (Thoughtworks), 2024-04-24
- Technology Radar Vol.34 — Thoughtworks, 2026-04（Claude Code: Adopt；Cursor: Adopt；Context Engineering: Adopt）