跳至主要內容

食品溯源與營養成分分析程式的困難

由AI產生的AI眼鏡營養成分分析

我之前寫過自己在做一個分析營養成分的Bot,用最簡單的方式追蹤每日、每週、每月的營養攝取狀況。做著做著,我發現一個問題:如果這個 Bot 要進一步給予建議,會踩到誰該給建議的界線。剛好最近食安新聞不斷,我想起自己多年前放棄的食品溯源專案,於是把原本分析營養成分的 Bot,延伸成一個自己動手做的食品溯源程式。這篇文章想分享的是這個延伸過程裡遇到的三個矛盾:營養分析的黑盒子問題、自己做溯源程式時撞到的資料難題,以及消費者實際採購行為與溯源理想之間的落差。

營養分析的黑盒子

目前市面上以AI分析營養成分的應用,有一塊我一直覺得模糊的區域:使用者無從得知分析依據為何。另外還有一個更根本的問題,使用者吃東西為什麼要先拍照才能吃?拍照分析一餐,本身就是打斷用餐過程,也不符合大部分人吃飯的日常邏輯。唯一真正說得通的應用場景,是把這個功能放進眼鏡裡,讓使用者所見即可分析,不需要額外動作。

即使先不談拍照這件事,營養分析Bot本身也有精準度的問題。脂肪與鈉含量是最難估算的兩項,AI會給出數字,但使用者不知道這個數字的計算依據,實際使用中也會遇到辨識失敗的案例,還需要「教會 AI 學習與記憶」歷次辨識的結果。

動手做自己的食品溯源程式

做到現在,大概能理解當初這類食品溯源計畫為什麼沒有做出大家都想用的成品。核心困難是各方資料庫格式不一致,在沒有 AI 協助的年代,清洗資料、做正規化本身就是一個工程量很大的任務。現在有AI協助,清洗與統一格式的速度快很多,但還是存有資料流失的風險。

台灣食藥署有提供開放資料下載,實際使用後我發現幾個資料本身的漏洞,而這些漏洞不是食藥署一個單位能單獨解決的:

  1. 進口商紀錄無延續管制:曾有食安風險新聞的進口商,依然可以繼續進口食品;
  2. 廠商自主登錄無強制力:部分食品不會主動登錄食藥署平台,登錄與否全靠廠商自願,沒有強制規範;
  3. 品牌名稱相近造成混淆:統一生機、統一生醫、義美生醫、義美生技等大廠的名稱相近,AI在判斷資料時,很難判斷該合併還是分開處理,還需要去工商登記查詢。

相對地,國內較大品牌像聯華、光泉、義美,通常會自建食品溯源網站,並在自家包裝上印刷條碼,消費者掃描條碼就能連結到來源與檢驗結果。這類大品牌的資料完整度高,我做溯源程式時,對於大品牌並建有溯源平台的資料則以品牌自建平台的資料為主,不會再抓下來。

使用行為的矛盾

整個使用流程是拍照或掃描、上傳程式、AI分析、產出結果。但這個流程背後有一個我不斷思考的問題:消費者實際的採購行為,真的支持這套流程嗎?

先看品牌與功效的取捨。消費者在便利商店買一盒無糖豆漿時,通常會先看品牌,還是先看蛋白質含量?還是單純圖方便好喝,或者價格才是第一考量?這決定了溯源資訊在採購當下有沒有機會被看到。

再看溯源行為本身的落差。有些超市會立牌標示馬鈴薯來自台灣哪個產區,或標明與哪位農夫契作,包裝蔬菜也常有標章或條碼可供溯源。但消費者在每一次採購裡,真的會駐足查詢嗎?就算查了,一般消費者讀得懂溯源網站上的檢驗報告嗎?傳統市場裡沒有包裝的食材,又還有哪些方法可以檢測?

最後是網路平台,特別是C2C賣場,更難掌控。還有社群平台如 Instagram、Threads、Facebook 上有不少「食品」廣告,這些食品的製造商可能來自中國,藉由集運方式將商品輸入台灣。相關單位無法管到這一塊。有些食品成分可能危害健康,但消費者無從得知,造成傷害時也無從索賠。

未來可能的應用

我試過各種方式想簡化操作流程,但目前還是無法讓這個程式變得更簡單、更直覺。不過我相信這類應用不久會出現,而且很可能出現在 AI 眼鏡上。針對這個想法,我得到以下資訊:

理論上可行,但要看是哪一種 AI 眼鏡,關鍵差異在於「有沒有開放的相機/開發者 API」。

核心邏輯可以搬過去:bot 現在的分析引擎本來就跟 Telegram 介面是分開的,Telegram 只是「拍照→傳圖片→收到分析結果」這個輸入輸出殼。只要眼鏡那端能把拍到的照片傳到某個後端,理論上就能接上現有的分析流程,不需要重寫辨識/查詢邏輯。

實際卡點在眼鏡本身:像 Ray-Ban Meta 這類消費級 AI 眼鏡目前是封閉生態,Meta AI 本身能辨識畫面內容,但沒有開放給第三方接自訂後端做這種客製化營養分析。少數有開發者 SDK 的眼鏡(例如某些 Android-based/XR 平台的眼鏡)理論上可以做到:使用者說「記錄這餐」或做個手勢觸發拍照 → 照片丟到自建後端 → 跑一樣的分析 → 語音或畫面回饋熱量/營養缺口。即時疊加顯示(像走到食物前直接在鏡片上看到熱量)技術上難度高很多,目前消費級眼鏡幾乎做不到即時準確辨識疊加。

重點是要找到一支開放相機串流/拍照 API 給第三方開發者用的眼鏡。

我讓 AI 做一張圖,模擬 AI 眼鏡看到食品並開始分析的畫面,畫面本身其實令人缺乏食欲。這也讓我重新思,使用者真正需要的,或許不是一張營養成分表,而是分析計算完使用者當日的飲食後,給出可以理解的建議。例如今天使用吃了很多肉類,系統會提示「今天還需要多補充蔬菜哦!」或是發現使用者攝取不足的蛋白質時,會主動提示「今天用餐可以再配些優酪乳、豆漿、牛奶」。這種具體、好懂的建議一定比一張難以解讀的營養成分表更有效,但這正是營養師的專業建議範疇,AI 不該越界代替營養師說這句話。

我的暫時性結論是,這件事真正卡住的不是技術,是誰有資格給建議。工具可以幫我清洗資料、比對條碼、算出熱量缺口,但「你今天該多吃點什麼」這句話,還是該留給營養師說。我會繼續做下去,但下一步要想清楚的,是這個程式該停在哪裡,把界線留給真正的專業。

食品安全的真正意義是「信任」

在製作應用時,我持續思考,消費者的行為與這個程式的意義,最終察覺「食品安全」是個表面議題,真正要探討的是整個供應鏈中,哪個管理環節鬆掉了、讓消費者失去信任,而不是急著課責。

消費者唯一有能力做的是「信任制度」,而不是擔心食品與營養成分,但不當管理、制度缺失造成危害身體健康,卻是所有人來承擔。貨架上的商品,在法令規範下,「原則上應該是安全的」,不需要消費者事後溯源,這才是主管機關應該做到,而不是把推給消費者或是生產者的責任。

留言

此網誌的熱門文章

停不下來的更新

一直更新Blog的版型,我必須承認是一件很無聊的事,不過這次除了版型的更動外,連分類和文章內文也做了變動。 先說分類吧!在Blogger叫做Label,不過,Blogger在分類上有一些bugs,只能使用英文,以前這裡的分類大多都是中文分類,結果在link上就是一堆亂七八糟的亂碼,所以我把它改成英文,同時細分一些項目,把出版的文章和一些教學的文章分開來,雖然已經很久沒寫新的,不過既然放上來就做個分類。然而就在新舊label移轉之後,發現中文的label還會存在,而且還會出現莫名奇妙的幽靈數字,Blogger知道這是個bug,不過似乎一直沒有修復的跡象。所以在分類上就出現了如右圖一般的情況,在英文標籤裡會有文章,但是在中文標籤裡是沒有文章出現的,但奇怪的是,有些中文標籤已經不見了,然而在Beauty-Beta這個部落格裡,我也做了分類上的變動,由於以前用英文開頭的Label,所以在label的變動上倒是不用擔心會有這樣的情況。 再來是文章的內容,把以前的文章重新分類,標題前面的一些全形符號或是分類刪掉,除了一些比較特殊的,我會留著,例如壹陸壹,因為在label裡為了統一,我留著原本的E61,但人家的店名是壹陸壹,所以留下文章標題前面的中文分類,另外像是Entertainment項目裡,可能有音樂,可能有電影,就會在前面留下中文分類。 前簡單的CSS和HTML改成現在的XML,這無疑是讓我們再多學些東西,能有時間鑽研當然是好事,可是轉換後,我一直沒有時間去改,當然多半也是因為懶,到現在也是拿別人做好的版型去改配色而已,所以像裡面的設定、安裝的widget和analytics的javascript都要一個一個重新裝,上個星期幾乎每天都弄到天亮才睡,只為了整理這個blog。也因為之前在blog裡放了technorati的分類,所以還要修改以前的文章,把它們加入technorati,還有裡面的語法要更改,所以這個星期甚至下個星期都會一直收到這裡的更新訊息,對於不斷收到訊息干擾的朋友們,在這裡說聲抱歉。 在版面上因為blogger系統在feed接受上的更新,所以還有四個東西沒加進去,分別是最近的文章(Recent Post)、Comments(目前是用別人寫的widget)還有GVO的feed訂閱顯示、Beauty-Beta的訂閱顯示也都還沒放上去。 在Feed訂閱上,以前bl...

用Claude Code做一個AI飲食營養分析Bot:從拍照辨識到條碼查詢的實作筆記

沒想到在十多年後,因為想做飲食營養控管,所以自己利用 AI 開始做一個簡單的食品營養分析工具,能分析我每餐的飲食是否充足或過量,並提供有依據的飲食建議。 最初的雛形是基於以往曾參與「 Food Open Data 」倡議的經驗,我希望用最簡單的方式,拍照-->AI辨識與分析-->提供建議,然後統計一段期間的營養攝取狀況。 最初的想法 當我把我的雛形想法告訴 AI 後,Claude Code 很快的就幫我設計好雛形、教我如何申請Telegram Bot,這些步驟都寫得很清楚,整個雛形做好不用半天,我還愣住了,怎麼可能這麼簡單?難怪那些應用程式公司只把飲食營養分析當作一個「附加功能」,主要目的是蒐集其他的生理監測資料,但這些公司蒐集資料的用途,我自己在處理過美國資料經紀公司所販售的資料隱私資訊後,這是值得關心的議題,但不在此篇文章裡討論。 不過,我只專注在飲食分析項目,我覺得這個功能如果可以做好,再想想其他的。最初的想法很宏大,因為家人與自己患有慢性疾病,所以特別針對某些族群設計,但事實上,如果沒有實際的使用情境,可能也無法做出符合需求的產品。 於是我把這個Bot的使用者只鎖定在我自己的飲食分析上,那就簡單多了。 工具與環境限制 我在今年已經改用 Claude Cowork 與 Claude Code 協作,雖然 Claude Code 有一般介面版,但我大多數時間都開著終端機視窗使用 Claude Code,這樣比較能專心工作。 基於使用工具的習慣,我使用 Claude Code 開始建置,當時的模型雖然已經有Opus 4.8,但Sonnet 4.6已綽綽有餘,而後來出現的Fable 5 則用在其他專案裡。 因為只做給自己用,所以選擇最簡單的 Chatbot 形式;也因為我希望可以自由的使用而不是提供過多的個人資料給其他平台,選用 Telegram Bot,而不是台灣人常用的 LINE Bot ,而且 LINE上太多廣告,根本不想開它。 在衡量經濟現實及自我管理資料的想法後,目前這個 Bot 與資料庫只放在我的電腦裡,沒有上雲端,當電腦休眠、網路斷線時,Bot就會停止工作。 雖然只是給我自己使用,但我還是要求資料庫是加密儲存的,匯出資料時也必須加密。 台灣的飲食文化很多元 我不是開發者、也不是營養師,我自己也沒使用過其他的應用程式,所以無從理解在開發飲食營...

AI 提高產出,但誰得到好處?

我收集了 2026 年 3 月至 9 月由 Anthropic 研究團隊公開發表的 5 篇文章,讓 Claude 重新翻譯並編輯,並修改為習慣的閱讀語氣,以利閱讀。 Anthropic 今年 3 月發表的報告顯示,美國整體失業率沒有上升,但 22 到 25 歲的年輕人每月順利進入 AI 高曝露職業的比例比 2022 年低約 14%。這是我讀完今年他們發布的 5 份經濟研究摘要後,最常想起的一句話:「AI 讓產出變多」與「誰能把產出變成自己的收穫」,是兩個得分開回答的問題。 AI 做得到,不代表已經在做 過去大部分研究或媒體在衡量 AI 對工作的影響時,常問「AI 理論上能做哪些任務」。問題在於,AI 做得到,不代表企業或個人真的已經拿來用。 在這次閱讀的文章中,研究團隊提出「觀察曝露度」(Observed Exposure)。這個指標結合 O*NET(美國職業資訊網路,Occupational Information Network)的任務清單、理論可行性評分與 Claude 的實際使用資料,並對「自動化」與「工作用途」給予較高權重。 排名最高的是電腦程式設計師(約 75%)與資料輸入人員(約 67%),客服代表也名列前茅;另有 30% 的勞工觀察到曝露度為零。AI 目前的實際使用與理論能力還有一段距離。 在公布的研究中,高曝露職業的從業者有幾個共同特徵:女性比例高 16 個百分點、平均薪資高 47%、學歷較高、年齡也偏長。受衝擊的是中高薪的知識工作者,和「AI 先淘汰低薪年輕勞工」的直覺相反。 衝擊有多大?研究用差異中差異法比對,發現 ChatGPT 發布前後,高曝露職業的失業率未見系統性上升。唯一較清楚的訊號在 22 到 25 歲:這個年齡進入高曝露職業的新工作起始率,約比 2022 年低 14%。研究團隊也註明,這個結果僅勉強達到統計顯著。 同一套 AI,成果為何不同 在針對使用者研究的報告中,使用 6 個月以上 Claude 的人,其對話成功率為 73.1%,新使用者為 66.7%,相差 6.4 個百分點。控制任務類型後,差距縮到約 3 個百分點;再加上模型、使用情境、國家等變數,差距維持在約 4 個百分點。 Anthropic 曾假設,資深使用者會更傾向於把工作整包交給 AI 自動完成。研究的資料指向相反的方向:資深使用者更常與 Claude 來回...