鐵人檔案
這是一個正在正式站上線的訂閱制服務的真實維運紀錄，不是概念展示。系列依序記錄技術架構、十個真實踩過的地雷（SQL跳脫、時區換算、資料單位混淆等）、訂閱分級與第三方訊息平台整合、AI內容生成的容錯設計，以及自動巡檢代理與CI/CD部署驗證機制。誠實記錄Claude Code在架構決策、地雷排查與日常維運代理中實際扮演的角色，給想一個人維運商業服務的開發者一份可直接參考的實戰紀錄。
事故現場 App 使用者回報截圖：畫面上的錯誤提示顯示著 [object Object]。 任何寫過 JavaScript 的人看到這串字都知道發生了什麼：一個...
事故現場 這條雷不是「炸」的，是「勒」的——它沒有造成任何一次事故，它造成的是每次改動都痛一次、綿延好幾個月的技術債利息。 服務最初的訂閱模型很單純：免費 vs...
事故現場 雲端資料庫服務商寄來用量警告：資料傳輸量暴增，額度快燒完了。服務功能一切正常、沒有任何錯誤、使用者毫無感覺——但帳單背後，某段程式碼正在以驚人的頻率重...
從 Day 12 的廢墟上重建 Day 12 講了 is_premium 布林旗標怎麼變成技術債。今天講重構之後的設計長什麼樣——一套撐得住「等級會增加、會停售...
一個反直覺的工程決策 服務的金流串接——收單服務商介接、訂單建立、付款回調、開通訂閱、對帳——全部做完了，然後用一個旗標整個關起來，一天都沒有開過。 聽起來像做...
從一個看似簡單的需求開始 服務裡有一套點數機制：完成某些里程碑（首次設定、連續使用等）發放點數，點數可以兌換進階內容。需求聽起來是 CRUD 入門題：「達成條件...
為什麼要接訊息平台 服務的通知管道除了 App 推播，還接了一個大眾普及率極高的訊息平台官方帳號。理由很實際：使用者不一定裝 App，但幾乎人人都用這個訊息平台...
一個思想實驗 想像這個場景：某次改版引入一個 bug，通知排程的去重邏輯失效，每 30 秒一輪的排程，每輪都把同一批通知重發一次。你睡了 8 小時，醒來時它跑了...
一人公司的客服困境 訂閱制服務一定有客服需求：帳務問題、功能疑問、操作卡關。而一人公司的殘酷現實是：你就是客服，而且客服時間直接從開發時間裡扣。所以客服體系的設...
需求：每天給訂戶一份 AI 生成的摘要 服務有一項訂閱功能：每天固定時段，用 LLM 把當天的資料整理成一份易讀的摘要內容，推送給訂戶。這是訂戶最喜歡的功能之一...
