專案與工作研究經驗

工廠 AI 轉型：數據底座才是第一道門檻——用 AI 解老設備協議的難題

專業文章｜2026-10-15 發表

獨立撰寫與發表（個人觀點文章）

針對製造業 AI 專案普遍「半途卡住」的現象提出診斷：真正的瓶頸不是演算法，而是高品質底層數據的獲取。文章主張「先建數據底座、再上層 AI 應用」的正確順序，並提出以「AI＋自研邊緣運算板」做數據逆向工程的策略——現場抓包、AI 批次分析封包特徵、自動生成協議層，讓老舊私有協議與現代標準協議都能接入，不需原廠文件、不需大規模換機。

閱讀全文　·　English version

專業文章｜工廠 AI 轉型的數據底座論

專業文章｜2026-10-15 發表

獨立撰寫與發表（個人觀點文章）

針對製造業 AI 專案普遍「半途卡住」的現象提出診斷：真正的瓶頸不是演算法，而是高品質底層數據的獲取。文章主張「先建數據底座、再上層 AI 應用」的正確順序，並提出以「AI＋自研邊緣運算板」做數據逆向工程的策略——現場抓包、AI 批次分析封包特徵、自動生成協議層，讓老舊私有協議與現代標準協議都能接入，不需原廠文件、不需大規模換機。

文章緣起與問題定義

觀察到製造業 AI 專案大量停在上層應用（AI Agent、智能排程、品質預測）而中途卡住，遂將問題重新定義：瓶頸不在演算法，而在底層數據能否完整採集、是否具營運價值、是否乾淨無漏記。這三項是上層模型可靠輸入的前提。

論證結構與策略主張

文章依「門檻溯源 → 傳統解法代價 → 核心策略 → 正確順序」四段展開。傳統解法（索取原廠文件、客製驅動、汰換硬體、加裝傳感器）又貴又慢，且老設備原廠多已停止支援並拒絕釋出協議規格；因此提出以邊緣硬體抓包搭配 AI 批次封包分析與特徵提取，自動生成協議層作為替代路徑。

實務對應與發表資訊

文中的邊緣抓包與協議自動生成策略，對應個人持續開發中的「工業邊緣網關（軟硬體＋AI）」專案（ESP32-S3 邊緣節點板 ＋ JSON 協議描述引擎 ＋ AI 生成協議描述與規則）。全文另收錄於本站 Blog 日誌（中英雙語）。

資料依據：個人專業文章，2026-10-15 發表｜全文見本站 Blog 日誌（zh-TW／en）

AI 表面缺陷分類與可解釋性實作

AI 視覺檢測實作｜2026

資料管線、模型訓練、可解釋性分析與演示介面，獨立完成

以工業表面缺陷為題，建立一套可複現的視覺分類實作：從公開工業資料集建構資料管線，在同一協定下比較 CNN 與 Transformer 兩類架構的遷移學習表現，並以 Grad-CAM 驗證模型判據與人工標註的一致性，最後包裝為可現場演示的推理介面。核心目的在驗證「判得準，也要判得能解釋」在產線 AI 的可行性。

問題定義與資料管線

以鋼材表面六類缺陷為分類目標，將 Pascal VOC 標註解析為類別標籤，建構固定種子的分層切分與統計報告，確保訓練、驗證與測試互不重疊，並產出資料樣例與標註框對照，作為後續可解釋性比對的基準。

模型比較與架構觀察

在同一資料切分與訓練協定下比較 CNN 與 Transformer，兩者盲測皆達 100%，說明在特徵明確的工業缺陷分類上，影像特徵與預訓練表徵已相當足夠。差異主要呈現在可解釋性——CNN 熱區聚焦缺陷主體，ViT 注意力分布較廣，反映架構特性對判據可讀性的影響，也是產線選型時除準確率外需納入的考量。

可解釋性與落地邊界

以 Grad-CAM 將模型判據視覺化並與人工標註框比對，驗證關注區域與缺陷位置一致。此環節對應產線 AI 的關鍵需求：判定結果須能被品保、製程與客戶追溯理解，而不只是分數。效益邊界說明：本專案為公開資料集之離線驗證，非實際產線部署；資料集本身規模與場景有限，100% 準確率反映基準特性，不等同量產環境表現。

資料依據：個人開發紀錄（GitHub: ai-aoi）｜NEU-DET 公開工業表面缺陷資料集

Wafer-to-Market 半導體後段實戰

半導體供應鏈與商品化專案｜2021

資金與供應鏈整合、測試封裝協調及銷售推進

2021 年疫情與晶片缺貨期間，透過產業管道取得 16 片 SXX wafer，整合資金與供應鏈資源，完成從晶圓取得、測試與封裝驗證到最終銷售的完整流程。

資料依據：

LINE 掃碼點餐 SaaS（PickMy Order）

獨立建置｜2026

產品定義、系統架構與開發主導

面向線下門市的 LINE 掃碼點餐與輕會員 SaaS，以掃碼點餐、會員積分與次卡為核心，從產品定義、前後端開發到自動化測試獨立推進（此處僅描述通用能力，不涉及專案細節與機密）。

資料依據：

0→1 數位平台建設與上線實戰

獨立建置｜2026

系統規劃、開發、測試到正式上線全程一人主導

以業餘時間完整走通一個多角色服務平台從架構設計、前後端開發、自動化測試到雲端生產環境上線的全流程（此處僅描述通用能力，不涉及專案細節與機密）。

資料依據：

AI 製程與工程參數最佳化

工作專案研究｜常熟精元

參與工程拉拔力預測，結合工廠管理推動製造 AI 應用。

將製造與設計問題轉為可分析的參數、預測目標及驗證流程，研究壓 key、噴漆治具、Pogopin 推力、鍵帽拉拔力與雷雕參數最佳化。

研究問題與方法

工程拉拔力專案針對鍵帽卡鉤開口尺寸依賴經驗及開模試錯的問題，利用材質與既有拉拔力資料，研究設計尺寸預測及參數組合推薦。簡報記載以 20 筆資料建模，另取 3 筆資料測試，屬初步驗證，仍需擴充不同規格與工況資料。

製造端驗證案例

壓 key 專案結合氣缸壓力、頂出時間、壓合時間與 Rubber 硬度，經模型推薦及線下測試，報告記載指標從 200 提升至 1,113 pcs／次。這是跨部門團隊成果，保留原始單位與適用範圍。

效益與研究邊界

拉拔力專案列出修模、實驗人力及新人培訓合計 RMB 104,800／年的估算效益。此金額為情境估算，不列為已實現節省，也不與原履歷 RMB 2M+ 單年成果加總。後續研究方向包括公差範圍推薦、擴充樣本與持續線下驗證。

資料依據：《AI專案優化彙整》：第 20、22、62、66–67、71、74、79–80 頁。拉拔力專案列名參與，其餘案例依團隊報告整理。

Jingtek E-bike App 與 IoT 服務系統

產品規劃與創業研究｜E-bike／IoT

結合共同創辦人／執行副總期間的產品研發與 App／後台架構規劃經驗。

研究電動自行車硬體通訊與 App、管理後台的整合，將產品功能延伸至線上交易、售後服務與使用者社群。

App 與後台服務規劃

簡報呈現車況異常偵測、附近維修據點、商品選購、願望清單與點數消費等情境。管理後台涵蓋會員、商品、維修管理，以及消費行為與商品銷售分析，將產品研發與售後服務流程一併考量。

IoT 與商業模式研究

研究透過社群、試乘及維修服務提升使用黏著度，並探索線上交易與體驗分享模式。租賃方案提出 GPS 定位、防盜與電子圍欄功能需求，硬體端則提出通訊相容與 OTA 更新程式庫規劃。

經驗定位

本案例呈現系統規劃、軟硬體整合與商業模式研究。簡報未提供營收、使用者數或全面上線驗證，因此不將功能構想寫成已實現的商業成效。簡報中的「支援逾 60% 通訊協定」屬硬體需求，與原履歷「65% 以上硬體適配率」為不同指標。

資料依據：《Jingtek E_bike app system》：第 3、5–16 頁。個人職責脈絡依《洪承洋resume0915》創業與 App 架構規劃經歷。

智能體工作流與製造業治理研究

持續研讀｜Agentic Workflow

研讀 Morris Fan 講義，延伸思考企業私有 AI Agent 的流程整合與管理機制。

以《智能體工作流的實踐與挑戰》為研究參考，聚焦製造現場問題定義、資料與工具串接、人工覆核，以及可追溯的決策流程。

架構與工作流研究

參考講義的資料與工具、智能體核心、協調工作流及治理覆核架構，研究如何把現場需求轉為可執行、可觀測的任務流程，並為資料查詢、工具操作與結果驗證設定清楚邊界。

製造營運治理觀點

聚焦人工覆核（Human-in-the-loop）、工具權限、證據紀錄、異常處理及中止機制，將不可逆性、產線風險與資料敏感性納入導入評估。研究任務成功率、成本、延遲與失敗恢復等管理指標。

研究應用與來源歸屬

將設備維修、品質知識、生產排程、需求預測及供應鏈預警作為後續應用研究方向。此項為講義研讀，原作者為 Morris Fan；講義示範系統、程式及成效不列為本人開發或部署成果。

資料依據：Morris Fan，《智能體工作流的實踐與挑戰》：第 4–13、27–32、73–82、84–91 頁。研讀參考，非本人著作。

技術經驗專家化與 AI 輔助審查實作

知識資產化實作｜2026

獨立完成：經驗萃取、專家角色定義、審查流程建置與人機分工驗收

將 10+ 年嵌入式電源與電機控制經驗（換相真值表、保護判據、CAN／J1939 協議設計）萃取為可封裝、可分發的專業專家角色，讓經驗不再隨人走；並以真實韌體驗證「AI 做標準化初步審查、人員負責風險定案」的人機分工——第一輪即產出 3 項安全紅線級缺失。

問題定義：經驗如何變成可攜資產

起點是資深技術經驗高度集中於個人、難以轉移的典型困境：關鍵判斷準則存在於腦中與程式註解裡，新人須靠反覆請教與試錯累積，經驗一旦離開原持有者就難以再生。傳統解法是寫文件或做教學，但兩者都難以承載「什麼情況下該做什麼判斷、什麼情況下絕對不能這樣做」這類帶條件的專業直覺，也無法在實務現場即時觸發。解法是把經驗改寫成可執行規則並封裝成角色，讓它在使用場景中主動被召喚。

萃取方法：把判斷準則轉為可執行規則

萃取重點不在把技術名詞寫齊，而在四類可執行規則：一是能力邊界（何種問題該由這個角色處理、跨到哪裡必須交還人）；二是工作流程（面對問題的固定推進順序，先定位邊界再拆解層次再給方案對照再落到參數級）；三是輸出規範（結論先行、對照表、參數帶單位、風險需標註來源）；四是安全禁區（不可逆動作、人身安全相關閾值、必須實測不得推定之項目）。四類規則缺一，角色就退化成問答機器人而非可承擔判斷的專業資產。

人機分工：AI 做標準化初審，人做風險定案

本次以真實韌體作為驗收標的。分工設計為：AI 依既定規則執行完整初步審查並產出可複核的客觀結論，人員負責判斷風險等級、確認修正方案與最終放行。實際結果顯示此分工有效——AI 產出的缺失多屬可機械比對與可數學推導的類型（對應關係錯置可由位元序逐條比對確認，方向錯誤可由場向量角度推導確認），而風險定案與方案取捨仍需人承擔。此分工同時降低了對資深人力時間的佔用，使資深人員投入從「逐條檢查」轉為「定義標準與終審決策」。

品質紀律：拒絕單一來源，兩路徑互證

此案最關鍵的實踐是確立「單一來源結論不予採信」的驗證紀律。同一技術結論分別以「逐條位元序比對」與「空間場向量角度推導」兩條獨立路徑重現，兩者必須一致方視為定案。同時要求驗證腳本直接從原始碼解析參數表、禁止人工轉錄——本次實際因此擋下一次轉錄造成的誤判（原判定為 5 項錯誤，經原始碼解析後修正為 4 項）。此紀律與製造業既有品質管理精神一致：不信任單點數據，須以可重現方法交叉確認，差異須追到底而非取其一。

風險分級與閉環：讓缺失可被指派

所有缺失依「是否涉及人身安全與產線安全」分為安全紅線、高風險、一般建議三級，每項均對應到具體修正動作與驗證方法，並明確標示須實機確認的項目與試驗程序。此分級設計使技術審查輸出可直接接入既有缺陷管理流程，而非停留在建議清單，使閉環速度取決於執行而非再翻譯。

實踐邊界與後續

此案為個人實作，驗證對象為自有韌體專案，尚未推廣至多專案並行或跨團隊複用。已確認的後續方向包含：將個人路徑與環境相依的私有資料與公開通用知識分離，以便在不同環境獨立使用；將可機械化重複的檢查（如參數表與文件一致性核對）固化成可重複執行的自動檢查；以及在累積足夠案例後評估將此類審查經驗轉為對外的專業技術服務。相關結論均為個人實測與分析結果，未經第三方驗證。

資料依據：個人實作紀錄（2026-10）：角色定義與審查規則自建，驗收對象為自有嵌入式韌體專案；驗證腳本與審查報告可重複執行以複核結論。

電動車控制器嵌入式開發

持續開發｜Embedded Systems

個人技術研究與開發（持續進行）

以 10+ 年嵌入式開發經驗為基礎，持續進行電動自行車控制器（三相 BLDC 電機控制）的韌體與工具鏈開發：從電機控制演算法、量產保護判據移植、通訊協議設計、上位機調校工具，到運行數據記錄與 AI 輔助診斷的整鏈實踐。

電機控制與韌體

以現代雙核 MCU（整合 CAN／BLE）重構量產驗證過的控制邏輯：三相 BLDC 換相與 SVPWM 正弦控制、過流／欠壓／堵轉保護，以及電磁煞車（E-ABS）與動能回收的韌體實現與安全管理。

協議與工具鏈

設計控制器↔儀表↔BMS 串列通訊協議與調試幀，開發 Windows 調校工具（參數讀寫、霍爾校準、即時曲線、診斷包導出），支撐電機匹配與量產標定流程。

AI 應用探索

將運行數據（電流、轉速、電壓、負載狀態）導出為結構化診斷包，探索大模型輔助故障診斷與電機參數自學習，延伸 IoT 服務與售後應用的可能。

資料依據：個人開發紀錄（GitHub）

電動車電池管理系統（BMS）研發

持續開發｜Battery Management

個人技術研究與開發（持續進行）

以 36V（10 串）鋰電池為對象，完成電池管理系統的整體設計：從類比前端（AFE）選型、主控 MCU 與 CAN 通訊架構，到煞車動能回收的安全准入與協商機制、端子接觸電阻線上監測等差異化功能，並產出完整原理圖、逐腳連接表與 CAN 協議草案。

系統架構與硬體

採用 BQ76930 AFE + STM32F103（內建 bxCAN）+ CAN 收發器架構：10 串電芯取樣與均衡、充放電 MOS 功率級、42V→5V 降壓與藍牙音響整合，已交付完整原理圖與逐腳連接表。

通訊協議與回收安全

將舊有 RS232 電池協議映射為 J1939 風格 CAN 報文，與控制器對接；煞車回充設「安全准入＋提前協商禁止」雙層機制（SOC、溫度、電流多級閾值），在不傷害電池與控制器壽命的前提下規劃兩版本落地路徑。

可靠性設計與差異化功能

自研端子接觸電阻 B+/P+ 雙點線上監測，即時估算功率回路接觸電阻並分級告警，提早發現戶外插拔鏽蝕與微振磨損劣化；另整合擬人化語音播報（電量／健康／接觸狀態提示，App 可切換語言與音色）。

資料依據：個人開發紀錄（GitHub: ebikeBMS）

工業邊緣網關（軟硬體＋AI 系統）

持續開發｜Industrial IoT

個人技術研究與開發（持續進行）

緣起於製造業的共同痛點：現場大量老舊設備（RS-232 私有協議儀表、老式 PLC）數據取不出來，設備對接找原廠或整合商，花大錢也不保證解決。本專案方向是以「軟硬體＋AI」把私有協議對接從客製開發變成配置——自研低成本邊緣節點板負責物理接入，JSON 協議描述引擎零改碼解析任意私有幀格式，AI 依抓包樣本與自然語言自動生成協議描述與告警規則，讓老設備快速、低成本接入數據平台。

邊緣節點硬體

自研 DIN 導軌節點板：ESP32-S3 主控＋CH438 多串口擴展，隔離 RS-232×4／RS-485×2／CAN×1，9-36V 工業寬壓與防護設計，以太網／WiFi 上送 MQTT。

JSON 協議描述引擎

私有協議不做硬編碼——幀頭／長度／校驗／欄位表寫成一份 JSON 描述，通用引擎串流解析（任意分片容錯、壞幀丟棄重同步），新增設備只改配置、零改碼；配套本地規則引擎（閾值防抖、死區過濾）完成邊緣計算。

AI 輔助對接

設計期由 AI 從抓包樣本與自然語言描述生成協議描述與規則、人工審核後下發，把協議逆向從人天級壓縮到分鐘級；運行期方向為輕量模型在節點側做異常檢測。

資料依據：個人開發紀錄（GitHub: edgenotepcb）

智能門鎖產品定義與選型（NPI）

產品定義與選型｜Smart Lock

產品定義、方案選型與成本工程，獨立完成（設計階段，持續進行）

以「家用＋公寓＋小型民宿」三場景共用同一套硬體為目標，重新定義全功能智能門鎖需求（WiFi／藍牙／房卡／密碼／指紋／電鈴／App／家居生態），完成生態路線選擇、主控與外設選型、整機成本結構與量產成本工程，以及飯店級完整系統（門鎖＋閘道＋發卡＋管理軟體）的架構規劃；並在既有藍牙鎖專案資產上，規劃自動二段上鎖與防撬警告等差異化功能。

需求重新定義與方案選型

把「WiFi 併入家居」重新定義為支援 Matter 標準（Apple／Google／Amazon／SmartThings 通吃），並將 BLE 認定為配網必經通道而非可選功能。比較自研、商用模組與混合三條路線後定案雙層架構：ESP32-C6（WiFi 6＋BLE 5.3＋802.15.4，Matter 原生）為主控，低功耗協處理器（DeepSleep 450nA）承擔常開待機與觸摸喚醒；外設完成統一選型（讀卡、半導體指紋、6068 標準鎖體、語音提示、驅動隔離）。硬體預留 Aliro（手機錢包碰一碰開門）能力，一次到位、軟體分期上線。

成本工程與三場景配置

建立整機成本結構，拆解八大區塊成本佔比並識別憑證層（讀卡、指紋等身分憑證）為主要成本項與議價重點，據此訂出量產階段的分級成本目標與詢價策略。架構上的關鍵設計是「同板不同配」——家用／公寓／民宿走 WiFi 直連即可，不需額外閘道；飯店則走 BLE 上報＋PoE 閘道集中管理（一台閘道服務多門），硬體差異收斂到鎖體等級、門磁與外殼三處，三個場景共用同一塊 PCB 與同一套韌體。

飯店完整系統與差異化功能

規劃飯店級完整系統：門鎖＋閘道＋發卡器＋房務管理軟體＋安裝交付的整體架構，以閘道覆蓋率最佳化與系統輕量化為成本優勢來源，並建立對外詢價清單與技術風險清單（含關鍵料供應與鎖價策略）。另規劃「自動二段上鎖與防撬警告」：定時／感應自動升二段並分級響應（先物理加固再警告），以四路傳感搭配雙路校驗降低誤報，並對接 Matter 原生鎖狀態與 DoorForcedOpen 報警碼。

資料依據：個人開發紀錄（智能門鎖選型方案 v1.0／功能增補 v1.1）｜併用既有藍牙鎖專案資料