過去兩個月，我參與了各種與 AI 與 Vibe Coding 有關的活動——完成 Google Cloud AI Study Jam、第一次擔任 AI 講師完成了一堂收費課程、報名六角學院的公益程式體驗營，也參加了 Google DevFest Taipei。看似要踏入前端工程領域，但真正帶給我的，是一次重新檢視自己工作方式的機會。
我一直喜歡研究生產力工具。還沒有 AI 協作風潮之前，我就常用各種外掛調整自己的工作流程。例如在外商擔任總經理 EA 時，我導入 Boomerang for Gmail，讓 Magic Calendar 直接嵌在信件中，對方只要點擊預約方塊就能確認會議時間，不需要 Email 反覆往返、核對不同時區的會議時間。當時我並沒有意識到這叫什麼「流程設計」，只是想把事情做得更順。但回頭看，這些經驗讓我自然養成一個習慣：工具要能真正解決問題，才能真正發揮價值。 也因為如此，當我開始接觸 Vibe Coding 時，我最在意的不是功能能不能跑，而是 —— 這個工具是否真的改善了流程？
這篇文章，是我在六角學院做 Day21 每日任務「活動報到小幫手」作業的完整紀錄。過去我在 Vibe Coding 的成果，多半依賴自己原有的工作習慣就能做出原型，但在這兩個月參與不同的課程、活動，學習之後，因為更理解程式的基本功，也開始從「能做出來」邁向「怎麼更有效率、做得更好」。
這次的作業，也成為我整理這段轉變與反思的起點。
以活動報到為例：用 Vibe Coding 把流程做成工具
我會選擇做「活動報到小幫手」，其實是前陣子我剛好協助朋友做了一個一頁式活動報名頁面。
當時靠依據自身對於舉辦活動的 knowhow，利用 Google AI Studio 很快就做出個有基本功能的報名網頁，朋友當時也很滿意，但我在調整頁面以及 debug 的過程，還是會有和 AI 來來回回的鬼打牆過程，所以才更想要知道怎麼樣能更有效率的與 AI 一起 Vibe Coding。
在這兩個月的學習當中，我補上了前端基礎、資料流、API 串接等核心能力，也重新連結到我在商業思維學院「產品經理學習營」中第一個學習到的產品思維：所有的產品都是為了解決痛點。
這也是 Vibe Coding 對程式小白最迷人的地方 —— 它降低了實作的門檻，讓想法能快速成形，但想法能否成為「真正有價值的工具」，取決於對需求、資料、流程的思考是否全面。
換句話說，Vibe Coding 只是工具，真正重要的是背後的流程設計與產品思維。
因此，這次的報到工具不只是作業，而是一次把產品思維、技術基礎與 Vibe Coding 串起來的練習。
Vide Coding 的 PDCA：把需求、流程全部釐清（PLAN）
這個報到系統本身並不難，其實丟一句 Prompt 給 AI，也做得出一個能運作的版本，例如：
我想要有一個活動報到系統，學員輸入手機之後，就會紀錄報到時間。
如果只是「做出來」，做到這裡就結束了；但這次我想試著做得更好一點。所以在動手寫程式前，我先把 spec 和 plan 寫出來，再請 Antigravity 一起開發。這背後其實是 SDD（Spec-Driven Development）的核心精神——先說清楚需求，再開始動手。
想要做一個活動報到小幫手，要考慮什麼
如果從活動現場看，一個最直覺的流程大概是：
學員到現場 → 進行身分驗證 → 確認是有效學員 → 報到成功
在產品語言裡，這是 user flow；但接下來要把它轉成系統真正的運作方式，也就是 function flow：
- Input：有哪些資料可用？（姓名、手機、Email、訂單編號…）
- Process：使用者輸入後，程式怎麼比對？流程如何運作？
- Output：學員端看到什麼？後台記錄什麼？
- Condition：靠什麼欄位來判斷學員的身分？
如果有用過 n8n，就會發現這種拆解方式非常熟悉 ── 它本質就是在想「資料怎麼流」。
在我預設的案例裡，報名的資料只有姓名、手機、Email，在 Vibe Coding 我就要先思考
- 希望的流程：掃 QR Code → 進入網站 → 學員輸入手機 → 系統驗證 → 系統記錄報到時間 → 顯示報到結果
- 期待的結果：前台顯示「報到成功」，後台留下報到時間與紀錄
- 條件判斷：用學員的 Email 還是用手機號碼驗證？不同方式的風險是什麼？
這些內容確定後，AI 在開發時就能更準確地生成程式碼，不會一直來回鬼打牆。
不會寫程式的小白如何利用 SDD 規格驅動開發
雖然現在有許多現成的 SDD 工具（例如 Github 的 Spec‑kit），但對我這種沒有軟體公司背景的人來說，剛開始看到時其實有點卻步。我第一次看到它的反應是：「這應該是工程師在用的吧，跟我應該沒什麼關係？」但後來才發現，它核心概念其實並不複雜——抓住 Why / How / What 的邏輯，就能用在自己的 Vibe Coding 流程裡。
回到工具的目的來看，其實核心概念很單純，就是三件事：
- Spec – Why：為什麼要做？要解決什麼痛點？
- Plan – How：打算怎麼做？流程會怎麼走？
- Task – What to do：要分成哪些小任務，一步一步完成？
只要把這三件事情說清楚，其實就已經是在做「規格驅動開發」了。差別只在於你是用工程師習慣的格式寫，還是用自己看得懂的語言寫。
在和 AI 協作時，我會先用這個框架整理好內容，再丟給模型，請它幫我轉成程式碼。
這裡我也借用了電腦玩物站長 Esor 提出的 CRIT 流程，讓 AI 扮演各種不同的專案，協助我以 SDD 的方式，寫出 spec 還有 plan
- 情境（Content）：先與 AI 說明目前遇到什麼困難，有什麼資源與限制，以及此階段希望變得更好的地方。
- 角色（Role）：指定希望 AI 扮演的專家角色，並請它在當前資源與限制下提出 2–3 個可行的解決方向，最後再協助收斂。
- 採訪（Interview）：請 AI 主動反問我，在收斂後的方案中，哪些內容我沒有想到？哪些例外狀況可能會造成問題？流程或資料欄位是否仍有缺漏？
- 任務（Task）：整合以上所有資訊，明確描述我當前真正要做的任務，並請 AI 協助執行。
對不會寫程式的小白來說，重點不是把 SDD 或 CRIT 用得多標準，而是透過這個過程，逼自己把需求、流程、資料想清楚。
當這些都講清楚了，你交給 AI 的，就不再是一句模糊的「幫我寫一個活動報到系統」，而是一個可以落地的、被拆解過的任務。
DO → CHECK → ACTION：讓作品真正可用
把需求釐清之後，後面的事情就相對簡單了。
以這次的作業來說，我會把任務拆成一小段一小段，請 Gemini 依序協助開發（Do）。
每完成一段功能後，我會自己人工驗收（Check），重新跑一次流程、點一次畫面，檢查邏輯是否如預期、體驗是否順暢。若有 bug、流程斷點、畫面不合理的地方，就再請 AI 協助調整（Action）。
接著再進入下一個 task，持續迭代，直到整體體驗符合自己的期待。
在課堂上，我也會提醒學員：「不要追求一次到位。」因為在真的做出作品後，才會看見真正的問題。
所以，比起一開始就追求完美規格，我更希望學員回頭問自己兩件事：
- 這個工具真的解決了你的問題嗎？
- 它有為你創造價值嗎？
核心功能先被滿足、能用，就先拿出來用。世界上沒有完美的規格，也沒有一次就做好的工具。Vibe Coding 做出來的成品，也需要在一次次試煉、實際使用中，慢慢調整、校準，最後才能成為真正適合自己工作流程的工具。
一個稍有工作經驗的活動人員會想什麼
這次做報到工具的過程，讓我重新意識到： 技術不是最難的，流程思考才是。
例如：
報到一定只能用網站嗎？能不能用 LINE 報到？
如果要用 LINE 報到，那報名階段就需要蒐集 User ID，該怎麼設計報名流程？
報到當下是學員最願意填資料的時刻，這時還能收什麼有用資訊？
目的和流程，只要有相關活動經驗的人來說都不難，但是 function flow 的設計，就會有很多需求還有場景的限制，同時，也要站在整體活動的角度來規劃
要用手機？生日？ email？姓名？來辨識學員？
哪些欄位資料容易重複（如同名同姓）？哪些欄位資料的可信性較低？
是否應該建立獨立的「學員編號」？
Vibe Coding 能幫你寫程式，但不能替你思考。 真正的難題永遠是在「寫程式之前」。
六角學院 21 天公益程式體驗營的心得
本來就有在接觸 Vibe Coding，但在自己摸索的階段，即使身邊有工程師朋友願意協助，仍常常感到卡關、焦慮 ── 不知道該學什麼，也不知道應該從哪裡開始。碎片化的內容、沒有路線圖的學習方式，讓我總覺得自己在原地打轉。
直到參加了 2025 GCG Taipei，聽到高見龍大大說的那句話 ──「AI 是能力的放大器，好習慣、壞習慣都會被放大。」我才重新理解：AI 放大的不只是技巧，而是流程習慣、思考深度，以及你在專業上願意堅持的程度。 這些本來就是我在原有工作領域中的基本功，只是以前沒有把它放在 Vibe Coding 時的思考脈絡裡。
這也是六角 21 天體驗營給我最大的啟發。
我重新把基本功補了起來：HTML、CSS、JavaScript，Git 與 GitHub，前後端的概念，也第一次在 Zeabur 上佈署自己的後端。之前的經驗都是在 Vibe Coding 之後，才意識到「啊，原來我需要這個」。基本功補上後，學習路徑變得更清晰，沒有那麼陡峭。
每天的任務與作業，都逼我多挑戰自己一點點。程式的基本練習，再一次與我過去做工具、做流程設計的習慣結合起來。這段靜下來扎實學習的時間，讓我又推進了一小步。
雖然痛苦，但非常快樂，也玩得非常開心。
最後
「活動報到小幫手」看起來是一個小作業，但它讓我第一次真正把需求釐清、流程拆解、與 AI 協作、PDCA 修正整個串起來。這也是我最喜歡 Vibe Coding 的地方 ── 讓我能把想法做成可以使用的工具。
如果你對 Vibe Coding 或 n8n 自動化有興趣，也歡迎聯繫我，讓我們一起把想法做成真正可用的工具。