這週工程團隊跨專案遭遇了一類共同挑戰：系統沒有崩潰、也沒有明顯報錯，但某條關鍵路徑早已悄悄停擺。直播串流耗盡後台連線池、密碼過期卻偽裝成登入成功、紙上交易帳戶被真實對帳邏輯誤清，還有 WAF 把合法 session token 當路徑遍歷攻擊封鎖——每一件都在考驗同一個工程能力：在系統「看起來正常」的表象下，找出靜默失效點，並建立可稽核的診斷與防線。
直播串流讓知識庫連線池靜默耗盡，兩個月後才爆 #
Claude Nexus 的瀏覽內容抓取器在某天開始卡死，但沒有任何明顯報錯。問題的根源遠不直觀：使用者幾個月前曾瀏覽過監控攝影機管理頁面，頁面上的兩個直播串流 URL 被瀏覽記錄擷取下來，排進了後續的批次抓取佇列。直播永遠下不完，read timeout 因為資料持續流動而從不觸發，一條 thread 永久卡死、持鎖，後續每批任務再多開一條排隊等鎖，40 條連線池在兩個月後默默耗盡。
診斷的關鍵工具是 py-spy 堆疊快照，直接定位到卡在 socket.readinto 的執行緒，省去所有猜測。修法加了三道防線：副檔名預判（.flv/.mp4 直接跳過）、stream 模式先讀 header 再決定要不要讀 body、body 大小上限控制。過程中同時發現向量資料庫的維度與現役嵌入模型不相容，導致瀏覽內容寫入管線從半年前就整條靜默 rollback，無一筆真正寫入；清空舊資料並升維後，語意搜尋模式半年來第一次真正運作。
直播串流、大型二進位資源是任何抓取器都可能踩到的坑，防線順序應該是「先排除、再讀 header、最後才讀 body」，read timeout 對持續流動的串流完全無效。同樣重要的是：維度不相容這類靜默失效，往往需要主動去查「到底有沒有寫進去」，而不是等報錯。
電壓升 5%、功耗幾乎不變：因果方向搞反才有正確答案 #
為了評估市電電壓調升對功耗的影響，最直覺的做法是拿穩態資料——「這個電壓對應的平均功率是多少」來分析。但這個方向是錯的：電壓偏低本身就是因為負載重導致的線路壓降，用這組資料分析出來的結論是「電壓越高、功率越低」，純屬因果混淆。
正確做法是找「電壓改變但負載幾乎不變」的瞬間，也就是 ATS 雙電源切換事件。利用 Solar Monitor 已有的切換紀錄，取出切換前後各 9 分鐘窗口，對 50 次切換的功率中位數做比對。實測結果：電壓中位數上升 5.4%，功率中位數變化幾乎為零（−0.0%）。純電阻負載的理論預測是 +10.8%，實測接近 0% 說明住宅負載幾乎全屬定功率型——變頻冷氣、電腦、LED、開關電源設備都會維持固定輸出，電壓升高只是讓電流等比下降。
維持較高的電壓輸出不會增加功耗，但導線損耗（與電流平方成正比）可降約 8%，對長期運轉的逆變器散熱也有間接幫助。這個分析框架對任何需要評估電壓-功耗關係的場景都適用：先確認因果方向，再挑選合適的「控制變數不變的瞬間」作為樣本。
密碼過期但登入成功：從猜測式分類到可稽核事實擷取 #
YISEN 記帳士平台的密碼過期偵測邏輯建立在一個錯誤假設上：密碼過期應該表現成「登入失敗」。財政部平台的實際行為是照常核發 token、讓登入成功，但後續每支 API 一律回 Access Denied。原本的錯誤分類器以關鍵字比對，這個錯誤模式沒命中任何分類，落進 fallback，告知使用者「等幾分鐘再試」——方向完全錯誤，問題反而越等越嚴重。
修法的核心是「不猜畫面、判斷行為」：API 被拒是可確認的事實，觸發時抓取當下頁面的 URL 與文字寫進診斷檔，有「密碼」字樣就自動導向正確的重設指引，認不出的頁面照樣留原始紀錄作為下次改善的樣本。這是從「猜測式分類」轉為「可稽核式事實擷取」的設計轉換：遇到不認識的失敗，不猜不靜默，留下現場。
這個問題模式在對接外部平台時很常見：對方的行為邊界往往和你的假設不一致，尤其是「正常流程中的異常狀態」（如密碼過期）。設計錯誤處理時，優先問「這個分類能被事後稽核嗎」，而不只是「這個分類在常見情境下對不對」。
WAF 把合法 session token 當路徑遍歷攻擊封鎖 #
某企業客戶的系統持續幾天出現登入失敗，症狀指向多種可能：密碼、WAF 封鎖、session 衝突。其中最難察覺的一層是：ModSecurity OWASP CRS 規則把 NextAuth JWE session token 中一段隨機生成的字元序列誤判為 OS 路徑嘗試（LFI 攻擊），以 403 直接封鎖整個請求。這個字元組合在黑名單裡是最短的形式，一般字串撞中機率極低，但加密 token 長度夠長，機率就成了現實。
修法採外科手術式：在 CRS 官方指定的例外設定檔中加一行，只對 authjs session cookie 建立精準豁免孔，其餘規則與攔截欄位全部維持。驗證了兩種情境：authjs cookie 含敏感字串通過、其他 cookie 含相同字串照樣被攔，確認豁免範圍沒有擴大。同步處理了第二個獨立問題：供應商帳號密碼從一開始就打錯，與 WAF 無關，但原本日誌設計無法區分「查無帳號」「密碼錯」「其他錯誤」，補強後伺服器端記錄結構化結果，對外畫面維持統一訊息，後台維運人員能一行指令精準判斷原因。
WAF 規則誤判在對接第三方 auth 框架時是高概率踩坑點，尤其是 token 長度夠長時。精準豁免（指定 cookie 名稱）優於廣泛放行（關掉整條規則），是最小侵入的正確做法。診斷可觀測性同樣重要：日誌區分失敗原因但對外統一訊息，這是安全性與可維護性之間刻意的取捨。
紙上帳戶被真實對帳誤清：多帳戶擴展時的職責邊界 #
量化交易系統在引入 per-session 多帳戶模式後，發現模擬（Paper）帳戶在某天突然產生大量假交易，全部呈現「進出場同價、持有幾十秒、損益為空」的異常形態。這些不是策略觸發的交易，而是系統誤判造成的。
追查確認問題來自「把系統記錄部位對齊到券商真實部位」的對帳函式，其職責邏輯上只應對 Live 帳戶生效，但引入 per-session 模式時只改了下單路徑，對帳機制沒有同步加上 Paper 排除過濾。結果只要 Live 帳戶平倉、券商部位歸零，對帳就把 Paper 的紙上持倉誤判為幽靈部位強制清零，產生假交易。修復方向是在兩個對帳入口補上 Live 過濾條件，其餘策略行為路徑（Paper 本應執行停損、強平）保持不動，避免過度修改。假交易備份後刪除，上線後 Live 對帳正常、Paper 部位不再被誤清。
這類問題在系統從「單一帳戶」擴展到「多帳戶」模式時是典型遺漏點：原本隱含「只有一個帳戶」的函式，在多帳戶環境下就跨越了職責邊界。架構上應對每個「只對 Live 帳戶生效」的操作做明確標記，而不是靠各函式自行判斷，才能在下次擴展時不再漏掉。
本週其他進展 #
- Claude Nexus 接入 Gemini 後端，補齊長期缺口 — Chat 頁的 Gemini 模型選項過去靜默失效，本週補實作後端分支，繞開 Claude SDK 改走內部代理，多輪對話以最近 12 輪歷史合併上下文，並新增每個專案的模型選擇記憶（存本地偏好），避免每次開頁重選。
- 台股條件單防呆邏輯系統性修復並驗證上線 — 發現三支手動建單 API 分別有「觸發條件不一致」與「參數名錯誤導致靜默失敗」兩類缺陷，停損單建立入口實際上從未成功過。抽共用驗證函式統一五種條件單類型的觸發規則，10 個自動建單呼叫點同步補強，部署後以測試單確認三個入口均正常攔截。
- sunnypilot 紅綠燈自動停車觸發命中率提升 — 改用半秒一階濾波取代連續計數，觸發命中率從 9 次提升至 17 次；修正前車否決邏輯，改為判斷前車是否在停止線之前而非固定距離門檻。同時發現移植觸發公式時遺漏了原系統的低速進入前提條件，已補足。
- sunnypilot YOLO 號誌燈偵測端到端延遲優化 — 拆帳各環節延遲後，增加推論執行緒數量並縮短 HUD 輪詢間隔，理論端到端延遲從約 2.2 秒降至約 1.5 秒，已部署至車機驗證。
- sunnypilot 橫向控制延遲大樣本交叉驗證完成 — 樣本擴展至 443 段（7.2 小時），階躍事件法驗出橫向延遲 0.833 秒，與先前單趟互相關結果一致，交叉驗證通過；同時確認低速回正問題為獨立 root cause，分開處理。
- cehtest 資安認證題庫完成 797 題中英雙語切換 — 前端採局部重繪避免答題狀態被清空，以 12 題為一批呼叫 Proxy API 批次翻譯並支援中斷續跑，語言偏好存本地，三種顯示模式（中文／雙語／英文）下次開啟維持選擇。
- cehtest 手機版 RWD 修復，三個斷點驗證通過 — 進度表改為兩行式排版、頂部導覽改為橫向捲動分頁條、操作按鈕統一滿版等寬，以 390px / 360px / 1280px 三個斷點驗證桌面版不受影響。
- motoway.tw 網域遷移收尾，GA4 與 Search Console 全數到位 — Google Analytics 4 資料串流網址更新至新網域，Google Search Console 完成資源登錄與 GA4 連結建立，自然搜尋數據開始回填。應用程式、反向代理、DNS、SSL、GSC、GA4 整個遷移工程全面落地。
- Apache 維護模式旗標機制驗證，ProxyPass 優先順序踩坑記錄 — 計劃維護以旗標檔控制 Apache 攔截，回應 503 + Retry-After 對 SEO 友善；過程中排查全站 ProxyPass 吃掉靜態維護頁資源的問題，以精準路徑排除解決，具通用參考價值。
- 某製造業客戶 ERP 交機文件三份完成 — 完成角色導向操作手冊（逾千行）、三類狀態標記的驗收點檢表（176 項）、以及流程圖與責任表前置的系統流程文件，同步修正知識庫中因程式碼已依業務規則移除但筆記未同步的三項錯誤。
- 期貨系統 PnL 重算修正，43 筆歷史異常紀錄修復 — 發現既有計算邏輯未使用實際成交價，修正後重跑存量資料，績效頁面數字與券商回報一致。
- 期貨系統新增 Tick 線三種時間粒度進場選項 — 支援約 30 秒、1 分、3 分 Tick K 棒作為進場觸發，讓短週期策略能正常訊號與下單。
- LCB 品檢作業 MSSQL 轉 FoxPro 資料管道設計完成 — 確認正確範本 pattern（主檔＋明細三層 cursor 結構），完成 view 設計、日期範圍篩選與 VFP 表單架構，並識別出上游系統良品流向欄位精度落差，需業主確認接受程度後才能定案。
本週技術心得 #
這週讓我感觸最深的是「靜默失效」這個模式——它幾乎出現在每個專案的問題清單裡。系統沒有崩潰、沒有報錯、日誌也顯示正常，但某條關鍵路徑已經停擺了幾週甚至幾個月。直播串流讓知識庫管線從三月就開始 rollback，停損單建立 API 因為參數名打錯一直在靜默失敗，對帳函式悄悄清掉了不該清的部位。
靜默失效的根源通常不是程式寫錯，而是「這條路徑沒有被主動驗證」。大部分系統在設計時只驗證常見情境，邊界情境（密碼過期但 token 有效、部分項目重取、多帳戶擴展後的職責邊界）往往等到客戶踩到才浮現。
對中小企業的 IT 系統來說，這個問題更嚴重，因為維運資源有限，不可能對每條路徑都保持高頻監控。我們這週的幾個修法有個共同方向：不只修那個 bug，而是讓失效變得「可被看見」——結構化日誌讓維運人員能一行指令判斷原因，診斷檔留下現場讓下次改善有據可查，明確的 LIVE-only 標記讓架構擴展時不再漏掉守衛條件。讓系統可觀測，比讓系統看起來正常更重要。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。