一個本來放著不動的網站，在 AI-coding 出現之後，自然長出了一些更順手的管理方式
前幾年寫了一篇蒐集有貓咪可以摸的店的小廢文，依照 SEO 界對 Google 的各種實驗，一個寫網頁設計和科技主題的網站跑去寫這種東西，這種太多不相干的主題的現象，在 Google 會把文章當作垃圾、蛆蟲，網路世界的毒瘤。
剛好那時候有其它想玩的東西，就把資料拆出來，搬到另外的網站去。當時面臨一些技術選型症候群:
選一種關聯式資料庫、選一個程式語言，做一套管理後台?
才不要，吃飽太閒嗎?
店家清單就做一個 json 清單檔案，
再寫一些 jQuery 程式把 json 顯示成一個帶有地圖的網頁。
這樣整個網站都是靜態頁面，成本最小化。
精美的地圖?
Google Maps API 要錢，
好看一點&有機構在維護的 OpenStreet Maps 圖磚也要錢，
就用免費最基本的。
強大的店家篩選條件，可以一下查出中藥行、咖啡廳? 貓的品種? 2隻貓以上? 中秋節的下午3點有營業?
才不要，這家店明天起不給人玩桌遊、那家店母貓生小貓，這些事誰知道? 誰要去更新名單? 有些店家連自己都不更新 Google Maps 的營業資訊了。
反正我只有做基本的縣市篩選，連行政區都不做了。
網站就這樣放生了幾年，直到近期每次看到一些 AI coding 工具的額度還沒用完，或是有免費的 AI 出來，又把網站撿回來，在業餘之餘開始幫網站加功能。
以前要把許多功能做好做滿，要花很多時間，現在和 AI 協作，提升了一些效率。
用 Google Maps API 自動爬資料
一開始網站上的店家只是放附近的、路過看到的、去過的店，資料當然就很少。
那乾脆也從 Google Maps 上抓資料的好了，又要用上 Place Details API 了。以下列一下有 AI 輔助，跟以前古法程式開發有何不同:
| AI輔助 | 傳統古法作業方式 |
|---|---|
| 人類找出文件 Places API - Place Details，讓 AI 整理免費用量範圍說明，人類再檢查 | 人工查表，持續修正例外情況 |
| 人類找出文件 Place Details SKU，讓 AI 挑出價格比較低廉的 SKU | 人工查表 |
| 讓 AI 調整程式呼叫 Text Search API 的參數 | 人工查表，持續修正例外情況，要改的地方太多了，還是改天吧 |
| 提出要顯示的資訊，指揮 AI 自己選參數串 API | 自己寫程式，光是地址資訊，就要把 addressComponents, addressDescriptor, adrFormatAddress, formattedAddress, location, shortFormattedAddress 全部呼叫一遍，看 Google API 回應的資料長什麼樣子，確定哪個是真的能用的。 |
資料進來之後，再進行檢查。
用瀏覽器擴充套件和 Python 程式加速審核作業
有人說 Google Maps 進來的資料可以直接用，那我問你(小明劍魔歪頭)
問題1:堆砌關鍵字的店名
一堆店名像這樣的:
- 口口金選十大好店｜台灣百大伴手禮店｜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!
問題2:看不出是賣什麼的店
有人可能覺得這種充滿行銷風味的店名，只要丟給 LLM 跑一下，就能直接換成正常普通的店名，都不用人工整理，啊能能能...能你媽X(小明劍魔痛斥)。
因為網站主題不是貓餐廳，而是買東西時任何有貓可以看的店，那範圍就很大。
有很多店名非常的文藝，根本看不出是賣什麼東西的，我還要幫他寫備註，是咖啡簡餐店、桌遊店、塔羅占卜、寵物用品、宵夜、手工藝坊...
還要檢查商家的 Google Maps 評論和照片，確認是否真的有貓咪? 看是不是什麼地雷店?
問題3:連結缺失
有些店家有官網，在 Meta 系的社群平台更新得很頻繁，在 FB、IG、Threads 上面有店家自己上傳的貓咪照片或影片，但是在 Google Maps 這邊什麼都沒有。然後有人覺得只靠 Google Maps 的資料就足夠了? 啊能能能...能你媽X(小明劍魔再次痛斥)。
這鍋有一部份可以算在 Google Maps 頭上:
- 如果店家把它主力經營的 FB 連結放在 Google Maps 的「網站」欄位，有機會收到 Google 寄的通知信，說連結不合規定，會被自動移除。
- GBP 允許的社群媒體檔案有限制平台種類(如下圖)，不能放 Threads，要等哪天系統開放。
還有會碰到店家的 GBP 名稱寫「公休請看 FB/IG」，但是根本沒放 FB/IG 的連結，有時候不是店家不放，是又被偉大的 AI 警告了。當然 AI 是不會錯的，AI 說什麼都對，Google 這麼大的公司會出錯嗎? 店家只能多找找自己的問題😢
總之我還常常需要另外去找店家的官方連結，KEY 在我們的店家名單系統內。
做些小程式輔助人工作業
為了節省 Google Maps API 的使用成本，還有跳脫 API 使用限制，有些部分直接用 GBP 電腦版頁面。
這邊又 vibe-coding，讓 AI 做一些東西輔助審核:
- 一個檢查店家照片有沒有貓的 Python 程式，人類不用仔細看照片，只要看框框有沒有變綠而已。
- 一個 Chrome 瀏覽器套件，會自動用某些條件搜尋 Google 找店家的官方社群平台連結，和檢查 Google 店家評論內容。
真的是有貓就給過。
沒有貓的則會被我放到黑名單，以免下次排程爬資料時，又自動被加進來等待審核。
這邊用 AI 輔助寫程式的占比又更大了:
| AI輔助 | 傳統古法作業方式 |
|---|---|
| 指揮 AI 做 Chrome 瀏覽器擴充套件 | 人工研究 Chrome 瀏覽器擴充套件怎麼寫 |
| 指揮 AI 做 Python+YOLO 影像辨識程式 | 人工研究 Python 程式怎麼寫，上網找範例程式 |
| 指揮 AI 做可以拖曳改變偵測視窗的大小位置；開始/暫停偵測的 Python GUI 程式 | 人工研究 Python 程式怎麼寫 |
| 能讓電腦操作的絕不手動操作，能在一個地方全部做完的絕不複製貼上，科技最大化輔助工作 | 人工點擊捲動瀏覽 Google Maps 網頁、打字搜尋評論、檢查照片、複製貼上 PlaceID 到名單中 |
找店家的官方社群平台連結，這回事感覺起來很簡單，做了之後才發現還是有坑。
例如用店家名稱去搜尋 Google，挑出前面幾筆 facebook、instagram 的連結，但可能挑出來的是FB地方社團的貼文，或是美食部落客的IG發文...。
處理了幾百家店的資料後，後來審查標準越來越寬鬆，還發現很多神奇的經營型態，與其說店裡有貓咪，大部分可能是別人帶去的貓咪。或是人家就是在賣貓咪/送貓咪的，只是有其它附屬經營模式。
還有些是薛丁格的貓，例如開在山上，或是一些遠離市中心的商店、景觀餐廳、花園、合法民宿，然後外面的貓跑來場地裡面，然後 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，每次資料更新時，會自動重新建置出網站中每個縣市的清單頁面，免費版的每月建置時間是有限的，所以要好好控制。
| AI輔助 | 傳統古法作業方式 |
|---|---|
| 指揮 AI 用 Google 的 API 完成需求 | 研究這個需求要用哪支 API、哪個欄位是我們要用的，花時間開發與測試 |
| 指揮 AI 用 GitHub 的 API 完成需求 | 研究這個需求要用哪支 API，花時間開發與測試 |
| 指揮 AI 用 LINE 的 API 完成需求 | 研究這個需求要用哪支 API，花時間開發與測試，平常還要在社群蹲點，看一下近期有沒有什麼坑 |
| AI 寫的程式可能比人寫得更漂亮 | 取一個好變數、寫註解、把主功能做完就花掉不少時間。多來幾個隕石級+限時需求，輕鬆把整個 chatbot 對話狀態流程改得面目全非 |
| 每次功能變更時，讓 AI 更新文件，人類審核 | 人類懶得更新文件，下次打開程式碼時要努力回憶之前做了啥東西 |
| 更輕鬆做完各種資料檢查程式、佈署流程設定 | 這是獨立的工作職缺，不是什麼誰寫程式跟當客服之餘「順便」做一下的事情 |
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 程式。不支援的瀏覽器就不會跑出表單元件預設樣式按鈕。
以前的那種允許視窗是縮在左上角網址列下方(如上圖的上半部)，然後容易被 UX 使用者體驗產品設計大師挑毛病，說容易被使用者忽略。網頁前端人員又要準備爆氣，瀏覽器的原生視窗要長怎樣才不是程式碼能控制的，但現在前端開發者還真多了一種選擇。
這個新功能的第一個好消息，是瀏覽器的權限要求視窗(permission promp)跑到畫面正中間(如上圖的下半部)來了。
但更多怪問題也來了，第一個碰到的怪問題，就是那個按鈕竟然顯示簡體中文字「使用精确位置」(如下圖)!!
冤枉啊，大人，那個文字跟圖示都是瀏覽器自動產生的，網頁本身是 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)
- 還有限制頁面上放的數量是有限的，所以像本文上面範例放了近10顆，有幾顆點了會沒反應。(Maximum limit of 3 permission elements has been reached. More permission elements can be added but they will not be clickable)
因為本來橘底白字的按鈕，對比度只有1.9，把背景色加深，改成官方規範的對比度3以上，geolocation 按鈕的請求權限功能又恢復正常了。
結語
吸貓地圖的網站還是一開始手寫的那個網站，
一切營運成本還是在免費範圍，
但整個資料更新和管理流程，已經靠著 AI coding 得到大升級。
透過 LINE 聊天機器人、Python 影像辨識程式，瀏覽器擴充套件，本機 Node.js 資料後台、CI/CD 流程。將一個休閒專案的資料維護、發佈流程做得更完整。
一般使用者瀏覽的前台保持純靜態、後台流程全自動化，整體架構變得可控、好調整，也不太會出奇怪的管理複雜度與維護風險。
還好當年剛做的時候沒有太有行動力，不然早做早受苦，晚做晚享受。