昨天講完我的工作長什麼樣，今天回答一個更前面的問題：這麼多 AI 工具，為什麼我最後主要用 Google 的？

答案不浪漫。不是因為它最強，是因為對一個學校行政人員來說，它是阻力最小的那條路。

行政人員選工具，跟工程師不一樣

工程師選工具看效能、看生態、看社群。我選工具的第一關卡在完全不同的地方：

一、要不要花錢？ 先講清楚，學校不是買不起——真要買別家的 AI 服務，預算是有的。但「要買」表示要提需求、要寫理由、要等流程跑完，而且之後每一年都要再解釋一次。免費的差別不在省那筆錢，在於我今天就能開始用，不必先說服任何人。 對一個手上有四條線同時在跑的人來說，這個差別是決定性的。

二、要不要自己架伺服器？ 這一關刷掉最多工具。我做的東西如果需要一台主機，那就牽涉到資安、備份、誰維護、離職怎麼辦。能不架就不架。

三、資料送到哪裡去？ 學校的資料裡有學生姓名、學號、簽到表。這一關不是技術問題，是責任問題。

四、我學不學得會？ 我不是資訊本科出身的，手上會的這些是因為有興趣，自己零零星星學來的。所以一個工具再強，如果它的入門資料預設你已經懂一堆前提，那它在我這裡就等於不存在。有沒有免費、而且聽得懂的學習管道，直接決定我用不用得起來。

拿這四關去篩，剩下的選項其實不多。

起點：學校本來就有 Google 帳號

第一個關鍵是這個——學校的信箱和雲端硬碟本來就是 Google 的。

這件事很多人視為理所當然，但它的意義是：我不需要為了用某個 AI 工具去申請新帳號、不需要說服任何人、不需要走任何流程。帳號已經在那裡了，登入就能用。

對行政工作來說，「不需要走流程」這件事的價值，比工具本身強多少還重要。

而且同一個帳號底下不是只有一個工具。信箱、雲端硬碟、試算表、表單本來就在用，後來接上的 Gemini、NotebookLM、Firebase 也都認同一個帳號。這件事的好處很實際：我不用為了每個新工具重新想一次「資料放哪、誰有權限、離職之後怎麼辦」——那些問題在學校導入 Google 的時候就已經回答過了。

第二個推力：免費方案

Google 從 2025 年開始推免費方案。我是去年十二月申請的，拿到的是 Google AI Pro——驗證是認學校信箱的，學校信箱本來就在那裡，所以整個過程沒有任何行政程序，填一填就過了。

這裡要先講清楚，因為它會影響你的判斷：今年這一波給的不是 AI Pro，是等級較低的 Google AI Plus。 我手上這個是去年那一批的，所以我講的使用經驗，跟你現在申請會拿到的東西不完全是同一個。

不過這裡要提醒三件官方條款上寫著、但很容易被忽略的事：

1. 註冊時要先綁信用卡，而且免費期結束後如果沒取消，會自動開始每月扣 165 元。這不是陷阱，條款寫得很清楚，但「免費一年」四個字太醒目，很多人不會捲到下面去看。對行政人員還有一層：那是一張私人的卡，綁在一個拿來辦公的帳號上。申請完就去行事曆記一筆到期日，別讓它靜靜地變成每月支出。
2. 每年都要重新驗證資格才能繼續。我的到期日在十二月，還沒遇到第二年，所以我沒辦法告訴你重驗會不會過、要準備什麼——這件事我只能等到時候再說。
3. 兌換期限是今年的 12 月 31 日。去年那一波的截止日也是十二月，看起來是固定的節奏，但想試的人還是別放到忘記。

還有一個我覺得該講清楚的：官方台灣頁面通篇寫的是「學生方案」，FAQ 甚至寫「18 歲以上符合資格的美國大學生」，但整個頁面掛在 /tw/、標價是新台幣 165 元。而實際申請時，驗證的是學校信箱——我用學校 Gmail 申請就通過了。

條款文字、頁面地區和實際驗證方式這三者沒有完全對齊。所以資格請以你自己申請當下看到的條款為準，不要照我這篇寫的推論自己一定符合。我能講的只有我自己的情況：用學校信箱申請，當下通過了；到期日在十二月，第二年還沒到，所以重驗會怎樣我也還不知道。

免費一年的意義不只是省錢。它讓「先試試看」變得可能。行政單位導入任何東西，最怕的是投入之後發現不合用，而免費期就是一個可以安心試錯的緩衝——不必先寫簽呈、不必先編預算，就能知道這東西到底幫不幫得上忙。

第三個推力：GDG 社群

工具拿到手，不代表會用。

我參加過多次 GDG（Google Developer Groups）社群辦的 AI 教學活動。這件事的價值在於：它把「這個工具能做什麼」變成看得見的東西。

自己看文件，你會知道功能列表；看別人現場示範，你才會想到「這個好像可以拿來處理我那個表單」。我很多實際的用法，是在那種場合被啟發的，不是讀說明書讀出來的。

而且社群裡的人做的東西，跟官方文件的示範不一樣——官方會給你最漂亮的案例，社群會告訴你哪裡會卡住。

所以我實際在用的是這些

盤點下來，我的日常工作裡固定在跑的有這幾樣：

這四樣都不用自己架伺服器，這就是前面那四關篩出來的結果。

清單上還少了一個東西：Google Apps Script。它是接在試算表後面的自動化工具，第一版的報到系統就是用它做的。後來換掉了，原因很單純——反應速度太慢。

後來換成 Firebase，因為它是為了「即時同步」設計的：手機那頭寫進去，大螢幕那頭幾乎同時就顯示出來。為什麼在報到現場「快」是硬需求、換掉之後又發生什麼，Day 17 會整篇講。

這件事後來變成我選工具的一條經驗：先問這個工具原本是為了解決什麼問題而生的。 它擅長的事和你要它做的事對不上，再怎麼調校也有限。

但我不是只用 Google

這裡要誠實：我手邊也有別家的工具在跑，而且有一段工作是這條線目前做不到的。

那一段是：代替我操作瀏覽器。

我的工作有很大一塊是把東西貼進學校的後台系統——登入、開新增頁面、貼原始碼、按確定、設發佈日期。這些動作沒有技術難度，但很花時間，而且要重複幾十次。這正是最該自動化的部分。

問題是：產文字的工具碰不到瀏覽器。 它可以把公告寫得很好，但接下來那幾十次點擊還是我自己點。

而命令列那套工具看起來可以——它有一個開瀏覽器的功能。我信了一陣子，後來實際去查作業系統的程序清單，發現它根本沒有開。那次驗證的完整過程是 Day 23 的主題，這裡先講結論：它說它開了，但沒有。

所以這一段我用了別家的工具。後面的文章提到它的時候，我會寫「另一套工具」——不是要避諱，是因為這個系列要講的是 Google 這條線，而它在這裡的缺口比它的替代品是誰更重要。

其餘的部分我會聚焦在 Google 這條線，不是因為別的不好，是因為一條線講深，比五條線各講一點有用。但我不會假裝這裡什麼都能解決。

明天

Day 4：我的第一條規矩——先問「這件事可不可以驗證」。

這條規矩會貫穿整個系列，也是我後來敢把工作交出去的唯一原因。