這週跨多個專案反覆出現同一種問題的不同面貌：程式跑起來沒有報錯，結果卻和預期不一致。台股量化交易的回測邏輯與實盤邏輯悄悄分叉、太陽能電池兩套計數都準確卻對不上、電子發票上傳「看起來失敗」其實早已送達、AI 平台 SDK 預設行為默默載入不該有的個人設定。這幾件事的共通點不是程式 bug，而是隱藏的假設從未被明確化——直到問題暴露，才發現根本沒有人說好「零點」在哪裡、「完成」是哪一刻、「隔離」是什麼意思。
回測說第一天買，實盤卻在第六天追——兩套邏輯原來從未對齊 #
自動化交易系統最難察覺的問題，不是程式當機，而是「它在跑，但買的點跟回測不一樣」。3Q 台股量化平台在實盤追蹤中發現，同一檔標的回測在訊號出現後第一天進場，實盤卻在六天後才買入，入場價貴了約 6%。兩套都沒有報錯，差距全由進場時間點解釋。
追查根因分兩層。表層是 MACD 類訊號一旦觸發，往往連續數日都顯示 BUY；深層是回測的統計口徑是「上一個 SELL 之後的第一個 BUY 日」，而實盤邏輯是「當天只要是 BUY 就進場」——遇到每天重算的過濾條件時，可能讓實盤在訊號已連亮多天後才通過，等同追高。修正方向是在進場判斷加一道時間門檻：今天必須是這組訊號對「上一個 SELL 之後的第一或第二個 BUY 日」，超過則不追，進觀察池等下一輪循環。停損後同一波也不再重進。修正後用現有四檔倒推驗證：買在回測當天的兩檔判定「可進」，晚了 6 天與 25 天的兩檔被攔下，與實際盈虧方向完全吻合。這個驗證說明邏輯修正不是事後補救，而是把實盤與回測重新校準到同一條規則。
量化策略上線前，不只要測「訊號對不對」，還要明確定義「何時算第一次觸發」——這個邊界在回測引擎裡可能是隱含假設，卻在實盤執行時造成系統性偏移。任何帶有「連續訊號」特性的自動化規則（促銷觸發、預警通知、補貨建議）都存在同樣的陷阱。
兩套電池計數都沒有算錯，差的只是「零點」定義不同 #
太陽能儲能系統長期存在一個疑問：保護板回報的剩餘電量百分比，和系統自行計算的可用安培小時數，為何總是對不上？這類「數字不一致」的問題往往讓人懷疑感測器壞了或韌體有 bug，但實際上兩套數字可能都是對的。
Solar Monitor 這週透過三週的 BMS 原始資料，用每晚充放電事件的電流積分除以 SOC 變化，反推出保護板認定的實際容量，14 個晚次的結果收斂在 ±5% 以內，相當穩定。進一步比對後確認：保護板的邏輯是滿充歸 100%，之後純庫倫計數往下扣；而系統定義的「0%」放電下限，在保護板眼裡仍剩約 21%。把這個偏移換算回安培小時：全容量 × (1 − 21%) 的結果，與實測的可用容量幾乎完全吻合。結論是兩套計數系統本身都準，只是「零點」的錨點定義不同。不需修正任何硬體或參數，只需在系統層面做定義對齊。
「數字對不上」不一定是其中一個算錯——更常見的情況是兩套系統各自定義了不同的基準點，卻從來沒有人明確寫下來。IOT 系統整合、設備資料對接、跨系統報表匯整時，值得先問：「這個指標的零點，兩邊說好了嗎？」
按下送出不等於等到確認：電子發票上傳的非同步陷阱 #
eMobile 電子發票平台的 B2B 上傳流程中，操作人員反映「上傳後查不到紀錄」。但實際上檔案早已送達財政部電子發票平台端，只是系統誤判成失敗而中止後續流程。問題的根源不在網路或平台，而在程式的時序設計。
原本的邏輯是按下「上傳 → 確認」後，不等平台回應就立刻跳到清單頁核對。平台回應速度穩定時可以運作，一旦平台變慢或流程多一個步驟，切頁動作就中斷了仍在進行中的上傳請求，前端查不到紀錄、程式誤判失敗並停止，但檔案其實早已到達。修正策略選擇不沿用舊路徑，改為：上傳後先等平台明確回應，再直接跳到「查詢」頁用發票號碼確認。為吸收平台處理延遲，加入每 10 秒查一次、最多 6 次的重試機制；6 次後仍有任何一張找不到，整批停止並回報缺失清單，避免部分送出造成對帳困難。核心取捨是：用可預期的最長等待時間換取流程的確定性，而非冒著靜默失敗的風險。新版 B2B 1.8.22 已打包上架。
「發出請求」與「等到確認」是兩件事，在非同步環境中不能混為一談。這個模式在任何需要對接外部平台（金流、政府 API、第三方服務）的系統中都值得檢視：你的流程是在等確認，還是在等切頁？
SDK 的預設行為有時就是安全漏洞：隔離環境必須明確宣告 #
fate.motoway.tw 是 3Q 自有命理查詢產品，背後走 Claude Agent SDK。本週發現一個嚴重的隔離問題：每一位訪客開啟對話時，系統都會自動載入伺服器帳號的個人設定，包含會把上一場使用者對話內容注入提示詞的 hook，以及具備遠端執行能力的 MCP 工具——訪客不知情，系統也沒有任何報錯。
根因是呼叫 Claude SDK 建立 session 時未設定 setting_sources，SDK 預設行為是載入執行環境帳號的所有設定，包含個人 hook、CLAUDE.md 規則與已安裝的 MCP 工具。對於開發者自己用的工具，這個預設合理；但對於公開網站的訪客 session，這個預設等同把開發環境的所有權限暴露給任意用戶。修正方式是在兩個對話端點建立 session 時明確傳入空的 setting_sources，讓 SDK 以隔離環境執行，不帶入任何個人設定。驗證確認修改前 hook 確實會注入，修改後三樣設定全無、問答功能照常運作。
用 AI SDK 建公開服務時，「預設行為」和「你需要的行為」之間的差距可能不只是功能問題，而是資安邊界問題。任何把 AI 能力包裝成公開端點的場景，都應該明確宣告 session 的隔離範圍，而非依賴預設。
本週其他進展 #
- Claude Nexus Chat 補齊「編輯重送」與「分岔對話」功能 — 透過 SDK 的 resume_session_at 機制，讓使用者可以把有疑慮的那輪從 context 移除後重送，或從任意訊息點另開對話分支。同步修正換模型後後端仍沿用舊模型的問題。
- Claude Nexus 新增子代理軌跡視覺化面板 — 以「卡片 + 共用時間軸」設計取代圖形畫布，每個子代理顯示任務、耗時、動作數與回報摘要，被安全分類器攔截的子代理以紅色「出錯」狀態呈現，而非原本的靜默 API Error。
- Claude Nexus Proxy 新增即時用量統計面板 — 在 proxy 加入用量端點，從對話紀錄反算 token 並按模型與呼叫來源彙整，讓異常大量呼叫的批次任務一眼可見，成功定位出本週撞到用量上限的根因。
- FATE 奇門遁甲「上中下元」計算邏輯重寫 — 修正程式只看「節氣當天」而未計算節氣後經過天數的缺陷，改用正規超接置閏法，修正後對照老師提供截圖，九宮全格一致。
- FATE AI 擇日年份解析從自由文字改為下拉選單 — 移除從輸入文字猜測年月的邏輯，改為固定選單（未來 30 天或指定起訖最多 6 個月），根除因生辰年份與目標年份混淆導致的查詢錯誤，並將查詢逾時從 60 秒延長至 120 秒。
- FATE 隱私權政策與關於頁面內容治理 — 修正「定期自動清除 IP」不實描述，補上 AI 解讀資料送交第三方的說明，移除關於頁誤述，選單重整為 6 分類下拉結構後送 GSC 重新索引。
- motoway.tw 進展頁改為 18 支獨立頁面提升 SEO 精準度 — 將 100 多條進展依系統拆分，每頁帶入具體描述、加上麵包屑結構化資料與頁尾互連，18 頁全部提交 GSC 索引，解決原本單頁設計導致搜尋語意切割失效的問題。
- 某電商客戶訂單統計全面排除「已取消」訂單 — 修正訂單列表、報表、儀表板、熱銷排行、促銷贈品報表及 AI 查詢前提共六處混入已取消訂單的問題，統一規則：所有統計預設排除已取消，確保衍生指標（日均單數、轉換率）不失真。
- 某電商客戶新增「僅門市販售」商品屬性並上線 LINE AI 客服 — 拍貼機代幣活動改為門市限定，網站結帳攔截邏輯驗證正常；LINE AI 客服本週正式上線，設計上只回答第一句後交回真人，避免 AI 接管完整對話的不可控風險。
- 發票抽獎系統審查通知信上線，同步完成 SEO 部署 — 補上後台改判時自動寄送通知信的邏輯，退件原因同時回填前台查詢頁；GA4、GSC 結構化資料、舊網址 301 轉址一併完成，七頁 sitemap 已被 Google 與 Bing 抓取。
- 出遊申請系統「例外人員」從硬編碼改為後台可配置 — 在既有資料表新增欄位，讓旅行社人員自行勾選開放例外資格，不再需要工程師改程式重新上線。前台新增統一的日曆顯示判斷入口，其餘規則（國定假日、車輛總量、截止日）完全不動。
- 3Q 倉儲系統報表日期邏輯統一修正跨月邊界漏單問題 — 系統性比對受影響資料後，統一修正 17 個檔案的台北時區日期篩選邏輯，對全角色報表逐一驗證，確保同一區間查詢結果收斂。
- 3Q 倉儲系統庫存異動強制留存稽核紀錄，修正靜默回滾 bug — 手動調整與批次匯入均強制填寫原因才能儲存，每筆寫入含操作人與調整量的異動紀錄；同步修正編輯頁開啟後若有出貨扣減、按儲存會把快照值蓋回去的並發覆蓋問題。
- sunnypilot 停紅燈控制授權持久化，407 項安全測試全過 — 在 panda 韌體、通訊層、openpilot 軟體三層同步修改，踩煞車與方向盤中間鍵不再清除授權，授權僅在熄火時自然重設，等待實車驗收。
- sunnypilot 前車換人後緩加速，資料驅動設計 — 分析千次以上換車事件後，確認前車剛被認到時速度估算未收斂是急加速後補煞的根因，換車後 5 秒內將加速上限壓低，保留「前車明顯加速離開」的豁免條件，模擬有來回換車比例從 85% 降到 40%。
- 期貨策略平台重播結果支援 CSV／JSON 下載 — 重播完成後新增三個下載按鈕，逐根明細 CSV、三種模式並排的交易明細 CSV（含來源欄區分）、完整 JSON，檔名含策略與商品資訊，CSV 附 BOM 避免 Excel 中文亂碼。
- 期貨策略平台手機重播卡在「計算中」問題修復 — 將長連線推送改為短連線輪詢（每 2 秒一次），按下開始後立即回傳工作編號，按鈕即時顯示計算進度，手機鎖屏或切 App 回來也能自動接續結果。
- 某餐飲客戶向永豐申請線上信用卡收單，完成 13 頁說明書 — 文件涵蓋網站架構、購物流程截圖、退款政策與個資保護，同步修正網站多處沿用多年的聯絡電話錯誤，並在網站新增信用卡結帳路徑（審核展示版啟用，正式版待串接完成後開放）。
- 某製造業客戶 MSSQL 報表 view 烘坯數顯示為零的根因定位 — 確認問題出在 view 篩選條件未隨業務流程更新，10 月起已出車的記錄狀態從「烘坯中」推進為「烘坯完成」，舊條件全部排除。SQL 修正已撰寫完畢，待客戶確認後上線。
- planmaker 完成 GA4、GSC、Bing Webmaster 初始串接 — GA4 直接在後台完成與 GSC 的資源連結，Bing 從 GSC 匯入網站省去獨立驗證，客戶帳號以「檢視者」角色加入 GA4；sitemap 目前 GSC 擷取異常，根因診斷中。
本週技術心得 #
這週看起來是不同專案各自解決自己的問題，但有一條隱線貫穿始終：系統在「沒有報錯」的狀態下，悄悄地做了和你以為不一樣的事。
中小企業導入自動化或 AI 工具時，最容易忽略的不是「會不會壞」，而是「它跑的和你想的是不是同一件事」。量化交易的回測與實盤邏輯在文件上看起來相同，但定義「第一次觸發」的方式不一樣，結果就南轅北轍。電池管理系統的兩個數字都是事實，但「零點」沒說清楚，對帳就永遠差一截。SDK 的預設行為在開發環境合理，但在公開端點就變成隱患。
這些問題的共同修法不是「加更多驗證」，而是「把隱含的假設變成明確的定義」——在策略進場加時間門檻是明確規則；在 SDK 呼叫加 setting_sources: [] 是明確隔離；在電子發票流程加重試與停止條件是明確確定性。
對想導入自動化或 AI 的企業來說，這個教訓很實用：新系統上線前，值得問一次「這個詞，程式和你的定義一樣嗎？」這個問題聽起來很基本，但多數問題都藏在這裡。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。