本篇文章更新時間：2026/01/18
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
OpenSpec：用規格把人類與 AI 對齊的一套開發流程
編輯前言：AI 寫程式已成為日常，但我們都知道它「很會寫，但不一定寫你要的」。OpenSpec 想解決的，就是這個需求不一致的老問題：讓人類與 AI 在寫程式前先「達成共識」。本篇讀後筆記整理自 GitHub – Fission-AI/OpenSpec。
核心觀點 (Key Takeaways)
- OpenSpec 的核心價值是：在寫程式前就先把規格鎖定，讓 AI 按照既定計畫產出可預期的結果。
- 採用「兩層資料夾」策略（specs 與 changes），讓「現況」與「變更」彼此分離，使修改既透明又可審核。
- 幾乎所有主流 AI Coding 工具都能整合 OpenSpec，從 Cursor、Claude Code 到 Copilot CLI，都有專屬 shortcut。
深入解析
OpenSpec 的定位很清楚：它不是要取代你的 AI 程式助手，而是補上「需求管理」這塊缺失已久的拼圖。
原文強調：如果需求散落在聊天紀錄裡，那 AI 的產出一定不可預測。於是 OpenSpec 做了最輕量的規格化流程，用規格把 AI 綁在軌道上。
「OpenSpec aligns humans and AI coding assistants with spec-driven development so you agree on what to build before any code is written.」
也就是說，OpenSpec 想做的是「先講清楚、再動手寫」。
以下是我覺得最重要的幾個環節：
-
Draft Proposal：需求先成形，不要直接寫程式
你跟 AI 說「我要 2FA」，它會自動建立一個 change proposal，包含 proposal.md、tasks.md、spec delta 等資料。 -
Review & Align：需求精煉迭代
規格會進行反覆討論，直到你與 AI 都 agree。這步驟非常像 mini PR review，但審的不是程式，是規格。 -
Implement Tasks：AI 寫程式，但完全對齊 spec
AI 會逐條完成 tasks.md 裡的任務，而且每一項都能記錄、核對。 -
Archive：把變更正式合併到 specs
最終把更新過的 spec delta 合併回 specs 資料夾，成為下一版「事實來源」。
這整套流程帶來的好處非常直觀：當你回頭看某個功能是怎麼演進而來，你會看到 proposal、tasks、spec delta，一切都是可追蹤、可審核、可查歷史的。
我特別喜歡它的「兩層資料夾模式」：
- openspec/specs：目前的真實世界狀態（source of truth）
- openspec/changes：所有未完成、正在提案中的變更
這讓新功能與修改舊功能的流程都變得清晰很多。
筆者心得與啟發
讀完 OpenSpec，我最大的感受是：這不只是一個工具，而是一種「補上 AI 時代缺失的軟體工程流程」。
我過去常遇到 AI 寫程式的兩大痛點：
- 需求散落在對話裡，過幾輪就忘了最初的目標。
- AI 有時候會「自行發揮」太多，導致返工。
OpenSpec 的流程就像一層保護網，避免這些混亂重演。透過 spec delta 與 tasks 這種明確可審核的 artifact，AI 的創作自由度變得可控，而不是無序。
特別是對於多人協作的專案來說：不同隊友使用不同 AI 工具（Cursor、Claude Code、Copilot、Windsurf 等），但全部人都能共享同一份 spec 與 changes，這套交付標準化的力量其實很大。
如果你正在大量使用 AI 寫程式，尤其是介於「0→1 建新功能」與「1→n 持續迭代」之間，我認為 OpenSpec 幾乎是必裝工具。它不只是讓 AI 按照你的意圖寫程式，更讓你對程式、對需求的掌控變得可視化、可追蹤、可審核。
換句話說：OpenSpec 幫 AI 程式助手補上了一塊真正的「工程流程」。