AI時代的開發轉變：為什麼「Spec 規格書」成為第一優先？
一、前言：開發模式正在被重寫
過去，軟體開發的核心能力是「如何寫出正確的程式碼」。
但在生成式 AI（如 ChatGPT、Claude）普及之後，開發流程發生了根本性的轉變：
👉 寫 code 的成本趨近於 0，但「寫對需求」的成本變得極高。
因此，Spec（規格書）不再只是輔助文件，而是：
🔴 直接決定 AI 輸出品質的核心輸入（Prompt Interface）
二、過去 vs 現在：開發流程的典範轉移
🏗️ 傳統開發流程（Pre-AI Era）
- 需求（模糊）
- 設計
- 工程師寫 code
- 測試 / debug
- 反覆修改
👉 問題：
- 規格可以不完整（工程師會補）
- 知識集中在「人」身上
- 修改成本高（每次都要改 code）
🤖 AI 驅動開發流程（Post-AI Era）
- Spec（高度明確）
- AI 生成 code / test / 文件
- 驗證輸出
- 微調 Spec（不是 code）
👉 核心改變：
| 面向 | 傳統開發 | AI 時代開發 |
|---|---|---|
| 開發主體 | 工程師 | Spec + AI |
| 成本重點 | 寫 code | 定義需求（Spec） |
| Debug方式 | 修改程式碼 | 修改 Spec |
| 知識位置 | 工程師腦中 | 文件（Spec） |
三、為什麼 Spec 變成 AI 開發的核心？
1️⃣ AI 是「Spec 驅動系統」
AI 不理解「你的意圖」，只理解：
👉 你寫出來的文字
因此：
- Spec = Prompt
- Prompt = 行為定義
如果 Spec 不清楚：
❌ 模糊需求 → AI hallucination
❌ 邏輯不完整 → 錯誤流程
❌ 邊界沒寫 → bug
2️⃣ Spec 成為「單一真實來源（Single Source of Truth）」
在 AI 開發中：
- code 可以重生（re-generate）
- 但 spec 是唯一穩定來源
👉 類似：
- Infrastructure as Code（IaC）
- 現在是 👉 System as Spec
3️⃣ Spec 決定可維護性與可擴展性
好的 spec 具備：
- 模組化（modular）
- 可組合（composable）
- 可測試（testable）
這直接影響：
👉 AI 能不能穩定生成大型系統
四、好 Spec vs 壞 Spec（實務對比）
❌ 壞 Spec（常見）
做一個登入系統，有帳密登入就好
問題：
- 沒有錯誤處理
- 沒有驗證規則
- 沒有安全機制
- 沒有 API 定義
✅ 好 Spec（AI-ready）
## Login System Spec
### Input
- email: string (RFC 5322 format)
- password: string (min 8 chars)
### Process
1. Validate email format
2. Check password hash (bcrypt)
3. If failed > 5 times → lock account 10 mins
### Output
- success: JWT token
- failure: error code (INVALID_CREDENTIALS / LOCKED)
### Edge Cases
- empty input
- SQL injection attempt
👉 差別：
- 可被 AI 直接轉成 code
- 可被測試
- 可被驗證
五、Spec 在現代 AI 工具中的角色
以下工具其實都在「吃 Spec」：
- Cursor
- GitHub Copilot
- Claude Code
👉 本質：
你不是在寫程式，你是在「設計 AI 要怎麼寫程式」
六、未來趨勢：Spec Engineering 將成為新職能
未來可能出現的新角色：
🧩 Spec Engineer（規格工程師）
負責：
- 定義系統行為
- 設計 prompt / spec
- 控制 AI 輸出品質
🧠 Prompt Architect
負責：
- 設計 AI workflow
- chaining / tool usage
- multi-agent coordination
🔄 Spec-driven CI/CD
未來流程：
Spec → AI → Code → Test → Fail → 改 Spec → 再生成
👉 Code 變成「暫時產物」
七、實際範例：Spec 驅動開發流程
Step 1：寫 Spec
Feature: 訂單系統
- 建立訂單
- 計算總價（含折扣）
- 支援優惠碼
Step 2：丟給 AI（如 ChatGPT / Claude）
👉 產出：
- Backend API
- DB schema
- Unit test
Step 3：測試後發現問題
👉 不改 code，改：
新增：
- 優惠碼不可重複使用
- 訂單需紀錄使用者 ID
Step 4：重新生成
👉 系統自動修正
八、優缺點分析
👍 優點
- 開發速度極快
- 降低工程門檻
- 可快速迭代
- 文件與系統一致
👎 缺點
- 對 Spec 能力要求極高
- 容易產生錯誤但看不出來（AI 自信錯誤）
- 缺乏 implicit knowledge（經驗）
九、結論：從 Code Engineer 到 Spec Engineer
未來的核心能力不再是：
❌ 「我會寫什麼語言」
而是：
✅ 「我能不能精準定義問題」
留言
張貼留言