一天做完的收納 App:小專案裡的五個工程決策
拍一張照,AI 認出家裡的物品,依收納專家的方法論給整理建議。四千五百行程式、五十二個測試、一天完成——小專案反而最能看清楚一個團隊怎麼做決定。
這是一個週末實驗:拍照 → AI 辨識出畫面裡的物品 → 依收納方法論產生整理建議與購物清單。React Native 加 Expo,約四千五百行 TypeScript、六個測試套件五十二個測試,從第一個里程碑到第五個在同一天完成。
小專案沒有複雜度可以炫耀,但每個模組都得做一個決定。以下是五個。
一、AI 服務三層自動回退
辨識用的是視覺模型 API,但呼叫路徑設計成三層:自架 proxy → 直連 API → 本機 mock。沒設任何金鑰時直接跑 mock,開發流程永遠不卡;設定檔裡則明白寫著:任何以 EXPO_PUBLIC_ 開頭的變數都會被打包進客戶端——客戶端藏不住金鑰,正式環境一定要走自架 proxy。
這個「先讓它能跑,再讓它安全」的順序,是小專案能一天做完的原因。
二、用 tool_choice 強制結構化輸出
和我們做文件辨識時一樣,不解析模型吐出的自由文字。辨識請求用 tool_choice 強迫模型回傳符合 schema 的資料:類別是列舉、邊界框歸一化到 0–1、附信心度。收到之後還有一層防禦性驗證——數值 clamp、邊界框不能超出畫面——模型再乖也不能信任到底。
三、自己寫九十行 IoU 去重
同一個物品常被模型框兩次。解法是電腦視覺的老朋友:同類別的邊界框,交集比聯集(IoU)超過 0.5 就合併,信心度高的當主框、數量相加。九十行純函式,十三個測試。不需要引入任何 CV 函式庫——理解概念,比引入依賴便宜。
四、異常偵測的邊界思考
為了防止重複計數,加了一條規則:某類物品的數量超過上次快照的三倍就警示。但「從零變多」不能算異常——第一次拍到某類物品,本來就是零到有。這種邊界條件是純邏輯,寫成純函式最容易測,也最容易在三個月後還看得懂。
五、可插拔的方法論引擎
這是整個專案最有意思的設計。收納專家的規則不寫死在程式裡,而是寫成 JSON 的條件樹(and / or 組合)加模板字串;引擎只做兩件事:評估條件、填入模板。換一套方法論,只要換一份 JSON。
為什麼這樣設計?因為我們想像的下一步,是邀請真正的收納專家把她的方法論授權進來——專家出 know-how,工程出引擎與 App,產品掛專家的名字。你會發現,這和我們對創作者提出的合作模式是同一個結構;這個小專案,其實是那個想法的第一次技術驗證。
誠實的現況
它是一個原型:本機儲存、沒有雲端同步、AI 要自備金鑰否則跑 mock、沒有 CI。我們把它寫出來,不是當作品集,而是想說明一件事——一個團隊的品質,看的不是大專案的規模,而是小專案裡每個決定有沒有被想清楚。
想聊聊你的產品想法,歡迎來信。