這週幾個專案不約而同在做同一件事：不接受表面上「看起來有效」的解法，一路拆到真正的根因。從 AI 開發平台的斷線追查、電子發票系統的身份分流，到太陽能電池均衡與熱感標籤列印，每個故事背後都是一次「原本的判斷可能是錯的」的自我推翻。
工具突然斷線，換版本不一定是真解法 #
AI 開發環境裡的瀏覽器自動化工具反覆斷線，一開始判斷是套件版本浮動造成，鎖了版本後問題只改善沒根除，時好時壞讓人很難信任這套工具還能不能用。
回頭比對啟動流程的每一層才發現，鎖版本只解決了「上網查版本」那段延遲，底層呼叫鏈本身在系統忙碌時仍會撞上啟動逾時，而失敗後不會重試，整個工作階段就從一開始少了工具可用。真正的解法是把套件改成本機常駐安裝、直接指向固定路徑執行，跳過整條容易卡住的解析鏈，並加一道逾時保險絲。實測啟動時間從不穩定的數十秒收斂到 1 秒內。
「鎖版本」跟「消除啟動路徑的不確定性」是兩件事，前者常被誤認為已經解決問題——遇到間歇性故障，值得多問一句：卡住的到底是哪一段？
同一張畫面塞兩種客戶，欄位就會互相打架 #
電子發票系統裡「幫客戶開立發票」跟「一般散客結帳開票」長期共用同一套畫面與邏輯，統編欄位該不該顯示、載具跟捐贈碼該不該出現，全部混在一起判斷，稍不注意就會開錯票。
把兩條路徑徹底拆開：企業對企業的打單流程統編必填、前後端雙重把關；散客開票統編可留空，載具與捐贈只在這條路出現。拆分過程也順帶抓出一個稅額計算誤區——原本只看「有沒有填統編」決定要不要分開列稅額，但機關和非營利單位雖然有統編，依法仍要以含稅價開立、稅額列零，跟一般企業买家不一樣，於是改成依身份分三種顯示邏輯。
兩種使用情境長在同一個畫面上，看起來省工，但欄位互相干擾的風險會一直藏在裡面；先把「誰在用、用來做什麼」分清楚，邏輯才會穩。
電池明明有壓差卻從不均衡，卡在兩個門檻互斥 #
太陽能儲能系統裡有一組電池近兩週完全沒有觸發過均衡動作，一開始懷疑是起始電壓門檻設太高，但調整後現象沒有明顯改善，代表真正卡點還沒找到。
把電壓與壓差兩個維度分開看才發現問題：電壓夠高的時候，靜置壓差只有一點點，剛好卡在觸發值以下；壓差夠大的時候，又剛好落在電壓偏低、系統本來就不判定要均衡的區間。兩個條件永遠湊不到一起，光調其中一個門檻不會有效。最終同時把起始電壓與觸發壓差都下修，讓多數靜置樣本能同時滿足兩個條件，其他原本就平衡的電池組則因為壓差夠小，不會被新門檻誤觸發。
多條件系統裡「調一個參數沒用」常常不是門檻設錯，而是兩個門檻的成立區間根本不重疊——先把每個條件的實際分布畫出來，比直覺猜哪個門檻太嚴更快找到答案。
掃 QR Code 能防偽嗎？先搞清楚金鑰在誰手上 #
設計一套以電子發票登錄為基礎的抽獎活動時，最初構想是用手機掃 QR Code 就能完成資料讀取與驗證，省去串接政府查驗介面的行政等待時間。
深入研究電子發票 QR Code 的加密結構後發現，條碼內建的加密驗證只保護「發票號碼」與「隨機碼」的對應關係，金額、品項、賣方統編這些欄位其實是明文可以竄改的；更關鍵的是，產生這把驗證金鑰的是開立發票的店家本身，不是活動主辦方，代表主辦方光靠掃碼解析內容，無法判斷這張發票是不是被動過手腳。因此確定政府查驗介面這一關不能省，掃碼只能當作第一層資料讀取的輔助，同時規劃了在正式串接核准前，先以格式檢核加名單比對的方式上線運作，等審核通過再無縫切入完整驗證，讓上線時程不被行政流程卡死。
看到「加密」兩個字不代表整份資料都不可竄改——要問的是「這把鑰匙保護的是哪個欄位」「鑰匙握在誰手上」，這對任何要做防偽或驗證機制的系統都適用。
熱感標籤的字為什麼印一印就消失了 #
倉儲系統的品名條碼標籤用熱感印表機列印，條碼清楚，但中文字卻常常糊成一團甚至整個筆劃不見，換過幾種字型設定都沒有明顯改善。
追查發現熱感印表機只有「打點」與「不打點」兩種狀態，沒有灰階；一般 PDF 向量字型在轉成點陣時，中文筆劃邊緣的灰階會被印表機驅動用網點抖動去近似，字級一小，筆劃就直接被抖沒了，粗實心的條碼反而不受影響。解法是放棄透過瀏覽器列印的路徑，改成後端直接依印表機解析度繪製整張標籤點陣圖並二值化輸出，讓畫面上從頭到尾只有純黑白兩色，驅動沒有灰階可以抖動；同時把標籤與 PDF 尺寸精準對齊到「一個像素對一個熱感點」，並抽出繪製邏輯，讓驗證用的是與正式列印完全相同的程式碼，逐一檢查所有真實品名的成品範圍。
印出來「看起來模糊」不一定是字型或解析度問題，先確認輸出裝置本身有沒有灰階能力——熱感、雷射點陣這類裝置常常需要在軟體端就把畫面轉成裝置能理解的純黑白，而不是丟一張漂亮的向量圖給驅動自己想辦法。
本週其他進展 #
- AI 開發平台：模型自動降級的診斷 SOP — 抓到兩個工作階段卡頓是觸發了安全過濾後的模型自動降級機制所致，建立「先查當前模型再查工具」的診斷順序，避免誤查方向。
- 電子發票系統：感熱與 A4 列印段落規則補齊 — 依身份別（打單客戶／散客／有統編機關）分流證明聯與交易明細段的開印條件，並讓各版式各自記憶對應印表機。
- 電子發票系統：政府傳輸防呆機制上線 — 新增拒收檔案掃描、退件單解鎖、傳輸目錄體檢三項防呆，避免退回的申報單卡死在待確認狀態。
- 公司官網：新產品頁與詢價流程打通 — 上線記帳士事務所平台產品頁，並用網址參數把產品資訊帶入聯絡頁自動預填詢價欄位，同步修正一個既有頁面標題重複顯示的小問題。
- 電子發票系統：促銷贈品階梯邏輯與門市日報完整性 — 滿額贈改為自動判斷「階梯擇一」或「多款擇一」；門市日報改為等關班訊號到齊才發送，避免延遲上傳的單據永遠漏收。
- 量化交易系統：修正入金被重複計入績效的問題 — 抓出長駐程式讀取設定值後不再更新的架構缺陷，改為即時讀取並補登資金流水修正帳目，同時統一了兩處不一致的手續費計算路徑。
- 記帳平台：政府媒體申報邏輯重構 — 修正誤判「已成功送出」的判斷邏輯，並改用正確的申報類型一次取得整期資料，同時解決彈出視窗在長頁面上定位失效的問題。
- 自駕系統：釐清煞車行為差異的架構根因 — 透過逐幀比對確認車輛減速偏軟是新舊架構停止點規劃邏輯不同所致，並修正語音介面覆蓋使用者手動速限設定的問題。
- 企業網站上線：SEO 串接與防翻譯設定 — 完成搜尋引擎工具串接與結構化資料埋設，上線三天即有頁面被收錄；並加上防止瀏覽器自動翻譯產業術語的全站設定。
- 生管系統：補齊增刪功能矩陣 — 沿用既有安全刪除模式，一次補齊生管表、附件、訂單與銷貨明細的新增刪除功能，修改範圍涵蓋 6 個檔案並完成實機驗證。
- 廣告投放：生日慶活動完整核銷 — 為期 12 天的廣告活動順利結束，總點擊率達 6.62%，完整歸檔成效報表與帳單核對文件。
- 工具站：AdSense 複查條件確認並送出申請 — 確認網站內容已改善但从未觸發重新審查，查證公網視角資料後正式送出複查申請，目前等候審核結果。
- 電梯保養案：發票列印雙軌格式規劃 — 針對有無統一編號的不同客戶場景，設計感熱標準格式與 A4 加列式證明聯兩種方案，並完成報價與規劃書交付。
本週技術心得 #
這週多個專案的共同模式是：遇到「感覺對了但沒完全好」的狀態時，不滿足於第一個看似合理的解釋，而是往下多拆一層找出真正的成立條件。無論是斷線問題、稅額計算、電池均衡門檻，還是防偽機制，表面上像是同一種故障，實際成因往往分屬不同層次——只解決其中一層，問題會用另一種面貌捲土重來。對中小企業導入系統而言，這也是挑選技術夥伴時值得留意的地方：能不能在「堪用」之後繼續往根因追，往往決定系統上線後是穩定運作，還是每隔幾週又冒出類似的怪異行為。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。