本週 3Q 工程團隊在五條技術主線同步推進：Claude Nexus AI 指揮平台修正版本偵測邏輯並完成跨主機模型切換；自建台股量化交易系統揪出回測 selection bias 與排程器靜默失寫 bug；eMobile 電子發票平台完成攤位版庫存同步架構；Solar Monitor 太陽能監控修復 MODBUS 與預報快取問題；另完成一次第三方地圖 API 金鑰的完整資安加固。每條線都有具體交付，沒有一條只停在「待確認」。
既有專案改進 #
Claude Nexus：版本偵測 Bug 修正與跨主機模型切換 #
發現並修復 Claude Nexus dashboard 誤將預發布版本識別為最新版本的問題，將版本檢查邏輯收斂為只讀取 latest tag，消除錯誤更新提示。同步完成 Fable 5 試用評估，試用期結束後順利切換回 Opus 4.7，UI 模型選單全站同步更新保持一致，並清理測試 session 殘留確認儀表板狀態乾淨。
Claude Nexus：前後端分層診斷，精準定位搜尋故障根源 #
針對週報生成功能的搜尋異常進行系統診斷，逐層驗證後確認後端搜尋邏輯回傳正確，問題實際出在前端資料處理路徑。「先確認後端資料正確，再追前端消費邏輯」的分層診斷方法，是複雜全端系統排查的標準姿勢，可有效避免在正確的層花時間找錯方向的 bug。
量化交易系統：修正 Selection Bias，回測更貼近真實市場 #
確認既有策略存在 selection bias 導致勝率嚴重虛高，大量有效樣本在決策流程中途遭裁剪。重構出場邏輯改採純 SELL 訊號驅動，並將雙層篩選合併為單一 gate，大幅簡化決策流程。同步將回測成交模式從當日收盤改為隔日開盤市價，讓回測結果更忠實反映實際下單情境，避免策略看起來很漂亮卻在真實市場失效。
量化交易系統：排程器 ORM 靜默失寫 Bug 修復與漏斗流程重設 #
診斷出排程器因 ORM 部署問題導致觀察池記錄靜默失寫——系統不報錯，資料卻完全沒有落庫。重啟排程器後確認修復，並同步修正策略漏斗流程為正確的「先進池再評估買點」順序。統一各模組的門檻設定，消除設定值不一致導致觀察池被誤踢光的問題。
eMobile 攤位版：庫存同步架構落地，UI 功能完善 #
完成 eMobile 門市版（攤位版）與 HQ 後台的商品分類同步架構設計與實作，支援 HQ 端分類變更自動同步至各攤位端。同步修復攤位版分類刪除、折扣啟用勾選、結帳頁下一號顯示等多項 UI 細節，確保門市實際操作不卡關。
eMobile HQ：Turnkey 傳輸修正與庫存時間戳 Bug 根除 #
修正 HQ 端 Turnkey 傳輸掃描邏輯，恢復遺失的對帳檔並重新打包安裝檔。診斷出攤位庫存同步失敗的根本原因：賣出扣庫存時未更新時間戳，導致同步邏輯誤判資料未異動而跳過推送。時間戳遺漏是分散式庫存同步最常見的靜默 bug 型態，症狀是「系統沒報錯，但庫存就是不對」。
Solar Monitor：MODBUS 寫入修正與預報排程穩定化 #
修正 MODBUS 寄存器寫入與讀取邏輯，強化日誌的設備來源區分，讓不同逆變器的事件可清晰追蹤。修復手動更新預報時僅寫快取、未同步寫入資料庫的 bug，確保重啟後預報資料不遺失。調整預報排程觸發機制並改善整體排程穩定性，解決前端快取未正確更新的顯示問題。
gomylife.tw：補產六期技術週報並修復自動化流程 #
完成六期技術週報的補產上線，同步修復文章排序 bug 與一處隱私處理漏洞。診斷出自動化 cron 排程因日誌檔權限設定錯誤無法寫入，修正後自動化流程恢復正常，週報生成排程重新穩定運行。
基礎建設 #
FindMy 系統：Google Maps API 金鑰完整資安加固 #
完成 Google Maps API 金鑰的全套資安加固流程：部署新金鑰、設定 HTTP Referrer 白名單限制、配置用量預算告警、按最小授權原則限縮各 API 的使用範圍。這套流程是任何使用第三方地圖 API 的系統都應落實的基本資安配置，可有效防止金鑰外洩後被濫用導致非預期費用或資料風險。
技術心得 #
嵌入式系統音頻故障診斷：CPU 資源競爭的隱性影響 #
pibar 樹莓派語音助理出現播音斷斷續續的問題，直覺以為是音頻驅動或緩衝區問題，實際診斷發現根源是 YuNet 人臉偵測推論 CPU 佔用過高，搶佔了音頻輸出執行緒的資源。降低推論頻率後症狀明顯改善。此案的啟示：在資源受限的嵌入式環境，「音頻問題」不一定出在音頻模組——任何高 CPU 負載的並行任務都可能是罪魁禍首。多執行緒資源競爭的症狀往往不直覺，需要跨模組的整體視角才能定位。
本週技術心得 #
本週最值得記錄的工程洞察是：靜默錯誤比顯性錯誤更危險，也更常見。量化交易的排程器不報錯但資料沒落庫；eMobile 庫存同步不報錯但因時間戳遺漏跳過推送；Solar Monitor 預報只寫快取不寫資料庫，重啟後才發現資料憑空消失。這三個來自不同系統、不同技術棧的 bug，有著完全相同的症狀特徵：系統「看起來正常運行」，問題在累積一段時間、或在特定觸發條件下才浮現。
對中小企業 IT 顧問來說，這個觀察有直接的實用價值。在做系統整合或串接驗收時，光看「沒噴錯誤」遠遠不夠——要實際追蹤資料有沒有正確落庫、正確同步、跨重啟後還在不在。建立「寫入驗證」的習慣，對每一次資料異動都抽樣確認最終狀態，是防止靜默 bug 最務實的方法。
另一個心得是資安處置的完整性。API 金鑰管理不是「換一支 key 就好」，還要配套做 Referrer 白名單、用量告警、最小授權，少一環都是留下風險窗口。這個道理在各種第三方服務整合場景都適用——金流、地圖、簡訊閘道，都該用同樣標準檢視。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。