拒絕爛代碼！SDD (規格驅動開發)：不可變更舊系統的 AI 現代化實戰指南

2026/01/14 更新2026/01/13 發佈閱讀 13 分鐘

前言：當 AI 遇上「絕對不能碰」的祖傳代碼

你是否也遇過這種情況？興致勃勃地將一段 15 年前的 Java 代碼丟給 AI，希望能重構得漂亮一點，結果 AI 自信地吐出了一段完美的代碼——引入了三個你的系統不支援的 Library、使用了你的編譯器看不懂的語法，甚至優雅地建議你「修改資料庫 Schema」——而那個資料庫可是全公司 20 個系統共用的心臟，連 DBA 都不敢正眼看它。

在綠地專案（Greenfield）中，AI 是飛天遁地的神隊友；但在充滿技術債、架構剛性且資料庫神聖不可侵犯的舊系統（Legacy System）裡，AI 的「現代化偏見」往往成為災難的源頭。它不懂為什麼你不能拆分微服務，不懂為什麼變數要叫 T_VAR_01，更不懂為什麼你絕對不能動那個 Stored Procedure。

這篇文章將提供一套硬核的作業工法——「規格驅動開發」（Spec-Driven Development, SDD）。教你如何在「應用層可重構，但資料層不可動搖」的極限條件下，馴服 AI 成為最忠實的修補匠。

1. 核心工法：規格驅動開發 (SDD) —— 讓 AI 閉嘴照做

面對舊架構，最危險的就是「氛圍編碼」（Vibe Coding）——即隨意給個 Prompt 讓 AI 發揮。在舊系統中，創意是毒藥，紀律才是解藥。我們需要導入 SDD (Spec-Driven Development)。

我們將開發過程鎖死為四個階段，並用以下流程圖來定義人機邊界：

SDD 的四個關鍵防波堤：

規格定義 (Specify)：這是「禁令清單」。明確告訴 AI 不該做什麼（例如：嚴禁引入新 Library、資料庫唯讀）。
技術規劃 (Plan)：在寫 Code 之前，強迫 AI 先交出「施工計畫」。這是你駁回「重構資料庫」這種危險想法的最佳時機。
任務拆解 (Tasks)：將計畫拆成原子化的任務清單。
實作 (Implement)：要求 AI 「測試先行」，確保重構不會破壞現有功能。

2. 四大實戰場景 (Scenarios)

這些不是理論，而是舊系統維護中最常見的「地獄場景」。我們來看看 SDD 如何一一化解。

場景 A：重構「上帝類別」 (The God Class)

狀況： 一個 5000 行的 OrderManager.java 包含了驗證、計算、資料庫存取所有邏輯。你需要提取 ValidationLogic，但很怕改壞。

SDD 策略： 要求 AI 執行特徵測試 (Characterization Tests)。
指令： 「在修改前，先為 OrderManager 寫 10 個測試案例，將目前的行為（包含錯誤的行為）錄製下來。重構後，這些測試必須全部通過。」

場景 B：修復「遠距離作用」的 Bug (Spooky Action)

狀況： 前端 JSP 頁面顯示金額錯誤，但前端代碼沒動過。問題可能出在後端某個共用模組的副作用。

SDD 策略： 利用全域搜索建立因果鏈。
指令： 「使用 Sourcegraph Cody 追蹤 totalAmount 欄位。找出從 DB 到 JSP 的所有轉換點，並與 spec.md 中的邏輯比對。」

場景 C：合規性批量升級 (Compliance Upgrade)

狀況： 資安稽核要求將全系統 50 個檔案中的 MD5 替換為 SHA-256。

SDD 策略： 規則驅動的批量編輯。
指令： 「根據 .cursorrules 中的安全規範，使用 Cursor Composer 掃描全專案。將所有 MD5 實例替換為專案內部的 CryptoUtils.hash256()，禁止使用 Java 原生 API。」

場景 D：不可變更資料庫的「絞殺榕」現代化 (The Immutable DB Trap)

狀況： 你需要新增一個複雜的「會員積點」功能，但資料庫是 Oracle，Schema 嚴禁變更，且欄位命名是令人崩潰的 T_VAR_01。

SDD 策略： 建立 防腐層 (Anti-Corruption Layer, ACL)。
架構示意：

指令： 「請為 T_MEMBER 表生成一個乾淨的 Java DTO Member。實作一個 Repository 負責將 T_VAR_01 映射為 Member.name。所有新業務邏輯只能操作乾淨的 Member 物件，不得直接觸碰 DB 模型。」

3. 實戰軍火庫：直接能用的 SDD 範本

為了確保大家能直接上手，我整理了五份核心範本。

注意：以下內容已格式化為代碼區塊，請直接點擊複製並存成 Markdown 檔案 (.md) 使用。

範本 A：舊系統專用 `.cursorrules` (防禦型配置)

用途： 放在專案根目錄 .cursorrules，強制 AI 遵守舊時代的規矩。

專案憲法 (Legacy Project Constitution)
You are an expert in legacy system maintenance. You prioritize STABILITY over modernity.

1. 資料庫絕對禁令 (DATABASE HARD CONSTRAINTS)
Schema Read-Only：嚴禁建議任何 DDL 操作（如 CREATE, ALTER）。
欄位映射：必須遷就現有的欄位命名（如 T_USR_NM），這不可更改。
Stored Procedures：若邏輯存在於 SP 中，必須調用它，不得在應用層重寫。

2. 代碼禁令 (Code Constraints)
禁止引入新依賴：嚴禁使用 npm install 或 Maven 添加新庫。
禁止語法升級：此專案運行於 Java 7。禁止使用 Lambda 或 Stream API。

3. 風格指南 (Style)
命名慣例：保持與周圍代碼一致。如果周圍使用 m_strName (匈牙利命名法)，請繼續使用。
日誌規範：使用 LegacyLogger.log()，禁止使用 System.out。

範本 B：規格書結構 (`spec.md`)

用途： 這是你（人類）主要撰寫的文件，用來定義任務邊界。

任務規格書 (Task Specification)

1. 業務目標 (Business Goal)
[簡述要達成什麼功能，例如：新增 VIP 會員折扣計算]

2. 範圍與邊界 (Scope & Boundaries)
涉及模組：BillingService, UserDAO
禁止觸碰：CoreKernel (絕對不要修改此檔案)

3. 技術約束 (Technical Constraints)
資料庫：只能讀取 T_VIP_RULES 表，不得修改。
輸出：計算結果不存 DB，直接回傳給前端 API。
錯誤處理：必須使用專案既有的 LegacyException，不要拋出 RuntimeException。

4. 驗證標準 (Acceptance Criteria)
[ ] 既有的普通會員計費邏輯不受影響 (Regression Test)
[ ] VIP 會員享有 9 折優惠
[ ] 無法連線 DB 時，應回傳 Default 費率

範本 C：計畫書結構 (`plan.md`)

用途： 要求 AI 生成的產物，需包含以下章節，供人類審查。

技術實作計畫 (Technical Plan)
1. 風險評估
[AI 分析] 修改 BillingService 可能影響 CheckoutProcess，需特別注意。

2. 擬定修改步驟
建立 VipDiscountStrategy 類別 (遵循防腐層模式)。
在 UserDAO 新增唯讀查詢方法。
更新 BillingService 調用新策略。

3. 回退計畫 (Rollback)
若新邏輯失敗，如何透過 Feature Flag 切回舊邏輯。

範本 D：任務清單 (`tasks.md`)

用途： AI 將計畫拆解為可執行的原子任務，供 Composer 執行。

任務清單
[ ] Task 1: 為 BillingService 現有邏輯撰寫 3 個單元測試 (Snapshot Testing)。
[ ] Task 2: 實作 VipDiscountStrategy 類別 (空實作)。
[ ] Task 3: 實作 UserDAO.findVipStatus 方法 (注意 SQL 語法相容性)。
[ ] Task 4: 整合邏輯並通過測試。

範本 E：SDD 架構師提示詞 (Prompt Template)

用途： 用這個 Prompt 叫 AI 讀取 spec.md 並生成 plan.md。

角色
你是一位極度謹慎的資深軟體架構師。

任務
請閱讀 spec.md 中的需求，並分析現有代碼庫。 請撰寫一份 plan.md，詳細說明你打算如何實作。

思考步驟
1.資料庫影響評估：確認此修改是否需要新的資料欄位？如果是，請提出「不修改 DB Schema」的替代方案。
2.全域風險掃描：列出此次修改可能影響的舊模組。
3.測試策略：說明如何驗證此次修改不會破壞現有功能。

輸出限制
請勿在此次回應中生成任何程式碼。 僅輸出 Markdown 格式的計畫書。

4. 推薦工具箱 (Toolbox)

⚠️ 核心策略：團隊工具必須統一

在介紹工具之前，必須強調一個生死攸關的策略：在舊系統維護中，嚴禁「自帶 AI 工具 (BYO-AI)」。

如果 A 工程師用 Cursor 並嚴格遵守了 .cursorrules 的安全規範，而 B 工程師用其他工具（可能忽略了專案規則配置）提交了代碼，SDD 的治理防線將瞬間瓦解。對於高風險的舊架構，一致性的紀律高於個人的工具偏好。團隊必須選定一套工具鏈並強制執行。

以下是我推薦的組合：

Cursor (主要開發)
- 推薦原因：它的 .cursorrules 強制力最強，且 Composer (多檔編輯) 模式能有效處理重構時的連鎖反應。是目前執行 SDD 流程的最佳 IDE。
- 官方連結：cursor.com
Sourcegraph Cody (全域檢索)
- 推薦原因：當系統跨越 10 個 Repo 時，Cursor 的本地索引會失效。Cody 能建立全域知識圖譜，告訴你「改了這裡，隔壁專案會不會爆」。
- 官方連結：sourcegraph.com/cody
RepoMix (上下文打包)
- 推薦原因：一個開源 CLI 工具，能把整個資料夾結構與代碼打包成 AI 易讀的格式。當你需要把一大包舊代碼丟給 Claude/GPT-4 時的神器。
- 官方連結：github.com/yamadashy/repomix
Unblocked (歷史考古)
- 推薦原因：它能整合 Jira, Slack 與 GitHub。當 AI 問「為什麼這裡要加 1？」，Unblocked 能幫你挖出 3 年前某個工程師在 Slack 上的抱怨，找出真正的上下文。
- 官方連結：getunblocked.com