這週的幾個故事看似互不相干，有自動化工具誤傷資料、畫面顯示過期的訊號、車上的方向燈、一場夜間斷電，但根子相同。問題都出在「有一份東西被默默假設是對的」。我們怎麼讓這些假設現形，又怎麼用機制取代「大家小心點」，是這份週報的主軸。
自動化工具誤傷資料兩次，我們選擇讓機制擋人，不靠小心 #
一週內，兩個自動化流程出了同一種錯：一個誤刪了數百筆紀錄，另一個事實變更偵測程式把數百行資料改錯。兩者的共通點是拿一段文字去比對，找到就全部動手，既不看上下文，也不限範圍。「下次小心一點」不是可靠的解法。
我們在 Claude Nexus 的刪除端加了防護 hook：DELETE／UPDATE 若用模糊比對或沒有 WHERE 條件，就直接攔下，要求改用 id 精確操作。真要批次處理，必須先把筆數與樣本給人看，同意後才放行。部署後攔與放行兩種情境都逐一測過。修改端則把偵測程式的作用範圍限縮在「發現該事實的那個專案」，沒標專案的內容一律不碰。還原時有個細節：同一行若被多筆事實連續改過，必須由新到舊倒著還原，順著還原會組出錯誤值。因此還原改用整行精準比對，無法判斷的少數幾行不動，列清單交人工複核。
自動化的破壞力取決於範圍有沒有被限定，而不是它判斷得準不準。任何會批次改資料的流程，都該先問：它最壞能動到多大範圍？再用機制把上限鎖住。
畫面顯示買進，策略卻沒買：一份沒人維護的資料庫副本 #
同一檔標的，篩選頁顯示勿進，決策頁卻顯示買進。兩頁都在談同一件事，結論卻相反。這種不一致最麻煩的地方在於，策略本身其實每天都有重算，也正確地沒有下單，錯的只是畫面。
追下去發現，篩選頁每次開啟都即時計算訊號，決策頁卻讀資料庫裡的「訊號快照」欄位，而這個欄位只在資料建立當天寫入一次。多數標的每天刪除重建，快照最多舊一天，看不出問題；唯獨一筆為避免被誤洗而長期保留的資料，快照停在兩個多月前才露餡。我們讓決策頁改和篩選頁共用同一支訊號計算函式，快照退為小字備註。每日批次也補上回寫，避免備註本身再失真。並把「畫面上的訊號一律即時算，不信資料庫快照」立為規則。目前兩頁對同一標的結果已一致，回寫邏輯要等下個交易日排程實跑後，才能從紀錄確認。
判斷邏輯與資料來源只該有一份真相。衍生資料若必須保存，就要有明確的更新責任人，否則寧可每次即時計算。
車上方向燈後裝：騙不過控制盒，就從源頭模擬一顆電阻 #
要在車上後裝方向燈控制，直覺做法是在車內網路上偽造「左轉／右轉」訊息。但原廠控制盒會自行驗證訊息，偽造的封包根本騙不過。
我們回頭看原廠撥桿的本質：它其實就是一顆電阻，控制盒讀取電壓來判斷左轉、右轉或不打，再把狀態廣播到全車。所以我們在源頭模擬對應的電阻值，對全車而言，等同真的撥了桿。再用雙切繼電器串接，斷電時自動回到原車狀態，即使我們這一段故障，也不影響行車。查閱原廠手冊後，接點也從拆裝繁瑣的轉向柱，改到較易拆的接線盒。
整合封閉系統時，先搞清楚訊號在哪裡產生，往往比在下游硬仿更穩。設計也應先確保故障時退回原狀態，再談功能。
夜間斷電不是停電：從散熱片溫度曲線抓出風扇回授故障 #
夜間監控資料中斷了三次，整戶連同監控設備一起斷電。第一直覺是市電或迴路開關跳脫，但這個推測要有證據才站得住。
Solar Monitor 的資料給了答案。逆變器自身的故障紀錄在每次中斷時都留下一筆風扇故障，推翻了開關跳脫的猜測。再回看散熱片溫度：同樣負載、同樣模式，正常時整夜 35 到 39°C 並隨負載起伏，異常時卻是 47 到 48°C 的一條死平線，代表風扇根本沒轉。這個徵兆 10 月初就出現，下旬幾乎天天發作，只是前幾晚是「沒起轉」，逆變器沒下指令，所以沒判故障。因為溫度本身不高、風扇也看得到在轉，我們判斷問題較可能在轉速回授訊號，而非葉片。處置依成本由低到高排序：先互換接頭判斷故障跟著風扇還是主板，再量測轉速線，接著清灰，最後才換風扇。目前仍在處理中，暫時維持逆變模式並設溫度監看，避免白天高負載撞上過溫保護。
「某件事從沒觸發」與「一條異常平直的曲線」本身就是訊號。先用資料排除假設、再從低成本處置往上走，比直接換零件更不容易白花錢。
對帳差額不要靠錯誤訊號曝光：把「加扣項」升格成正式欄位 #
寄售通路的月報表底部有退貨、折讓類的加扣項，但系統只依銷售明細算應開金額，扣項要到開票時才由人工調整。這種錯誤不會報錯，只會在對帳時變成一筆說不清的差異，而且多個月份都有同樣情形。
我們沒有繼續靠人記得去改，而是把扣項納入匯入流程：解析時直接讀取小計行的加扣項，隨銷售資料一併儲存，重新匯入時覆蓋舊值，並補寫歷史月份。關鍵取捨是金額口徑：對帳與開票用扣除後的金額，政府季報與歲入則維持原始銷售額，避免申報口徑被這次修正悄悄改變。驗證上，用原始報表逐月重新抽取，確認系統金額加扣項等於報表總計，且與實際已開發票一致。匯入時也加了防呆，自動比對報表底部總計，不符就提示人工核對，來源格式改版也能提早發現。介面上，扣項在財務核對頁成為獨立欄位，有扣項的月份以顏色標示，差異欄只反映真正的錯誤。
例外情況應該是一等公民的資料欄位，不該靠「對不上」來暴露自己。修正時也要分清楚對帳、開票、申報各自適用的金額口徑。
本週其他進展 #
- 對外訪客 AI 入口完成權限複查與統一加固 — 重新以一般訪客身分從外網實測，驗證 AI 無法動用工具，結論以工具真的被拿掉為準，而非模型口頭拒絕。修正集中在代理層統一處理，所有對外站台一次到位。
- Claude Nexus 自動接續對話改為依狀況分流 — 接續的新對話不再一律「回一句就停」：已完成就回報，下一步明確就先查現況再繼續，需要決策的列出選項等回覆。需決策的路徑已用真實接續文驗證，自行接續的路徑尚待實際跑過。
- Claude Nexus 儀表板補上來源標示 — 呼叫端現在以標頭回報來源名稱，解決儀表板長期出現「未標 app」的問題，並補上一個原本漏記用量的排程。
- NavDash 導航 App 連發 2.1.0 到 2.3.0 三版 — 2.2.0 讓藍牙旋鈕能在 HUD 主畫面切換右側欄位，2.3.0 新增語音輸入目的地與「結束 NavDash」按鈕。說明頁放在網站上，改說明不必重新安裝，沒網路時顯示內建版本。其中 2.1.0 需要使用者親自完成安裝確認，2.2.0 與 2.3.0 已在實機走完覆蓋安裝與版本驗證。
- 手機夥計 v0.5.2：懸浮按鈕改為按需呼叫 — 按鈕預設收起，由快速設定磚叫出，並將「是否顯示」與「無障礙服務是否運作」拆開，遠端讀畫面與點擊功能不受影響。同時修掉語音辨識出錯時小框文字永遠不消失的計時問題。螢幕關閉自動收起與鎖定畫面不顯示這兩項，尚待實機鎖屏確認。
- OMEinvn 餐廳 POS 與電子發票密集發版 — 結帳新增無發票選項與實收現金記錄，結帳後自動印紙本發票。單號改為資料庫內原子取號，不再有撞號機率。LINE Pay 重試付款改為加序號後綴，避開單號重複被擋。字軌新增逐號的號碼明細，並補上客人自助點餐的逾時取消與折扣管理。載具輸入框的新提示與螢幕鍵盤目前只過型別檢查，待店裡實機驗證。
- fate 占卜解讀新增「所問之事」欄位 — 補上選填的提問欄位後，AI 會先依盤面直接回答，再補整體解讀，四個占卜區塊共用同一元件。同時用「先檢查是否收錄、再送索引」的流程處理新網站收錄，並拆開流量來源，避免把賽事站的週期高峰誤判為官網衰退。
- LCBTRAN 老 ERP 現代化：發票補開日期與自動分本 — 開立時日期可選，系統自動分本，補開較早日期時跳到下一本，不浪費原本那本的號碼。發票版面用程式從 PDF 逐字比對樣本，取代目視。員工同步時自動建立帳號，管理員只需開通權限。打卡轉檔目前完成唯讀研究與頁面規劃，帳號流程尚待實際安裝後驗證。
- Sunnypilot：打燈後判斷換道或轉彎 — 改為導航優先，沒開導航才退回地圖推測，駕駛自己出力轉方向盤就取消減速。閉迴路模擬中，到路口仍超過 30 km/h 的次數從 8 次降到 0。導航分支要等實車驗證。
- Sunnypilot：低速入彎與卡車辨識的資料驗證 — 分析出低速入彎的扭力呈鋸齒狀回收，改為規劃「只進不退」的平順曲線，上車前先確認追線與過衝不惡化。卡車辨識把握度低於 0.7 就保守改當轎車顯示，200 張實車畫面中 15 台誤認有 13 台改正。
- Solar Monitor 兩項自動校正機制 — 電表估計值改為每次校正後，用最近兩筆面板讀數自動推算係數，並設有保護範圍。電池安時數修掉一個因漏撈電流欄位而讓「觸底歸零」從未成立的隱性 bug，容量更新只在乾淨閉環且差異夠大時才發生。
- 量化交易系統條件單與下單流程調整 — 條件單防呆規則統一，停損以當日最低價為準，判斷下沉為唯一真相來源。假日資料改用交易所官方來源，自動下單改為市價單並加入颱風假偵測。
- 桌面夥計的銷售分析與影片輸出 — 銷售分析報告把倉庫出貨與通路實銷分兩層計算，避免重複計入，且結論只寫現象不下因果。影片輸出改為照網頁樣式逐格繪製並多核心並行，單曲處理從一小時以上降到約 5 分鐘。
- 廣告投放預算節奏核對 — 用「剩餘預算除以剩餘天數」對照實際日花費，判斷某檔期不需調整預算。並確認目前尚未設定轉換追蹤，只能以點擊與點閱率評估成效，已列為投放前的基礎設定。
本週技術心得 #
這週回頭看，最常出現的問題其實不是「做錯了什麼」，而是「有一份東西被默默假設是對的」：一個沒人更新的快照、一個沒人讀的加扣項、一個被當成可信的參數名稱、一個從沒觸發過的條件。這些假設平常都不報錯，只在某天以差異的形式冒出來。對中小企業來說，與其追求系統永遠不出錯，不如多做三件事。第一，讓資料與判斷只有一份真相，必須保存衍生資料時就指定誰負責更新。第二，把例外變成正式欄位，不要讓它靠「對不上」來曝光。第三，安全與破壞性操作要在執行層用機制鎖範圍，並且實測，不靠提醒、不靠名稱、也不靠模型說得好聽。此外，我們也習慣把「已驗證」與「待驗證」分開講清楚，因為誠實標示尚未跑過的部分，才讓已驗證的部分有人願意相信。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。