規格驅動開發實戰

學員課前注意事項

規格驅動開發實戰:AI 時代的軟體開發新典範

課程簡介

我們公司近期開始導入規格驅動開發 (Specification-Driven Development, SDD)。在短短幾週內,我已經感受到在 AI 賦能的現在,全新的軟體開發典範正逐漸成形,並展現出極大的潛力。

各位可能很難想像,這種全新的軟體開發流程,可以對整個團隊的成員帶來多少價值。以往我們的專案經理經常需要對專案的大小事瞭若指掌,同時也需要產出不少文件,在一個開發團隊中,為了減少溝通問題,規格的重要性不言可喻。但對於工程師來說,規格僅僅是我們在真正開始寫程式之前用來搭建並最終丟棄的鷹架。你可以想想看,有多少人會在專案進行的過程中不斷更新「規格」文件?是不是大部分的人都是在修修改改的過程中,在最終交付成品之前才去撰寫必要的文件?有誰會在意「原始規格」寫了些什麼嗎?

我們在專案管理的過程中經常需要應付隕石等級的需求變更,整個過程經常難以掌控,即便我們公司已經導入了多年的敏捷框架,對於需求的變動也能有效控制,但專案在執行的過程中,團隊成員之間還是存在著許多溝通上的落差,這道鴻溝通常需要靠有經驗的 PM 才有辦法提早發現問題,很多時候都要等問題發生了,才會知道原來有人沒聽懂。越大的專案,這類溝通問題就會越嚴重,專案的耗損與成本也會越高。

在需求變化過程中,最初的「規格」經常變得不再重要。有時候,工程師不是不看規格,而是不願意看那些不夠成熟的規格書。首先,客戶或使用單位的人,天生就不會開規格,所以良好的規格本來就少見。再者,規格本身也需要具備敏捷性(Agile),需要能夠短期交付和頻繁迭代。但你知道誰最討厭頻繁迭代的規格書嗎?系統分析師、工程師、設計師!對!所有人!我就覺得奇怪,不是所有人都在擁抱敏捷嗎?怎麼改個規格就這麼反感!😅

工程師的謎之聲:「我最討厭修修改改的規格,都已經開工了,現在才跟我說不是這樣,又要改寫好測過的東西了,氣氣氣氣氣~」

總之,大家就是嫌麻煩,改規格就是一件會對所有人帶來困擾的事,修修改改就是煩,重點是文件更新很煩,程式架構要調整很煩,許多測試程式要重寫很煩,已經寫好的東西要打掉重練很煩。如果今天有個開發流程或好用工具,可以藉助 AI 的能力,幫助你隨時將「規格」轉換成「程式碼」,當你在更新規格的時候,隨時可以自動生成新版的程式碼,這樣是不是很完美?只要煩的工作不是「人」去做,那就不煩了吧!🤘

如果你們能親眼看我走一趟 SDD 的流程,就會知道這種透過 AI 輔助的規格驅動開發,只要施作得當,團隊中所有人都能獲益,並且大幅改善軟體開發的流程,更能大幅提高軟體產出的品質。

在傳統的軟體開發裡,程式碼一直是唯一真相,許多工程師也是堅信這一點。我長久以來也一直相信,良好的程式架構會比過時的文件來的有價值。所以在業界,規格文件、設計稿、架構圖,通常只是陪襯與指引,最終往往淪為過時的「歷史文物」。這樣的模式會讓需求和程式碼之間總是存在著落差──需求不斷在前進,而程式碼卻難以完全對齊。

規格驅動開發 (SDD) 正好打破了這種失衡。這不僅是一種小改進,而是一場權力的翻轉:程式碼不再是核心,規格才是真理。開發團隊的意圖、需求和設計,都透過精確的規格來表達,並由 AI 自動生成實作和測試。程式碼成為規格的「最後一哩」表達,而非創建過程的起點。

在這個新流程中,測試驅動開發 (Test-Driven Development, TDD) 的角色也被放大。過去 TDD 常被視為提升工程品質的良好實踐,但在 SDD 中,測試不再只是輔助,而是直接成為規格的一部分。規格先產出驗收條件,這些條件同時生成測試案例,再由程式碼去滿足測試。這使得「規格 → 測試 → 程式碼」三者完全一致,避免了過往需求與測試脫節、測試與實作不同步的問題。換句話說,TDD 不再只是開發技巧,而是貫穿 SDD 的核心流程。

不過,雖然說 SDD 與 TDD 的概念蠻直觀的,但實務在導入的過程中,還是經常會聽到同仁向我反應各種實作過程的疑惑,這些疑惑若沒有豐富的專案經驗打底,真的很難從一團迷霧中得到救贖。我為此特別設計了這堂課,希望能從一天 6 小時的過程中,帶領大家從一份原始的產品需求,透過 GitHub 的 Spec Kit 工具,落實規格驅動開發的流程,並體驗如何在其中自然地實踐 TDD,幫助大家更清楚地理解這個過程會帶來什麼樣的革命性變化。

本課程將會有 90 天的看課期限,你隨時可以從 規格驅動開發實戰:AI 時代的軟體開發新典範 課程頁面進入本班專屬的 Discord 頻道,學員可以在課後不斷進修與交流!

課程特色

  • 實戰導向:以真實案例演練,從需求到程式碼完整走一遍 SDD 流程
  • AI 融合:結合 GitHub Spec Kit 與多套不同的 AI Coding 工具,體驗如何用 AI 寫規格、出計畫、拆任務
  • TDD 融入:學會如何把測試條件寫進規格,並透過 TDD 驅動程式碼生成與驗證
  • 跨角色學習:同時兼顧 PM、工程師、架構師不同視角,理解溝通與落地的挑戰
  • 社群支持:課後專屬 Discord 頻道,延續討論與答疑
  • 可回放學習:90 天無限回看,幫助消化與反覆練習

報名連結

給學員的話

各位同學大家好:

寫規格根本不是什麼新鮮事,大家多多少少也都寫過規格,而 規格驅動開發 (SDD) 則是一個非常新穎的軟體開發流程,之所以會在這幾個月短期爆紅,完全是因為大語言模型已經足夠成熟,整件事我們都知道這一天會到來,現在只是水到渠成而已。

我在 2025/10/3 在 HappyDesigner Community Event 有一場 AI × Spec Driven Development (October 2025) 演講,影片已經釋出,建議大家都可以先看過,先養成一些關於 SDD 的基本觀念,對於上課的理解與吸收絕對有幫助。

這堂課主要會帶大家從頭到尾走完整個 規格驅動開發 的流程,我會採用 GitHub 推出的 Spec Kit 工具來示範整個流程,無論你是 PM 或測試人員,無論你是前端或後端工程師,只要你在一個軟體開發的過程中可以做出一些貢獻,都可以在這個流程中受益,我會在課程中帶大家釐清整個流程的盲點,也會回答大家許多實務面的問題,請準備好「疑惑」來上課。

我有定時對 Spec Kit 整個網站進行翻譯,大家可以追蹤我的 doggy8088/spec-kit 專案,上面都有最新版本的正體中文翻譯。

Spec Kit 正體中文版

由於 Spec Kit 是一個「實驗性」的開源專案,每天都在更新內容與規格範本,如果各位想要掌握近期的變更,也可以關注我整理的 Wiki 文件,我整理的文件可以幫助你更好的追蹤近期的變更: https://github.com/doggy8088/spec-kit/wiki

spec-kit wikis

當然,要能夠順利的導入 SDD 流程,還是有些門檻,我們會大量的藉助 AI 的力量幫助我們完成規格的制定,而且我認為規格制定的工作應該是由團隊大家一起協力完成的,而不是某個特定角色的工作,也不應該搞出一個「規格工程師」之類的職務出來。這件事當然也會牽扯到公司文化的問題,我都會在課堂上跟大家分享我的看法與見解,各位有問題也可以在我的 規格驅動開發實戰:學員提問專區 表單提問,我可以整理進課程,幫助大家釐清疑惑。

我們雖然是一整天 6 小時的課程,早上三小時,下午三小時,但理論上本課程不會給大家練習的時間,但你依然可以先準備好上課所需的工具與環境,隨時體驗 Spec Kit 與 SDD 帶來的強大威力,並在課堂上隨時提出你的任何想法與疑問。

以下文件將說明學員上課前的注意事項,請詳細閱讀並提前準備,有任何疑問都歡迎隨時來信或在本班的 Discord 頻道提問。

💡 提醒:你隨時可以從 規格驅動開發實戰:AI 時代的軟體開發新典範 課程頁面進入本班專屬的 Discord 頻道喔!

註冊 Discord 帳號

我們最近的課程都已經陸續將課程資訊集中到 Discord 伺服器管理,這是一個非常強大的社群工具,可以讓我們在課程之後也能夠持續交流,請大家先註冊一個 Discord 帳號,並且加入我們的多奇教育訓練 Discord 伺服器

加入多奇教育訓練 Discord 伺服器

加入 Discord 伺服器之後,進入本次課程專屬頻道的步驟如下:

  1. 進入 規格驅動開發實戰:AI 時代的軟體開發新典範 課程頁面

  2. 點擊畫面右邊的 加入 Discord 頻道,基本上可以「一鍵加入」才對,如遇到困難,請來信處理: training@miniasp.com

安裝 Git 工具

我們所有專案都有用 Git 版控,撰寫規格的過程中,理論上所有規格也都要進版控,所以使用 Git 是一個非常基本的技能。不過,就算你現在不會用,也不影響學習本次課程的內容就是了!

安裝 AI Agent 工具

由於 Spec Kit 是一套幫助您開始規格驅動開發的工具包,這個工具包依賴市面上一些知名的 AI 程式設計代理人工具 (Coding Agent) 才能運作。目前 Spec Kit 支援的 AI Agent 工具有:

Agent 支援狀態 備註
Claude Code  
GitHub Copilot  
Gemini CLI  
Cursor  
Qwen Code  
opencode  
Windsurf  
Kilo Code  
Auggie CLI  
CodeBuddy CLI  
Roo Code  
Codex CLI  
Amazon Q Developer CLI ⚠️ 不支援斜線命令

我們這堂課無法從頭教你使用這些工具,我有兩個相關的課程可以幫助你快速瞭解 AI Coding Agent 的使用方式,有興趣可以買來學習:

  1. GitHub Copilot 全方位實戰:協作×進階×代理人
  2. AI 程式設計代理人開發全攻略

不過,工具這麼多,我相信很多人會有一些選擇障礙,以下是我個人的經驗分享,提供各位學員參考:

  1. GitHub 非常喜愛 Claude Sonnet 4.5 這個模型,我可以說 Spec Kit 就是基於 Claude Sonnet 4.5 最佳化的,所以只要能用 Claude Sonnet 4.5 的 AI Coding 工具,都很適合拿來搭配 Spec Kit 使用。

  2. 因此我最推薦的工具是 Claude CodeGitHub Copilot 這兩套。

  3. 如果你選用 Claude Code,要用免費的額度來體驗 Spec Kit 幾乎不太可能,我會建議至少要購買每月 $100 美元的 Max 方案才能順利的使用,購買每月 $20 美元的 Pro 方案很容易就會被限流。

  4. 如果你選用 GitHub Copilot,要用免費的額度來體驗 Spec Kit 也是幾乎不可能的,我會建議至少要購買每月 $10 美元 Pro 方案才能順利的使用,如果不夠用的話,可以隨時升級到 Pro+ 方案,這個方案每個月才 $39 美元,而且幾乎用不完,我認為是 CP 值最高的 AI Coding 工具!

    除了用 VS Code 搭配 GitHub Copilot 之外,購買 GitHub Copilot 訂閱之後,你還可以使用 GitHub Copilot CLI 來實現整個 Spec Kit 流程,我實測效果跟 Claude Code 一樣好,因為背後都是採用 Claude Sonnet 4.5 模型!

Windows 用戶的注意事項

如果你是 Windows 用戶,可能會遇到比較多的障礙,因為每個人的 Windows 用久了都會很髒、很亂,環境變數亂七八糟的大有人在,所以我寫了三份文件,請大家自行選擇一個版本來安裝與設定。

  1. 如何在 Windows 作業系統安裝 Spec Kit 所需的工具與環境 (專家版)

    建議大家先用這個版本來安裝,這是最簡單的安裝方式,只要輸入我整理好的命令,就可以很順利的安裝到底!

  2. 如何在 Windows 作業系統安裝 Spec Kit 所需的工具與環境 (基礎版)

    這份文件寫的比較詳細,算是新手友善的版本,但是會花比較多時間手動安裝。

  3. 如何在 Windows 作業系統安裝 Spec Kit 所需的工具與環境 (Unicode)

    如果你的使用者家目錄(C:\Users\你的名字)包含「中文」字元,原本設計好的安裝過程可能會出現錯誤,此時建議參考這份文件下去重新安裝。

只要順利完成安裝,執行以下命令就可以檢查 Spec Kit 需要的工具支援是否完整:

specify check

你至少需要看到 Git version control 是綠燈,還有 GitHub CopilotClaude Code 或任何一套 AI Coding 工具是綠燈,環境就差不多設定完畢!

specify check

💡 關於 GitHub Copilot CLIClaude Code 的使用,各位學員可能要自行學習了!

macOS/Linux/WSL 用戶的注意事項

基本上,只要有 Bash 環境,無論用什麼終端機軟體,像是 macOS 內建的 iTerm 或自行額外安裝 iTerm2 都可以用。

你只是還要額外安裝 gituvNode.js 與 Spec Kit 的 Specify CLI 工具即可。另外也建議安裝 ripgrep 工具,因為 Claude Sonnet 4.5 很愛用。

我認為安裝這些工具最簡單的方式,應該是透過 Homebrew 套件管理器,如果你已經裝好 Homebrew 的話,就可以用以下命令自動安裝 git 與 uv 與 node.js 工具:

brew install git uv node ripgrep

接著安裝 Spec Kit 的 Specify CLI 命令列工具

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

安裝 AI Coding 工具,請自由選擇:

# 安裝 Copilot CLI
npm install -g @github/copilot

# 安裝 Claude Code
npm install -g @anthropic-ai/claude-code

最後檢查 Spec Kit 需要的工具支援

specify check

你至少需要看到 Git version control 是綠燈,還有 GitHub CopilotClaude Code 是綠燈 (任何一套都可以),環境就差不多設定完畢!

specify check

💡 關於 GitHub Copilot CLIClaude Code 的使用,各位學員可能要自行學習了!

上課前注意事項

由於我們上課時會採用 Zoom Workplace 桌面應用程式 軟體進行授課,因此請學員在上課前先安裝好 Zoom Workplace 桌面應用程式 軟體的最新版,並且測試好麥克風喇叭是否可以正常運作,以免上課時無法順利聽到課程內容。

以下幾點請在上課前確認完畢:

  1. 檢查 Zoom 是否為最新版本

    我這邊目前最新的 Zoom 版本為 6.6.1

    Zoom 版本

  2. 檢查 Zoom 麥克風與喇叭是否正常運作

    你可以透過 Zoom 的測試功能來檢查麥克風與喇叭是否正常運作,如果你的麥克風與喇叭都正常運作,你會看到以下畫面:

    Zoom 麥克風與喇叭測試

上課時的注意事項

🔥 請不要在最後一刻才進入教室 🔥

🔥 請不要在最後一刻才進入教室 🔥

🔥 請不要在最後一刻才進入教室 🔥

  1. 你可以在課程開始前 30 分鐘進入 Zoom 會議室

    我會在讓大家進入會議室時播放背景音樂,請確認可以聽的到聲音。

    若聽不到聲音,可以先檢查 Zoom 麥克風與喇叭的設定是否正確,或是重新退出 Zoom 會議室後再次進入。

    建議大家盡量不要使用「手機」進入 Zoom 會議室,因為手機的螢幕太小,上課體驗會比較差。但如果真的沒辦法,用手機也是可以上課,等日後看重播時用電腦看就好。

  2. 以下是進入會議室的步驟

    開啟 Zoom 軟體,點擊「加入會議」

    開啟 Zoom 軟體,點擊「加入會議」

    輸入我們課前通知的「會議號碼」與「顯示名稱

    輸入我們課前通知的「會議號碼」與「顯示名稱」

    輸入會議密碼

    輸入會議密碼

    測試喇叭和麥克風

    測試喇叭和麥克風

    請務必測試一下麥克風與喇叭是否正常運作,以免上課時無法順利聽到課程內容。

    請務必測試一下麥克風與喇叭是否正常運作,以免上課時無法順利聽到課程內容。

    進入會議室之後,如果聽的到聲音,就按下「回應」的 ✅ 按鈕。

  3. 多利用「回應」功能給予課程回饋

    過往有許多同學都找不到 Zoom 的「回應」功能,我特別截圖跟大家說明怎樣操作。

    Zoom Reactions

    基本上在 Zoom 最下方的工具列上,會有個「回應」的按鈕,按下去之後會有三排的表情符號可以按:

    第一排:這些表情符號按下之後可以表達你在課堂上的心情,而且 10 秒之後就會自動消失。這些表情非常重要,因為這可以讓講師知道你當下的心情,感覺開心的時候可以選 😂 (大笑),聽到很厲害的內容時可以按下 👍 (讚)、❤ (愛心)、👏 (拍手)、🎉 (獻花) 等表情,這可以讓課程變的相當活絡有趣!

    第二排:這些符號按下去之後不會自動消失,主要用來回應講師的提問,方便大家回答問題。例如講師問「大家都聽的到我的聲音嗎?」,你可以按下 ✅ (打勾) 來代表「聽的到」,或是按下 ❌ (打叉) 來代表「聽不到」,這樣講師就可以得知你的狀態。

    第三排:只有一顆「舉手」的按鈕,按下去代表你想要開麥克風發言,講師會看到你的舉手,然後依序讓你發言。先按「舉手」的人會排在最上面,講師會更容易看到你的舉手狀態。

    以下有幾個好用的鍵盤快速鍵給大家參考,上課時可以盡情使用,增加上課的趣味性:

    功能 Windows macOS
    快速開啟「回應」選單 Ctrl+Shift+Y Command(⌘)+Shift+Y
    傳送會議回應 [鼓掌] Alt+Shift+4 Option+Command(⌘)+4
    傳送會議回應 [讚] Alt+Shift+5 Option+Command(⌘)+5
    傳送會議回應 [愛心] Alt+Shift+6 Option+Command(⌘)+6
    傳送會議回應 [大笑] Alt+Shift+7 Option+Command(⌘)+7
    傳送會議回應 [驚訝] Alt+Shift+8 Option+Command(⌘)+8
    傳送會議回應 [慶祝/拉炮] Alt+Shift+9 Option+Command(⌘)+9
    舉手/放下手 Alt+Y Option+Y
    將音訊靜音/取消靜音 Alt+A Command(⌘)+Shift+A

    表1: Zoom 鍵盤快速鍵參考

  4. 利用【聊天室】來向講師或學員傳達訊息

    Zoom 軟體有個「聊天」功能,但請不要在「所有人」的視窗聊天,因為很多人一起聊天的結果,就是大家都找不到訊息。

    這個「聊天室」功能主要用來讓學員與講師之間的溝通,如果你有任何問題,可以在「聊天室」中發問,講師、助教或其他學員都會盡量回答你的問題。

    留言時,請務必在一個訊息中把問題打完,不要像 LINE 一樣,想到一句打一句,否則可能會不同人發問的問題之間交錯出現,導致閱讀困難。

    回覆留言時,請多利用「回覆」功能,讓一個問題的討論可以聚焦在同一個討論串內,這樣大家閱讀起來會比較清楚。

  5. 利用【麥克風】使用語音提問

    進入會議室之後,麥克風會處於「鎖定」的狀態,如有問題想透過語音發問,請先點擊 Zoom 軟體的「舉手」按鈕,講師會開啟你的麥克風讓你線上發問。

    如果講師需要學員進行語音互動時,願意發言的人,也可以先按下「舉手」等候講師呼喚,並準備開啟麥克風,這樣才不會花太多時間等待學員回應。

  6. 不開放【視訊】使用

    原則上我們上課不需要開啟視訊鏡頭,以確保大家的個人隱私。

上課連結

由於我們上課時會採用 Zoom Workplace 桌面應用程式 軟體進行授課,而上課的 Zoom 會議室連結實際上是會透過另外的郵件通知學員,郵件主旨會是:

【上課通知】規格驅動開發實戰:AI 時代的軟體開發新典範 1018

如果你在上課當天都還沒收到通知郵件,請立即寫信與我們聯繫!🔥