上級機關或其他學校寄來一份公文，內容是某個活動、某個競賽、某個研習，希望我們幫忙轉知給校內師生。
我要做的事：把它變成校網上的一則公告。
聽起來三分鐘的事。實際上每一則要花的時間比想像多，而且量不小：我把這個學年度的資料夾數了一次，到九月初為止有 35 個收文日、108 份來文，平均一週三份左右。
拆開來是這些：
真正花時間的是 3、4、5，而 AI 幫得上忙的也主要是這三段。
先講一件很無聊但很重要的事：檔案怎麼整理。
我的做法是先按學年度和收文日期分層，最底下依來文機關分資料夾，每個機關資料夾裡放兩樣東西：
轉知/
└─ 115/ ← 學年度
└─ 0813/ ← 收文日期
└─ 某某大學/
├─ 來文.pdf
└─ announcement.html
一份是原始來文，一份是我做出來的公告 HTML（HTML 就是網頁的原始檔，決定哪一段是標題、哪一段是連結，是要貼進學校網站後台的東西）。
這個結構有兩個好處。第一，之後有人問「這則公告的依據是什麼」，原始來文就在旁邊。第二，同一個機關的來文放在一起，下次再來，我可以直接看上次是怎麼處理的。
我原本還會另外做一份 Word 檔留存，後來停掉了——因為那份沒有人會打開。做了一陣子之後我發現，留存的價值在於「查得到」，而不在於「格式漂亮」。
這件事在檔案上看得出來：108 個機關資料夾裡，還留著 Word 檔的有 46 個，而且全部集中在前半段，最後一份停在六月初，之後就沒有了。我沒有計時過這樣省下多少時間，所以不寫一個數字——省下的是每一則都要多開一次 Word、多套一次格式、多存一次檔。
這一段我一開始是用 Gemini 做的。
讀懂來文、抓出重點。 公文有固定結構（主旨、說明、辦法），但重要資訊常常散在各處——報名截止日可能在說明的第三點，也可能只出現在附件裡。請它整理出「活動名稱、對象、時間、地點、報名方式、截止日」，比自己看快很多。
產出公告的 HTML。 我有固定的版型，把版型和內容給它，它產出符合格式的 HTML。
但有兩件事一定要自己確認：
一、日期。 這是最容易錯、後果最嚴重的。報名截止日抄錯一天，就會有人白跑一趟。我的習慣是日期一律回頭對原文，不管它整理得多漂亮。
二、連結。 報名網址、活動網頁——這些一定要實際點開看。網址少一個字元不會有任何錯誤訊息，就是打不開。
照實講：「寫出公告」這一段我一直用 Gemini，但「把公告貼進後台」那一段，我後來換成另一套工具。
原因就是 Day 3 講過的那個缺口——它不能操作瀏覽器。 產出 HTML 沒問題，但接下來這一串它做不到，只能我自己點：登入後台、開新增頁面、填資訊名稱、改發佈日期、把詳細說明切成 HTML、開原始碼視窗貼進去、切回預覽確認、存檔、再到「公告」頁籤勾分類按確定、到「總網」頁籤勾分類按確定、送出，最後回頭點開那一筆，確認兩個頁籤真的掛上了。
照著這個流程一步一步數，一則公告大約二十幾個動作，而且每一個都不能跳——其中「按確定」那兩下漏掉，東西看起來還是存進去了，只是沒掛到該掛的地方。
這一段沒有任何技術含量，但它很耗人。難的不是難，是每一則都要重來一次、而且中間不能恍神；這個學年度到九月初是 108 份，乘上去就是兩千多次同樣的點擊。
所以現在是這樣分工的：產文字的是 Gemini，代替我操作瀏覽器的是另一套工具。 這不是誰比較強，是「能不能碰到瀏覽器」這個功能上的差別。
而讓工具代替我打字之後，又冒出一個我完全沒預料到的坑——那個留到 Day 14 講。
公告不是我寫好就能貼上去的，它要走行政流程。流程本身要時間，而報名截止日不會等流程。
所以拿到一份來文，第一件要看的不是內容，是日期：活動哪一天、報名截止在哪一天、然後估這份東西走完流程還來不來得及。
這一步我現在會請 AI 幫我看一遍。 一份來文裡的日期常常不只一個——活動日期、報名截止日、系統開放時間，有時候正文寫一個、附件又寫另一個。我讓它把來文裡出現的每一個日期抓出來列成一排，再跟我要貼上去的公告內容核對一次，對不起來就直接告訴我是哪兩個對不起來。
它的價值不在「幫我決定」，在逼我在送出之前再看一次時間。日期是這件事最容易錯、也最難補救的地方：公告貼出去之後，有人是照著上面的日期去安排的，錯一天就是別人白跑一趟。
但來不來得及、時間卡住了要怎麼處理，這些還是我的判斷。它能做的是在我按下去之前說一句「這裡兩個日期對不起來」。
Day 10：公告的口吻是有立場的。
這是我做這件事以來，覺得最需要人來把關的一段——而且是我一開始沒意識到的。
iThome鐵人賽
看影片追技術