提示工程已死。歡迎來到規格驅動開發的時代。
在過去幾年裡，我們都沉迷於「提示工程」。我們試圖用完美的魔法咒語召喚強大的 AI，期望它能為每個問題提供完美的解決方案。但現在，宿醉正在襲來。作為開發者和架構師，我們正在醒悟到痛苦的副作用：
提示驅動 開發的宿醉
「提示工程已死。一切都是規格。」- Sean Grove，OpenAI
-
氛圍驅動開發： 我們用提示快速生成程式碼，但就像編譯後刪除原始碼一樣，我們丟棄了最關鍵的資產：意圖。這導致了架構漂移，系統慢慢偏離其預期設計。
-
不一致的系統： 一次性提示無法處理複雜的系統需求。結果是一堆脆弱、不一致的程式碼拼湊，無法保證**非功能性需求（NFRs）**如安全性、可擴展性和可觀測性。
-
溝通鴻溝： 當需求變更時，我們又回到重新設計提示，浪費無數小時為 AI「重新翻譯」人類意圖，而不是進行系統性的影響分析。
這些問題的根源在於我們要求 AI 猜測 我們想要什麼。這就是為什麼 Sean Grove 的說法如此引起共鳴。他認為我們需要將焦點從「如何提問」轉移到「如何定義」。這就是規格工程的崛起——一種新範式，看起來很像現代版的模型驅動架構（MDA）。
等等，「規格」和「模型」有什麼區別？
你可能會問，「如果這像模型驅動架構，那『規格』和『模型』有什麼區別？」
這是個完美的問題。簡單來說：我們所說的「規格」是「模型」的現代、輕量級實現。
- 傳統的「模型」（MDA）： 這通常意味著遵循嚴格範式（如 UML）的重量級、抽象藍圖。它們很強大，但往往需要複雜的工具鏈，而且感覺與開發者的日常工作流程脫節。
- 現代的「規格」（規格工程）： 這是一種務實的演進。它就是一個模型，但是：
- 開發者原生： 它使用純文字格式如 YAML 和 Markdown，對開發者和 Git 等版本控制系統非常友好。
- 具體且可行動： 它不是抽象的、平台無關的模型，而是針對特定、選定技術堆疊的單一事實來源，設計用於直接生成多個目標（程式碼、測試、IaC）。
所以，當我們談論「規格工程」時，我們是在 MDA 的核心理念上建構——讓模型驅動開發——但將其適應到更敏捷、以開發者為中心的框架。
規格作為活的模型：新的開發範式
在 DevAiOps 的世界中，規格不再是靜態的 Word 文件或 Confluence 頁面。它是一個可執行、可驗證、版本控制的系統模型。
軟體專業人士會很快發現，維護這個模型的品質比維護任何單一程式碼的品質更為關鍵。
為什麼模型比程式碼更重要
- 對齊的錨點： 規格是人類和 AI 之間的契約，使每個利害關係人——產 品、設計、工程，甚至法務——能夠在單一事實來源上對齊。
- 意圖的體現： 程式碼是規格的「有損壓縮」。一個優秀的模型能捕捉完整的業務邏輯、架構約束和決策歷史。
- 多目標生成： 就像原始碼編譯到不同平台一樣，一個優秀的模型可以生成：
- 後端程式碼（Go、Rust、Python）
- 前端 UI（React、Vue、Svelte）
- API 文件（OpenAPI、GraphQL Schema）
- 基礎設施即程式碼（Terraform、Pulumi）
- 測試套件（單元測試、整合測試、端到端測試）
- 使用者手冊甚至行銷文案。
這一直是夢想，但文件和程式碼之間的差距太大了。在 DevAiOps 時代，SpecAgent 是跨越這個差距的橋樑。
SpecAgent：你在系統設計中的智慧夥伴
SpecAgent 是 DevAiOps 框架的核心。它的工作是將人類在環的需求轉化為 AI 可以執行的結構化、機器可讀的模型。
它不僅僅是一個翻譯器；它是系統知識圖譜的守護者。專案的程式碼庫、過去的架構決策和 API 契約都是這個活的圖譜的一部分。
角色如何演進：PM、架構師和 SpecAgent
一個常見的問題是：「撰寫規格不是產品經理或架構師的 工作嗎？」為什麼要創建一個單獨的 SpecAgent？
這是一個關鍵點。傳統上，這個責任在 PM 和架構師之間模糊，這正是為什麼他們的輸出（PRD、架構圖）經常漂移分離。SpecAgent 透過充當協作綜合者來解決這個問題。
以下是職責的分離方式：
| 角色 | 核心職責 | 焦點 | 關鍵交付物 |
|---|---|---|---|
| 產品經理（PM） | 定義**「為什麼」** | 使用者、市場、業務價值 | 產品需求文件（PRD）、使用者故事、驗收標準 |
| 架構師 | 定義**「如何」** | 技術可行性、系統健康、NFR | 架構藍圖、技術堆疊、系統約束 |
| SpecAgent | 綜合**「什麼」** | 將「為什麼」和「如何」融合成單一、明確、可執行的模型 | 結構化、版本控制的規格 |
為什麼 SpecAgent 需要獨立？
- 關注點分離： PM 專注於「建構正確的東西」。架構師專注於「正確地建構東西」。
SpecAgent專注於精確記錄這些決策，充當中立、嚴謹的綜合者。 - 自動化和嚴謹性：
SpecAgent自動化了將人類意圖轉化為機器可讀格式的繁瑣、易錯的工作。這使人類能夠專注於高層策略。 - 衝突解決： 當 PM 的「為什麼」與架構師的「如何」衝突時，
SpecAgent可以標記不一致，強制進行深思熟慮、資料驅動的決策，而不是讓衝突隱藏在模糊的文件中。
簡而言之，SpecAgent 不會取代 PM 或架構師。它是一個強大的協作工具，確保他們的集體智慧完美地捕捉在可執行的開發藍圖中。
SpecAgent 的核心能力
| 能力 | 描述 | 對開發的意義 |
|---|---|---|
| 需求解析 | 從票據、會議記錄和對話中讀取非結構化需求。 | 將模糊的需求映射到現有系統模型以識別差距。 |
| 模型擴展 | 使用 LLM 解構需求並更新系統模型。 | 就像演進一種領域特定語言（DSL）來描述你的系統。 |
| 規格生成 | 自動生成結構化規格，包括使用者故事、AC 和 NFR。 | 確保每個規格都遵循總體架構原則。 |
| 任務分解 | 將規格分解為可執行的開發任務和序列圖。 | 不僅生成功能任務，還生成重構和技術債任務。 |
| 影響分析 | 當規格變更時，自動識別對程式碼、文件和測試的影響。 | 這創造了一個真正的「活架構」，文件和實現永不漂移。 |
範例規格：一個簡單的圖片上傳功能
feature: imageUpload
specVersion: 1.0
owner: architect
# 使用者故事
description: "作為使用者，我想上傳個人頭像，以便我可以個性化我的帳戶。"
# 驗收標準
acceptance:
- "支援 PNG、JPG 格式。"
- "檔案大小必須小於 5MB。"
- "上傳前顯示預覽。"
- "上傳時顯示進度條。"
# 非功能性需求（NFR）
nfrs:
security:
- "上傳時掃描惡意軟體。"
- "需要已認證的使用者會話。"
performance:
- "圖片處理（調整大小）必須在 2 秒內完成。"
observability:
- "記錄上傳成功/失敗事件及使用者 ID。"
# 依賴和整合
dependencies:
- "UserService：用於將圖片與使用者關聯。"
- "S3StorageService：用於儲存圖片。"
SpecAgent 工作流程
1. 輸入：一個模糊的需求，例如「我想要一個圖片上傳功能。」
2. 知識圖譜檢索（RAG）：SpecAgent 從其知識圖譜中提取相關的 API 設計、安全政策和現有服務。
3. 澄清和權衡分析：代理提出澄清問題並促進架構權衡，例如「為了支援即時預覽，我們需要增加前端複雜性。這可以接受嗎？」
4. 規格模型生成：基於對話，它生成結構化的規格草稿（如上面的範例）。
5. 人類審查和批准：架構師或 PM 審查並批准規格，確保它與產品和技術路線圖一致。
6. 多目標程式碼生成：SpecAgent 將最終規格交給下游代理（CodeAgent、TestAgent、IaCAgent）來生成程式碼、測試和部署腳本。
7. 模型回饋循環：當實現完成時，任何新的技術決策或程式碼變更都會反饋到系統知識圖譜中。
工具和框架的原則
要建構一個強大 的 SpecAgent，我們需要從架構師的角度選擇工具：
- 可控性和透明度： 避免黑盒子。我們需要對每個決策點有完全控制的工具，確保 AI 的行為與我們的架構原則一致。
- 開放性和標準化： 優先考慮開源或可自託管的解決方案。支援 OpenAPI 和 AsyncAPI 等標準有助於創建靈活、可互操作的代理生態系統。
- 為 AI 設計： 下一代工具必須支援 AI 原生開發模式，如規格版本控制、動態 AI 驅動 UI 和基於知識圖譜的程式碼導航。
核心需求是一種人類和 AI 都可讀的格式。這意味著結構化純文字（如 YAML + Markdown），透過 Git 進行嚴謹的版本控制。這將完全取代傳統的 Word/Confluence 文件，甚至半結構化工具如 Notion 或 wiki。
關鍵要點：規格工程的三個核心原則
如果你只記住這篇文章的一點，讓它是這三點：
- 規格優於提示： 放棄分散的、一次性的提示，轉向系統化、版本控制的規格。這是從簡單地向 AI 請求 事情到真正與它 協作 的關鍵轉變。
- 規格是活的模型： 你工作的輸出不是靜態文件。它是一個可執行的「單一事實來源」，可以生成多個產物（程式碼、測試、文件）。
- 協作是核心：
SpecAgent不會取代任何人。它是 PM 的「為什麼」和架構師的「如何」之間的橋樑，將它們融合成精確的「什麼」，以解鎖前所未有的開發速度和品質。
最後的想法：從編碼者到系統架構師
在 DevAiOps 時代，開發者的角色正在經歷根本性的轉變。我們不再是程式碼的工匠；我們是意圖的設計師和系統的架構師。
SpecAgent 是我們在這個新時代最重要的夥伴。它讓我們能夠將精力集中在最有價值的人類活動上：批判性思考、溝通、問題定義和優雅系統模型的設計。
當我們掌握規格工程的藝術時，我們就掌握了與 AI 協作大規模演進複雜系統的關鍵。
📍 下一篇：第 7 天 - 自動化設計和文件。 我們將探索 SpecAgent 如何邁出下一步：從規格自動生成 C4 架構圖和序列圖，創建一個永不過時的「活文件」系統。
你認為在你的團隊中實施「規格工程」的最大挑戰是什麼？ 請在下方評論中分享你的想法！