從隨興寫扣到可維護的開發：Vibe Coding 帶給我的規格思維
參加 Vibe Coding 實戰課程前，我以為重點會是如何寫出更精巧的提示詞，讓 AI 更快產生程式，或學會幾個自動生成的技巧。
沒想到課程一開始，我就發現自己對 Vibe Coding 的想像終究還是太淺了。課堂介紹的 OpenSpec 規格驅動工作流，大大開了我的眼界。
今天上課真的收穫很多，忍不住想趕快留下這份紀錄。尤其是當 AI 寫程式愈來愈快，我們能不能說清楚它為什麼改、改到哪裡，以及憑什麼判定完成？
原型跑得動之後，誰來說明它為什麼這樣做？
用幾句自然語言請 AI 搭出原型，確實方便。但當成果需要長期維護，單靠對話與「看起來可以用」，就容易遇到三個問題：
- 需求容易漂移。 多輪修改後，最初的限制可能被忽略；新增一項功能，也可能影響原本正常的行為。
- 決策難以追溯。 即使程式有版本紀錄，仍未必看得出某段業務邏輯為何改變、由誰確認，以及依據哪項需求。
- 驗收缺少共同標準。 沒有事先說清楚成功條件，開發者與使用者可能對「完成」各有解讀。
這些問題並非 AI 開發獨有，只是快速生成與修改，更容易讓它們被忽略。
規格先行，把對話變成可檢查的約定
規格驅動開發（Spec-Driven Development，SDD）的重點，是在實作前寫清楚問題、改動範圍與驗收條件。
OpenSpec 將這些約定放進專案文件，協助人與 AI 對齊需求；還沒想清楚時，也能先探索。OpenSpec 入門文件
以下整理五個協作環節；實作發現新資訊時，可以回頭修訂文件，並非只能向前的流水線。OpenSpec 工作流說明
使用前：先請 Codex 安裝 OpenSpec
這次課程使用的是 Codex 桌面版。開始前，可以直接在對話中請 Codex：「請幫我安裝 OpenSpec，並在目前專案初始化 Codex 的工作流。」安裝與初始化完成後，再依它列出的技能名稱操作；若過程需要權限，依介面提示確認。
以下以 Codex 的技能呼叫為主，同時保留 IDE 斜線指令，方便對照。
1. 提案與對齊：先說清楚「為什麼做」
- Codex 桌面版：
$openspec-propose - IDE 斜線指令：
/opsx:propose
建立變更。在預設的 spec-driven schema 下，產出提案 proposal.md、規格 specs/<功能>/spec.md、設計 design.md 與任務清單 tasks.md。OpenSpec 指令參考
AI 協助起草，人確認業務目的、權限、資料限制與驗收條件；文件齊全不等於內容正確。
2. 依序實作：讓任務有依據，也留下結果
- Codex 桌面版：
$openspec-apply-change - IDE 斜線指令：
/opsx:apply
依任務清單實作並更新完成狀態。OpenSpec 指令參考
把必要測試列進任務，保存執行結果，並檢查改動範圍，讓清單上的勾選有成果支撐。
3. 校驗與驗收：檢查「做了」是否等於「做對了」
- Codex 桌面版：
$openspec-verify-change - IDE 斜線指令：
/opsx:verify
檢查需求是否有對應實作、程式是否符合規格，以及設計是否落實。這是可選的擴充工作流，需依設定啟用。OpenSpec 指令參考
AI 協助找落差，但仍需實際測試、程式審查與業務驗收。
4. 規格同步：把確認後的變更納入正式規格
- Codex 桌面版：
$openspec-sync-specs - IDE 斜線指令：
/opsx:sync
將增量規格合併到 openspec/specs/，也可在歸檔時處理。OpenSpec 常見問題
同步不會從程式自動反推需求。實作若有調整，要先確認合理性、修訂文件，再同步。
5. 歷史歸檔：保留一次變更的脈絡
- Codex 桌面版：
$openspec-archive-change（課堂寫法：$openspec-archive） - IDE 斜線指令：
/opsx:archive
封存變更文件，保留規劃與任務紀錄。未完成的任務可能只觸發警告，因此歸檔不代表通過驗收。OpenSpec 指令參考
完整追溯還需串起程式版本、測試、審查與核定紀錄。
指令使用提醒： Codex 使用技能呼叫；IDE 斜線指令的格式則依整合工具不同。本文保留課堂的
$openspec-archive寫法，實際操作仍以安裝後顯示的名稱為準，五個環節也不必每次都逐一執行。OpenSpec 工具整合說明
只是寫個小工具，也需要完整流程嗎？
不一定。一次性、容易重做、出錯影響很小的腳本，通常不必套用完整 OpenSpec；反覆使用或交給同事的小工具，則值得留下基本規格。
用完就丟的資料整理，或在測試資料上摸索套件與 API，可以先快速試作。
但即使只跑一次，若會覆寫資料、刪除檔案或更動正式資料庫，仍要確認操作範圍，準備預覽、備份或還原方式。
小工具的維護負擔，常在追加功能或交接時出現。例如原本只把 SHP 轉成 GeoJSON，後來又加入面積計算與無效值過濾；若沒記錄座標系統、輸出條件與異常處理，就難以判斷修改有沒有影響既有結果。這是示意情境，但也提醒我：省下今天的紀錄，可能換來明天重新理解程式的時間。
人負責決策，AI 協助把決策落實
這堂課讓我重新看見工程經驗的價值：AI 可以協助實作，人仍要決定需求取捨、資料邊界與驗收標準。規格也可能漏寫，模型也可能誤解，因此文件與測試仍需有人檢查。
下一次使用 AI 開發，我想先問清楚：要解決什麼問題？哪些邊界不能越過？看到什麼證據，才算完成？
從「快點寫出來」走向「知道它做對了」，是今天最想留下的收穫。
技術流程依 OpenSpec 官方文件於 2026 年 10 月 12 日查核；實際指令與產物可能隨版本、整合工具及 schema 設定不同。文中的治理做法與心得為作者對課程的整理與延伸。
沒有留言:
張貼留言