跳至主要内容

RAG 與規格：AI 驅動開發的雙引擎

· 閱讀時間約 8 分鐘
Bater Chen
Bater Chen
Senior Full-Stack Engineer

要讓 AI 成為開發工作流程中的核心生產力驅動者，我們需要兩個引擎同時運轉：檢索增強生成（RAG）和規格即程式碼（Spec as Code）。

現實檢驗：AI 編碼工具揭示的上下文問題​

當我第一次實驗 Claude Code 和 Gemini CLI 等 AI 編碼工具時，我注意到它們都會自動掃描專案並建立索引，生成像 CLAUDE.md 或 GEMINI.md 這樣的檔案來為 AI 模型提供上下文。

這引發了一個關鍵問題：

專案程式碼只是冰山一角。我們如何讓 AI 獲得系統的完整上下文視圖？

以我的 C# .NET 專案為例。除了 API 專案本身，還有 Swagger 文件、資料庫設計和存放在 Git 之外的規格文件。我開始使用 Git 子模組將相關專案整合到同一個資料夾中，讓 AI 代理可以交叉參考：

  • 根據 DB schema 變更自動同步 DTO 更新
  • 從 Swagger 定義生成單元測試和 API 驗證

但我很快就遇到了瓶頸：規格文件很少能自然地整合到 AI 索引工作流程中。即使 Confluence 和 Notion 提供 API 或 MCP 整合，它們永遠不會像原始碼那樣成為 AI 代理的一等公民。

我曾建議用 Git + Markdown 取代 Confluence，但由於 Git 的學習曲線，PM 拒絕了。妥協方案是採用 Atlassian 的 Rovo Dev CLI 來自動生成發布說明、更新 Confluence 和同步 Jira 狀態——大幅減少了營運開銷。

AI 的記憶挑戰：為什麼我們需要 RAG​

即使我們可以將所有文件——規格、業務邏輯、變更日誌、監控資料——轉換成 Markdown 或 JSON 並全部餵給 AI，我們也會立即面臨一個根本限制：上下文視窗是有限且昂貴的資源。

當我們盲目地將所有歷史對話、專案文件和程式碼傾倒給 AI 時，我們會遇到三個主要問題：

  1. 成本高昂：處理長上下文很昂貴
  2. 延遲痛苦：大量文字顯著影響 AI 回應時間
  3. 中間迷失：AI 很容易錯過埋在資訊過載中的關鍵細節

**檢索增強生成（RAG）**是為解決這個困境而設計的核心策略。它的工作原理如下：

歷史資料 + 企業知識 → 可搜尋資料庫
     ↓
當前查詢 → 相關資訊檢索 → 精確 AI 回應

RAG 預處理大量外部知識（內部文件、程式碼庫、歷史記錄）並將其儲存在可快速搜尋的知識庫中。當使用者提問時，RAG 系統首先從知識庫中精確檢索最相關的資訊，然後將其與原始問題一起提交給 LLM。這樣，AI 可以在一個聚焦、可管理的上下文中做出準確的回應。

RAG 實踐：建構企業第二大腦​

透過 RAG，我們可以將所有專案相關資訊——從規格和程式碼到測試報告和執行時日誌——轉變為一個「RAG 化」的全知企業第二大腦。這帶來了革命性的變化：

DevOps 智慧導航​

AI 助手從被動的問答機器演變為主動的導航系統。它們可以根據錯誤日誌從 runbook 中自動檢索解決方案，或在檢測到程式碼變更時主動警告可能受影響的模組。

範例：

傳統方法：
開發者：「我想新增一個支付方式」
結果：忘記檢查現有的支付抽象層，重新發明輪子

RAG 驅動：
開發者：「我想新增一個支付方式」
AI：「我找到了你在 PR#247 中設計的 PaymentAdapter 介面。
     我建議實作 ApplePayAdapter 並參考
     StripeAdapter 的錯誤處理邏輯。別忘了更新
     payment-config.yml 和相關測試案例。」

加速知識轉移​

新團隊成員可以透過與 AI 助手對話快速掌握專案歷史和技術細節，大幅縮短入職時間。

自我修復回饋循環​

AI 可以將過去的錯誤資訊和解決方案納入知識庫，從失敗中學習並持續最佳化其建議和自動化工作流程。

規格即程式碼：意圖驅動開發的核心​

當規格變得可執行和可驗證時，我們就進入了「規格驅動開發」的時代。這意味著規格不再只是靜態文件——它們擁有程式碼的許多特性：

團隊對齊的錨點​

規格作為團隊溝通、辯論和建立共識的基礎。它們也是人類和 AI 之間的共享契約——規格不僅被人類團隊成員閱讀，也為 AI 成員提供上下文參考。

超越程式碼的完整性​

程式碼是規格的「有損壓縮」。好的規格文件可以完整捕捉業務邏輯、決策過程和價值觀。

多目標生成能力​

就像原始碼編譯到不同架構一樣，好的規格可以生成 TypeScript、Rust、文件、教程，甚至 podcast 內容。

可測試性​

我們可以為規格編寫測試，確保 AI 生成的程式碼符合預期。在 AI 開發工作流程中，**「提示 + 驗證測試」**成為新的「真相單位」。

OpenAI 模型規格：最佳實踐範例​

OpenAI 的模型規格展示了優秀的實踐：

  • 使用 Markdown 格式——人類可讀且可版本控制
  • 每個條款都有對應的測試案例
  • 跨團隊協作：產品、法務和研究團隊都有貢獻

還記得 GPT-4o 的諂媚問題嗎？正是因為有清晰的規格，團隊才能快速識別和修復問題。規格成為信任的錨點。

實施策略​

1. 提示作為原始碼​

  • 版本控制：像管理程式碼一樣管理提示
  • 測試驗證：確保提示輸出品質
  • 安全分離：避免硬編碼敏感資訊

2. 為 AI 編寫的文件​

  • 使用 Markdown 格式以便 AI 更好地理解
  • 減少 LLM 難以處理的圖片和複雜列表
  • 同時考慮機器和人類的可讀性

3. 結構化輸入/輸出​

  • 輸入：Markdown → 更好的 AI 理解
  • 輸出：JSON + Schema → 更精確的結構化資料

品質保證與開發者的新角色​

在這個新範式中，開發者角色和品質保證方法也隨之演進：

從「創作者」到「協作者」和「編輯者」​

開發者需要投入更多精力來審查、引導和修正 AI 輸出。

溝通成為核心技能​

最好的溝通者將成為最好的程式設計師。「編寫能完全捕捉意圖和價值觀的規格」成為最稀缺的技能。

擁抱 TDD​

堅持 紅 → 綠 → 重構 循環。測試是確保 AI 輸出正確可靠的關鍵保障。

系統化評估​

建立類似 APM 的 QA 指標，持續監控 RAG 系統的檢索品質、分塊策略有效性和 LLM 回應保真度——這些是確保整體系統可靠性的基礎。

前方的道路：挑戰與機遇​

常見的實施挑戰​

「如果 RAG 檢索不準確怎麼辦？」

  • 建立回饋機制：開發者可以將結果標記為「相關」或「不相關」
  • 定期分析檢索日誌並調整策略
  • 使用混合檢索（關鍵字 + 語義搜尋）

「編寫規格不會拖慢開發嗎？」

  • 初始投資較高，但在 2-3 個 sprint 後效益會顯現
  • 從關鍵功能開始，逐步擴展
  • AI 可以幫助生成規格草稿，減少從零開始的時間

「我們如何確保 AI 不會產生有問題的程式碼？」

  • 建立多層保護：靜態分析 → 單元測試 → 整合測試 → 程式碼審查
  • 為 AI 輸出設置「斷路器」：當複雜度超過閾值時人類介入
  • 透過信心評分持續監控 AI 輸出品質

成功指標：衡量轉型​

RAG 品質指標​

  • 檢索準確率：找到相關文件的百分比
  • 回應一致性：類似問題是否得到一致的答案
  • 知識庫覆蓋率：團隊知識「RAG 化」的程度

規格品質指標​

  • 完整性分數：規格對功能和非功能需求的覆蓋
  • 可測試性指數：可以自動生成測試案例的規格比例
  • 實作對齊度：最終程式碼與規格的一致性

AI 輸出品質指標​

  • 首次通過率：AI 生成的程式碼首次通過測試的百分比
  • 人類調整率：需要手動修改的程式碼比例
  • 回歸錯誤率：AI 變更造成新問題的頻率

結論：雙引擎開發時代​

要讓 AI 成為開發工作流程中的前線夥伴，我們需要兩種能力協同運作：

RAG：智慧記憶​

  • 給 AI 上下文背景，減少誤判和幻覺
  • 將團隊知識轉化為可查詢的智慧資產
  • 建立持續學習和演進的機制

規格：精確的溝通語言​

  • 幫助 AI 理解你想要什麼，精確實現需求
  • 成為人類團隊協作的共識基礎
  • 驅動測試自動化和品質保證

開發者的新使命​

未來的工程師不會是獨行俠式的程式碼工匠，而是與多個 AI 代理協作的架構師、品質守門員和系統思考者。

關鍵洞見：我們不是被 AI 取代——我們是與 AI 一起演進成更強大的開發團隊。

接下來是什麼？​

未來屬於掌握這種雙引擎方法的團隊。今天投資 RAG 基礎設施和規格驅動開發的組織，明天將擁有顯著的競爭優勢。

問題不是 AI 是否會改變軟體開發——而是你的團隊是引領還是跟隨這場轉型。

覺得這篇文章有幫助嗎？ 👍 按讚支持，📤 分享給需要的同事！