前言

昨天介紹了我這個專案一部份功能，今天最後一天我就來把剩下的部分介紹完，最後我也會做這30天來的學習反思，以及我對此專案得未來展望與優化。

功能展示

假設情境3

王小姐有偏頭痛的困擾，她的家庭醫生建議她服用「Ibuprofen」（布洛芬），但她的朋友則推薦她帶「Aspirin」（阿斯匹靈）。她想知道這兩種常見的止痛藥到底有什麼主要區別。
使用流程與成果展示：

操作：您切換到側邊欄的「藥品比較」功能。

在左邊的輸入框填入「Ibuprofen」，右邊填入「Aspirin」。
按下「比較」按鈕後，畫面左右並列顯示出兩種藥品的資訊。

• 互動式比較: 王小姐可以清晰地看到，雖然兩者都能止痛，但 Aspirin 有抗凝血（預防血栓）的效果，而 Ibuprofen 的主要作用是消炎。副作用的描述也並排呈現，讓她能一目了然地比較差異。
  這個功能幫助她根據自身需求做出更合適的選擇。

藥品清單:本地快取

查詢「amoxicillin」後，回到「藥品清單」頁面。
由於剛剛已經查過，這次的結果是直接從本地資料庫讀取，所以幾乎是秒出，這在網路不穩定或需要重複查詢時，能大大提升使用體驗。

專案心得與反思

在這次「智慧藥品助理」的開發旅程中，我收穫的不僅僅是一個功能完整的應用程式，更是一次從零到一、解決真實世界問題的寶貴經驗。

1. 從「數據」到「價值」的轉化：
   專案初期，我面對的是來自 FDA 的、冰冷且專業的英文 JSON 數據。最大的挑戰與收穫，在於如何將這些原始數據，轉化為普通使用者能看懂、能信任、能使用的「有價值資訊」。透過即時翻譯、重點摘要、圖片匹配等加工處理，我深刻體會到，技術的最終目的不是展示複雜的數據，而是將其變得平易近人，真正解決使用者的痛點。

2. 「使用者體驗 (UX)」是專案的靈魂：
   我很快發現，一個只有搜尋框的工具是不夠的。透過模擬使用者情境，我意識到使用者想的可能不是 Ibuprofen，而是「頭痛藥」。這個洞察催生了分類/症狀查詢功能，這也是整個專案從「工具」邁向「助理」的關鍵一步。同樣地，從單調的文字列表到美化的卡片式佈局，再到並列的藥品比較，每一步優化都讓我明白，流暢且直觀的體驗，才是留住使用者的核心。

3. 技術挑戰與衝突：
   開發過程並非一帆風順。從 duckduckgo_search 套件更名、遭遇 403 Ratelimit 頻率限制，到 googletrans 的依賴衝突，每一個錯誤都是一次學習機會。我學會了透過加入延遲 (time.sleep) 來模仿人類行為、更換更穩定的套件 (deep-translator) 來解決依賴問題，以及將設定檔（如字典）模組化來維持程式碼的整潔。這些解決問題的經驗，遠比順利完成專案來得更加寶貴。

未來展望與優化建議

1. 智能化分類與標籤系統：
   目前藥品分類依賴手動建立的字典。未來可以引入自然語言處理 (NLP) 技術，自動分析藥品 indications（適應症）的文本內容，為藥品自動生成標籤（如 #消炎、#止痛、#抗過敏）。這樣當使用者搜尋「消炎藥」時，系統就能動態地找出所有帶有此標籤的藥品，擴充性與智慧程度將大幅提升。

2. 🇹🇼 在地化資料庫整合：
   目前的資料來源為美國 FDA，雖然權威但可能與台灣的用藥習慣或品項有出入。下一步可以嘗試爬取或串接台灣衛福部食藥署 (TFDA) 的公開資料，建立一個更貼近在地需求的資料庫，甚至可以包含健保藥價等資訊。

3. 個人化用藥紀錄：
   新增使用者帳號系統，允許使用者建立自己的「家庭藥箱」。他們可以將家中常備藥品加入清單，並設定有效期限提醒。使應用從一個「查詢工具」進化為一個「個人健康管理平台」。

4. 藥物交互作用警示：
   這是最具挑戰性也最有價值的功能。可以引入藥物交互作用的專業資料庫 API。當使用者在「我的藥箱」中新增藥品，或在比較兩種藥品時，系統能自動分析並提出警示，例如「A 藥品與 B 藥品同時服用可能導致嗜睡加劇」，為用藥安全提供關鍵的輔助。

5. 部署至雲端平台並整合 LINE Bot：
   將此 Streamlit 應用部署到雲端平台，讓任何人都能透過網址訪問。更進一步，可以將核心查詢功能包裝成 API，並整合到台灣使用者最普及的 LINE Bot 中，讓使用者能透過 LINE 聊天視窗，隨時隨地查詢藥品資訊，實現真正的「智慧助理」。