我寫過一本書教沒有程式基礎的人用 Google Apps Script 做自動化。
那本書出版之後不到一年，AI 就變得可以直接幫你把整段程式碼寫出來了。
有人問我會不會覺得白寫了。老實說，有那麼一下下。但很快我就發現不是那樣——書裡最不重要的部分才是語法，而語法本來就是最容易被取代的那一層。 真正還站得住的東西，反而在 AI 進來之後變得更有用了。
這篇想講的就是那個「還站得住的東西」，以及 GAS 為什麼在 Vibe Coding 時代不但沒有過時，還變成了最好的入門場地。
為什麼是 GAS
先講為什麼我到現在還在推薦 GAS，而不是 Python 或別的。
理由只有一個：它已經在你的工作裡了。
你不用安裝任何東西。不用設定環境變數，不用管 pip、不用管虛擬環境、不用管版本衝突。你打開一份 Google 試算表，點「擴充功能」→「Apps Script」，就有一個可以寫程式的地方了。
而且它天生就連著你每天在用的東西：試算表、文件、簡報、Gmail、日曆、雲端硬碟、表單。這些東西的權限問題已經幫你處理好了。你不需要去申請 API 金鑰、不需要搞 OAuth 流程——你的帳號能看到的東西，你的腳本就能看到。
這在自動化這件事上是巨大的優勢。因為上班族的麻煩事，有八成就發生在這幾個地方。
我當人資的時候，每週要手動編一份 Excel 報表。那時候我用的是按鍵精靈、OCR 和 VBA，土法煉鋼。現在同樣的事，用 GAS 十幾行就解決了。
Vibe Coding 改變了什麼
Vibe Coding 這個詞我第一次聽到的時候有點反感，覺得太輕浮。後來我自己做了幾個東西，我承認它抓得很準。
它的意思大概是：你不從規格開始，你從一個模糊的想法開始。你講「我想要一個可以幹嘛幹嘛的東西」，讓 AI 把它變成能跑的程式，然後你看著跑出來的結果說「不對，我要的不是這樣」，再改。
聽起來很沒紀律，但它有效。有效的原因是修改一個能跑的爛東西，比從零想清楚一個完美的東西容易太多了。
這跟傳統教程式的順序完全相反。傳統的順序是：先學變數、再學迴圈、再學函式、再學物件，學完之後才有辦法做出第一個有用的東西。很多人在學到迴圈的時候就放棄了，因為他們看不到終點。
Vibe Coding 把順序倒過來。你第一天就做出一個能用的東西，然後在改它的過程中被迫學會迴圈。
那你還需要懂什麼
這是重點了。
如果 AI 可以把程式寫出來，那你還需要懂什麼？
我的答案是四件事。這四件事，AI 目前都幫不上忙，而且它們跟語法完全無關。
一、知道 GAS 能做到什麼、不能做到什麼
AI 很會寫程式，但它不知道你的環境。
你如果不知道 GAS 有觸發器（trigger）這回事，你就永遠只會請 AI 幫你寫「按一下執行一次」的腳本，而不會想到問「能不能每天早上八點自動跑」。
你如果不知道 GAS 有執行時間上限（單次六分鐘），你就會請它寫一個要跑三十分鐘的腳本，然後在正式用的時候莫名其妙失敗。
這一類知識是地圖，不是路線。AI 很會走路，但它不知道你家附近有什麼。
我書裡真正值錢的部分是這一塊：GAS 大概能做哪些事、每一類事情長什麼樣子、有哪些坑。看完之後你不見得記得語法，但你腦子裡會有一張地圖。有地圖的人問得出好問題。
二、把 Why 講清楚
我在公司分享過一個階梯：對 AI 下指令可以停在 What、How、Why 三個層次，而層次愈高，你需要的技術知識愈少。
用 GAS 舉例：
What：「幫我寫一個函式，把 A 欄的值複製到 B 欄。」
How：「用 onEdit 觸發器，在使用者改 A 欄的時候同步更新 B 欄。」
Why：「我們部門每次改報價都要手動同步三個地方，很容易漏掉，幫我想辦法。」
第三種講法最短，需要的技術知識最少，而且拿到的東西最好——因為 AI 可能會告訴你，你真正該做的不是同步三個地方，而是根本不要有三個地方。
停在 What 的人，永遠只能得到自己想得出來的東西。
三、判斷它給的東西對不對
這是最難的，也是唯一不能外包的。
AI 寫出來的 GAS 程式碼，有很高的機率可以跑。但「可以跑」跟「是對的」是兩件事。
我遇過幾種典型狀況：
- 它用了一個已經被 Google 淘汰的舊 API，程式跑得起來但會有警告，某天突然就掛了。
- 它寫了一個迴圈，每一圈都去讀一次試算表。資料量小的時候沒事，資料量一大就超時。
- 它幫我加了一個 try-catch 把錯誤全部吃掉。程式從此再也不會報錯了——包括真的出錯的時候。
- 它把我的邏輯實作得完全正確，但我一開始的邏輯就是錯的。
第四種最可怕，因為那不是它的問題。
要抓到這些，你不需要會從零寫程式。你需要的是看得懂。看得懂跟寫得出來，中間的難度差了一大截，而 AI 時代你只需要前者。
四、知道什麼時候不該自動化
這件事我在書裡沒有寫夠，現在補上。
我的判準是三個條件：會重複做、步驟穩定、要串好幾個工具。 三項都符合才值得。
我第一次寫自動化腳本是在 2015 年，那時候我剛進人資部門第二週。原本純手動要花一小時的工作，我用我的方法還是要花一小時——五十分鐘寫程式，十分鐘執行。完全沒省到時間。
但我知道那是投資，因為那件事我每週都要做一次。
如果那件事我一年只做一次，那五十分鐘就是純虧損。
Vibe Coding 讓寫程式的成本降到很低，所以這條線往下移了一點——以前要做十次才划算的事，現在做三次可能就划算。但這條線沒有消失。你還是得花時間交代需求、驗收結果、之後還要維護。
自動化不是免費的，它只是變便宜了。
一個實際的流程
講了這麼多原則，我把自己實際的做法寫下來，你可以照著改。
第一步，先手動做一次，而且記錄每一個動作。
不要跳過這步。你會發現自己有些步驟其實講不清楚——「然後我就看一下哪裡怪怪的」，這句話沒辦法變成程式。講不清楚的部分就是你真正要想的部分。
第二步，把 Why 寫成一段話，不要寫成規格。
我通常會這樣開頭：「我每週要做一件事，流程是這樣……這件事很煩，因為……我希望能變成……」然後把試算表的欄位結構貼給它。
不要一開始就講「請用 onEdit 觸發器」。那是你在替它做決定，而它可能有更好的辦法。
第三步，要它先講計畫，不要直接給程式碼。
這一步是我後來才養成的習慣，但它省了我非常多時間。看計畫比看程式碼快，而且大部分的錯誤在計畫階段就看得出來。
第四步，跑起來，然後刻意去弄壞它。
空白的欄位、超長的字串、重複的資料、權限不足的檔案。這些狀況正式用的時候一定會遇到，你現在遇到比較便宜。
第五步，留一條退路。
這是我在公司帶專案時的硬規定。我們把一個系統從 GAS 搬到 Cloud Run 之後，GAS 那版留著沒刪，就是為了萬一新的掛掉可以切回去。
自動化的東西壞掉的時候，通常都是在你最忙的那一天。
最後
我常常被問：那還要不要學程式？
要，但學的目的變了。
以前學程式是為了寫得出來。現在學程式是為了看得懂、問得出、判斷得了。
這三件事都比「寫得出來」耐久。因為語法會換、框架會換、連語言都會換，但「這段東西在幹嘛」「這裡會不會出事」的判斷力不會。
我當年從人資轉去寫程式，靠的不是任何一種當時學會的技術——那些技術現在幾乎都不用了。靠的是「遇到不會的東西該怎麼拆」的習慣。
所以如果你問我，該不該用 Vibe Coding 學 GAS？
該。而且要用它做出一個真的會被別人用的東西，最好是你同事每週都要用的那種。因為只有那種東西壞掉的時候，你才會真的學到什麼。
（沒有壞過的自動化，都還不算完成。）