本週幾個故事看似互不相干：量化交易的停損、電子發票的 XML、太陽能電池的校正、自駕車的紅綠燈辨識、商品圖的 AI 重製。共同點是「測試時通過」不等於「真實世界有效」。回測與實盤差一道機制、重播與實車差零點幾秒、AI 圖片與實物差一筆細節。我們怎麼找出這些落差，又怎麼決定要不要信任結果，是這週的主軸。
回測勝率九成，上線後卻老是被停損掃出場 #
自動交易的策略在回測中勝率 90% 以上，上線後卻發現系統自行出場的交易，大多是停損而非賣出訊號。更麻煩的是，每一筆虧損單看都合理，只有把整段歷史攤開才看得出結構性問題。
我們發現回測規則是「進場後只等賣訊號、不設停損」，上線卻多了一道回測沒有的停損機制。於是用同一套回測算法，逐筆算出歷史交易進場後的最深回檔，再套上實盤停損，結果各配對約半數交易會被先掃出場，其中近半原本是回測贏單。我們比較了 9 種停損設計。完全不停損數字最漂亮，但樣本都是「最後有等到賣訊號」的交易，天然排除了一去不回的情況，存在倖存者偏差，所以不採用。最後選擇放寬波動倍數、保留上限安全網，只調兩個參數、不新增機制。另外也把停損基準價改成下單當下的即時價，不再沿用前一日的計畫價。
回測與實盤的規則只要差一道機制，回測績效就不能代表上線表現。評估風控參數時，先問樣本是否已經過濾掉最糟的情況。
品名裡的一個「&」，如何讓整張電子發票送不出去 #
某客戶有幾張發票的品名含「&」，產生的 XML 沒有轉義，Turnkey 讀不進去，檔案落入錯誤區。表面症狀只是「發票送不出去」，根因卻藏在產生檔案的方式。
只改商品名稱，只能救這兩個商品，下次任何名稱出現特殊字元仍會重犯。所以我們修的是產生 XML 的程式（emobile HQ 1.4.34），讓 &、<、> 一律自動轉義。驗證時拿最近 200 張發票比對修改前後：192 張完全一致，4 張是這次壞掉的，另 4 張因含單引號被改寫成標準寫法，平台讀到的字不變。接著逐一盤點 B2B、POS 等其他版本是否自己拼 XML，確認風險後建議 B2B 發版，另一套使用標準 XML 寫入器的系統本來就會自動轉義，無須改動。我們也處理了平台錯誤區殘留同名舊檔、導致重送成功卻被誤判失敗的邏輯。
手工拼字串產生結構化資料，是這類問題的共同來源。修根因比修個案划算，修完要用大量歷史資料比對前後差異，才敢說沒有副作用。
保護機制從不觸發，也從不報錯：電池校正的沉默漏洞 #
Solar Monitor 追蹤電池安時數時，發現座標整體偏低約 20 AH。偏差是固定平移，不是持續漂移，容量設定本身沒錯，真正壞掉的是「觸底歸零」的校正機制。
查下去發現，歸零條件要求前一筆放電電流達標，但撈前一筆資料的查詢漏了電流欄位，電流永遠讀成 0，條件永遠不成立。三次觸底都沒歸零，日誌也沒有任何觸發紀錄，這種機制只能靠對照日誌與實際事件才抓得到。我們把校正拆成兩件事：觸底自動歸零；充飽時自動對齊容量，並記錄對齊前的偏差。容量值只在「歸零後一路充飽、中間無人為修改」的乾淨閉環，且與現值差距夠大時才更新，否則只記錄，避免再被漂移值誤校。保護板的 SOC 在低電量段會自行回調，只當粗對照。模擬 8 個情境全過，含反向案例，上線後觸底錨點首次實戰成功。
安全網類的邏輯不會報錯，所以要主動檢查它「有沒有被觸發過」。自動校正寧可保守，只在條件乾淨時才改值。
重播測試全過，上車卻不一樣：實車驗證的三個落差 #
自駕車的紅綠燈辨識在重播資料上驗收通過，但實車的條件不同：找燈的節奏比驗收時慢，開車時相機畫面的時間與內容還會錯開 0.5 到 1.5 秒。只在重播上通過，不代表上車有效。
改用實車節奏重播後，有幾張紅燈被判成可走。我們先讓畫面每次只取最新一張，再評估兩個方案：讓 GPU 多跑幾次（溫度明顯升高，放棄）、兩次找燈之間在小範圍補找（沒有淨效益，還多出紅判可走）。兩者程式保留但預設關閉，最後改讓追蹤更穩，並經 30 分鐘實測後上車。另一個發現是，「鎖燈只有一半」其實是分母不同：用實車當天錄影重播，比例與實車吻合，先前的數字只統計了前方確實有燈的畫面。遇到近燈改抓遠燈的問題，五種修法各修好個案，卻都讓別處多出誤判，所以用全量重播量化取捨。每項改動都有獨立開關，可隨時退回。
驗證環境要貼近真實條件，指標要先對齊分母。每項改動都該有一步可退的開關，並以同一批真實資料比對新舊版本。
AI 能把小圖變清楚，但不能憑空補出真相 #
Google 將提高商品圖的最小尺寸要求，並明講不要提交放大過的圖。真正的小圖細節本來就不存在，傳統放大不會多出資訊。
我們先依商品分流：已有高解析圖的，直接換成第一張；只有小圖的，才考慮重拍或 AI 重製。測試生成式重製工具後，原圖相對清楚的結果很忠實；原圖更小的則整體變清楚，但原本看不清的毛筆字、印字被 AI 自行畫上去，與實物不一定相符。擴大批次重製後，有部分圖片 AI 會改畫內容，我們決定暫停，重製圖保留備用，正式網站維持原樣。流程定為：忠實的可用，會改畫的人工比對實物，差異大的改用重拍，動到正式網站前先由負責人確認。
商品圖必須與實物一致，這是平台規範，也是信任問題。凡涉及「真實一致」的場景，生成結果都要有人工核對這一關。
本週其他進展 #
- Claude Nexus 儀表板新增額度與用量區塊 — 加入 API 額度與生圖點數餘額顯示，官方查不到的數字明確標示為估計值並與原始紀錄交叉對帳；順手補上每週排程漏記用量的缺口。
- Claude Nexus 生圖改走快速模式 — 生圖時間由約 3 分鐘縮短至約 40 秒；點數不足時自動退回排隊不扣點模式，一段時間後再試，不讓服務因餘額中斷。
- Claude Nexus 儀表板版面依反饋重排 — 用量卡改為整列三欄、Active Sessions 改緊湊網格，高度大幅縮小，窄螢幕自動堆疊，並以兩種寬度實際截圖驗證。
- 對話連線逾時的根因釐清 — 比對兩端日誌後確認是同機高負載工作拖慢服務回應，非平台缺陷且已自行恢復，決定先不改動、日後先查主機負載。
- 公司官網新增「自有服務」區塊 — 為自營的音樂故事書補齊產品頁、上線介紹文與首頁曝光，並另起區塊與既有自營網站並排，不混進 B2B 系統卡；部署前先試跑同步，上線後逐頁檢查。
- emobile POS 1.0.60 同步停用商品 — POS 會把後台已停用或刪除的商品在本機停用，並設有伺服器回傳空清單時不執行的防呆；停用檢查前移到結帳按鈕，避免卡已刷、發票開不出來，18 項測試通過並已發佈。
- 某客戶停用商品的後台處理一致化 — 盤點所有過濾點，庫存、盤點、進貨等需要看得到的地方改為顯示並標示「已下架」；同步協定新增已停用清單欄位並向下相容，新增商品被擋的問題改為自動編號與主動查重。
- 電子發票折讓匯出檔 0.7.23 修正 — 折讓取得階段略過作廢、註銷、退回的單據，避免匯出檔被平台整份拒絕；目前以模擬資料驗證兩條路徑，尚未在客戶真實資料上跑過。更新腳本也改為自動偵測安裝位置。
- 自家 ERP 多分頁工作區與即時訊息狀態 — 改為上方分類選單加分頁，保留查詢結果與還原；生產總覽新增現場看板與產品履歷流程圖，圖表可點進同口徑報表；訊息新增「我的狀態」，並以兩帳號驗證即時同步。
- 餐飲點餐系統自動收尾與外帶點餐 — 訂單與桌位逾時自動收尾，歷史整理以有收款或發票紀錄者不動為界；外帶取貨付款單改由店員接單；實體刷卡機整合以防重複扣款為設計重點，預設關閉、現場測通才開。
- 兩個旅宿活動的 Google 搜尋廣告建置與調校 — 從零建立廣告群組、轉換追蹤與排除字，客戶文案逐字讀回比對；首日數據出來後調整出價與時段，並以 Looker Studio 提供僅限單一活動、唯讀的成效報表。
- 新站 GSC 與 GA4 資料隔離設定 — 改用網址前置字元資源並建立獨立 GA4，避免同網域其他產品資料混入報表；Sitemap 提交成功，相關頁面皆回應 200。
- 自駕縱向控制的重新設計與上車驗證 — 針對前車很遠卻遲遲不加速的問題，模擬中被壓住的時間下降約四分之三；安全指標略差的版本不上車，改動均有開關可退回，尚待下次實車行駛才生效。
- 自駕轉彎指令兩項修正完成上車驗證 — 依導航距離決定轉彎指令時機，並在模型提早放棄轉彎時補發一次；以上萬幀真實格式行車紀錄重放皆無例外，兩項均可關閉。
- 行動裝置遠端操作守住人為把關 — 3Q夥計替使用者更新手機 App 時，遇到系統安裝確認視窗不硬繞，留給本人按，改裝新版後驗證版本號成功。
本週技術心得 #
這週的幾個案例，表面是不同領域，底下其實是同一個問題：我們拿來驗證的環境，跟系統真正運作的環境差了一點。回測少一道停損，重播少了相機延遲，AI 圖片少了對實物的核對，保護機制則從來沒被真正觸發過。對中小企業來說，這類落差最危險的地方在於它不會報錯，系統看起來一切正常，直到出事才發現。給 IT 決策者的建議有三個：第一，驗收時問「這個測試跟真實使用的差異在哪」，而不是只看通過率；第二，凡是『從不觸發的保護』，都要找辦法確認它真的有效，例如留下觸發紀錄或定期演練；第三，任何自動化改動都要能一步退回，並以同一批真實資料比對新舊。速度很重要，但能夠誠實說出『這個我們還沒驗證』，往往更讓客戶放心。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。