ai-agent 精選
我跟 AI 說我很累，它沒有安慰我，它去量了
量出來的答案不是「工作量太大」，是這套系統裡有三層東西在對我說謊，而我是唯一在檢查它們的人。兩天後四件事做完三件——而每挖開一層，底下的東西都比診斷書上寫的更深。最深的那一層是：反幻覺檢查的事實基礎，是幻覺本身。
[CODE]
技術文章
google-ads
那個把你最想要的訂單擋在門外的否定字
否定字的傷害天生看不見——它擋掉的查詢從不出現在任何報表裡。這篇講一個兄弟帳號怎麼變成揭穿它的對照組，以及為什麼「東西存在」不等於「東西在生效」。
astro
第三種狀態，業主設定起來零成本
民宿官網的空房表原本只有兩種狀態：可訂、已訂。業主需要第三種——連假鎖起來、引導客人打電話的日期。難的不是狀態本身，是怎麼讓忙碌的業主不可能設錯。
llm
那個死不掉的建議：抓到一個 LLM 從結論倒推回去硬凹
一份週報用錯的指標建議改廣告的到達頁。當驗證器逼它承認指標用錯，模型沒有放棄那個建議——它捏了一個新數字繼續撐著。這篇講怎麼擋這種行為。
astro
促銷貼滿全站，唯獨沒貼在廣告落地的那頁
民宿的暑假平日優惠，橫幅跑了、促銷卡也做了，但 Google Ads 實際導流的兩個房型落地頁上，什麼都沒有。這篇講怎麼把缺口補上，順便把促銷卡做成業主自己能挑顏色、附即時色塊預覽的一套自助系統。
claude-code
一個指令接好一個新客戶——再用 CI 守門員把這套劇本擋在 main 之外
以前接一個新民宿進分析 agent，要手動重跑十幾個容易出錯的步驟。我把整段流程包成一個 Claude skill，一個 session 跑完；然後加了一道 CI 守門員，確保這個塞滿內部路徑和 secret 配置的 skill 永遠不會進到公開分支。
ai
廣告一個檢查點，網站兩個：人該站在流程的哪裡
把 ads-execute skill 從「讀報告才動」改寫成端到端流程——AI agent 自己做診斷、改廣告帳號、改網站程式碼，而人只在審查真的會影響結果的地方出現。廣告改動一個檢查點，網站改動兩個，這個不對稱就是整個設計。
google-ads
知道跟做到之間的斷層：用可審閱的 YAML 改動真實廣告帳號
健檢報告告訴你哪裡有問題，但它什麼都不會改。這篇講的是把報告結論變成 git 追蹤、dry-run 預覽的 Google Ads 改動的執行 skill——以及那條不准把正在轉換的關鍵字停掉的防呆規則。
astro
假裝延後的延後：requestIdleCallback 在 Lighthouse 模擬器裡其實是立刻執行
兩個在真實瀏覽器裡看起來完全正確的延後載入策略，在 Lighthouse 模擬器裡都會立刻觸發——把 317KB 的 gtag 腳本和 17MB 的影片拉到 LCP 關鍵路徑上。四個民宿廣告到達頁衝到 90 分的過程。
nextjs
一張表單管兩館：分館選項，還有那個生出重複日曆的競態
當一位業主經營兩館、各館的訂房管道不一樣，一張共用表單就得跟著房源變形。而第一次多房源送出時，悄悄生出了兩個 Google 日曆——直到把送出改成依序執行才解決。
retrospective
2026 Q3 回顧：從民宿網站，長成一套會自己優化的廣告營運系統
這一季把幾個恆春民宿的網站，變成一套會量測自己、每週產報告、現在還能自己調整 Google Ads 的系統。上線兩個新站、做出讓業主自己改內容的後台，分析 agent 也把點擊代理指標換成了真實訂房資料。
GA4
一次 gtag、兩個去處：用 send_to 把 GA4 和 Ads 徹底分開
把一套驗證過的 GA4＋Google Ads 追蹤實作打包成可重複使用的 skill。核心規則只有一條：一次 gtag.js 載入、每個去處各自 config、每個事件都用 send_to 指明去哪——讓行為數據和轉換數據永遠不會互相污染。
case-study 精選
跑了好幾年的廣告帳號，學的是錯的東西
一家恆春的民宿，廣告憑感覺跑了好幾年。帳號把「客人查地圖導航」設成轉換目標，Smart Bidding 學的是吸引查地圖的路人，不是想訂房的客人。換一個正確的轉換目標、清掉幾百條無效關鍵字，一週學習期之後，找到了完全不同量級的客人。
typescript
一個 OAuth、五個廣告帳戶，與那道拒絕改錯帳戶的防線
一個共用的管理員帳戶 token，讓每個站台的流程都能存取每個客戶的廣告帳戶。解法不是多開憑證，而是把「該動哪些帳戶」的決定收到單一個地方，並把退路從靜默擴張改成大聲出錯。
analytics
分析對了之後，三個還沒對的事
把訂房資料接進週報系統，解決了指標虛假的問題。但底下還有三個系統張力沒動：執行層的邊際成本、歸因的精準度、以及驗證器擋不住的那種幻覺。
case-study 精選
廣告跑了一整年，系統什麼都沒學到
恆春兩家民宿的 Google 廣告跑了好幾年，後台轉換數一直掛零——因為落地頁在別人的網站上，根本裝不了追蹤。把落地頁換回自家網站、修好追蹤之後，單週詢問量翻三倍，YoY 營收破百。這是完整的來龍去脈。
typescript
四個 job 抓同一份資料：把 per-site 趨勢爬取收成一份市場快取
恆春九家民宿共用同一個觀光市場。Google Trends 管線卻跑四個一模一樣的爬取，對一個會限流的 API 打四次，產出四份完全相同的資料。修法是認清這份資料從來就不是 per-site 的。
astro
大家都在看、卻沒人行動的照片頁
相簿頁帶來流量，卻幾乎沒帶來任何聯絡。解法不是重新設計，而是把聯絡入口放在使用者真正所在的位置，並讓它觸發廣告引擎本來就在最佳化的同一組轉換訊號。
typescript
教驗證器相信一個百分比——還有當它沒辦法相信時，該怎麼放行
每份週報新增的轉換漏斗四層健檢、差點把它擋掉的反幻覺驗證器，以及為什麼一份無法驗證的報告現在會寄給維護者、而不是讓整條流程直接崩潰。
ai
讓廣告健檢 AI 別再建議「早就做完的事」
每週的 Google Ads 健檢一直叫民宿業者去關掉早就關掉的設定、去補早就補好的受眾訊號。解法不是把提示詞寫得更好，而是在模型開始推理之前，先把當前設定值塞給它看。
infrastructure
三天漸進斷線：Cloudflare 代理遮住了 Railway IP 換掉的事實
Railway 換了底層 IP，Cloudflare A record 還指著舊的 Fastly 位址。DNS cache 各地陸續失效，流量在三天內跌至正常水位的 1%。Cloudflare proxy 讓錯誤看起來像 SSL 問題——診斷路徑多繞了一層。修法：A record 換成 CNAME，讓 Railway 自己追 IP。
nextjs
輸入訂房資料的人，今年七十歲
在沒有 gclid 的情況下把真實成交資料送進各自的 Google Ads 帳戶，同時設計一個讓七十歲老闆娘每天願意用的輸入介面——兩個限制塑造了同一套系統。
typescript
訂房記錄這套東西，只有在沒人弄丟資料的前提下才成立
當民宿老闆開始把每一筆訂房手動記進這個 App，這些資料就變成廣告優化的真實依據。所以在信任這些資料之前，這個工具得先有備份、安全部署、測試日曆隔離，還有衝突檢查。
ga4
兩個廣告帳號、一張訂房表單，還有一筆沒有點擊 ID 的轉換
一位業主兩館民宿，各自一個 Google Ads 帳號。一張共用的訂房表單，要把每筆訂房送到對的帳號——而且手上沒有 gclid 可以歸因。為什麼最後選的是 GA4 事件名稱分流，而不是直送 Conversion API。
analytics
點擊從來就不是訂房
把 GA4 聯絡按鈕點擊換成 Supabase 真實訂房資料——解開 gclid 限制、讓兩個 Google Ads 帳號透過同一個 GA4 property 分流不污染，再把輸出拆成「收到訂單」和「實際入住」兩個視角。
google-ads
廣告自動化上線的兩個 bug：config domain 打錯、LLM 路徑亂猜
新民宿的廣告活動結構完整、文案正確——但每一個 URL 指向的 domain 根本不存在，另外還有四個 sitelink 連到 LLM 自己發明的頁面路徑。兩個獨立的 bug，同一次跑出來。
analytics
週報吃的是真實訂房，不再是點擊
Google Ads Smart Bidding 拿網站點擊當轉換學了好幾個月。填補這個缺口，得先建一個七十歲老人會每天用的記錄工具，再讓每一筆確認訂房同時接進 Supabase、Google 日曆和 GA4 Measurement Protocol。
case-study 精選
九間民宿、三個月：數位化究竟需要什麼
三個月、台灣九間民宿、五個 codebase。建的不只是網站：還有自動化週報、Google Ads 健診，以及讓業主不需要打開 GA4 也能收到決策建議的分析 pipeline。這是那段工程的真實面貌，以及 AI 在其中的邊界在哪裡。
astro
架設雙語 Astro 頁面，以及三個只有新內容才照得出來的問題
民宿網站新增 BBQ 和生日套餐的雙語頁面，功能本身沒什麼難的。後面三個 bug 才有意思：單引號字串裡的撇號讓 build 在下游崩潰、四個 CSS class 在語系副本之間悄悄消失、水印的 pseudo-element 在深色 hero 底下現出原形。
b&b 精選
週報終於不再數錯東西的那一週
幾個月來，民宿分析引擎一直拿網站上的聯絡按鍵點擊當轉換指標——因為 GA4 只看得到這個。直到真實訂房資料變得可讀，週報對轉換漏斗講的每一句話都得重寫。
astro
在 Astro 靜態頁面追 LCP 與 CLS
Lighthouse Mobile 76，業主 Quote 寫的是 ≥ 90。Hero image 274ms 就下完了，瀏覽器還等了 1,756ms 才能畫面。三個根本原因，兩個跟圖片無關——CSS、preload scanner 盲點、Google Fonts。
astro
五個民宿網站、一套自助更新架構：後台才是真正要解決的工程問題
五間恆春民宿、三種部署策略、一套共用的 GitHub App 後台——以及為什麼讓業主自己改定價，才是所有技術決策的起點。
typescript
四個容器換一個 Cron：替民宿業者重設計廣告自動化引擎
原本跑在 Railway 四個容器上的 n8n，一週只跑一次但 99% 閒置。遷移到 Python + GitHub Actions 之後，多帳戶支援從一開始就內建在架構裡，每次帳戶異動都需要明確的人工確認才能執行。
product
CastLoop：信任是這個平台的基礎建設
台灣釣魚圈靠關係傳遞真正有用的資訊，不靠平台。CastLoop 的整個架構——從 Zod 邊界驗證到 Helper 核准前的聯絡方式門檻——都從同一個問題出發：如何讓陌生人的可信度在接觸前就變得可讀？
astro
GA4 是基礎設施，不是儀表板
五間恆春民宿共用一套廣告優化管線。其中一間的 GA4 property 從網站上線就是空的——廣告帳戶一直在花錢，優化引擎在讀零。要讓埋點撐住持續迭代的事件邏輯、隔離 staging 流量、讓下一間能直接套用，架構比貼一段 script 複雜得多。
astro
打造一個掌控自己訂房的民宿網站
為恆春一家民宿打造直客訂房網站的第一塊地基：自助後台透過 GitHub App 寫進版控、GA4 三層主機分流追蹤 CTA 意圖、WebP/AVIF 流水線處理 81MB 照片、路徑感知 CSP——以及為什麼 Google Ads 活動在這個網站上線之前根本不能跑。
astro
把客戶工作變成技能：打造一套可複製的數位營運架構
四個禮拜、三份 AI 可執行的操作手冊，讓這個規模的業主第一次用得起正確的數位行銷。技術本身不新，改變的是誰能用得起、用得上。
astro
先接好事件，再談效能：恆春民宿直客管道的量測補建與 LCP 三層問題
廣告在跑，轉換計數是零。歸因沒建好之前，優化效能只是在替一個沒有回饋迴圈的漏斗打磨外觀。這篇記錄量測層的決策邏輯、在自己架構裡挖出的三個 LCP 問題，以及 Cloudflare 進場是為了解決一件事、失敗了、但意外帶來另一個 11 倍改善的完整過程。
typescript
把民宿廣告自動化從 n8n 搬到 GitHub Actions：保護規則要在兩個地方
原本跑在 Railway 的 n8n 廣告分析工具，四個容器 24/7 待命，一週才跑一次。搬到 Python + GitHub Actions，零基礎建設費用，但真正有趣的不是省錢——是 14 天關鍵字保護規則必須同時寫在系統提示詞和程式碼裡，因為提示詞一個人守不住。
deepl
讓 RSS 聚合器自動翻譯：一個 AI/ML 閱讀基礎設施的迭代
十七個英文來源、每月五十萬字元上限、一個在入庫時就翻好的 SQLite 聚合器。API 呼叫只有三行，前面的決定花了兩個禮拜。
bnb 精選
一套數位運作層、一個工程師、一條反幻覺回饋迴路：墾丁民宿的廣告與報告自動化
平台佣金遠比外界想像的高，而且帶走的不只是錢。這篇記錄我如何用 Astro 網站、GA4 分析、TypeScript 週報引擎和 LLM 驅動的廣告健檢，為恆春半島九家小型民宿搭起一套之前在任何價格帶都不存在的數位運作系統。
astro
把鑰匙交給業主：靜態網站背後的自助後台
民宿每改一次促銷都要找我，這個卡點讓行銷節奏永遠落後現實。Astro SSR 後台、GitHub App commit pipeline、加上讓業主編輯不被部署蓋掉的 branch promotion 腳本，把這條依賴關係拆掉了。
android
那個不該存在的狀態
TackleBox 的 UI 一直顯示業務邏輯從來沒打算製造的狀態組合。問題不是少了 null check——型別系統本身允許那個狀態存在。
og
為什麼你的 OG 圖片在 LINE 上不顯示：六個要確認的地方
LINE 分享出去是空白卡片，不管原因是哪個，症狀都一樣。這是我在一家恆春民宿網站上花了三個小時的紀錄——Facebook Sharing Debugger 顯示正確圖片，LINE 還是空白，最後找到的診斷順序。
claude-code 精選
PM → Architect → Engineer → QA：一個人跑多 Agent Pipeline 的真實紀錄
恆春民宿業者需要正式的 web 系統，但負擔不起一個開發團隊。結構化的多 agent pipeline 讓這個品質等級在可負擔的成本裡變得可行——代價是所有的錯誤修正機會全都集中在我一個人身上。
ga4
替不看 GA4 的客戶，自動生成每週分析報告
四家恆春民宿設好了 GA4 轉換追蹤，業主從來不看。我建了一套多資料源 pipeline，每週一早上自動拉 GA4、Search Console、Google Ads 資料，送進三階段 LLM 分析，把中文週報直接寄進業主信箱——不需要登入任何地方。
github-api
不用資料庫的民宿後台：GitHub App + Octokit
引進 CMS 是在解錯問題。我給一家恆春民宿建了後台，透過 GitHub App 直接對部署分支發 commit，不需要獨立資料庫，Railway 90 秒完成部署。
astro
Astro i18n：那兩個字我沒打，整個下午就沒了
Code & Cast 的 CI pipeline 要同時發布兩個語言版本的文章。這篇記錄 Astro i18n 層裡每個迫使你自己動手補的缺口：trailing slash 死結、content collection 不認識翻譯關係、entry ID 小寫化、以及用 TypeScript 在 build time 攔截漏掉的翻譯。
ddd 精選
用 TypeScript 實作 DDD：多出來的那些層什麼時候值得
Code & Cast 的內容由兩個自主 CI agent 負責寫作。DDD 分層架構存在的原因不是最佳實踐，而是要讓這個系統安全運作——Zod runtime 合約、結構型別讓測試不依賴框架、bounded context 隔離兩個獨立 agent。這篇談哪些設計真正賺回成本，哪些只是架構儀式。
claude 精選
每週 Google Ads 管理、零基礎設施成本：用 Claude 替恆春民宿做關鍵字分析
月報是事後記錄，不是管理。我把兩間恆春民宿的 Google Ads 週分析從 n8n Railway 四個長駐服務搬到 GitHub Actions，成本從每月 $10 降到接近零，並且解釋為什麼 14 天保護規則需要同時活在 Prompt 和程式碼裡。
google-sheets
試算表就是資料庫：用 Google Sheets 當狀態機
替恆春民宿業者建 Google Ads 關鍵字治理系統——以及為什麼她每天早上本來就在看的那張試算表，比我能建的任何後台都更有效。
android
Android Clean Architecture 重訪：三年維護模式真正讓你失去了什麼
14 年 Android 開發、3 年維護模式，然後是 TackleBox：一個刻意設計的 greenfield 重置，用來找出現代 Kotlin + Compose + Clean Architecture 留下的盲點在哪裡。
sqlite
那個什麼都沒做的搜尋框：用 SQLite FTS5 處理五萬筆聚合資料
入庫流水線跑了六個月、累積了五萬筆資料，檢索那一側悄悄壞掉了。為什麼在這個規模上 FTS5 打贏了 Algolia 和 Elasticsearch，以及 production 實作真正長什麼樣子。
github-actions
四個容器跑四個 cron job：我把 n8n Queue Mode 換掉的原因
一套每週執行一次的 LLM 關鍵字管理系統，跑在永遠在線的四個容器上。真正的代價不是費用，而是某個容器靜默失敗七天、由客戶先發現這件事。