<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:webfeeds="http://webfeeds.org/rss/1.0"><channel><title>automation on 林協霆醫師</title><link>/tags/automation/</link><description>林協霆醫師 (automation)</description><generator>Hugo -- gohugo.io</generator><language>zh-tw</language><image><url>https://htl.physician.tw/favicon-32x32.png</url><title>林協霆醫師</title><link>https://htl.physician.tw/</link><width>32</width><height>32</height></image><webfeeds:icon>https://htl.physician.tw/favicon-32x32.png</webfeeds:icon><webfeeds:logo>https://htl.physician.tw/android-chrome-512x512.png</webfeeds:logo><webfeeds:accentColor>5bbad5</webfeeds:accentColor><lastBuildDate>Sat, 09 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="/tags/automation/index.xml" rel="self" type="application/rss+xml"/><item><title>hemonc-daily-case：以 Claude Code Routine 自動產出 Q1 血液腫瘤每日病例摘要</title><link>/blog/hemonc-daily-case-2026-05-09/</link><pubDate>Sat, 09 May 2026 00:00:00 +0000</pubDate><guid>/blog/hemonc-daily-case-2026-05-09/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>對於專科醫師而言，持續閱讀並消化高品質期刊病例報告是維持臨床敏銳度的重要途徑，但臨床工作繁忙下要每日抽空閱讀並做筆記並不容易。Q1 期刊（如 NEJM、Blood、Lancet 系列）的病例報告字數密度極高，若僅以閱讀器被動瀏覽，難以形成可索引的個人知識資產。本專案以 Claude Code Routine 為自動化引擎，每日定時產出一篇結構化病例摘要，將被動閱讀轉換為主動可搜尋的個人題庫。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>系統以 Claude Code 提供的 Routine 機制建立排程任務，每日於固定時間執行：依據預設來源篩選新發表的血液腫瘤學病例報告，呼叫 LLM 依固定模板（病史、檢驗、鑑別診斷、治療、結果與學習重點）萃取結構化摘要，並寫入版本控制的 Markdown 檔案。Markdown 設計刻意對 Anki、Obsidian 與 Quarto 友善，便於後續轉換為複習卡或教學素材。&lt;/p>
&lt;p>整體流程強調無人值守：當日若無新案例則跳過或注記；若 LLM 輸出失敗則重試並紀錄錯誤。所有產出存入 Git 倉庫，形成具備時間軸的學習日誌。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>每日累積的病例摘要構成一個個人化、可搜尋的血液腫瘤學病例資料庫。透過 Git 歷史可追蹤每日學習軌跡；透過 Markdown 檔案可快速 grep 找出特定疾病或治療藥物相關案例；透過 Routine 化執行確保學習頻率不依賴人為意志力。對於正在準備內科或專科考試的住院醫師、研究員，本系統提供穩定的高品質題材來源。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案實踐了「將學習任務自動化為 routine」的觀念：當醫師專注於品質而非紀律時，學習的可持續性將顯著提升。其限制在於：摘要品質受 LLM 模型版本與 prompt 工程影響，且需確保來源符合著作權規範；過度依賴自動摘要也可能弱化讀者自身的批判性閱讀。未來可結合主動學習，根據使用者答題正確率動態調整摘要難度，並串接至 Anki MCP 自動產出複習卡。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/hemonc-daily-case">htlin222/hemonc-daily-case&lt;/a>&lt;/li>
&lt;li>後端：Claude Code Routine&lt;/li>
&lt;li>最後更新：2026-05-09&lt;/li>
&lt;/ul></description></item><item><title>polish-prompt：以排程式 LLM 教師回顧每日英文寫作 Prompt 資料庫</title><link>/blog/polish-prompt-2026-05-09/</link><pubDate>Sat, 09 May 2026 00:00:00 +0000</pubDate><guid>/blog/polish-prompt-2026-05-09/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>在 LLM 蓬勃發展之後，撰寫提示詞（prompt）已逐漸由臨時性指令演變為可被反覆檢視、版本管理與評估的「文本產出」。對於非英語母語的研究者而言，prompt 不僅是工具，更是英文寫作練習的高密度場域：每一句指令都需要在語法、語氣與精確度之間取得平衡。然而，多數使用者並不會回頭審視自己過去寫過的 prompt，因此錯誤的句式與不夠精煉的詞彙便不斷重複出現。&lt;code>polish-prompt&lt;/code> 即是為了解決這個盲點而設計的個人化專案。&lt;/p>
&lt;p>本專案的核心問題為：能否以最低耦合的 Shell 工具鏈，將個人累積的 prompt 視為一個小型「寫作語料庫」，並由 LLM 以英語寫作教師（English-writing teacher）的身分週期性地產出回顧報告，協助使用者察覺自身英語寫作的系統性缺陷與成長軌跡。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>系統採用以 Shell 為主要黏合劑的最小化架構：使用者每日於工作流中輸入的 prompt 透過 hooks 或排程任務寫入一個輕量資料庫（SQLite 或同等檔案型儲存），形成可被查詢的歷史紀錄。每小時排程器會取出新近 prompt，組裝為附帶上下文的批次請求，傳遞給設定為「英文寫作教師」角色的 LLM，要求其輸出可讀性高的批改報告。&lt;/p>
&lt;p>報告內容遵循固定模板，包含：本批次 prompt 的常見語法錯誤、可改寫的更精準表達、語氣（tone）與正式程度的一致性問題、以及推薦的替代句構。Shell 腳本負責處理檔案 I/O、API 重試與失敗回退，並將輸出統一存放在便於 grep 與 diff 的純文字檔，以利長期追蹤。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>由於 prompt 在累積一段時間後，其文字量已可比擬中等規模的個人寫作集，本系統能在不需手動標註的情況下自動產出語言學習報告。Shell 為主的設計可在任何 macOS 與 Linux 環境執行，且資料完全留在本機，符合作為個人化學習工具的隱私需求。專案目前以私有 repo 形式維護，並持續疊代回饋訊息的訊噪比。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案展示了「prompt 即文本」的觀念：將原本被視為一次性產物的 prompt 升格為值得被批改的寫作素材，能讓非英語母語使用者在不額外付出時間的前提下，獲得連續性的英語寫作訓練。其限制在於批改品質高度取決於 LLM 模型版本與系統提示的工程，且 prompt 的領域過於狹窄時可能導致建議重複。未來可加入錯誤分類分布的視覺化、與更細緻的時間序列分析以呈現語言能力的長期趨勢。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/polish-prompt">htlin222/polish-prompt&lt;/a>&lt;/li>
&lt;li>主要語言：Shell&lt;/li>
&lt;li>最後更新：2026-05-09&lt;/li>
&lt;/ul></description></item><item><title>Mail：個人化郵件處理工具之 TypeScript 實作</title><link>/blog/mail-2026-05-04/</link><pubDate>Mon, 04 May 2026 00:00:00 +0000</pubDate><guid>/blog/mail-2026-05-04/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>郵件仍是學術與行政溝通的核心管道，但個人收件匣的雜訊比急速攀升，重要訊息常被淹沒。商用郵件分類工具雖多，但缺乏針對醫療研究情境的客製能力，例如自動辨識期刊投稿狀態、研究合作邀約或臨床試驗 IRB 文件。本專案為個人探索性質的 Mail 處理腳手架，目標是建立可被 LLM 整合的可程式化收件匣。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>採用 TypeScript 作為主要語言，理由有二：一方面 TypeScript 在處理現代 IMAP／OAuth／Webhook 等網路協定上具備成熟生態系，另一方面便於與其他以 TS 撰寫的 LINE Bot、Cloudflare Workers 工具共用型別與資料結構。專案以模組化方式拆分郵件擷取、分類規則、LLM 介接與動作（標記、轉寄、回覆）等子系統，皆預留可被 MCP 或 Claude Skill 呼叫的 API 邊界。&lt;/p>
&lt;p>由於屬於個人實驗性質，目前優先確保「可在本地運行的最小可行版本」，再依需求擴充至遠端排程與多帳號支援。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>目前已完成基本的郵件擷取與標記實驗，並驗證 TypeScript 在處理跨服務 API 上的可行性。雖尚未穩定到日常依賴，但已能就特定收件人或主題自動產生整理摘要，作為通勤時間瀏覽的素材。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案的價值在於把郵件視為「可被程式化處理的事件流」，而非僅是顯示介面。限制方面，郵件內容涉及他人隱私與敏感醫療資訊，必須謹慎設計儲存與處理界線；OAuth 設定與長期憑證管理亦須投入額外時間。未來方向包括：與既有 LINE Bot、Telegram Bot 整合形成統一通知中心、加入 LLM 摘要與優先序評估。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/Mail">htlin222/Mail&lt;/a>&lt;/li>
&lt;li>主要語言：TypeScript&lt;/li>
&lt;li>最後更新：2026-05-04&lt;/li>
&lt;/ul></description></item><item><title>owa-sync：Outlook Web Access 個人同步工具的私有 Python 實驗</title><link>/blog/owa-sync-2026-04-24/</link><pubDate>Fri, 24 Apr 2026 00:00:00 +0000</pubDate><guid>/blog/owa-sync-2026-04-24/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>許多醫療機構仍以 Microsoft Outlook 作為內部通訊主要工具，而 Outlook Web Access（OWA）為遠端存取的標準介面。然而 OWA 本身與個人化生產力工具（筆記、任務管理、AI 助手）的整合度有限：使用者無法以程式化方式擷取郵件至個人系統，導致工作流斷裂。本專案探索如何在不破壞機構規範的前提下，將 OWA 中與個人相關的郵件同步至自有平台。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>實作以 Python 為主，採用標準 IMAP 或 OWA 公開 API（依機構政策）擷取郵件。架構上拆分為擷取、轉換與寫入三個階段：擷取階段負責認證、分頁與差異同步；轉換階段將郵件結構化（主題、寄件者、時間、附件 metadata）；寫入階段將結構化結果輸出至本地資料庫或檔案，供後續工具串接。&lt;/p>
&lt;p>由於牽涉機構帳號，專案刻意避開儲存敏感內容，僅同步必要的 metadata 與使用者明確標記的訊息。Python 在處理跨平台檔案 I/O 與後續資料分析上具備成熟生態，便於與其他研究／個人工具串接。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>目前已完成基本擷取與本地落地的概念驗證，可作為其他自動化工具（例如 LINE Bot 通知整合、Anki 卡片生成）的上游資料源。對於每天面對海量機構郵件的醫師而言，這提供了一個可程式化過濾與後處理的入口。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案最大的價值在於協助個人在機構限制下重新取得對自己訊息流的控制權。限制方面，機構政策、雙因素認證與郵件保留期限皆可能影響可實現程度；任何同步機制都必須謹慎處理隱私與資安。未來可加入 LLM 摘要、依寄件人優先排序，以及與既有 calendar／任務系統的雙向同步。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/owa-sync">htlin222/owa-sync&lt;/a>&lt;/li>
&lt;li>主要語言：Python&lt;/li>
&lt;li>最後更新：2026-04-24&lt;/li>
&lt;/ul></description></item><item><title>breast-cancer-uptodate：以 OpenEvidence、OncDaily、OncLive 與 ESMO 自動產出每週乳癌治療趨勢報告</title><link>/blog/breast-cancer-uptodate-2026-04-19/</link><pubDate>Sun, 19 Apr 2026 00:00:00 +0000</pubDate><guid>/blog/breast-cancer-uptodate-2026-04-19/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>乳癌治療領域進展極快，從 HER2 低表現的新藥（如 trastuzumab deruxtecan）、CDK4/6 抑制劑於早期治療的角色，到免疫治療與抗體藥物複合體（ADC）的試驗結果，每週都有可能改變臨床實務的訊息。然而臨床醫師難以每週手動瀏覽所有來源並整理趨勢。本專案以自動化方式定期蒐集 OpenEvidence、OncDaily、OncLive 與 ESMO 等可信來源的乳癌治療新訊，產出可被快速消化的趨勢報告。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>系統以 Python 為主，於每週固定時間執行排程任務：依關鍵字與日期過濾從各來源擷取最近一週的乳癌相關內容，並以 LLM 進行摘要、分類與重要性判定。輸出採用結構化 Markdown，包含「重要試驗」、「指引更新」、「FDA／EMA 動態」、「會議摘要」等固定欄位，使讀者能在固定模板下快速比較不同週次。&lt;/p>
&lt;p>設計重點在於來源透明：每筆摘要皆附原始連結與發布日期；任何由 LLM 生成的詮釋皆與原文嚴格區分。執行紀錄留存於版本控制中，使後續可回溯任一週的原始素材。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>每週報告構成一份個人化乳癌治療趨勢電子報，可由作者本人優先閱讀，亦可作為與住院醫師或 fellow 教學討論的素材。對於非專責乳癌但需偶爾接觸該疾病的內科醫師，此報告提供低成本的「跟上腳步」方式。長期累積的報告亦能作為文獻檢索的補充索引。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案實踐了「以自動化補足注意力有限」的概念：當資訊過量時，重點不在於讀更多，而在於有結構地讀少而對。限制方面，自動摘要可能漏掉超出關鍵字過濾範圍的重要訊息；LLM 對某些臨床細節的詮釋仍需人工把關。未來可加入個人化偏好（例如更關注 HER2 低表現或 BRCA 突變子群），並結合 RSS 訂閱整合至既有閱讀流程。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/breast-cancer-uptodate">htlin222/breast-cancer-uptodate&lt;/a>&lt;/li>
&lt;li>主要語言：Python&lt;/li>
&lt;li>最後更新：2026-04-19&lt;/li>
&lt;/ul></description></item><item><title>gh-repo-father-skill：從原始想法到完整 GitHub Repo 的腳手架 Skill</title><link>/blog/gh-repo-father-skill-2026-04-05/</link><pubDate>Sun, 05 Apr 2026 00:00:00 +0000</pubDate><guid>/blog/gh-repo-father-skill-2026-04-05/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>每個工程師都熟悉「想到一個點子，但被開新 repo 的繁瑣步驟拖延」的經驗：建立 README、選擇授權、設定 .gitignore、搭好基本結構、推上 GitHub。這些步驟雖簡單但累人，讓無數初始概念在尚未誕生前便被耗盡熱情。本 Skill 將「從一個想法到一個可用的 GitHub repo」全流程自動化，使工程師能將注意力放在實作而非設定。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>Skill 接收使用者以自然語言描述的專案構想，自動完成：建立合理 repo 名稱、語言對應的 .gitignore、適合的開源授權、起手式 README、基礎目錄結構與 CI 範本。並透過 GitHub API（或 &lt;code>gh&lt;/code> CLI）將本地專案推上 GitHub，產生可分享連結。整體採漸進式載入，安裝以 &lt;code>npx skills add htlin222/gh-repo-father-skill&lt;/code> 完成。&lt;/p>
&lt;p>設計重點為「結構合理勝於完整」：產出的 scaffold 並非萬能，而是「對該語言／領域常見的最佳起點」，使開發者能立即開始撰寫核心邏輯，而非被基礎建設綁住。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>使用者可在數分鐘內從一個構想得到可上手的 repo，與此同時 README、授權、結構皆已就位，避免日後重構基礎設施。對於高頻創建小工具的個人工程師（例如作者本人三個月內超過七十個 repo），本 Skill 顯著降低啟動成本，使「想到就動手」成為日常習慣。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案展現了「將開發者高頻儀式化任務交給 AI」的應用方向。其貢獻在於把零散的開機器步驟以一個 Skill 模組化。限制方面，產生的 scaffold 仍需人工調整以符合特定團隊規範；過度依賴自動化也可能弱化開發者對基礎設置的理解。未來可加入針對醫療研究 repo 的特化模板（如 IRB 文件、資料字典範本），並支援多種雲端平台的 secret 預設。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/gh-repo-father-skill">htlin222/gh-repo-father-skill&lt;/a>&lt;/li>
&lt;li>主要語言：Skill&lt;/li>
&lt;li>最後更新：2026-04-05&lt;/li>
&lt;/ul></description></item><item><title>prisma-automation：以 Python 與 R 自動化 PRISMA 系統性回顧工作流</title><link>/blog/prisma-automation-2026-03-28/</link><pubDate>Sat, 28 Mar 2026 00:00:00 +0000</pubDate><guid>/blog/prisma-automation-2026-03-28/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>PRISMA 為系統性回顧與 Meta 分析的標準報告框架，要求研究者透明展示每一步研究納入與排除的數量。傳統工作流以多個工具（Endnote、Excel、Covidence、RevMan）拼接，容易出現步驟之間的計數不一致。本專案以開源工具鏈將完整 PRISMA 工作流以程式化方式串起，從文獻搜尋、篩選、去重到流程圖自動產生，保障報告數字與實際操作完全對應。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>工作流以 Python 與 R 雙語言實作：Python 處理 API 介接（PubMed、Scopus、Web of Science）與機器學習篩選；R 處理統計合成與作圖。文獻去重採基於 DOI／PMID 的精確比對，搭配標題模糊比對作為補充。標題摘要篩選可選擇人工或 LLM 輔助，所有判斷紀錄留存。最終以 &lt;code>flowdoc&lt;/code> 等工具自動產出 PRISMA 流程圖，保證流程圖數字與資料一致。&lt;/p>
&lt;p>設計重點為「可審計性」：每個篩選決策皆可被追溯至原始紀錄，使審稿人或讀者能驗證計數正確。整體流程以 Make／Snakemake 等任務管理工具編排，便於部分重跑而不需重新處理整個工作流。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>研究團隊可顯著減少 PRISMA 報告的人工負擔：原需多人協作數週完成的搜尋與篩選工作，得以縮短為數天並提升一致性。對於同時進行多個系統性回顧的研究團隊，此自動化工具大幅提升整體產能。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案實踐了「以程式化保證透明度」的觀念：當每一步都是可重現的程式碼，PRISMA 對於透明度的要求自然得到滿足。限制方面，自動化篩選的決策需要謹慎驗證，特別是高風險偏誤的情境；不同資料庫的搜尋語法差異仍需手動橋接。未來可整合至 &lt;code>meta-pipe&lt;/code> 主管線，並加入 LLM 進行偏倚評估的初步建議。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/prisma-automation">htlin222/prisma-automation&lt;/a>&lt;/li>
&lt;li>主要語言：Python（搭配 R）&lt;/li>
&lt;li>最後更新：2026-03-28&lt;/li>
&lt;/ul></description></item><item><title>batch-download-hiroka：批次下載資源的 Python 私有工具</title><link>/blog/batch-download-hiroka-2026-03-12/</link><pubDate>Thu, 12 Mar 2026 00:00:00 +0000</pubDate><guid>/blog/batch-download-hiroka-2026-03-12/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>研究與教學工作中經常需要下載大量檔案：論文 PDF、課程影片、指引手冊、衛教素材等。手動下載不僅耗時，亦容易因步驟不一致而產生重複或缺漏。對於高頻擷取資料的研究者，自製批次下載工具是值得投資的個人基礎建設。本專案即為作者用於特定資料來源的下載自動化腳手架。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>實作以 Python 為主，採用 &lt;code>requests&lt;/code>、&lt;code>httpx&lt;/code> 等標準函式庫處理 HTTP 請求，搭配 &lt;code>tqdm&lt;/code> 提供進度顯示。設計上將「列表擷取」與「個別檔案下載」解耦：先取得需下載的清單與 metadata，再進入下載階段。下載階段支援續傳、平行化、與基本錯誤重試。所有下載紀錄存於本地 SQLite，避免重複擷取相同檔案。&lt;/p>
&lt;p>工具刻意保持私有，因為某些下載對象的 ToS 限制其再分發；公開化需要謹慎處理。整體保持輕量，便於應用於不同來源時快速調整。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>工具已能於背景處理大量下載任務，使作者得以將注意力放在資料分析而非檔案搬運。對於需要週期性更新本地素材庫（如 NCCN 指引、ESMO 簡報）的研究者，這顯著降低人工成本。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案實踐了「將重複行為自動化」的個人生產力原則。限制方面，下載工具高度依賴目標網站的 HTML 結構，遇到改版便可能失效；同時需要謹守機構與來源的使用條款。未來可加入 LLM 輔助解析網頁結構、結合內容摘要自動篩選真正需要下載的檔案。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/batch-download-hiroka">htlin222/batch-download-hiroka&lt;/a>&lt;/li>
&lt;li>主要語言：Python&lt;/li>
&lt;li>最後更新：2026-03-12&lt;/li>
&lt;/ul></description></item><item><title>teamplus-api：探索 Teamplus 對外 API 整合的 Python 私有專案</title><link>/blog/teamplus-api-2026-03-08/</link><pubDate>Sun, 08 Mar 2026 00:00:00 +0000</pubDate><guid>/blog/teamplus-api-2026-03-08/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>Teamplus 為許多醫療機構採用的內部協作平台，提供訊息、會議與檔案分享。然而其與個人化工作流的整合仍仰賴使用者手動切換，未能享受 API 化帶來的自動化潛力。本專案即為作者探索 Teamplus API 介接的私有實驗倉庫，目標是建立一個可被個人 AI 助手（如 Claude Code）呼叫的 API 包裝層。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>實作以 Python 為主，依 Teamplus 公開 API 文件（或反向工程）封裝常用功能：取得對話列表、發送訊息、上傳／下載檔案、查詢成員資訊。所有呼叫以結構化函式提供，便於後續被其他工具串接。認證採 OAuth 或 API Token 視機構政策而定，憑證透過環境變數而非硬編碼方式管理。&lt;/p>
&lt;p>設計上遵循「最小驚訝原則」：函式命名與參數盡量符合直覺，回傳值結構與其他 messaging API（Telegram、LINE）保持類似，方便跨平台搬遷。私有狀態使其能保留機構專屬細節而不影響其他人。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>倉庫提供作者個人在 Teamplus 與其他工作流（任務管理、會議備忘、檔案歸檔）之間的橋樑。例如可在 Claude Code 中以對話方式查詢 Teamplus 上的某段討論並自動產出摘要，或將特定群組訊息歸檔至個人筆記系統。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案展現了「打通機構工具與個人工作流」的工程實踐。限制方面，機構政策可能限制 API 使用；API 變動需持續維護；資料隱私必須謹慎處理，避免誤將敏感訊息留存於不適當位置。未來可加入 LLM 自動分類訊息重要性、與 Notion／Obsidian 同步特定討論串、以及行動端整合。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/teamplus-api">htlin222/teamplus-api&lt;/a>&lt;/li>
&lt;li>主要語言：Python&lt;/li>
&lt;li>最後更新：2026-03-08&lt;/li>
&lt;/ul></description></item></channel></rss>