技術文章

延續上一篇的問題 在上一篇文章中，我們遇到了一個問題：Link Table 資料遺失導致使用者沒有角色，所有 API 都回傳 401。 文章最後我拋出了一個問題： 如果你的系統把角色資訊 cache 在 Redis、JWT claim、或 BFF 層，當 Link Table 資料不正確時，系統應該： 名詞解釋： Redis：一種高速的記憶體資料庫（In-Memory Database），常用於快取（Cache）熱門資料，避免每次都查詢主資料庫 JWT claim：JWT Token 內的資料欄位。例如把使用者角色直接寫在 Token 裡：{ "sub": "user_123", "role": "admin" }，這樣就不用每次都查 DB BFF（Backend For Frontend）：一種架構模式，在前端和後端 API 之間多一層「專為前端服務的後端」，常會在這層做權限快取 立即全站拒絕？ 繼續相信 cache？ 還是進入 degraded mode？ 我的選擇是：進入 Degraded Mode。 這篇文章會解釋為什麼，以及如何實作。 一句話定義 Degraded Mode = 系統已知自己「部分不可信」，主動降級功能以維持安全與可用性。 不是壞了、不是裝沒事，而是： 我知道哪裡壞 我知道哪些功能不能給 我知道要保住什麼 為什麼不選另外兩個方案？ ❌ 方案 A：立即全站拒絕 所有 API → 401/503 → 業務全掛 問題： 使用者完全無法使用系統 對業務衝擊太大 「寧可錯殺一百」的策略在商業系統中代價過高 適用場景： 金融交易、醫療處方等「錯了比沒有更糟」的場景 ...

問題現象：登入成功卻被拒於門外 最近在 Staging 環境遇到一個詭異的問題：使用者登入成功，拿到了有效的 JWT Token，但存取任何需要認證的 API 都回傳 401 Unauthorized。 # 登入成功，拿到 token POST /api/auth/local → 200 OK { "jwt": "eyJhbGc...xxxxx...your-jwt-token", "user": { "id": 1001, "email": "user@example.com" } } # 但存取個人資料失敗 GET /api/users/me → 401 Unauthorized Token 驗證通過、使用者存在、帳號未被封鎖。問題到底在哪？ 根本原因：遺失的 Link Table 經過一番追查，發現問題出在資料庫同步時漏掉了關聯表（Link Table）。 什麼是 Link Table？ 在關聯式資料庫中，多對多關係需要透過中間表來建立。這個中間表就是 Link Table（也稱為 Junction Table、Join Table、或 Pivot Table）。 使用者與角色的關係： 一個使用者可以有多個角色（User → Roles） 一個角色可以分配給多個使用者（Role → Users） 這是典型的多對多關係 各種 ORM 的 Link Table 命名 不同框架的 Link Table 命名慣例不同，但概念完全相同： ORM/Framework Link Table 範例 備註 Django user_groups, user_permissions 使用 _ 連接 Laravel role_user, permission_role 字母順序排列 TypeORM user_roles_role 較長的命名 Prisma _UserToRole 以 _ 開頭 Sequelize UserRoles 駝峰命名 問題的本質：資料不完整 當我們同步資料庫時，通常會注意主要的資料表： ...

引言：一個技術選型的起點 2024 年 6 月，我坐在會議室裡，面對著老闆和行銷總監，準備報告我對公司新系統 CMS 的技術選型建議。這不是一個輕鬆的決定——選錯了，可能浪費數百萬的開發成本；選對了，能為公司省下可觀的人力支出。 經過數週的研究與分析，作為一個架構規劃師同時也是技術決策者，我最終選擇了 Strapi 作為我們的 Headless CMS 解決方案。這篇文章將分享我的決策過程、考量因素，以及最重要的——這個選擇如何為公司省下大筆預算。 什麼是 Headless CMS？ 在深入 Strapi 之前，先理解 Headless CMS 的核心概念。 傳統 CMS vs Headless CMS 傳統 CMS 將前端與後端緊密耦合，網站的外觀和內容管理綁在一起。而 Headless CMS 則專注於內容管理和 API 提供，讓前端團隊可以使用任何技術框架來消費這些 API。 Headless CMS 的核心優勢 特性 傳統 CMS Headless CMS 前後端耦合 緊密耦合 完全分離 前端技術選擇 受限於 CMS 模板 任意框架（Vue、React、Flutter） 多平台支援 僅限網頁 Web、App、IoT 皆可 擴展性 中等 極高 API 優先 否 是 為什麼選擇 Strapi？三大核心原因 原因一：前後端完全分離 Strapi 作為 Headless CMS，天生就是為了前後端分離而設計。這意味著： ...

前言：一個月燒掉 $100 的真實故事 如果你正在考慮升級 Claude Code 的訂閱方案，或者已經升級了卻發現 token 還是不夠用，那你來對地方了。 這不是一篇推銷文，而是一個真實的使用心得。 我從 Pro Plan（$20/月） 開始使用 Claude Code，很快就發現 token 不夠用。心想：「升級到 Max Plan（$100/月）應該就沒問題了吧？」 結果呢？ Max Plan 的 token 也不夠用。 更尷尬的是，我花了大把的 token 去處理一些看似簡單的 bug，像是： 體脂率的小數點精度問題 排便次數顯示 null 和 0 的差異 這些問題聽起來簡單，實際上卻各花了大量 token 去「探索」程式碼。 直到我發現問題的根源不是 token 不夠 (Pro plan是真的不夠！)，而是我沒有找到對的 Skill 來處理這類問題。 問題分析：Token 都燒去哪了？ 讓我用一張圖來說明沒有使用正確 Skill 時的除錯流程： 看到問題了嗎？ 這就是「漫無目的的探索」——AI 不知道該往哪裡找，所以它嘗試讀取所有可能相關的檔案，每次讀取都在消耗 token。 Token 消耗的真相 操作類型 Token 消耗 實際價值 讀取不相關的檔案 高 零 廣泛搜尋 grep/glob 中 低（通常需要多次） 隨機嘗試修復 高 可能為負（引入新 bug） 來回確認「這樣對嗎？」 中 低 我的真實案例：為了修一個體脂率顯示的小數點問題，AI 讀取了： ...

前言 傳統的前端開發流程往往是這樣的：你在程式碼編輯器中修改 CSS，儲存檔案，切換到瀏覽器查看效果，發現不滿意，再切回編輯器調整⋯⋯這個來回切換的過程不僅耗時，更打斷了創意的流動。 Cursor 的 Browser Visual Editor 正是為了解決這個問題而生。 這個全新功能將網頁應用程式、程式碼庫和視覺化編輯能力整合在單一介面中，讓開發者可以直觀地操作介面元素，同時保持與程式碼的同步。本文將深入解析這項創新功能的核心概念、運作原理和實際應用場景。 什麼是 Cursor Browser Visual Editor？ 核心概念 Cursor Browser Visual Editor 是一個整合在 Cursor IDE 中的視覺化編輯工具，它讓開發者能夠： 直接拖拉介面元素來調整佈局 透過側邊欄即時修改樣式屬性 使用自然語言描述想要的變更 讓 AI 自動更新對應的程式碼 這不只是一個簡單的 CSS 預覽工具，而是一個完整的**設計到程式碼（Design-to-Code）**工作流程。 省 Token 的關鍵利器 這裡要特別強調一個重要的實用價值：Visual Editor 可以大幅減少你對 AI 下 prompt 的次數，進而節省 Token 用量！ 想像一下傳統的 AI 輔助開發流程： ❌ 傳統 AI 輔助方式（消耗大量 Token）： 1. "請把這個按鈕的 padding 加大一點" → 消耗 Token 2. 看效果，不滿意 3. "再大一點，然後加個圓角" → 消耗 Token 4. 看效果，顏色不對 5. "背景色換成藍色" → 消耗 Token 6. 還是不滿意... 7. 反覆對話 10 次 → 消耗大量 Token 💸 ✅ Visual Editor 方式（幾乎零 Token）： 1. 直接在面板上拖動 padding 滑桿 → 0 Token 2. 調整 border-radius 數值 → 0 Token 3. 點選色盤換顏色 → 0 Token 4. 即時預覽，滿意為止 → 0 Token 5. 只有複雜變更才需要 AI → 少量 Token ✅ 對於 Cursor 的付費用戶來說，這意味著： ...

為什麼選擇 TWCA OV 證書 在生產環境中，使用自簽憑證會導致瀏覽器顯示不安全警告，影響使用者信任。雖然 Let’s Encrypt 提供免費的自動化證書，但某些企業或政府專案需要台灣在地的認證機構簽發證書以符合法規要求。 SSL 證書的三個等級 SSL 證書依據驗證強度分為三個等級： 證書類型 驗證內容 適用場景 信任標記 價格 DV (Domain Validation) 僅驗證網域所有權 個人網站、部落格 🔒 基本鎖頭 免費～低 OV (Organization Validation) 驗證組織身份 企業網站、SaaS 服務 🔒 組織名稱 中 EV (Extended Validation) 嚴格驗證企業 金融、電商、政府 🟢 綠色網址列 高 本文使用的是 TWCA OV SSL 證書，它提供： ✅ 組織身份驗證（瀏覽器可顯示公司名稱） ✅ 完整的證書鏈（受所有主流瀏覽器信任） ✅ 12 個月有效期 ✅ 台灣在地技術支援 HTTPS 與 SSL/TLS 運作原理 在深入部署之前，先理解 HTTPS 如何保護資料傳輸： 關鍵機制說明： 非對稱加密（RSA/ECDSA）：只用於金鑰交換，確保 session key 安全傳輸 對稱加密（AES）：實際資料傳輸使用，效能更好 證書鏈驗證（完全離線）：瀏覽器使用內建的 TWCA 根憑證驗證整個證書鏈，不需要連線到 TWCA 中間人攻擊防護：因為攻擊者沒有伺服器的私鑰，無法解密通訊 💡 重要觀念： TWCA 只在簽發證書時參與，TLS 握手過程中完全不涉及。瀏覽器使用內建的根憑證庫（包含 TWCA 根憑證）進行離線驗證。 ...

前言：AI 協作開發的範式演進 在 AI 輔助開發工具快速演進的今天，我們已經從「程式碼自動補全」進化到「AI 主動協作」的階段。Claude Code 作為 Anthropic 推出的革命性開發工具，引入了兩種截然不同但互補的協作模式：Subagent-Driven Development 和 Parallel Session。 ...

圖片來源：Google Antigravity 官方部落格 前言：當 AI 從助手變成隊友 2025 年 11 月，Google 悄悄推出了一款顛覆性的開發工具 —— Antigravity。這不是又一個「AI 程式碼補全工具」，而是一個徹底改變我們思考軟體開發方式的平台。如果說 GitHub Copilot 和 Cursor 是你的智慧助手，那麼 Antigravity 就是一支能夠自主規劃、執行和驗證的 AI 團隊。 在深入研究了官方文件、實際案例和社群回饋後，我想分享這個「代理優先」（Agent-First）開發平台的核心理念、創新功能，以及它目前仍面臨的挑戰。 核心概念：什麼是「代理優先」開發？ 傳統 AI 輔助 vs. 代理優先開發 在傳統的 AI 輔助編碼中，開發者仍然是主角：你逐行寫程式碼，AI 只是在旁邊提供自動完成建議。但 Antigravity 提出了一個全新的工作模式： 你不再是程式碼的執行者，而是任務的指揮官。 這個轉變體現在： 傳統模式：「我要在第 42 行加一個函數…」（微觀管理） Antigravity 模式：「建立一個包含搜尋功能的活動網站」（任務導向） AI 代理會： 分析需求並制定計劃 自主執行所有編碼工作 測試應用程式並驗證功能 產生可審查的成果文件（Artifacts） 三個核心介面：Mission Control 架構 Antigravity 設計了三個相互配合的工作介面： Editor 與 Agent Manager 的雙介面架構 1. Agent Manager（非同步任務中心） 這是你的「任務控制中心」，可以： ...