Skip to content

公開可操作的實作案例

從查資料到能操作:一個藥品成分比對工具的 AI 協作實作

資料查得到,為什麼還需要做一個工具?因為查到資料之後,還有辨識、比對與結果解讀要處理。

這個工具做什麼
用衛福部食藥署(TFDA)公開資料查出藥品成分,再與使用者自行建立的清單做精確比對。純前端網頁,清單只存在使用者自己的瀏覽器。

我在這個案子負責什麼
定義需求、拆解 AI 任務、檢查 AI 產出的結果、修正、部署與後續維護。工具執行時是依公開資料與既定規則比對,不是用 AI 判讀

台灣藥品成分與過敏清單比對工具總覽:比對 TFDA 公開資料庫、清單只存在瀏覽器、支援中英文品名與許可證字號


工具第一次開啟可先按「觀看示範」,用虛構藥品了解三種比對結果,不需要輸入任何個人資料。


原本要人工做什麼

這不是「資料查不到」的問題。TFDA 的許可證資料是公開的,任何人都下載得到。難的是下載之後的那幾件事。

從使用者痛點出發:過敏藥清單和醫師溝通、藥品名稱又長又難記、藥品過敏會引發問題

① 查資料

藥盒上的字號、中文品名、英文品名各是一套;資料集本身是 6 萬多筆的 CSV,不是拿來一筆一筆翻的。

② 辨識藥品

複方藥一顆可能有六、七種成分;同一個成分在不同資料列可能寫成不同劑量、不同拼法、不同鹽類字尾。

③ 逐項比對

手上那張清單要跟每一種成分核對。這是典型的「錯了會出事、所以一直不敢自動化」的流程。


我負責什麼

這個工具以 AI 協作開發。需要講準確的是:開發過程用 AI,工具執行時不用 AI。使用者按下查詢時,跑的是固定的資料索引與比對規則,不是把資料丟給模型判讀。這決定了結果可不可以重現、出錯時查不查得出原因。

  • 定義需求與邊界:先決定不做什麼——不做交叉過敏推論、不推薦替代藥、不判斷能不能服用。邊界決定了後面每一個技術選擇。
  • 拆解 AI 任務:把「做一個比對工具」拆成資料清理、索引建立、正規化規則、介面、離線測試等可以逐段驗收的小題目。
  • 檢查結果:AI 產出的程式要自己讀過、實際跑過。下面第四段的四個問題,都是在這一步被抓出來的。
  • 修正與寫成檢查:修好之後把判斷寫成自動化檢查,讓同樣的錯不會在下一版悄悄回來。
  • 部署與維護:自訂網域上線、資料更新流程、每次更新的差異覆核。

四個關鍵問題與解法

每一項都是「問題 → 如何發現 → 怎麼改 → 如何驗證」。這四段才是可以遷移到別的產業的部分。

關鍵決策 01

許可證只取數字,可能對到另一款藥

問題
不同類型的許可證會用到相同數字。「內衛成製字第000012號」與「衛署藥製字第000012號」是兩種不同的藥,只取數字就會對錯。
如何發現
建索引時對主鍵做重複檢查,發現數字鍵大量互相覆蓋。實際統計:62,696 張許可證裡有 35,388 張落在重複數字群組,最多 11 張共用同一組數字。
怎麼改
改用完整許可證字號當唯一主鍵,不建立純數字鍵。使用者只輸入數字時,一律列出全部候選讓他對照藥盒自行選擇,絕不自動選定任何一筆。
如何驗證
建置腳本遇到主鍵重複直接中止並列出清單,禁止靜默覆蓋;索引檢查腳本每次都會印出碰撞群組統計。
關鍵決策 02

要使用者自己分類,等於把出錯的責任丟給他

問題
清單原本要使用者選「這是成分還是藥名」。選錯的後果不是顯示難看,是整筆不會被比對到。
如何發現
自己實際使用時就會選錯。一個使用者會選錯的欄位,不能靠說明文字補救。
怎麼改
拿掉分類選單。每一筆清單項目都同時比對藥品的全部成分與中文品名,使用者只要輸入,不用先分類。
如何驗證
寫成自動化檢查:介面與程式碼裡都不得再出現分類欄位,違反就擋下。
關鍵決策 03

資料可以自動更新,但不能自動上線

問題
TFDA 資料會更新,但自動抓取的結果可能是空的、缺欄位的,甚至抓到一頁 HTML 錯誤頁。直接覆蓋就是把好資料換成壞資料。
如何發現
設計更新流程時先問:這一步失敗會怎樣?答案是「使用者查到的成分變少,而且沒有人會發現」。
怎麼改
更新流程改成:下載 → 重建索引 → 結構檢查 → 新舊差異比對與安全煞車 → 跑完整測試 → 只開 PR,不自動合併。許可證數量下降超過門檻(預設 5%)直接讓流程失敗,中文品名大量消失也會擋下。
如何驗證
每月排程跑一次,變更摘要(新增/移除/成分變動筆數與樣本)附在 PR 上,由人看過再決定合併。
關鍵決策 04

一個看截圖看不出來的錯:0.9% 開頭的成分比對不到

問題
正規化規則用了單字邊界寫法,導致「0.9% sodium chloride」不會被還原成「sodium chloride」。畫面完全正常,但該命中的沒命中——這是最危險的一種錯。
如何發現
拿真實資料裡帶百分比濃度的成分逐筆試,才發現兩種寫法正規化後不相等。
怎麼改
修掉規則,並把「清單」與「藥品成分」兩側統一套用同一份正規化程式,不讓兩邊有機會各自演化。
如何驗證
寫成迴歸測試:0.9%、5%、20% 等寫法正規化後必須與去掉濃度的寫法完全相等,這條規則往後不能被改壞。

這些問題不只出現在藥品資料。只要工作裡有反覆查資料、核對清單、整理不同來源,或「錯一次就會出事」的流程,都會遇到類似的資料、介面與更新問題。

也講一下付了什麼代價

我決定不把查詢內容寫進網址——不用 query string、不寫入瀏覽紀錄。代價是「把查詢結果分享給家人」這個功能做不成了。取捨是真的取捨,不是兩全其美。這類判斷在企業專案裡更常見:便利性與資料邊界,通常只能選一個。


實際怎麼操作

① 建立清單 → ② 查詢藥品 → ③ 查看比對。三步驟都在同一頁完成。

步驟一 建立我的過敏清單:直接輸入成分名稱或完整中文品名,無須分類,清單只存在這個瀏覽器

步驟二 查詢藥品與步驟三 查看比對:輸入中英文品名、成分名稱或完整許可證字號,核對後選擇候選項目

不用輸入個人資料就能了解三種比對結果:命中清單、未命中清單、無法比對的獨立示範模式

結果只有三種,而且措辭是刻意寫死的:

  • 比對到你清單中的成分 — 提醒使用者主動告知醫師或藥師。
  • 未比對到你目前清單中的成分 — 只代表未命中你輸入的清單,不代表不會過敏。這裡絕對不會出現「安全」或「可以使用」。
  • 找不到成分資料,目前無法比對 — 誠實說沒有資料,不用猜的補上去。

第三種狀態最容易被省略,但它其實最重要:一個會在沒把握的時候說「我不知道」的工具,比一個永遠給答案的工具可信。

就醫小卡在瀏覽器本機產生,可下載或列印;資料來源與比對方式在頁面上完整揭露

就醫小卡是用瀏覽器內建的繪圖能力在本機產生 PNG,可以下載或列印,帶去給醫療人員看。它只包含使用者自行記錄的名稱、備註與產生日期,不包含任何查詢判讀結果。長名稱會換行不截斷,內容多會自動分頁;超過頁數上限時明確提示改用 JSON 匯出,而不是產生一張缺內容的卡片。


目前能力、限制與維護方式

資料規模

資料來源 衛福部食藥署(TFDA)開放資料:許可證詳細處方成分、許可證主表
索引內容 62,696 張許可證、7,034 項成分、122,645 筆成分對應
查詢方式 中文品名(含部分品名)、英文品名、英文成分、完整許可證字號
載入 索引檔約 8.1 MB,壓縮後約 2.0 MB,有進度百分比、失敗可重試
語言 繁體中文/English,固定翻譯隨程式提供,不呼叫翻譯 API

限制(刻意不做的事)

  • 不做交叉過敏推論,也不因某一藥物命中就推論同類其他藥物。
  • 不推薦替代藥、不判斷能不能服用、不提供用藥建議。
  • 只做完全相等比對。部分品名可以用來查藥,但不算清單精確命中。
  • 並非 TFDA 官方服務;藥品資料以官方公告為準。

隱私邊界

  • 清單只寫入使用者自己瀏覽器的本機儲存空間,不會送往任何伺服器、分析服務或錯誤追蹤服務。
  • 沒有任何第三方 script、字型或圖片;頁面以內容安全政策限制成只允許同源資源。沒有 Google Analytics、沒有 Meta Pixel、沒有廣告。
  • 藥名與許可證字號不會寫進網址,也不會寫入瀏覽紀錄。
  • 所有畫面文字都以純文字方式建立,資料裡含角括號的成分名稱會原樣顯示,不會被當成程式碼執行。
  • 以上不是口頭承諾:用瀏覽器自動化實際錄下所有網路請求驗證過——無第三方請求、請求網址不含清單或查詢內容、主控台不外洩清單內容、網址列無查詢字串。

怎麼維護

每月排程自動跑一次資料更新:下載 TFDA 開放資料 → 重建索引 → 結構檢查 → 新舊差異比對與安全煞車 → 跑完整測試 → 有變動才開 PR。不自動合併、不直接推上線,一律由人看過變更摘要再決定。整個流程裡只有第一步會連外網,其餘全部離線。

目前有 142 項自動化檢查涵蓋正規化規則、比對邏輯、索引完整性、下載工具的網址白名單與解壓上限、介面文案紅線,以及手機瀏覽器的實際操作與網路請求。

說明:這些是軟體檢查,確認的是程式行為與資料處理是否符合設計,不是醫療效能驗證,也不代表任何臨床或專業審查


常見問題

Q1. 這個工具是用 AI 判斷過敏嗎?
不是。我用 AI 協作開發這個工具,但工具執行時跑的是固定的資料索引與比對規則,不會把使用者的資料交給任何模型判讀。這個差別很重要:規則式的結果可以重現、可以追查,出錯時知道錯在哪一行;模型判讀做不到這件事。也因為如此,工具不判斷過敏、不推論其他藥物、不提供用藥建議。
Q2. 未比對到清單,是不是代表這個藥可以用?
不是,而且工具刻意不這樣寫。「未比對到」只代表這個藥品的成分與中文品名,沒有出現在你自己輸入的那份清單裡。你的清單可能不完整,也可能有你還不知道的過敏原。工具的措辭從頭到尾都是「未比對到你目前清單中的成分」,不會出現「安全」或「可以使用」——這條規則甚至寫成了自動化檢查,改壞了會直接擋下來。
Q3. 我輸入的過敏清單會被上傳嗎?
不會。清單只寫入你自己瀏覽器的本機儲存空間,不會送往任何伺服器或分析服務,藥名也不會寫進網址。這一點有用瀏覽器自動化實際錄下所有網路請求驗證過。要注意的是:換裝置、換瀏覽器不會同步,清除網站資料可能會清掉清單,需要備份請自行匯出檔案並妥善保管。
Q4. 資料多久更新一次?會不會更新完就壞掉?
每月排程跑一次,但更新結果不會自動上線。流程會先做結構檢查與新舊差異比對,許可證數量下降超過門檻、或中文品名大量消失,都會讓流程直接失敗而不是覆蓋掉好資料。通過檢查也只是開一個待審的變更,由人看過摘要再決定要不要合併。這是我在所有資料工具上的固定做法:可以自動更新,不能自動上線。
Q5. 我的產業跟藥品完全無關,這個案例跟我有什麼關係?
藥品只是這次的題目。真正可以遷移的是處理方式:資料髒的時候怎麼定主鍵、使用者會選錯的時候怎麼改介面、資料會變動的時候怎麼設安全煞車、以及最重要的——先想清楚錯了會怎樣,再決定要不要自動化。這四件事在料號、規格表、法規項目、供應商清單上都一樣成立。

你的工作裡,有沒有一樣的流程?

同樣的做法可以用在:

  • 每次都要人工核對的清單比對——食材過敏原、法規項目、供應商料號、成分表對照。
  • 定期從公開資料重建的內部查詢表——政府開放資料、公告清單、價格或規格更新。
  • 分散在多個檔案、需要整理給同事使用的資訊——Excel 散在各處,每個人版本都不一樣。
  • 錯一次就會出事、所以一直不敢自動化的流程——這一類最需要的不是更快,是可以檢查、可以擋錯、可以由人確認。

這個工具展示了我如何把公開資料、比對規則與操作流程,整合成可以實際使用的網頁工具。

如果你的工作也需要反覆查資料、核對清單,或把分散資訊整理給同事使用,歡迎帶一個具體流程來聊。我們可以先確認資料來源、使用情境與交付範圍,再評估適合的工具形式。

第一步:單一流程工具化評估

交付目前流程的盤點、可行範圍、資料需求與原型方案。確認之後再估開發與維護。聊之前先想這四件事就夠了(描述流程即可,先不要提供任何敏感資料):

  1. 現在要查、整理或比對什麼?
  2. 資料在哪裡?
  3. 多久做一次、誰在做?
  4. 希望最後得到什麼結果?

關於本工具
本工具僅供個人紀錄與溝通參考,不提供診斷、治療、預測或用藥判斷,不能取代醫師或藥師的判斷。請先向醫師或藥師確認真正的藥物過敏清單,再記錄於工具中。藥品資料來自衛福部食藥署開放資料,著作權與使用條款依原資料集規定,以官方公告為準;本工具並非 TFDA 官方服務。


影片:

探索更多來自 米思行銷 的內容

立即訂閱即可持續閱讀,還能取得所有封存文章。

繼續閱讀