這週幾個故事有個共同點：遇到問題先查透原始文件與底層資料，而不是急著動手。從讀三份分散的財政部規範拼出正確填法、到從 JSONL 會話紀錄揪出模型被靜默降級的根因、再到重新設計一套不依賴人工到場的更新機制——都是把「先搞懂再做」貫徹到底的一週。
門市刷卡機串接，一天做完業界要數週的事 #
把電信業者的多元支付端末機（刷卡機）接進門市 POS，牽涉序列埠通訊協定的封包組解、校驗碼、逾時重送，還要涵蓋信用卡、電子票證、電子支付等多種交易型態，一般這類串接光驗收就要拉好幾週。
3Q 依原廠規格實作完整的 RS-232 協定層，同步寫驗收測試工具，一天之內完成協定實作、39 項驗收測試全數通過、測試日誌與開發規格書一次到位。過程中還整理出 4 個原廠規格書上查不到、只有實機打出來才會發現的欄位細節，另外做成實測回饋文件回報給電信業者，讓對方的規格文件也能因此補完。
硬體協定串接的速度差距，往往不是來自工具，而是來自「先把規格讀透、測試框架先行」的紀律。對正在評估收單設備串接的商家，這代表選對團隊可以把上線時程從數週壓到一天內。
電池充飽時間為什麼老是預估錯？ #
太陽能監控系統會即時推算電池什麼時候充飽，但下午雲層一來，發電量瞬間掉下去，原本的預估邏輯還是死板地照著晴天的曲線走，導致系統一直喊「一小時內充飽」，實際上根本沒有發生。
問題根源在於預估完全依賴氣象預報，沒有把「現在到底發生了什麼」納入考量。改用指數衰減的校正機制：拿當下的實測發電量除以當下的預報值算出一個比值，當前這小時完全信任實測結果，往後每過一小時這個修正力道衰減到 0.7 倍，五小時後逐漸回歸原始預報。這樣設計是因為短期天氣（一小時內的雲層）比長期預報更可信，但不能讓一次陣雨永久扭曲整天的預估。
任何依賴預測模型的監控系統都會遇到同樣的兩難：完全信預報會忽略眼前現實，完全信即時數據又會被短暫波動誤導。用「衰減權重」把兩者接起來，是一個能複用在其他即時決策場景（庫存預測、人流預估）的通用手法。
網站放了四年，聯絡表單其實從沒能用過 #
客戶的舊官網最後一次更新停在 2022 年，HTTPS 憑證早已過期，訪客一打開就是整頁紅色警告。這種案子常見的做法是直接套版重做，但沒人知道舊站到底哪裡壞、壞多深。
3Q 先做完整健檢再動手：SEO 基本檢查全數不通過、正文內容近乎空白。過程中翻開網站原始碼才發現，聯絡表單的 <form> 標籤裡只放了一張 logo 圖，沒有任何輸入欄位、沒有送出按鈕——這代表網站掛了四年，其實從來沒有真正收過任何一筆線上詢價，而這件事光看畫面完全看不出來。新站重建時也刻意全程使用客戶提供的實拍照片而非網路圖庫，讓內容量從 693 字擴到 11,802 字，圖片描述覆蓋率從 0% 做到 100%。
很多企業網站的問題不在於「舊」，而在於根本沒被驗證過關鍵功能還能不能用。上線前做一次表單、連結、憑證的全面健檢，往往比重新設計視覺更能挽回實際業績損失。
員工電腦上的 AI 更新失敗，問題不在網路，在三個互相掩護的舊坑 #
企業桌面 AI 助手「3Q夥計」的員工端理論上會自動更新，但實際上機器重開幾次都沒有更新成功。這種「看起來是同一個症狀」的問題最容易讓人誤判成單一根因，結果修了半天還是沒解。
拆開來看才發現是三條各自獨立的失敗路徑疊在一起：有的機器版本太舊、根本沒有自動更新這個功能；有的下載方式在網路不穩時會直接逾時；有的版本校驗檔案跟實際安裝檔對不上，驗證永遠過不了關。修復過程中還踩到一個更深的坑：build 腳本用「邊讀邊寫同一個檔案」的方式改設定，把一個關鍵模組寫壞了，但打包工具沒有報錯、直接產出一顆外表正常、實際少了關鍵功能的安裝檔，而這個壞版本比自動更新的檢查時機還早執行，導致連自我修復的機會都沒有。最終方案是不再假設 App 能自己救自己，改在外部另建一套獨立的守望機制，定時偵測員工機狀態、驗證下載檔案完整性、透過系統排程執行更新，讓「App 掛掉」與「更新能力」徹底解耦。
自動更新機制的可靠度，關鍵不在更新邏輯寫得多聰明，而在於它不能依賴「被更新的東西還活著」這個假設。把更新能力放到外部、獨立於主程式運作，是任何常駐型軟體都值得參考的容錯設計。
AI 明明還在跑，畫面卻卡住不動——問題不在應用層 #
AI 工程指揮平台的對話工作階段偶爾會出現「卡死」的假象：畫面顯示還在執行，但長時間沒有任何新內容跑出來，從應用層日誌完全看不出原因。
深入追查發現這其實是兩個問題疊在一起造成的視覺錯覺：一是系統設計了「回合結束卻沒輸出時自動催促繼續」的重試機制，讓卡住的畫面持續顯示「還在跑」；二是背後的模型請求被後端機制靜默降級到另一個版本，而那個版本存在「只產生思考過程、不輸出文字結果」的已知問題。兩者疊加，才讓卡死假象一直持續。真正定位問題的方法不是看應用層日誌，而是直接讀對話紀錄裡的原始模型欄位，才抓到真正在跑的是哪個版本。確認後同步升級三個相關服務的模型設定，並在管理的機群上全面驗證。
當一個異常同時牽涉「工具的重試機制」與「底層服務的降級策略」時，應用層日誌往往只看得到表象。往下一層看最原始的請求紀錄，是排查這類「看起來卡住但其實另有隱情」問題的關鍵一步。
本週技術心得 #
這週幾個故事表面上分屬硬體協定、氣象預測、網站健檢、桌面軟體更新、AI 平台維運，看似毫無關聯，但拆開每一個「意外卡關」都指向同一件事：症狀本身會騙人。同一個「卡住」可能是重試機制掩蓋了模型降級，同一個「更新失敗」可能是三條獨立路徑疊加而非單一 bug，同一句「網站沒詢價」背後可能是表單從沒真的存在過。中小企業導入任何自動化或整合系統時，最容易犯的錯誤是看到表面症狀就急著套用現成解法——修好一半、真正的根因還在原地。值得投資的不是更快的修復速度，而是先建立「讀原始資料、拆解每條路徑」的診斷習慣，這往往才是後續維運成本高低的真正分水嶺。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。