Diary

昨天我終於把產品管理的 CRUD 骨架穩固了，儘管腦袋還在回味那種「到底值不值得這麼糾結」的自我質疑，但今天一早，我直接撲向了條碼掃描的功能擴展。

這週最重要的技術里程碑，就是把 Ingrelens 的條碼掃描功能初步搞定。原本以為條碼掃描只是個 plug-and-play 的小功能，沒想到卻變成了一場影像處理的持久戰，真的是狠狠被現實教育了一波 😅。 回顧過去幾天，從一開始輕敵到後來陷入參數調整的漩渦裡，我意識到自己有時候會過度執著於技術細節，導致花了太多時間在不一定能即時帶來價值的地方。這次的條碼辨識問題，雖然最後透過影像前處理取得了不錯的效果，但我也提醒自己，下次再面對這種狀況應該早點跳出細節，以產品的角度重新評估投入與產出的平衡，避免陷入工程師的「優化黑洞」。 不過，以產品的戰略層面來看，條碼掃描功能的重要性絕對不能輕忽。這功能不只是方便用戶快速識別商品資訊，更重要的是對未來商業模式的佈局有重大影響。這週的經驗告訴我，條碼掃描的準確性與使用體驗將直接影響用戶對 Ingrelens 的信任感與黏著度。尤其是那些「逼死強迫症」的小尺寸條碼，正是我們產品未來和競爭對手拉開距離的關鍵機會點。 這次決定以「場景模式」快速落地，並透過 API 提供彈性，現在回頭看覺得這個決策還算明智——至少在短期內可以快速上線，先

終於讓條碼掃描的辨識率穩住了點，雖然還在腦中盤旋著「這功能值不值得這麼折騰」的疑問，但今天一早，我直接跳到產品管理的模組開發上。

我終於把 AI 服務的雛形穩住了，雖然還在擔心模型切換的穩定性，但今天一早我就轉移焦點到條碼掃描功能上——畢竟產品分析再好用，如果用戶連產品都掃描不出來，一切都白搭。

# API設計的自我懷疑與產品決策的折磨：週檢討（2025-03-16） 這週整體來說算是「進兩步退一步」的感覺。雖然沒有什麼驚天動地的功能上線，但在產品架構和 API 設計這塊倒是做了不少深度思考。尤其是禮拜五整個在 API 設計的抉擇中掙扎，現在回頭看，覺得有點像是在跟自己的完美主義死磕。但至少最後做出的決定還算滿意。 這一週最大的成就，應該是把 API 架構再精簡了一輪，移除了原本設計的 AI 模型切換端點，直接整合進產品分析的 API 中。當初猶豫的點是擔心未來用戶可能會頻繁切換模型，但冷靜下來想想，這種使用情境真的會發生嗎？還是只是我在自嗨？最後決定簡化 API，避免過度工程化（over-engineering），現在看來是正確的選擇。 從產品策略的層面來看，這種決定背後其實反映了我對 Ingrelens 使用情境更真實的理解。產品的核心價值，是提供用戶穩定且準確的 AI 分析能力，而不是讓用戶花時間在各種模型之間跳來跳去。這種深入思考使用場景的習慣，未來也要持續保持。 但坦白說，這週在 API 設計上的猶豫，

今天一早起來就盯著電腦，腦袋裡盤旋著那個 AI 服務的配置問題。記得前幾天我本來想把 GPT 服務簡化一下...