在學習 Vibe Coding 的過程當中,在好友圈發起了一個 Side Project 計劃,好朋友們提供題目,我試著用 Vibe Coding 來實作,二代學團服訂購網站就是第一個和好友協作的作品。
使用的工具
Google AI Studio 的 Build apps with Gemini(免費)
Google Gemini API(免費)
Google Cloud Platform 的空間(付費)
這次比較多的學習主要在新手小白第一次使用 Google Cloud Platform 去佈署網頁。剛好當時發生了知名講師 API 事件,讓人緊張又害怕。
製作內容、過程與費用
團服訂購的前台:React,不過原則上我都是讓 AI 跑的,沒有特別指示要用什麼程式語言 團服訂購的後台及資料庫:包含訂單名單、庫存統計、銷售報表,都是串 Google Sheet 網站的前台由 React 架構生成、後台串接 Google Sheet,負責接收訂單、統計庫存與製作銷售報表。整體架構都由 AI 撰寫程式,我僅提供流程與設計方向。若要形容這個網站,我會說它比較像一個漂亮的 Google Form,但具備簡單的交易邏輯。 整個開發過程大約是兩小時。其實最主要的時間是花費在和好友討論 user flow 還有他期待的銷售流程。
原則上都以 AI 對話指令完成設計、部署及串接,從 9/23 開發上線到 10/4 關站收單,AI 對話、佈署、雲端伺服器總成本約新台幣 1 元。收費還在新手村武器店的朋友友情價 —— 兩杯星巴克,但這次玩玩具的價值是這個 Side Project 讓我重新理解了「開發」與「規劃」之間看待事情的視角不同。
部署不是結束:從雲端成本到資安意識
剛好這次的時間遇上了知名的 API 事件,所以特別請教了 AI 還有真人工程師關於 Google Cloud Platform 種種問題,很可惜的是,AI 問答的錯誤率很高,大致上略略懂了一些概念,但學習地圖建的不是很紥實;其次是這很吃工程師的經驗,身邊剛好沒有重度使用者,所以也只是很淺碟的問了問。有件事我後來覺得那位 AI 講師說得一件事有點道理:「Google AI Studio 的 UI 設計來說並沒有做得很好」,他在「下架」這件事上,是很 1 或 0 的,deploy 之後如果不是像我一樣,大致上知道怎麼關站,通常都只有刪除專案一途,對於完全不懂程式的人就有點不太友善。
無獨有偶,Google AI Studio 也在不久之後更新了 API 的頁面,可以觀看專案的用量,友善很多。
這次也有被提醒,因為網站只在私域內部流傳,所以資安方面沒有做得太好,如果有惡意攻擊什麼的,應該是會撐不住,下次也許在一開始和 AI 溝通需求的時候,會再把資安的需求加入,這裡就是屬於「我不知道我不知道」的地方,還需要多加學習。
依據我模模糊糊的理解,應該是每一次 deploy 之後就會上傳一個備份,剛好這個銷售頁大大小小改十幾個版,這在我自己其他的作品中很正常,但是在用 Google AI Studio 時,每一次改版重新 deploy 就會上傳一個備份,每天會固定花 50% 左右的費用在存這些備份檔,所以後來網站穩定後,就把前面初期的備份刪掉了,Cloud Storage 就沒花太多錢。
從使用者思維到開發者思維的轉換
這大概是我後知後覺,覺得這次最有價值的學習。
以前都是當前台的企劃或者 Planner 比較多,所以不會考量到 if else 甚至是更裡層的問題。
像這次一開始的需求,就是單純做一個一頁式的銷售頁,提供給群組團員們訂購團服,所以當下 AI Coding 完網站,搭配一頁 Google Sheet 的銷售表單後,就上線了。
這個階段要從甲方的角色轉變為 PM 角色,和 ChatGPT 一起開發。對話當中所有看不懂、無法理解為什麼的東西或流程, 一定要請他用各種方式解釋清楚,就算用童書繪本風格也可以。身為 PM 你一定要知道你要去哪,要怎麼去,不然 AI 工程師只會做白日夢,開始胡言亂語。
一切都沒有問題之後,按照他的步驟執行(或者你請他給流程清單,就一步步照做)。
以這個 side project 來說,要進行的步驟就是
設定 Notion API,並且在資料庫中 integrate
設定 n8n
在 Zeabur 佈署前端網頁
從網路上的分享還有我自己的經驗, ChatGPT 寫網頁很醜,所以我打算先從後台開始,前台打算之後轉移到 Claude 繼續。
記得每一個節點都要設測試,避免 AI 幻覺,不然做到最後發現他在胡說八道導致白做工,真的是會很生氣。
中間不斷地 設定→測試→修正,到都完成的時候,和 ChatGPT 說
整理一下目前的討論,我想換到 claude 上請他繼續
就能順利轉移了。
以 ChatGPT + Claude 完成首個 Vibe Coding 專案
這個月因為工作的關係付了一個月的 Claude 訂閱,終於可以吃大一點的檔案,Claude 對話窗的長度沒有短到像明天就要世界末日,說完需求後直接生出一個改都不用改的 html 檔,超神!(我額外有給 n8n workflow 的 json 檔,但好像沒有用到)
但這也是如果使用免費版開發上的限制,雖然 Claude 的程式碼品質非常好,但一個對話窗能夠使用的額度太低,加上還要幫新對話補充專案資訊,常常兩三次來回之後就要另開新對話。 後期因為後來額外想顯示資料庫的資料,讓大家可以用核對而不是新增的方式確認,也是在 Claude 上就 n8n 的設定又來回了一陣子。
和上一段的過程差不多,但明顯 Claude 雖然也有亂講話的問題,但他給的內容的正確性很高,所以解決得都蠻快的 最後測試一下,無論是測試帳號還是我自己的資料都可以正常使用
在整個開發過程中,我主要使用的是 ChatGPT,因為付費版的 ChatGPT 能夠提供深入且高效的討論。但在實際分析 PDF 文本的環節,我最終選擇了 Claude API,原因在於它能直接處理 PDF 文字內容,而 OpenAI 和 Google Gemini API 雖然知名且廣泛使用,卻需要額外將 PDF 轉換成圖片才能進行分析,對我而言多了一道工序,降低了自動化流程的效率。
在探索的過程中,ChatGPT 提供了許多建議,但也曾經「騙」過我,讓我嘗試許多最終不可行的方法,這導致我意外地學了不少用不上但卻有趣的新技能,例如 JSON 格式的撰寫及 Google Cloud API 的使用。
社群與專業工程師協作的重要性
在過程中,當我遇到無法解決的問題時,幸好有加入幾個專門討論 AI 工作自動化的 LINE 社群(如知識倉鼠、偷懶辦公室)。這些社群中有許多熱心且專精的大神,當我卡關時只要在群組內求助,很快便能得到有效解法,極大地節省了摸索時間。
好不容易完成了「抓取上/下班打卡紀錄」這個功能時,又發生了日期無法 match,所以打卡紀錄每次執行都會新增一筆當天相同的資料而非更新當天的上/下班打卡紀錄,和 AI 互動到最後差點翻桌,直接 call out 求助,還順便 code review。事後我詢問了程式好朋友,為什麼會有這個問題,他告訴我,因為寫入 Google Sheet 之後,原本的日期就不是我們眼中看到的資訊了,他的格式除了 yyyy/mm/dd 以外,還會有時區、經緯度…等等,所以 AI 在抓資料是一比對,就覺得今天還沒有資料啊,自然就繼續新增,而不是更新現有資料了。要解決不難,就是在更新資料要重新判讀原有的日期欄位,但幾經嘗試一直失敗,所以我劍走偏鋒,直接改為每次抓資料時都直接砍掉重抓,反正 30 天的資料而已,還能忍受。
而最煩且煩讓人沮喪的問題是 AI 寫程式最底層的問題。三種功能其實都陷入相同的困境,原先這三大功能都是在同一個 Google Apps Script 的腳本中,每當我請 AI 修正或者調整錯誤的部份,它會重寫整段程式碼,錯的不一定改成對的,更煩的是它會覆蓋掉之前正確的部分,有時候還會不小心刪除部份程式碼。這種反覆修改的過程既耗時又令人煩躁。
解決問題靠得反而是專案管理經驗
AI 這種反覆修改是無常的,他的本質上是一個抽卡,什麼時候抽到 SSR 完全靠運氣,而且也因為版本太多,每一天在金魚腦上床睡覺前,都要決定要退回哪一個版本,才能繼續穩定提升品質,所以最後,我開始請 AI 依據我的檔案命名原則,加註 log,方便版本控管。
另外,反覆修改之下,每次都要重新測試所有功能是否正確,沒有被改到錯的,真的太累人了。有一天我靈光一閃想起以前專案管理的時候,我是用模版來處理各種活動,也會用專案 dashbaord 來匯總所有檔案與資源,所以又開啟了一個對話,和 AI 討論塊組化還有整合調用的作法以及可行性,每一次只專注一個功能,抓記錄就抓記錄、抓名單就抓名單、Slack 訊息就只寫 Slack 訊息,然後再用一個中樞管理檔案去調用,從一個大腳本拆成 6 個小腳本,才開始把產出的品質穩定下來。
寫到這裡,不禁開始想,這樣 AI 能夠起到什麼效果?AI 可以幫我們快速產出各種個人化的社群文章、文章不假,甚至也與文章中的「工作效率及營運效率的提升,也可帶來成長」這一點相符,但偶爾我的內心還是會有一種「這真的是他們的所思所想嗎?」「AI 這些文章與評論,究竟有什麼意義呢?」這種想法,內心柔軟的我還是很在意這些文章是否真心,但職場上的我,看得更多的是,那些客戶其實也沒有什麼想法,多數是「不反對」,而不是熱情,這種「工作效率提升」也許在工作上是必然,但同時也更希望客戶們也和公司一起關注這些社會議題,讓好理念被看見。
說來也有趣,2 年前在商思學習的時候,跟了個風成立了個人的部落格,但其實我並不覺得做祕書的這些瑣事有什麼分享的價值,所以後來棄坑,部落格草長得老長。後來進了廣告代理商,再轉往品牌行銷領域當特助,當然也知道個人品牌的重要,只是工作更忙,忙著做客戶的個人品牌,也更無暇來管自己的部落格。不過每到三節送禮期間,部落格就會迎來一批爆炸性的流量,通通都是透過 Google Search 找「名片怎麼貼」這個關鍵字來的,看來這個問題實在是不小,也讓我感受到無形的敲碗壓力,哈哈。
不過近幾年,禮盒的設計愈來愈複雜,我就會以盡量不傷害禮盒設計的方向為主(畢竟禮盒美美的,對方收到也開心),再來看看可以貼在哪一個角落或者空位。但如果四個角落有空間的話,還是優先貼角落,千萬不要往中間貼。今年收到一個阿默蛋糕的禮盒,直接把送禮者的名片貼在正中,緊鄰著 Amo 的 LOGO,不知道的還以為兩位合作夥伴是 Amo 的股東…
最近 AI 在 ChatGPT 還有 MidJourney 引領之下,變成了一個全民話題,我嘗試了一陣子之後,也覺得蠻好玩的,也學了一點 AI 詠唱。每一次新科技出現,就會有更多的職業焦慮,還有引發職業焦慮的言論,像是 AI 以後會取代掉翻譯、祕書…等,我不覺得我有資格可以大放闕辭,但可以從我最近的觀察來說起。
AI 可以幫忙做投影片了!以後不用做 PPT 了!真的嗎?
ChatGPT 開始一波 General AI 的浪潮,AI 開始會對話、寫文案、創作故事文本…等,所以請 AI 做投影片這個服務,也如雨後春筍般一個個誕生。就先不論 AI 資料的正確性,我相信這個問題終於會在人類大量餵養、機器大量學習之下解決,不過 AI 生成的投影片對我們到底有沒有幫助,倒是一個可以可以觀察的角度。
在繼續這個話題之前要先聲明,這篇文章沒有要針對誰或者哪一個粉絲專頁,只是前幾天流感病中剛好看到相關的議題分享,所以我在 Facebook 特地標記了起來,想練習實作。相反來說,還是要感謝各路大神開發 AI 的各種可能性。
幫老闆做旅遊計畫要考慮的,其實和自己出去玩沒有什麼兩樣,只是要注意同行者的毛可能很多,而且又不能得罪,不像是自己家人或者朋友,知道我強勢,往往都會讓著我一點。撇開機票、住宿不先談,景點選擇、安排景點的前後順序、如果下雨有沒有雨備、景點重點特色、歷史脈絡、需不需要購票、哪些景點必看、景點的停留時間、需要不要安排導覽人員…甚至是有沒有網路訊號等等,當中有很多小小又煩雜,但是安排好老闆會很順心的事。像這種這種 Google 或者問 ChatGPT 就有的景點 data,連 information 都稱不上。
其實可以在輸入 prompt 時指定他生成繁體中文的檔案,而每頁的投影片也都可以再進行編修,不過目前應該是只能利用 tome 分享,無法下載投影片,但我想產品迭代下去,很快就能夠下載 PDF 了吧。
利用 AI 生成投影片的實用性,AI 真的能取代祕書嗎?
這種 AI 生成的東西到底有沒有用,也許有吧,但我想更有用的是我腦海裡密密麻麻要幫老闆做事的任務系統。
AI 想取代祕書?從打字機時代到電腦時代,祕書或者特助這個職稱一直存在著,凡存在就代表這個人、這個角色,始終一直被需要,只是在時代推移、科技進步之下,職務內容隨著老闆的需求調整後,愈來愈複雜了而已。對於我來說,祕書是 problem solver,是老闆的第二大腦,AI 可以處理已知,但處理未知還有與老闆協作的能力才是祕書的價值,所以也可以說,學得不夠快,不懂得幫自己加值的人,才會被取代,不管哪一個行業,我想都是亦然。
而 AI 生成的投影片到底實不實用,其實就要回到投影片的目的是什麼。依照劉奕酉老師在簡報課中的說明,我們可以將簡報分成工作型簡報、展演型簡報以及提案型簡報,但不管是哪一種簡報,目的其實都是為「解決問題」。在這個層面,我又把解決問題分為兩個層面「溝通」以及「行動」。「溝通」是希望透過簡報,讓簡報的讀者或者參與會議的人,和我有相同的共識;「行動」則是希望透過簡報,能夠擬定下一步的行動方針。
所以注意到了嗎?簡報當中最重要的地方,是身為「人」所能提出的見解、行動方案還有執行的能力,這些都是 AI 目前遠遠所不能及的。把 AI 當成工具,積極去擁抱他所帶來的優點,同時也不固步自封,透過持續學習幫自己加值,就會是一個難以取代的人。我想,祕書在這裡更有優勢的地方,就是我們早已養成各種想辦法、找工具,還有釐清老闆需求的習慣,所以也不用過度憂慮,把 AI 帶來的轉變,當作是裝備升級的武器,加化我們 problem solver 的能力。
題外話,自從行銷大神開了 《ChatGPT 生活運用》 群組之後,我其實觀察到很多堪稱社會實驗的社會跟風現象,像是把 AI 校調整寶寶、渣男、海女、蘿莉控…等,甚至是要 AI 表現出「老婆說的永遠是對的,1+1=3」,我們一邊在大肆批評 AI 的資料錯誤連篇,但又不停地拿錯誤的資料餵養他,人類真的是很神秘又充滿惡意的生物。
後來我很認真去復盤到底我哪裡沒有做好,導致我和老闆的想法沒有對齊,有很大的因素,我沒有在老闆的意見當中察覺到他的心理需求和對專案的預期是什麼,而老闆都對專案成功要有什麼成果也沒有概念,只是覺得這件事情應該要有人做,此時我就該有心理準備,這個專案不是老闆最主要的 priority,他想進行這個專案,可能只是為了心理需求而已。而事後我觀察 Data team 的 planner 的提案,他們就可以很容易地和老闆切出各階段的交付物還有交付日期,我想是很好的佐證。但實際層面上,遇到上述對利害關係人或者主管、老闆都是「重要但不緊急」的專案,什麼都想要但又都說不清楚的情況,要怎麼進行(或者拒絕)我還是沒有一個很好的辦法。
之前的工作內容完全沒有接觸過用戶訪談,在學習營中我也常常和同學們說,我真的對人沒有什麼好奇心,我不知道該怎麼聊下去,讓我知道用戶到底是怎麼想的。經過了三次的訓練,我有明確的察覺到我訪談技巧上進步很多,除了訪綱的內容之外,我會去關心用戶的目標、為什麼用、為什麼不用,用與不用背後的決策依據是什麼,而這次更是貫徹了觀察用戶實際使用產品的情況,為了避免當下腦內一片空白,實際使用上我也都設定好用戶要完成的任務,以及如果第一次沒有完成任務時,我要給的說明與提示,這些在後來收斂用戶的痛點時,都讓我們擬出的 User Journey Map 更有所本。
最近剛好在討論職涯發展的困境,所以對於提案細節的完整度也特別有感。第一次參加學習營的時候,要看課程、寫作業,還要完成每週學習營的任務,焦頭爛額又被自己實務經驗的匱乏所限制,所提出的產品設計其實很粗糙,不過當中有一個亮點是,我把小組中所有人的產品用策略串起來,成為一個 Me Now 宇宙,在 Me Now 宇宙中,用戶可以使用公司不同產品線的產品,達成各方面「好好生活」的核心目標。雖然完全脫離了產品解,但我還是很喜歡當下策略腦整個爆發的那一刻,串起來的時候心裡的滿足感塞滿整個胸腔。