👤 講師簡介
關於講師
林鼎淵 Dean Lin
外商工程師 · 企業內訓講師 · 暢銷書作家
專注於 AI 開發工作流的實踐與推廣，協助企業導入 AI 輔助開發流程。
擅長將複雜的技術概念轉化為可落地的工作流程，讓團隊真正提升開發效率而非盲目追逐工具。
AI 寫程式讓產能暴增，但「品質、維護、擴充」才決定產品能走多遠
工具會過時，框架會淘汰，
但解決問題的思維，永遠有價值。
專注於 AI 開發工作流的實踐與推廣，協助企業導入 AI 輔助開發流程。
擅長將複雜的技術概念轉化為可落地的工作流程，讓團隊真正提升開發效率而非盲目追逐工具。
一句話 AI 就能生成有前端、後端、資料庫的系統，但...你敢用嗎？
這代表你已經進入了下一個階段，開始思考如何讓 Vibe Coding 的成果真正可靠。
其實在沒有 AI 的時代，這些問題就已經存在；但 AI 寫程式速度太快，所以這些問題被加倍放大。
風格不一致，留下多餘程式，增加 Code Review 負擔。讓 AI 根據規格文件做事，完成從 0 到 1 的建立，更處理從 1 到 100 的迭代邏輯可被追朔、定義 Branch 命名規則、設計 PR 方便 Code Review新功能符合預期，舊功能執行穩定，並透過測試覆蓋率報告了解實際狀況版本控制與分支策略，確保出包時有回頭路，以及不影響到正式版本檢查格式、測試功能，並設定要保護的 Branch網頁版的 AI 只能告訴你該怎麼做，AI Agent 能直接幫你完成工作。
1. 需要打開瀏覽器操作： 開啟新對話後，又得重講專案背景
2. 難以給予完整上下文： 手動複製程式碼、錯誤訊息，AI 無法了解專案全貌（功能相依性、資料夾結構），容易誤判
3. 要自己手動修改程式： AI 給予答案後，你要自行編輯程式，但容易發生貼錯、少貼的狀況
4. 驗證與測試要自己做： 不管提示詞再好，AI 還是可能犯錯，來回溝通成本高
1. 看到整個專案的檔案和程式內容：不只是一段段貼給 AI，而是讓 AI 了解你全部的程式脈絡，減少誤判。
2. 可以直接增修檔案執行指令：在調整完程式後，可以直接測試確定符合預期，不需要複製貼上來回確認。
3. 查專案非常方便：專案功能對應的程式、函式呼叫路徑，甚至可以知道當初是誰寫的這段程式。
社群媒體上，好像每個人用 AI 就能輕鬆完成專案，但我卻處處碰壁。
把AI 能做到的事跟人必須負責的判斷分清楚。
讓 AI Agent 執行很久，不一定最強；我不認為對專案毫無掌控度是件好事。
好的結果，不該靠消耗 Token 拼運氣；而是靠清楚的方向、可重複的工作流、以及人類在關鍵節點的決策。
人的精力有限，技術是學不完的；要先培養出辨識問題的能力，然後思考如何解決，工具只是在過程中學會罷了。
現場遇到的問題都是不同的，沒有現成的解決方案，就要自己設計出來。
.claude/ 就像給 Claude 一本專屬手冊：告訴它你是誰（設定）、你可以做什麼（權限）、你想怎麼做（規則）、你希望它自動完成什麼（技能），以及特別的角色（代理）。
專案層級放在 your-project/.claude/，使用者層級放在 ~/.claude/，兩者會合併生效，專案設定優先。
1. MCP：透過標準介面呼叫其他工具的 API，操作方式較穩定、可預期
2. Rules：每次對話都會參考，通常不會寫太多，因為會佔用到上下文的空間
3. Skills：把日常工作中執行任務的細節、技巧、判斷模式放進去，AI 遇到相關任務時會主動觸發
4. Commands：可以設計完整工作流（ex: 執行多個 Skills），要手動觸發
AI 會執行的指令是無法完全預期的，為了減少悲劇發現，我們可以透過設定來阻止。
| 模式 | 無需詢問即可執行的操作 | 最適合 |
|---|---|---|
| default | 僅讀取 | 入門、敏感工作 |
| acceptEdits | 讀取、檔案編輯和常見檔案系統命令（mkdir、touch、mv、cp 等） | 迭代您正在審查的程式碼 |
| plan | 僅讀取 | 在變更前探索程式碼庫 |
| auto | 所有操作，具有背景安全檢查 | 長時間執行的任務、減少提示疲勞 |
| dontAsk | 僅預先批准的工具 | 鎖定的 CI 和指令碼 |
| bypassPermissions | 除受保護路徑外的所有操作 | 僅隔離容器和 VM |
：可以按 Shift+Tab 循環「default → acceptEdits → plan」
啟動時：可以用「claude --permission-mode plan」來設定
如果想知道目前對話消耗多少文本（Context），或是剩餘額度（Rate Limit），建議設定 Status Line。
這可以避免當 Context 被自動壓縮（Compact）、Claude 忘記前面資訊、額度耗盡時，你完全沒有意識到。
在 AI 時代，寫了多少行程式、完成幾個 feature、修了多少 bug，已經不像過去那麼重要了。
但如果能把某個協作環節變順，讓大家少踩坑、少重工、少在無聊的事情上浪費時間，那會給你帶來 Credit 與 可累積的職涯資本。
比起讓 AI 永不犯錯，更重要的是設計當 AI 犯錯時警告的通知！
下載 Repository 後，可以跟著課程進度操作，裡面有事先安裝好的 Agent Skills（放在 .agents 資料夾下）
如果 clone 失敗，代表尚未設定 GitHub SSH 金鑰。
請參考 GitHub 官方教學 完成設定，或改用 HTTPS：https://github.com/deancourse/cake-2026-build-with-ai.git
1. AI 有一定隨機性：即使有 Rules 規範，AI 生成的格式（ex: 縮排、引號）可能每次都不一樣，而且有可能動到原有邏輯。
2. 加上 Pre-commit：Commit 前確保專案 Coding Style 一致性、測試都通過。
雖然課程講的是 Claude Code，但 Cursor、Codex、Antigravity 這些主流工具都支援 MCP / Rules / Commands / Skills。
每個 AI Agent 的路徑稍不同，可以使用 dotagents 來協助建立 symlinks。
/opsx 前綴強制驅動：apply / archive / explore / proposeopenspec config profile 擴充更多 workflows使用「Plan Mode」，並請 AI 與自己釐清細節會得到更好的結果；下面 Prompt 是讓大家快速體驗完整流程
第一次啟動可以請 AI 幫忙，因為 AI 有很高的機率在第一版遇到零星錯誤
初步確認功能符合預期後，請他將變更歸檔
過去出缺勤、考核這類內部系統，企業通常找廠商購買、支付年費維護。但 Vibe Coding 的出現正讓企業做出不同的選擇。
有些企業導入 Vibe Coding 的目標不是取代工程師，而是讓熟悉業務的人有能力設計出符合使用需求的產品原型，再交給工程師做優化與維護。
用 OpenSpec 建立規格文件 — 就是讓這個交接過程有據可循，而不是一團無文件的程式碼丟過去。
CLAUDE.md 是給「做事」用的，openspec/config.yaml 是給「規劃」用的
初版完成後，要加入版控；未來更新時，才會清楚 AI 到底改了哪些細節
先使用內建的 AI 來 Generate Commit，Commit 後將變更 Sync Changes 更新上去
如果沒有規格文件，下次改功能時 AI 不知道之前的設計邏輯，可能把同一個功能重複寫好幾次，或改 A 壞 B。
用 OpenSpec 每次迭代都會在 Source Control 留下規格變更，AI 跟人類都有文件可以參考。避免關鍵人物離職後，系統知識直接斷層。
市場不會為爛產品買單；加入自動化測試，是 Vibe Coding 從玩具走向產品的關鍵
很多時候 AI 只是修好了眼前的錯誤，但過程中改壞了過去的邏輯。千萬不要嫌寫測試浪費時間，測試其實是在幫你加速開發。
現在儘管有 AI 輔助撰寫測試程式，我們還是要仔細檢查 AI 給的測試情境是否合理、有遺漏。
先放一個檔案確認結果符合預期獨立的測試程式，方便定位問題不可能一次到位重要邏輯都包含在測試程式內，才是最重要的；有了測試，規格書上的功能才能被真正驗證。
不同部門、團隊都有自己的工作流，專案也有各自的情境；而 Agent Skills 讓每次達成的目標，成為下次的起點。
根據需求建立 Agent Skills，畢竟能實際給予幫助的，才是好的 Skill。
因為只讀取 Meta data（name、description），description 的重點不是描述 Skill 要做什麼，而是在哪些情境會被觸發。
如果想測試 git-smart-commit Skill，可以切換到 feature/add-activity-log-page branch，輸入 git reset --soft a401f90f168a37bf2d1d3239863221d219362b41
pr-template 生成 Title 與 Description（漸進式揭露）
Code Review 的速度已經跟不上 AI 寫程式的速度。當人成為 AI 的瓶頸時，要去想的是如何降低門檻，而不是放棄審核。
設計 Commit、PR 的 Skill 就是透過優化流程讓開發更順暢。雖然每一步都是 AI 在執行，但如果沒有實務經驗，其實不知道怎麼串起這些工具。真正值錢的不是工具本身，而是知道什麼時候用、怎麼組合。
Git Worktree 主要的目的不是「平行開發」，而是方便處理不同性質的「任務」。
AI 執行的效率已經非常高了，與其平行開發後解衝突，還不如把精力放在 Code Review 上面確保專案穩定性。
AI 寫程式很快，但穩定性不足、難以維護、無法驗證，這些問題在 AI 時代被加倍放大
安裝系統環境、理解 MCP / Rules / Commands / Skills 核心概念，打好與 AI 協作的基礎
用 SDD 規格驅動開發、設計 Commit / Branch / PR Skills，導入測試與 CI/CD，讓流程可靠可追蹤
歡迎提問，一起深入探討
不管 AI 多強大，
按下同意時，責任就歸屬於你。