分類彙整: AI 自動化工作流程

【實作案例】用 Notion + n8n + AI 工具打造「報名資料更新小工具」|Vibe Coding 專案紀錄

這篇文章,是我給未來某個跟我一樣「不會寫程式、但想解決問題」的你。

專案起點:從馬祖路跑報名的煩惱開始

一年一度的馬祖路跑即將開始,負責報名的我又得整理隊員們的個資。雖然馬祖路跑小隊已經成軍三年了,過去也有一些資料留存,但報名所需要的資料太多,手上的資料還是不夠齊全。而報名的資料中還有姓名、身分證字號等機敏資訊,如果直接請大家開啟共用的 Notion 編輯,那幾十個人就都能看到彼此的資料,對我來說曝露的程度和風險又有點高了,若是請大家私訊確認補資料,一次要追 10 個人,又好麻煩,這個煩惱,成為我開啟這次 Vibe Coding Side Project 的動機。

我能不能做一個只讓使用者看到自己資料的小工具,讓他們自己來更新?

解決思路:用 AI + 自動化工具做出自己的「資料驗證與更新工具」

以下是我原本就有在使用的 AI 工具,因為原本就有在使用,所以不算是這次開發的專案成本。

  1. ChatGPT Plus
  2. Claude Pro
  3. Zeabur 開發者版本(之前在講義活動時還得到了 5 美金的折扣碼,Zeaber 真的簡單好用,推推)
  4. n8n
  5. Noion Plus

在與 AI 討論之後,決定了以下的工具以及用途

  • Notion Database:作為後端資料儲存
  • n8n:處理資料比對與身份驗證流程
  • Zeabur:佈署前端頁面
  • ChatGPT + Claude:協助我撰寫程式、規劃架構與 Debug

在正式 Vibe Coding 實作之前,我做了什麼?

我完全沒有 PM 經驗,沒有實際進行過產品設計以及產品開發,若真說要有一點產品經驗的話,在幾年前參加過商業思維學院的產品經理學習營,也上完產品經理學程,過程當中對於產品有一點基礎的認識。

第一步很產品經理:盤點資源,搭建專案架構
如果需要一個方法論的話,我會說,請釐清以下三件事情

  1. 你想做的事情是什麼,你希望使用者怎麼用這個工具 (user flow)
  2. 你的能力到哪裡、目前有什麼工具可以使用
  3. 在這個專案當中,有什麼事情是絕對不可以退讓犧牲的

我個人覺得第 3 點尤其重要,發現 AI 如果不記得了,也要常常提醒他。以這個專案來說,就是「資訊安全」。

如何用 ChatGPT/Claude 開始 Vibe Coding?

在搭建專案架構的時候,我非常推薦使用 ChatGPT 而不是 Claude。如果平常大量使用 ChatGPT 時,在搭建架構以及技術規格時,ChatGPT 還能依據過往的記憶,推薦出比較適合的作法,非常貼心。

確認好架構、資源後,就能開始扮演甲方角色,請 ChatGPT 提案,只要用自然語言描述想要達成的產出就可以了。我一開始的 Prompt 也就只有:

我有一個 Notion Database,裡面有成員的基本資料。
我希望有一個介面,可以讓成員輸入姓名和身分證字號驗證之後,
確認資料是否正確,並補齊沒有填完的資料。
請給我幾種解法,說明每種所需工具與優劣比較。

此時 AI 會像 PM 一樣提 A、B、C 三種方案,記得請他說明

  1. 需要有什麼能力
  2. 簡述作法(我有說我不會寫程式,請用大學生的角度說明)
  3. 優點與缺點

記得,這時候都不要開始寫程式,先把 要怎麼做 搞清楚,後面會順利很多。

在 ChatGPT 提出做法,清楚說明各方案需要的技術、操作方式與風險之後,視自己的能力或需求,選擇合適的方案走下去,就可以了。當時我的 prompt 是:

我想試試方案三,我有 Zeabur,可以佈署網頁。你可以幫我規劃架構嗎?

這時,ChatGPT 神奇地記得我會用 n8n,還主動建議把驗證邏輯放在那裡,讓前端不碰敏感資料,完美!

在 AI 給架構之後

不要直接相信 ChatGPT!!

這個階段要從甲方的角色轉變為 PM 角色,和 ChatGPT 一起開發。對話當中所有看不懂、無法理解為什麼的東西或流程, 一定要請他用各種方式解釋清楚,就算用童書繪本風格也可以。身為 PM 你一定要知道你要去哪,要怎麼去,不然 AI 工程師只會做白日夢,開始胡言亂語。

一切都沒有問題之後,按照他的步驟執行(或者你請他給流程清單,就一步步照做)。

以這個 side project 來說,要進行的步驟就是

  1. 設定 Notion API,並且在資料庫中 integrate
  2. 設定 n8n
  3. 在 Zeabur 佈署前端網頁

從網路上的分享還有我自己的經驗, ChatGPT 寫網頁很醜,所以我打算先從後台開始,前台打算之後轉移到 Claude 繼續。

記得每一個節點都要設測試,避免 AI 幻覺,不然做到最後發現他在胡說八道導致白做工,真的是會很生氣。

中間不斷地 設定→測試→修正,到都完成的時候,和 ChatGPT 說

整理一下目前的討論,我想換到 claude 上請他繼續

就能順利轉移了。

以 ChatGPT + Claude 完成首個 Vibe Coding 專案

這個月因為工作的關係付了一個月的 Claude 訂閱,終於可以吃大一點的檔案,Claude 對話窗的長度沒有短到像明天就要世界末日,說完需求後直接生出一個改都不用改的 html 檔,超神!(我額外有給 n8n workflow 的 json 檔,但好像沒有用到)

但這也是如果使用免費版開發上的限制,雖然 Claude 的程式碼品質非常好,但一個對話窗能夠使用的額度太低,加上還要幫新對話補充專案資訊,常常兩三次來回之後就要另開新對話。
󠀠
後期因為後來額外想顯示資料庫的資料,讓大家可以用核對而不是新增的方式確認,也是在 Claude 上就 n8n 的設定又來回了一陣子。

󠀠和上一段的過程差不多,但明顯 Claude 雖然也有亂講話的問題,但他給的內容的正確性很高,所以解決得都蠻快的
󠀠
最後測試一下,無論是測試帳號還是我自己的資料都可以正常使用

完成!

後續延伸應用與反思

目前這個專案已功成身退,畢竟就只是讓隊友們對一下報名資料而已。不過後來想想,不管是課程系統、預約系統
好像後續都可以再繼續發展下去。

於我自己來說,有另外一個新的目標想做,沒有什麼特別的契機的話,這 side project 就這樣結束。

在做完這個專案之後,和朋友們討論了一下 Vibing Coding 對我而言是什麼。我一開始其實覺得蠻新奇有趣的,看著很多人的成品覺得原來是有機會做到這件事,然後覺得很有趣!有機會也想來試試看。

在這次的 side project 之後,更像是覺得取得一個「自己做小工具來解決自己的問題」的能力,不是要取代工程師,而且多了一種解決問題的方法,覺得自己又多會了一點點東西,這種能夠實現自己的想像的感覺很好。

我不會說需要什麼才能開始,也不會說我 AI 玩得多厲害,關於如何學習 Vibe Coding 這件事,有大神幫我說完了

如果問我,如何能夠走出這一小步,除了自己喜歡玩玩具之外,不可獲缺的是案例,各式各樣、各行各業的案例,這也是為什麼每一次我都想在 Facebook 記下自己 side project 過程的原因。我不是一個有創新能力的人,但我是一個抄作業抄得很好的執行者,也希望我稱之為還在 #VibeCoding 危樓的程度下的經驗,成為未來某人的養份。

如何利用 Make.com 打造 Email 電子發票自動報帳系統

每個月,公司都會有不少電子發票需要處理,特別是由老闆轉寄過來的各式電子帳單。從下載附件、上傳至指定的 Google Drive、填寫帳務資訊到 Google Sheet 報帳表單,這些步驟繁瑣而耗時,且具高度重複性,處理起來經常令人煩躁。

作為一名經常需要處理行政事務的工作者,我決定以這個流程作為自動化工作的起點,希望節省時間、提升效率,並將這項成果作為我工作流程自動化的作品集。

我是如何規劃這個自動化流程的?

一開始,我認真地畫出了一個「我以為」的報帳流程,這個步驟相當重要,因為我們常常低估了人腦在進行任務時的自動化程度。一些看似簡單、甚至無意識完成的步驟,反而會成為自動化流程中的重大障礙。

舉個最明顯的例子,就是電子發票的檔案命名。我習慣使用以下格式命名單據:

報帳年月_部門_科目_項目_金額_發票號碼

這個習慣能讓我快速找到需要核對的檔案,但對自動化而言,這意味著工作流程需要取得日期、部門分類、科目、項目、金額與發票號碼這些資訊。對人類來說,這只是「看一眼收據」的事情,但對工作流來說卻是一連串的精細步驟。

實際的工作流架構

經過多次重構與 AI 討論後,我最終確定的自動化流程如下:

  1. 查看 Gmail 中特定寄件人的信件
  2. 使用 Claude API 分析附件中的 PDF 檔案,直接提取文本內容
  3. 產生 JSON 格式的報帳資料
  4. 將附件自動上傳到指定 Google Drive 資料夾
  5. 自動生成 Google Drive 的檔案分享連結
  6. 將報帳資料和檔案分享連結一併回填到 Google Sheet
  7. 將處理完的電子郵件標記特定標籤並封存

報錯機制

這個流程當中,難免會出現一些狀況,比如遇到發票檔案需要密碼才能開啟,這時 Claude API 就沒辦法正確分析內容。為了避免因此漏報,我設計了一個簡單的報錯機制:當 Claude 無法處理檔案時,系統會自動傳送通知到 Slack,提醒我需要手動處理這筆帳單。

之所以選擇 Slack,而不是 Email 或其他通訊工具,是因為我的日常工作幾乎都在 Slack 上進行,這樣不需要額外切換視窗或監控其他平台,也比較不容易漏掉提醒。

AI 工具的選擇與使用心得

在整個開發過程中,我主要使用的是 ChatGPT,因為付費版的 ChatGPT 能夠提供深入且高效的討論。但在實際分析 PDF 文本的環節,我最終選擇了 Claude API,原因在於它能直接處理 PDF 文字內容,而 OpenAI 和 Google Gemini API 雖然知名且廣泛使用,卻需要額外將 PDF 轉換成圖片才能進行分析,對我而言多了一道工序,降低了自動化流程的效率。

在探索的過程中,ChatGPT 提供了許多建議,但也曾經「騙」過我,讓我嘗試許多最終不可行的方法,這導致我意外地學了不少用不上但卻有趣的新技能,例如 JSON 格式的撰寫及 Google Cloud API 的使用。

社群與專業工程師協作的重要性

在過程中,當我遇到無法解決的問題時,幸好有加入幾個專門討論 AI 工作自動化的 LINE 社群(如知識倉鼠、偷懶辦公室)。這些社群中有許多熱心且專精的大神,當我卡關時只要在群組內求助,很快便能得到有效解法,極大地節省了摸索時間。

自動化成果與效益

經過 8 小時的努力後,這個報帳自動化流程已經順利上線了。現在每當老闆再寄電子發票來,我再也不用花費大量時間手動處理,流程變得順暢且有效率。

至於成本,整個自動化過程僅使用 Claude API 處理 4、5 月份的發票,費用僅花費 0.33 美金(約 10 塊台幣),大幅節省了原本需要耗費的時間成本。

未來優化與下一步計畫

未來,我希望能持續優化這個流程,包括加入照片報帳、擴充處理國外 invoice 並自動換算台幣的功能(這部分其實我已經在這次流程中透過更新 Claude API 的 prompt 初步完成了),並進一步延伸到其他紙本帳單的自動化處理。

此外,這次經驗也提醒了我,這些靠著「無章法學習」獲得的新知識,其實我並不算真的熟悉,雖然看起來完成了自動化流程,但未來維護時還是可能要重新摸索一遍。因此還是得乖乖整理成完整的專案筆記,才不會讓自己每次維護都像初學者一樣手忙腳亂。

透過這篇文章,我希望能夠幫助新手或經常處理行政事務的秘書朋友們,更清楚地了解如何建構工作自動化流程,並嘗試實踐於自己的工作場景中。這次在社群貼文分享之後,甚至還有人詢價,讓我小小驚訝了一下。如果你剛好也面臨類似的行政困擾、對自動化流程感興趣,或許我們也可以聊聊,看看能不能一起把工作變輕鬆一些。

我的 Email 信箱 hi@iamstellala.me

AI 寫程式後的復盤與反思

幫公司寫的打卡機器人功能已經正常運作了 2 週左右,差不多也是來做心得總結的時候,一個完全不懂程式的文組小祕書,如何利用 AI 協助寫程式,當中又遇到了什麼困難,最後是我的心得感想。

規格說明:我的資訊能力還有背景

身為一個文組人,我的日常工作和程式設計從來沒有交集,和程式碼稍微像一點的,就是我很會寫 Excel 的公式
󠀠
不過要說完全沒有程式基礎可能也不太對,雖然看不懂程式語言,但在資訊素養與認知,可能還是高於平均。

和 AI 一起寫程式,專案開始

從今年的 AI 年會看到薩泰爾的分享,還在 AI 社群讀書會當中,許多像我一樣沒有技術背景的文組小夥伴,利用 AI 完成了許多功能實用的小工具和專案,看著這些案例當下超級興奮的,也想著:「或許我也能試試看寫個什麼?」
󠀠
一開始我以為我會寫什麼「合約產生機器人」之類的,也想過自己的日常可以作一些什麼,不過從「想法」就開始卡關,一來是我想不到我有什麼事情需要特別寫個 AI 來處理,而不用現用的工作流程或者工具就好?其次是眼界不夠開闊,我缺乏想像,沒有辦法想出「原來 AI 可以這樣應用」。
󠀠
很有趣的事情就是,還是回到產品營的第一個訓練 ── 為什麼要做一個產品?其實到最後這些產品是為了要解決問題,那麼現在有什麼問題要解決?剛好公司需要解決將大家在 Slack 上的打卡紀錄抓下來匯總成冊、保留 5 年這個問題(感謝勞動部…),如果都用手動就真的太蠢了,於是小專案就出現了。

專案過程的困難

看了幾個案例之後,我想著,前輩們的東西拼拼湊湊應該不會太困難,所以我決定用 AI 幫助開發一個 Slack 的打卡機器人,功能其實也很簡單,就是抓取 Slack 特定頻道的打卡訊息、人名、上/下班卡別、訊息時間,都寫入 Google Sheet 裡,後來還自己加了 Slack 的 定時發送「缺卡通知訊息」,這兩個功能就構成了我的出缺勤紀錄機器人。
󠀠
這個想法看似簡單,但過程卻真的是重重難關。一開始依照 ChatGPT、Claude、Perplexity 的教學設置 Slack 機器人的時候,就遇到權限問題,機器人無法正確啟用並且加到 Slack 頻道裡,後來是靠著三方比對,把問題問得更深入,在 Perplexity 的延伸問題中,才找到蛛絲馬跡。
󠀠
好不容易完成了「抓取上/下班打卡紀錄」這個功能時,又發生了日期無法 match,所以打卡紀錄每次執行都會新增一筆當天相同的資料而非更新當天的上/下班打卡紀錄,和 AI 互動到最後差點翻桌,直接 call out 求助,還順便 code review。事後我詢問了程式好朋友,為什麼會有這個問題,他告訴我,因為寫入 Google Sheet 之後,原本的日期就不是我們眼中看到的資訊了,他的格式除了 yyyy/mm/dd 以外,還會有時區、經緯度…等等,所以 AI 在抓資料是一比對,就覺得今天還沒有資料啊,自然就繼續新增,而不是更新現有資料了。要解決不難,就是在更新資料要重新判讀原有的日期欄位,但幾經嘗試一直失敗,所以我劍走偏鋒,直接改為每次抓資料時都直接砍掉重抓,反正 30 天的資料而已,還能忍受。
󠀠
最後,我完全沒有想到,最大的挑戰來自後續的提醒功能。我希望機器人能在中午 12 點還有晚上 8 點,提醒當天沒有打卡的同事記得補打卡,我原本以為,我都有打卡紀錄的資料了,不就是照著這個結果,發提醒訊息而已,是有多難?結果卡關卡最久就是這裡!
󠀠
而最煩且煩讓人沮喪的問題是 AI 寫程式最底層的問題。三種功能其實都陷入相同的困境,原先這三大功能都是在同一個 Google Apps Script 的腳本中,每當我請 AI 修正或者調整錯誤的部份,它會重寫整段程式碼,錯的不一定改成對的,更煩的是它會覆蓋掉之前正確的部分,有時候還會不小心刪除部份程式碼。這種反覆修改的過程既耗時又令人煩躁。

解決問題靠得反而是專案管理經驗

AI 這種反覆修改是無常的,他的本質上是一個抽卡,什麼時候抽到 SSR 完全靠運氣,而且也因為版本太多,每一天在金魚腦上床睡覺前,都要決定要退回哪一個版本,才能繼續穩定提升品質,所以最後,我開始請 AI 依據我的檔案命名原則,加註 log,方便版本控管。
󠀠
另外,反覆修改之下,每次都要重新測試所有功能是否正確,沒有被改到錯的,真的太累人了。有一天我靈光一閃想起以前專案管理的時候,我是用模版來處理各種活動,也會用專案 dashbaord 來匯總所有檔案與資源,所以又開啟了一個對話,和 AI 討論塊組化還有整合調用的作法以及可行性,每一次只專注一個功能,抓記錄就抓記錄、抓名單就抓名單、Slack 訊息就只寫 Slack 訊息,然後再用一個中樞管理檔案去調用,從一個大腳本拆成 6 個小腳本,才開始把產出的品質穩定下來。
󠀠
雖然最後真的寫出來了,這段經歷讓我重新思考:使用 AI 來寫程式,真的有效率嗎?我們是否應該走這條路?一開始興致勃勃時大概花了 3 小時左右寫出了抓取上/下班功能的腳本,但實際整個專案完成,應該耗費了 5 倍以上的時間(我猜應該 20 小時),若不是當作一個新工具的嘗試,這 20 小時拿來上個班,我都可以多完成 1 週的進度了。

那文組人應該開始與 AI 協作,一起寫程式嗎?

󠀠
這是一個沒有標準答案的問題。但從我的經驗來看,這值得嘗試。AI 確實降低了寫程式的門檻,它讓像我這樣的非技術背景者也能做出實際可用的工具。但同時,它也揭示了一個重要的事實:AI 並不是萬能的。在設計複雜功能時,仍然需要邏輯思考和耐心。
󠀠
這樣的嘗試讓我學習到的事情是,就算邏輯給得再清楚,AI 都不見得第一次就成功。我當時的 prompt 連決策樹都給了,第一版的完成度也只有 60% 左右。如果 prompt 連這種架構都沒有,AI 在釐清需求這塊應該要更多的時間。我也是沒想過,產品營學到的釐清需求這個練習,會用回自己身上(笑)
󠀠
以前,我對程式還有技術,一直抱持著「交給專業的人來完成」這個想法,完全符合經濟學的比較利益原則,這個想法現在依然沒有變,在自己動手嘗試後,我更能理解,程式的開發需要考量的不僅是功能本身,還有邏輯結構、效能優化,甚至是版本管理。就和一開始我就知道 AI 無法取代小蜜的功能一樣,AI 也無法取代工程師。我可以請 AI 寫出 6 個檔案,將近 800 行的程式碼來解決一個小問題,但厲害的工程師可能 100 行以內就可以解決了(之前那份 code review 過的腳本,真的是讓產出穩定非常非常多)。

如果還是想要試著寫寫看

以工具來說,Google Apps Script 還有 Chrome 外掛依然是最好入手的地方,但我覺得最重要的是學習了如何站在工程師的角度去看待問題,還有怎麼去用工程師的邏輯結構(至少是「有邏輯」)去描述需求給 AI 聽
󠀠
其次,接受技術限制,找出解決辦法。AI 工具的侷限讓我認識到,AI 寫程式不可能一步到位。與其執著於完美,不如先完成最小可行版本(MVP)。然後,直接找大神幫忙 code review 或者調整。我覺得站在文組人還有工程師的兩種角色來說,這是 AI 能夠幫上最多忙的地方。我們可以先簡單呈現我們想要的是什麼,在 AI 足夠清楚的註解之下,工程師夥伴也可以快速找到要處理的地方,快速拉齊彼此的認識,省下時間,一起前進。(突然想起峰值體驗,老師的節點有種成功耶
󠀠
最後,一定要做完整的記錄與版本管理。在反覆修改腳本的過程中,版本記錄的重要性變得更加重要,在找程式好朋友協助時,清楚的文件與版本控制也可以節省很多溝通成本。

我還會不會再寫?

也許會吧,案例看得愈多,也還是會覺得可能性好大,也會想試試看。AI 讓寫程式變得更容易上手,但它並不是完美的工具,很多細節仍需要手動調整。
󠀠
不過下次會把範疇再縮得更小一點點,讓成就感早點來,也不會覺得有 AI 什麼事都可以辦得到,AI 是工具之一,重點是選對工具、提升效率,而不是「想辦法用 AI」。那是學習的過程,不是策略與產出。

AI 寫程式番外篇

這篇是用 ChatGPT 的對話模式寫的,雖然他寫出來的東西爛透了,我大概改了 70% 以上,但用訪談的方式可以講出很多沒有想過的心情,有人打稿也解決了我懶得從頭寫又拖延症的這個問題,而且又嘗試了一個 AI 功能,真的是一舉兩得~