python on 林協霆醫師

openevidence-mcp：將 OpenEvidence 包裝為 MCP 伺服器並整合 PubMed/Crossref 驗證

Sat, 09 May 2026 00:00:00 +0000

# Introduction（引言）

OpenEvidence 為近年備受關注的醫學文獻 AI 問答平台，能在臨床問題上整合即時文獻並提供出處連結。然而 OpenEvidence 並未開放官方 MCP 介面，使其結果難以直接接入現代 AI Coding 助手如 Claude Code、Codex 與 Gemini CLI 的對話流。對於日常需要在醫學書寫與研究中即時查證文獻的醫師而言，這形成顯著的工作流斷層：使用者必須在瀏覽器與 IDE 之間切換，並手動處理引用格式。

本專案提出一個非官方但可重現的 MCP 伺服器實作，將 OpenEvidence 的問答能力以工具呼叫的方式暴露給 LLM 客戶端，並在輸出端整合 BibTeX 匯出與 Crossref 驗證，使每一筆引用都能被自動追溯與重新核實。

# Methods（方法）

伺服器以 Python 標準函式庫為主撰寫，避免複雜外部相依以簡化部署。驗證採用 cookies.json 機制：使用者於瀏覽器登入 OpenEvidence 後匯出 Cookie，伺服器讀取後以同一 session 呼叫後端 API。MCP 工具介面提供至少一個查詢函式，回傳 OpenEvidence 的答案與引用列表；引用會進一步被傳入 Crossref API 比對 DOI 與標題的一致性，標記出可能的幻覺或錯誤匹配。

伺服器另外附帶針對 Claude、Codex、Gemini 的安裝協助腳本，自動將設定寫入各客戶端的 mcp.json 或對應設定檔，降低非工程背景使用者的配置門檻。輸出可選 BibTeX 格式，方便直接導入 Zotero 或學術寫作管線。

# Results（結果）

藉由將 OpenEvidence 包裝為 MCP 工具，使用者可在 LLM 對話中直接以自然語言查詢臨床文獻，並在同一回應中取得可被 Crossref 驗證的 BibTeX 條目。此設計縮短了從「問題」到「可重現引用」的距離，並能搭配多客戶端使用，避免工作流被綁定於單一供應商。引文驗證模組進一步降低 LLM 幻覺帶來的風險。

# Discussion（討論）

本專案展示了 MCP 作為「私域整合層」的價值：當官方未提供標準介面時，使用者仍能以最小成本將自己日常使用的工具納入 AI 對話流。限制方面，由於採用 Cookie 驗證，使用者需自行管理失效與更新；同時非官方 API 可能在後端變動時失靈。未來方向包括：以 Crossref 結合 PubMed 雙重驗證、加入引用評分機制，並探討於本地 LLM 上重現相同管線的可行性。

# 連結

GitHub：htlin222/openevidence-mcp
主要語言：Python
最後更新：2026-05-09

openevidence-skill：以 Python stdlib 鏡像 openevidence-mcp 工具介面的可攜技能包

Thu, 07 May 2026 00:00:00 +0000

# Introduction（引言）

Claude 推出 Skills 機制後，使用者可將特定任務以「漸進式載入」的形式封裝為可重用模組，避免將所有工具一次性塞入 system prompt 而造成 context 浪費。openevidence-mcp 雖能提供完整 MCP 伺服器體驗，但仍需要本地進程管理與 stdio／HTTP 設定。對於僅需要在對話中偶爾查詢醫學文獻的使用者而言，將相同工具介面封裝為 Skill，可大幅降低安裝與維護門檻。

# Methods（方法）

本專案的設計原則是「1:1 鏡像」：完整對齊 openevidence-mcp 的工具呼叫名稱、參數與回傳格式，使既有的 prompt 與工作流可在不改寫的情況下切換到 Skill 模式。實作刻意僅依賴 Python 標準函式庫，避免額外的 pip install 步驟，使技能包可在任何具備 Python 的環境中執行。

部署面則透過 npx skills add htlin222/openevidence-skill 一行指令完成安裝，將檔案複製到 Claude Skills 目錄下即可被 Claude Code、Claude Desktop 與其他相容客戶端讀取。技能包附帶必要的 metadata 與漸進式說明文件，以利 LLM 在判斷是否載入此能力時取得最少且必要的訊號。

# Results（結果）

使用者可在不另外維護長駐 MCP 伺服器的情況下，於 Claude 對話中即時呼叫 OpenEvidence 工具。Skill 形式相較於 MCP 伺服器，啟動延遲更低、跨機器同步更容易；對於以個人筆電為主的醫師工作流尤其友善。1:1 介面亦使團隊能在 MCP 與 Skill 之間自由切換，依環境選擇最適合的部署方式。

# Discussion（討論）

本專案展示了「同一能力、多種封裝」的工程實踐：當底層 API 穩定後，重點便轉移到如何降低使用者採用成本。限制方面，Skill 缺乏 MCP 完整的工具發現與互動協定，較不適合複雜長對話；標準函式庫的限制亦使網路重試與並發控制較為簡略。未來可進一步考慮以 WASM 化的方式分發，或建立 Skill 與 MCP 之間的自動轉換工具。

# 連結

GitHub：htlin222/openevidence-skill
主要語言：Python
最後更新：2026-05-07

session-collection：個人 Claude Code 會話歷史的彙整與檢索倉庫

Tue, 05 May 2026 00:00:00 +0000

# Introduction（引言）

長期使用 Claude Code 之後，個人會累積大量會話檔案：每段對話都可能包含對特定問題的思考過程、可重用的 prompt 模式與最終解法。然而 Claude Code 預設的 session 儲存以時間為主軸，難以從主題或專案視角檢索。當使用者想找回「上次處理 NGS 報告時用過的提示詞」或「某段 R 程式碼的演進過程」時，往往需要逐一翻閱資料夾。本專案旨在建立一個個人化的會話倉庫，將散落於不同機器的紀錄集中後，提供更高層次的檢索與利用。

# Methods（方法）

倉庫以 Python 為主要語言，搭配版本控制將會話檔案結構化保存。透過約定的命名規則（日期、專案、議題標籤）與 metadata 標頭，使每筆會話皆具備可被 grep、可被索引的關鍵字。後續以 Python 腳本進行統計與摘要，例如統計常用 prompt 結構、抽取共通設計模式，或產生可重用的 prompt 模板庫。

設計刻意保持輕量：不引入向量資料庫等複雜架構，先以純文字加 SQLite 形式累積，待資料量超過閾值再考慮升級。此一決策呼應「先讓資料穩定，再選工具」的原則，避免過度工程化。

# Results（結果）

目前倉庫已能集中管理跨機器的會話紀錄，並支援按專案或議題快速回顧。對於從事多專案、需要在不同 LLM 工作流間切換的使用者，本系統提供了個人化「外部記憶」，補足模型本身上下文有限的缺陷。倉庫亦可作為實證資料，分析使用者自身的提示工程演化軌跡。

# Discussion（討論）

本專案的價值在於把「會話」視為長期可分析的資料而非一次性消耗品。限制方面，會話內容可能含敏感資訊，需嚴格控管權限；不同 Claude Code 版本的紀錄格式變動亦需要維護兼容層。未來可考慮加入語意搜尋、跨會話的代理人記憶整合，並將高品質模式自動回灌為 Skill。

# 連結

GitHub：htlin222/session-collection
主要語言：Python
最後更新：2026-05-05

owa-sync：Outlook Web Access 個人同步工具的私有 Python 實驗

Fri, 24 Apr 2026 00:00:00 +0000

# Introduction（引言）

許多醫療機構仍以 Microsoft Outlook 作為內部通訊主要工具，而 Outlook Web Access（OWA）為遠端存取的標準介面。然而 OWA 本身與個人化生產力工具（筆記、任務管理、AI 助手）的整合度有限：使用者無法以程式化方式擷取郵件至個人系統，導致工作流斷裂。本專案探索如何在不破壞機構規範的前提下，將 OWA 中與個人相關的郵件同步至自有平台。

# Methods（方法）

實作以 Python 為主，採用標準 IMAP 或 OWA 公開 API（依機構政策）擷取郵件。架構上拆分為擷取、轉換與寫入三個階段：擷取階段負責認證、分頁與差異同步；轉換階段將郵件結構化（主題、寄件者、時間、附件 metadata）；寫入階段將結構化結果輸出至本地資料庫或檔案，供後續工具串接。

由於牽涉機構帳號，專案刻意避開儲存敏感內容，僅同步必要的 metadata 與使用者明確標記的訊息。Python 在處理跨平台檔案 I/O 與後續資料分析上具備成熟生態，便於與其他研究／個人工具串接。

# Results（結果）

目前已完成基本擷取與本地落地的概念驗證，可作為其他自動化工具（例如 LINE Bot 通知整合、Anki 卡片生成）的上游資料源。對於每天面對海量機構郵件的醫師而言，這提供了一個可程式化過濾與後處理的入口。

# Discussion（討論）

本專案最大的價值在於協助個人在機構限制下重新取得對自己訊息流的控制權。限制方面，機構政策、雙因素認證與郵件保留期限皆可能影響可實現程度；任何同步機制都必須謹慎處理隱私與資安。未來可加入 LLM 摘要、依寄件人優先排序，以及與既有 calendar／任務系統的雙向同步。

# 連結

GitHub：htlin222/owa-sync
主要語言：Python
最後更新：2026-04-24

tcga-brca-reanalysis：以 Venet 2011 範式重新檢驗乳癌機轉導向基因標記的預後價值

Fri, 24 Apr 2026 00:00:00 +0000

# Introduction（引言）

Venet 等人於 2011 年指出，乳癌中許多被宣稱具有預後意義的基因標記，其表現甚至不優於以「隨機抽取相同大小基因集」為對照的虛擬標記。此一觀察動搖了多項分子分類器的價值，但相關範式並未被廣泛複製檢驗。本專案在 TCGA-BRCA 上重複並擴充此一比較，並進一步以 METABRIC 與 SCAN-B 兩個獨立資料集驗證，並做 meta-PCNA（增殖相關基因）校正以排除增殖訊號的干擾。

# Methods（方法）

研究蒐集已發表、宣稱具備生物機轉解釋的乳癌預後基因標記集合，於 TCGA-BRCA 中以 Cox 比例風險迴歸評估其與整體存活的關聯。對照組為等量隨機基因集（重複多輪取得分布），比較目標標記是否顯著優於隨機集。為控制乳癌族群中強烈的增殖訊號，採用 meta-PCNA 校正，將每個標記的訊號扣除增殖共線性後再評估。最後將同樣分析套用至 METABRIC 與 SCAN-B，檢驗結果在不同資料集間的穩定性。

整體實作以 Python 為主，利用其在生物資訊與統計計算上的成熟生態，並嚴格紀錄資料前處理、標記定義與隨機種子，確保可重現性。

# Results（結果）

初步分析顯示，相當比例的「機轉導向」標記在隨機基因集對照下並未展現顯著優勢，且在 meta-PCNA 校正後其顯著性進一步下降。跨資料集驗證亦顯示部分標記僅在 TCGA 中具關聯，於 METABRIC 與 SCAN-B 並不穩定。此結果延伸並更新 Venet 2011 的觀察，提供當代乳癌分子分類研究的反思素材。

# Discussion（討論）

本專案提醒研究社群：在處理高維表現數據時，「比隨機好」應為基本門檻而非高標準。其貢獻在於建立可被重複的基準，使後續新標記能被同樣的方法檢驗。限制方面，原始論文的標記定義可能不完整，且不同資料集的處理流程仍可能引入偏誤。未來可擴充至其他癌症類型，並結合機器學習模型公平比較。

# 連結

GitHub：htlin222/tcga-brca-reanalysis
主要語言：Python
最後更新：2026-04-24

meta-pipe-validation：meta-pipe AI 輔助 Meta 分析管線之驗證實驗

Thu, 23 Apr 2026 00:00:00 +0000

# Introduction（引言）

AI 輔助的 Meta 分析管線（如本作者之 meta-pipe）能在文獻搜尋、資料萃取與統計合成上大幅減少人力。然而當管線由人工流程升級為高度自動化時，必須以系統性方式驗證其結果是否與既有人工 Meta 分析一致。本專案即為 meta-pipe 的驗證實驗倉庫，蒐集多項已發表 Meta 分析作為「真值」資料集，並以重現結果的差異作為品質指標。

# Methods（方法）

驗證流程以 Python 為主：選定一系列具備完整原始資料與可重現分析腳本的已發表 Meta 分析作為基準，將其原始文獻 ID、納入排除標準與主要終點輸入 meta-pipe，比對自動化管線輸出與已發表結果。比對指標包含：納入研究數一致性、主要效應量點估計差異、95%信賴區間重疊、以及異質性指標。

對於差異顯著的案例，以根因分析方式逐步檢視：是否在文獻檢索階段漏掉某些研究？是否在資料萃取階段發生值錯誤？是否統計方法選擇造成差異？此一精細化驗證使後續改進有具體方向。

# Results（結果）

驗證結果作為 meta-pipe 改版的依據：當特定類型的研究（如交叉設計、群集試驗）出現系統性偏差時，便可在主管線中加入專屬處理邏輯。此私有倉庫亦可作為投稿方法論論文時的審稿補充材料，提供高度透明的可重現性證據。

# Discussion（討論）

本專案展示了 AI 輔助科學工具的標準驗證實踐：不僅描述其能力，更要量化其與人工結果的差距。限制方面，「真值」依賴的已發表 Meta 分析本身也可能有缺失，需謹慎挑選；驗證資料集的代表性會影響結論的泛化能力。未來可擴充至跨疾病領域、跨研究設計的驗證集，並建立持續整合（CI）每次更新都自動跑驗證的流程。

# 連結

GitHub：htlin222/meta-pipe-validation
主要語言：Python
最後更新：2026-04-23

ashop：以 Python 探索小型商店資訊系統雛形的個人實驗

Wed, 22 Apr 2026 00:00:00 +0000

# Introduction（引言）

對於主要工作於醫療領域的工程師而言，刻意涉入其他領域（如零售、餐飲）能反向幫助理解「資訊系統的共通結構」：商品、庫存、訂單、會員、優惠等概念在多數產業皆有對應實體。本專案以小型商店為虛擬情境，作為個人練習領域建模、Python 後端設計與資料庫互動的實驗素材。

# Methods（方法）

實作以 Python 為主，遵循從最小可行版本逐步擴張的方法：先以資料類別與簡單檔案儲存實作核心領域物件（商品、訂單、客人），再引入 SQLite／SQL 資料層、API 介面與基礎權限控制。每一步皆刻意保持程式碼可讀性，並紀錄設計決策的理由，以利日後回顧。

雖然並非真實上線專案，但採用如同臨床研究般的嚴謹態度：撰寫測試以驗證關鍵業務規則、以版本控制紀錄重大重構、並維護精簡而清楚的 README。透過此一過程，作者能在脫離醫療領域慣性後，以更通用的眼光審視軟體工程實踐。

# Results（結果）

專案目前提供一個可被啟動的小型商店原型，包含商品管理與訂單流程。對作者個人而言，更重要的成果是練習了「跨領域思考」與「以最少程式碼表達清晰領域模型」的能力，這些在臨床資訊系統設計上同樣關鍵。

# Discussion（討論）

本專案凸顯了個人化練習倉庫對於工程師長期成長的價值：不一定要為了上線而存在。限制方面，由於非真實場域，缺乏實際業務反饋下的演化壓力，部分設計決策可能無法被現實檢驗。未來可考慮將其重構為臨床情境下的「小型診所管理系統」，把個人練習轉化為對醫療資訊系統的方法學貢獻。

# 連結

GitHub：htlin222/ashop
主要語言：Python
最後更新：2026-04-22

breast-cancer-uptodate：以 OpenEvidence、OncDaily、OncLive 與 ESMO 自動產出每週乳癌治療趨勢報告

Sun, 19 Apr 2026 00:00:00 +0000

# Introduction（引言）

乳癌治療領域進展極快，從 HER2 低表現的新藥（如 trastuzumab deruxtecan）、CDK4/6 抑制劑於早期治療的角色，到免疫治療與抗體藥物複合體（ADC）的試驗結果，每週都有可能改變臨床實務的訊息。然而臨床醫師難以每週手動瀏覽所有來源並整理趨勢。本專案以自動化方式定期蒐集 OpenEvidence、OncDaily、OncLive 與 ESMO 等可信來源的乳癌治療新訊，產出可被快速消化的趨勢報告。

# Methods（方法）

系統以 Python 為主，於每週固定時間執行排程任務：依關鍵字與日期過濾從各來源擷取最近一週的乳癌相關內容，並以 LLM 進行摘要、分類與重要性判定。輸出採用結構化 Markdown，包含「重要試驗」、「指引更新」、「FDA／EMA 動態」、「會議摘要」等固定欄位，使讀者能在固定模板下快速比較不同週次。

設計重點在於來源透明：每筆摘要皆附原始連結與發布日期；任何由 LLM 生成的詮釋皆與原文嚴格區分。執行紀錄留存於版本控制中，使後續可回溯任一週的原始素材。

# Results（結果）

每週報告構成一份個人化乳癌治療趨勢電子報，可由作者本人優先閱讀，亦可作為與住院醫師或 fellow 教學討論的素材。對於非專責乳癌但需偶爾接觸該疾病的內科醫師，此報告提供低成本的「跟上腳步」方式。長期累積的報告亦能作為文獻檢索的補充索引。

# Discussion（討論）

本專案實踐了「以自動化補足注意力有限」的概念：當資訊過量時，重點不在於讀更多，而在於有結構地讀少而對。限制方面，自動摘要可能漏掉超出關鍵字過濾範圍的重要訊息；LLM 對某些臨床細節的詮釋仍需人工把關。未來可加入個人化偏好（例如更關注 HER2 低表現或 BRCA 突變子群），並結合 RSS 訂閱整合至既有閱讀流程。

# 連結

GitHub：htlin222/breast-cancer-uptodate
主要語言：Python
最後更新：2026-04-19

topological-stratification-aml：以拓樸資料分析建立 AML 轉錄體風險分層管線

Sat, 18 Apr 2026 00:00:00 +0000

# Introduction（引言）

急性骨髓性白血病（AML）在分子層面具有高度異質性，傳統分子分類（如 ELN 風險分層）能解釋部分預後差異，但對眾多基因表現異常仍缺乏統一視角。拓樸資料分析（topological data analysis, TDA）以 Mapper、persistent homology 等工具，能在高維資料中萃取「形狀」訊息，捕捉一般降維方法（PCA、UMAP）易忽略的全域結構。本專案以 TDA 為核心，結合 TCGA-LAML 與 BeatAML 兩大公開資料庫，建立可重現的 AML 轉錄體風險分層管線。

# Methods（方法）

管線以 Python 為主要語言，採用如 giotto-tda、kmapper 等套件。資料整合階段先標準化兩資料集的基因表現量並調整批次效應，再以共同基因集為輸入計算 Mapper 圖；節點上的子群以下游分析（生存、突變共現）描繪其臨床意義。Persistent homology 則用於量化不同特徵子集所攜帶的全域形狀資訊。

模型輸出為個體層級的拓樸位置（topological coordinates），可作為下游 Cox 模型或機器學習分類器的輸入。整體流程嚴格保留可重現性，所有資料來源版本與分析腳本皆紀錄於 Git。

# Results（結果）

初步結果顯示 TDA 能識別不被既有 ELN 風險分層完全捕捉的子群，且部分子群在兩資料庫間具一致的預後表現。對於臨床醫師而言，此一方法提供傳統分子分類之外的補充視角；對於方法學研究者，本管線可作為將 TDA 應用於其他血液惡性腫瘤的範本。

# Discussion（討論）

本專案突顯了拓樸方法在生物資訊學的潛力：當問題的關鍵在於「整體形狀」而非單一特徵時，TDA 是值得納入的工具。限制方面，Mapper 結果受參數選擇影響顯著，需謹慎調校；TDA 的可解釋性對非專業讀者仍不直觀。未來可加入單細胞 AML 資料集，並結合 LLM 對拓樸結果產出可被臨床醫師理解的敘事化摘要。

# 連結

GitHub：htlin222/topological-stratification-aml
主要語言：Python
最後更新：2026-04-18

research-guardian-skill：以多閘自動驗證守護 AI 生成研究產出的品質

Fri, 17 Apr 2026 00:00:00 +0000

# Introduction（引言）

當 LLM 大規模參與研究寫作後，研究產出（草稿、表格、引用、分析腳本）的品質保證成為新興問題：作者必須在 LLM 速度與學術嚴謹度之間維持平衡。手動審查每一個 AI 生成段落並不可行，研究界需要可程式化的「品質守護人」，在交付前對產出進行系統檢查。本 Skill 即扮演此一角色，將品質審查視為一連串可被自動執行的閘門。

# Methods（方法）

Skill 以 Python 撰寫，提供多閘驗證機制，可由 Claude 對話呼叫。每一閘對應一類常見品質問題：引用真實性（透過 PubMed／Crossref 比對）、統計合理性（檢查報告之 p 值與信賴區間是否內部一致）、結構規範（是否符合 IMRaD 或指引格式）、語氣中立度（避免過度斷言或宣傳語氣）。閘門皆設計為可獨立呼叫，使用者可依需求選擇全部執行或局部執行。

設計上強調「拒絕分」而非「給分」：守護人並非評鑑作品優劣，而是擋住明顯的錯誤與過度表述。Skill 安裝以 npx skills add htlin222/research-guardian-skill 完成，與其他作者撰寫工具（如 OpenEvidence、bestseller）可組合運用。

# Results（結果）

研究產出在送交審稿前先經過多閘驗證，可大幅減少因引用錯誤、統計矛盾或語氣偏誤而被退稿的風險。對於以 LLM 加速研究寫作的團隊，此 Skill 提供了「自動化的編輯第二雙眼」，特別適合住院醫師、研究生等仍在學習學術規範的階段。

# Discussion（討論）

本專案展現了一個重要趨勢：當生成端進入工業化階段，驗證端也需相應工業化。其貢獻在於提供可組合的品質閘門模組，使研究者能根據自身工作流彈性裝配。限制方面，閘門無法完全取代人工審查，特別是在創新性與洞見的判讀上；過度依賴自動化也可能導致研究者對自身產出的盲目信心。未來可擴充至特定學門的專屬閘門，並結合 LLM 的 chain-of-thought 提供更細緻的審查紀錄。

# 連結

GitHub：htlin222/research-guardian-skill
主要語言：Python
最後更新：2026-04-17

sctda-cancer-plasticity：以 TDA 量化 EGFR 突變肺癌之藥物誘導細胞狀態可塑性

Wed, 15 Apr 2026 00:00:00 +0000

# Introduction（引言）

EGFR 突變肺癌對標靶藥物的反應與抗藥性是現代腫瘤學的重要主題。近年研究指出，抗藥性不全然來自基因突變，更多源自細胞狀態（cell state）的可塑性轉換，例如上皮間質轉化（EMT）或分化退化。傳統聚類方法以離散群集刻畫單細胞資料，難以捕捉狀態之間的連續流動。本專案以拓樸資料分析（TDA）提供量化「狀態空間形狀」的工具，並於 EGFR 突變肺癌的 scRNA-seq 資料上實作。

# Methods（方法）

管線以 Python 為主，採用 Mapper 與 persistent homology 等 TDA 方法，輸入為治療前後配對的單細胞表現矩陣。第一步以高變異基因進行降維後計算 Mapper 圖，描繪細胞狀態之間的連結結構；第二步以 persistent homology 量化處理前後拓樸結構的差異，作為「可塑性」的可量化指標。

整體流程設計為可重現：每個步驟皆有對應的 Quarto 文件記錄參數選擇與生物學詮釋；資料來源公開且版本明確標註，使他人可獨立重複此分析。

# Results（結果）

初步結果顯示，治療後細胞狀態空間的拓樸結構發生顯著變化，並可由 persistent homology 指標量化呈現。此一指標可與抗藥性程度進行關聯分析，作為新的生物標記候選。框架本身亦可被推廣至其他癌症與其他治療類型的單細胞研究。

# Discussion（討論）

本專案展示了 TDA 在腫瘤可塑性研究的潛力：以「形狀」而非「群集」作為主要分析單位，更能對應細胞狀態的連續性。限制方面，TDA 結果敏感於降維與 Mapper 參數，需透過多種設定進行穩健性檢查；單細胞資料本身的批次效應與 dropout 仍會影響下游解讀。未來可加入空間轉錄體資料以納入組織結構訊息，並與機制模型結合提供更完整的可塑性描述。

# 連結

GitHub：htlin222/sctda-cancer-plasticity
主要語言：Python
最後更新：2026-04-15

meta-pipe：AI 輔助、端對端可重現的 Meta 分析管線

Sun, 12 Apr 2026 00:00:00 +0000

# Introduction（引言）

Meta 分析雖被譽為證據金字塔頂端，但其完整流程從文獻搜尋、篩選、資料萃取到統計合成往往耗時數月。傳統工具（如 RevMan、Covidence）雖支援工作流，但在自動化與可重現性上仍有空間。隨著 LLM 在文獻處理上的能力大幅提升，是否能將 Meta 分析從「人工為主、工具為輔」翻轉為「工具為主、人工為輔」成為值得探索的方向。本專案即提供一套 AI 輔助、端對端可重現的 Meta 分析管線。

# Methods（方法）

管線以 Python 為主，分為以下階段：（1）文獻搜尋，整合多個資料庫 API 並產出符合 PRISMA 流程圖的紀錄；（2）標題摘要篩選，由 LLM 依預設納入排除標準先行分類，人工僅審核邊緣案例；（3）全文擷取與資料萃取，LLM 從 PDF／HTML 中擷取結構化欄位（PICO、效應量、變異）；（4）統計合成與敘事化結論，採用既有套件（如 metafor、PythonMeta）執行森林圖、異質性分析與敏感性分析。

關鍵設計為「人類在環」：LLM 處理重複性高、規則明確的任務，研究者則在每階段交叉口進行決策確認。所有 LLM 呼叫皆紀錄 prompt 與輸出，確保可追溯。

# Results（結果）

管線可在合理時間內完成大量原本需數月人工的工作，並產出可被同儕審查的中間產物（PRISMA 流程圖、納入研究表、效應量計算腳本）。對個別研究者而言，這降低了從問題形成到投稿的時間；對教學者而言，管線可作為 EBM 課程的具體實作範例。

# Discussion（討論）

本專案展現了 AI 輔助 Meta 分析的可行性，並建立可被驗證的方法論基礎（與姊妹專案 meta-pipe-validation 配對）。限制方面，文獻篩選的 LLM 判斷仍受 prompt 設計影響，需在不同主題下重新校準；資料萃取對於非標準報告的論文準確度仍有限。未來方向包括：與既有研究軟體的雙向資料同步、加入網絡 Meta 分析支援、以及多語言文獻的整合。

# 連結

GitHub：htlin222/meta-pipe
主要語言：Python
最後更新：2026-04-12

lymphoma-TLS-outcome：淋巴瘤腫瘤溶解症候群是否預後較差的研究腳手架

Sat, 11 Apr 2026 00:00:00 +0000

# Introduction（引言）

腫瘤溶解症候群（tumor lysis syndrome, TLS）為高負荷淋巴瘤治療開始時的潛在致命併發症，其嚴重程度可由臨床／實驗室定義。臨床觀察上，呈現自發性 TLS 或於初期治療即誘發 TLS 的患者，其腫瘤負荷往往較大、增殖率較高。此一觀察是否能轉化為「預後較差」的量化結論，仍缺乏系統性證據。本專案即以此問題為核心，建立可重複的研究腳手架以對標多個資料來源。

# Methods（方法）

研究以 Python 為主，採回顧性分析框架。納入標準涵蓋具明確 TLS 診斷紀錄之淋巴瘤病人，並依 Cairo-Bishop 等共識劃分臨床／實驗室 TLS。對照組為相同期間內未發生 TLS 之同類淋巴瘤病人。主要終點為整體存活，次要終點包括無進展存活與治療中斷。

統計上採 Cox 比例風險迴歸，調整年齡、IPI 分數、組織學型別與一線治療等共變項，並以傾向分數匹配作為敏感性分析。所有資料前處理與分析腳本均納入版本控制，確保結果可被獨立重現。

# Results（結果）

研究目前以骨架專案的形式建立，預計分析結果將於正式發表後揭露。即便最終結果為負相關（即 TLS 並不獨立預示更差預後），其方法學貢獻仍有意義：提供結構化、可遷移的「特定併發症與預後關聯」研究模板。

# Discussion（討論）

本專案展現了臨床觀察與系統性研究之間的連結：將「我覺得這群病人比較差」的直覺轉換為可被檢驗的假設。限制方面，TLS 紀錄品質受醫師判讀影響，可能存在分類錯誤；不同治療強度的混雜需謹慎處理。未來可結合多中心資料、加入分子亞型資訊，並與 LLM 自動化的病歷標註系統結合擴大樣本。

# 連結

GitHub：htlin222/lymphoma-TLS-outcome
主要語言：Python
最後更新：2026-04-11

toefl-skill：TOEFL iBT 2026 備考教練與學習系統的 Claude Skill

Mon, 06 Apr 2026 00:00:00 +0000

# Introduction（引言）

TOEFL iBT 為臨床醫師申請海外進修、研究合作或英語教學職位常見的英語門檻測驗。其四個子測驗（聽、說、讀、寫）各自需要不同訓練策略，而市售教材多為被動式內容，缺乏針對個人弱點動態調整的教練功能。隨著 LLM 在語言評估與互動上的能力提升，將 TOEFL 備考流程數位化、客製化並嵌入個人 AI 工作流，成為有意義的設計目標。

# Methods（方法）

Skill 以 Python 撰寫，採漸進式載入：使用者透過 npx skills add htlin222/toefl-skill 安裝後即可在 Claude 對話中觸發。內含分項練習（精選題型、口語題範本、寫作架構）、模擬測驗與弱點分析。每次互動皆會將結果結構化記錄，作為下次練習動態出題的依據。

設計重點為「學習如同教練指導」：Skill 不單純提供答案，而是引導使用者先嘗試、再回饋、再反思。為了避免 LLM 評分的飄移，內建多個對標 ETS 評分標準的提示詞模板，使口語與寫作回饋盡可能穩定。

# Results（結果）

完成 Skill 後，使用者可在固定碎片時間內進行針對性練習，特別是口語自我錄音與寫作即時批改。對於忙碌醫師，能將通勤、值班空檔轉換為有效備考時間。Skill 形式亦使其能與作者其他學習工具（eng-speaking、zh-ebn-report-skill）形成完整的英語訓練生態。

# Discussion（討論）

本專案展現了「將傳統考試備考數位化」的可能性：當教材本身具備互動與反饋能力時，學習效率可顯著提升。限制方面，TOEFL 出題機構與評分系統的細節仍為閉源，Skill 評分僅能近似而非完全等同；長期備考的動機維持仍需學習者主導。未來可加入語音直接打分、與 Anki 整合進行單字長期保留，並提供繁體中文的學習說明。

# 連結

GitHub：htlin222/toefl-skill
主要語言：Python
最後更新：2026-04-06

zh-article-analyzer-skill：繁體中文文章深度分析的 Claude Skill

Sat, 04 Apr 2026 00:00:00 +0000

# Introduction（引言）

繁體中文社群每日皆有大量文章流通：從新聞、社群貼文、醫學科普到評論文章。讀者若僅以「同意／不同意」作為消費方式，便錯失了反覆訓練批判思考的機會。傳統閱讀方法靠手寫筆記，效率低；單純丟給 LLM 摘要又流於表層。本 Skill 主張「文章值得被結構化拆解」，並提供可重複的分析框架。

# Methods（方法）

Skill 以 Python 撰寫，定義了多個分析面向：論點與支撐（找出主張與證據）、語氣與情緒（中立／批判／煽動）、邏輯謬誤（是否存在常見謬誤）、修辭手法（反問、訴諸權威、滑坡）、可驗證之事實主張。對於每篇輸入文章，Skill 系統性地針對各面向給出評論，並請使用者自行判斷文章是否值得進一步信任或引用。

設計重點為「不下結論」：Skill 不告訴使用者「這篇文章對或錯」，而是提供結構化分析使讀者自行判斷。安裝為 npx skills add htlin222/zh-article-analyzer-skill。

# Results（結果）

使用者可在閱讀繁體中文文章時，將內容貼入 Claude 對話以快速取得多面向分析報告。對於日常瀏覽社群媒體、評估健康資訊、甚至評估自身寫作品質，本 Skill 提供了一個輕量但深度的工具。對作者本人，更是練習「不被表面情緒帶走」的閱讀紀律。

# Discussion（討論）

本專案具體實踐了「LLM 為讀者賦能」的理念：與其讓 LLM 替使用者讀，不如讓 LLM 幫使用者讀得更深。限制方面，分析面向仍受預設模板限制，特殊文類（小說、詩、學術論文）需要不同框架；繁體中文 NLP 與簡體中文資源生態仍有落差。未來可加入領域特化模板（醫療科普、法律時事）與互動追問模式。

# 連結

GitHub：htlin222/zh-article-analyzer-skill
主要語言：Python
最後更新：2026-04-04

FoundationOne-to-Oncoprinter：將 FoundationOne 報告轉為 cBioPortal OncoPrinter 格式

Sat, 28 Mar 2026 00:00:00 +0000

# Introduction（引言）

FoundationOne 是腫瘤學常用的商用 NGS 報告平台，但其輸出格式與研究界常用的 cBioPortal OncoPrinter 不一致。臨床研究者若想以 OncoPrinter 視覺化一群病人的突變地景（mutation landscape），需手動整理資料並對齊欄位，極耗時。本專案提供一個自動化轉換工具，將 FoundationOne 報告（PDF 或結構化資料）轉為 OncoPrinter 接受的格式，包含突變、複製數變異（CNV）與融合三大類型。

# Methods（方法）

工具以 Python 撰寫，輸入支援多種 FoundationOne 報告格式（PDF 經 OCR 萃取、官方 API、結構化匯出）。轉換階段依 OncoPrinter 規範產出三類事件：突變以基因符號加變異形式呈現、CNV 標示為 AMP／DEL、融合則為兩基因符號連接。輸出採 tab-separated values（TSV）格式，可直接貼入 cBioPortal OncoPrinter 線上工具或本地版本。

設計重點為「忠於原資料」：每個事件可追溯至原始報告中之頁碼或欄位，避免轉換過程造成資訊扭曲。對於模糊事件（如 VUS 變異），工具提供標記而非自動排除，由研究者依研究目的決定是否納入。

# Results（結果）

轉換工具讓臨床研究者得以在數分鐘內將數十份 FoundationOne 報告整理為 OncoPrinter 視覺化所需格式，省去原本以 Excel 手動整理數小時的負擔。對於進行回顧性分子流行病學研究的團隊，這顯著加速了從報告到圖表的流程。

# Discussion（討論）

本專案展現了「臨床基因體學工具鏈中介層」的價值：解決商用報告與開源生態之間的格式落差，雖技術簡單但實用性極高。限制方面，OCR 解析的準確性仍受 PDF 品質影響；FoundationOne 報告版本變動可能導致欄位對應失敗。未來可擴展支援其他 NGS 商用報告（如 Caris、Tempus），並接入 OncoKB 進行可治療性註解。

# 連結

GitHub：htlin222/FoundationOne-to-Oncoprinter
主要語言：Python
最後更新：2026-03-28

nccn-skill：將 NCCN 指引 PDF 轉為結構化 AI Skill 的元 Skill

Sat, 28 Mar 2026 00:00:00 +0000

# Introduction（引言）

NCCN（美國國家綜合癌症網路）臨床實踐指引為腫瘤學最廣為使用的決策參考之一，但其 PDF 格式不利於 AI 工具直接消費。當醫師詢問特定臨床決策時，LLM 若只依賴一般訓練資料，可能引用過時版本或產生幻覺。本專案以「元 Skill」（meta-skill）為定位：它的功能不是直接回答臨床問題，而是把任意 NCCN PDF 指引「轉換為可被 Claude 等客戶端載入的 Skill 套件」。

# Methods（方法）

實作以 Python 為主，整體流程：擷取 PDF 為結構化區段（章節、決策樹、藥物表格）；以平行 Haiku 模型完成各區段的細節轉譯；產出符合 Vercel Skills 協定的 Skill 套件，包含 metadata、漸進式揭露的內容檔與抗幻覺機制。引文強制機制要求最終 Skill 在回答時必須引用對應的指引段落原文，避免 LLM 自行延伸。

設計重點為「漸進式揭露」：Skill 不會一次將整份指引塞入 LLM context，而是依使用者問題動態擷取相關段落，平衡資訊密度與 context 長度。平行 Haiku 設計則大幅縮短轉換時間，使一份完整指引可在數十分鐘內被「Skill 化」。

# Results（結果）

研究者或臨床教師可將任意 NCCN 指引透過本元 Skill 轉換為可分享的 Skill 套件，並透過 npx skills add 安裝至 Claude 客戶端。對於組織內部教學，這提供一種「將共享資源轉化為共享工具」的新方式。實證上產出的 Skill 在抗幻覺機制下顯著降低引文錯誤率。

# Discussion（討論）

本專案具體實踐了「指引即 Skill」的觀念：當臨床指引能以結構化方式被 LLM 消費時，便能在不違反著作權的前提下大幅提升 LLM 的臨床可信度。限制方面，PDF 結構複雜時轉換品質仍需人工審核；NCCN 指引更新頻繁，Skill 需有版本管理機制。未來可擴展支援其他指引（ESMO、ASH、ESC），並建立中央 Skill 倉庫供臨床社群協作。

# 連結

GitHub：htlin222/nccn-skill
主要語言：Python
最後更新：2026-03-28

openEvidence：個人 Telegram Bot 包裝 OpenEvidence 提供串流式醫學問答

Sat, 28 Mar 2026 00:00:00 +0000

# Introduction（引言）

實證醫學問答工具如 OpenEvidence 在桌面瀏覽器上體驗良好，但臨床醫師多數時候並不在桌前：值班、會診、查房中皆可能突然需要查詢實證資料。此時手機是最方便的入口，而 Telegram Bot 提供低摩擦的對話介面。本專案將 OpenEvidence 包裝為個人 Telegram Bot，使醫師可在行動裝置上以對話方式取得實證答案與 PubMed 引文，並支援串流回應以維持即時感。

# Methods（方法）

Bot 以 Python 撰寫，採用 Telegram Bot API 並串接 OpenEvidence 後端（透過 Cookie 或 API 認證，依姊妹專案 openevidence-mcp 的機制）。回應採串流模式：當 OpenEvidence 後端開始輸出時，Bot 即時將文字轉為 Telegram 訊息更新，使使用者不必等待完整回應。引文則以結構化方式附加，包含 PubMed 連結與摘要資訊，方便進一步閱讀。

設計上強調個人化使用：僅授權給特定 Telegram 帳號，避免被作為公共服務濫用。所有查詢紀錄存於本地，不外傳第三方，符合作者個人對資料主權的偏好。

# Results（結果）

完成的 Bot 使醫師能在行動裝置上以低摩擦方式取得實證答案。實際使用情境包括：值班時快速確認某藥物在特定情境的證據等級、會診前查閱最新指引摘要、查房中針對特殊病例獲得鑑別診斷建議。串流回應顯著改善等待體驗，更接近與真人對話的感受。

# Discussion（討論）

本專案具體展示了「將後端工具搬上行動端」的價值：當入口被改造為合適的介面，使用頻率與場景都會擴張。限制方面，Telegram 在某些國家的可用性有限；OpenEvidence 後端的速率限制亦會影響高頻使用。未來可加入語音輸入、與 LINE Bot 並行部署，並結合 RSS 訂閱推送個人化文獻更新。

# 連結

GitHub：htlin222/openEvidence
主要語言：Python
最後更新：2026-03-28

prisma-automation：以 Python 與 R 自動化 PRISMA 系統性回顧工作流

Sat, 28 Mar 2026 00:00:00 +0000

# Introduction（引言）

PRISMA 為系統性回顧與 Meta 分析的標準報告框架，要求研究者透明展示每一步研究納入與排除的數量。傳統工作流以多個工具（Endnote、Excel、Covidence、RevMan）拼接，容易出現步驟之間的計數不一致。本專案以開源工具鏈將完整 PRISMA 工作流以程式化方式串起，從文獻搜尋、篩選、去重到流程圖自動產生，保障報告數字與實際操作完全對應。

# Methods（方法）

工作流以 Python 與 R 雙語言實作：Python 處理 API 介接（PubMed、Scopus、Web of Science）與機器學習篩選；R 處理統計合成與作圖。文獻去重採基於 DOI／PMID 的精確比對，搭配標題模糊比對作為補充。標題摘要篩選可選擇人工或 LLM 輔助，所有判斷紀錄留存。最終以 flowdoc 等工具自動產出 PRISMA 流程圖，保證流程圖數字與資料一致。

設計重點為「可審計性」：每個篩選決策皆可被追溯至原始紀錄，使審稿人或讀者能驗證計數正確。整體流程以 Make／Snakemake 等任務管理工具編排，便於部分重跑而不需重新處理整個工作流。

# Results（結果）

研究團隊可顯著減少 PRISMA 報告的人工負擔：原需多人協作數週完成的搜尋與篩選工作，得以縮短為數天並提升一致性。對於同時進行多個系統性回顧的研究團隊，此自動化工具大幅提升整體產能。

# Discussion（討論）

本專案實踐了「以程式化保證透明度」的觀念：當每一步都是可重現的程式碼，PRISMA 對於透明度的要求自然得到滿足。限制方面，自動化篩選的決策需要謹慎驗證，特別是高風險偏誤的情境；不同資料庫的搜尋語法差異仍需手動橋接。未來可整合至 meta-pipe 主管線，並加入 LLM 進行偏倚評估的初步建議。

# 連結

GitHub：htlin222/prisma-automation
主要語言：Python（搭配 R）
最後更新：2026-03-28

TMLE-explain：以 Manim 與中文 TTS 製作 TMLE 動畫解釋影片

Sat, 28 Mar 2026 00:00:00 +0000

# Introduction（引言）

目標最大概似估計（Targeted Maximum Likelihood Estimation, TMLE）為近年因果推論的代表性方法，可結合機器學習進行雙重穩健（doubly robust）估計，但其數學細節（影響函數、目標化步驟）對非統計背景的臨床研究者並不友善。傳統教科書與課程多以公式為主，缺乏可隨時暫停回看的視覺化呈現。本專案以 Manim 製作動畫並搭配中文 TTS 旁白，將 TMLE 的核心觀念視覺化。

# Methods（方法）

製作流程以 Python 為主：使用 Manim（3Blue1Brown 開發之數學動畫引擎）製作關鍵步驟的動態圖示，例如初始預測、處理機率、目標化更新與最終估計。中文文字轉語音（如 Azure Cognitive Services、Edge TTS）提供清晰的中文旁白，避免使用者因英文發音差異而分心。所有動畫腳本以程式碼定義，便於同儕審查與後續修改。

設計重點為「視覺化勝過文字」：不要求觀眾在第一遍就看懂所有公式，而是讓他們先建立直覺，再回到教科書補足細節。影片保留中文旁白以服務在地醫學研究社群。

# Results（結果）

完成的影片可作為因果推論課程的教材，亦可作為臨床醫師自學 TMLE 的入門素材。對於非統計專業的研究者，影片提供「為何要這樣估計」的直觀理解，使後續閱讀技術文獻時不至於迷失於符號叢林。

# Discussion（討論）

本專案展現了現代教學工具與生成式 AI（TTS）結合的可能性：高品質教材的製作門檻顯著降低。限制方面，Manim 的學習曲線陡峭，動畫品質仍需作者花時間調校；TTS 雖已自然，但仍不及人類錄音的情感表達。未來可擴展為完整因果推論影片系列（DAG、IPTW、g-computation、TMLE），並提供英文／繁中雙語版本。

# 連結

GitHub：htlin222/TMLE-explain
主要語言：Python（Manim）
最後更新：2026-03-28

clinboard：以 Python 探索臨床儀表板（dashboard）原型的研究專案

Mon, 16 Mar 2026 00:00:00 +0000

# Introduction（引言）

電子病歷雖累積大量資料，但其呈現方式以線性紀錄為主，臨床醫師需在多個頁面之間切換才能掌握病人全貌。在腫瘤學、重症與長期慢性病情境下，這種「資訊片段化」會增加決策延遲與遺漏風險。儀表板（dashboard）是補償此一問題的常見方案：以單一視圖呈現關鍵指標的趨勢與異常。本專案即為臨床儀表板原型探索。

# Methods（方法）

實作以 Python 為主，前端採用 Streamlit 或 Dash 等快速儀表板框架，後端以結構化資料（CSV、SQLite）模擬電子病歷。儀表板呈現包含：生命徵象趨勢、檢驗值時序、用藥時間軸、與重要事件（住院、手術、化療）標註。視圖刻意保持簡潔，避免將儀表板做成「另一個 EHR」。

設計重點為「決策支援而非資訊堆砌」：每個元件需回答一個明確的臨床問題（例如「這個病人最近三個月血色素趨勢如何？」），而非單純呈現所有可得數據。原型不接入真實電子病歷，僅以模擬資料探索 UI／UX 設計，便於後續向資訊部門提案。

# Results（結果）

原型可作為臨床醫師與資訊工程師之間的溝通媒介：醫師看到具體儀表板後更容易表達需求，工程師亦能基於原型理解臨床流程。對於有意推動科內儀表板建置的研究者，本專案提供低成本的 proof-of-concept 工具。

# Discussion（討論）

本專案展現了「以原型加速跨領域溝通」的方法。其貢獻在於建立可被快速調整的儀表板樣板。限制方面，模擬資料與真實 EHR 之間仍有複雜度落差；隱私與權限管理需在實際部署時謹慎處理。未來可結合 FHIR 資料模型、加入 LLM 自動化異常解讀，並擴展至跨科部協作的儀表板。

# 連結

GitHub：htlin222/clinboard
主要語言：Python
最後更新：2026-03-16

batch-download-hiroka：批次下載資源的 Python 私有工具

Thu, 12 Mar 2026 00:00:00 +0000

# Introduction（引言）

研究與教學工作中經常需要下載大量檔案：論文 PDF、課程影片、指引手冊、衛教素材等。手動下載不僅耗時，亦容易因步驟不一致而產生重複或缺漏。對於高頻擷取資料的研究者，自製批次下載工具是值得投資的個人基礎建設。本專案即為作者用於特定資料來源的下載自動化腳手架。

# Methods（方法）

實作以 Python 為主，採用 requests、httpx 等標準函式庫處理 HTTP 請求，搭配 tqdm 提供進度顯示。設計上將「列表擷取」與「個別檔案下載」解耦：先取得需下載的清單與 metadata，再進入下載階段。下載階段支援續傳、平行化、與基本錯誤重試。所有下載紀錄存於本地 SQLite，避免重複擷取相同檔案。

工具刻意保持私有，因為某些下載對象的 ToS 限制其再分發；公開化需要謹慎處理。整體保持輕量，便於應用於不同來源時快速調整。

# Results（結果）

工具已能於背景處理大量下載任務，使作者得以將注意力放在資料分析而非檔案搬運。對於需要週期性更新本地素材庫（如 NCCN 指引、ESMO 簡報）的研究者，這顯著降低人工成本。

# Discussion（討論）

本專案實踐了「將重複行為自動化」的個人生產力原則。限制方面，下載工具高度依賴目標網站的 HTML 結構，遇到改版便可能失效；同時需要謹守機構與來源的使用條款。未來可加入 LLM 輔助解析網頁結構、結合內容摘要自動篩選真正需要下載的檔案。

# 連結

GitHub：htlin222/batch-download-hiroka
主要語言：Python
最後更新：2026-03-12

teamplus-api：探索 Teamplus 對外 API 整合的 Python 私有專案

Sun, 08 Mar 2026 00:00:00 +0000

# Introduction（引言）

Teamplus 為許多醫療機構採用的內部協作平台，提供訊息、會議與檔案分享。然而其與個人化工作流的整合仍仰賴使用者手動切換，未能享受 API 化帶來的自動化潛力。本專案即為作者探索 Teamplus API 介接的私有實驗倉庫，目標是建立一個可被個人 AI 助手（如 Claude Code）呼叫的 API 包裝層。

# Methods（方法）

實作以 Python 為主，依 Teamplus 公開 API 文件（或反向工程）封裝常用功能：取得對話列表、發送訊息、上傳／下載檔案、查詢成員資訊。所有呼叫以結構化函式提供，便於後續被其他工具串接。認證採 OAuth 或 API Token 視機構政策而定，憑證透過環境變數而非硬編碼方式管理。

設計上遵循「最小驚訝原則」：函式命名與參數盡量符合直覺，回傳值結構與其他 messaging API（Telegram、LINE）保持類似，方便跨平台搬遷。私有狀態使其能保留機構專屬細節而不影響其他人。

# Results（結果）

倉庫提供作者個人在 Teamplus 與其他工作流（任務管理、會議備忘、檔案歸檔）之間的橋樑。例如可在 Claude Code 中以對話方式查詢 Teamplus 上的某段討論並自動產出摘要，或將特定群組訊息歸檔至個人筆記系統。

# Discussion（討論）

本專案展現了「打通機構工具與個人工作流」的工程實踐。限制方面，機構政策可能限制 API 使用；API 變動需持續維護；資料隱私必須謹慎處理，避免誤將敏感訊息留存於不適當位置。未來可加入 LLM 自動分類訊息重要性、與 Notion／Obsidian 同步特定討論串、以及行動端整合。

# 連結

GitHub：htlin222/teamplus-api
主要語言：Python
最後更新：2026-03-08

hematology：血液學個人筆記與分析腳本的彙整倉庫

Thu, 19 Feb 2026 00:00:00 +0000

# Introduction（引言）

血液學作為作者的主要專業領域，相關筆記、分析腳本、教學素材與研究實驗散佈於多個專案中，長期容易碎片化。本倉庫定位為「血液學中心倉庫」：將跨多個情境（臨床、教學、研究）所累積的血液學素材集中管理，便於後續分流至專案級倉庫或公開資源。

# Methods（方法）

倉庫以 Python 為主要工程語言，搭配 Markdown 撰寫文字內容、Quarto 處理結合敘述與分析的文件。組織原則依血液學經典分類（紅血球、白血球、凝血、輸血、惡性腫瘤）建立目錄，並輔以時間戳記版本標記重要更新。Python 工具腳本則包含臨床計算、表現量分析與資料視覺化等可重複使用單元。

設計上強調「個人優先、再分流」：不需要每筆筆記都完整或公開化；當某主題累積到一定密度時，再以分支或新倉庫的形式公開（如 pocket-hematology、hematology-board-review 即由此類分流而生）。整體採 Git 管理，使任何變動皆可追溯。

# Results（結果）

倉庫已成為作者血液學知識的私人核心。在臨床現場、研究會議、教學準備等多重情境下，皆能從這個中心倉庫快速取得相關素材。對作者個人而言，這是減少資訊熵的關鍵基礎建設。

# Discussion（討論）

本專案展現了「個人專業知識需要中心倉庫」的觀念：當資訊跨多裝置與多情境流動，缺乏中心便會持續散失。限制方面，私有倉庫的內容無法直接被其他人取用，需有意識地將適合公開的部分分流；維護紀律仰賴持續投入。未來可結合作者其他血液學專案（pocket-hematology、hematology-board-review、HOASH-2026-Asia）形成完整的血液學個人知識生態。

# 連結

GitHub：htlin222/hematology
主要語言：Python
最後更新：2026-02-19