這週我們在三個完全不同的系統裡，碰到同一個根源：資料或訊號存了多份副本，各自維護、邊界模糊，最終行為就悄悄發散。台股量化系統的賣訊從未觸發、政府網站後台的亂碼、POS 系統把付款失敗判成成功——表面上是三個不同問題，但解法都指向同一個方向：讓判斷下沉成唯一來源，展示層只負責讀取。另一條線是 AI 輔助駕駛的紅綠燈辨識，一次域偏移讓辨識率從 17% 跳到 76%，說明模型訓練資料的「家」和它被部署的「家」必須一致。
賣訊永遠不觸發：兩條路徑共用不同邏輯的時序地雷 #
量化交易系統的回測顯示策略表現正常，但即時交易從未出場過一次。這種「回測好、實盤壞」的現象往往讓人懷疑策略本身，但真正的問題其實在更底層：兩條執行路徑對「什麼叫做賣出訊號」的定義從一開始就不一樣。
追查後發現，回測引擎只看 signal == SELL，即時交易路徑則多了一條強度門檻過濾。RSI 策略產生的賣訊強度長期低於這個門檻，導致所有賣訊都被靜默丟掉，系統從未真正出場。同時，決策頁面讀的是資料庫裡的快照欄位，這個欄位自六月就停止更新，畫面顯示「買進」但實際訊號早已是「賣出」——兩頁對同一檔股票給出截然相反的結論。修法分兩層：顯示層改成即時計算，不再依賴快照；邏輯層把即時路徑的判斷統一回「只看 signal」，讓兩條路徑共用同一套邏輯。
「存了一份副本卻沒維護更新路徑」是分散式系統最隱蔽的陷阱之一——它不會報錯，只會讓不同入口看到不一樣的世界。這種問題的偵測往往需要兩個來源同時出現矛盾才會被發現；預防它的方法是從一開始就讓計算只發生一次，其他地方只讀不算。
紅綠燈辨識率從 17% 跳到 76%：換硬體時訓練資料也要換 #
原本在 C4 行車記錄器上訓練的看燈模型，部署到 C3 上後，有號誌燈的畫面辨識率只有 17–23%，全解析度也只到 30%。直覺上會懷疑解析度或模型大小，但這兩個方向排查後都沒有改善。
根本原因是訓練資料的「域」（domain）不對：C4 與 C3 的鏡頭角度、安裝位置不同，模型從未看過 C3 視角的畫面，自然認不出來。九月時曾評估「先找燈、再判色」的兩階段做法，當時在 C4 上兩種做法效果相當所以被否決；這次 C3 上差了四倍，構成重新評估的新證據。改用通用小模型 YOLO11n 只找燈不判色，辨識率立刻跳至 76%。下一步是把這個找燈器接上已訓練好的輕量判色器，再以連續幀投票確認燈色。
模型部署到新硬體時，不只要確認格式相容，更要確認訓練資料和部署環境的感知視角是否一致。「在 A 機器上沒差別」不等於「換機器後也沒差別」——遇到效果急遽下降時，先問的不是模型夠不夠大，而是「訓練資料的家和模型被部署的家，是同一個地方嗎」。
Cloudflare 快取了 RSC payload：除錯要從「請求有沒有到主機」開始追 #
政府客戶的網站後台，某個管理頁面偶爾直接顯示一段系統內部路由資料，而非正常頁面。這類亂碼現象，第一反應往往是程式渲染出了問題，但從程式碼找起往往徒勞。
對照伺服器存取紀錄，發現問題頁面當天只打到伺服器一次，其餘請求全被客戶機關的 Cloudflare 直接回應快取內容。推測機關為其另一個服務設定了含有 content 字串的快取規則，路徑比對過於寬泛，把我們後台的 /admin/content 也納入。第一次抓到的剛好是換頁時的預先載入資料，之後所有使用者都拿到同一份快取，同時 bypass 了伺服器端的登入驗證。修法選擇在 Apache 層做轉址而非改程式路由，理由是可當天上線、可逆、對前台民眾零影響，代價是轉址本質上是繞路，日後若機關修正規則需記得移除。
伺服器端把 Cache-Control 標記正確並不夠，只要中間有一層 proxy 依自訂規則覆蓋快取行為，整套保護就失效了。這類問題的除錯起點應該是「這個請求有沒有打到主機」，而不是從程式碼開始看——如果 access log 裡找不到記錄，問題一定在主機前面的某一層。
LINE Pay 回傳 HTTP 200 不代表付款成功：returnCode 才是事實 #
POS 系統整合 LINE Pay 時，測試環境看起來流程正常，但有一個靜默的錯誤：LINE Pay 不管付款成功或失敗都回傳 HTTP 200，真正的結果藏在回應 body 的 returnCode 欄位。原本程式只檢查 HTTP 狀態碼，導致認證失敗仍會被判定成功，繼而出單、開發票，但款項實際上並未扣款。
修法是把判斷邏輯從「HTTP 200 = 成功」改為「returnCode == 0000 才算成功」，非 0000 一律判定失敗並把錯誤碼顯示給消費者，用測試環境驗證（刻意回傳 1104）確認修正有效。同步清理了一個從未正常運作的掃碼入口：台灣 LINE Pay 付款碼為 18 碼，但系統只接受 13 碼，客人條碼一律被擋；加上認證方式不正確，這個入口直接移除。三個收款畫面統一整理為現金、信用卡、LINE Pay Mini 三個選項，收據也修正為依實際付款方式顯示，不再誤印為現金。
金流 API 整合時，HTTP 狀態碼只代表「這次 HTTP 通訊成功了」，不代表「業務邏輯成功了」。任何涉及金錢的 API，都必須進一層讀取回應 body 裡的業務狀態碼；信任 HTTP 200 等同於把驗證責任交給通訊層，而通訊層根本不懂你的業務。
三十年 VFP9 系統移除 .NET 橋接：REST API 讓老架構直接對接 #
老式 VFP9 系統要對接新的電子發票服務，過去靠 .NET 橋接層轉接，部署相依複雜。改用標準 REST API 後，橋接層可以整個移除，但 VFP9 的字元編碼（Big5）與 Windows 代理伺服器設定帶來了兩個不易察覺的地雷。
以 VFP9 內建 WinHttp 直接呼叫 REST API，部署相依大幅降低。實測中特別針對 Big5 編碼的危險字元（第二個位元組恰好是反斜線的中文字，如「許功蓋」）驗證 JSON 序列化與資料庫存取，確認不會發生截斷或跳脫錯誤。另一個問題是 WinHttp 會繼承 Windows 系統 Proxy 設定，連本機服務也可能失敗，在呼叫層強制設定直連後解決。分支版本設計上系統性拿掉與 LCB 現場無關的模組，讓部署包更小、現場人員不會誤操作無關功能，主線程式碼未受影響。
老系統現代化不一定要全部重寫。REST API 標準化讓不同年代的技術棧都能互通，關鍵是測試「那個年代的字元處理有沒有踩到新格式的邊界條件」，以及「系統環境的隱性設定（如 Proxy）有沒有干擾新的呼叫路徑」。
本週其他進展 #
- Claude Nexus 多語言飄移三層注入修法上線 — Opus 長任務中繁中規則被工具呼叫稀釋的問題，以「每則使用者訊息附帶語言提醒 + 每 8 次工具呼叫補一次 + 接續 session 時先翻譯英文摘要」三層解決，對話紀錄頁面不受影響。
- Claude Nexus 派工 session id 競態與逾時上限修正 — 新 session 建立後立即寫入派工紀錄，修正 planmaker 拿到舊紀錄誤判中斷的問題；chat_server 超時上限從 10 分鐘調整為閒置 35 分鐘或總計 120 分鐘。
- Claude Nexus 安全攔截後三條路徑統一處理 — Chat 網頁、夥計 App、派工三條路徑統一補齊被 Anthropic 安全機制攔截後的處理：停下詢問而非自動換模型，同時修正夥計 App「開新對話」從未真正斷開舊 session 的隱藏 bug。
- 3Q夥計桌面版模型切換功能上線 — 對話視窗標題列新增模型指示器與下拉選單（含 Opus、Sonnet、Fable、Haiku），模型由 chat_server 回報實際使用值後更新 UI；修正 config.set() 寫檔後未刷新程式內快取導致切換失效的 bug，設定跨重啟保留。
- 3Q夥計手機版跨夥計派工能力上線 — 對話中指名目標夥計即可把任務派給 Nexus 上任何 Claude 專案，短任務同步等待、長任務背景執行後推送通知；修正夥計判斷目標在本機而自行執行（違背委派意圖）的問題後重測正確。
- Android 手機夥計 v0.4.1 四項功能上線 — 新增操作前截圖紀錄（動作前存底）、截圖自動批次清理、對話體積逼近 4MB 自動換新並帶入最近數句、電池最佳化豁免清單；四項合併實測通過後正式上版。
- 手機夥計 Phase 1 驗收，Shizuku 操控路線確立 — 手機端基本對話、工具呼叫、知識庫記憶整合已驗收；Phase 2/3（看畫面、操作手機）確立以 Shizuku 取代無障礙服務作為技術路線，截圖交 AI 判斷為主要感知路徑。
- Solar Monitor 逆變器風扇故障根因定位完成 — 監控資料確認 fault 21 連發四次觸發自我保護，溫度排除過熱後，比對 10/6 起散熱片溫度死平線，研判風扇軸承老化或轉速訊號電路問題，已提出白天關機後逐步驗證的診斷方案。
- Solar Monitor BMS 幀解析修正部署 — bms_reader 在 WiFi 訊號不穩時收到截斷幀導致資料異常，修正幀解析邏輯後重新部署，後續資料讀值恢復正常。
- eMobile LCB 分支版本完成交付 — 從 HQ 主線分出 LCB 專屬分支，移除無關模組，Turnkey 整合縮減為最小路徑；多台工作站共用資料庫的同單競態在資料庫層以唯一性保護解決。
- FATE 占卜頁「所問之事」欄位上線 — 四個占卜區塊（金口訣、大六壬、六爻、時家奇門）新增選填問事輸入，AI 改為先給針對所問的明確判斷再補整體解讀，抽出共用元件避免重複邏輯。
- sunnypilot C3 錄影服務修復，每分鐘錄影正常啟動 — 影像壓縮程式需即時優先權，以一般使用者身分執行時被系統拒絕導致服務靜默中止；補上服務層權限設定後 C3 正常錄影，為後續取得標準答案訓練資料打通通道。
- sunnypilot 後窗 LED 斷線根因修復 — WiFi 頻道掃描導致字幕機通訊中斷，容錯邏輯因底層通訊改變後錯誤訊息格式不同而靜默失效；快取網路清單查詢並鎖定 MAC 位址後，15 分鐘斷線歸零。
- 台股量化系統颱風假非交易日自動偵測首次真實驗證 — 以「最後成交日是否等於今天」作即時偵測，颱風假當天 09:01 確認未開盤後，條件單檢查、賣策略、自動交易全部自動跳過；排程順延至下一交易日機制首次在颱風假下驗證通過。
- YISEN 電子發票安裝包改為自給自足封裝 — 原安裝包在客戶端環境出現 VC++ Runtime 缺失與離線套件問題，修正 build 流程明確列舉所有相依並一併納入安裝包；新增密碼重設工具讓管理員無需直接進資料庫操作。
- OMEinvn chenspos 0.2.18 發佈，WebSocket 路徑補齊 — 補上
/ws路徑轉送，修正多人桌邊點餐即時同步中斷問題；LINE Pay 審核展示流程與測試文件產出完成，本次發佈同時包含收款畫面統一整理與收據付款方式顯示修正。 - LCBTRAN 現代化提案簡報完成，真實資料全面替換示意圖 — 從 LCN DBF 與生產追蹤資料庫取出真實數字支撐每一頁，將提案主軸從「重寫 LCN」改為「生產追蹤系統整合 LCN」，已實作功能從「日後擴充」移至「上線就有」。
本週技術心得 #
這週最值得帶走的觀念，是關於「副本」的代價。資料或狀態存了多份——回測與即時邏輯各一套、快照與即時計算各一份、HTTP 狀態碼與業務狀態碼各一層——每多一份副本，就多一個需要同步的地方，而同步失敗通常不報錯，只是靜默地讓不同入口看到不同的世界。中小企業的 IT 環境尤其容易出現這個問題：系統往往是一次加一個功能長出來的，每次加功能的人不一定知道其他地方也存了一份。
解法的邏輯其實很簡單：找出誰是「唯一真相」，讓計算只在那裡發生一次，其他地方只讀不算。但執行上需要一點反直覺的紀律——當你發現某個頁面顯示不對，第一個衝動是「修這個頁面的邏輯」，但正確的動作往往是「找到這份資料的其他副本，把它們全部指向同一個來源」。
另一個通用觀念來自 Cloudflare 快取案例：任何「明明程式沒問題，行為卻不對」的除錯，第一步應該是確認「這個請求有沒有打到你的程式」。中間的 proxy、CDN、快取層都可能在你不知情的情況下攔截並改寫請求或回應；從 access log 往回追，比從程式碼往前找省時得多。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。