這幾年做企業內訓的時候，我會請客戶提供內部的「去識別化資料」，這樣我才能根據公司實際狀況設計課程。

但實際收到檔案時，通常裡面還是會殘留一些比較敏感的資訊，比如「姓名、電話、Email、身分證字號、地址…」

我知道承辦人員已經很努力了，只是當檔案太多、操作又很瑣碎時，就算有心去做，也很容易漏掉。

就像一份 Excel 有多個工作表時，可能處理完第一個，後面的就忘記了。

而 PDF 更麻煩，因為檔案無法直接編輯，所以有些人會用白框遮擋，但其實被遮擋後文字依舊可以被複製。

其實我收到這些檔案還好，因為合作時有簽署保密協議。

但如果是直接丟給 AI，情況就不一樣了

你上傳的資料，是有可能會被 AI 拿去訓練模型而導致外洩。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【AI 陷阱 EP3】資料別直接丟 AI！Word、Excel、PDF、TXT 一鍵去識別化 | 資訊安全 | Vibe Coding | AI 資安 | ChatGPT | Claude

這邊先帶大家看一下 ChatGPT 與 Claude 如何關閉這個設定。

ChatGPT 可以點擊左下角頭像，選擇設定，切換到資料控制的分頁後，將「協助改善所有人的模型體驗」切換成關閉。

而 Claude 也是點擊左下角頭像，選擇設定（Settings），切換到隱私權（ Privacy）分頁後，將「Help improve our AI models」切換成關閉。

建議大家檢查一下自己的帳號，因為預設是開啟的。

駭客常用的釣魚手法

不過就算把設定關閉，也不代表上傳的資料就安全了，因為你的帳號有可能被駭客盜用。

最常見的手法，就是冒用你公司的 CEO、技術長這些高階主管；用他們的頭像，以及相同的 Email 前綴，以填寫 Google 表單的名義寄信給你。

你點連結後，可能會看到一個非常像 Google 的登入畫面。

此時只要不小心輸入了帳號密碼，你的帳號就被盜了。

駭客掌握帳號後，除了可以直接登入你的信箱外，還可透過它登入其他應用程式，比如進入 AI 工具瀏覽對話紀錄。

假如你提供的敏感資料完全沒有去識別化，那對駭客來說真的就是得來全不費功夫。

所以建議大家除了要給帳號加上多重驗證要素外，把敏感資料上傳給 AI 前，也要做到去識別化的動作。

去識別化工具分享

這邊分享一個我設計的免費去識別化工具：

1. 支援 Word、Excel、PDF、TXT 等多種格式
2. 可以一次處理 10 個檔案
3. 能辨識並隱藏姓名、身分證、電話、地址等常見隱私資訊
4. 發現有辨識錯誤或遺漏的地方，也能手動增加或取消
5. 工具以純前端網頁設計，所以檔案從頭到尾，都不會離開你的電腦
6. 在 AI 處理完後，還能還原回來

這篇文章我會分成三個部分：

① 為什麼需要去識別化

從資訊安全的角度分享去識別化的重要性，以及過去手動處理的痛點與風險

② 去識別化工具實戰 Demo

示範工具在實務應用上的使用場景：「資料去識別化、與 AI 協作、還原資料」

③ 在 AI 時代，打造客製化的工具

分享製作工具時的設計思路，大家了解後可以根據自己的需求來優化功能

① 為什麼需要去識別化

許多公司都會要求員工把敏感資料上傳給 AI 前，要先去識別化；但又沒有提供對應的工具，所以很多人是用土法煉鋼的方式，純手搓。

手動去識別化的問題

以 Word 來說，我發現許多人是用「取代」的功能一個一個換，但要取代的內容一多就很容易漏。

而且除非你有設計對照表，否則改完後就回不去了。

另外 Excel 最常見的疏漏，就是第一個工作表處理完了，但後面幾個就忘了

至於 PDF 更麻煩，很多人會直接畫一個白框蓋上去；表面上看起來是遮掉了，但如果框選起來複製貼上，你會發現資料還在。

安全的去識別化工具

前面的痛點，是讓大家了解手動處理是一件繁瑣，且漏洞百出的方案。

資料去識別化這個任務，其實我們是可以透過工具處理的。

如果在網路搜尋「去識別化工具」，你會看到有許多現成的服務可以使用。

但提醒一下大家，除非你了解服務背後使用的技術架構；否則你原本的目標是去識別化，結果卻直接把機敏資料送給對方。

所以我不敢推薦別人製作的工具，因為萬一推薦錯了，就會產生資安危機

因此我乾脆自己做一個，這樣企業在提供資料給我的時候，就能透過這個工具，更輕鬆地處理敏感資料。

講課時，也能直接示範給學員看如何使用，並培養資訊安全的意識。

② 去識別化工具實戰 Demo

這邊我就直接跟大家示範這款工具的操作方式。

網址：https://deanlin.net/data-deidentification/

STEP 1｜上傳檔案

打開網頁後，你可以直接把檔案拖進來；工具支援 Word、Excel、PDF、Markdown 等多種常見格式，最多可以同時處理 10 個檔案。

如果是信件或對話紀錄，也可以直接貼上文字

如果你只是想嘗試這款工具如何使用，我也有內建不同格式的範例，這邊我先以 Word 格式的合約來跟大家示範。

STEP 2｜看預覽

點擊「載入」後你可以看到，預覽的排版跟原本的 Word 幾乎是一樣的，被辨識為敏感資料的部分，會換成方括號加上類別。

像公司、統編、姓名、電話、電子郵件，都被隱藏起來了。

如果想看原始資料，滑鼠移過去就會直接顯示。

預設是「部分保留」，會留下姓氏、電話前幾碼、地址的縣市行政區，這些可能會拿來統計的部分。

如果不需要統計，可以把「部分保留」改成「全部隱藏」，這樣所有敏感資訊就會全部轉為編碼。

STEP 3｜人工調整

不過自動偵測一定會有誤判，所以建議大家在預覽階段先瀏覽一下。

比如你如果認為銀行帳戶屬於敏感資訊，但沒有被隱藏，可以用滑鼠圈起來，選好類別，就能手動隱藏。

而抓錯，或認為不需要隱藏的，點一下標記，按「取消去識別化」，就會恢復原文。

如果想檢視這份文件有多少內容被去識別化，也可以直接「展開偵測清單」快速瀏覽：

STEP 4｜下載

確認一切都符合預期後，點擊上方的「下載」，你就會獲得兩個檔案，一個是去識別化的文件，另一個是 CSV 編碼表。

這兩個檔案是一組的，如果 CSV 編碼表沒有好好保存，未來資料會無法順利還原。

STEP 5｜上傳 AI

完成資料去識別化後，我們就能放心地提供給 AI 了。

比如把 Word 上傳給 ChatGPT，請他協助確認合約細節，比如跟他說：

我是甲方，請從法務角度確認合約中是否有不利於甲方的條款，如果有，請給出合適的處理方案，並直接從原本 Word 契約書裡面調整，調整的部分用紅字標注

等 AI 優化完後，我們拿到了新版的契約書，變更的部分都有用紅字顯示。

STEP 6｜還原

接下來，如果你確認變更的條款都符合預期後，可以回到工具「還原」的分頁。

把 AI 處理完的檔案，跟剛剛的編碼表一起上傳；就會看到內容都被還原了，並且檔案可以順利下載。

STEP 7｜自訂規則

那如果你覺得內建的這些規則還不夠用，想要自己新增，這個工具也有保留彈性。

這邊我點擊「換一個檔案」，用範例中客戶資料 Excel 來示範，先點擊「載入」。

你可以看到第一欄就是「客戶編號」，如果你想要把它隱藏，手動一行一行處理太慢了。

此時，可以到「偵測規則」的分頁，來新增自訂規則，如果你不知道規則要怎麼寫，可以按「複製 AI 提示詞」。

貼給你常用的 AI，再補上客戶編號長什麼樣子，AI 就會幫你把規則寫好。

把規則貼回來，按「新增規則」，接著回到去識別化頁面，你會發現整欄客戶編號都有去識別化了。

③ 在 AI 時代，打造客製化的工具

這個工具，其實我是用 Vibe Coding 完成的，接下來跟大家分享，我設計工具時的思路。

未來如果你也想做自己的工具，可以參考看看。

要不要用資料庫

首先規劃工具的時候，我會先判斷資料是否要儲存，以及「資料庫」是否為必要元素。

因為多了資料庫就代表你需要建立完整的系統架構，需要涵蓋前端、後端，以及註冊、登入、管理、維運等元素。

除了複雜度大幅上升外，資訊安全的問題也隨之而來。

以今天介紹的「去識別化工具」為案例。

如果我有設計對應的系統架構，儘管可以獲得更準確的辨識，甚至對會員進行收費。

但相對的，我就需要保障會員上傳的資料，並提供相應的售後服務。

在評估完要付出的成本與可能獲得的收益後，我最後決定採用「純前端網頁」的形式分享。

檔案只在瀏覽器裡處理，不會傳到任何伺服器，少了一整層要保護的資料。架構也單純很多，非常適合用 Vibe Coding 來做。

從自己的需求出發

另外大家在選擇 Vibe Coding 的主題時，建議從自己實際的需求出發，這樣功能才會想得夠細，並且有辦法判斷成果是否符合需求。

不過 AI 在完成第一個版本後，一定會有很多不夠完善的細節需要優化。

絕對不是網路上那些號稱「一個指令生成系統」那麼簡單。

除了去識別化還要能還原

比如 AI 給我提供的第一個版本，就只有提供去識別化的功能。

但實際上手操作一段時間後，我就發現如果去識別化後無法還原，那其實很多應用會受限。

比如合約調整完畢後，難道我要自己手動把原有資料填寫回去嗎？

所以我就請 AI 把敏感資料設計為 CSV 編碼表，讓我可以還原。

遮的範圍要剛剛好

但講了幾堂課後，我發現把敏感資料全部遮擋雖然解決了去識別化的問題。

但有時這些敏感資料會需要拿來統計分析，像是用身分證前兩碼看地區跟性別，或是用地址的縣市、行政區做分析。

全部變成編碼，就會無法回推

所以我後來又加上了「部分保留」的功能，資訊會根據不同類別進行對應的遮擋。

規格驅動開發

也跟大家分享我在製作這款工具時，使用的是「規格驅動開發（SDD）」的方式。

這個技巧可以讓 AI 在寫程式前，先用文字幫你把專案的細節完善，畢竟不是每個人都擅長寫專案的需求規格。

關於這個議題，過去我有拍兩隻影片分享，分別是 OpenSpec 與 Spec Kit 的應用。

它們可以幫你把模糊的需求變得具體，並設計成完善的任務清單，讓我們用更省力的方式，完成有品質的成果。

結語：把資訊交給 AI，責任還是要自己扛

在影片的最後提醒大家幾件事：

1. 如果你發現工作中的某個流程很繁瑣，或許可以自己 Vibe Coding 一個工具來解決
2. 上傳敏感資料前請先去識別化，但自動偵測可能會有誤判，還是要自己檢查一遍
3. 編碼表可以把所有資料還原，不要跟檔案一起丟給 AI，否則去識別化的意義就消失了
4. 去識別化，不等於匿名化，像是資料裡寫著「某縣市行政區的鋼材加工廠」；如果那個行政區剛好只有這一家鋼材加工廠，就算公司名稱遮掉了，大家還是一看就知道是誰，所以要去識別化到什麼程度，還是要依照資料的內容，自行評估。

別忘記，當你把資料交給 AI 的那一刻，責任還是要由人類來承擔。

今天分享的這套去識別化工具我有把它免費開源：

GitHub 連結：https://github.com/dean9703111/data-deidentification

如果有功能想要新增，可以 Fork 修改成適合自己的版本；歡迎路過按個 Star，讓我知道自己的分享對大家有幫助。

好的，今天的分享就到這邊，如果這個系列有給你啟發與幫助；別忘了按讚、訂閱，並把文章分享給需要的朋友。

我替他開心，也順口問了幾個問題：系統有權限設計嗎？API 有沒有限制呼叫次數？有把使用者的操作記錄下來嗎？

他愣了一下，說：「我聽不太懂你的問題？這些重要嗎？」

聽到這個回答，我不禁捏了把冷汗，並列出一個檢查清單給他參考。

這幾年用 AI 輔助開發，我最深的體會就是這句話：「看起來能動的東西，才是最危險的。」

AI 真的很強，簡單的指令就能完成功能，甚至建立系統、App。

但它不一定會主動幫你補上那些「沒要求、卻很關鍵」的東西 — — 權限控管、測試、錯誤處理、資訊安全、上線維護。

有開發經驗的人，知道這些很重要，所以發現 AI 沒設計會要求他補上。

但如果是完全 0 基礎的小白，其實會陷入「不知道自己其實需要的囧境」。

我拍過十幾支用 AI 寫程式的教學影片，也幫不少企業做過內訓。

一路下來我慢慢發現，大家真正卡住的地方，其實不是 Prompt 下得好不好、工具選得對不對。

而是 — — 不知道怎麼把學到的技巧，整合進一個真實的專案裡。

所以我把幾個最會拉開差距、卻最常被忽略的地方，整理給你 👇

1️⃣ 別再用「寫了幾行程式」衡量產出

→ AI 五分鐘能噴 5000 行，也很擅長自產自銷 Bug。真正該看的，是交付出去的良率，以及出事之後多快能修好。

2️⃣ AI 跟你鬼打牆，通常不是 AI 的錯

→ 很多時候是你給的資訊不夠。log 不完整、需求太模糊，AI 再聰明也只能用猜的。先把資訊補足，遠比燒 Token 有效。

3️⃣ 解過的問題，不要再解第二次

→ 把這次的做法整理成一個 Agent Skill，教會 AI 一次，它就永遠記得。下次遇到同樣的任務，直接複用。

我很常被問：「AI 工具幾乎每天都在變，現在學的東西，明天還有用嗎？」

老實說，如果課程只教你工具如何使用；那過不了幾個禮拜，你學到的知識就過期了。

所以我更喜歡分享「如何拆解需求、怎麼定義規格、怎麼驗證結果、怎麼為產出負責」的知識，因為這套底層邏輯，是可以跟著 AI 與自身經驗一起進化的。

在人人都能用一行指令生成系統的年代，「軟體工程」反而變得更重要。因為有了清楚的地基，AI 才知道要照什麼規格開發、用什麼標準驗收、依循什麼流程交付。

如果你想學的，不只是「AI 能不能幫我做點什麼」，而是「我該怎麼把它放進自己的開發工作流」，那這場免費直播，我會完整分享自己的實戰經驗。

👉 立即免費報名: https://tibame.tw/hI1Ks

這幾年協助企業導入 AI 時，發現對大部分的企業來說；他們判斷是否要導入一個 AI 工具的標準，除了功能與實際業務的「匹配度」外，他們其實更在意工具的「使用門檻」。

因為只要使用門檻高，不管工具有多強大，通常上完課後只有少數人會繼續使用。

我過去也分享過很多 AI Agent 的工具，但大多需要打開程式碼編輯器，甚至搭配終端機操作。

這對沒有技術背景的人來說，容易產生抗拒感，甚至使用初期會有挫折感。

所以今天要跟大家分享一款普通人可以快速上手的 AI Agent 工具，他就是「Manus」。

並搭配實戰案例，讓你了解這款工具可以給你的生活、工作帶來哪些幫助。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【Manus 實戰教學】從研究、簡報到個人網站，帶你掌握普通人也能上手的 AI Agent

從對話型 AI 到任務型 AI

過去我們使用網頁版的 Chatbot，通常比較像是在跟 AI 對話，就算討論得到了結果，最後還是要自己動手去做；而 Manus 不一樣的地方在於，你可以真的把任務交給它。

• 基本任務、進階任務：它除了可以幫你做到基本的搜尋資料、整理資訊外，生成簡報、建立網站這些進階工作也能搞定。
• 工具連結：如果給他權限連結到 Gmail、Google Calendar、Notion 這類工具，它還可以成為一個更全能的助手。
• 重複任務：假使你有一些重複性任務，也可以打包成 Skill 技能；這樣你只要教會 AI 一次，之後遇到類似任務時，AI 就知道如何應對。

把事情做完，不等於把事情做好

在進入實戰前，先跟大家分享一個很重要的觀念。

讓 AI 把事情做完，跟讓 AI 把事情做好，其實是兩件事。

因為以現在 AI 的能力來說，如果只是想應付交差，一行指令就夠了。

不管企劃、簡報、音樂、影片，甚至連網站、手機 App 都可以一鍵生成。

但做得出來，不代表做得好，如果希望結果符合需求，你要先搞清楚自己要什麼。

所以我除了分享 Manus 有哪些功能外，還會分享自己與 AI 對話的技巧，並搭配實際案例，讓大家了解 AI Agent 可以如何融入我們的工作與日常中。

從釐清需求、生成研究簡報，到建立個人品牌網站都有具體操作，會由淺入深的帶大家掌握工具。

① 根據個人背景，掌握技術重點

註冊 Manus

🔗 註冊連結: https://manus.im/invitation/9EZQALE1FISTXZP

目前 Manus 有提供 Facebook、Google 等多種方式註冊；如果你是透過我的邀請連結註冊，除了會獲得初始的 1000 積分外，還會多獲得 500 積分喔！

另外每天登入就會獲得 300 積分，所以右上角可以看到一開始就有 1800 積分了。

我這邊特別跟官方爭取到一個小禮物，新帳號點擊連結可免費領取 Manus 1,000 積分（名額有限）。

這些積分，能讓我們使用 Manus 各式各樣的 AI 功能；給大家一個初步的概念，像我生成一個 15 頁圖文並茂的簡報大約需要 300 積分。

而 Manus 在使用模式上，有分成三種，目前免費版只能使用 Lite 模式。

建議大家先透過 Lite 熟悉基礎操作，如果覺得 Manus 真的有幫你解決痛點，就可以考慮升級到付費版。

為了讓大家更清楚 Manus 的能力，這篇文章我是用付費版示範給大家看的（順手幫我點個讚吧）。

不要盲目使用工具

這裡先分享我是如何快速掌握一款新的 AI 工具，畢竟現在市場上的工具太多了，而且每天都在更新。

如果每接觸一款新工具，都自己人肉測試，那其實很容易錯過好工具；因為憑感覺使用一款工具，未必會試到這個工具對自己有幫助的地方。

所以現在接觸新工具時，我都會先請 AI 幫忙研究。

畢竟人的時間有限，我們也不需要精通一個 AI 工具的所有功能。

最重要的，是知道：「這個工具有哪些功能，是真的對我有幫助的。」

使用 Chat 模式節省積分

我先分享一個節省點數的技巧，其實 Manus 有分成 Chat 模式跟 Agent 模式。

一開始與 AI 討論問題、腦力激盪的時候，我們可以先用 Chat 模式。只要點擊右下角的更多，就可以看到「Chat 模式」。

請 AI 規劃學習指引

比如我想知道 Manus 可以給我帶來哪些幫助，就可以貼上提示詞跟他詢問

我是一名工程師、協助企業導入 AI 的內訓講師，同時也經營 YouTube 頻道。

我想要了解 Manus 有哪些功能可以幫助我更快完成工作。

請你從官方網站、網路文章與近期社群媒體的討論中，幫我整理 Manus 目前最值得關注的功能、實用技巧與應用場景。

每個場景附上對應的提示詞，讓我體驗 Manus 的強大。

• 背景描述：一開始我先說明自己的背景資訊，是工程師、企業內訓講師，也是 YouTuber。
• 研究方向：這邊就請他從公開資訊，整理 Manus 有哪些功能可以幫助我更快完成工作。
• 行動指引：最後為了方便驗證功能，我要求他要附上提示詞，這樣可以方便我們後續的行動。

送出之後 Manus 很快的就給了我們行動指引，下面這份報告是根據我的提供的背景來介紹 Manus 的，並根據不同身份，給予對應的應用場景，並在下方提供可以直接實戰的提示詞

執行完畢後，我們點擊右上角文件的符號，可以看到在 Chat 模式下使用積分為 0。

也給大家看一下 Agent 模式有什麼不同，這裡我就點擊「啟動 agent」。

你會看到 Manus 啟動一台虛擬機，然後自己打開瀏覽器、搜尋資料、看網頁、整理內容，感覺就像一個真的助理在幫我們做事一樣。

稍等一段時間，他就幫我們生成了一份報告，跟 Chat 模式相比，因為多了搜尋資料整合案例的步驟，研究成果會更有深度且符合實際需求。

所以在每個應用的技術上也會說得更加完整，我們了解工具中哪些功能對自己有幫助後，再做針對性的測試，可以幫我們節省不少盲目使用時間。

② 從釐清需求到生成簡報

我其中一個身份是企業講師，常常要到不同產業授課，為了讓學員有共鳴，我需要根據公司情境把案例客製化。

但坦白說，許多產業對我來說也是完全陌生的領域，所以備課時，都是請 AI 幫我研究主題、設計案例。

其實別說是我，大家日常工作也是一樣的。

可能主管突然丟一個主題，要你做市場調查、整理資料；然後要求你今天下午或明天，就要上台跟同事做簡報分享。

哇～光是想像這個場景，我整個壓力就上來了！

如果你跟我有一樣的痛點，那千萬不要錯過接下來用 AI 生成簡報的案例。

不要一開始就叫 AI 做簡報

這邊我們一樣先使用 Chat 模式。

STEP 1: 優化提示詞

提醒一下大家，如果你打算請 AI 做簡報，那第千萬不要一開始就讓 AI 做簡報；而是先初步提出自己的需求，並讓 AI 優化提示詞。

這個步驟會讓 AI 補充許多你一開始沒有考慮到的細節

我是一間台灣汽車零件零售業的廠商。

我們銷售的汽車零件包含：「煞車系統零件、濾芯、底盤零件、引擎周邊零件、常見保養耗材。」

目前在評估是否進軍東南亞，希望切入 Tier 2 或售後維修市場

我需要製作一份簡報給主管，說明建議的切入策略

請你幫我把上面這段需求，優化成更完整、更適合交給 AI 研究的 Prompt，用 Markdown 顯示

• 背景描述：一開始我先說明自己的背景是「汽車零件零售業的廠商」，並提供主要的販售項目。
• 初步目標：進軍東南亞，切入 Tier 2 或售後維修市場。
• 受眾：主管。

一開始的需求描述模糊沒有關係，因為最重要的是最後一行：

請你幫我把上面這段需求，優化成更完整、更適合交給 AI 研究的 Prompt，用 Markdown 顯示

多了這行，AI 就會把原本初始的 Prompt 做更完善的優化。

同時也跟大家補充一下，這邊我之所以要求使用 Markdown 格式，是因為它輸出的是結構化，有明顯階層的。

像這邊你就看到，原本只有四行的提示詞，在 AI 的幫助下補充了這麼多細節，大標、次標、描述的層次都很清楚。

STEP 2: 請 AI 反問我還缺什麼

乍看之下，上面的 Prompt 感覺已經很完善了對吧？但這個時候我會建議大家換個角度。

讓 AI 反問自己，如果補充哪些背景資訊可以得到更完善的結果。

從市場研究顧問的角度來看這段 Prompt，如果要完成這個研究，我還需要補充哪些資訊，才能讓你產出更精準、更符合商業決策需求的結果？
每個問題請簡短說明：

1. 為什麼需要這個資訊
2. 如果缺少這個資訊，可能會影響哪一部分的分析

這步非常重要，因為很多時候我們根本不知道要提供哪些資訊，與其自己硬想，不如讓 AI 幫我們檢查，這也是我覺得跟 AI 協作很重要的一個概念：

不是只有你問 AI 問題，你也可以讓 AI 反問自己

在收到問題後，大家可以自行補上必要資訊；這邊我為了示範，所以讓 AI 自問自答一下

用公司老闆的身份，模擬回答上面問題。

STEP 3: 先設計簡報大綱

在背景資訊完整後，接下來也不要直接製作簡報，先幫我設計一份約 15 頁的簡報大綱

幫我設計一份約 15 頁的簡報大綱。內容涵蓋：

1. 簡報主軸
2. 每一頁的標題
3. 每一頁要說明的重點
4. 建議搭配的圖表或資料類型

用 Markdown 顯示

之所以要先做大綱，是因為如果直接請它生成完整的簡報；除了會花比較多時間外，每次生成簡報也會消耗不少積分，如果方向錯了，後面要改的地方也會很多。

因此我建議先讓 AI 產出大綱，確認方向符合預期後，再生成完整的簡報，這樣可以減少很多來回修正的時間。

STEP 4: 生成圖文並茂簡報

在大綱生成出來，確認符合需求後就可以生成投影片了，最簡單的方式是點擊建立，選擇「投影片」。

這這種方案我們對生成結果的掌控力是很低的。

所以我建議大家先把簡報大綱複製起來，儘管這次 AI 是用表格生成，但點擊右下角也是可以把內容複製起來的。

開一個新對話窗，點擊「製作簡報」，這邊你換看到三種選項，分別是專業、GPT 與 Nano Banana。

• 專業：如果你想要製作的以 HTML 為主，重點呈現文字跟圖表，方便大家直接編輯細節，風格偏向傳統簡報。
• 圖片視覺：而如果你希望每張投影片的視覺效果拉滿，就選擇 GPT 或 Nano Banana。

如果選擇專業的話，也有許多模板可以選擇：

稍等一段時間，簡報就製作完成了，你會發現透過以上步驟製作出來的簡報，內容詳盡、結構完整、而且有適當的搭配圖表。結果會更符合你一開始設定的目標。

但提醒一下大家，AI 生成出來的結果有可能會錯誤，若涉及數據、真實資訊，請自行核實

用專業模式生成的簡報，裡面的文字也是可以編輯的。

如果你想要調整成其他風格的簡報，可以點擊右下角的「更改主題」，從裡面選擇自己喜歡的版型。

如果不知道上台怎麼講，點擊右下角的「讓 Manus 生成」，他就會根據每一頁簡報的內容，設計出有起承轉合的逐字稿，讓你上台分享時更有底氣。

當然，你也可以把它下載成 PPT 來精修細節、或用 PDF 格式與別人分享，甚至想在 Google Slide 編輯也可以喔！使用上非常有彈性

③ 把繁瑣的任務，整理成可以重複使用的 Skill

這邊分享一個實用的技巧，剛剛我們不是透過好幾輪對話才得到這個結果嗎？

如果每次研究新主題都要這樣搞，感覺太煩了吧；幸好 Manus 有提供建立 Skill 的方案。

可以透過「/skill-creator 描述」幫剛剛繁瑣的流程，建立為可以重複使用的技能喔！

/skill-creator 幫我把剛剛提供主題生成簡報的流程設計為 Skill，日後提供主題就會觸發

最後會記錄成一個文件，打開後點擊「新增到我的技能」，AI 日後遇到類似的任務時，就會按照指引來去執行。

如果想找尋儲存好的技能，可以點擊左下角的個性化，在功能列就會看到技能。

剛剛建立好的技能會存放在這個位置，技能除了可以自己建立外，也可以匯入別人建立好的技能喔！

驗證 Skill 是否符合預期

在 Skill 建立後，建議大家可以提供另外一個主題，來驗證這個 Skill 是否會順利觸發，以及觸發後，是否有順利運作。

這邊我就給他一個新主題，讓他研究亞洲餐飲行業近十年的的趨勢：

請研究亞洲餐飲行業近十年的的趨勢，品牌爆紅的關鍵，以及是否維持的關鍵因素，請幫我製作一份 12 頁的高端專業研究簡報。

指令送出後，可以看到 AI 有使用剛剛建立的 Skill。

稍等一段時間，我們就能看到 Manus 根據我們剛剛的需求建立簡報。

只是這次他認為我提供的主題更偏向說故事，所以採用 Nano Banana（圖片視覺）的方式來建立簡報。

跟前面專業模式透過 HTML 生成簡報的方式相比，你可以明顯感受到簡報的圖片品質非常棒。

但因為個簡報其實是圖片，儘管你也可以編輯裡面的文字；但這些細節的調整就等於重新生成一張圖片，修改起來比較花時間。

所以在使用上，如果簡報的重點是傳達故事、概念，我覺得視覺化簡報的方案很棒。

但假使簡報需要時常調整數據細節，涵蓋大量圖表，我會推薦使用專業模式來生成 HTML 簡報。

④ 整理不同格式檔案，建立個人品牌網站

接下來我們換個場景，如果你是自由工作者或一間新創公司，那最重要的就是讓別人認識你、找到你。

相比於傳統名片，我認為建立個人形象網站或公司官網，會達到更好的宣傳效果。

在過去，如果你不會寫程式，可能要把網站交給外包公司；但現在，你可以請 AI 幫你完成網站的初稿。

請 AI 整理資訊

這邊我就拿自己當案例示範給大家看；這次我的目標是建立個人形象網站，所以下面要先選擇「建立網站」，然後選擇「個人連結頁」

我是個講師，準備製作個人形象網站，相關背景資訊可以參考附件的檔案

幫我從裡面提取出文字後，整理出如下資訊：

- 擅長領域: 搭配可以佐證的資訊
- 個人成就: 找出可數據化的成就，展現實力的強大
- 課程資訊: 課程主題、說明、價格、受眾、預期成果

並像個善於推銷自己的 KOL 般，先用自信的語氣撰寫出文案，並說明每段適合搭配的圖片

這步先彙整資訊，不需生成圖片與網站

這段 Prompt 我先表明自己的身份是「講師」，要求他根據我提供的素材，整理出「擅長領域、個人成就、課程資訊」的資訊，以此做為「個人形象網站」的素材

如果你的目標是建立公司官網，請 AI 幫你生成對應提示詞就可以了

這段想要呈現的，是 Manus 針對不同格式檔案的資訊分析、彙整能力

你可以看到我上傳的有 Word、PPT 跟 PDF 檔案，這也更符合實際工作場景，因為資料來源往往是不統一的。

生成網站

在彙整完資訊後，你可以先看看 AI 整理的資訊是否符合期待。

確認沒問題後，就可以上傳網頁所需的圖片，然後透過下面的指令來生成網站了

請使用我上傳的圖片，參考圖片檔名放到網頁合適的位置，讓整體更有設計感與專業度

設計純前端的個人形象網頁即可

在 Manus 生成網站的過程也提醒一下大家，因為我跟他說生成存前端網站，所以有較高機率給我一個單純的 HTML 檔案。

如果你生成的是較為複雜的專案，甚至包含到後端與資料庫，操作的細節會跟這次示範有所不同。

稍等一段時間，Manus 就根據我們提供的文件與圖片幫我們完成了一個測試網站，我們先點擊一下網址，看一下他是如何設計的。

Manus 連接器

確認整體符合需求後，這邊剛好跟大家介紹 Manus 連接器的功能。只要開啟對應工具的權限，Manus 就可以透過 API 來進行操作。

因為我已經有連結到 GitHub 帳號，所以他可以直接幫我建立對應的 Repository。

這邊提醒一下大家，雖然權限開越大 AI 能做的事越多；但前提是你了解自己在做什麼，否則可能造成無法挽回的後果。

了解完風險後，我們回到 Manus，下面我就直接跟他說：

我已經連結到 GitHub 帳號，幫我建立

等待一段時間後，發現 AI 暫停了。這邊他要我們接管瀏覽器，完成 GitHub 帳號的登入，或提供帳號密碼來讓 AI 代為操作。

但只要在瀏覽器登入帳號，基本上就等於讓 Manus 擁有帳號的完整權限，我個人是不敢這樣做。

面對有風險，但我們又不清楚如何操作的事情，也可以向 AI 詢問操作步驟：

告訴我後續的操作步驟

在 GitHub Actions 確認部署狀況

這邊補充一個細節，關於部署的狀態，我們是可以在 GitHub Actions 的分頁來觀察的。

另外把專案存放到 GitHub 後，其實也順便做到了版本控制。

因為與 Manus 對話，調整網頁時，可能會改到許多程式，未必每次都符合你的期待。

但有了 GitHub，在結果不如預期時，便可以輕鬆回到過去的版本。

接著回到 Manus 網頁，在部署完成後，點擊連結便可看到剛剛建立的個人形象網頁；你可以把網址分享給自己的朋友，展示自己的戰果喔！

範例網站：https://deanlin.net/dean-lin-website/

如果做到了這一步，也別忘記幫文章點個讚，讓我知道自己的分享是對大家有幫助的。

透過對話優化網站細節

另外如果你對網頁有其他優化的需求，也可以直接跟 Manus 說，這邊就分享一個小技巧。

如果你想要讓網站圖片渲染的速度更快，可以把圖片轉成 webp 格式。

幫我將圖片轉成 webp 格式，讓使用者可以更快載入網頁

指令送出後，AI 除了會幫我們把圖片檔進行壓縮外，因為我們有開啟 GitHub 的權限給 Manus，所以他也把變更同步到了 GitHub，我們可以點擊網址來做確認。

恭喜你，成功用 Manus 完成了個人形象網站！

解決不同裝置瀏覽問題

最後提醒一下大家，雖然 AI 可以幫我們加速，但品質還是需要自己把關。

雖然網頁版沒有問題，但我改成用手機瀏覽時，還是出現各種破版的狀況：

遇到錯誤不要害怕，跟 AI 溝通就可以了，怕的是根本沒有意識到有錯誤發生。

結語：AI 能做到哪些事，取決於你的想像力

最後我們來回顧一下今天的文章：

1. 一開始我跟大家分享我是如何在短時間掌握一款新的 AI 工具
2. 然後展示如何與 AI 腦力激盪，生成一個圖文並茂的簡報，並將這個繁瑣的流程打包成一個可以重複使用的 Skill

3. 最後分享 Manus 如何整理不同格式的檔案，然後建立個人形象網站

當然，這支影片只是帶大家入門，體驗 Manus 的基礎功能，了解 AI Agent 可以幫我們做到哪些事情。

也提醒大家，現在 Manus 除了可以在網頁使用外，有提供桌面與手機的 App 可以操作喔！

好的，今天的分享就到這邊，如果這篇文章對你有幫助，可以順手按個讚，並把文章分享給對 AI 主題感興趣的朋友們。

老實講，以現在工具發展的速度來看，就算我們拼盡全力學習，也不可能全部掌握。

而且就算掌握了工具的最新技巧，真的等於工作能力變強嗎？

如果換一套工具，過去學習的方法能辦法轉移過去嗎？

這堂課會以 Claude Code 作為主要示範工具。

但不管你平常使用的是 Cursor、Antigravity，還是 Codex，都可以跟著一起操作。

因為我設計這堂課，是以「完成專案」為目標，工具只是在實戰過程中自然掌握的能力。

工具應該讓大家學以致用，而不是靠大腦死記硬背。

我會著重分享 Rules / Commands / Agent Skills 的具體應用，因為這些技巧，在主流的 AI Agent 都有相似的概念。

也就是說，切換到新工具時你不用重新學一遍。

甚至可以透過 npx @dean9703111/dotagents建立不同工具之間的軟連結（symlinks），讓規則集中管理。

這樣只要修改一次，就能同步套用到不同工具中，讓維護更輕鬆。

面對生成式 AI 結果的不確定性，我們也不能只靠感覺驗收。

所以我會搭配 Lint 與 Unit Test，來確保專案基礎品質。

Lint 可以規範程式碼的 Coding Style，初步過濾冗贅、格式不一致，或不符合團隊規範的程式碼。

Unit Test 則能幫助我們在功能新增或修改時，確認是否影響既有邏輯，並在錯誤發生時更快定位問題。

當我們把 Lint 與 Unit Test 放進 Pre-Commit 與 CI/CD 流程，很多問題就能在進入主分支前被擋下來。

考量到大多數人不喜歡寫文件，或者不知道規格該如何撰寫，

所以我會帶大家了解如何用 OpenSpec 生成規格文件，讓 AI 執行的每一步都有明確方向。

它不僅幫你從 0 到 1 建立系統，更重要的是，這些文件讓後續每一次功能迭代都有依據。

在多人協作、長期維護、持續迭代的專案，文件不只是寫給人看的，也是 AI 理解專案的基礎。

每個人（團隊）在開發時都有一套工作流。

但當專案有時程壓力時，我們容易「先求有，再求好」，然後留下一堆技術債。

此時我們不妨反過來思考：

能不能把這些重複發生、又容易被省略的工作，設計成可以讓 AI 穩定執行的 Skills？

例如：

• Commit 訊息撰寫
• Pull Request 描述
• Unit Test 設計
• 分支命名規則
• 程式碼檢查流程

這樣就能讓我們把注意力放在驗收「結果」，而非消耗精神的「過程」。

在人人都能用一行指令生成系統的年代，「軟體工程」反而變得更加重要。

因為有好的地基，AI 才知道該照著什麼規格開發、用什麼標準驗收、依循什麼流程交付。

如果需求是模糊的，規格是破碎的，測試是缺席的，那 AI 生成得再快，也只會成為後續維護的負擔。

所以這堂課想帶給大家的，是如何把 AI 放進真實開發流程裡，建立一套穩定、可維護、能持續迭代的實務工作流，而不是停留在一次性的工具展示。

• 📌 專屬折扣碼: DEANONLY
• 👉 課程詳情: https://tibame.tw/Zmnts

我在 YouTube 已經拍了十幾支用 AI 寫程式的教學影片。

通常會用「一個技術，搭配一個專案」的方式來分享，因為這樣比較容易讓大家快速認識某個工具，也能實際做出一個具體成果。

但這樣的方式雖然適合幫大家理解單一主題，卻不一定足夠應付真實工作情境。

因為回到工作現場後，你遇到的不會只是某個技術點。

你會同時碰到前端、後端、資料庫、權限、測試、版本控制，還有整個協作流程。

遇到問題時，很多人以為是 Prompt 下的不夠好、工具沒選對，

但我在幫企業培訓的時候，發現真正卡住的原因是：「不知道如何把學會的技巧整合運用。」

這也是我決定開這堂課的原因。

因為我覺得如果沒有搭配一個完整的專案，就算學到了某個工具，也不一定知道如何把它應用在實務上。

所以在課程中，我會帶大家從需求、規格、生成、驗證、測試，到最後的 CI/CD，完整走完。

你會看到的，不只是某個技巧怎麼用，而是當這些東西導入工作流後，專案是怎麼運作的。

而這些調整，也不是我憑空想像出來的。

其實拍完影片後，我都會收到不少觀眾的留言；再加上這段時間做企業內訓，也接觸到很多不同背景的學員。

有人本來就有資工背景，但不知道怎麼將 AI 導入工作流；也有人對很多技術名詞感到陌生，但又真的想學。

這些回饋對我幫助很大。

它讓我了解大家缺的，不一定是再多一個工具，而是需要有人把使用 AI 開發這件事，用更完整、更白話的方式講清楚。

所以這次課程中，我也把很多在影片裡來不及講深、講完整的內容，整理進課程裡。

像是安裝流程、名詞解釋、為什麼用這個技術、為什麼這個階段要這樣做。

因為我不希望這堂課只有本來就有基礎的人才跟得上。

我更希望，就算你是初學者，也能在實戰的過程中認識整個脈絡。

現在網路上最不缺的，就是 AI 很強、AI 很快、AI 很會 XXX 的內容。

但真正實戰過的人都知道，難的從來不是把東西生出來，而是當需求改變、功能增加後，這個專案還能不能持續擴充、穩定維護。

所以這堂課，我想講的不只是「怎麼把功能做出來」。

而是怎麼把 AI 放進一套可維護、可驗證、可持續擴充的工作流。

這也是為什麼我會分享 OpenSpec、Agent Skills、單元測試、CI/CD、Git Worktree 這些內容。

不是因為它們聽起來比較厲害，而是因為它們剛好都在處理實務中最容易被忽略、人類最不想做，但往往最容易出問題的地方。

這堂課，就是我這一路拍片、實戰、收集回饋後，整理出來的一個答案。

如果你想學的，不只是「AI 能不能幫我做點什麼」，而是「我怎麼把它放進自己的工作流裡」，我相信它會對你有幫助。

• 📌 專屬折扣碼: DEANONLY
• 👉 課程詳情：https://tibame.tw/Zmnts

前陣子我跟 Cake 合作，在台大分享怎麼把 AI 導入工程師日常的開發工作流。準備過程中，我腦中突然蹦出了一個想法。

既然課程在講 AI 寫程式，那與其使用傳統的 PPT 做講義；不如嘗試用 Vibe Coding，打造一個屬於自己講義網站，這樣使用者介面可以完全根據自己的需求量身打造。

然後花了一個晚上的時間，完成了模板的雛形設計。

他不僅可以在電腦、平板、手機瀏覽，甚至還可以匯出 PDF。

為了讓設計可以被重複使用，我把他封裝成了一個 Agent Skill。

這樣未來我收到新需求時，只要提供講義初稿，AI 就會在分析內容後，直接生成一個講義網頁。

如果對產生結果不滿意，也可以調整 Markdown 文件修改細節。

今天這篇文章，我除了會分享如何用系統設計思維打造 Agent Skill 外，更會提醒過程中會遇到的陷阱與痛點。

相信大家看完後，就不會只把 Vibe Coding 的成果當成免洗餐具，用完就丟；而是開始去思考，如何把它設計成可以長期使用、維護、擴增的工具。

今天使用的 AI Agent 是 ChatGPT 的 Codex，目前免費版就可以使用。

我會展示兩種操作方式，一種是在終端機輸入指令，另一種則是在程式碼編輯器安裝外掛，透過對話窗操作。

透過實際 Demo 讓大家更直觀的比對兩種使用方式的差異。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【ChatGPT Codex 實戰】將 Vibe Coding 成果從「用完就丟」，變成「可持續優化」的 Agent Skills

培養多個 AI 工具使用的能力

如果你是頻道的老觀眾，也許看到這邊會有個疑惑：「為什麼我怎麼一直分享新的 AI 工具？」

其實會這麼做，是想培養自己「多個 AI 工具交替使用的能力」。

因為只要某個 AI 被捧上天，通常在不久後就會開始限縮額度，歷史總是驚人的相似。

所以我教學的目標從來不是強調「哪一款工具」最強，而是透過實際案例，讓大家了解如何解決痛點。

因為工具間的差異，並沒有你想像的那麼大；唯一要提醒的，就是不要為了折扣付年費，因為每個時期最好用的 AI 一直在改變。

① 安裝 Codex，在終端機生成網頁

今天這個教學，你可以使用自己熟悉的程式碼編輯器，不管是 VSCode、Cursor、Antigravity 都可以。

如果不知道使用哪一款，可以跟我一樣，使用 Google 推出的 AI 程式碼編輯器 Antigravity，登入 Google 帳號就能免費使用。

但這次，我們沒有要使用到編輯器內建的 AI 功能，使用他，只是為了方便檢視程式碼的變更。

給 AI Agent 工作區

在開始前，我們要先準備一個空的資料夾（lecture-example），這是為了讓 AI Agent 有明確的工作區，你可以點擊 Open Folder，或是直接把資料夾拖曳進來都可以。

安裝 Node.js

因為今天分享的 Codex 與實作的專案會使用到 Node.js，所以，我們要點擊上方的 Toggle Panel 打開終端機。

接著輸入「node -v」，來確認電腦是否有完成安裝，如果沒有顯示版號，而是出現沒有指令的錯誤訊息，就需要先去安裝 Node.js 才能執行後續步驟。

在安裝 Node.js 這塊，我建議大家透過 NVM 來安裝，因為 Node.js 有多個版本，而 NVM 這款工具可以幫你快速在不同版本間切換、更新。

如果你跟我一樣使用 Mac，執行下面的指令就可以安裝了：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash

但如果你是 Windows，就需要下載 exe 檔來安裝： https://github.com/coreybutler/nvm-windows/releases

nvm 安裝完成後，點擊上方的「+」開啟新的終端機，然後輸入 nvm -v，確認有成功安裝，接下來輸入 nvm install –lts 來安裝最新版本的 Node.js。

安裝完畢後，輸入 node -v 便可檢視現在使用的版本。

安裝 Codex

在 Node.js 安裝完成後，我們要來安裝 Codex，只要在終端機輸入下面的指令，便可以完成全局安裝：

npm i -g @openai/codex

在安裝完成後，於終端機輸入 codex ，這邊有提供三種登入方式：

1. Sign in with ChatGPT：第一種是透過 ChatGPT 帳號來登入，選擇後會獲得認證網址，接著登入自己的帳號即可，這是我最推薦的方案。
2. Sign in with Device Code：但如果你想要在沒有瀏覽器、無使用者介面的虛擬機（VM）上登入，就要使用第二種方案；你可以在其他裝置貼上網址登入 ChatGPT，接著輸入終端機的驗證碼即可登入；但有一點要特別提醒，你需要先到 ChatGPT 的設定，於安全性的分頁將「啟用 Codex 裝置代碼授權」打勾，才能使用這個方案喔。
3. Provide your own API key：最後一種方案則是輸入 OpenAI API Key，他會根據你實際的用量來計價；有興趣的觀眾可以到OpenAI 的官方網站，在「API keys」的頁面下就可以創建了；但這個方案如果沒有設計好用量限制，你可能在看到信用卡帳單時會爆哭。

在成功登入後，他一開始會先詢問你是否信任這這個資料夾，選擇 Yes 才能繼續。

接下來出現的輸入框，就可以把它當成過去與 AI 的對話視窗，兩者並沒有什麼差異。

在終端機生成網頁

這邊我先貼上一段 Prompt，請他幫我生成一個教學講義的網頁：

請扮演熟悉 AI 主題授課的講師，以「Agent Skills」為主題設計講義
講義用純 html 網頁（CSS/JS 都放裡面）呈現
日系風格的設計感，部分文字與背景可以搭配適當的漸層
開頭會根據內容呈現標題，然後下面有發人深省的標語
會根據不同層級與意圖呈現對應的區塊（ex: 大小標題、陳述、列點、流程）
最後放上社群連結鼓勵大家訂閱（FB/YouTube/Medium）
側邊欄會有對應的目錄，方便跳轉到對應位置

下面分享提示詞的幾個重點：

1. 角色：請扮演熟悉 AI 主題授課的講師，以「Agent Skills」為主題設計講義 首先我讓他熟悉 AI 主題授課的講師，以「Agent Skills」為主題設計講義
2. 目標：講義用純 html 網頁（CSS/JS 都放裡面）呈現 然後說明產出的目標，這邊讓 AI 只生成單純的 html 網頁，這是為了讓日後部署更輕鬆
3. 風格：日系風格的設計感，部分文字與背景可以搭配適當的漸層 接著我說明自己想要的風格，如果沒想法也可以讓 AI 扮演設計師幫你想
4. 架構：開頭會根據內容呈現標題，然後下面有發人深省的標語 最後則是分階段提出我希望的網頁架構，包含開頭頁面如何呈現、網頁層級如何設計、社群連結要放在最後、側邊欄要有目錄這些

在網站就生成出來後，打開存放網頁的資料夾，點擊兩下 html 檔案便可瀏覽成果：

老實講，這個版本的完成度已經不錯了；也就是說，如果只是想要一份「看起來可以用」的講義網站，其實做到這步就夠了。

痛點：細節調整困難

但如果你是追求細節的人，很快就會遇到問題。

因為 AI 生成的文字描述可能不符合你的期待，段落結構也未必是你要的。

此時我們有兩個選擇：

1. 第一，與 AI 對話調整細節
2. 第二，直接修改 html 網頁

但第一種方案隨機性太高，還可能會動到不該動的；而第二種方案，就算我本身是工程師，改起來都覺得痛苦。

假使在後續要花很大的力氣才能調整，那不管 AI 生成網頁的速度再快、畫面再漂亮；也很難應用到現實專案上。

所以，我們不妨換一種思路；既然生成式 AI 的輸出注定充滿隨機性，那有什麼方式，可以在結果產生後，輕鬆調整細節。

我的答案是建立「可重複使用的模板」

② 將隨機的結果，變成穩定的模板

模板的核心概念，就是不要讓 AI 每次都從零開始生成， 而是先定義好「模板」規則，讓它只要填入內容，這樣就能產出穩定、一致的成果。

這邊我就拿自己當案例，受邀到企業內訓時，我每次都需要準備課程講義。假使都用 Vibe Coding 生成，那講義的內容與網頁風格會充滿隨機性。

但如果有一套模板，那只要替換內容，就能快速產出符合我需求的講義。

不管你是做簡報、寫文件、還是建立網頁，只要是重複性的工作，這個概念都可以適用。

這邊我做了一個嘗試，在對話視窗中跟 AI 說：

我希望剛剛生成出來的網頁，是可以透過 Markdown 格式編輯內容的
請幫我將網頁結構拆解（列點、步驟、圖片、表格、註解）、分層次（大標、中標、小標），並以常見的 Markdown 語法來設計規則
最後建立一個腳本，我只要編輯 Makdown 文件，網頁的 HTML 就會及時改變
操作方式寫在 README.md 文件中，並建立 package.json

• 期待目標：我希望剛剛生成出來的網頁，是可以透過 Markdown 格式編輯內容的
• 設計架構：請幫我將網頁結構拆解（列點、步驟、圖片、表格、註解）、分層次（大標、中標、小標），並以常見的 Markdown 語法來設計規則
• 渲染方式：最後建立一個腳本，我只要編輯 Makdown 文件，網頁的 HTML 就會及時改變
• 說明文件：操作方式寫在 README.md 文件中，並建立 package.json

這段提示詞，目標是把 HTML 逆向回 Markdown 語法結構。

因為想要對內容有掌控力，就應該把它設計在一個可編輯，方便維護的格式中，而不是放在最終輸出的 HTML 裡面。

而且我不只是把它變成 Markdown 而已，我還要求他建立一套可以執行的腳本，這樣我只要編輯 Markdown 文件，HTML 的內容就會及時調整。

稍等一段時間後，AI 就初步幫我們把模板建立完成了。

回到瀏覽器，你可以看到網頁有順利渲染，相比於先前透過靜態的 HTML 打開網站，現在則是透過啟動伺服器的方式來瀏覽。

所以我們就可以來驗證調整 Markdown 文件時，畫面是否會連動。

先回到程式碼編輯器，目前 AI 逆向回來的 Markdown 文件是 lecture.md，我們就嘗試在 Agent Skills 這個標題旁邊加上 Dean Lin 的文字。

儲存文件後，便會重新渲染網頁；然後回到瀏覽器，你就會發現剛剛加上的文字有渲染成功嚕！

建立 Agent Skills 工作流

此時我們就可以把剛剛的工作流，設計成一個可重複使用的 Agent Skill 了。

如果你是第一次接觸 Agent Skills，我過去有拍一隻影片分享安裝、使用、製作的技巧：https://youtu.be/xe00zJEtuMo

接下來我們在終端機輸入下面的 Prompt，我跟 AI 說：

根據下面需求在「.agents」資料夾建立 Skill：
- 參考模板：根據剛剛腳本設計的規格，建立明確的 Markdown 使用規範
- 觸發時機：使用者提供初步想法想建立網頁時，會觸發這個 Skill
- 設計架構：要在 Skill 內建立 scripts 資料夾存放執行腳本、references 資料夾存放參考文件資料
- 執行順序：這個 Skill 會先深入研究輸入的主題，再根據規範設計對應的 Markdown 文件；最後把 Markdown 文件透過腳本生成 html
- 特別提醒：預計會有多個主題，所以觸發時，請根據主題建立新資料夾（英文），裡面存放生成的 Markdown 與 HTML 檔案

稍等一段時間，AI 就根據需求製作好了對應的 Agent Skill，在左側我們可以看到一個「.agents」的資料夾，裡面有 SKILL.md 這個檔案。

name 就是這個 Skill 的名稱，description 則是說明觸發的時機點與預計的執行成果。

references 資料夾放著 Markdown 格式的參考文件，而 scripts 則是存放模板編譯的程式腳本。

驗證 Agent Skill

輸入下面的提示詞：

我想要建立深度介紹「ChatGPT 使用技巧」的課程講義網頁。

這邊你會看到他有成功觸發對應的 Agent Skill 來進行設計：

稍等一段時間，我們可以在左側資料夾下方，看到 chatgpt-usage-skill 的資料夾，對應的 Markdown 文件與 html 網頁有成功生成！

這邊我就直接打開 html 檔案來瀏覽，你可以看到網頁的版型樣式與先前建立的風格一致。

如果你有跟著教學走到這一步，恭喜你建立了屬於自己的模板，但…這只是開始而已。

③ 自由度高的背後，是功能的不完善

儘管剛剛設計的 Agent Skill 搭配模板腳本可以輕鬆生成講義網頁。

但其實功能非常不完善，這邊跟大家舉例：

1. 首先像側邊欄雖然方便導覽，但他會佔掉講義的展示空間，我希望講課時可以自由收合
2. 還有目前的網頁為「淺色」設計，但有時我授課場地是關燈的，如果螢幕是唯一光源，台下觀眾眼睛看久會不舒服
3. 另外有些單位會希望講者提供 PDF 講義，如果使用網頁預設的 PDF 列印，那畫面會非常的醜

這邊我只是舉出幾個常見痛點，雖然建立模板聽起來很厲害，但自由的背後，代表你是目前唯一的維護者。

因為模板的細節是在實際使用後，你才知道哪裡要調整；儘管設計與程式撰寫可以交給 AI，但方向與美感還是要自己掌握。

這就是自己設計模板的代價。你想要主控權，就得承擔客製化背後的複雜度。

老實講，如果只是要有一個線上簡報工具，市面上已經有很多現有工具，比如 Gamma 或 Marp，不一定要走自建模板這條路。

而我選擇做這件事，與其說是建立一個更好的方案，不如說是在設計一套最符合自己需求的工具。

④ 安裝 Codex 外掛 & 體驗模板強大

這邊我就直接跟大家分享，剛剛 Agent Skill 我經過多次迭代後的版本，目前我已經使用這套模板講了 5 場 Vibe Coding 課程了。

歡迎路過按個 Star，讓我知道自己的分享對大家有幫助: https://github.com/deancourse/agent-skill-lecture-builder

我把它設計成一個 Agent Skill，大家可以直接 Fork 我的 Repository 來體驗，Fork 完成後，點擊 Code，從裡面複製專案網址。

然後回到程式碼編輯器，點擊 Clone Repository，貼上剛剛複製的網址來下載專案，指定下載路徑，完成後點擊 Open 便可跟著影片一起操作。

這邊要先安裝所需的套件，打開終端機，輸入 npm install 即可。

這個指令會安裝 package.json 裡面 devDependencies 的套件，而 puppeteer 這款套件，我是用來截取網頁 Open Graph 預覽圖片用的。

安裝 Codex 外掛

也趁這個機會，跟大家分享如何在程式碼編輯器，安裝 Codex 使用這介面的外掛，只要點擊左側的 Exetentions，輸入「chatgpt」。

安裝完成後，點擊上方的 ChatGPT 圖示：

這款外掛有提供登入 ChatGPT 帳號與使用 API Key 兩種使用模式，這邊我選擇登入 ChatGPT 帳號：

登入後，就可以在與 AI 的對話視窗中體驗了，相比於終端機透過輸入指令溝通，透過外掛安裝的使用者介面更適合初學者。

認識 Codex 介面

你可以更輕鬆地切換 GPT 模型、調整思考深度；如果把滑鼠符號打開，AI 就可以辨識你目前選中的區域和打開的檔案。

如果你還想要做更多細微的設定，可以輸入「/」來了解：

比如你打算讓 AI 複雜任務，可以把 Plan mode 打開，來獲得更加詳盡的規劃；假使想了解目前剩餘的額度，則可以透過 Status 來確認。

另外往下滑，會看到安裝好的指令（Commands）與技能（Skills），這邊會看見剛剛我們剛剛設計的 Course Page Generator 這個 Skill。

這邊補充一下，「/」也是可以在終端機當中使用，比如我們這邊打 status 一樣可以看到使用量，但需要你對關鍵字有一定的熟悉度。

提供主題生成講義

假使你今天想要根據指定主題來生成講義網頁，只要在與 AI 的對話視窗輸入自己想研究的主題就好，像我這邊就說：

扮演一位擅長用實際案例解說的資安專家，設計"生成式 AI 資訊安全"的講義並生成網頁
完成後直接啟動

接著稍等一段時間，網頁就建立完成了：

這邊可以看到側邊欄是可以自由收合的，而且在收合後下方會有進度條，讓我講課時可以掌握授課進度：

由於我的授課內容有很多地方需要複製指令，但講課時我可能只有一隻手能操作電腦，所以指令右側有一個複製的 icon，這樣我單手就能輕鬆複製，而不需要透過滑鼠選半天。

並且能夠根據場地自由切換淺色、深色模式；設定中也有多款主題可以使用。

當講課到一半，覺得需要中場休息時，點擊「休息一下」就能夠設定休息時間，而且還有倒數計時來提醒大家。

而前面提到的匯出 PDF，我也直接設計了對應的版面，而不是把網頁的結構直接搬過去，而是做了針對性的設計，這樣才會有更好的閱讀體驗。

甚至如果你想要用簡報模式呈現，右下角的「簡報模式」也可以使用喔，可以針對不同情境自由切換！

提供草稿生成講義

這次我要跟大家示範另一種生成網頁的方式，如果你已經準備好課程講義的草稿，這個 Agent Skill 也可以直接轉換。

我在專案的 exmaple 資料夾底下就有準備一個 Markdown 文件讓大家體驗：

其實這個文件就是這隻影片的 Markdown 逐字稿，我開啟一個新的對話窗，直接跟 AI 說

轉換成網頁，並啟動專案

稍等一段時間，AI 就幫我們完成設計並啟動專案嚕～

相比於提供主題來生成講義，提供詳盡的背景資訊來生成講義，你會對最終生成的結果有更高的掌握度。

讓 AI 學習模板語法

講到這邊，可能會有人好奇網頁背後的 Markdown 文件長什麼樣子，這邊我就回到程式碼編輯器展示給大家看，你會發現大部分都還是依照既有的 Markdown 語法來設計。

但由於這個模板是我建立的，所以我也能設計特殊的語法，像是指令的區塊，以及流程圖的區塊：

不過這些語法我不需要去背誦，因為我已經把它寫成了一個 Agent Skill。

你只需要提出自己想放進去講義的資訊，AI 就會辨識內容，並找到最合適的版型整合到講義中。

你需要做的，就是當文字不符預期時，手動做一些微調。

雖然模板前期的建立有很多細節要處理，但建立好後，你就能根據自己的意志來優化細節，不再被平台綁架。

而且因為它不是一次性工具，所以你會願意花更多時間打磨細節。

輕鬆部署

確認符合預期後，我們就可以打開 Source Control，接著點擊 Generate 自動生成 commit，並 Sync Changes 將內容更新到 GitHub 上面。

接著來到 GitHub 頁面，如果你想要讓網頁被大家瀏覽，只要去 Settings 頁面，因為我們已經把 html 檔案生成完畢，所以選擇預設的 Deploy from a branch 即可，你只要把 Branch 切換到 main 就可以了。

此時到 Actions 的頁面就會看到開始網站正在部署，順利的話，就會看到部署完成後的網址。

但點開來後，你會發現頁面不存在，這是因為網頁檔是存在 example 資料夾底下，所以只要在網址後面加上 example 就可以順利顯示嚕～

而更前面設計的資安網頁，也是複製資料夾路徑，替換上去就可以看到嚕～

了解基礎的操作方式後，你就可以在不同的資料夾下建立對應的課程網頁。

專業對 Vibe Coding 的幫助

這邊也提醒一下大家，雖然這個專案都是 Vibe Coding 出來的，但如果完全沒有技術背景，可能會設計出不合理的架構，或忽略細節。

比如 Open Graph，也就是 OG；如果你最終完成的成品打算公開分享，但沒有設定標題（title）、描述（description）、縮圖（image），那網址預覽畫面會很醜。

如果想知道網頁有沒有設定，可以到這個網站：https://www.opengraph.xyz/

這邊貼上剛剛部署的網址，就能看到 OG 是否有完成相關設定嚕～

設計共用資料夾

接著再回到程式碼編輯器，跟大家分享我的設計細節，如果有些資訊如果希望反覆利用，其實我們可以把它抽出來。

這裡我有設計一個 config 資料夾，裡面存放的設定可以在所有頁面被共用。

像這邊我就把講者介紹、頁面尾端的社群宣傳設計成一個 global.yaml 檔案，而講者圖片我則是放在 assets 資料夾中。

如果有文章想客製化調整的設定細節，則可以編輯 config.yaml 檔案來蓋過去。

模板易用性

我認為好的模板要盡可能減輕使用者操作的負擔；所以在設計上將時常變更的資訊放在 Markdown 文件方便修改，共用的資訊則設計成 config 來進行維護。

而 Markdown 文件、網頁，以及 OG 圖片的初始化，我則是設計對應的 Agent Skill 來處理。

這樣就能讓 AI 幫我快速完成第一版，而我也能在後續輕鬆調整細節。

我已經用 AI 寫了 3 年多的程式，最大的感觸是：

當我們開始思考專案架構的時候，Vibe Coding 的成果才會慢慢脫離 Demo，進入長期可用的狀態。

結語：從「用完就丟」到「越用越好」

回顧這隻影片，我們做了三件事：

1. 用 Codex 從零生成網頁
2. 把 AI 的隨機輸出，轉成可用 Markdown 維護的模板
3. 把模板打包成 Agent Skill，讓它可以重複使用。

在走完這整個流程之後，我感觸最深的，是發現 AI 真的可以把自己腦中的工作流，一點一點變成一套系統。

這個任務放在過去，是需要一個團隊，花好幾週的時間才有可能做到的。

但這次我只是在備課的過程中突然靈光乍現，然後就透過 Vibe Coding 完成了模板的雛形。

當然現在的它還不夠完美，但我覺得最有價值的，反而不是它現在功能有多完整。

而是從這一刻開始，我不再只是使用別人的工具。我也開始有能力，慢慢把工具設計成更符合自己需求的樣子。

而就是讓 Vibe Coding 的成果，從玩具走向產品的過程。

我認為 AI 真正厲害的地方，從來都不是幫你省下一次工作的時間；而是它開始讓你有機會，把自己原有的工作流，設計成一套可以持續優化的模板。

好的，今天的分享就到這邊，如果這篇文章對你有幫助，可以順手按個讚，並把文章分享給對 AI 主題感興趣的朋友們。

前陣子與朋友聚會時，我們交流了彼此用 AI 開發專案的心得。

然後發現一個值得討論的議題：「同樣在用 AI，有些人花很少額度就完成一堆任務；但有些人額度燒光，卻連一個問題都沒有解決。」

這種落差，大到讓人懷疑，我們真的在用同一個工具嗎？

為了釐清問題，我們乾脆直接打開電腦，實際 Demo 彼此的操作方式。

看完之後，發現問題其實不在 AI，而在「使用方式」。

我把幾個最關鍵的操作整理給你 👇

1️⃣ 遇到問題就丟給 AI，但每次都跑很久、還不一定解得掉

→ 因為沒有指定範圍，所以 AI 要掃描整個專案，過程不但浪費時間、消耗額度，還很容易改錯方向，衍生更多問題

2️⃣ 請 AI 新增功能，但沒有考量到既有架構

→ 在沒有足夠上下文與規格資訊的狀況下，AI 往往選擇「從頭做一份」，這種做法除了浪費額度外，還會讓專案越來越難維護

3️⃣ 每次調整功能，都要重新提醒規則與習慣

→ 在新的對話視窗中，AI 未必會記住你過去的使用習慣、判斷邏輯，所以要花很多時間在「資訊對齊」上面，甚至要自己手動調整細節

老實說，這些問題真的很常見。

因為很多人即使用了 AI 程式碼編輯器，還是把它當成「問答工具」。

但我認為 AI 的價值，是在幫你建立一套「可重複使用的工作流」。

而現在的 AI Agent 其實已經有對應的解決方案了

✔ 指定資料夾、文件，限定 AI 讀取範圍

💡 可以用「@」的方式，給予 AI 參考資料；當目的、方向明確後，AI 的效率與穩定性會大幅上升。

✔ 建立需求規格，讓 AI 迭代功能時有文件依據

💡 無論新舊專案，都可以透過 OpenSpec 來輔助建立專案的需求規格；這不但能解決團隊專案缺乏文件的痛點，還能讓 AI 與人類在未來迭代功能時更有依據，減少重工的問題。

✔ 設計 Rules / Commands / Agent Skills

💡 不管個人還是團隊，都一定會有自己的「使用習慣、判斷邏輯」，我們可以把通用規則寫在 Rules（不要說廢話、專注解決問題），特定情境的工作流放在 Commands（觸發多個 Skills 的固定流程），而希望 AI 使用的技能記錄到 Agent Skills（前端設計能力、撰寫 Commit、PR）。

不要讓 AI 的「快」，變成未來的「債」。

我自己現在更在意的，其實不是 AI 寫多快，而是：

1. 專案的規格是否足夠清晰，可以持續迭代
2. 新增修改功能時，有沒有影響到既有功能
3. 這次做出的成果，能否整理成 Agent Skill，讓下次直接使用

這些，才是真正會拉開差距的地方。

我在 4/21（二）有一場線上說明會，將透過實際 Demo，分享如何從「用 AI 寫程式」，轉變成「用 AI 建立開發流程」，邀請你免費參加！

如果你希望 AI 不只幫忙寫幾段程式碼，而是真正融入需求拆解、規格整理、開發協作、測試驗證與任務交付，或是有問題想與我線上討論。

那千萬別錯過這場說明會！

👉 立即報名: https://tibame.tw/Rsc3G

因此我請他示範平常的用法。

他先打開 ChatGPT、把需求貼上去、等回覆、複製回 VS Code、跑起來報錯、再把錯誤訊息貼回去問。

來回操作四五次後，我跟他說：「或許不是 AI 幫不了你，是你還沒用到合適的工具。」

使用 AI Agent，讓 AI 直接幫你做事

我使用 AI 輔助開發 3 年了，前兩年也是這樣用的；只把它當成一個比較聰明的「問答機器人」，有問題就問，問完自己動手。

直到去年開始用 AI 程式碼編輯器，整個工作效率才明顯提升，兩者的差別在於：

• 網頁版 AI 是「你問、它答、你自己做」。
• AI Agent 是「你說需求、它直接改程式碼、跑測試、遇到錯誤自己修」。

內訓那天，我開場就直接 Demo 了一段 AI Agent 的開發流程。

過程中我注意到，那位工程師全神貫注地盯著螢幕。

結束後他跟我說：「我之前以為 AI 就是那樣了，完全不知道已經能做到這種程度。」

他不是個案，很多學員的反應都差不多 ──

他們不是不想用，而是「從來沒有」體驗過 AI Agent 的威力，所以一直停留在複製貼上的階段。

直接問 AI 就好，幹嘛學？

不過，光是換工具還不夠。

社群上常有人說「有問題直接問 AI 就好，幹嘛學？」

也許未來有一天，AI 真的無所不能，但至少現在，還遠遠不是。

過去 3 年來，我已經在 AI 工具上投入數千小時學習，直到現在也還在持續研究與嘗試。

因為使用 AI 真正困難的，從來不是工具本身；而是你知不知道怎麼把問題交給它、做完後該怎麼驗證、做錯了又該怎麼修正。

從「知道 AI 可以寫程式」到「真的把它用在工作上」，中間那條路，才是最多人卡住的地方。

把目標從「學習工具」改為「解決痛點」

後來我發現，與其一直追著新工具跑，不如回頭看看自己的工作流，到底是哪裡卡住。

AI 時代每天都有新工具、更強的模型。如果目標是「學會工具」，學完很快就忘了。

但如果出發點是「解決痛點」，你就會開始去想：

• 需求怎麼寫，才不會讓 AI 跑偏？
• 功能迭代後，怎麼確保專案不會壞掉？
• 重複踩到的坑，有沒有辦法系統性地避免？

過去我也針對這些主題，拍了許多 AI 寫程式的實戰教學。

但我發現對剛接觸 AI 寫程式的人來說，很難透過碎片化的資訊，把技術應用到實際專案。

用實戰完整理解，減少認知負擔

所以我開了這堂課。

把過去 3 年摸索出來的開發流程，整理成一門從零開始的全端實戰課程。

不只帶你認識工具，更帶你走完一輪真實的開發流程：從需求釐清、專案初始化、自動化測試，到版本控制和 Code Review。

會讓你看到 AI 可以在哪些環節介入，以及遇到問題時該怎麼處理。

如果你也想把 AI 從「有在用」變成「融入工作流」，這門課就是我想給你的答案。

👉 完整課綱: https://tibame.tw/Zmnts

📌 專屬折扣碼: DEANONLY

最近收到的企業邀約中，除了有軟體部門想將 AI 導入開發工作流外，也有不少來自人力資源、執行業務部門的邀約。

而面對要客製化的課程，會先安排需求訪談。

開會過程中，有位客戶說的話讓我印象深刻，他說：

「我們企業的痛點，是開發系統的人不用系統；真正用系統的人不會開發，所以我們才想學 Vibe Coding。」

其實這個痛點是業界常態，以人力資源系統來舉例好了，雖然是工程師開發，但 HR 才是主要的使用者。

這導致不管前期規劃與設計有多麼詳盡，初步完成的產品在進入易用性測試後，還是會收到一大堆需求變更。

會有這樣的結果，並不是使用者很刁鑽；而是真正的問題，往往在使用後才會被發現；但這些並不是在前期設計，就能完全考慮到的。

所以有些企業想導入 Vibe Coding，目標是讓熟悉業務的人：

有能力設計出符合自己使用需求的產品，並希望完成的產品原型，未來能交給工程師做後續的優化與維護。

這個課程需求如果放在去年，我還真的不敢接；但最近 AI 成長的速度實在太快了。

今天跟大家介紹的 Claude Code，已經可以讓沒有任何程式基礎的人，在了解與 AI 對話的技巧後，生成出一套涵蓋前後端與資料庫的系統。

並透過與 OpenSpec 的搭配，讓 AI 幫忙撰寫專案文件，達成用規格驅動開發的目標；同時解決過去小白不知道如何撰寫規格，以及工程師不想寫文件的痛點。

在 Claude Code 與 OpenSpec 的幫助下，我們不僅能完成專案從 0 到 1 的建置，更可以做到從 1 到 100 的迭代。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【Claude Code 實戰】一次搞懂 OpenSpec，讓專案每次迭代都有依據

① 安裝 Claude 與 OpenSpec，初始化專案設定

安裝 Antigravity

今天這個教學，你可以使用自己熟悉的程式碼編輯器，不管是 VSCode、Cursor、Antigravity 都可以。

如果不知道使用哪一款，可以跟我一樣，使用 Google 最新推出的 AI 程式碼編輯器 Antigravity，登入 Google 帳號就能免費使用。

但這次，我們沒有要使用到編輯器內建的 AI 功能，使用他，只是為了方便檢視程式碼與規格文件的變更，並降低 Claude Code 的入門難度。

確認 Node.js 版本

因為今天分享的 OpenSpec 與實作的全端專案會使用到 Node.js。

所以，我們打開終端機輸入「node -v」，來確認電腦是否有完成安裝。

如果沒有顯示版號，而是出現沒有指令的錯誤訊息，就需要先去安裝 Node.js 才能執行後續步驟。

在安裝 Node.js 這塊，我建議大家透過 NVM 來安裝；因為 Node.js 有多個版本，而 NVM 這款工具可以幫你快速在不同版本間切換、更新。

如果你跟我一樣使用 Mac，執行下面的指令就可以安裝了：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash

但如果你是 Windows，就需要下載 exe 檔來安裝。

nvm 安裝完成後，要開啟新的終端機，然後輸入 nvm -v，確認有成功安裝。

接下來輸入 nvm install — lts 來安裝最新版本的 Node.js，安裝完畢後，輸入 node -v 便可檢視剛剛安裝的版本。

安裝 OpenSpec

在 Node.js 安裝完成後，我們要來安裝 OpenSpec，只要在終端機輸入指令，便可以完成全局安裝：

npm install -g @fission-ai/openspec@latest

透過這款工具，我們只要用白話的方式與 AI 對話，就能建立完善的規格，讓專案從零到一的過程更加完善。

而且日後擴增、修改功能時，不管人類還是 AI，都有對應的文件規格可以參考。

這可以盡量避免過去用 AI 寫程式時，相同功能重複被寫好幾次的痛點。

安裝 Claude Code

安裝好 OpenSpec 後，接下來要安裝 Claude Code。

你可選擇在終端機輸入指令安裝：

macOS, Linux, WSL:
```
curl -fsSL https://claude.ai/install.sh | bash
```

Windows PowerShell:
```
irm https://claude.ai/install.ps1 | iex
```

Windows CMD:
```
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd
```

但終端機對新手來說，用起來會比較有壓力，所以我更推薦在介面上操作；打開左側的 Extensions，搜尋 Claude Code 就能找到這個外掛。

點擊 Install 安裝完畢後，點擊 Open Claude 的按鈕，就可以打開他。

如果你過去使用過 Cursor 或是 Antigravity，其實操作上大同小異，就是有個對話視窗可以跟 AI 溝通。

但提醒大家，目前 Claude Code 只有付費版才能夠使用，你可以在對話框輸入「/login」來登入。

這邊我們選擇第一個，在網頁點擊授權後回到程式碼編輯器。

另外如果你使用免費版帳號，在登入時會出現這個提醒升級的畫面：

目前 Claude 的月費是每月 20 美金，如果看完今天的影片，覺得 Claude Code 很強大的話，可以考慮付費訂閱。

我認為「時間」才是最寶貴的資產；而「AI」可以幫助你奪回自己的時間。

在專案初始 OpenSpec

登入完成後，你可以在電腦建立一個專案用的空白資料夾，然後選擇 Explorer 用 Open Folder 的方式打開他。

由於這個專案要搭配 OpenSpec 輔助開發，所以要點擊 toggle panel 在終端機輸入：

openspec init

執行指令後，要點擊 Enter 進行初始化，這時問你使用哪些 AI 工具，你可以用「上下鍵」移動，並透過「空白鍵」做選擇。

他是可以多選的，但因為今天以 Claude 做示範，所以就只選 Claude Code。

完成後，就會在左側目錄下看到新增的資料夾，首先要介紹的是「.claude」的資料夾，這個裡面是存放驅動 OpenSpec 功能的 Agent Skills 技能包。

如果你在與 AI 對話的過程中，需求涉及專案的新增、修改、刪除等任務時，AI 會自動調用這些技能，不需要你特別去背指令，我覺得這才更符合 Vibe Coding 的開發流程。

如果你想更深入了解 Agent Skills，我過去有拍一隻影片分享安裝、使用、製作的技巧：https://youtu.be/xe00zJEtuMo

提醒一下大家，在指令不夠明確時，AI 可能不會觸發對應的 Skill，假如想強制驅動 openspec，可以在對話窗中輸入「/opsx」來操作。

目前預設只有提供 4 個指令，其實已經足以面對大多數的需求了。

如果你想要擴充指令的話，可以在終端機輸入

openspec config profile

此時會看到幾個選項：

1. Delivery 是指這些功能「裝在哪裡」

2. Workflows 則是這些功能「有哪些」

這邊我選擇「Delivery and workflows」示範給大家看：

1. Delivery 我選擇要同時安裝在 skills 跟 commands 中

2. 而 workflows 我就用空白鍵，把可以使用的都全選

完成後按下 Enter 就好，安裝好的 skills 跟 commands 會出現在資料夾底下：

如果你想知道每個 Skill 的具體功能，直接請 AI 解釋給你聽就好，這邊就直接貼提示詞，跟他說：

我想知道 openspec 目前安裝的 skill 用途
請使用表格呈現，用白話簡短描述

② 規格驅動開發，從零打造全端系統

安裝 Docker

根據過去經驗，最容易在環境設定上卡關的是「資料庫」，因為每個人電腦環境不同，所以要先安裝 Docker 這款工具。

你可以把 Docker 想成一個「標準化的容器」，把專案需要的環境通通打包在裡面，這樣不管你用 Mac 還是 Windows，打開就能跑，不用自己一個一個裝，也方便未來與其他人一起維護專案。

到官網根據自己的作業系統下載安裝後，就可以直接使用，不需要特別註冊、登入帳號。

在完成 Docker 安裝後，接下來，我們就能體驗 OpenSpec 加 Claude Code 的威力了。

過去的開發流程

今天的教學，我想以大部分上班族都會使用到的「出缺勤系統」作為範例。

在沒有 AI 輔助的年代，如果想完成這個系統，前期需要與 HR 部門開會釐清需求，然後請設計師根據需求完成每個頁面的流程示意圖。

過程中 PM 會把討論細節撰寫成需求規格，之後才會由工程師著手開發。

過去光是要做出能讓 HR 體驗的最小可行性系統（MVP），都至少要花一個月的時間。

但現在，前面的所有步驟，已經有機會讓沒有程式背景的 HR 自行完成。

大家不要急著留言說我妖言惑眾，看完示範後，就會知道這一切並不是誇飾。

Prompt 設計

完整提示詞如下：

請設計一個出缺勤管理系統，員工可以透過此系統打卡上下班
權限分成管理者與一般使用者，管理者可以修改、新增/刪除使用者
新增使用者時，會發送 Email 給予登入密碼
員工可透過系統請假、申請加班，申請假單需要簽核流程，並且有年假、補休申請，代理人制度

前端使用 React，後端使用 Express，資料庫用 Postgres
希望透過 Docker 啟動，並且要包含 Postgres Admin 網頁
這是初步需求，我們可以透過討論釐清細節後，參考 openspec 的 skill 執行

在提示詞中，我分成了 3 塊，分別是「專案目標、使用技術、細節討論」

• 專案目標：在專案目標這塊，我先大概說明自己的需求，一開始的描述有點模糊沒有關係，因為 AI 會在後續跟你釐清細節。

請設計一個出缺勤管理系統，員工可以透過此系統打卡上下班
權限分成管理者與一般使用者，管理者可以修改、新增/刪除使用者
新增使用者時，會發送 Email 給予登入密碼
員工可透過系統請假、申請加班，申請假單需要簽核流程，並且有年假、補休申請，代理人制度

• 使用技術：接下來則是描述使用技術，這個非常重要，如果希望專案完成原型後，可以由工程師團隊接手維護；一定要先詢問他們目前最擅長的「前端、後端、資料庫」是哪些，並且為了讓彼此環境一致、啟動更方便，所以我指定使用 Docker 來啟動。

前端使用 React，後端使用 Express，資料庫用 Postgres
希望透過 Docker 啟動專案，並且要包含 Postgres Admin 網頁

• 細節討論：最後則是提醒 AI 要與我們討論規格的細節，這樣可以釐清一開始沒說清楚的地方，最後要求他要參考 openspec 的 skill

這是初步需求，我們可以透過討論釐清細節後，參考 openspec 的 skill 執行

送出提示詞後，你可以看到 AI 會根據我們的需求提出問題，讓細節更加完善：

同時提醒一下大家，用 Plan Mode 的規劃會非常詳盡，如果大家想要加速體驗，可以在提示詞最後加上「以最小可行性方案來規劃」，否則執行下去跑半小時也是有可能的。

OpenSpec 撰寫專案文件

前面釐清完需求後，你會看到 AI 觸發 OpenSpec 的 Skills 做更細部的規劃：

• proposal.md：一開始會先建立 proposal，這個文件是用來確認目標是否正確、範圍是否合理。
• design.md：然後再進入技術規劃，design 文件就是在說明技術挑選的理由，以及專案可能會遇到的風險與處理方案。
• specs 資料夾：緊接著在 specs 資料夾底下，會根據功能區分資料夾，並分別建立說明細節的規格文件。
• task.md：在最後會設計一個執行任務的 task 文件，他是用來檢驗任務是否完成的列表，目前都是空的，等任務完成後才會打勾。

規格驅動開發（SDD）

確認以上規劃都符合預期後，說「開始實作」，AI 就會根據規劃開始撰寫程式了。

在等待一段時間後，AI 說他已經完成了初版，此時剛剛 Task 的任務列表已經全部打勾：

如果你不知道如何啟動專案，可以貼上下面的提示詞請 AI 幫忙啟動

幫我啟動專案，我想在 Local 開發前後端程式
只有 Postgres 跟 Postgres Admin 用 Docker 啟動
如果根目錄 README.md 沒有操作步驟，請協助補充

我個人建議第一次啟動可以請 AI 幫忙，因為處理較大型的專案時

AI 有很高的機率在第一版遇到一些零星錯誤，我們可以先讓他自我修正一下

初步驗證功能

啟動後就可以根據 AI 只是來確認功能是否符合預期。

首先我們可以正常打卡的，並且當打卡時間沒有在上班時間內時，會有遲到的訊息：

因為我們進來的權限是管理者，所以也可以進行使用者的新增、權限的設定：

再確認網頁內容可以順利瀏覽後，接著我們可以試著打開 Postgres Admin 網頁，看一下資料庫是否是否有順利寫入。

如果不知道這些資訊如何填寫，直接問 AI 就好了。

使用者的資訊會存放在 users 資料夾，這邊就能看到預設的 Admin 管理者帳號，以及剛剛新增的一般使用者：

接受此次變更

初步確認功能符合預期後，我們回到程式碼編輯器，可以跟他說

功能符合預期，進行歸檔

稍等一段時間後，你會發現原本空空的 specs 資料夾底下，出現專案對應的規格文件，而 archives 底下出現了歸檔的文件，並註明了對應的日期。

建立專案規則

在完成專案初步建立後，我們可以在 Claude 對話窗輸入「/init」，這個指令會掃描目前的專案結構，並在根目錄建立「CLAUDE.md」。

這份文件會在每次對話開始時自動載入，幫助 Claude 在未來開發過程中，能更了解這個專案的架構、技術、開發規則等資訊。

除了 Claude 的設定外，我們也可以幫 OpenSpec 建立規則，你可以在對話窗輸入這段提示詞：

Please read openspec/config.yaml and help me fill it out
with details about my project, tech stack, and conventions

這是請 AI 幫你填寫專案使用到的技術，以及需要遵守規則，目標是讓 OpenSpec 的 Skill 觸發時，有參考的慣例。

簡單來說，CLAUDE.md 是給「做事」用的，openspec/config.yaml 是給「規劃」用的。

③ 建立版本控制，根據需求迭代功能

在完成專案初版後，我強烈建議大家先建立版本控制，因為 Vibe Coding 時，你的每個指令都可能大幅調整專案程式。

但 AI 修改的結果未必是你要的，甚至有時會把正常的功能給改壞了。

為了把改壞的內容救回來，我會建議大家安裝 Git，這個程式碼版本控制工具，並註冊 GitHub 帳號來管理專案。

如果你是第一次接觸，我有專門錄一隻影片分享詳細的操作步驟！

https://www.youtube.com/watch?v=5DEV_K0JauQ&t=836s

設計 .gitignore

版本控制並不代表你需要把專案底下所有檔案都上傳，比如像「.env」這類有隱私資訊的檔案就不適合加入。

所以我們要建立「.gitignore」，把他從 Git 版控中移除；如果不確定專案有哪些檔案、資料夾要加入「.gitignore」，可以使用下面的提示詞：

請幫我設計專案的「.gitignore」
但「.claude、openspec」要加入版本控制

建立版本控制

完成前面 Git 的相關設定後，可以點擊左側的 Source Control，點擊 Initialize Repository 可以初始化專案。

接著點擊 Generate，AI 就會辨識我們更新的內容，來產生 commit 訊息；確認文字描述符合自己的預期後，點擊 commit，就會在自己的電腦記錄這個變更。

但如果想更新到雲端，你需要點擊 Publish Branch才會正式上傳喔！

如果專案尚未存在於 GitHub，會有彈窗出現，讓你輸入專案名稱，這邊我就用跟資料夾一樣的就好了。

如果你的專案沒打算對外公開原始碼，我建議選擇 Private 隱私模式，完成後，點擊 Open GitHub 去看看是否部署順利。

如果能看到專案的內容，就代表你成功上傳專案了！

迭代功能

其實不管 Vibe Coding 還是開發系統，最難的並不是 0 到 1，而是 1 到 100 的那段路。

不過有了 OpenSpec 的幫助，這一切會變得容易許多。

這邊我們開一個新對話窗來處理新任務，比如我們可能會有忘記打卡的情形發生，就可以跟 AI 說：

幫我設計忘打卡的處理方案，讓規則彈性一點，使用 OpenSpec

這樣 AI 就會開始著手設計，並根據 OpenSpec 的 SKill 建立對應的需求規格；稍等一段時間後，AI 就完成了前期的設計。

由於我們有加入 Git 做版本控制，所以可以在 Source Control 中，清楚看到 AI 撰寫的需求變更規格書。

再確認需求與自己的期待相符後，接下來的流程都是一樣的，直接跟他說「開始實作」就好。

驗證功能

等 AI 完成調整後，因為功能涉及後端與資料庫，所以我會建議大家跟 AI 說：

請協助確認資料庫變更是否執行，並幫我重新啟動後端程式

等 AI 執行完畢後，我們再去瀏覽網頁，這樣測試會比較準。

畫面中能看到補打卡的功能完成新增：

申請補打卡：

核准補打卡：

確認結果生效：

功能歸檔

確認沒問題後，回到程式碼編輯器，直接在與 AI 的對話窗說

幫我歸檔

稍等一段時間後，你就會看到 archive 裡面多了一個資料夾，裡面放的就是這次的變更。

另外專案的 specs 也有進行對應的調整，綠色是新增，黃色是變更的意思。

這邊也提醒大家，每做完一件事，記得保持 commit 的好習慣；這樣每個版本完成的功能會比較明確，而不是一堆功能全部混一起。

模擬測試資料

補充一個情境，不是所有變更，都會觸發 OpenSpec 的 Skill。

比如目前專案初始狀態下，只有一個 Admin 的帳號，這樣想測試多位使用者的不同情境，要自己手動慢慢加，很沒效率。

此時我們就可以請 AI 幫忙設計模擬資料，我就跟他說：

我想要根據權限建立多位使用者，來模擬不同情境

因為這個需求不會涉及到功能上的改變，所以不會觸發 OpenSpec 的 Skill

等 AI 完成後，我們可以到員工管理看一下，哇！真的建立了對應的員工資料：

這樣可以方便我們測試更加複雜的流程。

設定 Email SMTP

另外如果有功能卡住，不知道如何處理時，也可以先詢問 AI 如何設定。

比如新增員工時，會需要寄信通知，但如果環境變數沒有設定好，信件是不會發送的。

此時就可以詢問 AI：

我要如何設定環境變數，讓 email 可以順利寄出？

這邊他就說 Gmail 要開啟兩步驟驗證，我們就點擊對應的網址來進行設定。

設定完成後，因為我們有更新到「.env」環境檔，所以要重啟才會生效，你可以直接請 AI 幫忙：

幫我重啟後端

重啟完畢後，我們再新增一個使用者測試是否能收到信件：

如果你也跟著教學走到了這一步，先給自己拍拍手，然後別忘記幫文章點個讚。

你已經初步完成一個有資料庫的全端系統啦！

AI 正在改變企業決策

如果在幾個月前拍這個主題，我肯定會從 AI 完成的系統挑出很多安全性的漏洞。

但這次拍完教學後有點被嚇到，雖然還是遇到了許多功能上 Bug，但我已經無法在短時間找出系統漏洞了。

以往這類的出缺勤管理系統，企業都是要找特定廠商購買，並且支付年費來維護的；但 Vibe Coding 的出現，可能會導致企業做出不同的選擇。

不過提醒大家，目前只是完成系統的初版，如果接下來打算在團隊內開發協作，還需要設計合適的工作流。

我過去有拍一隻影片，分享如何解決版本控制與團隊協作的痛點：https://youtu.be/1VuLTQidbPM

另外如果你想要讓系統更穩定，還需要加入自動化測試，畢竟市場不會為爛產品買單：https://youtu.be/Rb0_LutRIaw

別忘記，不管 AI 有多強大，出事還是要人類來背鍋。

結語：AI 時代下每個人，正在經歷角色的轉變

其實我是懷抱沈重的心情發布這期影片的，因為今天介紹的 OpenSpec 與 Claude Code 給了我完全不同的開發體驗。

如果你是工程師，一定要嘗試看看這個工具組合；假使你沒有程式背景，建議跟著影片實作一遍。

其實早在幾個月前，我就想拍攝這個主題了。

但用相同的指令，當時 AI 完成的初版，連專案啟動都有問題。我需要來回溝通十幾次，才能勉強讓專案跑起來，但結果還是漏洞百出。

可是今天這期影片想必大家也都看到了，我們已經能用簡單的提示詞生成一個有資料庫、登入功能的前後端系統。

儘管中間遇到了一些小問題，目前版本也有許多細節要優化。

但光是這個版本，放在過去可是要一個專業團隊才有辦法完成。

也許這樣說會被很多人罵，但我還是想提醒大家，尤其是工程師。

過去，程式碼是個昂貴的產品，但不是程式碼本身貴，而是要產生出有意義的程式，需要大量的經驗、專業。

但 AI 的發展正在讓程式碼快速貶值，因為 AI 不僅寫程式很快，品質還越來越優秀。

不過今天這隻影片想傳遞的不是「工程師已死」，這類網路上爛大街的口號。

而是透過實際的範例告訴大家，在 AI 時代下的每個人，大家正在經歷角色的轉變。

工程師的重點不再是寫了多少行程式，而是去評估系統架構、審查程式碼合理性。

而 PM 與執行業務單位，也不再只是眼巴巴的等工程師開發，在 AI 的輔助下，他們已經可以嘗試加入開發。

這中間當然還有很多細節要磨合，我自己也還在摸索。

但有件事我可以肯定，現在的開發分工，跟過去相比已經不一樣了；而不久的將來，變化只會更快。

好的，今天的分享就到這邊，如果這篇文章對你有幫助，可以順手按個讚，並把文章分享給對 AI 主題感興趣的朋友們。

最近與一群工程師朋友聚餐時，我們聊到公司導入 AI 加速開發後，遇到的各種問題。

其中討論最熱烈的點，就是大家 Code Review 的負擔大幅增加，畢竟 AI 寫程式的速度，實在太快了。

在過去，一天完成既定工作量就是好員工；但現在有了 AI 的幫助，有些公司會認為，一天要完成 3 倍工作量才算達到 KPI。

而這，就衍生了一系列的問題：

① 缺乏深度思考

因為 KPI 大幅上升，大家為了追上進度，就會犧牲對需求的深度思考，或者說，直接讓 AI 代替思考。

② 懶得 Code Review

完成的功能增加，就會導致功能合併到主線時的 Code Review 負擔，以往會認真思考別人的設計是否合理，但如果要看的份量太多，很多人就放棄理解直接合併。

③ 最終導致的結果

團隊集體責任感下降、專案理解力降低、程式碼品質降低、上線後錯誤增加。

切記，我們雖然可以讓 AI 自己檢查、修改、寫測試程式，但這只是確保產品的底線。

假使用 AI 開發過中大型專案，就會理解全權交給 AI 有多麼的不切實際。

AI 產生的程式碼很多，但這不是你不檢查的原因，我們應該去想怎麼利用 AI 去優化檢查流程。

別忘記，當你對 AI 產出的內容，按下同意的那一刻，所有的錯誤必須由人類來承擔。

所以今天這篇文章，我要跟大家分享如何用 Git Worktree 搭配 Agent Skills，來解決前面提到的痛點：

① 爲什麼版本控制很重要

我會先展示一個經典的錯誤案例，讓大家更直觀的理解，如果沒有基礎的版本控制概念，專案會遭遇哪些災難。

② 完成前置作業

接著帶大家了解 Git Worktree 基礎操作，並安裝 pnpm 減少磁碟空間浪費，以及分享有哪些好用的擴充套件能增加我們操作效率。

③ Agent Skills：透過 Git Worktree 拆分任務、設計 SPEC

然後就要進入實作階段，這邊會先提出一個複雜功能，以此觸發 Agent Skills 執行 Git Worktree 拆分任務，讓每個功能都有自己的工作區，這樣 AI Agent 就可以同時執行。

④ Agent Skills：拆分 Commit，讓邏輯可被追蹤

在確認功能符合預期後，我會請 AI 根據調整檔案分階段的 commit，讓邏輯在未來可以被追蹤。

⑤ 降低 Code Review 負擔

把修改推送上去後，我們要透過 Pull Request 將變更的內容合併到主分支，為了讓 Code Review 的人快速理解，我們可以請 AI 根據變更生成 PR 模板。

如果你是第一次接觸 Agent Skills，我過去有拍一隻影片分享安裝、使用、製作的技巧：https://youtu.be/xe00zJEtuMo

如果你剛接觸 Vibe Coding ，或是進入職場不久，相信這隻影片會讓你了解業界在導入 AI 開發時，遇到的實際狀況。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【Git Worktree 實戰】指揮 AI Agents 同時運作，搭配 Agent Skills 建立自動化協作體系

① 缺乏版控概念，是災難的起點

現在輸入簡單的指令，AI 就可以根據需求完成功能，甚至一口氣完成 10 個功能都沒有問題。

從表面上來看，效率倍增，但實際上有非常多的隱患，這邊展示一個實際案例讓大家更能理解：

在團隊合作時，如果想把自己的修改合併回主線，會先開一個 Pull Request，讓其他人幫你檢查程式碼、討論是否需要修改，確認沒問題後再合併。

以這個 Pull Request 舉例，標題寫著「新增 i18n 多語系、淺色深色主題設計、常見 QA 問答區…」等多個功能，感覺做了很多事。

但從專案管理的角度來看，其實每個功能都應該對應到不同的 feature branch，不要在一個分支中放多個功能。

把視角切換到「Files changed」，你會對我說的話更有體會，像這個 Pull Request 涵蓋了 18 個檔案，有近千多行的程式變更；從 Code Review 的角度來看，你根本無法了解變更的功能要對應到哪些檔案。

再來，我們看一下「Commits」的分頁，你會發現改了這麼多功能，竟然只有一個 commit，而且訊息也非常的簡單。

這會導致未來發生問題時，我們無法追溯當時的設計邏輯，完全沒有參考價值。

其實這邊所展示的問題，在過去就已經存在了，但在使用 AI 加速開發後，問題被成倍放大。

因此接下來要跟大家分享，如何透過 Git Worktree 與 Agent Skills 來解決這些痛點。

② 建立 Git Worktree 環境：Git + pnpm + Extensions

為了方便大家可以跟著影片操作，我在 GitHub 有上傳一個練習用的專案，歡迎大家路過按個 Star：

這邊我建議大家點擊 fork，將專案複製到自己的帳號下：

然後點擊 Code，從裡面複製專案網址：

接著打開你熟悉的程式碼編輯器，這邊我以 Google 最近推出的 Antigravity 來示範，這是 Google 最新推出的 AI 程式碼編輯

目前登入 Google 帳號就可以使用，但如果付費升級到 Pro 會有更高的使用額度：

但如果你熟悉的是 Cursor 或 Claude 等其他 AI 工具也沒關係，因為以 Agent Skills 的設定來說，只有路徑稍微不同而已。

好的，我們再把注意力轉回 Antigravity，點擊 Clone Repository，貼上剛剛複製的網址來下載專案：

接下來要先跟大家分享，安裝哪些工具可以更舒適的使用 Git Worktree 功能：

確認 Git 版本

首先，我們要確認電腦的 Git 版本。

提醒一下大家，因為這隻影片會使用到 Node.js 與 Git 等技術，如果你是第一次接觸，我有專門錄一隻影片分享詳細的操作步驟喔！

https://youtu.be/5DEV_K0JauQ

安裝好 Git 後，點擊上方的 Toggle Panel 開啟終端機，輸入指令 git -v 確認有正確安裝。

另外提醒安裝過的朋友，如果你的版本低於 2.30，建議升級到最新版本，這樣 Git Worktree 功能會較為完整。

安裝 pnpm

因為 Git Worktree 會建立多個工作目錄，而 Node.js 專案的 node_modules 動輒上百 MB。

如果用 npm 安裝會消耗大量硬碟資源，因此我推薦大家使用 pnpm 這款套件。

在終端機輸入 npm install -g pnpm 便可完成全局安裝。

pnpm 會將所有套件存放在電腦的一個共用儲存區，各專案的 node_modules 只是透過連結指向同一份套件。

雖然每個 Worktree 需要執行 pnpm install，但不會重新下載套件，非常適合搭配 Git Worktree 進行並行開發。

安裝 Extensions

然後我們把視角轉到左側選單，點擊「Extensions」的分頁，這邊推薦大家安裝兩款外掛。

第一款是「Git Worktree Manager」，他能讓你透過介面輕鬆的建立、切換、清理 Worktree。

第二款是「GitLens」，安裝好後，你把滑鼠移到對應的程式碼位置時，可以直接看到 Commit 的歷史。

不過這邊要提醒一下大家，這些外掛大部分是由第三方開發的，安裝前請自行評估安全性。

了解 Git Worktree 工作模式

做好前置作業後，我們先在終端機輸入 pnpm install 安裝套件。

安裝完成後，輸入 pnpm run dev 便可啟動專案，下面就會有一個「localhost:3000」的網址。

確認專案可以順利啟動後，我們回到 Antigravity，點擊左側剛剛安裝好的「Git Worktree Manager」，然後點擊這個資料夾的符號來新增 Worktree。

因為我們要從現在的主分支，切換到其他分支，所以選擇第一個「Create new branch」

至於分支的名稱就打 test，主要是先讓大家了解 Git Worktree 概念；至於目錄，使用系統自動生成的就好了，最後點擊「Create」，就會直接把工作區的內容複製一份過去。

此時，你就會看到 test 出現在 Worktree List 當中：

點擊後便會開啟一個新的工作區，打開終端機後，要在輸入 pnpm install 來安裝套件；你會發現套件幾乎在瞬間安裝完畢，打開 node_modules 資料夾，你會發現有箭頭圖示「↩」。

代表只是建立資料夾的連結，而非重新下載套件，這就是 pnpm 的運作方式，可以幫我們節省硬碟空間。

然後我們嘗試輸入 pnpm run dev 啟動專案，這次的網址變成了「localhost:3001」，點擊後，網頁也可以順利呈現。

這邊的示範，是想要讓大家了解每個 Worktree 都是獨立的工作目錄，所以可以同時跑不同的 dev server 跟 port。

當然，也代表我們可以同時指揮多個 AI Agent 並行開發不同功能。

也跟大家說明一下，如何把 Worktree 刪除；在刪除前，請先把剛剛啟動的專案關閉。

然後回到 Git Worktree Manager 的介面，點擊右鍵，在 Worktree Action 當中選擇 Remove Worktree，就可以移除了。

③ Agent Skill：自動建立分支與開發規格

前面有說到，不同的功能應該使用不同的 feature branch 來開發；但具體怎麼拆分功能，以及 branch 的名稱如何命名，我們可以直接設計一個 Agent Skill 來幫我們搞定。

如果你是 Fork 我的專案，在根目錄下方會有一個「.agent」的資料夾，我有放一些 Skills 讓大家跟著影片一起體驗：

像這邊我設計了一個 git-worktree-design 技能，把 Markdown 點開來後，跟大家說明一下設計的邏輯：

1. 首先會檢查目前專案分支的狀況，確認既有 Worktree，以及是否有沒提交的變更。
2. 然後將複雜的需求拆成獨立的 feature branch 以及參考的規格後，用表格預覽，使用者確認後才會執行。
3. 接下來就會根據 Skill 指定的格式建立 Worktree。
4. 並順便安裝好每個 Worktree 的套件。
5. 然後新增這個 feature 要執行的 SPEC，方便後續 AI Agent 的開發。
6. 完成以上任務後，會再用表格像我們展示完成的結果。

了解 Skill 的設計邏輯後，我們在右側與 AI 的對話視窗中，輸入指令

採用 Worktree，新增淺色深色主題設計、常見 QA 問答區、Cookie 同意彈窗

此時，你會發現 AI 判斷需要使用 Git Worktree 這個 Skill，並初步規劃了每個 Worktree 要參考的規格：

確認沒問題後，就可以讓 AI 幫我們執行下去，稍等一段時間後，AI 說他已經幫我們完成了對應的設計。

打開左側 Git Worktree Manager 的分頁，可以看到看到新增的 Worktree：

這邊點擊其中一個 Worktree，你可以看到 AI 有根據我們的指示，用 pnpm 來安裝套件，所以 node_modules 下面資料夾有這個箭頭符號。

並且根目錄的地方有存放給「git-Worktree-spec.md」這個給 AI Agent 參考的規格，確保執行的方向。

④ 指揮多個 AI Agents 同時執行

但讓 AI 參考規格開發前，跟大家分享一個小技巧。先開啟與 AI 對話的視窗，點擊右上方的「…」選擇 Customizations，選擇 Workflows：

我有設計一個自動化流程，這樣只要輸入快捷鍵，就可以讓 AI 知道讀取規格、執行實作、驗收結果的步驟：

這邊我們先點開其中一個 Worktree，輸入「/」，選擇剛剛的那個 workflow，點擊「Enter」他就會開始執行了：

以往我們開發功能因為在同一個工作區，所以需要一個完成後才能執行下一個。

但用 Git Worktree 的好處，就是可以多個 AI Agent 同時執行。這邊我也把另外兩個 Worktree 打開，輸入「/」讓他們根據 workflow 來執行。

但如果如果要在多個視窗切換，來觀察不同 AI Agent 執行的進度有點麻煩。

所以我們可以點擊上方的「Open Agent Manager」，這樣就能知道 Agent 執行的過程是否需要我們介入。

像這邊轉圈圈就是代表執行中，而稍等一段時間後，就會變成鈴鐺提醒的符號。

稍等一段時間後，AI 就在不同的工作區，完成了各自的功能，這邊我們也可以從 SPEC 的修改中，看到他已經自我驗證了功能符合需求。

但 AI 完成後，人類一定也要自行確認結果是否符合期待，這邊我先開啟各個 worktree 的瀏覽器。

把所有服務都啟動後，也剛好趁這個機會，跟大家說明不同功能分 feature 開發的好處

首先是我們人類驗證功能會比較輕鬆，因為要確認的面向單一

• 像 Cookie 的部分，就是下方在使用者進入時，會有彈窗提示

• 而淺色深色主題這塊，則是上方多了一個按鈕，讓使用者自由切換主題

• 至於常見問答，也有根據主題新增了對應的區塊

再確認修改符合預期後，先把 Agent Manager 關閉，我們要把 Worktree 的變更推送上去。

比如我們來打開淺色深色主題的 Worktree，以往我們可能是人工手打，或是點擊「Generate」讓 AI 自動產生。

但人工手打不僅耗時，每個人的撰寫習慣也各不相同；但假使點擊 Generate 讓 AI 自動產生，他生成的訊息有時候是英文，有時是中文，而且長短很隨機。

所以 commit 這塊，我也有設計一個 Skill，讓 AI 根據我的指引生成。

我們先回到專案的目錄，點擊「.agent」資料夾，在 skills 底下有一個「git-smart-commit」的技能：

他的任務就是把雜亂的變更，拆分成有意義的 commit；畢竟請 AI 輔助開發時，很可能一口氣改了很多個檔案，如果全部放在一個 commit，那這個 commit 就跟沒寫一樣。

這邊我們把左側的選單切換到 Source Control，你就會看到這個淺色深色主題有修改到多個檔案

這邊我就在對話窗輸入

新增 commit

稍等一段時間，會看到 AI 根據變更的檔案，生成對應的 commit 訊息：

commit 送出後，記得要點擊 Publish Branch 才會將檔案上傳喔！

完成後可以把這個工作區關閉，另外兩個 Worktree 也是一樣操作即可。

都 Publish 之後，我們回到 GitHub 網頁，此時你會看到下拉選單中有剛剛上傳的 branch：

隨便點擊一個，就可以看到剛剛撰寫的 commit 訊息：

但目前的 feature 都在不同的 branch，所以接下來會帶大家透過 Pull Reqeust，將功能合併到主線。

⑤ 好的 Pull Request，讓 Code Review 變輕鬆

這邊先點擊上方的「Pull Requests」：

選擇「New Pull Requests」：

如果你是 fork 我的專案，這邊要特別注意，base 要改成自己的帳號，然後 compare 要選擇想合併進來的 feature 分支：

建立 PR 後，你會看到要填寫標題與描述，根據我的工作經驗，PR 是決定專案品質的重要環節：

因為他是讓團隊成員 Code Review 時，理解你到底做了些什麼的文件

如果隨便寫寫，那審核的人通常也是隨意看看；畢竟直接讀程式碼，去理解功能為何這樣設計，真的太消耗腦力了。

我知道很多人嫌寫 PR 很麻煩，所以我也設計了一個 Skill，用來生成 Pull Request 的草稿。

這邊我們把視角切換到 Antigravity，這個 Skill 一樣是放在「.agent/skills」底下，名稱叫做「git-pr-description」。

這邊跟大家簡述這個 Skill 的設計

1. 首先，預設合併的目標為 master 這個主線分支，如果你是用 main/develop 等其他的分支請自行調整。
2. 接下來就會把當前的分支與目標分支進行比對，讀取差異的檔案與 commit 訊息，這邊也再次跟大家提醒 commit 訊息是很重要的，你不想寫，至少要讓 AI 幫你寫吧。
3. 而後就是分析變更的內容，然後生成 Pull Request 的 Title 與 Description。
4. 其中 Description 的部分，我是要求他參考「pr-template」的這個範例檔來撰寫，如果大家想把這個 Skill 導入目前的工作流，可以改寫這個檔案。

講了這麼多，我直接示範給大家看比較快；一樣打開 Agent Manager，然後再各自的 Agent 輸入。

撰寫 PR

稍等一段時間後，他就會根據 Skill 提供的格式生成 Pull Request 的草稿了：

這邊我們把它複製到 GitHub 後，我強烈建議大家至少要跟著測試案例執行過一遍。

如果是前端專案的話，建議附上對應的圖片，這樣可以減少別人 Code Review 時的負擔，同時也確認了功能符合預期。

如果專案是自己開發的，那就直接點擊 Merge 合併就好。

接下來回到 Antigravity，合併好的 Worktree，我個人會建議直接點擊右鍵，在 Worktree Action 當中選擇 Remove Worktree 將他移除，避免 Worktree 太多管理困難。

至於另外兩個 Worktree 也是一樣操作，先建立 Pull Request，接著用 AI 生成對應的 Review 草稿，確認沒問題後合併回主線，完成這一切後記得移除 Worktree。

但有一點要提醒一下大家，因為 Worktree AI Agent 同時開發，所以開發當下不會知道彼此的變更

所以把功能合併回主線時，可能出現衝突；像常見問答跟淺色深色的分支在合併時，都遇到了這個問題：

點擊「Resolve conflicts」可以看到發生衝突的位置，但我個人並不建議在網頁上調整，因為你無法得知調整後的實際狀況：

我建議回到程式碼編輯器上操作，本地解決完衝突，確認結果符合預期後再更新上去。

這邊先回到 Antigravity 的頁面，我以切換淺色深色主題這個分支來做示範。

首先，我們要打開終端機，執行 git fetch origin 拉取遠端最新資料 然後再執行 git merge origin/master 來同步主線的更新。

執行後，你就會發現左側 Source Control 這個地方，在 Merge Changes 有一個衝突的檔案：

打開後就會看到產生衝突的位置，衝突通常分成「語法衝突」跟「邏輯衝突」。

邏輯衝突較難處理，因為要考量到相容性或是改寫程式，這個之後有機會透過一個主題專門分享。

而現在看到的這個是調整 CSS 網頁外型的語法衝突；只是括號位置撞到了而已，所以我選擇 Accept Current Change。

這邊也跟大家提一下前面安裝 Gitlens 外掛的好處，像這邊滑鼠移到程式碼時，你就可以看到當時是誰更新了這段程式、更新的目的是什麼：

處理完衝突後，按下「+」，然後輸入 commit

chore: sync with master

這是與主線同步的意思，然後點擊「Sync Changes」推送上去。

此時回到 GitHub，刷新一下網頁，就會發現可以順利合併嚕！

等所有 feature 都合併到主線後，我們可以在 master 的這個地方輸入 git pull，拉回變更。

然後輸入 pnpm run dev，來確認合併後的內容是否符合預期。

這邊把視角切到網頁，我們可以看到第一次進入時，下方會有 Cookie 的詢問視窗，上面可以切換淺色、深色主題，往下滑一點，常見問題的段落也有順利顯示。

如果文章看到這邊，先給自己拍拍手，然後別忘記幫忙點個讚。

假使你有跟著教學做到這個步驟，歡迎留言，讓我知道觀眾裡面有狠人，因為這個主題真的不容易。

結語：人，才是 AI 的瓶頸

完成這隻影片後，我不禁有個特別的感悟。

因為這隻影片不管是專案範例、Commit 訊息、Agent Skills，甚至連 Pull Request 都是 AI 生成的。

我從頭到尾一行程式都沒有寫，主要任務就是去 Review AI 給的建議、執行的成果。

我想未來絕大多數產品，背後也都是 AI 在進行開發與迭代。

但這並不代表 AI 可以取代工程師，雖然現在人人都可以寫程式；但「團隊溝通、功能擴充、系統維護、問題解決」都是需要經驗的。

就拿今天的影片來舉例好了，我是因為觀察到 Code Review 的速度，已經跟不上 AI 寫程式的速度。

當人成為 AI 的瓶頸時，就要去分析如何降低門檻。

比如不同功能要建立各自的分支，以減少 Code Review 的認知負擔。又或者完成功能後，請 AI 分析程式碼分段 commit，並撰寫 Pull Request 草稿，讓團隊協作的資訊有一致性。

雖然每一步都是 AI 在執行，但如果沒有業界的實戰經驗，大家對這些工具如何與 AI 協作是沒有概念的。

但這些才是真正的痛點，只要設計好就能提升個人與團隊的工作效率。

當然，我相信一定還有很多更好的方案，歡迎大家留言分享。

最後提醒大家，不管 AI 多強大，總需要有個人按下同意按鈕。

當你按下去的那刻，責任就歸屬於你，畢竟 AI 還不能幫人背鍋。

如果這篇文章對你有幫助，可以順手按個讚，並把文章分享給對 AI 主題感興趣的朋友們。

用 AI Agent 工具一段時間後，你可能會遇到下面幾個痛點：

① 不知如何下好指令

前陣子收到觀眾私訊，他說：「我覺得 Google AI Studio 的美感比較好，Antigravity 的設計有點醜。」

但其實造成這個問題的關鍵原因，不是工具而是指令；如果你有給 AI 指定的風格、參考的設計，甚至是配色的引導，那肯定能獲得更理想的結果。

不過大部分的人，並不具備這些專業知識。

② 需要重複貼上提示詞

比如寫程式時要 AI 遵守特定的 Coding Style、撰寫企劃時要 AI 參考指定的模板架構，就連現在大家看的這個影片，下面的字幕都是請 AI 執行特定流程優化的。

儘管我根據不同情境設計對應的提示詞；但隨著提示詞數量增加，需要時都要找半天，甚至忘記自己設計過，浪費時間重寫一個。

③ 使用額度快速耗盡

如果看過我過去幾篇文章，你可能已經根據自己的工作需求設定了 Rules。

如果你只是設定通用型的 Rule 那沒什麼問題，但如果每個情境都有設計對應的規則，那 Token 額度會消耗很快。

因為 AI 開啟新對話時，會先載入這些 Rules，並在後續對話中檢查是否需要遵守；如果設計太多不僅會浪費額度，有時還會因為資訊過載導致忽略規則。

而今天跟分享的 Skill，就是用來解決這些痛點的。

你可以把 Skill 想像成一個技能包，裡面有精心設計過的提示詞（Prompt）、程式腳本（Scripts）、參考資源（Reference）。

而現在的 AI Agent，有能力在收到你的指令後，透過閱讀技能包的描述，自行判斷使用時機。

所以我們只要安裝合適的技能包，並根據自己的需求建立技能，AI 就能夠從庸才走向專家。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【Antigravity Agent Skills 教學】當別人還在複製貼上，你的 AI 已經自動搞定

① Rule/Workflow/Skill 的使用場景

為了方便大家了解 Skill 如何運作，我在 GitHub 有上傳一個練習用的專案：

https://github.com/dean9703111/ai-agent-skill-for-video-workflow

這篇文章使用 Antigravity 來做示範，但如果你熟悉的是 Cursor 或 Claude 等其他 AI 工具也沒關係，因為以 Skill 的設定來說，只有路徑稍微不同而已。

接下來跟大家說明 Rule/Workflow/Skill 各自的使用場景：

Rules — 通用規則

在這邊填寫的內容，以「通用規則」為主，在大多數場景都能直接適用。

我並不建議大家把 Rule 的內容寫得太仔細，因為每次開啟新對話時，AI 都會把這份文件讀一遍。

換句話說，過多的 Rule 不僅會佔用上下文空間浪費 Token 額度，還可能載入一些不必要的資訊造成幻覺。

如果想根據不同場景設計，建議使用後面提到的 Skill 方案。

Workflows — 工作流

相比於每次都會觸發的 Rule 規則，Workflow 就需要用「/」才能呼叫執行；通常會在這邊設計有明確步驟，邏輯較為複雜的工作流。

以這個範例來說，我就是在一個 Workflow 裡面根據不同情境使用多個 Skills：

這個工作流就是方便我在完成影片拍攝後，執行「上字幕、設計字卡、影片介紹」等後期工作。

你會發現每個步驟我都有讓他參考單獨的 Skill，而不是直接把完整邏輯寫在裡面，這個設計是讓我在未來擴充與維護上更有彈性。

Skills — 專業技能

相比於 Rule 會閱讀完整份文件，Skill 則是在你送出提示詞後，根據需求來使用。

● Skill — Discovery

比如我這邊建立了「音訊轉字幕（audio-to-srt）、優化字幕（srt-enhancer）、設計字卡（srt-card-annotator）、影片介紹（srt-social-summary）」的 Skills。

之所以用這些技能舉例，是想提醒大家，AI Agent 並不是只能用來寫程式，分析資源、內容創作的表現也是很棒的。

這邊打開與 AI 的對話窗，把測試用的音訊檔案拖曳進去後，輸入轉 SRT 字幕檔

他就會開始搜尋是否有跟任務相關的 Skill。

● Skill — Activation

像這裡，我們看到他匹配到了「audio-to-srt」這個 Skill，此時他才會完整閱讀整份 Markdown 文件。

在這之前 AI 只會先閱讀文件裡面的技能名稱與描述，可以大幅節省 Token。

從 AI 的視角來說，有點像是我們用 Google 搜尋時，會先看到標題與描述。

● Skill — Execution

接著 AI 就會跟著文件描述逐步執行，如果環境沒有設定好，AI 也會輔助你安裝所需資源；也提醒一下大家，如果你跟我一樣使用 Mac，但版本沒有升級到 Sonoma 以上，套件安裝可能會失敗。

這邊警告一下大家，如果你找到的 Skill 底下有 scripts 要執行，請謹慎評估，因為你並不確定這些程式是否含有惡意程式。

稍等一段時間，就可以看到 srt 字幕檔在 Skill 的幫助下生成完畢。

Skill 除了有 scripts 這個存放執行腳本的資料夾，還有一個存放參考資料的 references 資料夾。

這邊我以「srt-social-summary」這個用來做影片簡介的 Skill 舉例，為了讓影片被更多人看到，我需要到 Facebook、Thread、YouTube 等不同平台宣傳。

但不同平台都有自己的特性，而 references 的文件就是用來補充這些細節的參考資源。比如 HashTag 要如何標記、開頭怎麼吸引人、不同平台的內容要怎麼撰寫。

這些細節不用寫在「SKILL.md」裏面，讓 AI 判斷有需求的時候再去讀取就好，這是一個漸進式揭露（Progressive Disclosure）的技巧。

② 站在巨人的肩膀，使用設計好的 Skill

在初步理解 Skill 的運作原理後，接下來我會透過實戰，讓大家直觀的了解「不使用 Skill」與「使用 Skill」所帶來的差異。

不使用 Skills

這邊先展示「不使用 Skills」的原始狀態，我準備了自己的個人簡歷與參考圖片，請他幫我客製化一個能呈現專業的個人品牌網頁。

參考來源履歷後，新增資料夾「personal-website」，設計一個有專業質感的中文個人品牌網頁

稍等一段時間後我們得到了一個網頁，打開後你會覺得這個畫面的配色有熟悉的藍紫色，排版也有種 AI 感，距離好看的網頁還有一段距離。

安裝 Skills

所以接下來我們要為專案新增一個 Skill，這邊推薦大家可以到 SkillsMP 這個網站: https://skillsmp.com/

有些多人把自己建立好的 Skill 分享出來讓大家使用，你可以看到總數已經超過了 10 萬個。

你可以透過英文的關鍵字，來搜尋自己想要的 Skill；比如你如果想要設計個人形象網頁，你可以輸入「frontend-design」

這邊就會看到一個由 anthropics 官方建立的 Skill，如果想要安裝他，直接複製上面的指令就可以了。

這邊提醒一下大家，如果沒安裝 Node.js 是無法執行這個指令的，我過去有把 Python、Node.js、Git 這些工具的安裝與使用，拍成教學影片: https://youtu.be/5DEV_K0JauQ

接下來我們把畫面切回 Antigravity，開啟下方的終端機把指令貼上去後，這邊你就會看到 Claude 有提供的 Skills，你可以用鍵盤的「上下」滾動畫面，透過「空白鍵」來選擇。

這邊我就以「frontend-design」來做示範，安裝完成後，我們可以打開右側與 AI 的對話視窗。

使用 Skills

然後輸入一樣的提示詞

參考來源履歷後，新增資料夾「personal-website-skill」，設計一個有專業質感的中文個人品牌網頁

此時你會發現他有先找到對應的 SKILL.md，然後再去做執行：

稍等一段時間後，他就幫我們把網頁生成出來了。第一眼看上去，網頁整體的質感有稍微上升：

但稍微往下瀏覽後你會發現，其實跟上一個沒使用 Skill 的相比，也許結構上有些微提升，但老實講差異沒有差太大。

透過這個範例，是想讓大家了解：

並不是有 Skill 就能得到好作品，他只是讓你有更好的起點

整個看下來，這個網頁存在幾個問題：「首先是設計上沒有特色，再來是資訊只是平鋪直述，所以整體看下來並沒有什麼吸引力。」

使用 Skills + 完整提示詞

但如何讓網頁更有吸引力呢？接下來我就要跟大家分享，如何優化提示詞放大 Skill 能力。

請參考我的履歷後，新增一個資料夾「personal-website-skill-enhance」並依照以下步驟執行：
## STEP 1: 內容彙整
完整閱讀我的履歷後，整理成「個人品牌網站可用的內容模組」，**不可自行刪減重要資訊**。
請至少包含（若履歷中有）：
- 核心定位（一句話我在幫誰解決什麼問題）
- 專業角色與背景
- 授課 / 演講 / 企業內訓經歷（請完整保留）
- 專案或代表案例
- 媒體、著作、出版或公開曝光
- 可合作項目與服務形式
- 聯絡方式與行動引導（CTA）
## STEP 2: 敘事優化
請你將上述內容改寫為「適合放在個人品牌網站的版本」：
- 用專業但有人味的中文
- 避免履歷條列感
- 讓「企業、學校、合作夥伴」一看就懂我能帶來什麼價值
- 授課經歷請以「信任背書」角度呈現，而不是流水帳
此階段請只產出文字，不要有 HTML / CSS。
## STEP 3: 元件與版型決策
扮演「個人品牌網站 UX 設計師」的角色，判斷：
對每一段內容，請標示：
- 適合的呈現元件（例如：Hero 區塊、Timeline、Card Grid、Logo Wall、CTA Section、Sticky Contact）
- 為什麼用這個元件（目的與心理預期）
- 建議放在頁面的位置（上 / 中 / 下）
- 是否適合做成「強調區塊」
請用表格呈現。
## STEP 4: 網站生成
最後根據以下要點生成網頁（參考 SKILL 裡面的 frontend-design）：
- 單頁個人品牌網站
- 中文為主
- 強調專業、可信任、可合作
- 聯絡方式要「非常清楚、好行動」
- 請參考文字引用圖片（複製一份過去）

看完上面的提示詞後，可能有人會舉手發問：「老師！你這個提示詞也太複雜了吧！」

是的，我的提示詞真的挺複雜，但如果你希望 AI 辦好事，你提出的需求就要足夠具體。

假如你認為這些提示詞使用的頻率很高，你也可以把他們設計為 Skill。

但以剛剛的範例來說，因為有根據履歷這個情境特別設計，所以設計成 Workflow 這類需要主動觸發的工作流會更為合適。

等 AI 完成後，我們打開網頁瀏覽一下，此時你會發現不只設計感提升了，連裡面的描述都變得更加有吸引力：

而且前兩個生成的網頁都沒有圖片，而這個全部都有：

我想大家一看就知道，有 Skill 再加上精準的提示詞能得到更好的結果。

哪些地方有 Skill

了解如何安裝與應用 Skill 後，我再跟大家介紹幾個分享 Skill 的網站

比如 awesome-claude-skills 這個 GitHub Repository 裡面就有許多的 Skills 讓大家參考

GitHub - ComposioHQ/awesome-claude-skills: A curated list of awesome Claude Skills, resources, and… A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows … github.com

除了撰寫程式的 Skills 外，內容也涵蓋了像是「文件處理、圖片優化、研究助理」這類型的技能。

這邊再介紹一個優化前端視覺的 Skill

跟前面分享的 frontend-design 相比，他有根據不同網頁主題做優化；像這邊就有區分成教育類型的網頁、寵物服務的網頁、電子商務的網頁：

如果你想使用這個 Skill，在終端機的地方輸入 npm install -g uipro-cli ，然後輸入 uipro init — ai antigravity，你就會看到它安裝完畢了。

因為剛剛指定安裝到 antigravity，所以技能會被存在「.agents/skills」底下。

我們把資料夾展開看看，你會發現有一個「scripts」的資料夾，裡面有一些 Python 的程式，這些程式會在 SKILL 載入後，於不同的時機點被執行。

Skill 安全問題

雖然前面已經說過了，但我還是要再次提醒大家，如果打算使用別人的 Skill，建議確認以下 3 點：

1. 從信任的來源去安裝 Skills，如果是從 GitHub 上下載，可以透過他的 Star 數量來初步判斷。
2. 建議看一下 scripts 目錄下的程式有沒有危險的操作，像呼叫外部 URL、修改檔案、存取敏感資料這類的，如果看不懂程式，可以請 AI 幫你做初步的檢查。
3. 確認「SKILL.md」是否有敏感指令，比如把儲存隱私資訊的「.env」傳送到特定網址。

希望大家在享受 AI 帶來便利的同時，也能對資安有更高的敏銳度。

Skill 使用經驗

最後提醒一下大家，Skill 並不是裝越多，AI 就越強；像這邊能處理前端的 Skill 我裝了兩個，因此請 AI 生成網頁時兩個都會觸發。

而這所造成的問題除了 Token 的浪費外，還很容易讓 AI 執行到一半卡住。

因此同類型的技能，建議擇優安裝一個，或是合併成一個；在提示詞的世界，1+1 有可能會小於 1。

另外網路上的 Skill 雖然很多，但並不是每個都能讓 AI 變強，有些描述的很猛，但實際體驗很差。

建議大家可以先用 Project 的方式，獨立測試 Skill 運作是否符合預期。真的有用，並且通用的再把他放到 Global Skill 裏面。

這個表格是常見工具的 Global Skill 路徑：

如果你希望安裝一次，就能在所有工具中生效，Mac 可以使用 ln -s，Windows 可以使用 mklink 的指令，將資料夾建立為 symlink 連結。

希望我的經驗，可以讓大家更高效地享受 Skill 帶來的好處。

③ 建立自己的 Skill，搞定繁瑣工作

儘管網路上有很多 Skill，但未必能符合自己實際的工作流，如果找不到合適的，那我們就自己建立！

安裝 Skill Development

不知道怎麼下手也別擔心，我們可以請 AI 幫忙生成初版，這邊我在終端機輸入剛剛用來安裝 frontend-design 的指令，npx skills add anthropics/claude-code ，不過這次我要安裝的是 Skill Development。

建立自己的 Skill

安裝完畢後，開一個新的對話窗，描述自己想建立的 Skill，這邊我是請 AI 建立一個用 Python 將音訊檔轉成 srt 字幕檔的 Skill。

我想要建立一個透過 Python 將音訊檔轉成 srt 逐字稿的 Skill
使用 openai-whisper 套件
我可以設定每行最多幾個字，若沒填寫預設最多 22 字，最少 4 個字
時間軸若不連續，當間隔小於 0.3s 時，後面需要往前補
執行時會先檢查環境與套件是否安裝，並確認有提供音訊檔
將最後輸出的 srt 檔命名為「origin.srt」

你這邊在 AI 執行的過程中看到，他是有參考剛剛安裝的 Skill Development：

稍等一段時間後，AI Agent 就用這個 Skill 幫我們建立了一個新的 Skill。

我們打開建立好的 SKILL.md，跟大家說明內容結構，上面這塊是 Meta Data，也就是 AI Agent 一開始會閱讀的資訊，其中最重要的是 description 的描寫，寫得越具體，AI 執行時會更容易找到。

下面則是這個 Skill 的描述與執行步驟，像一開始會先確認環境，是否有安裝 Python 與對應的套件，沒問題後才會去執行 Python 腳本；這邊你會看到有一個 scripts 的資料夾，這就是 AI 幫我們寫好的 Python 腳本。

測試 Skill

得到 Skill 初版後，接下來最重要的是去驗證他的運作是否符合預期，這邊先開一個新的對話窗，提供一個音訊檔，然後輸入指令：

轉成字幕檔

稍等一段時間後，srt 字幕檔就產生了，我們來驗證一下他是否有根據規則設計：

1. 首先檔名是「origin.srt」符合預期
2. 有遵守每行最長 22 字，最少 4 個字的規則
3. 前後段時間軸會黏在一起

如果你跟著教學做到這一步，恭喜你完成了第一個 Skill。

這邊我再建立一個有關聯性的 Skill 示範給大家看，這個 Skill 的目標是請 AI 在 srt 字幕檔內，判斷適合增加字卡的位置，加快我後期剪輯的效率。

我想要建立一個在 srt 逐字稿文字下方補上「參考字卡」的 Skill
只能在每段字幕的「文字區塊」下方新增字卡行，不可更改原本的時間碼與原字幕文字。
我希望的結構是 `[字卡](word:xxx / type:yyy)`
- word：必須是從該段內容萃取出的「重點詞/短句」（10~16 字內，避免太長）
- type：必須從 references/*.yaml 定義的 type 之一選擇(金色重點、白色提醒、紅色警告、藍色列點)
每 10 段字幕內，至少要新增 2 個字卡，字卡必須「貼合情境」選型：
- 有風險、錯誤、踩雷 → 紅色警告
- 建議、提醒、注意事項 → 白色提醒
- 條列、步驟、清單感 → 藍色列點
- 核心結論、最關鍵一句 → 金色重點
將最後輸出的 srt 檔命名為「reference-cards.srt」
請勿使用 Python 之類的腳本，必須要用 AI 來判斷

在 Skill 完成後，我們開一個新的視窗，把上一步生成的「origin.srt」放進去，然後在提示窗輸入：

給我字卡重點

稍等一段時間後，可以看到「reference-cards.srt」的字幕檔出現了，點進去後，你會發現 AI 有在裡面設計一些參考插入字卡的位置。

觸發多個 Skill

確認 Skill 運作符合預期後，你也可以一個指令中觸發多個 Skill：

幫我將音檔轉成逐字稿後，再生成字卡

這邊你會看到他閱讀了兩個 Skill 的檔案，並且在最後成功生成「origin.srt、reference-cards.srt」的檔案。

優化 Skill

但我們發現這兩個檔案被放在「.agent/skills」的目錄底下，他應該要跟音訊檔在同個階層才對。

發現結果不如預期，請 AI 幫我們調整就好，這邊我就跟他說：

「origin.srt、reference-cards.srt」應該與音訊檔在同個階層，幫我優化 Skill，並移動檔案

設計 Workflow 觸發

確認 Skill 可以組合應用後，再介紹一個更偷懶的方式，我們可以設計 Worflow 讓他穩定觸發，名稱我打 audio-to-srt-cards ，描述這邊我寫「將音檔轉成逐字稿後，再生成字卡的工作流」，而內容清楚描述每一步要參考的 Skill 就可以了：

按造下面步驟執行
STEP 1: 使用「mp3-to-srt」的 Skill 將音檔轉成逐字稿
STEP 2: 使用「reference-cards」的 Skill 用逐字稿生成參考字卡

設定完成後，開一個新的對話窗，輸入「/」後，選擇剛剛建立的 Workflow，接著我們把先前產生的 srt 移除後，將音訊檔放進去。

稍等一段時間，就可以看到工作流有根據我們的指引，參考對應的 Skill 完成任務了！而且生成的字幕檔有跟音訊檔在同個階層：

相信大家掌握 Skill 與 Workflow 搭配的技巧後，做任何事都會更加省力！

結語：把解決問題的經驗，變成可重複使用的資產

使用生成式 AI 一段時間後，你會發現 AI 並沒有你想的那麼聰明。交給他的任務，往往要透過幾次來回對話，才能得到期待的結果。

但得到答案後，大部分人會習慣直接把對話視窗關閉；然後下次遇到類似的問題時，又要重頭開始與 AI 對話。

我覺得這件事非常可惜！

建議大家下次與 AI 協作解決問題後，不要急著關閉對話框，嘗試用這個指令來彙整你們之間的對話：

請將上方對話整理成以下內容，並在最後設計一個可以重現結果的提示詞：
1. 起初怎麼提問
2. 中間如何引導與調整
3. 最終是如何得出這個成果的

得到提示詞後，你就可以用前面分享的方法，把它變成一個 Skill；之後遇到類似的問題時，AI 就知道要使用這個 Skill 來解決。

我認為過去解決過的問題，不應該再花時間解決第二次。

當然一開始建立的 Skill 可能考量的不夠完善；但遇到結果不如預期的狀況時，不就是打磨 Skill，讓他更強大的時機嗎？

這個技巧用得越久，你的 AI Agent 會越來越強大，成為別人難以跨越的護城河。

Agent Skills 的出現，讓 AI 的價值可以持續累積；只要教會一次，他就永遠記得怎麼做！

如果這篇文章對你有幫助，可以順手按個讚，並把文章分享給對 AI 主題感興趣的朋友們。

如果你已經開始嘗試用 Vibe Coding 開發專案，一定會遇到以下問題：

穩定性

你一定遇過請 AI 解決目前遇到的問題，結果改完後發現過去正常的功能被改壞了。

複雜度

隨著專案不斷完善，功能肯定會持續增加；如果還是依靠人工去確認流程的正確性，是非常浪費時間、沒有效率的。

擴充性

Vibe Coding 在初期可以加速開發，但隨著專案架構逐漸複雜，功能之間開始有相依性時，任何修改都可能引發連鎖影響；最怕的就是程式看起來可以跑，但背後的商業邏輯一團糟，出狀況時，你連問題都不知道如何定位。

如果這幾個問題能引起你的共鳴，先給自己比個讚，因為這代表你已經進入了下個階段。

而今天這篇文章，就是要跟大家分享如何導入「自動化測試」，讓 Vibe Coding 的成果更加可靠。

並一口氣解決前面提到「穩定性、複雜度、擴充性」的問題。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【Antigravity Workflow 實戰】市場不會為爛產品買單！建立自動化測試，解決 Vibe Coding 痛點

假使你有把 Vibe Coding 成果產品化的打算，我強烈建議大家把這篇文章儲存下來，這樣之後才能得到喔！

我會透過實際專案，帶你掌握以下知識：

① 哪些地方需要寫測試

② 怎麼設計工作流，讓 AI 幫你寫測試

③ 如何設計 GitHub Action 建立自動化測試

④ 建立 Rule 保護主分支的技巧

記住，市場不會為爛產品買單；而加入自動化測試，是讓 Vibe Coding 的成果，從玩具走向產品的過程！

一、不寫測試，才會沒有時間

這邊我用 Vibe Coding 寫了一個有「登入頁、儀表板、管理後台、Mock API」的前端專案。

https://github.com/deancourse/vibe-coding-testing-practice

如果你有興趣從頭開始，我有把專案初始化的提示詞放在 GitHub 的專案上，可以直接複製貼上體驗。

不過今天文章的主軸是「自動化測試」，所以我建議你可以直接下載我放在 GitHub 的專案，然後跟著練習。

如果你是第一次接觸 Git 與 Node.js 的朋友，可以參考我過去拍的影片，裡面有詳細的操作教學。

這邊我建議大家點擊 fork，將專案複製到自己的帳號下。

然後點擊 Code，從裡面複製專案網址。

接著打開你熟悉的程式碼編輯器，這邊我以 Google 最近推出的 Antigravity 來示範。

第一次接觸程式碼編輯器的朋友也不用擔心，可以參考我過去分享的影片，不管 Cursor 還是 Antigravity 都有對應的教學。

好的，我們再把注意力轉回 Antigravity，點擊 Clone Repository，貼上剛剛複製的網址。

選擇下載的路徑後就會開始下載，把專案下載好後，把視角切換到 package.json，其中 dependencies 與 devDependencies 是專案用到的套件。

我們打開終端機，輸入 npm install 就能夠安裝這些套件，安裝好的套件會存放到 node_modules 的資料夾中。

另外上面 scripts 的部分，則是專案能使用的指令，輸入 npm run dev 就可以啟動專案了。

當然你也可以直接打開與 AI 的對話視窗，跟他說 幫我安裝套件並啟動專案 就能搞定一切；但多了解專案的架構，Vibe Coding 可以走得更遠。

登入頁面

這邊先從登入頁開始，跟大家說明系統功能，以及要測試的情境：

可以看到要輸入「電子郵件」與「密碼」才能登入系統，看起來很簡單，但其實這裡是第一道防線。

以網頁系統來說，會分成「前端」跟「後端」，我們看到的視覺頁面是前端。

假使使用者輸入的「電子郵件格式錯誤」，或者「密碼沒有英數字混合並大於 8 碼」，因為格式錯誤，所以根本不需要呼叫後端 API，來增加伺服器的負擔。

至於有沒有傳送到後端，我們可以打開 F12，或是點擊滑鼠右鍵，選擇檢查，來開啟「開發人員工具」，點擊「網路」的分頁。

在基礎格式錯誤的狀態下，可以用前端驗證擋住；所以你會發現，即使按下登入也不會呼叫後端 API。

將兩者格式改為正確之後，才會呼叫 API：

以剛才的操作來說，就至少涵蓋了 3 種測試情境：

• 使用者格式輸入錯誤的時候，前端會擋住
• 不同的格式錯誤，會有對應錯誤訊息
• 只有格式正確時，才會呼叫 API

在程式加入這些測試情境後，未來請 AI 修改程式時，你才知道是否會影響到既有功能。

使用 Mock API 模擬情境

另外在真實的世界中，呼叫後端 API 並不會永遠成功，以登入來說，可能會有密碼錯誤、帳號不存在、系統出問題等狀況。

所以我這邊用 Mock Service Worker 來模擬後端，讓我們可以測試不同的情境，比如：

• 密碼錯誤時，有錯誤提示
• 帳號不存在時，有錯誤提示
• 並確認成功後，有沒有拿到 Token

Mock API 給我們帶來的幫助，就是除了測試成功情境外，還能模擬錯誤情境。

而且實際與後端串接時，如果 API 回傳有問題，也可以即時釐清問題。

角色權限與憑證

登入後，我們把分頁切換到「應用程式 → 本機儲存空間 → localhost 的網址」

這邊可以看到有一個「msw_user_role」的金鑰，系統的前端就是用它來判斷使用者的權限，決定前端頁面要如何渲染。

像我們身份為 admin 的狀態下，頁面才會「管理後台」，至於「auth_token 」這個欄位，則是你取得的登入憑證，以測試來說，可以有一個基礎的判斷：

• 有 Token，才會用它來呼叫後續的 API
• 沒有 Token，直接導向到登入頁

Token 是決定呼叫後端 API 時，能取得哪些資源的憑證，比如這邊我使用「清除 Token」後，可以看到除了 auth_token 移除外，頁面也重新導向到登入頁。

因為對系統來說，你已經沒有憑證了。

接著我把權限切換到一般使用者，登入後你會發現「msw_user_role」的角色切換成了 user，上方的「管理後台」也不見了：

這邊示範的就是權限測試的重要性：

• 要確保一般用戶不會看到管理者功能
• 並且不能讓一般用戶誤闖管理者後台

權限的設計如果不完善，那對系統來說就是重大事故！

在這總結一下，我剛剛跟大家示範的流程涵蓋： 「登入功能、API 回傳、角色權限、Token 驗證、介面差異」 這些情境都應該設計對應的測試案例。

因為在 Vibe Coding 的世界， 我們很常改流程、改權限、改 API，如果少了測試案例，那你根本無法判斷這次修改 會不會動到其他系統功能。

千萬不要嫌寫測試很浪費時間，別忘記現在已經有 AI 可以幫忙了。

根據我過去十幾年的開發經驗，其實寫測試是在幫助你加速開發；因為他讓你可以更放心新增與修改功能，在遇到問題時也可以快速定位。

另外測試案例不太可能一次到位，他會隨著規格變更、實際操作而有所調整；但有了它，需求規格的內容才能真正被驗證。

同時提醒一下大家，我們在前端做的格式驗證（ex:帳號格式、密碼格式），後端也不能少。

因為知道 API 路徑的人，也能直接繞過前端打 API，這些都是設計上要注意的細節。

二、用 AI 撰寫測試程式

這篇文章我使用 Google 最新推出的 Antigravity 來給大家做示範。

目前登入 Google 帳號就可以使用，但如果付費升級到 Pro 會有更高的使用額度。

但如果你熟悉的是 Cursor 或者是其他 AI 編輯器，也可以跟著操作。

這邊我們點擊右上角的「…」，選擇「Customizations」來做客製化。

Rules 的部分，我是參考 Cursor 內部員工的 Rules 範例，其實提示詞都是通用的：

DO NOT GIVE ME HIGH LEVEL SHIT, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON'T WANT "Here's how you can blablabla"

- Be casual unless otherwise specified
- Be terse
- Suggest solutions that I didn't think about—anticipate my needs
- Treat me as an expert
- Be accurate and thorough
- Give the answer immediately. Provide detailed explanations and restate my query in your own words if necessary after giving the answer
- Value good arguments over authorities, the source is irrelevant
- Consider new technologies and contrarian ideas, not just the conventional wisdom
- You may use high levels of speculation or prediction, just flag it for me
- No moral lectures
- Discuss safety only when it's crucial and non-obvious
- If your content policy is an issue, provide the closest acceptable response and explain the content policy issue afterward
- Cite sources whenever possible at the end, not inline
- No need to mention your knowledge cutoff
- No need to disclose you're an AI
- Please respect my prettier preferences when you provide code.
- Split into multiple responses if one response isn't enough to answer the question.

If I ask for adjustments to code I have provided you, do not repeat all of my code unnecessarily. Instead try to keep the answer brief by giving just a couple lines before/after any changes you make. Multiple code blocks are ok.

而這次撰寫測試的部分，我們要使用 Workflow，讓 AI 根據我們的流程來執行。

如果你是下載我提供的練習專案，你會看到兩個在 Workspace 底下的 Workflow，這代表 Workflow 只會在這個專案中執行：

這邊我點進去跟大家說明，主要的 Workflow 是 gen-test-cases，Description 是這個工作流的描述，我就寫 生成測試案例工作流 ，而 Content 則是說明這個工作流要做的事。

角色扮演

扮演一位經驗豐富的軟體測試專家，根據以下步驟進行協作

首先我讓他扮演一位經驗豐富的軟體測試專家。

STEP 1: 建立存放文件的資料夾

STEP 1: 檢查專案底下是否建立 `doc/test` 資料夾，若無則建立

一開始先請他檢查專案底下是否有建立 test 資料夾，我們會在這裡面保存 Markdown 格式的測試清單，方便日後閱讀檢視。

STEP 2: 撰寫測試案例清單

STEP 2: 根據選擇範圍撰寫測試案例清單，撰寫格式請參考 `.agent/workflows/test/template.md`，並將發想的結果用 Markdown 格式寫入 `doc/test` 底下，完成後進行 Reivew 不要直接生成測試程式，確認符合預期後再下一步

然後請他撰寫測試案例清單，這邊用了一個技巧叫做 reference，直接給他一個參考模板，避免 AI 每次生成的格式都不一樣。

我們開一下這個模板，這就是寫給 AI 參考的撰寫範例，要有測試的類型、說明、範例輸入、期待輸出等資訊。

同時用了一個小技巧，就是以「狀態」的概念來管理，有測試通過才會標記；並給他幾個測試類型的範例參考。

接著我們再回到一開始的工作流，這邊我有要求他要把這些發想的測試清單，寫到 test 資料夾下， 然後再完成這個任務後，我要求他將這個 Markdown 文件存到專案資料夾中，並讓我們 Review，這樣我們才能確認 AI 給的測試情境是否有遺漏的狀況。

STEP 3: AI 撰寫測試程式

STEP 3: 參考上一步完成的 `doc/test` 撰寫測試程式，不同頁面需建立獨立檔案

**重要規則：**
- 第二層 `describe()` 必須為「測試類型」，下面每一個 `it()` 描述必須為對應的測試案例的「測試說明」
- `it()` 內的文字描述請「直接使用 Markdown 的原文，不需翻譯、不需重新命名」

在我們確認要測試的範圍符合需求後，就可以讓 AI 開始撰寫測試程式了。

這邊有一個特別的「重要規則」，就是要求他程式內的描述，要跟剛剛文件撰寫的測試說明一致，這樣才方便我們比對。

STEP 4: 驗證測試程式

STEP 4: 驗證測試程式，若結果符合預期，請去 doc/test 底下，將 Markdown 打勾

在 AI 生成測試程式完成後，我們要求他自主驗證程式正確性，若通過要去文件內打勾。

STEP 5: 限制測試次數

STEP 5: 若測試不符預期，重複 STEP 3–4，最多 5 次，仍失敗就討論原因

因為撰寫的程式可能會有問題，所以我讓他可以重複 STEP 3 跟 4 的動作，但最多嘗試 5 次；這個限制是為了避免 AI 在錯誤的方向狂奔，我們適時地介入，去確認問題發生的原因。

這套工作流主要是用來撰寫前端專案的單元測試為主，你可以根據自己的需求自行調整。

再設計好 Workflow 並儲存後，點擊「Back to Agent」回到對話窗，此時我們按下「/」就會看到剛剛設計好的 Workflow。

這邊我用 gen-test-cases 示範給大家看，我們把視角移到左側的專案，我們專案的三個頁面，都被放到 pages 的資料夾底下。

我建議大家請 AI 撰寫測試程式時，不要讓他一口氣生成，而是先放一個檔案。

確認他執行的結果與我們的期待相符，否則一口氣生成，如果結果不是你要的，那不但浪費時間還浪費 Token。

這邊把檔案拖曳進去後，只要按下 Enter，AI 就會開始閱讀程式碼根據工作流開始運作了。

首先我們會看到，他有要求我們建立對應的「 doc/test」資料夾來存放文件，點擊 Accept 接受就好。

接著稍等一段時間，他就參考我們提供的 Markdown 文件來撰寫測試案例文件，可以看到初始的狀態都是空的。

並且有根據測試類型進行分類，這可以幫我們快速理解測試的意圖，然後可以從輸入輸出的描述，判斷他想測試的情境跟你的期待是否相符。

如果覺得有缺少，就可以直接跟他討論；覺得沒問題，就請他繼續 。

但我也在這邊跟大家說，AI 給予的測試案例，可能會有錯誤或者多餘的狀況，建議大家看一下。

並提醒一下大家，如果你看不懂 AI 執行的指令，建議把指令複製起來詢問一下比較保險。全部無腦點擊 Accept，有可能會出大事。

因為有時 AI 會執行一些危險的操作，之前就曾經有網友遇過 AI 直接把整個 D 槽硬碟刪除的悲劇：

稍等一段時間後，AI 就幫我們把測試程式完成了，點擊 Accept 讓他執行測試前，我們先看一下他有沒有按照工作流的指示撰寫。

在「describe」這邊有幫我們做基礎的分組，另外「it」的描述也與文件吻合；這次的話很幸運，一次就成功了；如果有問題他就會多嘗試幾次。

這邊也提醒一下大家，儘管我們的 Workflow 說最多嘗試 5 次，但隨著執行次數增加；AI 可能會忽略這個規則，這是需要注意的。

AI 完成一個頁面的測試案例，並驗證通過後，就會回頭更新測試清單，這邊我們可以看到上面都標注通過了。

如果你做到了這一步，請給自己一點掌聲，恭喜你用 AI 撰寫了測試程式，並跑完了一個頁面的功能驗證！

一般來說，我會建議每個頁面都有獨立的測試程式，這樣日後修改遇到問題時，可以快速定位。

在第一個頁面的測試程式撰寫並測試完成後，其實這個工作流你要放兩個檔案進去也是可以的。

稍等一段時間後，對應的測試程式就完成了，並且對應的驗證邏輯也通過了；你可以看到光是 3 個功能不多的頁面，就能涵蓋這麼多的測試情境。

如果用人工測試，即便是小專案；你都要花個好幾分鐘才能手動把流程跑過一遍，甚至可能還會有遺漏的項目。

但加入自動化測試後，你放給他跑就好了；隨著專案擴增，你更會體會到他給你帶來的幫助。

因為以市面上的大型專案來說，功能動輒成千上萬，彼此間又有各種複雜的關聯性。

沒有自動化測試，專案就像是個危樓，任何不起眼的改動，都可能導致問題在你想不到的地方炸裂。

今天分享的這個工作流只是一個雛形，如果大家有更好的方案，也歡迎交流分享。

三、用 GitHub Action 執行自動化測試

完成專案的測試案例後，下一步就要把測試的步驟加入 GitHub Action。

這樣我們每次更新程式時，都會自動執行測試，確保基礎功能的基礎流程都是正常的。

不過在這之前，我先跟大家簡介一下 Git Flow，Git 是用來版本控制的工具，Git Flow 則是分支合作的策略。

目前我們還在 main 的這個主分支上：

你可以想一下，如果把邏輯錯誤，或功能不完善的版本更新上去，那產品不就壞掉了嗎？

所以在開發上，我會建議至少要有一個 develop 的開發分支，日常更新推送到上面就好，等功能完善後再合併到 main 這個主分支。

雖然 Git Flow 還有新增功能用的 feature 分支、發佈上線版本的 release 分支、以及處理緊急問題的 hotfix 分支。

但如果你是第一次接觸，可以先從 main 分支出 develop，來了解為什麼需要用不同分支開發。

這邊先打開終端機，在下面輸入 git checkout -b develop ，就可以從 main 切出一個 develop 的分支。

然後到與 AI 的對話窗中輸入以下內容：

我希望在 GitHub Action 加入自動化測試的流程
每一個分支將更新推送到 GitHub 都會觸發一次自動化測試
測試完畢後，要生成覆蓋率報告讓我下載

等 AI 將 GitHub Action 內容更新完畢後，我們就可以將變更推送到 GitHub 上面

Commit 的部分可以由 AI 自動生成，或是自己手動輸入，這邊我選擇貼上準備好的訊息：

1. 撰寫 pages 頁面下的測試案例
2. 在 GitHub Action 增加自動測試的流程

送出去後，我們把視角切換到 GitHub，點擊 Action 的分頁，這邊你可以看到 GitHub Action 執行的狀況，成功成的話會是綠色勾勾，失敗則是紅色叉叉。

這邊我們很幸運的看到是綠色勾勾，點進去後，你可以看到測試的細節：

回到 Summary，在「Artifacts」的部分會有測試報告可以下載：

這樣每次有新功能完成後，如果主管想要看測試報告，就有東西可以給他們參考嚕。

下載後會得到一個 zip 檔案，解壓縮後點擊「index.html」檔案就可以看到專案的測試覆蓋率了：

透過這份報告，你就可以了解專案中哪些功能測試比較多，比如像是剛剛撰寫測試程式的 pages 就接近覆蓋率 100%。

而其他沒有被測試到的頁面，我們就可以再去補一些測試情境。

但提醒一下大家，在測試覆蓋率這塊，我們沒必要追求 100%；而是重要的邏輯都要測試到，這才是最重要的。

四、設計 Rules 保護專案，測試通過才能合併

我們剛剛更新的分支是 develop，要透過 pull request 這個操作，才能將更新合併到 main 這個主分支。

但如果你希望只有「通過測試」的分支才能合併到主分支，你需要多做一設定。

我們回到 GitHub 頁面，選擇 Settings，然後選擇 Rules 下面的「Ruleset」，這邊我們要根據分支來做設計，所以選擇「New branch ruleset」。

name 的部分你可以輸入「Protect main branch」，然後「Enforcement status」這個記得要切換到 Active 才會生效。

Target branch 選擇「Include default branch」

然後把「Require a pull request before merging」這個必須「用 PR 才能合併的選項」打勾。

並將「Require status checks to pass」打勾，以及下面的「Require branches to be up to date before merging」也打勾，這是在設定「測試必須通過才能合併」。

接著點擊「Add Checks」，搜尋 test，然後把他打勾，這就是要檢查的項目。

如果「test」搜尋不到結果，可以到 Github 這個 Repository 的 Actions 下，確認命名。

完成以上設定後，我們滑到最下面，點擊「Create」保存設定。

接著回到 Antigravity，故意做一個測試失敗的，看看「pull request」是否會無法合併。

我們到專案挑一個測試案例，故意把裡面的結果弄壞；此時如果在終端機執行 npm run test，就會看到有一個錯誤。

然後我們將這個錯誤更新上去，commit 就填寫 test PR failure condition ，推上去後回到 GitHub，此時點擊「pull request」。

如果你是 fork 我的專案，這邊要特別注意，base 你要改成自己的帳號：

然後 compare 要選擇 develop，因為我們的目標是把 develop 的內容更新到 main。

在建立 pull request 的時候，建議填寫裡面的 description，這是為了幫助其他人，以及未來的自己了解我們做了什麼更新。

你會發現因為測試有錯誤，所以合併的按鈕是灰色，符合我們的預期。

接著回到專案，把這個問題修正回來，commit 就填寫 test PR success condition 。

更新後再回到 GitHub，稍等一段時間，你會發現合併的按鈕變成綠色，可以順利合併了！

有了 Rule 保護專案的主分支後，我們至少能保證合併進來的功能都是經過基礎驗證的。

結語：用自動化測試，守住系統的底線

測試的領域博大精深，今天的分享只是帶大家入門而已。

同時提醒大家，加入測試，不代表專案無懈可擊，但至少能守住專案的底線；也相信把影片看到這裡的你，充分了解到 Vibe Coding 是需要學習的。

也許用一行指令就能生成系統，但能穩定運行、並且有擴充性的系統才是有價值的。

突然想到前陣子跟一些老闆聊天時，有聊到目前企業導入 AI 遇到的瓶頸。

其中一個是邀請講師來企業內訓的時候，同仁都用得很開心；但隔天上班，想實際應用到工作時卻感覺非常卡。

當時我就跟他說：「因為講師在設計教材時，給予的是最佳體驗路徑；但換個情境，一定會遇到許多問題。」

就像今天這支影片，如果你直接使用我提供的專案操作，通常可以順利完成每個步驟。

但這只代表你對測試有了初步的概念，並不代表你已經掌握了自動化測試。

把我的指令搬到其他專案執行時，可能會遇到不一樣的問題；這個時候不要氣餒，因為你遇到的問題才是屬於自己的護城河。

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

讓 AI 成為你的助手，而不是取代自己的思考與判斷。

最後總結一下，為什麼測試對專案來說如此重要：

• 因為有測試，你才有辦法驗證規格書上的功能你都有做到。
• 因為有測試，當需求變更時你才敢大膽修改程式，不怕改壞原有功能。
• 因為有測試，當遇到錯誤時，你可以快速定位問題，而不是一個個慢慢嘗試。

再了解測試的好處後，跟大家介紹一種開發模式，叫做 TDD(Test-Driven Development)，也就是測試驅動開發。

相比於大家熟悉的先完成功能再寫測試，他則是先撰寫測試再去開發，之後有機會再跟大家深入分享。

如果過去沒有寫過測試程式，我認為先養成撰寫測試的習慣才是最重要的。

建立自動化測試，你才知道 AI 是否改動到邏輯；掌握關鍵知識，你才能走得更遠。

另外今天這支影片，我都是用 Mock API 來代替後端；所以在接下來的 Vibe Coding 系列影片中，我打算在這支影片的基礎上做延伸。

跟大家分享後端與資料庫的設計，帶大家把這些模擬的 API 都變成真實可用的。

如果這篇文章對你有幫助，可以順手按個讚，把文章分享給正在 Vibe Coding 的朋友們。

如果你剛開始接觸 Vibe Coding，可能會有一種感覺：

❝工具很多、教學很多，但不知道該怎麼開始，才不會走冤枉路。❞

因此這篇文章，我會用「實戰 Demo」的方式，帶你有系統的建立使用觀念。

讓你知道不同階段，該選擇什麼樣的 AI 工具比較合適。

我們會從入門的 Gemini，到進階的 Google AI Studio，再到偏專業應用的 Antigravity。

實際示範它們各自的特點。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【Vibe Coding 學習地圖】用實戰帶你搞懂 Gemini、Google AI Studio、Antigravity 的使用情境

一、Gemini：Vibe Coding 起手式

現在應該很多人使用 Gemini 處理自己的日常工作事宜。

不管是文書應用、圖片生成，還是簡報草稿，他都能給我們驚艷的表現。

同時，他也是最適合新手入門 Vibe Coding 的工具。

因為他只要打開瀏覽器就能操作，用簡單的對話就能生成漂亮的網頁，完成後還可以把成果分享給朋友。

下面我直接示範給大家看：

優化提示詞

像我本身是一個作家，如果想製作一個宣傳自己書籍的 Landing Page（著陸頁）。

就可以請 AI 來協助設計，但第一步，我會先提出自己的基礎需求，請他優化成更完善的提示詞：

我想要提供[書籍簡介]讓 AI 生成網頁

下面的 Prompt 如何優化才能得到更好的結果？

```
根據下方內容，判斷合適的風格後，設計出吸引人的互動網頁
```

• 需求：一開始我先說明自己的需求是提供書籍簡介，讓 AI 生成網頁
• 目標：然後請 AI 優化我提供的初始提示詞
• 初始 Prompt：最後提供初步的 Prompt 請 AI 延伸

相信有些人會覺得要學那麼多提示詞架構好累，到底 AI 是在幫我還是在搞我？

下次你有這樣的想法時，不妨學我先描述自己腦中的想法，然後請 AI 協助優化成更加完善的提示詞。

像這邊 AI 就幫我們撰寫了一個更完善的提示詞。

把它複製下來後，我建議大家開啟一個新的對話貼上去，這麼做是為了避免上下文的干擾。

用 Canvas 生成網頁

點開工具，選擇 Canvas，這樣才能生成網頁。

另外最下面要放上給 AI 參考的書籍資訊，這邊我就使用今年剛出版的工程師下班有約當作範例。

把書籍大綱貼上後，就可以點擊送出，稍等一段時間，網頁就生成完畢了！

但這邊要提醒一下大家，有結果不代表內容正確。

優化網頁細節

比如你點擊購買書籍，會發現這個按鈕根本是假的，按下去毫無回應，另外網站沒有作者頭像，也沒有書籍封面。

如果要增加這些資訊，你可以直接跟他說：

根據下面需求調整
1. 書籍的購買連結為: https://www.tenlong.com.tw/products/9786264142083
2. 作者頭像連結：https://duk.tw/DVw5tb.jpg
3. 書籍封面連結：https://duk.tw/0poc5o.jpg

特別提醒一下，在 Gemini 想加入圖片，需要把圖片上傳到圖床網站上，然後貼上圖片網址才會有效。

你直接複製圖片貼上是沒有用的喔！

調整完畢後，就可以看到作者頭像跟書籍封面了，購買連結也可以順利跳轉到我們指定的網頁了。

新增 Gemini 功能

這邊再介紹一個 Gemini 有趣的功能

如果你點擊右下角「新增 Gemini 功能」，AI 會根據網站主題來自動增加對應的功能

AI 新增了 Dean AI 職涯導航的功能：

分享網頁

確認網頁都調整的差不多後，你可以點擊分享向大家展示成果

但是上下面都有 Gemini 的浮水印標誌，我覺得有點礙眼

用 Google Site 建立網站

這邊要跟大家分享一個移除標誌的小技巧，那就是使用 Google Sites 來免費建立網站。

記得把剛剛建立的頁面拉到最上方，然後對原本的首頁點擊右鍵，選擇刪除，就可以發布網頁了！

用 Google Site 發布網頁後，原本在最上方跟最下方的 Gemini 標籤消失了。

但如果你去使用 AI 功能，就會發現無法順利使用，這是因為假如你要使用 AI 功能，會需要搭配 Gemini 的 API Key。

API Key 警告

把視角轉換到 Gemini，在程式碼的地方搜尋 apikey，如果沒有填寫的話，你是無法使用 Gemini AI 功能的。

至於這個 Key 如何取得，我會在下一節 Google AI Studio 的介紹中說明；但並不建議大家使用，因為免費的 API Key 額度很少。

如果想要正式使用，勢必要綁定帳單，但假使額度沒有設計好，你的信用卡可能會被刷爆。

另外使用 Gemini 建立的網頁是純前端網頁，如果你真的把 API Key 貼上去，別人按下 F12，搜尋 apikey 就能取得你的設定，然後刷爆你的卡。

希望大家不要跟自己的錢包過不去！

純 HTML 網站可以直接複製

這邊再給大家建立一個基礎觀念，Gemini 建立的 App 基本上都是純前端網頁（可搭配 Firebase 存取資料庫資源）。

所有的業務邏輯都是公開的，也就是說如果有人想要抄你的網站，只要檢查網頁元素，把 HTML 的部分複製起來，就可以整包帶走。

儘管 Gemini 可以用簡單的指令建立網站，但透過他建立的應用，別人可以毫無難度的直接抄襲。

但我依然建議大家先使用 Gemini 作為 Vibe Coding 入門的工具，因為成就感是一切的起點。

二、Google AI Studio：掌握進階技巧

用 Gemini Vibe Coding 會得到一個 HTML 檔案，結構相對簡單，而接下來分享的 Google AI Studio 則是以「前端專案」的角度呈現。

生成第一個 AI App

這邊我們先選擇 Vibe code GenAI Apps 來建立第一個 AI App。

在官網中，你可以看到他有許多可以選擇的 AI 應用，圖片生成、語音辨識、影片生成等應有盡有，這邊我先以最近爆火的 Nano banana 為範例，帶大家完成一個有 AI 功能的網頁。

這邊我跟他說：

使用者只要上傳照片，就可以轉換成自己想要的風格
介面先列出 5 個常見風格，也允許使用者自己輸入

接著點擊「Build」後就可以開始看 Gemini 表演了，稍等一段時間後，這個 AI APP 就完成惹。

這邊我先上傳自己的照片，選擇一個風格後，點擊開始轉換就能得到結果嚕～

分享 App

在確認結果符合需求後，我們就可以分享成果。

把 Publish your app 打開，這樣別人才能看到；而 Default to fullscreen 打開，才能預設顯示全螢幕，否則會是跟 Google AI Studio 對話的視窗。

用這種方式分享 App，一樣是要登入 Google 帳號後才可以使用。

但用這種方式分享，App 的上下都有預設的文字，我個人很不喜歡。

另外點擊右上角的 Leave fullscreen，你專案的程式碼都是直接公開給對方看的。

甚至可以根據這個 App 為基礎去做二次創作，所以大家分享前要先注意到這些細節。

Deploy app 注意事項

另外我並不建議大家使用 Deploy app on Google Cloud 這個功能。

因為他要綁定付費的專案才能使用，當別人使用這個 App 時，帳單是算在你頭上的。

除非你很清楚自己在做什麼，否則我不建議透過這個方式分享 App。

API Key

Google AI Studio 首頁，左下角有一個 Get API Key

點進去後，點擊右上角的「Create API Key」就可以取得自己 API Key 了。

但使用上，會分成免費版與付費版兩種：

• 以免費版來說，你只能使用一些比較舊款的模型，像最新推出的 gemini-3-pro 這類模型都是不可用的。
• 但如果你的專案有綁定信用卡，各種最新的模型都可以使用，但使用前你要搞清楚自己在做什麼，因為用多少算多少！

建立前端專案

其實 Google AI Studio 除了能建立有 AI 功能的 App 外，也可以建立一般的前端專案，這邊我就以「抽籤、分組」的 App 為例。

並在建立完成後，分享如何將成果保存到 GitHub 做版本控管，並透過 Antigravity 補齊專案細節，在 GitHub Pages 上免費部署。

剛好最近接近尾牙時間，許多公司都會有抽獎的需求，這時不妨自己 Vibe Coding 一個！

我的提示詞是這樣設計的：

我是一個 HR，想製作一個網站
可以上傳 CSV 或貼上姓名作為名單來源
有兩個功能，一個是獎品抽籤，會有動畫隨機抽取，這邊可以設定要重複抽取，或是不重複
另一個是自動分組，可以設定要幾人分組，分組後的結果會視覺化顯示

等 AI 完成後，我們來驗證一下功能是否符合需求，先貼上姓名，然後去抽籤，接著分組：

優化專案

儘管功能都符合需求，但操作過程中發現幾個可以改進的地方：

• 首先是名單，站在想快速理解與測試功能的角度上，如果有模擬名單的功能，那會更實用。
• 另外匯入名單時，目前沒有考慮到重複名單的問題，這塊也可以請 AI 在預覽名單處標記出來，並提供一個按鈕讓使用者一次性移除重複的姓名。
• 最後則是自動分組的地方，希望可以下載成 CSV 紀錄，畢竟這只是一個前端網頁，下次進來後紀錄就不在了。

我希望增加以下功能
1. 名單這塊，我覺得可以有模擬名單的選項，讓大家可以理解如何使用
2. 匯入 CSV 或貼上名單時，若發現有重複的學生姓名，則在預覽名單處標記出來，並提供一個按鈕讓使用者一次性移除重複的姓名
3. 自動分組後，希望可以下載成 CSV 紀錄

等 AI 調整完畢後，記得測試一下他增加的功能是否符合需求！

保存到 GitHub

在測試確認功能都符合需求後，我們可以將它保存到 GitHub 上面。

如果你是第一次接觸 GitHub，可以先到他們的官方網站，用 Gmail 就可以註冊了，他可以幫你的專案做版本控制。

這邊我們點擊「Save to GitHub」

首先你要輸入 App 的 name，建議使用英文，這邊我輸入 hr-helper。

至於 description 則可以中文白話描述，我就寫「上傳名單後可以抽籤、分組」。

因為後續我們想要用 GitHub Pages 發布，所以這邊選擇 Public。

然後點擊「Create Git repo」就建立這個儲存庫嚕！

接著 AI 會根據專案生成這次更新的 commit 訊息，你也可以自行編輯成自己看得懂的版本。

沒問題後點擊「Stage and commit all changes」就會上傳資料。

這邊我們把視角切換到 GitHub，看一下自己帳號的 GitHub Repository，就會發現剛剛我們透過 Google AI Studio 建立的 App 就出現了！

Gemini 與 Google AI Studio 差異

大家還記得一開始分享 Gemini 生成網頁時，是只有一個 html 檔案的嗎？

而現在我們使用 Google AI Studio 製作出來的網站，就不是一個單純的 HTML 檔案了。

他是用 React 這個框架設計的前端專案，你會發現他的結構複雜很多。

而且這些檔案是要經過編譯後才能使用的，所以無法透過先前 Google Site 的方式來分享網頁。

所以接下來，我要跟大家分享，如何使用 Google 推出的另一款產品 Antigravity 的補充專案細節，並部署到線上環境。

三、Antigravity：認識專業工具

Antigravity 是一款程式碼編輯器。

不管你電腦的作業系統是 Windows、Mac、Linux，都可以安裝體驗，目前 Antigravity 只要登入 Google 帳號就可以免費使用。

但如果付費升級到 Pro，你的使用體驗會好很多。

設定 Rules，讓 AI 更懂你

建議大家可以選擇「Customizations」來設定一下自己的使用偏好。

在 Rules 這個地方，我選擇 Global，這邊我複製貼上一個 Cursor 內部員工的 Rules 範例，其實提示詞都是通用的：

https://x.com/kayladotdev/status/1853272891023872450

DO NOT GIVE ME HIGH LEVEL SHIT, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON'T WANT "Here's how you can blablabla"

- Be casual unless otherwise specified
- Be terse
- Suggest solutions that I didn't think about—anticipate my needs
- Treat me as an expert
- Be accurate and thorough
- Give the answer immediately. Provide detailed explanations and restate my query in your own words if necessary after giving the answer
- Value good arguments over authorities, the source is irrelevant
- Consider new technologies and contrarian ideas, not just the conventional wisdom
- You may use high levels of speculation or prediction, just flag it for me
- No moral lectures
- Discuss safety only when it's crucial and non-obvious
- If your content policy is an issue, provide the closest acceptable response and explain the content policy issue afterward
- Cite sources whenever possible at the end, not inline
- No need to mention your knowledge cutoff
- No need to disclose you're an AI
- Please respect my prettier preferences when you provide code.
- Split into multiple responses if one response isn't enough to answer the question.

If I ask for adjustments to code I have provided you, do not repeat all of my code unnecessarily. Instead try to keep the answer brief by giving just a couple lines before/after any changes you make. Multiple code blocks are ok.

貼上後，這個規則就會在所有的專案中生效。

另外如果你想給目前的專案設定特定的 Rules，比如程式碼規則這類的，也可以點擊 Workspace 來設定喔。

而點擊上方的齒輪符號，你可以點擊「Open Antigravity User Settings」

在 Agent 的分頁中，如果把 Secure Mode 打開，那 AI 執行的過程會安全許多；但缺點就是大部分的任務執行都會詢問使用者。

下載 GitHub 專案

了解基礎設定後，接下來我們要透過 Clone Repository 來下載剛剛 Google AI Studio 完成的專案。

下載完成後，左側是專案資料夾區塊，裡面會有各種程式與設定檔；而右側則是 AI Agent 工作區，你可以直接輸入自己的需求。

在模型方面，Google 除了自家的 Gemini 外，還提供了 Claude 與 GPT 的模型讓大家使用。

在對話上，有分成 Planning 跟 Fast 兩種；如果要處理的是複雜任務，就建議選擇 Planning，而簡單的問答用 Fast 就足夠了。

完善專案

因為我們要請他補齊專案缺少的資訊，所以我這邊選擇的是 Planning。

然後輸入下面的 Prompt:

請擔任資深的 React 工程師，幫專案完成以下任務：
1. 設定 package.json，並安裝對應套件，完成後啟動確定是否可以運行
2. 設計 GitHub Action，讓我可以直接部署上線
3. 設計 .gitignore，避免上傳不必要的資料夾、暫存檔、隱私檔
4. 將相關操作記錄到 README.md

如果執行過程遇到不確定的指令，請務必確認

請問執行這個指令有危害嗎？
[貼上指令]

可以請 AI 執行專案，確認功能符合需求。

確認功能都符合需求後，就可以將變更部署到線上環境。

但在檔案上傳前，我建議大家先到 .gitignore 的這個檔案，確認一下設計是否完善。

部署專案

點擊左側的 Source Control，點擊 Generate，AI 就會辨識我們更新的內容，來產生 commit 訊息。

確認文字描述符合自己的預期後，點擊 commit，就會在自己的電腦記錄這個變更；但如果想更新到雲端，你需要點擊 Sync Changes才會正式上傳喔！

完成這些操作後，我們先來 README.md 看看專案的 GitHub Action 如何設計。

我們把視角切換到 GitHub 網頁，前往 Settings 的頁面，選擇左側的 Pages，然後將部署的來源選擇為「GitHub Actions」

完成這些操作後，我們回到 GitHub 點擊「Actions」的分頁，查看部署的狀況。

成功的話會有綠色勾勾，失敗則是紅色叉叉，會需要點進去釐清具體的錯誤原因。

這邊我們看到部署失敗，所以點進去把錯誤訊息複製起來，直接貼到與 AI 的對話視窗中，讓他幫忙解決

我遇到如下錯誤，請告訴我如何解決
[貼上錯誤訊息]

這邊可以看到錯誤原因是因為剛剛 GitHub Action 還沒開啟，所以我們點擊 Re-run all jobs 讓這個 Job 重新執行看看。

OK，這次執行得很順利，我們點擊一下網址，畫面有成功出來～

以上就是把 Google AI Studio 的 App 透過 Antigravity 放到程式編輯器開發與線上部署的流程。

當然 Antigravity 的功能不只這些，我過去有拍一隻影片專門介紹，如果你做更近一步的功能設計，可以參考下面影片：

【Google Antigravity 教學】把想法化為現實！用 Vibe Coding 完成輕量級全端專案

結語：心態比聰明更重要

到企業做 Vibe Coding 內訓時，我會先問大家一個問題：「你們覺得，Vibe Coding 最需要的是什麼？」

有人說需要有程式的背景，也有人說，與 AI 對話的經驗很重要。

我覺得這些答案都沒錯，但根據我的教學經驗，能把 Vibe Coding 學好，並且實際應用在日常工作中的人，通常都是過去被某個痛點困擾很久的朋友。

也正因為這樣，當 AI 給錯答案、改壞功能，甚至整個流程卡住時；他們不會第一時間放棄，而是願意多試一步、多問一句。

我想提醒大家一件事：

Vibe Coding 並不是「一次就成功」的工具

就像今天這麼簡單的前端網頁，我們都能看到 AI 犯錯了；但遇到錯誤不要害怕，因為只有直面錯誤，才有機會一步一步把問題解開。

另外隨著你越來越深入使用 Vibe Coding，面對更複雜的邏輯與資料結構時，你可能會發現：

為了完成 A 功能，AI 可能把原本正常的 B 功能一起改壞

但這些問題單純靠「更明確的指令、給予輸入輸出範例、限制操作範圍」等技巧未必能解決。

所以在接下來的 Vibe Coding 系列影片中，我會分享如何用 AI 撰寫「測試程式」。

當專案有測試案例後，即使規模變大、功能增加，也能讓系統維持在相對穩定的狀態！

Vibe Coding 最大的優勢；就是你可以在短時間快速迭代，驗證想法可行性

如果這篇文章對你有幫助，可以順手按個讚，把文章分享給正在 Vibe Coding 的朋友們。

今天要跟大家分享 Google 最新推出的 Antigravity 這款 AI 程式碼編輯器。

不管你電腦的作業系統是 Windows、Mac，還是 Linux，都可以安裝體驗。

這隻文章我會透過 Vibe Coding，手把手帶你完成一個輕量級的全端專案，透過實戰的方式，帶大家了解他有哪些特色。

如果你是剛接觸 Vibe Coding 的新手，可以了解有哪些實用技巧，能讓 AI 給你更精準的回覆，並根據你的需求進行功能調整、畫面優化。

最後告訴你，如何在確保資訊安全的前提下，把專案部署到線上環境。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【Google Antigravity 教學】把想法化為現實！用 Vibe Coding 完成輕量級全端專案

一、全端架構快速入門

以全端專案來說，通常會包含前端、後端、資料庫 3 個部分。

前端是給使用者瀏覽的畫面，我選擇了 React 這款知名框架，他有許多現成的元件素材可以讓 AI 使用。

而後端是處理邏輯判斷的部分，如果採用傳統的 Python、Node.js、PHP 等程式語言。

對新手來說，我認為難度太高了，就算真的把功能做出來也沒有掌控力。

所以我打算使用 Google Apps Script，這款打開瀏覽器就能使用的工具作為替代方案。

至於資料庫，我也不使用 MySQL、Postgres、Mongo；而是使用大家非常熟悉的 Google Sheets，打開就能看到並且編輯資料。

採用這套組合，你不需要伺服器、不用綁信用卡、不需要複雜的前置作業。

就能透過實作理解全端專案的架構，而且最後可以免費把專案放到 GitHub 公開部署。

不管你是要跟朋友炫耀，還是要直接應用到職場上都是可以的喔！

二、快速上手 Antigravity

如果使用過 VS Code 或是 Cusor，那他的介面你應該可以無障礙使用。

目前 Antigravity 只要登入 Google 帳號就可以免費使用，至於免費多久，就看 Google 的心情了。

這邊我先新增一個「pixel-game」的資料夾，然後把它拖曳到 Antigravity 中，這樣 AI 才知道他的工作區，在哪個資料夾底下。

接下來跟大家說明一下右側 Agent 可以做的設定。

這個 … 打開後有 3 個選項，分別是「客製化、MCP 伺服器，以及下載診斷」

設定 Rules，讓 AI 更懂你

建議大家可以選擇「Customizations」來設定一下自己的使用偏好，在 Rules 這個地方，我選擇 Global。

這邊我複製貼上一個 Cursor 內部員工的 Rules 範例，其實提示詞都是通用的：https://x.com/kayladotdev/status/1853272891023872450

DO NOT GIVE ME HIGH LEVEL SHIT, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON'T WANT "Here's how you can blablabla"

- Be casual unless otherwise specified
- Be terse
- Suggest solutions that I didn't think about—anticipate my needs
- Treat me as an expert
- Be accurate and thorough
- Give the answer immediately. Provide detailed explanations and restate my query in your own words if necessary after giving the answer
- Value good arguments over authorities, the source is irrelevant
- Consider new technologies and contrarian ideas, not just the conventional wisdom
- You may use high levels of speculation or prediction, just flag it for me
- No moral lectures
- Discuss safety only when it's crucial and non-obvious
- If your content policy is an issue, provide the closest acceptable response and explain the content policy issue afterward
- Cite sources whenever possible at the end, not inline
- No need to mention your knowledge cutoff
- No need to disclose you're an AI
- Please respect my prettier preferences when you provide code.
- Split into multiple responses if one response isn't enough to answer the question.

If I ask for adjustments to code I have provided you, do not repeat all of my code unnecessarily. Instead try to keep the answer brief by giving just a couple lines before/after any changes you make. Multiple code blocks are ok.

貼上後，這個規則就會在所有的專案中生效；另外大家可以再加上一個 Rules，告訴 AI 你習慣使用的語言。

- Always respond in 繁體中文

點擊刷新後，就可以看到自己設定好的 Rules。

另外如果你想給目前的專案設定特定的 Rules，比如程式碼規則這類的，也可以點擊 Workspace 來設定喔。

跨模型支援

在模型這塊，Google 除了自家的 Gemini 外，還提供了 Claude 與 GPT 的模型讓大家使用。

這邊要提醒一下，每個模型使用是有額度限制的，超過後需要換一個模型使用。

對話模式

在對話上，有分成 Planning 跟 Fast 兩種。

如果你今天要處理的是複雜任務，比如專案初始的規劃，就建議選擇 Planning。

假使你只是想要簡單快速的得到解答，那選擇 Fast 更省時喔。

不要完全賦權給 AI Agent

• Terminal Command Auto Execution 不建議用 Turbo 模式（此模式僅建議在獨立容器內執行）
• 編輯 Deny List Terminal Commands 放黑名單指令

三、引導 AI 生成專案

可以在右側的 Agent 對話框中，貼上我們的需求：

# 角色
你是一位資深的 React 前端工程師與遊戲設計師。請根據需求描述協助我設計一個網頁的「闖關問答遊戲」

# UI/UX 需求
- 前端框架：React Vite
- 風格：Pixel Art 像素風，像是 2000 年代的街機，樸實但是有設計感。
- 關主圖片處理：使用 DiceBear API 預先載入 100 張不同素材
- 關卡呈現：每一關皆配有一個 Pixel 風格的「關主」圖片

# 功能需求

## 操作流程
- 首頁：使用者需輸入「ID」才能開始遊戲，此 ID 是為了記錄到 Google Sheets
- 題目來源：透過 Google Apps Script 從指定 Google Sheets 的「題目」工作表隨機撈取 N 題（不包含解答欄位）
- 成績計算：將作答結果傳送到 Google Apps Script 計算成績，並記錄到 Google Sheets

## Google Sheets 配置
- 「題目」工作表：題號、題目、A、B、C、D、解答
- 「回答」工作表：ID、闖關次數、總分、最高分、第一次通關分數（若同 ID 已通關過，後續分數不覆蓋，僅在同列增加闖關次數）、花了幾次通關、最近遊玩時間
- Google Apps Script：是直接從這份 Google Sheet 擴充功能配置的

# 環境變數設定 (.env)
請將以下參數設計為可透過環境變數配置：
- GOOGLE_APP_SCRIPT_URL：Google Apps Script 的後端連結
- PASS_THRESHOLD：通過門檻（需要答對幾題才算通過）
- QUESTION_COUNT：每次遊戲的題目數量

這邊說明一下我是如何發想專案的。

最近在幫學校老師與企業的人資上課時，他們提到自己時常有出考題給學生，以及對員工有培訓考核的需求。

但市場上找不到可以免費亂數出題、自動批改、簡單操作的工具。

了解需求後，我就想：

那不如我嘗試用 Vibe Coding 設計一個簡易的闖關遊戲？

於是今天的影片就出來了，我希望大家 Vibe Coding 時，盡可能從「實際」的需求出發；如果只是複製貼上別人的提示詞，你是學不到什麼東西的。

下面跟大家說明一下我的提示詞架構：

前端風格

首先，我做了角色設定，讓他扮演資深的 React 前端工程師與遊戲設計師。

另外如果你是第一次接觸 React，會需要先安裝 Node.js，詳細安裝與設定步驟可以參考上方的資訊卡，我有特別錄一集影片，分享安裝哪些工具可以讓 Vibe Coding 效率加倍。

好，除了有角色設定與框架選擇外，我還跟他說了我期待的設計風格是 Pixel 像素風。

並且關主的圖片要先下載好，每一關都要配置一個。

前後端邏輯設計

接下來，我則是非常明確的規範專案的「功能需求」，這塊就是講解前後端的運作邏輯。

我告訴他使用者需輸入「ID」才能開始遊戲，此 ID 是為了讓 Google Sheets 紀錄分數時知道對方是誰。

另外遊戲一開始會透過 Google Apps Script 從 Google Sheets 撈取「題目」，這邊有特別交代不要包含解答欄位。

之所以不直接從 Google Sheets 抓題目，是為了保護資料來源。

另外作答完畢後，會把答題結果傳送到 Google Apps Script 計算成績，並記錄到 Google Sheets。

資料庫設計

然後為了要讓 AI 明白資料如何讀取與寫入，所以我提供了非常明確的 Google Sheets 配置，減少模糊地帶。

不管題目還是回答的工作表，我都有明確列出欄位。

並且針對特殊欄位有額外的說明，像是「回答」工作表的第一次通關分數，我就備注：「若同 ID 已通關過，後續分數不覆蓋，僅在同列增加闖關次數」。

還有特別補充一點，Google Apps Script 是直接從這份 Google Sheet 擴充功能配置的，這是表達工具間的相依性。

環境變數設計

最後考量到專案完成後的「易用性」，所以我把「Google Apps Script 連結、通過門檻、題目數量」等設計為環境變數。

這樣日後要換考題、改變評核標準，就不用打開程式，在網頁動動手指就好了。

通常第一次的結果都不會滿意的

不滿意的地方，你可以直接跟 AI 討論（可以參考影片）

四、部署前注意事項

確認功能都符合需求後，接下來我們就要準備將專案部署到 GitHub Pages。

但部署前，我先提醒一下要注意的事項：

設計 .gitignore

在這裡放不要加入 Git 版控的檔案、資料夾，比如：

• 套件資料夾（node_modules）
• 程式自動生成資料夾（dist）
• log 檔
• 暫存檔（.tmp）
• 隱私檔（.nev）

設計 .env.example

雖然 .env 不可以上傳，但為了讓其他人知道可以如何使用這個專案，我會設計一個 .env.example 的範例檔：

請幫我建立一個 .env.example 的範例檔

設計 Github Actions

另外因為我們想要在 GitHub 部署，所以這邊我也請 AI 協助設計對應的工作流

請設計能自動部署到 Github Pages 的 Action，會使用到的環境變數請參考 .env.exmaple 檔
並將操作流程更新到 README.md 文件

五、用 GitHub Pages 免費發布網頁

先點擊左側的 Source Control，點擊 Initialize Repository 可以初始化專案。

接著點擊 Generate，AI 就會辨識我們更新的內容，來產生 commit 訊息。

確認文字描述符合自己的預期後，點擊 commit，就會在自己的電腦記錄這個變更。

但如果想更新到雲端，你需要點擊 Push 才會正式上傳喔！

如果專案尚未存在於 GitHub，這邊會有彈窗出現，讓你輸入專案名稱。

另位因為我們的專案預計要發布到 GitHub Pages，所以選擇 Public Repository，完成後，點擊 Open GitHub 去看看是否部署順利。

如果能看到專案的內容，就代表你成功上傳專案了！

完成這些操作後，我們回到 GitHub 點擊「Actions」的分頁，查看部署的狀況。

成功的話會有綠色勾勾，失敗則是紅色叉叉，會需要點進去釐清具體的錯誤原因。

一開始部署失敗很正常，你可以把錯誤訊息複製起來，直接貼到與 AI 的對話視窗中，讓他幫忙解決

如果一切順利，點擊進去就會看到這個專案的網址嚕

之後這個專案都是使用這個網址，把它點開來，順利的話，就可以看到成品嚕～

但這個時候還不要高興的太早，因為我們還沒有設定這個專案的環境變數

這邊我們再回到 GitHub 頁面，選擇 Settings 分頁，選擇左側的「Secrets and variables」。

選擇「Actions」，這時你會發現環境變數的設定有分成兩種

Secrets，是放比較隱私的變數，而 Variables 則是放較不敏感的環境變數。

至於怎麼放，我們可以回到專案，點開「.github」資料夾底下的 deploy.yml 檔案。

在 .env 的地方就有跟我們說明了哪些環境變數使用 secrets，哪些使用 variables，這邊使用「New repository secret」來設定。

完成後，要記得到 Action 的分頁，找最後一個 deploy 的結果，選擇 Re-run all jobs，這樣環境變數的變更才會生效喔！

這邊提醒一下，這隻影片是先幫大家初步掌握「全端專案的核心概念」

讓你了解前端怎麼顯示、後端如何處理資料，以及資料庫如何存取

目前的專案架構，並不適合處理邏輯複雜與高流量的使用場景

但在了解這些概念後，未來後端想換成 Node.js，資料庫換成 MySQL 會輕鬆許多

六、結語：培養真正的工程思維

最近我拍了許多 AI 主題的影片，但主要目的不是要介紹工具如何使用，而是透過自己的經驗，從「實戰」的角度去深入分享。

這幾年來，我在學校、企業講過許多 AI 輔助撰寫程式的課程，也就是現在大家所說的 Vibe Coding。

很多學員都在問我，使用哪個工具才是最好的，我跟他們說：「選擇你最順手的主流工具就好，儘管工具間有差異；但完成專案的關鍵在於人，而不是工具。」

以程式編輯器來說，從 VSCode、Cursor，到今天介紹的 Antigravity。

工具永遠在更新、競爭，但我開發十幾年後，體悟到很重要的一件事：

「不管程式語言還是工具，他們的本質都是為了解決問題；

一直學新的程式語言、換新的工具，其實對個人的成長極其有限。」

因為你的精力被分散了，對新手來說，還不如選擇一門程式語言，好好去深入研究。雖然程式間的語法不同，但底層邏輯都是差不多的。

我不會特別崇拜某個程式語言，也不會非某個工具不用，因為現實世界只有「當下最合適」的選擇。

技術會一直迭代更新，但程式的底蘊可以持續累積。

在文章的最後，請大家在 AI 時代一定要保有自己的判斷力與行動力；就算你覺得這篇文章的內容很棒，那終究是「我的使用情境」。

動手將知識轉化成自己實際能用到的，那才會變成你的。

如果未來你打算用 Vibe Coding 開發更完整的全端專案，可以先看看這隻影片。

我有錄一隻影片分享 Vibe Coding 時，前端、後端、資料庫最常遇到的陷，他可以幫助你有系統地建立安全意識。

儘管 AI 工具會越來越強大，但他同時會給沒有相關知識背景的人帶來更大的幻覺。

過去 AI 寫錯程式會跑不動，你會知道他錯了。

可是他現在有能力寫出「看起來能動」的工具，畫面正常、功能正常；但可能背後的邏輯有問題，或者你看到的只是假資料。

如果沒有前後端概念，不了解資料庫如何運作，那你是沒有能力判斷 AI 給的資訊是否正確的。

記住！AI 是一個好幫手，但他並非萬能

如果這篇文章對你有幫助，可以順手按個讚，把文章分享給正在 Vibe Coding 的朋友們。

如果你正在 Vibe Coding，那這篇文章一定要看完！

它可以幫你有系統地建立安全意識。

我會從「前端、後端、資料庫、版本控制」四個面向，讓你了解風險與問題出在哪。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【AI 陷阱 EP2】Vibe Coding 實戰必看！10 個會讓你專案翻車的技術陷阱

1. 把敏感數據寫在前端

有時我們請 AI 設計一個登入頁面，結果他把帳號密碼的驗證邏輯寫在前端。

這樣只要按下 F12，搜尋「password」這類關鍵字，就可能找到登入的帳號密碼。

除了帳號密碼外，有些人會分享一些 AI 生成圖片、影片的服務，但這些服務通常要 API Key 才能使用。

而 API Key 往往要綁定信用卡，這代表洩漏 API Key，你的信用卡可能會被刷爆。

2. 將暫存資料當永久資料

有時 AI 做好的網站看起來有儲存功能。

但他未必是存到資料庫，有可能只是暫存到網頁的變數，或是存到瀏覽器的 localStorage 中。

這樣當你刷新頁面，或換一個瀏覽器時，就會發現資料不見了。

3. 頁面沒有做權限控管

這樣只要使用者知道網頁路徑，就能跳轉到管理者介面。

而這個問題可能會導致客戶個資外洩、產品訂單被篡改，除了經濟損失外，還會連帶影響品牌信譽。

4. API 沒有權限設計

接下來聊聊後端的部分。

有些人設計了登入機制，但卻沒有設計角色權限，這會導致非常嚴重的問題。

你可以想想看，如果一般消費者登入 PChome、Momo 這類購物平台後

可以自由修改商品價格，那會造成多嚴重的後果

5. 沒有設計審計日誌

不管前期規劃多完善，系統上線後一定會出問題！

假使沒有設計審計日誌，你連錯誤在哪裡、什麼時候發生、使用者做了什麼操作都一無所知。

無法重現問題，怎麼可能解決問題？

6. 沒有限制 API 呼叫次數

這邊以使用者登入來舉例，假使系統登入的 API 沒有次數限制。

那不就代表使用者可以嘗試不同密碼組合去暴力破解？

7. 使用者密碼用明文儲存

如果資料庫裡使用者的密碼，沒有經過雜湊處理，那一旦資料庫外洩，所有使用者密碼會直接暴露。

我知道很多人是一個密碼打天下，這代表其他帳號可能會被駭客盜用。

8. 選錯資料庫

有時 AI 會選擇 Redis 來當系統資料庫，但只要伺服器重啟，災難直接降臨。

因為 Redis 是記憶體資料庫，重啟後緩存的資料就不見了，即使有持久化設計，也不建議當主資料庫。

9. 把機密檔案上傳到 GitHub

現在很多人用 GitHub 來做專案的版本控制。

但如果不小心將存放隱私資料的 .env 環境檔上傳，然後你的 Repository 還是公開的。

那系統的後台，可能就變成所有人可以隨意進出的遊樂場。

10. 沒有設計 .gitignore

這會導致你把 node_modules、dist、log 這類體積大、數量多的檔案加入版本控制。

不僅會讓 repository 上傳下載時間變長，還會讓版本控制混亂，難以追蹤真正變更。

好的，以上就是今天跟大家分享 Vibe Coding 的十大陷阱。

這篇文章涵蓋的資訊量比較大，如果有聽不懂的地方也別擔心。

我會在後續的文章中，透過實際案例跟大家分享這些問題如何解決。

如果這篇文章對你有幫助，可以順手按個讚，把文章分享給正在 Vibe Coding 的朋友們。

一開始會分享與 AI 釐清需求，討論出產品規格的技巧；並說明請 AI 撰寫程式前，我會如何設計專案的規則，讓 AI Agent 撰寫程式時，有參考的依據。

在準備好專案的規格與規則後，我才會讓 AI Agent 開始動手寫程式、完成專案。

但程式完成，不代表結果符合預期；你可能會遇到錯誤訊息、外觀破版，或是想要新增更多功能。這邊也會跟大家示範，可以如何引導 AI，讓專案更加完整。

在最後會分析整個專案架構，帶大家了解 AI Agent 到底幫我們做了哪些事；並透過 GitHub Pages 發布專案，讓你完成的網頁可以直接分享給朋友。

建議搭配影片觀看實際的操作步驟。

【Cursor 教學】Vibe Coding 實戰！從釐清需求到部署上線，一次搞懂完整開發流程 #spec #git #nodejs #deploy #ai #sdd

第一次接觸 Cursor 與 Vibe Coding 的朋友，可以先參考下面的文章：

➤ Cursor 教學：入門到實戰，用 AI Agent 自動化你的工作流！

➤ Cursor 教學：安裝 3 款讓 Vibe Coding 效率翻倍的工具！用「個人形象網站」實戰演練

① 釐清需求，生成專案規格

我覺得 Vibe Coding 的目的，是要在短時間實踐你腦中的靈感，或解決現實生活遇到的痛點。

最小可行性方案

儘管每個人想完成的專案大小不同，但建議大家先釐清目標的「最小可行性方案」

把想要一口氣搞定大型專案的想法，從腦中拿掉；否則最終產生的結果，要馬不會動，要馬問題一堆。

後續反而要花更多的時間，一一排除這些問題。

製作純前端網頁

同時建議沒有程式背景的朋友，可以把「純前端網頁」，也就是這篇文章的範例，當成第一個 Vibe Coding 專案。

因為不涉及後端、資料庫，所以比較沒有資訊安全、隱私外洩的問題。

而且完成後可以直接把網頁分享給朋友，非常有成就感。

真的會用到的工具

另外專案的目標，最好設定為自己「真的會用到」的工具。

像大家現在看我上面的 YT 影片，可能覺得我侃侃而談，講得流暢不卡詞。

這不是因為我有多厲害，而是因為面前有一個提詞器；準備好逐字稿後，我只要錄影時照著念就好了。

一開始我是使用網路上，其他人分享的線上提詞器；但免費的廣告一堆，付費的又塞了一堆用不到的功能。

既然如此，我乾脆直接用 Vibe Coding 寫一款完全符合自己使用需求的提詞器，同時也讓大家免費使用。

新增空資料夾，來開始專案

我們要先透過討論釐清這個網站需要有的功能；因此這邊不使用 AI Agent，而是先切換到 Ask 的模式來討論。

我想要設計一個「純前端」的「提詞器」網頁
想要以「最小可行性方案 MVP」來進行設計
請從實際使用者的角度，將功能依據「必要、次要」的方式來分類
並告訴我使用者體驗最佳的操作流程

此時你會得到 AI 初步的規劃建議，如果你對結果不滿意，可以繼續討論。

假使覺得這個規劃可以接受，就可以把它轉換成方便網頁工程師理解的需求規格。

請扮演專業的 UI/UX 設計師，根據上面的討論
用下面的格式，回傳「具體、可執行」的網頁設計規格。
目標是幫助前端工程師能依據描述直接開始開發，內容需具備視覺與互動細節。

輸出格式：
# [頁面名稱]
- 功能簡述：（一句話概述頁面目的）
- 色系搭配：（主色、輔色、背景色、按鈕色）

## [由上而下列出使用元素]
請依畫面垂直順序列出元件，格式如下：
- 元件名稱（如：頂部導覽列 / 按鈕 / Banner 區塊）
  - 顏色：
  - 寬度：
  - 高度：
  - 字型大小與樣式（如有文字）：
  - 功能說明（該元件的目的）：
  - 若為[按鈕] → 說明觸發任務（例：「送出表單」「切換主題」）
  - 若為[功能按鍵] → 說明使用方式（例：「滑過顯示選單」「長按複製」）

⚠️ 請只輸出上述格式內容，不要附加分析、理由或額外說明。

透過這個提示詞，你就會得到一份非常詳盡的規格：

接下來切換成 Agent 模式，請他將前面對話的內容彙整成一個 Markdown 格式的 Prompt，儲存到專案「idea」的資料夾中。

將上面對話的結論彙整成 Markdown 格式的 Spec
請儲存到專案根目錄的「idea」資料夾中（若無自動建立），以好辨識的英文命名檔案
還不需要實作

之所以這麼做，就是產生一個可以讓我們手動編輯細節的規格文件，而且後續開發時可以回顧專案的設計。

儘管相關訊息可以從過去的對話找到，但相信我，你幾乎不會翻過去的對話內容。

儘管我們可以使用 AI Agent 模式，讓 AI 直接寫程式；但我更建議大家先討論出具體、明確的專案框架後，再請 AI 做事。

近幾年流行一個名詞，叫做 SDD（Specification-Driven Development），也就是規格驅動開發

比如今天的範例，就是用規格驅動 AI 開發，當目標足夠明確、解決的問題足夠具體時，你對生成的結果才有較高的掌握度，Vibe Coding 的成功率才會上升。

如果你在想這些步驟會不會花太多時間。

我可以用十多年的開發經驗跟你保證，如果初期沒寫好文件，日後要花好幾倍的時間去反覆修改。

② 設計規則，讓 AI 知道做事邏輯

今天的範例為「前端網頁」，可以只用簡單的 HTML、CSS、JavaScript 來完成。

但為了讓大家對「專案」有更具體的概念，所以我以三大前端框架 Vue、React、Angular 做示範。

在每個框架下，其實都還有各自的元件庫可以使用

• Vue：Element Plus、Vuetify、Naive UI
• React：Ant Design、Material UI、Chakra UI
• Angular：Angular Material、NG-ZORRO、PrimeNG

如果你對這些框架不熟悉，建議你可以先挑一個（ex: React + Material UI），未來 Vibe Coding 就直接指定他。

之所以這麼做，是因為每個框架與元件庫會遇到的坑都不一樣，假使每次都用不同的框架來製作專案。

那可能每個坑都得走一遍，這是一件非常沒有效率的事情。

建立專案的 Rules

接下我們要去建立專案的 Rules，讓他製作網站時知道要依循什麼規則。

點擊右上角的設定，選擇「Rules & Memories」，在 Project Rules 點擊新增。

檔名我就直接打「spec」，然後選擇 Always Apply 讓他每次對話都會觸發。

然後貼上設計的規則，在規則的部分，使用 Markdown 的語法撰寫就好，大家有興趣可以自行客製化，我只是提供一個基礎的範本。

## 使用的框架與元件庫
- 框架: React + Vite
- Node 版本: 加 .nvmrc
- 元件庫: Material UI

## 注意事項
- 請先搜尋網路上類似工具使用的套件
- 需考量 RWD 響應頁面
- 建立 .gitignore 來排除指定檔案上傳（ex: node_modules）

## README
- 專案介紹、功能列表、需求（Node 版本）、安裝與啟動、部署步驟、授權

## GitHub Pages 部署
- 使用 GitHub Actions
- 僅 master branch 觸發

③ 讓 AI Agent 參考規格、規則開發專案

在專案的需求規格以及規則都設計好後，接下來就可以用 AI Agent 設計初版網頁了。

建議開一個新對話，選擇 Agent 模式，你直接跟他說：

請參考「idea」的 SPEC，在專案根目錄新增「teleprompter-app」來實作專案

稍等一段時間，AI Agent 就會根據 SPEC 把這個網站製作出來。

如果他有自動幫你運行專案，你可以先請他關閉：

幫我關閉專案

這是因為在專案完成後，建議大家用新的 Cursor 視窗來來開啟這個專案，因為前面專案的規格與規則是為了產生這個專案而寫的，專案產生完畢後，繼續使用原有的規格、規則，可能會導致 AI 混亂。

另外在安裝專案套件與啟動專案這塊，你可以直接跟 AI 說：

幫我安裝套件並啟動專案

不過我是更建議大家打開 package.json 這個檔案，裡面有專案的各種資訊，像 scripts 這塊就是你可以透過 npm 執行的各種指令。

像是基礎的開發啟動是 npm run dev、想要建立靜態檔用 npm run build 。

如果想安裝套件，就用 npm install，他會安裝 dependencies 與 devDependencies 所列出的套件。

這邊我們打開終端機，在下面貼上指令「npm run dev」來啟動專案（具體指令請參考 scripts）

但提醒大家，不管我們前期的規格對功能、外型描述得多仔細；他完成的結果還是有可能會不如預期（比如影片範例就是一片空白）。

別忘記，生成式 AI 的結果本來就是充滿隨機性的。

這些是我為何建議先完成最小可行性產品，因為範圍小，所以釐清錯誤、調整內容相對方便。

一但範圍大了，你連怎麼調整都會沒有頭緒。

所以千萬別想著靠一個指令就生成一套系統，因為光生成一個簡單的網頁都會遇到很多問題了。

④ 解決問題、優化專案、新增功能

以前端網頁來說，問題通常分成兩大塊：

• 外型：你可能覺得頁面的版型、顏色、按鈕大小不符合你的預期
• 功能：有些操作起來不符合你的預期

解決問題

比如我想要讓提詞器播放順利，可以這麼說：

提詞器進入全螢幕後遇到以下問題：
1. 第二次點擊播放時，進度條會直接到底
2. 觸控板滑動時，頁面滑動與滑鼠感受不同
3. 滑到中間位置時按播放，感覺是更從前面的位置開始

優化專案

另外這個網頁有一些快捷鍵，我希望具體的使用方式可以放在首頁輸入框下方，這邊我就貼上一個比較模糊的指令，跟他說：

在首頁「輸入框」下方，新增「快捷鍵」提示的區塊，說明快捷鍵功能，請使用明顯的色系搭配

這個 Prompt 我就沒有指定具體色系、寬度、高度，由 AI 自動判斷。

等 AI 完成實作後，如果你不滿意，可以透過後續引導來微調細節。

新增功能

這邊我再新增一個功能來做示範，比如我希望貼上文字後，能有中文、英文、符號的字數統計，以及總共行數：

在首頁「輸入框」下方，增加「即時字數統計」的功能，在 1 列分 3 塊顯示
- 中文字數、中文標點符號數
- 英文單詞數、英文標點符號數
- 總共行數
希望文字有對應顏色搭配方便辨識

等 AI 搞定後，我們回到網頁，然後貼上文字，初步確認計算是否符合需求。

其實這個提詞器還有很多細節可以優化，這邊給大家看我最後調整了哪些細節：

• 在首頁的地方，我增加了自己社群的資訊
• 把「字數統計、快捷鍵說明」這兩個區塊都改成一行顯示，減少空間上的浪費
• 進入全螢幕畫面後，我把原本置中的內容改成靠左以符合我的習慣
• 因為錄製影片時前面會有腳架，所以我設計了間隔，讓文字不要被腳架擋住
• 設計了分段的功能，讓我可以調整講話節奏
• 右上角多了一個「倒數計時器」，讓我知道現在的稿子會講多久

我覺得 Vibe Coding 的魅力不是一鍵搞定，而是你可以根據實際需求快速迭代產品，但前提是你知道自己要的是什麼。

⑤ 了解 AI 生成的專案架構

接下來讓我們來瀏覽一下專案資料夾，了解 AI 幫我們做了哪些事情：

package.json

• scripts 這裡，有專案啟動、建立靜態資源的指令
• dependencies、devDependencies 則是專案使用套件的版本資訊

未來隨著專案規模擴大，你可能會遇到框架與套件、套件與套件之間相容性的問題，到時可能就會有鎖定版本、升降版本的需求，原則上就是在這邊調整的。

node_modules

「dependencies、devDependencies」列出的套件，都會被安裝到 node_moodules 的資料夾當中。

以 Node.js 的專案來說，通常體積最大的就是 node_moodules 這個資料夾。

因為套件版本已經有 package.json 控管，所以我們並不會把 node_moodules 上傳到 Git。

至於如何把他從 Git 版控中移除，就要談到 .gitignore 這個檔案了

.gitignore

這個檔案是用來告訴 Git 哪些檔案或資料夾不該被版本控制追蹤：

• MacOS 與 Windows 的系統暫存檔（.DS_Store/Thumbs.db）
• 儲存專案套件的 node_modules 資料夾
• 自動生成的結果，如 build 這類資料夾
• 像 .env 這種會儲存個人設定與密鑰的設定檔

README

這份文件會包含專案簡介、功能列表、安裝環境需求等資訊，可以幫助你快速掌握這個專案的重點資訊。

⑥ 用 GitHub Pages 免費發布網頁

確認專案都符合需求後，我們可以透過 GitHub Pages 發布專案，具體的執行流程可以參考專案中 「.github/workflow」 底下的 「deploy.yml」 設定檔。

在 GitHub 建立 Repository 後，會根據這邊設計的流程來發布專案。

建立 Repository

Repository 名稱輸入「teleprompter-app」，因為我們這個專案預計要發佈到 GitHub Pages，所以選擇 Public。

把電腦專案與 GitHub Repository 連接

在終端機輸入 git init 來初始化專案 git。

然後回到網頁，複製第一行 git add… 貼到專案的終端機，這樣我們就可以把電腦的專案與 GitHub 上面的專案連結。

確認有更新到 GitHub Repository

點擊提交，就會在自己的電腦記錄這個變更，但如果想更新到雲端，你需要點擊 Push 才會成功喔！

Push 後我們回到 GitHub 網頁，刷新一下頁面，如果能看到專案的內容，就代表你成功上傳專案了！

到 Actions 分頁查看部署的狀況

成功的話會有綠色勾勾，失敗則是紅色叉叉，會需要點進去釐清具體的錯誤原因。

錯誤通常都是因為：

• 靜態資源沒找到（static resource）
• 語法格式錯誤（line error）
• 套件相依問題（npm dependency）

把它複製起來貼到 AI 對話框，通常都能快速釐清問題並解決。

如果一切順利，點擊進去就會看到這個專案的網址嚕：

之後這個專案都是使用這個網址，把它點開來，順利的話，就可以看到成品嚕～

如果影片看到了這裡，可以幫我點個讚鼓勵一下，我會持續分享更多實用教學。

結語：Vibe Coding 的底層邏輯

過去學程式、寫程式，是一個痛苦，且漫長的週期。

沒學到一定的程度，你連小程式都開發不了。

但現在有了 AI，即使你不會寫程式，也能透過對話的方式，一步步完成專案的建立。

像今天這隻影片就分享了用 Vibe Coding 從 0 到 1 的完整過程，雖然專案的規模較小，不過日後面對更大型的專案時，底層邏輯與流程也是一樣的。

建議大家先從小專案開始練習、熟悉開發的流程；這樣日後想設計大專案時，會更有完整的概念。

另外隨著專案規模擴大，功能增加，你還需要搭配一些自動化測試的工具來輔助。

單靠人工的方式手動測試，不但沒效率，還很容易有遺漏的測試項目。

而且新功能的增加，有可能會導致舊功能壞掉，如果這隻 YT 影片的按讚破 200，我會再出一隻影片。

跟大家分享用 AI 撰寫測試程式的概念與技巧～

之所以製作一系列 Vibe Coding 影片，是為了避免大家踩到我遇過的「坑」。

如果你對 AI 工具、自我成長、職涯發展感興趣，歡迎追蹤我！我會我會持續分享新的觀點 💡

給我 1 分鐘，帶你認識現在最夯的 Vibe Coding #ai #aicoding #vibecoding #chatgpt #cursor #githubpages

開始拍 YouTube 影片後，因為我總是記不住台詞，所以需要提詞機；但免費版廣告一堆，付費版又塞了一堆用不到的功能。

既然如此，我乾脆直接用 Vibe Coding 寫一款無廣告的提詞機給大家免費使用！

工具選擇

一開始我先用 ChatGPT 來寫程式，但隨著需求增加，他開始鬼打牆；不但新功能沒做好，連原本能用的也壞了。

就算提示詞加上各種限制，或開新的對話窗，也沒太大幫助。

所以在 Vibe Coding 的工具選擇上，我並不推薦使用 ChatGPT。

我個人更推薦使用的工具是 Cursor，他是一款內建 AI 功能的程式碼編輯器。

可以使用中文與他溝通，且每次修改都有差異比較。

不論新手學程式或老手解 bug，Cursor 都比 ChatGPT 高效。

使用提醒

但還是要提醒大家，AI 雖能加速開發，卻不保證一次到位。

如果你有程式的底子，那提出具體問題、給予明確方向，可以大幅縮短開發時程。

沒有程式基礎的也別擔心，先請 AI 解釋邏輯、逐步拆解，你一樣能從 0 打造自己的工具。

不過 Vibe Coding 雖然聽起來輕鬆，但背後仍需要反覆測試，以及對錯誤訊息保持耐心。

AI 是助力，不是萬能！

成果展示

如果你 Vibe Coding 的作品是靜態網頁，上傳到 GitHub Pages 就能向大家展示自己的成果。

我完成的題詞器，以及上面提到的工具連結如下，歡迎取用：

• 讀稿提詞機: https://deanlin.net/teleprompter/
• ChatGPT: https://chatgpt.com/
• Cursor: https://cursor.com/cn
• GitHub: https://github.com/

如果你對這個主題感興趣，可以幫我點個讚。

我是鼎淵，一個熱愛分享 AI 知識、自我成長、職涯發展主題的工程師。

歡迎追蹤我的 YouTube，帶你掌握時代趨勢！

《工程師下班有約》網路書店： 🐲天瓏書局

我是林鼎淵，如果覺得這邊文章對你有幫助，歡迎追蹤筆者的 Facebook 與 YouTube，我會持續分享實用的新知識 💡