隨著生成式 AI（Generative AI）技術的爆發，許多企業開始思考：既然 AI 已經能寫程式，軟體開發是不是變得像按鈕一樣簡單？成本是不是會大幅下降？
AI 可以寫程式，但無法取代軟體開發
作為第一線技術團隊，我們的答案是：AI 確實提升了開發效率，但真正決定軟體品質的，從來不是程式碼本身，而是需求分析、系統架構、規格設計與品質驗證；AI 將開發者的角色從「程式碼的打字員」提升到了「系統架構的指揮官」。
本篇文章將與大家分享資通電腦技術團隊如何透過規格驅動開發（Specification-Driven Development，SDD）：先定義規格，再進行開發。在擁抱 AI 創新技術的同時，確保交付給客戶的系統具備企業級的穩定度、可擴充性與長期維護性。
為什麼企業不應只依賴 Vibe Coding？
在 AI 輔助開發的初期，業界流行一種被稱為「Vibe Coding（憑感覺寫程式）」的模式。開發者想到什麼就對著 AI 輸入提示詞（Prompt），AI 吐出程式碼後就直接貼上測試，這種方式雖然能快速完成原型開發或小型專案，但如果直接應用於企業級系統，就會因為缺乏完整規格與架構設計，容易累積技術債，影響系統品質與後續維護。
無使用 SDD 的 Vibe Coding，缺乏全局觀。當系統只有幾百行程式碼時，Vibe Coding 看起來很神奇；但當專案擴展到幾萬行、涉及複雜的商業邏輯與資安規範時，AI 會開始產生幻覺、邏輯衝突，甚至產出無法維護的「義大利麵條式程式碼（Spaghetti Code）」，讓整體結構錯綜複雜、控制流程混亂。這不僅沒有降低成本，反而會帶來巨大的技術債。
而使用 SDD 的開發模式時，我們會將「規格」放在首位。在讓 AI 寫下任何一行程式碼之前，先透過嚴謹的規格書來收斂需求，並藉由 SDD 確保 AI 在我們設定好的軌道上高速行駛，而不是盲目地橫衝直撞。
| 比較項目 | Vibe Coding（無 SDD） | SDD 規格驅動開發 |
|---|---|---|
| 小型專案 | 快速有效 | 需前期規劃時間 |
| 大型專案 | AI 產生邏輯衝突、難以維護的義大利麵條程式碼 | AI 在規格軌道上穩定運行 |
| 商業邏輯 | 邊界條件（Edge Cases）容易遺漏 | 規格書預先定義所有情境 |
| 長期維護 | 技術債快速累積 | 可維護性高，擴充成本可控 |
| 資安合規 | 難以確保每段程式碼符合規範 | 「專案憲法」約束 AI 產出 |
Vibe Coding 與 SDD 差異比較表
工程師的核心價值：定義「做什麼」與「為什麼做」
在與 AI 協作的過程中，我們深刻體會到：AI 很擅長解決「如何做（How）」，但只有人類能定義「做什麼（What）」與「為什麼做（Why）」。
- 核心價值 1. 制定不可動搖的「專案憲法」：在每個專案啟動之初，我們團隊的首要任務是制定「專案憲法」。這是一套系統層級的規範，包含架構設計原則、資料庫選型、資安邊界、錯誤處理機制以及 API 命名慣例。這些規範會成為引導 AI 的最高指導原則，確保 AI 產出的每一行程式碼都符合企業級標準，這正是技術團隊的專業價值所在：負責把關系統的靈魂與骨架。
- 核心價值 2. 向 AI說明「為什麼做」，打造真正的需求：在傳統的需求描述中，我們可能只會寫：「建立一個會員登入頁面」。但在 SDD 的流程中，我們更著重於向 AI 描述「為什麼要這樣做」。例如：「我們需要一個包含多因素驗證（MFA）的登入機制，因為系統將處理敏感的財務數據，我們必須防範憑證填充攻擊，同時確保高齡使用者的操作體驗不被打斷。」當我們將商業脈絡與目的（Why）清晰地傳遞給 AI 時，AI 不僅能產出登入功能的規格，還能主動盤點出潛在的邊界條件（Edge Cases）。這是人類領域知識與 AI 邏輯運算深度結合的展現。
SDD 實戰工具鏈：OpenSpec、SpecKit 與 Superpower
為了落實 SDD 應用，資通電腦技術部門建構了一套高度自動化且嚴謹的開發工具鏈。目前我們主要以 OpenSpec 與 SpecKit 作為規格規劃的核心，並在實作階段配合 Superpower 進行測試驅動開發（Test-Driven Development，TDD）。
OpenSpec、SpecKit 標準開發程序
我們將開發程序精煉為以下幾個關鍵階段，確保 AI 產出的準確性：
- 情境對齊（Context Alignment）：工程師將客戶的商業需求、專案憲法與「為什麼」輸入 OpenSpec 或 SpecKit。
- 規格生成與人工審查（Spec Generation）：產出結構化的系統規格草案。此時，資深工程師會介入審查，針對 AI 遺漏的商業盲點進行修正。
- 鎖定合約（Contract Lock-in）：規格確認無誤後，產出機器可讀的標準格式，成為開發階段唯一的真理（Single Source of Truth）。
- 透過規格的版本控制、跨團隊協作與變更管理，確保需求變動時，規格更新能即時同步至所有相關模組。
結合 Superpower 實踐 TDD 開發
進入實作階段時，我們不會直接讓 AI 寫業務邏輯，而是先讓 AI 根據規格產出測試案例（Test Cases）。工程師確認測試邏輯涵蓋了所有情境後，才讓 AI 撰寫實際的程式碼來通過這些測試。這種「先寫測試，再寫功能」的作法，將出錯機率降到了最低。
零妥協的品質防線：將單元測試做到極致
業界過去的常態是：大家都知道單元測試（Unit Test）很重要，但因為時程壓力，往往難以達到理想的涵蓋率。
現在，我們將這個痛點徹底翻轉。借助 AI 的強大算力與 SDD流程，把以前難以全面落實的單元測試，做得比以往都更踏實。每一次程式碼修改都會觸發完整的單元測試，AI 可快速補齊繁瑣的測試腳本，而技術團隊則能專注於設計更刁鑽的極端情境測試。這意味著交付的軟體不只是做得快，更具備了前所未有的堅固與穩定，讓AI 輔助開發帶來真正的品質躍升。
SIT / UAT：業務 Know-How 是 AI 無法取代的最後防線
雖然 AI 與 SDD 讓單元測試變得極致完善，但這並不代表我們可以將系統驗證完全交給機器。單元測試確保了程式碼邏輯的正確性，但系統是否真正契合真實的商業運作情境？這一點 AI 無法代勞。
在進入系統整合測試（System Integration Testing，SIT）與使用者驗收測試（User Acceptance Testing，UAT）階段時，我們依然高度依賴熟悉業務的客戶端使用者或領域專家。因為，只有真正懂業務的人，才能設計出符合實際作業情境的驗證案例，包含各種例外狀況與特殊流程，確保系統能因應真實的營運需求。
舉例說明，AI 可以確保資料庫正確扣除點數，但只有人類專家知道：當一位使用者在跨年夜進行大額結帳，卻遇到第三方金流瞬斷時，系統該如何符合公司內控流程來進行退款與客服提示。這凸顯了在 AI 時代，深厚的業務 Know-How 依然是軟體系統中最昂貴、也最有價值的資產。
AI 時代，高品質軟體來自「人 × AI」協作
回到最核心的問題：AI 讓軟體開發的成本變低了嗎？
精確的答案是：AI 改變了我們投資資源的位置。它讓工程師不再花費大量時間撰寫重複性的程式，而將更多心力投入架構設計、需求分析、規格定義與業務情境驗證上。
對企業而言，真正的競爭力並不是「使用 AI 寫了多少程式」，而是能否建立一套完善的開發流程，讓 AI 在正確的規格下發揮最大價值。
資通電腦系統整合開發服務（System Integration；簡稱 SI）將 AI 技術結合規格驅動開發（SDD）、測試驅動開發（TDD）及多年企業資訊系統建置經驗，打造兼具高品質、高安全性、易維護與可持續擴充的系統開發流程，協助企業降低開發風險，加速數位轉型，建立更具競爭力的資訊系統。
**本文章是由資通電腦資深工程師提出核心觀點，由AI 協作完成，與一般常見由 AI 生成再由人工潤飾不同，這也是我們認為在人與AI 協作中，人應該扮演的角色。
