這週幾個專案不約而同地踩到同一種坑：直覺告訴你往某個方向走，但數據或追查結果把你拉回來。凌晨切市電反而比清晨貴；驗證 middleware 放對層卻選錯型別斷掉 SSE；同一套費率寫了五份各自演化，對帳時才發現數字早已分叉。這篇週報記錄四個反直覺的工程發現，以及背後的設計取捨邏輯。
凌晨切市電，比清晨多花 15 元、多浪費 10 度太陽能 #
電池電量偏低時，「越早切市電越保險」是很常見的直覺判斷。但這個直覺隱含了一個沒有被驗證的假設：晚切會讓電量不夠用。實際上，凌晨沒有太陽能發電，此時切市電是在用市電「保住」一塊隔天太陽能本來就會補回來的電量——相當於花錢買了一個不存在的風險緩衝。
Solar Monitor 儀表板新增一張每 10 分鐘自動重算的智能切換決策卡片，核心問題是「現在幾點把負載切到市電最划算」。模擬結果顯示，凌晨 00:00 切比 06:00 切多花約 $15、多浪費 10.5 度太陽能——06:00 切讓太陽能從容充電，市電只補真正的缺口。卡片同時跑中位（P50）與保守（P10）兩套天氣預報，讓使用者直接看到「天氣不如預期時這個決策是否還安全」。切換建議本身設有抑制機制：若最優方案與維持現狀的差距低於閾值，顯示靜態灰色提示而非行動建議，避免在費率無差異時產生誤導性的金色提示。
任何涉及「儲備 vs 即時補給」的調度決策，都值得做敏感度模擬——直覺往往預設了一個不存在的風險。把「維持現狀的最優方案」也算出來並放在旁邊對比，是讓自動建議系統不過度干擾使用者的關鍵設計。
SSE 長連線一直掉，問題出在 middleware 型別不是網路 #
我們將 crawl4ai 部署為 Claude Nexus 機群共用的集中式抓取服務，核心需求是在一個地方截斷過長的 markdown 輸出、防止 LLM context 被網頁內容淹沒。部署後 SSE（Server-Sent Events）長連線持續掉線，症狀看起來像是網路不穩，但換網路環境後問題依然存在。
追查根因後確認是 FastAPI 的 BaseHTTPMiddleware 在處理 SSE 回應時，會把串流 response 包進 body_iterator，中斷了長連線的維持——這不是 bug，而是 BaseHTTPMiddleware 的設計限制，它假設 response 是一次性的 body，而非持續串流的事件流。修法是把 Bearer Token 驗證從 BaseHTTPMiddleware 改成 pure ASGI callable，後者完全不碰 response body，驗證通過後直接把請求交給下一層，SSE 串流得以保持完整。程式碼裡加入了封印註解，說明為何不能改回 BaseHTTPMiddleware，防止日後被「整理」掉。
凡是 SSE 或 WebSocket 這類長連線協定，middleware 的選型需要特別謹慎——任何會在 response 層「包一層」的 middleware 都可能破壞串流行為。驗證手段不能只測「收到第一個事件」，要測長連線能否撐過完整的串流週期。
同一套手續費邏輯寫了五份，對帳時才發現數字各自漂移 #
量化交易系統在做完整對帳時，損益數字與券商報表出現落差。表面看起來是小額誤差，但追查後發現整個系統散落了五套各自獨立的手續費計算邏輯，每套的四捨五入規則略有不同，最低門檻的套用位置也不一致。更嚴重的是，入金記錄直接調整了初始資本欄位，導致那天的日報酬率異常跳升，連帶污染了 Sharpe Ratio 與累計報酬計算。
核心修法是新增統一的費率計算模組作為全系統唯一來源，所有計算點改為呼叫同一函式，消除各自為政的規則分歧，並回補了歷史交易的累計誤差。入金問題則新增資金流水記錄表獨立追蹤資金進出，初始資本還原為最初投入金額，各績效指標分母改用「累計投入本金」，日報酬計算時扣除當日淨流入，才能還原真實操作績效。修法的核心取捨是「寧可多一次資料庫查詢，也要用實際記錄值，而非重新推算」——讓系統在費率規則未來變動時仍能保持正確，而不是在每個計算點埋下隱性的規則假設。
費用計算、成本分攤、績效基準，每多一個獨立實作就多一個漂移點。對任何涉及金融計算的系統而言，「同一個概念只有一個實作」是資料正確性的前提，而不只是程式碼整潔問題。一旦規則在任何一處更新，其他地方立刻落後。
回測賺錢、實盤不賺，落差終於有了具體數字 #
量化策略在回測環境表現良好，切換到實盤後績效往往大幅縮水——這個現象在量化圈很常見，卻鮮少有人能說清楚「到底差多少、為什麼差」。根源是兩套引擎的計算路徑根本不同：回測引擎一次看完整資料段計算所有訊號，即時引擎每根 K 棒只能看到截至當下的資料，rolling 指標的計算天生就不一樣，加上成交價假設也不同，造成系統性落差。
為了讓使用者能自行驗證落差，我們開發了「即時重播」頁面：選定策略版本、商品與日期後，後端用與實盤完全相同的執行路徑逐根餵歷史 K 棒，每根只讓策略看到截至當下的資料，進出場邏輯與觸價規則與實盤一致。前端呈現 K 線圖進出場標記，並加入回測引擎與即時引擎的並排比對表，直接顯示每筆交易的點數差與損益差。初次驗證結果顯示，同一張多單在兩套引擎下的獲利差距達 6.7 倍，這是首次能以具體數字向客戶說明落差來源，而不是憑感覺估計。
「用實盤路徑重播歷史資料」是驗證回測可信度的正確方式，也是向客戶解釋實盤表現差異的溝通工具。任何引入量化策略的團隊，都值得在正式上線前先量化這個落差——否則部署後看到的每一次虧損，都無法判斷是策略失效還是引擎差異。
本週其他進展 #
- emobile 2.7.19 發布：同步週期縮短至 60 秒 — 商品與分類同步週期從 5 分鐘縮短至 60 秒，操作介面兩顆分工不明的同步按鈕合併為「立即同步（全部）」並顯示各類別同步筆數。同步修正分類刪除未同步的根因：Windows 推送的清單即為權威清單，Hub 自動將未收到的分類標為停用，確保平板端顯示與 Windows 端一致。
- EMOBILEALL 交付工具鏈全面完工 — Electron 桌面端打包問題定位修復，Biz、Store、Dine、Shop 四個版型均可成功 build 並啟動；provision --demo 指令自動備妥示範資料（賣方、字軌、商品、客戶、發票）；卡機協定層 36 項測試、部分退款 13 項 e2e 測試本週一併完成，累計推至 37/55 功能項，全庫型別檢查全綠。
- instantnews 修復靜默失敗問題並升級爬蟲方案 — 引入 FatalCrawlError 型別，讓額度耗盡、Token 失效等整平台不可用的錯誤穿透兩層 catch 上報，修前 crawl_logs 誤記成功、修後正確記錄錯誤訊息；同步修正監控起始日被改為動態當天導致歷史資料遺漏的問題，並補齊活動期間因服務中斷遺漏的粉專貼文。
- Claude Nexus 機群版本清理與 Windows 升級修正 — 清除機群中舊版殭屍 claude binary（互動 shell 遮蔽症狀、非互動環境才暴露），補入機制要求日後掃查必須對全部機器跑同一條檢查指令。Windows 升級腳本因 bash heredoc 產出的 PowerShell 檔案缺少 UTF-8 BOM，導致靜默跳過覆蓋步驟，補 BOM 後修復，診斷指紋（升級輸出缺 Applied launcher 欄位）已記錄。
- 3q3.com.tw 運送單選單過濾邏輯修正 — 修正運送單頁面停用帳號（含歇業站點與停用廠商）混入選單的問題，以及倉庫帳號無法被選為出貨方的前後端邏輯不一致問題，改為白名單策略並單獨補入兩個例外帳號，正式站實測驗證通過，同日建立的真實運送單均選到正確站別。
- YISEN 授權碼工具改為獨立 exe，交付文件分層 — 授權碼簽發工具由網頁版改為 PyInstaller 打包的獨立桌面程式，雙擊即用，不依賴 Python 環境，私鑰自動定位且公鑰比對狀態明確顯示；客戶交付文件與內部操作文件正式分離，客戶端只收安裝與資料轉入流程，授權機制細節僅保留在內部版。
- 倉儲清潔週報工具上線，自動產出加戳照片與 Word 表格 — 開發並部署至內網的 Web App，操作者拖入照片、確認時間後一鍵下載含加戳照片與完成 Word 表格的 ZIP；照片張數自動判斷站點免除人工切換，PhotoCap 流水號跨次持續累加確保編號全局唯一，消除過去人工填表的欄位順序錯誤與字型不一致問題。
- 某客戶網站替換影片並加入雙影片並排版面 — 替換主展示影片並壓縮至原始大小約 48%，src 加版本查詢字串確保 CDN 快取失效；同一頁加入第二支影片，採 CSS grid 依各自長寬比分配欄寬，視覺高度自然對齊，桌面與手機版均截圖驗證，正式站透過 WP File Manager API 部署，傳輸前後 md5 驗證一致才覆蓋 HTML。
- FATE 廣告歸因鏈斷裂診斷 — 診斷某電商 GA4 廣告歸因鏈斷裂根因，發現兩個獨立問題：GA4 與 Google Ads 帳戶從未連結導致 gclid 無法傳遞，以及網站完全未埋電商追蹤事件（purchase、add_to_cart）。提供分層修復路徑，前者可由 GA4 管理側修復，後者需轉交網站負責人補埋追蹤代碼。
- 某製造業客戶 ERP 遷移：退貨沖銷與電子發票稅額修正 — 實作負數應收帳款沖銷機制（比對舊系統 107 張負數出貨單確認習慣），修正 getOutstanding 函式將負數列排除的邏輯漏洞；ETL 稅額欄位對應錯誤（OVER 旗標欄誤對應至 externalTax）透過比對 VFP 原始碼確認並修正，5 組驗算金額均滿足財政部容差標準，電子發票不再退件。
- planmaker 廣告出價策略調整，三天內平均 CPC 顯著下降 — 搜尋廣告設置單次點擊出價上限後，三天內平均 CPC 大幅下降、點擊量同步提升，驗證用出價上限取代手動排字的策略有效；電商促銷贈品觸發機制改以商品 ID 為依據，解耦折扣邏輯，引入 exclusiveGroup 控制多贈品庫存競爭，POS 端補發 noGiftCount 欄位避免套組金額被誤計入滿額累計。
- 某餐飲業者線上點餐網站上線，完成 LINE Pay 審核環境 — 為客戶部署配備 SSL 憑證的線上點餐網站，產出審核截圖，完成 LINE Pay 申請審核所需的線上環境，完成最新版本打包。
本週技術心得 #
這週跨多個專案收到同一個教訓：最危險的錯誤不是明顯報錯的那種，而是系統確實在跑、數字確實在出，只是計算起點從一開始就偏了。費用計算散落五個地方各自演化；middleware 選了正確的位置但錯誤的型別；切換時機的直覺忽略了「不切其實電也會補回來」這個隱性假設；回測引擎和即時引擎的差距大家都知道存在，卻沒有人量化過它。
這類問題有個共同特徵：在正常路徑下永遠不會觸發，只在做完整對帳、壓力測試、或碰到邊界條件時才暴露。對中小企業的 IT 系統而言，要提前發現這類問題，最有效的方式是把「可驗證成功條件」納入設計本身——每個計算路徑都要有一個能回答「這個數字從哪來、怎麼驗」的錨點，而非等到外部對帳或客戶回報才反向追查。這個習慣不是額外的測試工作，而是在設計階段就確認「我怎麼知道這是對的」，它讓每一次修改都有明確的成功定義，而不是靠感覺判斷「應該可以了」。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。