本週工程團隊在多條主線同步推進：摩葳寄售系統 Phase 1 完成 31 項測試並正式上線，門市 POS 與電商庫存同步架構完成規劃；eMobile 攤位與 HQ 多功能持續交付，LINE Pay 完成 sandbox 端到端驗證取得正式金鑰；Stock Trading v2 回測邏輯貼近真實市場並修復排程寫入異常；Claude Nexus 知識庫授權與搜尋問題精確定位修復；Solar Monitor 與 PiBar 在硬體層持續深耕。基礎建設面，電源事件後全機復原驗證與 VPN 路由故障排復均順利完成。
新專案 #
摩葳寄售系統 Phase 1 完成建置與部署 #
完成摩葳實業寄售管理系統第一階段建置，涵蓋多通路差異計價模式、品項對應邏輯、金融計算規則與 UI 呈現，31 項測試全數通過後正式部署上線。同步完成解析器模組規劃，為後續自動化資料匯入打下基礎，系統已具備真實業務承載能力。
門市 POS 與電商平台庫存同步架構規劃 #
規劃以 POS 為起點、經電商平台、Hub 至 HQ 的多層庫存同步拓撲，釐清各節點職責邊界。POS 端聚焦發票開立與打卡核心功能，發票字號依通路分段分配，確保多通路並行時字軌不衝突。此架構為後續門市與線上庫存實時同步奠定基礎。
既有專案改進 #
Claude Nexus：知識庫授權機制排查與多主機驗證 #
追查 save_memory 功能回傳授權錯誤的根本原因，確認為設定檔缺漏所致，補齊後推送至多台主機並逐一驗證成功。過程展示了跨主機設定一致性管理與快速定位授權鏈問題的能力。
Claude Nexus 搜尋故障定位：前端層問題精確隔離 #
搜尋功能異常時，透過逐層驗證確認後端搜尋邏輯運作正常，問題根源在前端事件處理層。這種前後端責任明確切分的診斷方式，避免了對後端的無效修改，大幅縮短修復週期。
gomylife.tw 技術週報自動化：隱私安全、排序修正與排程穩定性 #
補齊多週技術週報內容並完成上線，同步修復隱私資訊外漏問題與列表排序邏輯錯誤。另外診斷自動化排程失效根因為日誌檔權限設定不當，修正後排程恢復正常執行，提升整體發布流程的穩定性。
eMobile 攤位與 HQ 多功能階段交付 #
本週完成攤位字軌改當期及下期分配、商品 UPSERT 邏輯、全量檢測機制，以及 HQ 端新增商品等多個功能階段，同步部署多支新 API endpoint。新版本攤位與 HQ 端均已完成打包並交付，持續推進各通路功能完整性。
診斷並修復遠端 XML 殘留的撤回同步 bug #
發現 HQ 與 B2B 兩個通路在撤回操作後，遠端 XML 未被正確刪除的問題。追查根本原因為前端程式碼硬寫參數覆蓋了後端預設行為，導致刪檔指令失效。同步修正兩個版本的邏輯並重新打包交付，確保撤回操作的資料一致性。
HQ 報表邏輯重新定義，支援多支付方式分類統計 #
重新定義 HQ 報表的統計邏輯，改為現金與電子支付各別獨立統計，提升帳務數據的可讀性與對帳精確度。同步完成攤位商品編輯標題修正，並規劃完成後續各功能階段的推進順序。
LINE Pay 正式上線前置作業全數就緒 #
完成 LINE Pay sandbox 環境的端到端完整驗證，確認金流流程無誤後取得正式金鑰，並完成安全白名單設定。所有上線前置條件均已達成，金流整合品質以完整驗證流程把關，而非僅依賴文件確認。
Stock Trading v2：回測情境貼近真實市場邏輯 #
將回測成交模式調整為隔日開盤市價，使模擬結果更符合實際可執行的交易條件。同步修正觀察池因篩選門檻前後設定不一致而導致全數清空的 bug，重新確立「先進池、再評估買點」的漏斗順序，確保選股流程邏輯自洽。
Stock Trading v2：Scheduler 寫入異常根因定位與修復 #
透過 ORM 部署層的行為差異診斷出 Scheduler 無法正確寫入觀察池記錄的根因，重啟服務後驗證修復生效。展現對排程器與資料庫中間層的完整可觀測能力，問題定位精確、修復週期短。
Solar Monitor：新一代逆變器通訊協議相容性規劃 #
完成對 SRNE V2.6.1 協議的暫存器位址盤點，比對舊系統映射表後確認核心邏輯不變、僅位址有所更新。已完成差異分析與升級規劃，待硬體到位即可按新規格更新 solar-service 程式碼與 Modbus 暫存器映射，確保監控資料不中斷。
PiBar：音頻斷音根因定位至 AI 推論資源競爭 #
追蹤 PiBar 音頻播放中斷問題，診斷出根源為 YuNet 臉部偵測推論佔用過高 CPU，與音頻執行緒產生資源競爭。調降推論頻率後音頻穩定性顯著改善；啟用 voice_listener 常駐模式後出現新的播放中斷情境，持續深入追蹤，展現邊緣裝置上 AI 推論與即時音頻共存的調校能力。
基礎建設 #
多台 Linux 主機批次更新與 VPN 路由故障排復 #
執行多台主機例行批次更新，並遠端排查其中一台主機 VPN 連線中斷問題，確認根因為路由表被清空，手動補回路由後連線恢復正常。展現了對 Linux 網路層的快速診斷能力與遠端運維紀律。
電源事件後全機盤查：基礎設施自動復原驗證 #
電源重開後執行完整的基礎設施盤查，涵蓋實體主機、PVE 虛擬化平台與所有 Docker 容器，確認各服務均按預期自動拉起並正常運行。定期執行此類盤查是維持高可用性的基本紀律。
技術心得 #
大型語言模型在超大 Context 下的 JSON 輸出退化現象 #
本週遭遇大型模型出現 malformed 結構輸出，系統性排查後確認根因為 context 視窗壓力過大導致 JSON 格式退化，而非資料品質問題。這項診斷結論讓我們能精準調整 context 管理策略，而不是無謂翻查資料管線。
Stock Trading v2：兩則假警報的診斷方法論 #
針對前端呈現的兩個「看起來有問題」的現象逐一溯源：觸發價無法計算源於策略精度過濾條件的設計行為，並非資料錯誤；篩選頁面一閃空白則是 React Query 首次載入的瞬間狀態，並非真正無資料。將每個症狀獨立回推至其執行路徑，是避免誤判、浪費修復資源的核心工程紀律。
本週技術心得 #
本週最值得中小企 IT 團隊借鑑的，是「症狀獨立溯源」這條工程紀律。無論是 Claude Nexus 搜尋的前後端責任切分、Stock Trading v2 的兩則假警報診斷，還是 PiBar 音頻與 AI 推論的資源競爭定位，都遵循同一個邏輯：不因「感覺是同一件事」就合併處理，而是每個症狀各自往下追到執行路徑的斷點。這個習慣在人力有限的小團隊裡尤其關鍵——錯誤的假設會讓工程師在錯誤的地方挖半天，真正的問題卻毫髮未傷。
另一個值得記錄的觀察是 LLM 在超長 context 下的 JSON 退化問題。這不是模型品質差，而是 context 視窗壓力到達臨界點後的可預期行為。對於把 AI 整合進業務流程的團隊來說，這意味著：輸出結構的穩定性需要納入架構設計，而不是事後靠 retry 兜底。控制輸入 context 的長度、在關鍵輸出前明確重申格式約束，是目前最務實的對策。
最後，摩葳寄售系統以 31 項測試全通過作為上線門票，LINE Pay 以完整 sandbox 端到端驗證取代文件確認——這兩個案例都在說同一件事：「測試是信心的來源，不是流程的裝飾」。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。