找一顆電阻，花掉半節課
實習課和專題製作時，大家常常要在元件盒裡翻找零件。零件種類多、格子排列複雜、標示又不清楚，很容易拿錯規格、多拿或少拿。
庫存也沒有系統：零件快用完時，要靠學生主動告訴老師才會補，既不即時也不完整。我們想做一套能快速定位、即時辨識、自動管理庫存的系統，把時間還給實作本身。
一支 App，三個功能
BoxApp 用 SwiftUI 開發，以 TabView 分成「零件盒」「零件辨識」「我的庫存」三頁，相機、庫存和藍牙狀態透過依賴注入在各頁共用。
智慧庫存管理
手動輸入或拍照建立零件資料；同名同規格自動累加數量，資料以 JSON 存在手機裡。
AI 零件辨識
拍下零件，交給 Gemini 判讀名稱、規格、功率與用途；確認後一鍵加入庫存。
藍牙硬體連動
選好零件，App 透過 BLE 通知 ESP32，對應格子的盒蓋自動掀開、燈號亮起。
手機負責操作，雲端負責看，ESP32 負責動
影像辨識交給雲端模型，手機只處理介面與流程；開蓋指令走藍牙直接送到盒子，不需要網路也能用。
試了三種方法，才找到會「動」的那一個
一開始想用燈號指示位置，實測後一路改到伺服馬達拉線。每一次放棄都有明確的理由。
LED 指示燈
App 下指令後對應格子亮燈。但實驗桌上光線太亮，燈號根本看不清楚。
電磁線圈彈開盒蓋
用電磁斥力把蓋子推開。概念可行，但需要大電流和大線圈：耗電、佔空間、散熱差，安全性也不夠。
伺服馬達拉線＋磁吸
馬達轉到 90° 拉緊棉線掀開盒蓋，回到 0° 放鬆、蓋子靠重力落下，再由磁鐵吸住，搬運時也不會誤開。馬達端並聯 100 µF 電容、加上續流二極體，避免突波讓板子重開機。
BoxApp
從原本的 Swift 架構全面改寫成 SwiftUI＋MVVM。相機用 AVCaptureSession 自己封裝，加入手勢縮放與點擊對焦；藍牙模組有模擬模式，沒有硬體也能測完整流程。
100% 準確率，反而是警訊
我們先用 Google Cloud Vertex AI 訓練自己的分類模型。驗證結果漂亮得不真實——因為資料只有兩類、量也太少，那個數字只代表資料太單純，不代表真的會認零件。
Vertex AI 自訓模型 放棄
- 431 張圖（訓練 345／驗證 43／測試 43）
- 只有 2 個類別，泛化能力無法驗證
- 訓練 20 多小時就累積大量費用，學生負擔不起
Gemini 2.5 Flash / Pro 採用
- 不用自己蒐集、標註、訓練
- 同時判讀外觀、規格與基本用途
- API 改版快：回頭對照官方文件，重新核對模型 ID、Request Body 與標頭才串通
卡住的地方，都在「接起來」的縫裡
- ERROR
does not conform to ObservableObject→ 漏了import Combine - ERROR
Undefined symbol: _main→ App 進入點檔案被移出 Target，重新加回 - ERROR
'openCompartment' was not declared in this scope→ 在使用前補上函式原型 - ERRORBLE 回傳失敗：
setValue()不收std::string→ 改傳uint8_t*與長度 - FIXEDGemini「模型 ID 無效」「請求格式錯誤」→ 網路範例過時，改照官方最新文件重寫請求
從選零件到開蓋，只要幾秒
外觀相似的零件仍需要人工確認；AI 快速建檔功能還有 JSON 解析與重複寫入的問題待修，會在後續版本改善。未來想加入 Wi‑Fi 雲端同步、開蓋感測回饋，並在經費允許時訓練能在本機執行的小模型。
要當一個 T 型人
我們熟悉電路和程式，但對機構幾乎陌生。盒蓋開關不順的問題卡了很久，靠著一次次請教老師、修改才解決。這讓我體會到：只會一個領域不夠，要能往旁邊延伸。
軟體上，為了突破 App Inventor 的介面限制，我們選了較少人走的 SwiftUI＋ESP32 組合。這次不只學會 App 開發和串接 AI，也在軟硬整合時補上了許多實習課沒教到的實務電路知識。
下一步回到作品列表