01起點：一件每個月都要記得的小事
用天然氣的人每個月都要自己抄表，然後上瓦斯公司的網站把度數填進去。 這件事不難，但它有兩個很煩的地方：你要記得，而且你要開電腦。 忘記就變成估算帳單，開電腦則是一件沒有人想在睡前做的事。
我們想做的東西很單純：拍一張瓦斯表的照片，丟到 LINE，剩下的都不用管。 LINE 是台灣人本來就開著的 App，不用再裝一個新的東西 —— 這是整個產品唯一的關鍵決定， 後面所有技術選擇都是為了服務它。
02第一版：一行程式都沒寫
第一版刻意走無程式碼路線，先用最便宜的方式驗證想法。整條流程搭在 Make.com 上， 像積木一樣把服務串起來：LINE 收到訊息 → 丟給 OpenAI 看照片讀出度數 → 存進 Google Sheets → 再叫一個 Apify 上的爬蟲去瓦斯公司網站把表單填完送出。
這個版本是真的會動的，而且花不到幾天就跑起來了。 對於「這個想法到底成不成立」這個問題，它給了一個很便宜的答案：成立。
先用最快的方式證明想法可行，不要一開始就蓋一棟房子。 這個決定到現在都還是對的 —— 錯的是我們以為它可以一直用下去。
03撞牆：積木疊不上去了
問題不是出在某一天壞掉，而是慢慢變得綁手綁腳。 流程一長，Make 的每個節點都要付錢；出錯的時候只看得到「某一格紅了」， 看不到為什麼；想加一個新的判斷，就得在網頁介面裡拖半天。 更麻煩的是安全性 —— LINE 傳過來的訊息應該要驗簽章確認真的是 LINE 發的， 用現成模組串起來的版本根本沒有做這件事。
到這裡我們做了第二個關鍵決定：把整套打掉，用真正的程式重寫。 做法是把行為定義清楚，再和 AI 一起把它變成看得懂、改得動的程式碼 —— 這後來成為我們每一個產品的開發方式。
04打掉重做：判斷在我們，實作交給 AI
重寫的過程都在 Claude Code 裡進行。我們負責描述行為、審產出、指出哪裡不對； 它負責寫檔案、跑測試、解釋每一步在做什麼。整套服務被拆成幾塊：
- 收訊息：自己接 LINE 的 webhook，並且手動驗證簽章 —— 這是無程式碼版本沒有的那一層。
- 讀照片：用 GPT 的視覺模型把瓦斯表上的數字讀出來；純文字的訊息交給比較便宜的小模型處理，能省一點是一點。
- 存照片：上傳到 Cloudinary，而且改成簽章上傳，用完就刪。
- 記帳：資料寫進 Google Sheets，因為我們要能隨時打開查。
- 送出去：用 Playwright 開一個瀏覽器，照著瓦斯公司網站的三個步驟把表單填完送出。
2026 年 7 月，我們把 Make 的流程和 Apify 上的爬蟲整個刪掉。 刪之前先用真實的一筆抄表從頭到尾跑過一次，確認新版本真的把資料送到瓦斯公司那邊，才動手。
05上線後才學到的一課：LINE 只等你一秒
新版本部署在 Render 上。免費方案有個特性：沒人用的時候它會睡著， 下一個請求進來才醒。這在大部分情境沒差，但 LINE 的 webhook 大約只等一秒 —— 服務還在爬起來，LINE 已經判定失敗了。
對使用者來說，症狀是「我傳了照片，它沒反應」。這種問題最惡劣的地方在於： 它不會報錯，看起來就只是壞掉。
解法不是換更貴的方案，而是加一道門：一個永遠醒著的小程式放在 Vercel 上， LINE 只跟它講話，它立刻回一個「收到」，再把工作往後傳。 現在的路徑是 LINE → Vercel 中繼站 → Render 主服務 → 讀圖／記帳／送表單 → 回訊息給你。
會動跟撐得住是兩件事。第一版證明想法可行，第二版才開始處理現實 —— 而現實通常不是功能問題，是超時、是簽章、是免費方案的小字。
06用了哪些 AI 工具和服務
07一個 LINE 帳號只能綁一個瓦斯表
一個 LINE 帳號目前只能綁一個瓦斯帳號 —— 換一個用戶號碼就會蓋掉舊的。 家裡有兩個表的人用不了。要支援得多加一層「你要報哪一個」的問答， 目前先放著 —— 還沒有使用者實際回報這個需求，我們不想為了假想的情境增加註冊時的步驟。
下一步是把支援的瓦斯公司從一家擴到多家 —— 每一家的網站表單都不一樣，所以這不是設定問題，是一家一家接的工程。