雅寶社區 · 頂客論壇 (AHPAL.COM)

📜 歷史腦洞

如果本草綱目有資料庫：中藥知識的結構化與檢索

發表時間：2026 年 10 月 31 日 | 更新日期：2026 年 10 月 31 日 | 編輯：雅寶社區編輯團隊

所以主鍵應該是一個內部編號，比如 HERB_ID。藥名與別名各自建表，透過中間表做多對多關聯，並附上時代與地域屬性，才能處理「同名異物」與「異名同物」這兩種情況。

接著是分類欄位：部、類可用外鍵指向分類表。產地與採收時節散見於「集解」，可以抽出產地表。炮製方法在「修治」，需要拆子欄位（炒、炙、煅、蒸、酒製、醋製……）。性味歸經在「氣味」，這一欄要拆得更細：四氣（寒熱溫涼平）、五味（酸苦甘辛鹹，另有淡、澀）、有毒無毒、歸經（可能多條，需用關聯表）。功效與主治在「主治」「發明」。禁忌與配伍禁忌雖然不是固定欄目，但散落在各條之中，需要另外做主題抽取。

再往下，是比較麻煩的部分：劑量。中藥的用量單位歷代不同，斤、兩、錢、分、銖、升、合、方寸匕、一字……同一味藥，漢代用「兩」，明代用「錢」，換算比例還隨朝代變動，甚至同一朝代不同地區也有差異。如果資料庫要能回答「這味藥該用多少」，劑量欄位就不能只存一個數字，必須存「數值＋單位＋時代＋原始文本」四件套。少了任何一件，查出來的結果都可能誤導人。

最後是不可省略的來源欄位：卷次、頁碼、版本、校勘註記。沒有這一段，資料庫就只是二手轉述，遇到爭議時無法回溯到原文，也就失去了作為「文獻工具」的資格。

1.3 結構化的極限：有些欄位一拆就死

寫到這裡，一定會有人問：既然都拆成欄位了，為什麼不乾脆把中醫理論也一起編碼，做成一張「症狀—證型—治法—藥物」的完整對應表？

答案是：有些東西一拆就死。

舉個例子。「氣味」欄位可以寫「甘，平，無毒」，這很好存。但李時珍在「發明」裡談甘草，講的是「甘草外赤中黃，色兼坤離；味濃氣薄，資全土德」，這是把性味、顏色、五行、臟腑、升降浮沉全部織在一起的一套類比推理。你可以把它存成一段文字，但你沒辦法把它存成「五行屬性＝土」這樣一個標籤然後拿去查詢——因為一旦標籤化，那套推理的上下文就不見了，剩下一個孤零零的標籤，反而比原文更容易被誤讀。

這就是中藥知識結構化的第一道邊界：可結構化的是「記載」，不完全可結構化的是「論證」。前者可以進欄位，後者只能進全文索引，再加上足夠的原文引用。

一個成熟的資料庫設計，應該坦率地承認這道邊界，而不是假裝它不存在。硬把所有東西都塞進欄位的結果，通常是得到一個看起來很整齊、實際上處處失真的資料集。

二、檢索：從「翻目錄」到「下查詢」

有了資料，下一步就是怎麼把資料找出來。這裡有個很容易被忽略的事實：李時珍其實已經親手做過一次「檢索引擎」。

2.1 卷三、卷四：古人版的倒排索引

《本草綱目》卷三、卷四為〈百病主治藥〉，把常見病證分門別類列出來，每一種病證底下直接列出可用之藥，例如中風、傷寒、痰飲、咳嗽、諸蟲……共列一百餘種病證。這個設計的思想非常現代：它不是按藥查病，而是按病查藥——本質上就是一份以症狀為 key、以藥物清單為 value 的倒排索引。

如果沒有這兩卷，讀者想找「治咳嗽的藥」，就必須把一千八百九十二條從頭翻到尾。有了這兩卷，翻一次就能得到一份候選清單。這是四百年前的資訊檢索工程。

但它有三個明顯的不足：第一，它只有一層，無法交叉查詢，「性溫」與「治咳嗽」只能分別查，不能疊加；第二，它不告訴你出處，某味藥列在咳嗽項下，你得自己回去找那味藥的條目，才知道劑量與禁忌；第三，它不分語義極性，「治咳嗽」與「咳嗽忌用」在文字上都可能出現「咳嗽」，檢索時容易混淆。

這三點，恰好就是現代資料庫能補上的三個地方：多維交叉、可回溯出處、語義標註。

2.2 全文檢索的難題：你要找的是「字」還是「意」？

假設使用者輸入「頭痛」。

最樸素的全文檢索會命中所有出現這兩個字的段落：主治裡的「頭痛」、附方裡的「頭痛」、發明裡的「頭痛」、集解裡某人頭痛的故事，甚至連「頭痛者忌服」都會命中。命中率很高，精確率很低。

因為同樣出現「頭痛」，語義方向可能完全相反。有的是直接功效（「主治頭痛」），有的是限定條件（「治頭痛兼發熱」），有的是禁忌（「頭痛者不可服」），有的是病案敘述（「一婦人頭痛三年」）。如果不加區分，檢索結果就是一堆雜訊。

解決辦法不是期待資料庫「讀懂」中文，而是讓標註更精細。技術上有幾條路徑：一是分欄位索引，讓使用者指定檢索範圍（只在「主治」裡查，或只在「附方」裡查）；二是建立功效詞表，把「治」「主」「療」「止」「除」標為正向功效動詞，把「忌」「禁」「不可」「勿」「慎」標為負向，讓查詢可以表達為「欄位＝主治 AND 詞＝頭痛 AND 極性＝正」；三是同義詞擴展，把「頭風」「腦痛」「首疾」都映射到「頭痛」這個概念之下。

但這裡有一個現實問題：古人的書寫並不整齊。「主治頭痛」可能寫成「療頭風」、「止頭痛」、「頭痛者宜之」，甚至「頭風痛不止，用之效」。想做可靠的檢索，就必須先做詞表與同義詞擴展，而這個詞表本身，取決於編庫者對中醫的理解程度。

資料庫不會自己懂中醫，懂中醫的人得先把知識餵給它。這句話值得所有做中醫數位化的人貼在牆上。

2.3 多條件查詢：「孕婦可以吃嗎」該怎麼問

假設一位使用者輸入四個條件：懷孕、咳嗽、怕冷、不想吃苦的藥。

這是四種性質完全不同的條件。前三個是醫學相關，第四個是體驗相關。傳統目錄完全無法回答，但資料庫可以拆解：妊娠禁忌（禁忌表）、主治咳嗽（功效表）、性味偏溫熱（氣味表）、排除味苦（氣味表）。

查詢邏輯大概是這樣：從藥材表出發，關聯功效表找出含「止咳」「下氣」「化痰」「潤肺」的條目，關聯氣味表篩選四氣屬溫或熱，再 LEFT JOIN 禁忌表排除妊娠禁忌項，最後按五味欄位排除味苦者，並按毒性欄位排序，讓無毒記載的排前面。

有意思的是，這種查詢會產生一批「李時珍沒想過要並列」的結果。比如某味藥在草部隰草類，主治咳嗽、性溫、味甘，且書中未見妊娠禁忌——它可能一輩子都沒被當成「孕婦咳嗽」的推薦用藥，因為古人開方是辨證論治，不是按症狀清單檢索。

資料庫的價值就在這裡：它不是重複古人的思路，而是提供一條古人沒走過的路徑。這條路徑可能有用，也可能荒謬，所以每一個結果都必須附上原文，讓使用者自己判斷。

2.4 相似與替代：缺藥的時候怎麼辦

中藥房最常見的現實問題是缺藥。某味藥沒了，能不能用別的代替？

資料庫可以做相似度計算。把每味藥表示成一個向量：四氣、五味、歸經、功效標籤、毒性等級、產地、炮製方式。然後計算距離。性味歸經越接近、功效標籤重疊越多，距離越近。

但這種「演算法推薦」在傳統藥學裡要非常小心。中藥配伍講究君臣佐使，講究一藥多能，講究「同氣相求」也講究「相反相成」。兩味藥在向量空間裡很近，實務上未必能互換。人參與黨參性味歸經相近，功效方向類似，但古今醫家對二者能否替代爭論至今，劑量與適用人群也不同。更別提有些藥「形似而性異」，一旦互換可能出大問題。

所以相似度檢索的定位應該是「提示」，不是「處方」。它給出的不是答案，而是「這幾味藥值得進一步比較」的清單，並附上各自的原文依據。

這個定位如果搞錯，資料庫就會從知識工具變成風險製造機。

三、資料從哪來：編纂、校勘與版本控制

前面講的都是理想狀態。真正的難關，是把一部四百年歷史的古籍數位化。

3.1 資料清洗：異體字、錯簡與「一名多物」

把《本草綱目》數位化，第一道關卡不是程式，而是文字。

古籍裡異體字、俗字、避諱字滿天飛。同一味藥，不同版本可能寫成不同字形；同一個字，在不同版本裡可能指不同的藥。再加上傳抄過程中的錯簡、脫字、衍文，以及後人增補的內容混入正文。如果直接把某一個刻本的 OCR 結果建成資料庫，等於是把一個特定版本的錯誤固化成「標準答案」。

所以合理的建庫流程應該是：多版本並置 → 校勘 → 建立異文表 → 標記可疑段落 → 保留每一處判斷的理由。這聽起來很學術，其實跟現代軟體的版本控制是同一件事：每一次校改都是一個 commit，要有作者、時間、理由、diff。四百年來的歷代註家，就是四百年份的 commit log。

3.2 歷代註家就是 commit log

《本草綱目》不是憑空出現的。它站在《神農本草經》《本草經集註》《新修本草》《證類本草》一長串前作的肩上。李時珍在書裡大量引用前人說法，並且常常加上自己的判斷——「××曰……時珍竊謂……」這樣的句式，其實就是一種註解式開發。

如果我們把這些層次都保留下來，資料庫就會變得多維：同一味藥，西元二世紀怎麼說，六世紀陶弘景怎麼補，唐代官修本草怎麼改，宋代唐慎微怎麼彙整，明代李時珍怎麼訂正。使用者可以選擇看哪一層，也可以選擇看全部並排。每條記載都標記：來源文獻、時代、作者、可信度評級。

這比單純給出「標準答案」有價值得多。因為中藥知識的本質是累積的、有爭議的、不斷被修正的。一個把爭議抹平的資料庫，看起來乾淨，其實是把最珍貴的部分刪掉了。

順帶一提，金陵版刊行於萬曆二十四年（一五九六），而李時珍已於一五九三年去世，他本人沒能見到這部書印出來。他的兒子李建元把書進獻給朝廷。也就是說，《本草綱目》的第一個「正式發行版」，作者本人根本沒有機會參與最終校對。這件事本身就說明：任何古籍版本，都不是「作者原意」的完美副本，而是一個充滿中介環節的產物。資料庫如果只標一個「出處：本草綱目」，其實是過度簡化了。

3.3 毒性與禁忌：資料庫的責任邊界

這一節要嚴肅一點。

《本草綱目》裡有大量「有毒」「大毒」「久服令人……」的記載，也有不少在現代看來有問題的內容。如果一個公開資料庫把這些內容整理得漂漂亮亮、加上篩選器、做成手機 App，會發生什麼事？

會有人照著查，然後照著用。

所以任何一個認真的中藥資料庫，都必須在設計層面處理責任問題。第一，檢索結果必須附原文與出處，不能只給結論；第二，毒性、妊娠禁忌、十八反十九畏這類高風險資訊，必須有明顯警示標記；第三，不能提供帶有處方性質的輸出，例如「建議劑量」「建議配伍」；第四，要有明確的免責聲明，說明這是文獻檢索工具，不構成醫療建議。

技術上這些都不難，難的是克制。做資料庫的人最容易犯的錯，就是把「能查」當成「能用」，把「有資料」當成「有答案」。

四、如果真的有這個庫：它會長成什麼樣子

講完原理，來做點更具體的想像。

4.1 知識圖譜：把「方」與「藥」連起來

《本草綱目》附方一萬一千零九十六首，這是最有價值的部分之一，也是傳統閱讀最難利用的部分——因為方子散在各藥之下，你要找一個方，得先知道它掛在哪味藥後面。這是一種「以藥找方」的單向索引，反過來「以方找藥」就很吃力。

建成圖資料庫之後，這件事會變得非常有趣。節點有三類：藥、方、病證（或症狀）。邊有多種：方包含藥（並記錄劑量與炮製要求）、方主治病證、藥主治病證、藥與藥之間有配伍關係（相須、相使、相畏、相殺、相惡、相反）。

有了這張圖，就可以回答很多過去難以回答的問題：哪些藥是高頻核心藥？哪些藥對經常同現，形成穩定的「藥對」？某個方子的用藥結構是什麼？某味藥在歷代方劑中的角色如何變化，是從主藥退成佐藥，還是反過來？

甚至可以反過來做：給定一組症狀，找出歷史上結構最接近的方劑群，然後看它們共同用了哪些藥。這不是開方，是研究。研究價值和臨床價值要分清楚，但研究價值本身就已經很可觀——它能讓現代研究者看見古人在相似情境下的用藥傾向，而不只是零散地讀幾個醫案。

4.2 一個具體的檢索範例

我想像中的介面大概是這樣。使用者輸入：

「想找性平或性溫、味甘、歸脾經、能補氣、且不含毒性記載的藥，並列出書中相關附方。」

資料庫回應一個清單，每筆附上：藥名、部類、氣味原文、主治原文、引用卷次頁碼、相關附方數量、可點開的原文。

清單裡大概會出現甘草、大棗、山藥、白扁豆之類。然後使用者點開甘草，看到的不只是「補氣」兩個字，而是從《神農本草經》到李時珍的整條註釋脈絡，以及「甘草反大戟、芫花、甘遂、海藻」這條禁忌的原始出處。

這個體驗和翻書的差別，不是快慢，而是「能不能橫向比較」。紙本書是線性的，資料庫是網狀的。線性閱讀適合深入，網狀檢索適合發現。兩者不是取代關係，而是互補關係——這也是我在整個思考過程中最想強調的一點。

4.3 它做不到的事

再說清楚一點它做不到什麼。

它不能替代辨證。中藥的使用從來不是「症狀對藥名」的對應，而是「證候對治法」的推理。同一個咳嗽，風寒、風熱、燥邪、痰濕、陰虛、肝火，用藥完全不同。資料庫能告訴你某味藥「主治咳嗽」，但不能告訴你這個病人屬於哪一種咳嗽。

它也不能替代炮製與劑量的專業判斷。同一味藥，生用與製用、先煎與後下、大劑與小劑，效果與風險都不同，這些細節在古籍裡往往語焉不詳，需要藥師與醫師依實際情況決定。

它更不能替代人。資料庫是望遠鏡，不是眼睛。

五、結語：結構化的目的，是為了更好地保存不確定性

很多人以為資料庫的目標是「標準化」，是把散亂的知識整理成乾淨的表格，讓一切變得確定、可計算、可比對。

但做完這個思想實驗，我反而覺得，一個好的中藥資料庫，最珍貴的功能是「保存不確定性」。

《本草綱目》裡有多少東西是確定的？藥名、產地、形態，這些相對確定。性味歸經，大體有共識但也有分歧。功效主治，歷代累積、彼此重疊又彼此矛盾。至於「為什麼有效」，李時珍用的是氣化、五行、升降浮沉的語言，這套語言今天已經很難直接翻譯成生化語言。

如果資料庫把這些分歧全部平均掉，輸出「甘草：甘、平、無毒、補氣、清熱解毒、調和諸藥」，看起來很清爽，實際上把一本四百年來不斷被討論、被質疑、被修正的書，壓縮成了一行字。那不是整理，那是閹割。

好的資料庫應該相反：它讓你能一眼看到「這裡有分歧」，然後一鍵跳到三條不同的原文，讓你沿著三條線索自己判斷。它把確定性留給欄位，把不確定性留給引用。

四百年前，李時珍用三十年的時間，把散落在八百部書裡的知識收攏成一部書，讓後人不必再一一翻找。四百年後，如果我們真的為這部書建一個資料庫，做的其實是同一件事：不是替讀者下結論，而是讓讀者更快地抵達那些值得被閱讀的原文。

索引的目的是讓人找到原典，而不是取代原典。這句話，對四百年前的〈百病主治藥〉成立，對今天的資料庫，也一樣成立。

六、附錄：一份假想 Schema 的欄位清單（節錄）

給想動手的人一點參考。以下是這個假想資料庫的幾個核心表與欄位，僅為概念演示，不是完整設計：

藥材主表（herb）：herb_id（主鍵）、標準藥名、部_id、類_id、氣味_四氣、氣味_五味（多值）、氣味_毒性、歸經（多值）、是否有妊娠禁忌（布林）、原始條目連結。

別名表（herb_alias）：alias_id、herb_id（外鍵）、別名、別名來源文獻、時代、地域。

功效表（effect）：effect_id、herb_id（外鍵）、功效描述原文、功效標籤、極性（正／負）、來源欄位（主治／發明／附方）。

附方表（formula）：formula_id、方名、主治病證、出處卷次頁碼、所屬藥條 herb_id（外鍵）。

方藥關聯表（formula_herb）：formula_id、herb_id、劑量數值、劑量單位、炮製要求、在方中角色（君／臣／佐／使）。

禁忌表（contraindication）：禁忌_id、herb_id（外鍵）、禁忌類型（妊娠／配伍／體質／飲食）、禁忌描述原文、來源卷次頁碼。

版本異文表（variant）：variant_id、herb_id、版本名、異文字句、校勘說明、校勘者、校勘年代。

你會發現，這些表裡沒有一張叫「標準答案」。所有表的最後一欄，幾乎都是「來源」與「原文」。這不是巧合，而是設計理念的直接反映：資料庫負責組織線索，判斷留給人。

如果真有這麼一天，我們打開瀏覽器，輸入一串條件，然後看見四百年前那些密密麻麻的小字，一條一條被燈光照亮——那一刻，李時珍大概會覺得，這三十年的功夫，總算沒有白費。

```

🏠 返回首頁