一個本來放著不動的網站，在 AI-coding 出現之後，自然長出了一些更順手的管理方式

前幾年寫了一篇蒐集有貓咪可以摸的店的小廢文，依照 SEO 界對 Google 的各種實驗，一個網站中太多不相干的主題，Google 會把文章當作垃圾、蛆蟲，網路世界的毒瘤。

剛好那時候有其它想玩的東西，就把資料拆出來，搬到另外的網站去。當時面臨一些技術選型症候群:

選一種關聯式資料庫、選一個程式語言，做一套管理後台?
才不要，吃飽太閒嗎?
店家清單就做一個 json 清單檔案，
再寫一些 jQuery 程式把 json 顯示成一個帶有地圖的網頁。
這樣整個網站都是靜態頁面，成本最小化。

精美的地圖?
Google Maps 要錢，
好看一點&有機構在維護的 OpenStreet Maps 圖磚也要錢，
就用免費最基本的。

強大的店家篩選條件，可以一下查出中藥行、咖啡廳? 貓的品種?
才不要，這家店明天起不給人玩桌遊、那家店母貓生小貓，這些事誰知道? 誰要去更新名單?
只有簡單的縣市篩選。

網站就這樣放生了幾年，直到近期每次看到一些 AI coding 工具的額度還沒用完，或是有免費的 AI 出來，在業餘之餘開始幫網站加功能。

以前要把許多功能做好做滿，要花很多時間，現在和 AI 協作，提升了一些效率。

用 Google Maps API 自動爬資料

一開始網站上的店家只是放附近的、路過看到的、去過的店，資料當然就很少。

那乾脆也從 Google Maps 上抓資料的好了，又要用上 Place Details API 了，這部份用了 AI 輔助:

資料進來之後，再進行檢查。

用瀏覽器擴充套件和 Python 程式加速審核作業

有人說 Google Maps 進來的資料可以直接用，那我問你(小明劍魔歪頭)

一堆店名像這樣的:

• 口口金選十大好店｜台灣百大伴手禮店｜XX咖啡｜XX口口口口必買｜XX口口口必吃｜XX鬆餅必點｜口口特色美食｜寵物友善｜口口伴手禮｜ESG永續理念｜食材循環經濟｜口口美食｜餐廳｜
• XX五金工具行 電動工具專家 口口口口北區旗艦店-地名1五金行 地名2五金行 地名3五金行 地名4五金行 地名5五金行 產品1 產品2
• 口口市 口口區 - XXXXX||早午餐/義大利麵/鮮奶燉飯/鬆餅午茶/口口巴斯克蛋糕:emoji:||口口獨棟包場推薦 抓周慶生聚餐尾牙首選 (平日預約制:emoji:請先參考臉書訊息)
• 口口市 口口區 - XXXXX- 口口 口口 老屋咖啡廳推建 老宅咖啡首選 網友打卡咖啡店 讀書 甜點好評 平價 專業手沖咖啡 巷弄咖啡 優質 高CP值 提拉米蘇 巴斯克 布朗尼 古董居家氛圍 下午茶 精選咖啡豆 聚會
• 口口市 口口区 - XXXXXX貓舍#新北板橋貓舍 #英短#布偶#曼赤肯#金漸層#銀漸層#新北貓舍#新北耶誕城#板橋車站#新北寵物店#英短#布偶貓#板橋賣貓#24小時營業#貓舍#金漸層矮腳#藍金漸層矮腳

這麼長的店名，在手機上換行好幾行，如果邊吃飯邊滑手機，飯都吃完了，網頁 UI 上的一家店還沒滑完。然後點擊地圖上的圖釘，資訊視窗顯示不下這麼長的店名。

這種店名能用嗎?
回答我! Look at my eyes!

除了把這種充滿行銷風味的店名，換成正常普通的店名，
很多店名非常的文藝，根本看不出是賣什麼東西的，我還要幫他寫備註，是咖啡簡餐店、桌遊店、塔羅占卜、寵物用品、宵夜...

還要檢查評論和照片，確認是否真的有貓咪? 看是不是什麼地雷店?

為了節省 Google Maps API 的使用成本，還有跳脫 API 使用限制，有些部分直接用 GBP 電腦版頁面。

這邊又做一些東西輔助審核:

• 一個檢查店家照片有沒有貓的 Python 程式，人類不用仔細看照片，只要看框框有沒有變綠而已。
• 一個 Chrome 瀏覽器套件，會自動用某些條件搜尋 Google 店家評論內容。

真的是有貓就給過。
沒有貓的則會被我放到黑名單，以免下次排程爬資料時，又自動被加進來等待審核。

後來商店審查標準越來越寬鬆，還發現很多神奇的經營型態，與其說店裡有貓咪，大部分可能是別人帶去的貓咪...或是人家就是在賣貓咪/送貓咪的，只是有其它附屬經營模式。

還有些是薛丁格的貓，例如開在山上，或是一些遠離市中心的商店、景觀餐廳、花園、合法民宿，然後場地裡面常常有外面跑來的貓，貓咪介於老闆養的/室外放養/野生流浪貓之間的量子疊加狀態。

話說店裡有貓咪或其他動物這件事，也是一個動保法律爭議的議題，我想蒐集整理的大部分都是咖啡簡餐店，或是什麼中藥行之類的一般零售店面，不是休閒農場、動物園之類的特殊業種。老闆也可以說是家庭寵物，不是展演動物。

法規如果設計得不好，反倒可能讓一般的貓咪咖啡廳被加強管制，有心人士在法律產業的幫助下繼續鑽漏洞。總之這些問題太高深了，輪不到我煩惱。

用 LINE 聊天機器人更新店家資料

本網站是自己維護一套名單，不是 Google Maps 套殼。剛剛用程式自動定期去查 Google 的各種 API，然後把資料抓回來。

但現實是總有一堆店家明明沒有貓，也莫名其妙被 Text Search 和 Gemini 覺得有貓。還要小心用量超過 API 的免費用量範圍。

另外常常在 IG、Threads、地方 FB 社團上看到店裡有貓咪的照片，這些店家也很值得分享吧?

但問題是一開始沒考慮在手機上更新店家資料:

• 雖然有一個 Node.js 寫的資料管理後台，但那個只有跑在電腦本機上。
• 我可不想公開放在網路上，然後還要做一堆防禦措施。
• 而且還要調整版面，讓它適合手機操作，想想就有夠麻煩。
• 每次把店家先存在書籤或備忘錄，等到有開電腦再更新? 這也很麻煩。

決定又再開一個 LINE 官方帳號，用聊天機器人的方式來更新店家資料。

開發 LINE Chatbot 真是罄竹難書

LINE 是台灣很多人使用的通訊軟體，也有很多促進經濟發展的開發需求，但開發這種東西十分考驗團隊能力。

例如我自己就是那種 iPhone 的 LINE 訊息常常傳不出去的人，不管是對朋友傳訊息，還是對官方帳號傳訊息都會這樣，要是從電腦上看，訊息根本沒發出去。

反正我已經訓練有素，傳訊息時確定有傳出去，才切換 APP。訊息卡住時就把 APP 滑掉重開，然後重傳訊息。

要是在開發 LINE 聊天機器人碰到這個可不得了，使用者的手機訊息根本沒發不出來，我的程式這邊當然接收不到，又通通都變成我的鍋囉?

LINE 生態系有很多玩意，串串 API、做圖文選單，用的大部分也是寫網頁程式、設計網頁那些技能，但是就比較沒辦法像網頁一樣直接 debug，而且隨著 Android/iOS/電腦系統不同、手機APP有沒有更新，還會出現不同的問題跟功能限制，LINE 又不是我家開的，要看平常累積的功德夠不夠多。

接著還有「用一隻黑色的筆畫出紅線，然後用紅線畫一顆綠色的樹，這需求已經講得很清楚了」的鬼故事。

一下說要像哪個LINE官方帳號一樣(然後他們是直接在對話途中開一個網頁視窗)，但是又要做一些在 LINE 的網頁瀏覽器無法使用的功能。

一下說要像另一個LINE官方帳號一樣(然後他們是用 flex message)，但是又要把 flex message 訊息卡片的樣式硬改成官方 API 沒提供的。

一下子說要像哪個LINE官方帳號一樣(然後他們是用 LINE LIFF 做簡易身份驗證)，但是又還要憑空取得消費者的生辰八字住家地址婚姻狀況，並設計各種整消費者的會員機制。

一下說要像誰誰誰(那個是在 App Store 上架的 APP...)。

要是隊友只會無腦傳話複製貼上、壓時間、丟一個名詞就要大家開始作文比賽，專案很容易就變成______，然後責任莫名其妙通通算在某個基層人員頭上。

做自己好自在

但我這個吸貓地圖更新工具不用考慮這些煩惱，反正網站是自己在更新的，聊天機器人只有自己在用的，不用考慮邊開飛機邊換零件的穩定性問題，還有維護服務範圍等等商業問題。

LINE 聊天機器人的功能:

• 新增模式，輸入店家名稱或地址後，從 Google Place API 把地址、縣市區域、經緯度、店家網站等資料都自動填上，有重複的會提醒，減少麻煩的手動輸入。
• 修改模式，修改店家資訊。
• 查詢模式，用來檢查店家有沒有輸入過，找不到的可一鍵進入新增模式。
• 狀態，查詢一些佈署狀態之類的系統狀態。
• 發佈，可以修改多家，改完再發佈。
• 權限控管，用 LINE LIFF 做驗證，有登入&白名單的帳號才能編輯資料。每次登入保留 3 天。
• LOG 工具，用來當操作記錄，還有 LINE 和 Google 的 API 回應資訊。

LINE 聊天機器人背後有一套 PHP 程式，用來處理 LINE API 發來的請求，每次更新店家資料的時候，會去 GitHub 把店家資料拉下來，改完再推送上去。

雲端有一套CI/CD，每次資料更新時，會自動重新建置出網站中每個縣市的清單頁面，免費版的每月建置時間是有限的，所以要好好控制。

Chrome 144 新增了一個新的 <geolocation> 功能

這個月中(2025/1) Google Chrome 發布版本 144 的穩定版更新，看到 Chrome for Developers 的官方技術部落格介紹了一個新功能 Introducing the geolocation HTML element，剛好可以用在網站內，以下發表一下心得感想。

光看官方的介紹，一樣也是在網頁瀏覽器上，讓網站的前端程式跟使用者要地理位置資訊用的，但程式碼跟以前的那個相比看起來更漂亮。這年頭好像不流行「程式碼更漂亮」這種說法，那換個說法好了....AI 寫起來可能比較省 tokens?

它是一個 html tag，只要放 <geolocation></geolocation> 在頁面上，就會自動生成一個灰色大按鈕，使用者點了跳出來詢問是否允許地理位置權限。

下面放個範例

雖然 Safari 跟 Firefox 瀏覽器都不支援，但是它 fallback 相容性很好，還是可以在裡面放其他 button 元素，觸發原本的權限要求 JS 程式。不支援的瀏覽器就不會跑出表單元件預設樣式按鈕。

第一個特色是權限要求視窗(permission promp)跑到畫面正中間(如上圖的下半部)，而不是像以前的那種，縮在左上角網址列下方。然後被 UX 大師挑毛病說容易被使用者忽略。

前端工程師又要發牢騷，瀏覽器的原生視窗要長怎樣是我能控制的? 但現在前端開發者還真多了一種選擇。

使用後第一個用到的怪問題，就是那個按鈕竟然顯示簡體字「使用精确位置」(如下圖)!!

冤枉啊，大人，那個文字跟圖示都是瀏覽器自動產生的，網頁本身是 html lang="zh-Hant-TW"，瀏覽器的偏好語言跟作業系統語系也都是繁體中文，最後在按鈕上也直接加 lang="zh-Hant-TW" 屬性，終於乖乖變成繁體中文。

幫按鈕加樣式改顏色之後(如上圖2)，按鈕竟然點了就沒反應? console 也沒 error? 然後把按鈕改回預設灰色，或是改成黑色背景就正常，這太不科學了吧!

回去看官方文件，原來為了防範欺騙性設計模式( deceptive design patterns)，按鈕的對比度、大小、CSS變形、透明度、都有規範，以下列舉幾個:

• 背景色和文字顏色對比度 3:1 以上 (Text and background colors are checked for sufficient contrast (typically a ratio of at least 3:1))
• 不能設定透明度(the alpha channel must be set to 1 to prevent the element from being deceptively transparent.)
• 不能使用負的 margin 和 outline-offset (Negative margins or outline offsets are disabled)
• transform 僅支援 2D 平移與比例縮放 (Distorting effects are limited—for example, transform supports only 2D translations and proportional scaling)

因為本來橘底白字的按鈕，對比度只有1.9，把背景色加深，改成官方規範的對比度3以上，geolocation 按鈕的請求權限功能又恢復正常了。

結語

吸貓地圖的網站還是一開始手寫的那個網站，一切營運成本還是在免費範圍，但整個資料更新和管理流程，已經靠著 AI coding 得到大升級。

透過 LINE 聊天機器人、Python 影像辨識程式，瀏覽器擴充套件，本機 Node.js 資料後台、CI/CD 流程。將一個休閒專案的資料維護、發佈流程做得更完整。

一般使用者瀏覽的前台保持純靜態、後台流程全自動化，整體架構變得可控、好調整，也不太會出奇怪的管理複雜度與維護風險。

還好當年剛做的時候沒有太有行動力，不然早做早受苦，晚做晚享受。