用 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 的朋友們。