Cake 2026 Build with AI

市場不會為爛產品買單！

Vibe Coding 讓你快速啟動，但「品質、維護、擴充」才決定產品能走多遠

林鼎淵 Dean Lin — 外商工程師 · 企業內訓講師 · 暢銷書作家

“
工具會過時，框架會淘汰，
但解決問題的思維，永遠有價值。
👤 講師簡介

關於講師

林鼎淵 Dean Lin

林鼎淵 Dean Lin

外商工程師 · 企業內訓講師 · 暢銷書作家

專注於 AI 開發工作流的實踐與推廣，協助企業導入 AI 輔助開發流程。
擅長將複雜的技術概念轉化為可落地的工作流程，讓團隊真正提升開發效率而非盲目追逐工具。

📚 出版 7 本專業書籍 🎤 超過 100 場講座 ✍️ 發表超過 400 篇文章
1 前置需求

開始前請先確認環境已就緒

電腦需要安裝以下工具，才能往後續流程操作

必要工具安裝
Terminal 安裝 Node.js（透過 nvm）
nvm install --lts nvm use --lts node -v
課程範例 Repository

下載 Repository 後，可以跟著課程進度操作，裡面有事先安裝好的 Agent Skills（放在 .agents 資料夾下）

Terminal Clone 課程 Repo
git clone git@github.com:deancourse/cake-2026-build-with-ai.git cd cake-2026-build-with-ai
還沒設定 SSH Key？

如果 clone 失敗，代表尚未設定 GitHub SSH 金鑰。 請參考 GitHub 官方教學 完成設定，或改用 HTTPS：https://github.com/deancourse/cake-2026-build-with-ai.git

設定 Agent Skills

第一次接觸的朋友，可以透過這支影片深入了解

因為每個 AI Agent 的路徑不同，可以使用 dotagents 來協助建立 symlinks。

Terminal 將 Agent Skills 同步到指定的 AI Agent
npx @iannuttall/dotagents
2 新專案

用 SDD 讓 AI 根據規格建立專案

規格驅動開發（Spec-Driven Development）— 讓 AI 不只寫程式，還幫你建立完善的規格文件

OpenSpec 初始化
為什麼需要 OpenSpec？
  • AI 寫程式越來越快，但專案越改越亂，甚至越改越壞
  • 關鍵人物離職，沒有文件，系統知識直接斷層
  • 解法：白話文對話 → AI 自動建立規格文件 → 根據規格驅動開發

📦 安裝與初始化

  • 選擇使用的 AI 工具（ex: Claude Code）
  • 產生 .claude 的 Agent Skills
Terminal 安裝指令
npm install -g @fission-ai/openspec@latest openspec init

⚡ Skills 與 Commands

  • Skills — AI 在對話過程中自動觸發的技能包，不需要背指令
  • Commands — 用 /opsx 前綴強制驅動：apply / archive / explore / propose
  • 可透過 openspec config profile 擴充更多 workflows
Prompt 查看 Skill
我想知道 openspec 目前安裝的 skill 用途 請使用表格呈現，用白話簡短描述
從零建立專案

🎯 Prompt 設計三要素

1
專案目標
大方向描述需求，AI 會釐清細節
2
使用技術
指定使用技術，便於團隊接手
3
細節討論
提醒 AI 主動提問，釐清模糊需求

使用「Plan Mode」，並請 AI 與自己釐清細節會得到更好的結果；下面 Prompt 是讓大家快速體驗完整流程

Prompt 建立 MVP 系統
設計車輛管理系統，包含以下功能： - 登入頁面（帳號密碼驗證，區分管理者與一般使用者） - 首頁儀表板（上方顯示關鍵數據卡片，下面顯示資料圖表） - 車輛管理頁（可檢視、新增、編輯、刪除車輛資料） - 員工管理頁（僅管理者可檢視、新增、編輯、刪除員工資料） 前端使用 React + Vite8，使用 MSW Mock API 模擬後端回應 參考 openspec 的 skill 執行，以最小可行性方案來規劃

📋 OpenSpec 自動建立規格文件

1
proposal.md
確認目標與範圍
2
design.md
技術選型與風險評估
3
specs/
按功能分類的詳細規格
4
task.md
任務清單，完成自動打勾
Prompt 開始實作
開始實作

🚀 啟動專案進行歸檔

第一次啟動可以請 AI 幫忙，因為 AI 有很高的機率在第一版遇到零星錯誤

Prompt 讓 AI 協助啟動
請幫我啟動專案

如果覺得外觀太過慘烈，可以讓 AI 參考 ui-ux-pro-max-skill 修正一下

Prompt 讓 AI 協助啟動
參考 UI/UX SKill 美化頁面

初步確認功能符合預期後，請他將變更歸檔

Prompt 歸檔
功能符合預期，進行歸檔
AI 正在改變企業決策

過去出缺勤、考核這類內部系統，企業通常找廠商購買、支付年費維護。但 Vibe Coding 的出現正讓企業做出不同的選擇。

有些企業導入 Vibe Coding 的目標不是取代工程師，而是讓熟悉業務的人有能力設計出符合使用需求的產品原型，再交給工程師做優化與維護。

用 OpenSpec 建立規格文件 — 就是讓這個交接過程有據可循，而不是一團無文件的程式碼丟過去。

建立專案規則

📐 生成 CLAUDE、OpenSpec 專案參考規則

CLAUDE.md 是給「做事」用的，openspec/config.yaml 是給「規劃」用的

Terminal 初始化規則
/init
Prompt OpenSpec 設定
Please read openspec/config.yaml and help me fill it out with details about my project, tech stack, and conventions

🗂 ️ 設計 README.md、.gitignore 並加入版控

初版完成後，要加入版控；未來更新時，才會清楚 AI 到底改了哪些細節

Prompt 設計 .gitignore、README.md
請幫我設計專案的「.gitignore」但「.claude、openspec」要加入版本控制 並且將「專案簡介與啟動方式」寫入 README.md

先使用內建的 AI 來 Generate Commit，Commit 後將變更 Sync Changes 更新上去

3 舊專案

根據情境設計 Skills，讓 AI 有執行依據

最難的不是 0 到 1，而是 1 到 100；透過 Skills 設計，讓 AI 在迭代功能、版本控制、Code Review 都有規範可循

OpenSpec 迭代

✨ 用 OpenSpec 新增新功能

Prompt 新增功能
增加使用者紀錄頁面，供管理者查看 使用 OpenSpec
Prompt 確認後實作
開始實作
為什麼 1 到 100 比 0 到 1 更難？

如果沒有規格文件，下次改功能時 AI 不知道之前的設計邏輯，可能把同一個功能重複寫好幾次，或改 A 壞 B。

用 OpenSpec 每次迭代都會在 Source Control 留下規格變更，AI 跟人類都有文件可以參考。關鍵人物離職最痛的不是少了一個人，而是系統知識直接斷層。

Prompt 歸檔變更
幫我歸檔

Tips: 不是所有事情都需要觸發 OpenSpec，像 branch 命名直接讓 AI 想就好

Prompt 新增分支
分析目前的變更內容，依照 camelCase 命名規則生成 feature branch 名稱，並建立與 checkout 該 branch
設定 Commit Skill

根據需求建立 Agent Skills，能實際給予幫助的，才是好的 Skill

📝 為什麼需要 Commit Skill？

  • 分析變更的檔案 → 判斷應拆成幾個 commit → 分段提交
  • 不同功能的修改分開 commit，讓邏輯可被追蹤
  • 保持好習慣：每做完一件事就 commit，不要多功能混一起
人工手打：耗時且風格不一致 AI 自動生成：長短隨機、中英混雜 解法：git-smart-commit Skill
Prompt 拆分 Commit
新增 commit
設定 PR Skill

🔀 git-pr-description Skill

  • 比對當前分支與目標分支的差異
  • 讀取 commit 訊息與變更檔案
  • 參考 pr-template 生成 Title 與 Description
Prompt 生成 PR
撰寫 PR，與 main branch 比對
人，才是 AI 的瓶頸

Code Review 的速度已經跟不上 AI 寫程式的速度。當人成為 AI 的瓶頸時，要去想的是如何降低門檻，而不是放棄審核。

設計 Commit、PR 的 Skill 就是透過優化流程讓開發更順暢。雖然每一步都是 AI 在執行，但如果沒有實務經驗，其實不知道怎麼串起這些工具。真正值錢的不是工具本身，而是知道什麼時候用、怎麼組合。

4 導入測試

讓維護與擴充更有底氣

市場不會為爛產品買單；加入自動化測試，是 Vibe Coding 從玩具走向產品的關鍵

🛡 ️ 為什麼 Vibe Coding 一定要測試？

1
穩定性
請 AI 修 bug，結果舊功能壞掉
2
複雜度
功能越多，人工測試越不可能覆蓋全部
3
擴充性
功能間有相依性，修改可能引發連鎖影響

不寫測試才浪費時間 — 測試讓你敢大膽修改，遇錯快速定位

建立適合專案的測試工作流

🔄 測試撰寫流程

1
建立資料夾
存放測試清單
2
AI 撰寫清單
類型、說明、輸入、期待輸出
3
人類 Review
確認情境有無遺漏
4
AI 撰寫測試
描述與文件一致
5
自主驗證
最多嘗試 5 次

下面以 command 指令形式強制觸發任務

Prompt 生成測試案例
/Gen Test Cases （拖入要測試的檔案，ex: src/pages/LoginPage.tsx）
從玩具到產品，差的就是測試

很多時候 AI 只是修好了眼前的錯誤，但過程中改壞了過去的邏輯。千萬不要嫌寫測試浪費時間，測試其實是在幫你加速開發。

現在儘管有 AI 輔助撰寫測試程式，我們還是要仔細檢查 AI 給的測試情境是否合理、有遺漏。

💡 實務建議

  • 不要一口氣生成所有測試，先放一個檔案確認結果符合預期
  • 每個頁面/模組有獨立的測試程式，方便定位問題
  • 測試案例會隨規格變更而調整，不可能一次到位
GitHub Action 自動化

🔁 自動化測試流程

  • 每次推送到 GitHub 都觸發測試
  • 測試完畢生成覆蓋率報告
  • 設定 Branch Protection Rule（ex: protected-by-tests）：測試通過才能合併到主分支（將 Require status checks to pass 打勾，然後輸入「test」）

測試覆蓋率不需追求 100%，重要的邏輯都要測試到。有了測試，規格書上的功能才能被真正驗證。

Prompt 自動化測試
我希望在 GitHub Action 加入自動化測試的流程 每一個分支將更新推送到 GitHub 都會觸發一次自動化測試
★ 總結

今天的三大主軸

🏗️

新專案 — SDD

OpenSpec: 讓 AI 產生完善文件後，用規格驅動開發，完成從零到一的步驟

⚙️

舊專案 — Skills

用 OpenSpec 迭代，並設計 Commit / PR Skills，讓 AI 在大型專案中有規範可循

🧪

導入測試 — CI/CD

設計讓 AI 撰寫測試的工作流，搭配 GitHub Action 守住品質底線

不可能掌握某個技能就變大師

講師設計的教材是最佳體驗路徑，但換到自己的專案情境一定會遇到不一樣的問題。回去後不要只是複製指令，而是把流程搬到自己的專案試一遍。

學習 AI 不是搜集指令複製貼上，更重要的是了解應用情境後，透過實踐調整為適合自己的工作流。

“
能判斷哪些流程需要自動化的，
只有每天在現場操作的你。

不管 AI 多強大，
按下同意時，責任就歸屬於你。
主題色彩
匯出