一、同一件事，我後來發現至少有五種做法

開始做自動化沒多久，我就撞上一個問題：同一個需求，擺在我面前的做法從來不只一種。

把一封通知信轉成日曆提醒，可以用 Google Apps Script 寫三十行搞定；也可以用 Python 寫一支程式，架一台機器讓它整天開著跑；也可以直接去 Zapier 串一條，三十美金一個月，什麼都不用寫。三條路都能到終點，但成本、維護方式、將來會卡在哪裡，完全是三個世界。

一開始我每次都是想到什麼工具就用什麼，後來吃過幾次虧——用錯工具做出來的東西，通常不是做不出來，是做出來以後沒人維護得動。所以我花了點時間，把手上會用到的工具各自的守備範圍想清楚。

二、五種工具，各自守住哪個位置

想清楚之後，其實沒有想像中複雜，大致分成五種。

這張表我後來常常拿出來對照。遇到新需求，先看它落在哪一格，而不是先想「我最近比較熟哪個工具」。

三、真正該先問的，不是工具，是對方有沒有 API

表列出來之後，選工具反而變簡單了，因為前面那道問題比工具本身重要得多：對方有沒有開放 API？

有 API 的事，不管用哪個工具都輕鬆——資料乾淨、格式固定、串起來就是搬資料的問題。沒有 API 的，不管我多會寫程式，都得靠 Playwright 這種方式硬闖網頁介面，而且要準備好對方隨時改版、隨時多加一道驗證機制的心理準備。這是完全不同量級的投入。

問完有沒有 API，我接著問的是這件事要不要開放給別人用——只有我自己用的小工具，一支能跑的程式就夠；要給同事、客人用的，就得包成一個網頁或服務。最後問這件事要不要長期一直跑下去，還是做一次就結束——長期跑的，才值得花時間搭基礎建設；一次性的，寫完就丟也沒關係。

三個問題問完，答案通常已經很明顯了，不太需要再猶豫。

四、AI 該放在哪一層，我也是後來才想清楚的

做久了之後，我發現有一條界線特別重要：AI 負責判斷跟生成，不負責搬東西。

判斷客人詢問符不符合服務範圍、生成一封回信草稿、從一張圖片辨識出報價數字——這些需要理解與生成的事，AI 做得比我寫規則好太多。但把一封信從收件匣搬到另一個資料夾、把一筆資料從試算表寫進另一張表，這種純粹的搬運，我一律交給確定性的程式碼，不假手 AI。

原因很簡單：搬運這件事本來就有標準答案，程式碼做起來又快又穩、還不用付 token 費用；一旦讓 AI 去做搬運，反而多了一層不必要的不確定性——它可能會漏、可能會重複、出錯了還不容易查。這條分工原則，我後來在每一個系統裡都在用。

五、一個選錯又選對的真實例子

會議室預約系統是我一開始想錯工具的案例。

那是一個「收到一封信，自動去公司內部的訂房系統下訂」的需求，我原本理所當然想拿 Zapier 串——結果一查才發現，訂房系統的頁面內容藏在一層層巢狀的 iframe 裡面，Zapier 那種靠固定介面操作網頁的方式根本進不去。

後來換成 Apps Script 搭配 Playwright 才解決：Playwright 可以直接鑽進那層 iframe，找到系統背後真正在跑的函式，直接呼叫，比在畫面上模擬點擊還穩定。回頭看，這正好對上前面那張表——這不是一個單純的資料搬運，是要跟一個沒有標準介面的網頁互動，落在 Playwright 的守備範圍，不是 Zapier 的。

如果你也是旅行社

選工具最容易犯的錯，是先問「我比較會用哪一個」，而不是先問「這件事的性質是什麼」。

下次要做自動化之前，先問自己三件事：對方有沒有 API、這東西要不要給別人用、這件事要不要長期跑下去。答完這三題，往前面那張表一對，該用哪個工具通常已經很清楚，不用猜。