一、我以為最難的部分會是寫程式

開始做這些系統之前，我以為最難的部分會是把程式寫出來。做到後來才發現不是——我根本不寫程式，我寫規格。真正花時間的，是把一件事講清楚到 AI 不會誤會。

我每做一個自動化，都會先建一個資料夾，裡面固定放四份檔案：一份寫清楚這件事要解決什麼，一份寫分成哪幾步做，一份記錄現在做到哪、卡在哪，最後一份是完成後給人看的使用說明。

二、資料夾不會忘記，但 AI 會

這樣做的理由很實際：跟 AI 對話久了會斷——今天談到一半，明天可能就要重新解釋一次背景。但資料夾不會忘記。下一次不管是我自己接著問，還是換一個新的對話開始，把那份「要解決什麼」的檔案丟過去，馬上就能接著做，不用重講一次前情提要。

三、一份規格長什麼樣

舉一個真實的例子。有一支自動化是要把兩種信件的附件自動存進雲端硬碟——中華電信的帳單通知、玉山銀行的外幣水單。我寫給 AI 的規格，大概分成五段：先講這件事要做到什麼、再講整個流程的邏輯（多久檢查一次、去哪裡找信、抓到附件之後存去哪）、然後是例外情況要怎麼處理、接著是技術上的限制條件，最後附上一條一條可以打勾驗收的清單。

例外規則那段我特別花時間想，因為那才是真正會出包的地方。像是「信件裡沒有附件的話，不准嘗試自己登入電信公司或銀行網站去抓」——聽起來理所當然，但如果沒寫清楚，AI 可能真的會想辦法幫你把這件事「做完」，而登入別人的網站去抓資料，遠比在雲端硬碟裡歸檔一個附件危險得多。把這種邊界寫進規格裡，比事後除錯省事太多。

四、三條讓我這種非工程師也能驗收的規矩

規格寫得再清楚，程式終究是別人（AI）幫我做出來的，我不可能靠讀程式碼來判斷它對不對。所以我另外訂了三條規矩，讓我用「行為」而不是「程式碼」來驗收。

第一條是任何會動到真實資料的程式，第一版一律先設成只讀不寫，讓它先空跑一段時間，我確認它判斷得對，才准許它真的動手。第二條是牽涉核心營運的部分，新舊系統要並行跑上一段時間，兩邊結果逐筆對過，確認沒有差異才敢把舊的關掉。第三條是失敗要吵——任何一支程式出錯，都必須主動通知我，不能悄悄死掉，因為悄悄死掉的自動化，比從來沒做過還危險，你會以為它在跑。

五、我甚至設了一個代理，自己排隊做完剩下的

後來我還做了一件更省事的事：設一個排程代理，每天早上自動挑「編號最小的待開發」資料夾繼續做。十幾支要從舊工具搬過來的自動化，就是這樣一支一支排隊生出來的，我不用每天想著「今天該做哪個」。

六、誠實說，AI 產的第一版能用多少

老實說，第一版程式碼能直接上線的比例並不高，通常需要來回調個一兩輪。但這一兩輪花的時間，遠比我自己從頭學程式語言、慢慢除錯要少得多。而且回頭看，我花最多時間的環節從來不是等 AI 寫程式，是把規格寫清楚、把例外情況想全——這件事換成任何一個懂公司流程的人來做，都做得到，不需要先會寫程式。

如果你也是旅行社

你不需要學會寫程式，才能開始做自動化。你需要的是能把一件事講清楚——正常情況怎麼跑、遇到例外要怎麼辦、出錯了要通知誰。這份說明清楚到什麼程度，AI 幫你做出來的東西就準到什麼程度。而寫清楚這件事，本來就是你比任何工程師都拿手的部分。