上一篇把活動資料放進 Google 試算表，網站就有東西可以讀了。不過，資料放進去以後，還有不少事情要處理。

假設你想另外整理一張「近期活動」：每天打開表格，看看哪些活動結束了，把還沒結束的挑出來，再複製到另一個分頁。做一次不難，但每天都做，就會開始想：這件事不能讓電腦自己處理嗎？🙂

可以。Google Apps Script 就很適合拿來做這類工作。

Google Apps Script 是什麼？

你可以把它想成一位照著工作清單做事的助理。你把步驟交代清楚，例如「讀活動表、比較日期、把符合條件的資料放到另一個分頁」，它就依序執行。

這份工作清單，就是程式碼。Apps Script 使用 JavaScript，並提供操作試算表、Gmail、雲端硬碟等 Google 服務的工具。你可以在瀏覽器裡編輯程式，由 Google 的伺服器負責執行，入門時不用先在自己的電腦安裝 Node.js。（參考：Google for Developers：Apps Script overview）

如果用做菜來比喻，JavaScript 是寫食譜的方式，Apps Script 則提供廚房和常用器具。你不用從蓋廚房開始，就能交代它讀哪張表、把結果寫到哪裡。

但這位助理不會自己猜你的意思。你說「幫我整理一下」，它不知道什麼叫整理；你寫「留下結束日期不早於今天的活動」，才有明確的判斷規則。AI 可以協助寫出這份食譜，執行時 Apps Script 仍然是照程式做事。

這張圖列的是可選的入口與服務。一支程式可以只整理試算表，不必把所有服務都接起來。

從試算表上方的「擴充功能 → Apps Script」，就能進入程式編輯器。下面第二張圖已經放入這次的整理程式；第一次打開時，不會自動有這些內容喔。

除了整理表格，還能做什麼？

如果你的工作本來就常用 Google 工具，可以先從這幾種需求想：

• 整理資料：把各分頁的資料合併、挑出符合條件的紀錄，再產生一張報表。
• 接續表單流程：有人送出表單後，依照回覆內容整理名單或準備後續通知。
• 串接其他 Google 服務：例如依資料建立文件、整理雲端硬碟中的檔案，或建立日曆活動。（參考：Google for Developers：Apps Script overview）

第一次練習，我會先選「結果看得到、改錯也容易發現」的工作。整理三筆活動資料就很好：原始表格和輸出結果可以並排看，一眼就能確認有沒有漏掉。

先做一件小事：整理還沒結束的活動

這次先準備兩個分頁：「活動資料」放原始內容，「近期活動」放整理結果。

這次實際示範的日期是 2026 年 10 月 1 日，規則是「結束日期在今天或之後就保留」，那麼結果應該是：

這裡要先講清楚「今天結束的活動算不算」。人看日期可能會自己補上意思，程式卻需要一個確定的答案。原始日期欄也要用試算表真正的日期值，避免同一欄混著「下週五」和「10/8」等不同寫法。

程式要做的事可以拆成四步：

1. 讀取「活動資料」的每一列。
2. 依照約定的時區，比較結束日期與今天。
3. 挑出還沒結束的活動。
4. 更新「近期活動」的結果，保留原始資料。

你可以把下面這段需求交給 AI，請它協助寫程式：

請幫我寫一個綁定在 Google 試算表的 Apps Script。

來源分頁叫「活動資料」，第一列是標題：
A 欄活動名稱、B 欄結束日期、C 欄報名網址。
B 欄使用真正的日期值，以 Asia/Taipei 的日期判斷。

把結束日期在今天或之後的活動，寫入「近期活動」分頁。
今天結束的活動也要保留。

只能更新「近期活動」的 A:C 資料區，不可修改來源分頁。
每次執行要替換上一次的結果，不要重複追加。
只有標題列或沒有符合的活動時，也要正確處理。
空白或無效日期請略過，並在執行紀錄中註明。

先提供手動執行版本，附上操作說明與測試方法。
說明需要哪些 Google 權限，暫時不要寄信或建立排程。

這段提示詞刻意寫了「更新哪裡、不能改哪裡」，因為「整理資料」也可能被理解成直接刪掉已結束的原始紀錄。把範圍交代清楚，之後才好檢查。

拿到程式後，先在測試用的試算表副本執行。第一次操作需要存取 Google 資料的功能時，可能會出現授權畫面；確認專案與權限符合用途，再繼續。

驗證時也別只看「執行成功」。用上面的三種日期檢查結果，再連續跑兩次，確認資料沒有重複、原始分頁沒有變動。這才表示它有照你的規則工作。

下面是實際操作的結果：原始分頁有三筆活動，整理後剩下兩筆。重複執行後也沒有多出重複資料，原始分頁仍保留三筆。活動和報名網址都是示範資料，不是真的報名頁面。

一定要自己按執行嗎？可以幫它設鬧鐘 ⏰

前面先手動執行，是為了確認程式有做對。等結果穩定了，就可以設定「觸發條件」，也就是什麼時候開始做這份工作。

觸發條件負責「叫程式起床」，程式本身負責「起床後做什麼」。同一個整理函式，可以先手動測試，再交給時間觸發條件執行。

因為程式跑在 Google 的伺服器上，設定好的時間觸發條件不需要你一直開著瀏覽器。不過它不是精準到秒的鬧鐘；例如每天上午 9 點的時間觸發，可能會安排在 9～10 點之間執行。（參考：Google for Developers：Installable triggers 與 Quotas for Google Services；配額查核：2026-10-01）

另外，這裡透過設定頁建立的是「可安裝的觸發條件」，會使用建立它的帳號執行。不能因為同事填了表單，就以為後續程式會自動改用同事的權限。

在左側「觸發條件」新增設定，選擇整理函式，再選「時間驅動 → 日計時器」和執行時段。這次只示範設定畫面，沒有按下儲存，所以不會真的每天執行。

它也能當網站的簡單後端嗎？

可以。除了自己按執行或設定排程，Apps Script 也能部署成 Web App，取得一個可以接收網站請求的網址。（參考：Google for Developers：Web Apps）

可以把這個網址想成服務窗口。網站拿著需求來問：「請給我近期活動。」Apps Script 收到後，檢查請求、讀取試算表、整理內容，再把結果交回網站。

這會遇到兩個名稱，先知道它們的工作就好：

• doGet(e)：收到 GET 請求時執行，常用來取得資料。
• doPost(e)：收到 POST 請求時執行，可以接收送來的內容，再由程式決定如何處理。

括號中的 e 可以先想成隨請求一起送來的單子，裡面放著查詢條件或傳入資料。回應可以是網頁，也可以是像 JSON 這樣供程式使用的資料。這篇先認識流程，實際網站串接還要測試授權與瀏覽器端的請求行為。

跟上一篇相比，Sheets API 讓網站呼叫 Google 提供的試算表功能；Apps Script 則讓你多放一段自己的處理步驟，例如先篩掉已結束的活動、只回傳網站需要的欄位，再交給前端顯示。

最重要的設定：這個窗口拿誰的鑰匙？

部署時要分清楚兩件事：誰可以使用這個網址，以及程式用誰的身分執行。

如果設定成以你自己的身分執行，就像窗口裡的人拿著你的鑰匙去讀資料。來訪的人原本不一定能打開你的私人表格，程式仍可能把讀到的內容交給他。因此程式要檢查哪些請求可以處理、哪些欄位可以回傳。

如果設定成以存取者身分執行，就使用來訪者的授權與存取權限。實際可選的存取範圍，也可能受帳號和組織政策影響。部署成功，並不等於權限已經設定正確。（參考：Google for Developers：Web Apps）

下面是部署設定的實際畫面。這裡選擇以「存取網頁應用程式的使用者」身分執行，存取範圍則是「只有我自己」。先在自己看得到的範圍測試，再來考慮要開放給誰，不用一開始就把門全打開。

這次示範先把「近期活動」的整理結果存成一份快照，再讓 Web App 回傳這份資料。你可以把它想成先拍好一張照片，之後有人來問，就把照片拿給他看，不是每次都重新整理試算表。

下面的回應畫面由作者提供。mode: "snapshot" 表示這是一份快照，capturedAt 是產生快照的時間，activities 裡則是保留下來的兩筆活動。之後就算表格改了，這份快照也不會跟著變，還要重新產生才會更新。

開始用之前，還有幾個地方要注意

Google 幫你提供執行環境，但這個環境有使用限制。例如一般指令碼目前每次執行上限是 6 分鐘，寄信、觸發條件的每日總執行時間等，也各有配額。限制會隨功能和帳號類型不同，實際使用前要核對官方表格。（參考：Google for Developers：Installable triggers 與 Quotas for Google Services；配額查核：2026-10-01）

另一個常見狀況是「程式改了，網站怎麼還是舊的？」編輯器裡儲存的程式和已發布的版本要分開看。使用版本化的 Web App 部署時，更新程式後還要更新部署使用的版本；開發測試網址 /dev 和正式部署網址 /exec 也有不同用途。（參考：Google for Developers：Web Apps）

對這篇的活動整理範例來說，先把資料規則寫清楚、手動確認結果，再加排程，就已經能省掉每天重複整理的工作。接著若要讓網站讀取，再處理 Web App 和權限。

我會建議第一次就做到這裡。先讓一件小事穩定運作，之後真的有大量請求、複雜登入或長時間運算的需求，再來評估其他後端服務。你會更清楚自己需要的是哪一部分。

文章同步發表於 https://book.casper.tw/it2026/what-is-google-apps-script