為什麼找一位腎臟科醫師來講 AI？

我不是 AI 工程師，今天也不打算教你怎麼寫提示詞。
我每天的工作，是把艱澀的醫學資訊，轉成病人聽得懂、而且不會誤解的話。
AI 來了之後，這件事沒有變簡單，只是變快了。

今天不是工具教學。提示詞、外掛、模型比較，網路上都查得到，也不該找我。

3.5 年，432 篇 AI/LLM 分享，從未中斷

2022-07：ChatGPT 公開前 4 個月，我寫「AI 是人類的未來，至少是生命科學的未來」（AlphaFold 蛋白質宇宙）
2022-11-30 ChatGPT 公開，第 2 週就 hands-on；第 1 個月 6 篇實驗
2025 質變年：占比從 5-7% 跳到 20% — 從話題之一變成主軸
2025-04：用 AI 導讀期刊（pipeline #1 prototype）
2025-12：每週在 FB AI 群組分享 production-quality NEJM 導讀
今天：給你看背後的 pipeline 怎麼跑

我不是來教你「AI 是什麼」。我是分享：3.5 年裡撞出來的、跑得起來、不會破產、不會被 paywall 擋死的 pipeline，是怎麼長出來的。

你的專業，會不會被 AI 抹掉？

一個路人對 AI 說：「幫我生成一份藥物衛教圖文。」
如果他拿到的成品，跟你——一位藥學專業者——拿到的幾乎一模一樣……
那就代表：你的專業價值，在這件事上被抹去了。

真正的問題不是「AI 會不會做衛教」，而是「有了 AI，你和路人的差異還剩什麼？」

差異，來自兩件 AI 給不了的事

一、沒有 AI 的時候，你本來就會做衛教——指的是「內容」，不是生成的技術。
二、你看得出 AI 產出哪裡不對——但這道門檻正在變低：路人只要付費用最強的模型，錯誤率也能很低。

所以關鍵不在「會不會用 AI」，在你是否真有藥學專業、是否真正在做衛教。這條會貫穿整場——稍後「怎麼知道 AI 的邊界」會再回來。

為什麼衛教比「寫程式」更難被 AI 取代

看 coder 界：LLM 讓「會寫程式」門檻大降、人人能 vibe coding——被衝擊的正是「產出 code」這一層。
衛教表面上也一樣：LLM 讓「產出衛教圖文」門檻大降。
但關鍵差異：衛教的產值本來就不在圖文，而在人際互動——面對面解釋、回應病人的疑慮與情緒。圖文只是工具，不是產值來源。

寫程式的產值就是 code，所以衝擊大；衛教的產值是人際，AI 取代不了——除非哪天進化成人型機器人。被 AI 降低的只是「工具產出」，不是「專業本身」。

先正名：你現在用的 AI，在哪一格？

過去我們用的 AI，從前沿角度看叫「對話式 LLM」；正在興起的是「代理式（agentic）LLM」。看兩條軸就清楚——

	月訂閱（包月・有用量上限）	API（按 token・工程師）
對話式（視窗裡聊）	① ChatGPT／Gemini 2022・你現在在這	② API 自搭問答 advanced，一直有
代理式（進你電腦做事）	④ Claude Code 月費版 2026・今年打通	③ vibe coding 2025・工程師

① 左上是你的起點；走到 ④ 左下的門，今年才開——代理式不再綁工程師、不再要 API 帳單，月費就能用。今天，帶你走過去。

所以，今天聚焦哪一半？

剛剛那張 2×2：AI 的「速度」那一半——讓寫出一篇衛教幾乎不花成本——已經是現成的。
但「該不該這樣寫」「寫得對不對」，AI 不會替你負責。

速度交給 AI，正確留給專業——今天談的，是後面這一半。

如果是現在的我，第一步會做什麼？

不是叫 AI 生成衛教

我的第一步，是產出一份「衛教產圖的 prompt」。
但要寫好這個 prompt，得先回頭研究一件大家當理所當然的事——「什麼才是好衛教？」
衛教是一門學問（健康識能、plain language、CCI 指標），不是「會看病就會教病人」。
我因此把衛教專業資源抓進自己的知識庫：CDC Simply Put、CDC 清晰溝通指標(CCI)、AHRQ 健康識能工具包——研究完，才寫得出那份 prompt。

第一步不是「叫 AI 生成」，是「研究這件事本身、把專業沉澱成 prompt」。跳過研究直接生成，你根本沒能力判斷產出對不對。

AI 很會寫，但它不知道該不該寫

給它一個題目，30 秒就生出一篇圖文並茂的衛教貼文。
排版漂亮、語氣親切、舉例生動，看起來毫無破綻。

問題就在「看起來」。流暢，是 AI 的天賦；正確，不是。

打開 AI 之前，先審來源：四個問題

證據層級？

個案、觀察性研究、隨機試驗、系統性回顧

適用族群？

這個結論，是對「誰」做出來的

是否過時？

醫學會更新，舊結論可能已被推翻

是否被污染？

出錢的人，想要的是哪一種結論

四個問題都過得了，才值得餵給 AI。

查證 AI 產出：當心「超譯」

AI 很少憑空捏造，最常見的錯是把「有一點點」說成「很厲害」——這叫超譯。產出後逐項查核：

這是「相關」，還是「因果」？
這是「相對差」，還是「絕對差」？真實人數是多少？
這是「替代指標」，還是「真正的臨床結局」？
這是「群體平均」，還是在暗示「個體的保證」？
有沒有只報好處，避談傷害與代價？

AI 產出之後，逐項打勾。打不過的那一句，就是要修改的地方。

把方法用回你的專業

你是 AI 的審稿者，不只是使用者

藥學、中藥資源、藥用化妝品、營養，你們未來都會產出衛教素材。
接下來三個場景，直接套用前面的方法。

場景 A：保健品衛教

看到一個保健品宣稱「研究證實有效」，先別急著寫，先審：

是哪一種研究？（個案？觀察？隨機試驗？）
對「誰」做的？跟你的衛教對象像不像？
看的是替代指標，還是真實結局？
研究是誰出的錢？

四題過不了，就不要讓 AI 把它寫成一篇漂亮的貼文。

場景 B：藥物風險溝通

仿單上的不良反應與交互作用，如何轉成病人聽得懂、又不會嚇到亂停藥的話？
AI 可以幫你起草「白話版」，但劑量、禁忌、風險高低，必須由藥師逐句校正。

盡量用「絕對風險」說明副作用發生率，而不是只說「可能會」「有風險」。

場景 C：營養衛教

「吃 X 可以預防 Y」這類句子，大多是把「相關」講成了「因果」。
AI 起草時最容易在這裡超譯，因為這種說法在網路上到處都是。

把維生素 D、腸道菌那一題的邏輯，原封不動套上去檢查。

在 AI 時代，醫藥專業的位置

被取代的想像

AI 會寫，就不需要藥師、營養師了

真實的位置

AI 負責起草，你負責校正，並為內容負責

你不是被 AI 取代的人，你是 AI 的編輯與審稿者。這個角色，AI 給不了它自己。

一個可以重複使用的流程

先定義：受眾是誰、要他做什麼
選來源：通過「四個問題」的可靠資料
讓 AI 改寫成好懂的素材
專業校正：逐項打過「超譯查核表」
依場景，調整語氣與版型

提示詞只影響第 3 步。真正決定品質的，是第 2 步和第 4 步。

使用 agentic LLM 的心法

不要報著某種期待去使用

「為了用而用」的人，很快會失望。
正確順序：先 audit 自己日常數位化內容 + 過程 → 拆解 → 找一個 step 可以請 agentic AI 代勞。
One at a time。先把第 1 個 step 變 agentic + 看到效果，再加第 2 個。

不要去發明沒做過的事。專注在自己很熟、做很久的事。

反過來問：不是「AI 能做什麼」

多數人問

「AI 能做什麼新事情？」
「我該怎麼用 ChatGPT？」
「最酷的 AI 應用是什麼？」

該問的

「我每天做什麼可以拆？」
「哪一步可以請 agentic 代勞？」
「我熟悉做很久的事，哪個 step 適合自動化？」

從「我已經做很久的事」開始，agentic AI 是省力工具，不是新興趣。

我每天怎麼用 AI

5 個 case 全來自「我做很久的事」

聽錄音 + 手寫筆記 → case 1 自動轉錄
寫衛教 + 校 reference → case 2 自動校正
每週讀期刊新刊 → case 3 自動導讀
反思自己 FB 累積 → case 4 自動 mapping
思考「該怎麼寫好衛教」→ case 5 寫成 SKILL.md

沒有一個是新需求。全是「我本來在做」的事，拆出某個 step 變 agentic。

agentic LLM 會很吃設備嗎？

先分清兩件事：LLM 在哪跑 × 記憶／資料存哪

模式	運算在哪	資料存哪	吃你硬體？
訂閱問答（ChatGPT／Gemini）	雲端	它家伺服器	否
我的 agentic	雲端	自己硬碟	否
租雲空間	雲端	你租的雲	否
本機 LLM（Ollama）	你的機器	自己硬碟	是

只有「本機跑 LLM」才吃硬體（要 GPU／記憶體）。我每天用的 agentic = 雲端引擎 + 本機只存文字（markdown／DB）→ 一台普通筆電就夠。

我的 KB pipeline：5 層架構

Layer 1 Source ingest — inbox → corpus bundle + PG metadata
Layer 2 Raw extraction — MinerU / MacWhisper / scrapers
Layer 3 Proofread — Opus 校稿 + tag-anchored + zh-TW
Layer 4 Synthesis — article / SKILL.md / note
Layer 5 Runtime invoke — Claude Code skill / wiki query

每一份病人衛教、每一篇期刊導讀、每一條 reference 校驗，背後都是同一條 pipeline。

Case 1：演講錄音 → transcript（含本場演講）

錄音檔 drop 進 ~/Downloads/ → launchd WatchPath 偵測 → MacWhisper 轉錄 → archive → git mirror
整個流程拆解 15 步：1 步是 ML (Whisper)，0 步用 LLM，其餘是 30-50 年前 Unix + macOS 工具

反 intuition

「agentic 一定要 LLM」

真相

本機跑、不送雲端、零訂閱費

本場演講錄音結束後，也走同一條 pipeline。

Case 2：vit D 衛教 + 來源校正

病人問：「我每天吃 vit D 是不是會預防心血管疾病？」

Claude Code 起草衛教文
自動 grep corpus 找 VITAL trial
curl Crossref 驗 DOI 10.1056/NEJMoa1809944 真假
curl PubMed 看 primary outcome（negative）
Claude 自動改寫 conclusion：「不建議常規補充」
對比同題丟 ChatGPT web — 它會正面回答

14 步中 4 步 deterministic gate（step 4-8 grep + curl × 2 + 對應）—— 這就是「來源判讀」的本體。

藥師最該知道的第 3 個 deterministic API：OpenFDA

Crossref + PubMed 是文獻；OpenFDA 是藥物 label / 副作用 / 召回 — 藥師日常更需要的。

api.fda.gov/drug/label.json — 完整仿單 41 fields (boxed_warning / indications / interactions ...)
api.fda.gov/drug/event.json — FAERS 不良反應 reports（tirzepatide 已 2,641 筆）
api.fda.gov/drug/enforcement.json — 召回 records（vitamin D 有 8 筆 recall）

免費、no auth、自 2014 維持 12 年。30 秒 curl 一行可上手。

美國 OpenFDA vs 台灣 — infrastructure gap

🇺🇸 OpenFDA（since 2014）

label / event / enforcement REST API
JSON 回應
query syntax 可 filter / search
千萬筆 FAERS 不良反應 reports

🇹🇼 台灣 TFDA / 健保署

「藥品許可證查詢」ASP.NET form
無 REST API
「藥物不良反應通報」內部系統不公開
data.gov.tw 只有 CSV 整批 dump

台灣藥師查跨國藥物 label / 副作用，用 US OpenFDA 比查自家 TFDA 更方便。這個 gap 不是 LLM 能解，是政府治理問題。

Case 3：藥學第 1 名期刊 weekly TOC 自動化

每週 publisher 出新期 → 自動 fetch 全部文章 → quality-check 7/7 → GPT-Pro 寫導讀 → apply to corpus → deploy
17 步中 13 步 deterministic + 1 步 LLM (GPT-Pro 寫導讀) + 1 步 hybrid + 3 步 human
本期 Drugs Vol 86 Issue 6 (2026)：13 文章 / 1.5 MB mega-md / 3 分鐘跑完

過去手動讀 1 期 NEJM = 1-2 hours；現在 5 min。3 年累積省 600-900 hours = 75-115 個工作天。

同一條 pipeline，兩種牆：付費 vs OA

剛剛 Case 3 跑的 Drugs 是付費期刊；換成校方推薦的 JFDA（食藥署，OA）——同一個 bundler，只差在怎麼跨牆。

Drugs（Springer，付費牆）

cloud LLM 連全文都拿不到
要沿用我瀏覽器既有的訂閱 session 跨牆
local agent 才抓得到

JFDA（食藥署，OA）

一行 urllib server-side 直取
連 session 都不用
13 篇全文 + abstract 秒拿

fetch 限制只在付費牆出現。判斷一個來源能不能自動化抓取，第一步不是「LLM 夠不夠強」，而是「它 OA 還是 paywall」。

5 個 case 的 LLM 比例 spectrum

0%　Case 1 macwhisper-watch — 重複 mechanical
6%　Case 3 journal-TOC pipeline — bulk fetch + 1 LLM step
28%　Case 5 SKILL.md 寫作 — build-time codification
29%　Case 2 衛教校正 — LLM creative + verify
35-40%　Case 4 ad-hoc research — judgement-heavy reasoning

Task 越偏 judgement，LLM 越多；越偏 mechanical，LLM 越少。設計 pipeline 不是問「要不要用 LLM」，是「每個 step 屬於哪一種」。

看 AI 醫療產品要問的 4 個問題

它有沒有 deterministic gate？（沒有 = LLM 自由發揮，hallucinate 風險高）
LLM 用在哪 step？（用對地方 = creative；用錯地方 = verify）
Build time vs runtime LLM 比例？（高 build + 低 runtime = 健康 production）
跨 paywall 怎麼處理？（cloud LLM web browsing 拿不到 = 它在唬你）

問對這 4 個的學生／藥師／醫師，看 AI sales pitch 時直接識別「fancy chat 包裝」vs「真 production pipeline」。

結語

AI 讓衛教變快
專業讓衛教變對

速度，是 AI 的。
正確，是你的；而且只能是你的。

真正的差異化：你 own 不 own 自己的 KB

Sandbox 訂閱 chat（你目前熟的）

知識在他家伺服器
對話 history 綁帳號
不能 grep / cite
換 LLM 廠商會失效
公司 sunset 你死定

自己的 KB pipeline（我每天用的）

知識在自己硬碟
所有 source 可 grep
所有 reference 可 cite
任 LLM 都能讀
跟 LLM 廠商解綁

Sandbox 是「借」LLM 處理；KB pipeline 是「擁有」整套知識資產。差異化不在「會用哪個 LLM」，在「你 own 不 own 自己的 KB」。

FAQ — 訂閱那家倒了怎麼辦？ 資料是你的、在你硬碟；LLM 引擎隨時換（Claude → GPT → Gemini → Llama），核心資產不動。

帶一句話回去

打開 AI 之前，先問：「來源可信嗎？」
產出之後，先問：「有沒有超譯？」

謝謝大家。｜Q & A

本場 talk 完整資料：copper0722.com.tw/talk/ai-health-edu-cmu-2026-06-03/

用 AI 做健康衛教