這週幾個專案不約而同碰到同一種難題：同一件事，在不同畫面、不同工具、不同系統裡各有一套算法或一套認知，數字對不起來、操作對不上工具。3Q 工程團隊這週的共同動作是「找到單一真相來源」，把分歧收斂回一個標準，而不是頭痛醫頭地各自修補。
官方後台的按鈕壞了，不代表功能壞了 #
客戶網站的檔案上傳功能建在第三方 CMS 外掛之上，這類外掛版本落後、UI 又常年沒人維護——這次遇到的狀況是，外掛介面完全點不動：雙擊資料夾沒反應、目錄樹沒反應，一般人會直接判定「外掛壞了，只能等更新或換工具」。
我們先確認一件事：UI 失效，不代表它背後的服務失效。這類外掛的介面其實只是呼叫一組固定的後端 API，兩者是分開的。實測後端 API 回應完全正常，於是決定繞過壞掉的介面，直接對 API 送出上傳請求。上傳順序也刻意設計成「先傳素材、確認回應正確後才覆蓋正式頁面」，避免中途失敗讓客戶網站出現斷圖或缺片段的狀態。跨網域直傳會被瀏覽器安全機制擋下，我們用自有的一個已設好授權的中繼站當跳板，合法完成傳輸。最後逐項核對檔案雜湊值、播放狀態、追蹤碼是否完整保留，確認與本機版本完全一致。
遇到「工具介面壞了」先別急著等修復或換工具——很多系統的 UI 只是呼叫固定 API，找到那組 API 往往比等外部維護更快、更可控。
同一筆訂單，三個畫面算出三個金額 #
某供應商結算系統裡，後台、供應商對帳頁、匯出報表對同一筆訂單算出的金額經常對不上。根本原因不是計算錯誤，而是含稅／未稅的計算起點分散在三個地方，各自用不同的方式回推稅額，四捨五入的位置一多，數字自然湊不齊。
我們沒有逐一修正三處的算法，而是先定義「單一計算來源」：以商品標價乘以供應商成數，在商品層先取整算出未稅小計，再統一集中計算稅額，不從含稅金額往回推。三個畫面各自展現不同細節（銷售層看含稅、請款單看未稅明細、對帳單三行並列），但底層邏輯完全鏡像同一套規則，等於是同一份帳本換三種擺法，而不是三本各自維護的帳。過程中也處理了特價商品不套用全局折扣的例外情況，確保既有商品設定不被覆蓋。
多個畫面顯示同一項業務數字時，優先確認它們是否共用同一個計算來源；分散計算是帳目對不齊最常見、也最容易被忽略的根因。
官網寫的和真實狀況對不上，比沒有官網更傷 #
定期盤查發現公司官網的內容已經落後於實際狀況：某項自有產品早已從單一工具演進為系列化產品，官網卻仍以舊形態呈現；部分案例的狀態標記停在「規劃中」，實際上早已上線運行。這種「網站說的和實際不一樣」，對第一次接觸的潛在客戶而言是信任度的重傷。
團隊選擇全面盤查而非逐一小修，把所有產品敘述與案例狀態重新核對一輪。另一個值得記錄的判斷來自訪客分析：日誌顯示網站流量約九成來自搜尋引擎與內容採集機器人，真人讀者佔比很低。這個數據直接推翻了「應該加英文版比較好」的直覺——在真人讀者基數還小的階段，翻譯的邊際效益撐不起工程成本，於是決定先讓真人讀者「找得到、看得懂」，多語系留到自然流量有明顯成長後再評估。
做內容或功能優先順序決策時，先看流量真實組成再決定投入方向，直覺覺得「應該有幫助」的事，不一定是當下最該做的事。
同一段錯誤代碼，可能是三個不同的坑 #
老系統的轉檔程式回報同一種現象——庫存查詢查不到資料，看起來像單一 bug，但深入排查後發現是三層完全獨立的問題疊在一起，只有全部排除才能真正修好。
第一層是索引比對長度不符：資料庫索引鍵定義了固定長度，但來源欄位型別比實際需要的長，串接起來後長度對不上，資料庫對這種情況是「靜默找不到」而不是報錯，於是查詢直接回傳空值。第二層是索引狀態未強制設定：舊系統在多個畫面共用同一份資料表時，索引的排序狀態是全域共用的，若判斷邏輯誤以為「已開啟過表格就不用重設」，就會沿用別的畫面留下的錯誤排序狀態。第三層則是設計被誤還原：某支轉檔程式原本明確決定「不扣庫存」，卻被後續開發誤植入完整的扣庫存邏輯，還混用了兩套資料源的欄位命名規則，導致執行到最後一步才報錯。三層逐一拆解、逐一修復，而不是套一個統一補丁蓋過去。
老系統裡「同一個症狀」常常是多層獨立問題疊加造成的假象；查到第一個原因就急著收工，往往只是修好了三分之一。
先把「什麼是B2B」定義清楚，才能談上市 #
電子發票系統要支援多種商業型態上市，卡在一個看似基本卻始終模糊的問題：怎麼判斷一筆交易是 B2B 還是 B2C？用金額？用客戶類型？不同判斷標準會牽動發票開立通道、金流驗證邏輯、後台報表分類——整份上市規劃的根基都建立在這個定義上。
團隊把判斷基準明確收斂為「有無統一編號」：有統編走買受人上傳，沒有走消費者載具，不再用金額或客戶類型模糊帶過。同時盤查了餐飲、電商、展覽擺攤、辦公室自用等 19 種商業型態，逐一核對進銷存需求，並刻意保留各型態的組合彈性而不是為每種場景獨立開分支——分支太多在後期維護時會快速失控。最後用「問卷定價」的方式驗證方案：使用者依自身場景回答問題，系統推薦對應方案，確保電子發票與多元支付（含 LINE Pay）的選項齊全。
多場景系統上市前，先把核心分類邏輯定義到「不會產生歧義」的程度，比急著把功能做滿更重要——定義模糊，後面所有功能都在替模糊買單。
本週其他進展 #
- 多元支付正式上線，POS 結帳流程改造 — 門市多元支付完成端對端整合並打包 1.0.33 版供更新；同步將結帳時序控制權轉移給刷卡機端，並修訂門市 SOP 文件對齊新流程。
- Android 平板藍牙讀取執行緒修復 — 定位並修復平板連接刷卡機時，首次握手後讀取執行緒無聲死亡的問題，打包新版測試 apk 驗證。
- 電子發票載具整合規格補齊 — 釐清退貨與發票交錯處理原則、簽單控制邊界，並以真實交易電文完成四類電子發票載具的合規驗證，與現有近三百張已上傳發票逐一比對結構一致。
- 三版本（餐飲／電商／平板）實機驗證通過 — 完整走完點餐到開票同步流程，逾八百項測試全數通過，確認版本隔離架構穩定。
- AI 平台跨機群知識搜尋能力升級 — 改良內部 AI 開發平台的知識注入機制，加入跨專案 fallback 與脈絡擴充，提升模糊查詢的命中率。
- 供應商 Portal 功能補齊 — 修正報表日期篩選器預設值不一致問題，並新增供應商自助修改密碼功能，通過完整端對端驗證。
- 太陽能監控三項修正 — 修正市電流向顯示邏輯、確立雙台逆變器並行的資料彙總架構、校正發電量預報的方位角與容量參數，提升預測準確度。
- 搜尋引擎爬取異常排除 — 確認 sitemap 擷取異常是舊防火牆規則誤封搜尋引擎爬蟲所致，解除封鎖並將網站地圖規模擴展至 110 頁重新提交。
- 後台圖片上傳功能上線 — 新增專欄後台圖片上傳，採獨立儲存路徑設計避免重部署遺失檔案，並通過安全與可讀性驗收測試。
- 量化交易系統多項資料修復 — 修復除息資料缺漏、前端持倉快取失效、條件單並發覆寫遺失等問題，並改善加碼計畫的操作確認流程降低誤觸風險。
- 資料庫中文亂碼根治 — 確認並修正連線層字元集設定缺漏，從根本解決中文字元存取時的亂碼問題。
- 策略引擎暖身邏輯修正 — 修復冷啟動時暖身期提前判定完成的計數 bug，確保指標計算樣本量充足。
本週技術心得 #
這週幾個看似不相關的案例，其實指向同一件事：系統出問題時，「哪裡看起來壞了」和「哪裡真的壞了」經常是兩個地方。介面點不動不代表服務掛了，數字對不上不代表哪一邊算錯，同一個錯誤訊息也可能是好幾層獨立問題疊加的結果。中小企業在維運老系統或多方整合時最常犯的錯，是看到症狀就往最直覺的方向下手——重啟、補丁、換工具——而不是先花時間定位症狀真正發生的那一層。把時間花在判斷「問題出在哪一層」，往往比急著動手修，更快把事情真正解決。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。