歲月的容顏 YingChu Chen

我之前寫過自己在做一個 分析營養成分的Bot ，用最簡單的方式追蹤每日、每週、每月的營養攝取狀況。做著做著，我發現一個問題：如果這個 Bot 要進一步給予建議，會踩到 誰該給建議的界線 。剛好最近食安新聞不斷，我想起自己多年前放棄的食品溯源專案，於是把原本分析營養成分的 Bot，延伸成一個自己動手做的食品溯源程式。這篇文章想分享的是這個延伸過程裡遇到的三個矛盾：營養分析的黑盒子問題、自己做溯源程式時撞到的資料難題，以及消費者實際採購行為與溯源理想之間的落差。 營養分析的黑盒子 目前市面上以AI分析營養成分的應用，有一塊我一直覺得模糊的區域：使用者無從得知分析依據為何。另外還有一個更根本的問題，使用者吃東西為什麼要先拍照才能吃？拍照分析一餐，本身就是打斷用餐過程，也不符合大部分人吃飯的日常邏輯。唯一真正說得通的應用場景，是把這個功能放進眼鏡裡，讓使用者所見即可分析，不需要額外動作。 即使先不談拍照這件事，營養分析Bot本身也有精準度的問題。脂肪與鈉含量是最難估算的兩項，AI會給出數字，但使用者不知道這個數字的計算依據，實際使用中也會遇到辨識失敗的案例，還需要「教會 AI 學習與記憶」歷次辨識的結果。 動手做自己的食品溯源程式 做到現在，大概能理解當初這類食品溯源計畫為什麼沒有做出大家都想用的成品。核心困難是各方資料庫格式不一致，在沒有 AI 協助的年代,清洗資料、做正規化本身就是一個工程量很大的任務。現在有AI協助，清洗與統一格式的速度快很多，但還是存有資料流失的風險。 台灣食藥署有提供開放資料下載，實際使用後我發現幾個資料本身的漏洞,而這些漏洞不是食藥署一個單位能單獨解決的： 進口商紀錄無延續管制：曾有食安風險新聞的進口商，依然可以繼續進口食品； 廠商自主登錄無強制力：部分食品不會主動登錄食藥署平台，登錄與否全靠廠商自願，沒有強制規範； 品牌名稱相近造成混淆：統一生機、統一生醫、義美生醫、義美生技等大廠的名稱相近，AI在判斷資料時，很難判斷該合併還是分開處理，還需要去工商登記查詢。 相對地，國內較大品牌像聯華、光泉、義美，通常會自建食品溯源網站，並在自家包裝上印刷條碼，消費者掃描條碼就能連結到來源與檢驗結果。這類大品牌的資料完整度高，我做溯源程式時，對於大品牌並建有溯源平台的資料則以品牌自建平台的資料為主，不會再抓下來。 使用行為的矛盾 整個使用流程是拍照或掃描、上...

之前分享利用 Claude Code 做 飲食營養分析 Bot 的經驗 。我自己有個習慣，就是在做新的專案時，會先評估法遵風險。當我在做飲食營養分析 Bot 時，我才知道原來台灣除《醫師法》外還有《 營養師法 》，而《營養師法》第 12 條列舉營養師的法定業務，包含營養評估、飲食設計、個案諮詢、膳食管理等。 這部《營養師法》在幫大家的健康把關，因為不能隨便一支影片、一段報導，就能提供營養建議。在法規中，需要接受完整的專業教育，並持續進修，每 6 年就要提出繼續教育的證明文件，才能更新執業證照；沒有「營養師」的證照不能自稱「營養師」，法規中列舉了營養師的業務範圍，並規定須親自執行業務，不能由他人代理，如果藉由通訊方式執行業務，還要經過執業登記的主管機關核准；執行業務時還要做紀錄，這些紀錄可能還會成為法律或醫療紀錄文件。 成為「營養師」需要符合嚴格的要求與限制，並不是隨便用AI分析、讓AI提供建議就能取代的。台灣每年會舉辦 2 次營養師的考試，參考自中華民國營養師公會在 2025年的統計資料 ，台灣每年營養科系的畢業生約 1500 人，到 2025年，累計已有 11,860 人通過考試取得執照，及格率約 25%，看起來是一個具有挑戰性的考試。 Bot 的個人化建議，算不算「執行業務」？ 在我設計的 Bot 裡，不是只有拍照上傳讓 AI 去分析、評估，事實上還有其他情境的飲食需求，再提供使用者建議，例如由 Bot 提醒當天攝取的蛋白質不足，或我在前篇文章中提到的鈉的攝取量過高，Bot可能提醒要減少鈉的攝取或是多補充哪些蛋白質來源，這些分析與建議是否算「執行業務」？在該法第 29 條中也寫明，如果沒有取得營養師的資格而執行相關業務，本人及其雇主各處新臺幣 5 萬元以上，25 萬元以下罰鍰。 法律規範的對象是「人」，目前法律還沒有明確定義 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工具，讓台北市政更「前進」。台北市資訊局也已快速推出 CiviClaw，目標是 2027 年讓每位公務員都能無門檻使用 AI。 這樣的政策方向讓我感到憂心。長期觀測各國個資保護規範的我清楚知道：台灣的個人資料保護主管機關至今仍是「籌備處」，尚未正式運作；《個人資料保護法》的修法呼聲雖久，AI相關條款卻付之闕如；《人工智慧基本法》已於今年1月施行，但高風險AI認定標準的子法至今仍是空白。 有網路、有 IoT 不等於智慧城市，有 AI 當然也不等於智慧城市，應該重視制度能否承接工具帶來的責任。 歐盟已明確禁止業者使用 AI 推測員工或學生的心理狀態；美國聯邦政府要求採購 LLM 時廠商必須提交模型卡與資料卡；韓國 AI 基本法的子法早已配套生效。這些都是台灣政府在推動配給公務員 AI 之前，必須正視的制度差距。 以下我與大家分享長期觀測的內容，由AI協助整理資料： 歐盟：從禁令到揭露義務的多層規制體系 歐盟的AI治理框架是由多部法律疊加起來的立體架構，最底層是2018年施行的 GDPR，處理的是個人資料如何被蒐集、儲存、使用的基礎規則，再來疊是2024年生效的《人工智慧法》（EU AI Act，下稱 AI 法），建立不同風險等級分類管理AI系統，從禁止使用到高強度監管、再到一般透明度義務，形成不同層次。最新的一層則是仍在立法程序中、但主要架構已確立的 Digital Omnibus ，試圖修補 AI 法與 GDPR 之間的規範衝突。 AI 法第50條是最直接影響生成式AI服務的條款，自2026年8月2日起全面適用。根據這條規定，凡是讓使用者與AI系統互動的業者，必須主動告知對方「正在與 AI 互動」，而不能讓人誤以為面對的是真人。AI生成的文字、影像、音訊等內容，還必須以機器可讀的格式加上標記，使平台與監管機關得以溯源辨識。與此同時，AI法第14條要求高風險AI系統必須設計成「可由自然人有效監控」的形式，確保機器的決策不會在缺乏人工審核的情況下直接作用於當事人。 AI法所稱的「高風險 AI 」，涵蓋的場景比一般想像的廣。依該法附件三列舉，生物辨識系統、關鍵基礎設施管理、教育與職業篩選、就業與人員管理、信貸與社會福利申請審核、執法、移民邊境管制，以及司法審判輔助，都在高風險範疇之內。這些場景的業者必須進...

因為種種原因，今年6月1日開始，我從原單位全職轉為兼任員工，放下長期擔任的全職工作。就在做出這個決定後不久，NVIDIA GTC 大會的通知跟著到來，我候補到黃仁勳執行長 Keynote 演講的入場名額。 計程車上的台灣故事 六月的第一天早上雖然是個不太熱的陰天，我在咖啡店外攔到計程車，表示要前往台北流行音樂中心，司機大哥很敏感的說：「要去聽黃執行長演講啊？那裡排好多人。可以去買紀念品哦！」基於十多年的工作經驗，辦會、與會，我只留對我有意義會議的Badge，其他都是身外物，然而這位司機大哥的熱情稍微感染了我。 熱情的司機大哥一路上不停講述家裡親人在相關供應鏈工作的忙碌，每天都當空中飛人，落地沒多久就又要到另一個國家的工廠監督。台灣的電子製造業供應鏈養活許多家庭，這是很棒的一件事，這些家庭又帶動其他消費需求，帶動創造經濟效益。 人潮與恐慌 當我下車看到會場的人山人海時，倒抽一口氣。 因為疫情前的密集出差經驗，我得了機場恐懼症，只要看到人群、機場相關場景或班機表，全身就開始冒冷汗。平常去送機接機，或路過北門站，都要努力克制自己的恐慌。人多的場合也會觸發類似反應。 好在現場的流程管控得當，幾千人入場，一切準時開始。排隊時偶爾有人因為天氣悶熱不耐等候而抱怨，但多數人都能控制自己，沒有不愉快的事發生。每位與會者除通行證外，還收到一個漫畫版黃執行長擁抱龍蝦的小吊飾（代表NVIDIA 的 NemoClaw），是當天與會的小紀念品。 帳篷裡的 AI 人才問題 在會場外的帳篷裡，還有幾場專家訪談直播，與會者一邊排隊等候，一邊可以聽訪談。其中一場的主持人問：「我們還需要什麼樣的AI人才？或我們還需要再訓練AI人才嗎？」 這個問題讓我想起多年前「數位經濟」這四個字很熱門時，同樣的問題，只是把「數位經濟」換成「AI」，所以我只是靜靜的繼續排隊。 就像種植蔬果，不管專家怎麼呼籲，市場往往還是一窩蜂種高麗菜，搶著賺高麗菜的利潤，結果菜價崩盤。人才培育也有類似的慣性，大家一窩蜂往電子或相關領域擠，真正重要的人文領域反而乏人問津，最後又要政府砸幾千億去呼籲、鼓勵產出「內容」。 與 Windows 重逢，心情複雜 領到通行證，進入會場後，一般與會者只能遠距離觀看，所以如果沒有要再去看 Computex或是參與NVIDIA GTC其他活動的話，看轉播或是之後再看錄影就可以，而且會更清楚。 一如以往，黃...

台灣有不少企業直接在歐盟市場做生意，或是與歐盟企業有供應鏈往來。只要產品或服務觸及歐盟，AI Act 的規範就可能適用，這件事與台灣企業的距離很近，而今年5月是AI Act進度發展密集的一個月，值得整理一下發生什麼事。 AI Omnibus 修正案：從提案到5月協議 AI Omnibus 修正案 (一攬子修正案，以下簡稱Omnibus )是指把多項修正打包成一個法案同步處理的立法方式。這次的 AI Omnibus，是《AI Act》2024年正式生效以來的首次實質修正。 它的起點在2025年11月。當時歐盟執委會(European Commission)提出修正提案，認為《AI Act》中的高風險 AI 的法遵負擔過重，有必要調整期限並減輕中小企業壓力。歐盟理事會(Council of the European Union)與歐洲議會在2026年3月分別通過各自的談判立場，三方協商正式展開。歐盟理事會與歐洲議會在5月7日凌晨達成暫定協議，打包以下2項修正： 時程延後： 就業審查、執法、信用評分等領域的AI系統( Annex III )，遵法的截止日從2026年8月延到2027年12月；嵌入醫療器材、機械等產品的AI( Annex I )，則延到2028年8 月。 新增禁令： AI生成非自願性親密影像(俗稱AI裸化應用)，以及生成兒童性剝削內容的AI系統，2項均在2026年12月生效。 這份協議目前仍是暫定協議，需要歐洲議會全體投票與理事會正式採納，預計2026年6至7月完成。 行程緊湊的歐盟AI Office Omnibus 協議簽完，歐盟AI Office在5月做2件事： 透明度義務指引草案(5月8日)： 歐盟執委會就《AI Act》第 50 條的 透明度義務公開徵求意見 至6月3日。這份指引將規範「互動式 AI 系統必須主動告知使用者正在與 AI 互動，生成式 AI 的內容也必須植入機器可讀的浮水印」，這項義務沒有延後，依然在2026年8月2日生效，距現在只剩10週。 高風險AI分類指引草案(5月19日）： 148 頁的草案出爐，涵括生物辨識、教育、就業、基本服務、執法、移民、司法等7大領域，逐一說明什麼樣的AI系統會被認定為高風險。「 高風險AI分類指引草案 」公開徵詢意見至6月23日。這份指引原定2月發布，實際延遲整整3個月才出來。但歐盟 AI Of...