AI學習

用日期累積自己的 AI 學習歷程，把每天真的有吸收的觀念、實作心得和值得回看的連結整理下來。

#AI學習 #每日紀錄 #持續更新

這裡會用日期持續記錄我的 AI 學習歷程。 每一篇都只做兩件事：留下今天真正學到的重點，以及整理值得回頭再看的資源連結。

之後只要沿用同樣格式新增新的日期檔案，就能慢慢累積成自己的 AI 學習知識庫。

2026年
4月
2026/4/18

今日最有感的事

今天最有感的，不是 Claude 又多了一個新產品，而是這件事背後的方向越來越清楚了：AI 工具正在從單點能力，變成一條更完整的工作鏈。

今天收件匣最值得記的是 Claude Design。表面上它看起來像一個「用聊天做設計稿、原型、簡報」的工具，但真正有價值的，不只是它能不能快速生出好看的畫面，而是它開始站上了一個更關鍵的位置，也就是設計和實作之間的銜接層。今天整理內容裡有一句我覺得很準，Claude Design 不是單純畫圖工具，更像是 Claude Code 的前端設計前站。這句話其實點出了一個很大的變化。

以前很多 AI 工具都停在靈感階段，幫你想點子、畫個草圖、做個 mockup，但接下來要變成真正產品，往往還是要靠人手動重做一遍。現在開始不一樣了。如果一個工具能讀 design system、吃 GitHub repo、理解品牌資產，還能把設計確認後打包成 handoff bundle，交給 coding agent 繼續做，那它就不只是設計工具，而是進入了 workflow orchestration 的位置。也就是說，AI 的價值不再只是「幫你做一張圖」，而是「讓設計和開發之間的斷點變短」。

這對 Bear 這種有很多半產品化構想的人特別有感。像急專大補帖新頁面、dashboard、landing page、醫學學習工具 mockup，最卡的常常不是完全沒想法，而是腦中有方向，卻還沒進到可以交付給 coding agent 的清楚程度。Claude Design 這類工具的真正意義，就是把這段模糊區壓縮掉。

如果用急診比喻，它不像多請一個只會講理論的人，而比較像多了一個能先把病人整理好、把資料準備好、把接手條件整理清楚的前置系統。真正厲害的不是畫面本身，而是它開始讓下一棒更容易跑。

今日收集的資源

  • Claude Design 懶人包

  • 睡前丟題目，隔天早上收 AI paper 的 workflow

  • Roam 補充：Bear 的 AI 工作流正在往系統級工具鏈靠近

    • 連結: Roam daily note 2026-04-18
    • 一句說明：從 local AI、Gemini HATW 分析器、Roam research 匯出，到今天這類 Claude Design / Claude Code 接力概念，重點已經不是單工具，而是整條 AI 工作鏈怎麼串起來。
2026/4/6

今日最有感的事

今天收進來的幾個 AI 素材表面上很分散：有 Claude Code CLI 接法、Gemini 生圖、PersonaPlex 語音 agent，還有 Bear 直接在 Discord 裡測試 model 與 routing。但把它們放在一起看，核心其實是同一件事：現在真正拉開差距的，已經不是單一模型多厲害，而是你能不能把模型穩定接進自己的工作流。

最有感的是那張在討論 Claude 訂閱與第三方調用的圖。重點不是「找到漏洞把訂閱榨乾」，而是重新確認一個比較健康的方向：如果想把 Claude 放進 agent workflow，與其依賴灰色轉接，不如走官方 CLI／本機已登入工具，再由 OpenClaw 這類系統接起來。這個差別很像急診流程裡的「暫時有效」和「可長期維運」：前者也許一時能跑，但系統一忙、規則一改就垮；後者才是真的能留下來的基礎設施。

另外一條很有意思的線，是 Gemini 生圖和 PersonaPlex 這類新能力帶來的誘惑。看起來每個工具都很強，但 Bear 今天的實際脈絡反而提醒我：不是看到新模型就要追，而是先問它能不能進入現有系統、能不能被遠端控制、能不能在你的 Mac mini 上穩定運行、能不能跟 Discord / OpenClaw / cron 接起來。技術亮點很吸睛，但真正有複利的是 workflow integration。這也是今天最大的收穫：AI 工具不再只是「試玩」，而是在慢慢變成一套能持續工作的臨床級基礎設施。

今日收集的資源

2026/4/5

今日最有感的事

今天最有感的，不是單一新工具有多強，而是工作模式正在明顯換軌：從「我開口，AI 回答」變成「我給方向，AI 在背景持續跑」。Discord 收件匣今天累積的幾個案例，其實都指向同一個變化。Claude Cowork 的亮點不是它會總結，而是它能排程、自動蒐集資料、跨工作區整理脈絡，甚至把手機變成遠端 dispatch 入口；Claude Code 的 /insights 則讓 AI 不只幫你寫，而是回頭分析你過去一個月怎麼用它、卡在哪裡、該怎麼優化工作流；另一條線是 NanoBanana MCP，把圖片生成直接接進 Claude Code，等於把文字、流程、視覺都拉進同一個工作台。

這些看起來分散，其實核心是一樣的：AI 開始從「工具欄上的一個按鈕」變成「會接手流程的執行層」。這個轉變對急診工作的啟發很大。臨床上最耗腦力的，常常不是關鍵判斷本身，而是前面那些反覆蒐集、整理、交叉比對、確認有沒有漏掉的流程。就像 AIVR 不是任務完成，而只是提醒你血管可能還沒真正安全；AI 也是一樣，它最有價值的地方不是替你按一次按鈕，而是幫你把後面持續追蹤、整理、提醒的鏈條接起來。真正厲害的，不是 AI 回得快，而是它能不能讓你少做那些本來就不該由人腦反覆消耗的工。

今日收集的資源

  • Claude Cowork：一句話指揮電腦完成整段流程（王伯達觀點）

  • LLM Knowledge Base 四層架構（林穎俊）

  • Claude Code /insights 指令（林穎俊）

  • NanoBanana MCP：把 Gemini 生圖接進 Claude Code（Ci | AI 驅動開發）

  • Roam 今日反思：AIVR 不是任務完成，而是風險還在（Bear 今日筆記）

    • 來源: Roam Daily Note 2026-04-05
    • 重點：AIVR 可能只是 partial reperfusion，不代表真正安全；這種「不要把過渡訊號誤認為完成訊號」的判讀框架，也很適合拿來看 AI workflow —— 有自動化，不等於整個系統真的穩了。
2026/4/4

今日最有感的事

今天看到兩個很互補的觀點，放在一起讀，讓我想通了一件事。

林穎俊分享了一個簡單到不行的 workflow：手機背面點兩下 → 觸發捷徑 → 語音口述 → 自動存進 Apple 備忘錄。想整理的時候，Claude Code 再來幫你分類歸檔。

這個設計的精妙之處在於「消除 capture 的摩擦」——你腦子裡冒出一個想法的那一秒，不需要開 app、不需要找資料夾、不需要想分類。就說出來，先存著。

昨天讀 Karpathy 說的「用 LLM 操控知識」，這兩件事加起來，構成了一個完整的圖：

  1. 低摩擦 capture（Apple 備忘錄/語音）
  2. AI 整理歸檔（Claude Code / Roam）
  3. AI 維護連結（wiki、backlink、索引）

我現在的系統其實做到了 2 和 3，但在 1 這塊做得不夠好。我的 capture 端還是依賴手打、或是 Discord 收件匣，缺少一個「0秒存入」的管道。

另一個值得記下的是 Dustin 的 Claude Code 用量優化建議。他提到「切換模型會破壞 cache」、「閒置超過一小時會破壞 cache」、「貼圖也會破壞 cache」——這些剛好也是 OpenClaw 的注意事項。今天才剛把 contextPruning.ttl 從 1h 改成 2h，就是為了讓 cache 活過每小時的 heartbeat。

知識管理系統最終的目標不是「存得多」，而是「取得快，思得深」。

今日收集的資源

2026/4/3

今日最有感的事

Karpathy 說了一句話，讓我想了很久：

「我的 token 使用量，越來越多從『操控程式碼』轉移到『操控知識』。」

他把論文、文章、YouTube 逐字稿丟給 LLM，讓它自動整理成有內部連結的 wiki，以 Markdown + 圖片的形式儲存。知識的 index、backlink、概念文章，全部由 LLM 維護。

這聽起來很新，但我細想，我其實已經在做這件事了——只是工具不同。

Karpathy：Obsidian + Claude Code + GitHub
我：Roam Research + OpenClaw + Zotero + ECG 文獻

差別在於：Karpathy 的知識幾乎全由 AI 維護，而我是 Bear + AI 協作。我自己寫筆記、自己做 ECG 判讀、自己在 Roam 留下當下的思考，OpenClaw 負責整理、歸檔、連結。

這個 hybrid 模式，在醫學情境下反而比純 AI 代管更合適。因為臨床直覺、病人互動、邊際判斷——這些不能只靠語料，要有實際接觸病人的思考痕跡才算數。

另一個今天讓我大開眼界的是 Boris Cherny（Claude Code 負責人）的 15 個功能示範。他說他「大多數程式碼是說給 Claude 聽的，不是打字的」，然後讓幾十個 agent 在不同 git worktree 並行工作，自己在手機上用 /teleport 跨裝置監控進度。

這種工作方式，和我每天在急診做決策的模式很像——我不是要把所有事情都自己做，而是要在對的時間點做對的判斷，然後讓系統幫我執行細節。

AI 工具的本質，從來不是「幫你做你做不到的事」，而是「讓你專注在只有你能做的事上」。

今日收集的資源

2026/4/2

今日最有感的事

今天看到 OpenClaw 中文社群分享一篇貼文，講的是 AI 最大的硬傷：session 結束，記憶清空。他們花了幾個月建了三層架構來解決這個問題：Auto Memory（AI 自動累積）、CLAUDE.md（硬性行為準則）、Memory Files（主題式索引）。

看到這個，我第一個反應是：這不就是我現在用的系統嗎？AGENTS.md 就是行為準則，MEMORY.md + LanceDB 就是知識索引，架構上一模一樣。

但仔細想，缺口在 Auto Memory——我的 AI 助理還是太被動。任務完成了，如果我不主動說「把這個記下來」，它不會主動去存踩坑記錄。就像急診的 handover，再好的交班格式，如果住院醫師不主動說出沒寫進 chart 的細節，交班就是不完整的。

架構解決的是「記憶放哪裡」，但 Auto Memory 解決的是「什麼時候記」——後者才是真正的難題。

今日收集的資源

  • AI 最大的硬傷：Session 結束，記憶清空（OpenClaw 中文社群）
    • 連結：https://www.facebook.com/share/p/1CBrfQaCnZ/
    • 三層記憶架構實作分享，適合在用 Claude/OpenClaw 的開發者參考
3月
2026/3/31

今日最有感的事

Queen of Hearts 是目前公認最強的 AI ECG 判讀工具之一，但昨天在 Dr. Smith's ECG Blog 讀到一個案例，讓我重新思考它的侷限性。

一名 30 多歲男性，複雜多支冠狀動脈病變，同時有下壁、後壁、側壁三個區域 OMI 並存——Queen of Hearts 認出了後壁和側壁的問題，但漏掉了下壁 OMI。

這讓我想到：AI 工具的訓練邏輯，對「單一模式的最強訊號」最為敏感，面對多個 OMI 同時出現、互相掩蓋的複雜案例，整合判斷就會出現盲點。就像急診分診系統——抓得到最突出的問題，但「兩件事同時發生」的情境，人腦整合能力仍無可取代。

AI 是 co-pilot，不是機長。最大價值是降低「看漏了」的機率，但最終臨床決策，仍需人類整合判斷。

今日收集的資源

2026/3/30

今日最有感的事

今天看到一篇貼文，解釋了一個我一直沒想清楚的問題：為什麼 Claude Code 內建的 Web Search 抓不到 Instagram、TikTok、Reddit？

答案有三層：第一，這些平台在 robots.txt 明確禁止 AI 爬蟲；第二，IG 的貼文內容是頁面載入後才由 JavaScript 動態渲染的，Web Search 只看到空 HTML 殼；第三，X、TikTok 要登入才能看完整內容。

這讓我想到急診裡的「確認偏誤」——你用聽診器聽不到的東西，不代表不存在，是工具的限制，不是疾病的限制。Web Search 也一樣，不是 Claude 笨，是工具觸及不到那個地方。

解法是加裝 MCP Server，讓 Claude Code 改用 headless browser 渲染完整頁面。兩個主要選項：

Firecrawl：丟 URL 進去，吐出乾淨 Markdown，用 AI 理解頁面結構而不靠 CSS selector，網站改版也不會壞。適合讓 AI 做研究、讀文章。

Apify：15,000+ 現成爬蟲 Actor，IG profile、TikTok 資料、Google Maps 評論各有專屬工具。適合想抓結構化資料的場景。

這個發現讓我決定下週來試裝 Firecrawl MCP，看看能不能讓 Claude Code 直接幫我整理醫學文獻和新聞。

今日收集的資源

2026/3/29

今日最有感的事

今天同時看到兩則 FB 貼文，乍看無關，卻讓我想通了一件事。

林思翰分享了 Claude Code 的官方秘技速查表：CLAUDE.md 要控制在 200 行內、用 MUST/NEVER 語氣、Context 要主動管理。而王介立醫師則講了一個故事：他兒子問家裡的 Discord BOT「老爸的密碼是什麼」，BOT 說沒有。結果呢？密碼被 zip 起來，搜尋找不到，但看檔名就知道了。

這兩件事放在一起，給了我一個很清楚的認識：AI 的「不知道」和「不說」，是兩件完全不同的事。

Claude Code 秘技講的是如何讓 AI 正確工作——規則要精準、語氣要強、Context 要省。但王醫師的故事提醒我們，AI 的行為本質上受限於它被怎麼設計、被給了什麼資訊。BOT 說沒有密碼，是因為它沒搜到；但它也沒有說「我有看到一個可疑的 zip 檔叫做 passwords.zip」。

在急診，我們有一個概念叫做 anchoring bias——你認定了一個診斷，就不再主動尋找矛盾的證據。AI 也有類似的問題：它回答了你的問題，但沒有告訴你它沒回答到的部分。

所以不論是用 Claude Code 寫程式，還是把 AI 當家裡的 BOT，核心原則都一樣：不想被知道的事，不要告訴它。不知道它不知道什麼，才是最大的風險。

今日收集的資源

2026/3/28

今日最有感的事

今天的 ECG 學習有個有趣的「連環套」：昨天剛學了 T wave alternans 是 TdP 的前兆，今天 OpenClaw 立刻說：「這個觀念只講了一半。」

T wave alternans 不只出現在 QT prolongation 的情境。它有三種臨床面向：電解質異常 + QT 延長（最經典）、急性心肌缺血（STEMI 或高風險 ACS 的早期警示）、以及嚴重心臟結構問題（HF、心肌炎）。每個情境的處理優先順序完全不同。

第二個洞見更讓我震驚：PE 可以造成 STE。這不是一個罕見的 ECG 怪事——它有清楚的生理機制：大量 PE 導致右心壓力驟升，右心室擴張壓迫左心室（interventricular septal shift），加上右心室缺血，就可以在 V1–V3 出現 ST elevation。

這個陷阱的殺傷力在於：急診醫師看到胸痛 + V1-V3 STE，第一直覺是「這是 anterior STEMI，啟動 cath lab」——但如果是大量 PE，給抗凝可能救命，導管反而誤診。先看 context，再看 ECG。

今日收集的資源

  • T Wave Alternans 的三個臨床面向（Amal Mattu × OpenClaw 深度分析）

    • 連結：Bear 的 Roam #ECG觀念 筆記
    • 面向一：QT prolongation + TWA → TdP 即將發作（立刻 Mg + 移除誘因）
    • 面向二：急性缺血 + TWA → 心肌「電不穩定」，VF 風險升高（不等同 TdP，但同樣致命）
    • 面向三：重症心肌病 + TWA → 反映心室整體電不穩定性
    • ED 快速分辨：看 QTc 延長嗎？看有無胸痛缺血跡象？看病史有無心肌病？

  • PE 造成 STE 的機制（Amal Mattu ECG Tips × OpenClaw 延伸分析）

    • 連結：Bear 的 Roam #ECG觀念 筆記
    • 大量 PE → 肺動脈阻力升高 → RV 擴張 → 室間隔左移（septal shift）→ 右心缺血 → V1–V3 STE
    • 同時可見：S1Q3T3、右束支傳導阻滯（RBBB）、竇性心搏過速
    • 致命陷阱：胸痛 + V1-V3 STE ≠ 一定是前壁 STEMI；要整合 context（突發呼吸困難、低氧、DVT 病史）
    • 黃金法則：ECG 是工具，不是診斷。Clinical context 永遠先於 ECG pattern
2026/3/27

今日最有感的事

今天沒有刻意去「學 AI」，但 AI 在幫我「學急診」。

這幾個月我在 Roam 裡默默積累了大量 ECG 觀念筆記——但那些筆記都是零碎的，像是從不同地方撿回來的碎片。今天 OpenClaw 把其中幾個觀念「重新組裝」了，補上了我沒想到的角度。

最有感的是這個認知：V1/V2 Lead Misplacement 不是技術問題，是診斷問題。 我知道 V1/V2 放太高會讓 ECG 出現假象，但我從來沒有把它連結到「風險最高的病患，往往 ECG 品質最差」這個系統性矛盾。躁動的老人、焦慮的胸痛病患——護理師貼電極時最難貼準，而這些人又是最需要準確 ECG 的人。

AI 的價值不是告訴我「要檢查 V1/V2 位置」（我已經知道了），而是幫我把這件事的臨床重量放大——讓我從「知道」進化到「會主動去核查」。

這就是我想用 AI 做的事：不是讓 AI 替我思考，而是讓 AI 幫我把自己的思考推得更深一點。

今日收集的資源

  • V1/V2 Lead Misplacement 與 Posterior OMI（OpenClaw ECG洞見）

    • 來源：Bear 的 Roam ECG筆記 × OpenClaw 深度分析
    • 核心：電極位置可以靜悄悄地抹去 posterior OMI 最脆弱的 reciprocal STD 訊號

  • Serial ECG 必須搭配胸痛時間軸（Ken Grauer PEARL）

    • 來源：ECG Tips #ECG觀念 × OpenClaw 延伸分析
    • 核心：每張 ECG 上應標注「CP NRS ___/10, HH:MM」，否則動態監控等於靜態快照

  • AIVR = Reperfusion 的掌聲，更是 Re-occlusion 的警告（Amal Mattu）

    • 來源：ECG Tips × OpenClaw 延伸分析
    • 核心：看到 AIVR → 立刻 call CV man，不是「看看就好」

  • Low Voltage + Tachycardia = 心包積液直到 Echo 排除（LITFL Key Teaching）

    • 來源：ECG Key Teaching Points × OpenClaw 延伸分析
    • 核心：Electrical alternans 出現代表太晚了；low voltage + tachy 才是觸發點
    • 致命陷阱：誤診 PE 給抗凝 → 出血性心包壓塞
2026/3/26

今日最有感的事

今天有兩個學習主線：一個是 Amal Mattu 的 T wave alternans 警句，一個是 SCCM 2026 的 ICU 重磅研究整理。

最有感的是 T wave alternans（TWA）的那一條認知升級路線。

我知道「TWA 是 TdP 的前奏」，但今天 OpenClaw 把這件事拆解成三個急診最常 miss 的情境，讓我意識到：我以前「知道」TWA，但不一定「會辨識」TWA。

最危險的認知陷阱是把 TWA 看成 artifact。特別是急診躁動的病患，ECG 本來就有點亂——T wave 忽大忽小很容易被當成「電極接觸不良」。但 TWA 是有規律的 beat-to-beat pattern，不是隨機漂移。

10 秒逐拍看 rhythm strip 的 T wave，可能是救命的 10 秒。

今日收集的資源

  • T wave alternans 機制與臨床意義（Amal Mattu × OpenClaw 深度分析）

    • 連結：Bear 的 Roam #ECG觀念 筆記
    • TWA = 心室復極不均勻性（repolarization heterogeneity）急劇增加的外在表現
    • 看到 QTc 延長時，多做一步：scroll rhythm strip，逐拍確認 T wave 振幅有無交替
    • 發現 TWA → Mg 2g IV push + 心律監護 + 移除誘因（藥物/電解質）

  • 右位心 vs Lead 貼錯——鑑別要點（@jymalva IG × ECG 教學）

    • 連結：https://www.instagram.com/p/DWVM7zNGF9X/
    • 看到奇怪的 ECG 先別慌：可能是 Dextrocardia，也可能只是 Lead 貼錯位置 😂
    • 口訣：看圖前先確認 lead 有沒有貼對！

  • SCCM 2026 ICU 重點更新（Chien Hua Tseng FB 貼文整理）

    • AKI in ICU：Sodium Bicarbonate（BICARICU-2, JAMA 2025）— AKI 救治新進展
    • RSI 插管：Etomidate vs Ketamine → 死亡率無差，但 etomidate 減少 cardiovascular collapse（17% vs 22%）；標準做法：Etomidate + Succinylcholine 1mg/kg
    • ARDS：Driving pressure 目標 <15 cmH₂O；長時間 Recruitment Maneuver（>35cmH₂O >1min）增加死亡率，不應使用（JAMA 2017）
2026/3/25

今日最有感的事

急診讀 ECG 的視線，幾乎所有人都從 II、III、aVF 開始，然後掃 V1–V6——aVR 幾乎永遠排最後，甚至完全被忽略。

今天 OpenClaw 幫我整理了這個盲點的臨床重量：aVR 的 ST elevation 是目前臨床上最容易識別左主幹閉塞（LM occlusion）和三支病變（3-vessel disease）的 ECG 線索之一。

最有感的認知轉換是這個：我以前知道「廣泛 ST depression 要注意左主幹」，但從來沒有把它內化成一個主動的視覺搜尋習慣——「看到廣泛 ST depression，立刻往 aVR 看」。

AI 的價值不是告訴我新知識，而是把我已知的知識組裝成可以在臨床現場觸發的思維框架。aVR 是急診 ECG 的「後視鏡」——大多數人開車不看後視鏡，直到有東西從後面撞上來。在 ECG 判讀上也一樣：不看 aVR，你會漏掉最凶險的那一種。

今日收集的資源

  • aVR ST elevation 的生理學與臨床意義（OpenClaw ECG 洞見 × Bear 的 Roam ECG 筆記）

    • 連結：Bear 的 Roam #ECG觀念 筆記
    • aVR 面向右心室流出道與室間隔基底部，ST elevation 代表廣泛心內膜下缺血或左主幹/三支病變

  • 實戰思維框架：看到「廣泛 ST depression」時立刻看 aVR（OpenClaw 深度分析）

    • 廣泛 ST depression（≥6 leads）+ aVR ST elevation ≥1mm → 高度懷疑 LM occlusion 或 3-vessel disease
    • 這個 pattern 不等同 STEMI，但死亡率可能更高，需要緊急心導管評估

  • Serial ECG 必須搭配胸痛時間軸（Ken Grauer PEARL × OpenClaw 延伸分析）

    • 每張 ECG 上應標注「CP NRS ___/10, HH:MM」，否則動態監控等於靜態快照
    • 核心：疼痛嚴重程度與 ECG 變化的時序關係，是判斷 re-occlusion 或 reperfusion 的關鍵
2026/3/24

今日最有感的事

王介立醫師說「資料庫不放 PDF」這句話，是整個工作流的核心。

急診有個概念叫 "clear the queue"——別讓病人在走廊上積著，要把每個人分流到對的地方。PDF 也是一樣，它是「原始資料」，不是「可查詢知識」。進庫前要先轉換：MinerU 是分診台，Claude 是主治醫師，Zotero 是病歷室。PDF 在這個流水線裡只是暫時停留的原料，不是終點。

這個思路讓我想到今天自己動手做的事：把 IG reel 自動存到 YouTube。看起來是兩件不相關的事，但背後邏輯一樣——把「零散散落在網路各處的內容」轉成「我的知識庫可以管理的格式」。IG reel 是原料，YouTube 不公開收藏是倉庫，之後再加上 AI 摘要就完整了。

OAuth 踩了幾個坑：PKCE mismatch（gws client_secret 預設帶 code_challenge，但手動 server 接不住）、帳號選錯（誤選品牌帳號熊簡單之家而非主帳號曹建雄）。但一旦跑通就是全自動——下次只要說「存到 YouTube」，skill 就知道怎麼做了。

今日收集的資源

  • MinerU（王介立醫師推薦）

  • ig-to-youtube skill（自建）

    • 連結: ~/.openclaw/workspace/skills/ig-to-youtube/SKILL.md
    • yt-dlp 下載任意社群媒體影片 + YouTube Data API v3 上傳，含完整 OAuth 流程與踩坑記錄
2026/3/23

今日最有感的事

今天 AI 幫我延伸了一個我已經知道、但沒有完整想透的觀念。

我原本對 T wave alternans（TWA）的認知是：「這是 QT prolong 病患在跳 TdP 前的警告信號。」這個框架沒有錯，但它在我腦中已經變成一個自動觸發的條件反射——只有在 QT 延長的時候才會主動尋找 TWA。

但有一個被嚴重低估的臨床事實：急性心肌缺血——特別是 OMI——本身就能直接誘發 TWA，而且跟 QT 長短完全無關。

機轉並不複雜：缺血心肌的復極化每一跳都在不穩定的灌流下完成，相鄰心肌的 action potential duration 於是出現交替性差異，ECG 上就看到 T wave 形態逐跳改變。文獻（Nearing & Verrier, JACC 2002）甚至指出這比 QT 延長更早出現，是 ventricular fibrillation 的直接前兆。

最危險的地方在於：當這個病患 QT 正常，我的大腦會自動說「這是 noise」。但如果他同時有胸痛、subtle ST 變化、缺血病史——這個 TWA 可能正在告訴我他快撐不住了。

更麻煩的是：monitor 的 smoothing algorithm 會把 TWA 消掉，只有在 12-lead 仔細比較相鄰 QRS 才看得出來。

以後遇到懷疑 OMI 的病患，看 serial ECG 時，我會額外做一件事：比較同一 lead 的相鄰兩個 T wave，看有沒有高-低-高-低的逐跳交替。即使 QT 正常，只要有這個 pattern，就要高度警覺、持續 monitor、準備除顫。

今日收集的資源

  • 每日 ECG 深思 | AI 洞見筆記（OpenClaw AI 補充）
    • 來源：Roam Daily Notes 2026-03-23
    • T wave alternans × 急性缺血的完整機轉解析
  • 原始觀念來源：Amal Mattu
    • T wave alternans 為 TdP 前奏的經典提醒
    • 參考：Nearing & Verrier, JACC 2002
2026/3/22

今日最有感的事

今天看到兩件事，講的其實是同一個道理：連續性（continuity）有多重要。

張維峰的貼文在介紹 Claude Cowork 新的 Projects 功能。他用了一個很貼切的比喻：舊的 Folder 是「檔案櫃」，新的 Project 是「辦公室」。差別在哪？檔案櫃有資料，但助理每天早上來上班都忘記昨天在做什麼。辦公室裡有白板（記憶）、行事曆（排程）、牆上的工作說明（自訂指令），每次走進來所有東西都還在原位。

這個比喻讓我想到急診的一個老問題。我們常說 Triage ECG 正常，但「正常」是什麼意思？是那一秒鐘的電氣活動正常。但病患主訴的是「過去 2 小時的胸痛」——那段時間內，冠脈可能已經閉了又通好幾次。我們用一個靜態快照，去評估一個動態的血流危機，這是根本性的時間謬誤。

AI 工具沒有記憶，就像一個助理每天失憶——你只會拿它做零散的事，不敢把完整的工作流程交給它。Triage ECG 只代表那一秒鐘，OMI 卻是幾小時的動態過程——你用那一秒判斷幾小時，就會漏掉危險。

連續性，不管是 AI 的還是臨床診斷的，都是從「偶爾有用」到「真正可靠」的關鍵門檻。

今日收集的資源

  • Claude Cowork 新增 Projects 功能整理（張維峰）

    • 連結：https://www.facebook.com/share/p/1GgUDjnUtS/
    • 說明：從 Folder 到 Project 的核心差異，包含跨對話記憶、排程任務、可從 Claude Chat 匯入

  • 每日 ECG 深思 AI 洞見（OpenClaw）

    • 來源：Roam 2026-03-22 每日筆記
    • 說明：Triage ECG 時間謬誤——靜態快照 vs 動態 OMI 血流危機
2026/3/21

今日最有感的事

今天看到林協霆（血液腫瘤科）分享他做的東西，讓我停了很久。

他建了一個完整的 全自動統合分析 pipeline——你只需要說一句話：「請幫我研究某某藥在某某病的影響，網路統合分析，不需要停下問我任何問題，請照著指引直到最後生成發表文獻。」然後去倒一杯咖啡。

架構很清楚：用 Claude Code + 自訂的多層 skill，每個環節（文獻搜尋、評讀、統計分析、R套件）都有對應的 skill，加上 CLAUDE.md 當 agent 的指揮手冊。容易幻覺的部分（DOI 驗證、文獻真實性）靠 API 補強。

這能直接投稿嗎？ 他說不行。但這讓我想到一個更實際的用途：快速驗證題目可行性。一個題目做不做得起來，文獻夠不夠多、方向對不對——以前要花幾週摸索，現在可能一個下午就知道答案。

另一個讓我印象深刻的細節：他說現在在試 Claude Code GitHub Action——直接 tag Claude 讓它發 PR。這讓「迭代」這件事從人工步驟變成自動化循環。

同一天，Claude Cowork 終於推出了專案功能。有趣的是，留言裡反應最一致的是：「已經在用 Claude Code 的人，大概不太需要 Cowork。」也許 Cowork 的定位就是「給還沒跨過 CLI 門檻的使用者的 Claude Code」。

今日收集的資源

  • 🔬 meta-pipe GitHub repo — 林協霆的全自動統合分析 pipeline，Claude Code + skill 架構，說一句話跑完 systematic review
  • 🧵 @startandkeep Threads 討論 — Claude Cowork 推出專案功能，有在用 Claude Code 的人覺得雞肋
2026/3/20

今日最有感的事

今天在 Facebook 看到王介立醫師（腎科，已驗證帳號）分享他的 AI 學習流程，讓我印象深刻——不是因為它多炫，而是因為它極度務實。

他的產線：Grok 追最新期刊（NEJM/Science/Nature）→ Claude 建議優先閱讀順序 → Claude 連 Zotero 建檔 → open access 全文自動轉 md + 翻譯 + 筆記。

他說省掉了 70% 的爬網和建檔時間。

這讓我想到兩件事：

1. 為什麼是 Grok？ 他明確說：「只有它能直接連上這些期刊官網，其他 AI 都卡住。」這是一個清醒的工具選擇——不是因為 Grok 最強，而是它在這個任務上有特定優勢（即時搜尋、可連期刊）。

2. 「管理員 agent」的概念 他留言補充說，他有一個固定視窗當「admin agent」，持續監控知識庫、接收其他 agent 報告、對系統做修正。這其實跟 Claude Code 今天教的「子代理架構」是同樣的概念——父代理只拿結論，子代理自己消化細節。

這兩個概念今天剛好撞在一起，感覺不是巧合。

今日收集的資源

2026/3/19

今日最有感的事

今天讀完 @minchunyen 的三個月 Claude 實戰紀錄，有一句話讓我印象深刻：

「真正的效率，來自於理解每個工具『做不到什麼』。」

這和我在急診的經驗很像。很多住院醫師拿到一個病人，直接衝上去用他最熟悉的那一招——就像 vibe coding 那樣，直接叫 AI 開始做，結果問題越滾越大。

@minchunyen 的故事更有說服力：他是電子工程師，不懂 Python。程式寫出來有 bug，一般人的做法是「把錯誤貼給 AI 叫它修」——結果越修越亂。

他的頓悟是：不需要看懂程式碼。只需要：

  1. 定義 Schema（這是正確的輸出格式，等同於「標準答案」）
  2. 指出哪裡錯了（JSON 裡哪個欄位對不上）
  3. 讓 Cowork 讀程式碼反推問題在哪裡
  4. 讓 Code 去修復

這不就是工程師的核心能力嗎？定義規格、驗收成果——中間的實作交給對的工具。

另外今天 @claude.world.taiwan 的 Claude Code 教學第三堂也很有共鳴：claude --plan 這個規劃模式的邏輯，其實就是「先讓 AI 把思路寫出來讓你看，確認沒問題再動手」。

在規劃階段抓住錯誤假設，比修改了 20 個檔案之後再回頭，代價差太多了。

Claude 三工具分工速查：

  • Chat（網頁版）：Deep Research、深度分析、設計規格 → 負責「想」
  • Cowork（桌面版）：直接讀寫本地檔案、跨檔案調查 → 負責「查 + 做」
  • Code（命令列版）：自主寫程式、測試、迭代修復 → 負責「程式」

今日收集的資源

2026/3/18

今日最有感的事

今天最密集的學習，是圍繞著 Claude Code Skills 這個主題，從多個角度來回確認同一件事：Skills 的本質不是一份文件，而是一個系統設計決策。

從 Anthropic 工程師 Thariq Shihipar 的原文，到 @oso_cy 在 Threads 的整理，到林穎俊的完整中文翻譯，同一篇文章被三個管道送到眼前。這不是偶然，這是訊號。

幾個讓我反覆思考的觀念：

1. Description 是觸發條件，不是摘要

Claude Code 啟動時會掃描所有 Skill 的 description 清單，來判斷「這個請求有沒有對應的 Skill？」這代表 description 的寫法根本是另一回事——它不是功能說明，而是 if-then 條件式。這個觀念完全改變了我對 OpenClaw Skills SKILL.md 應該怎麼寫 description 的理解。好的 description 讀起來更像「什麼情況下要用」，而不是「這個 Skill 做什麼」。

2. Gotchas 區塊是 Skill 的靈魂

最有價值的內容，往往不是「這個 Skill 做什麼」，而是「Claude 在用這個 Skill 時最常在哪裡犯錯」。這需要實際使用後持續更新，不是一次寫好就結束的東西。每一次 Claude 踩坑，都是 Skill 進化的機會。

3. Security by Permission，而非 Security by Restriction

Claude Code 的權限設計哲學也讓我印象深刻：不是把危險工具藏起來不讓 AI 看，而是公開所有工具但嚴格管控執行權。這樣 AI 才能看見全局做出正確的規劃，而不是在資訊不完整的狀況下靠猜。被拒絕時，AI 甚至能解釋意圖並主動請求授權——這和「把危險的東西藏起來」的思路是完全相反的邏輯。

4. MCP vs SKILL 的選擇框架

今天另一個清楚收穫是 @claude.world.taiwan 整理的三條路徑：有裝且有 CLI → SKILL+CLI；沒裝但有 API → SKILL+API；完全沒控制底層 → MCP。進階用法是兩層疊加：MCP 當感知入口（一行 JSON，隨插即用），SKILL 當邏輯編排層（組合流程、定義 SOP）。

5. NemoClaw：NVIDIA 解決了 agent workspace isolation 的問題

最後一個讓我眼睛一亮的是 NemoClaw——每個 Agent 被關在自己的 K3s Pod 沙箱，互看不見，所有 outbound 流量都過 L7 proxy，可以 ALLOW/DENY/REROUTE。這種設計把安全性從「信任模型本身不做壞事」移到「架構上隔離掉壞事的可能性」，更接近 Zero Trust 的思路。

這些概念放在一起，讓我對「怎麼設計一個讓 AI 穩定工作的系統」有了更完整的框架。不只是學怎麼用工具，而是開始理解這些工具背後的設計哲學。

今日收集的資源

2026/3/17

今日最有感的事

今天最有感的，不是某個模型又變強了，而是我更清楚看見：真正好用的 AI，不只是會回答問題，而是能進入我正在工作的上下文。

過去遇到 Facebook 這類平台時，AI 常常只能拿到 Open Graph metadata、部分摘要、或被登入牆擋住的殘缺資訊。這種情況下，AI 雖然「有在工作」，但離真正有用還差一大截。因為我看到的是全文，AI 看到的卻只是預覽卡片，兩邊處理的是不同世界。

今天的突破點在於：改用瀏覽器控制流程，讓 AI 不再只依賴 web_fetch、metadata 或一般爬取，而是透過已開啟的瀏覽器頁面與 snapshot，直接讀取頁面上實際渲染出來的內容。這件事的意義非常大。

它代表 AI 的能力，從「讀網頁」升級成「讀我眼前正在看的畫面」。差別在於：

  • 它可以接觸登入後內容，而不只公開頁面
  • 它可以處理 Facebook、社群平台、動態 JS 頁面這類一般抓取常失敗的場景
  • 它可以和我的實際工作流程銜接，而不是每次都從零開始開新 session

今天實測最有感的一幕，是原本只能抓到 Facebook 貼文前面一小段摘要；但改走瀏覽器 snapshot 後，就成功讀到洪惠風整理的 2026 ACC/AHA 血脂治療指引 10 個重點，包含：

  • 早期介入與生活型態轉型
  • PREVENT™ 風險評估公式
  • 初級預防門檻前移
  • 回歸 goal-directed therapy
  • ApoB / Lp(a) / CAC 的角色提升
  • 二級預防目標更嚴格（如 LDL-C <55 mg/dL）

這個經驗讓我重新確認：AI 的瓶頸很多時候不是推理能力，而是能不能拿到對的上下文。

如果上下文拿不到，再強的模型也只能在殘缺資訊上硬猜；但一旦上下文接上，AI 才真的能變成工作流裡的搭檔。

另一個今天很值得記下來的點，是我把這次成功流程進一步固化成 skill 規則：之後遇到 Facebook share/post link，不應太早停在 partial metadata，而要按順序升級：

  1. 先試 web_fetch / raw HTML / OG metadata
  2. 再試 yt-dlp
  3. 再試 cookies
  4. 不夠就直接走 browser path
  5. 若使用者已安裝 browser relay / attach-tab / CDP 類工具，就優先接 live tab

也就是說，今天不只是解決了一篇貼文，而是把一條未來可重複使用的「讀登入後網頁內容」工作流做出來了。

我覺得這種能力，未來不只可以用在 Facebook，也能延伸到：

  • 讀需要登入的教學平台內容
  • 讀 email / internal tools / GitHub private pages
  • 讀正在操作中的管理後台
  • 讓 AI 更貼近真實的人類工作桌面

如果說以前的 AI 像是在門外幫忙查資料，那今天比較像是：它終於被邀請進桌面旁邊一起看螢幕。

今日收集的資源

2026/3/16

今日最有感的事

今天最有感的，不是某一個模型又更強了，而是越來越清楚看到：AI agent 的競爭，正在從『誰比較會回答』，轉向『誰比較能穩定接上真實世界』。

這個「真實世界」有三層。

第一層，是 agent orchestration。像 Paperclip 這類工具在談的，不再是「怎麼做一個 agent」，而是「怎麼同時管理很多個 agent」，包括工作分派、預算控制、審計與持續運作。這代表單一 agent 已經逐漸商品化；真正困難的，不是做出 User → LLM → Tool 的 loop，而是把這個 loop 放進一個可治理、可追蹤、可長時間運轉的系統裡。

第二層，是 live environment access。像 chrome-cdp-skill 這類工具吸引人的地方，不只是能自動點按鈕，而是它能直接接到「你正在使用中的 Chrome」，沿用已登入 session、既有 cookies 與目前分頁狀態。這背後的意義很大：agent 不再只是在沙盒裡模擬工作，而是開始接手使用者真實的數位環境。這也解釋了為什麼 browser control 的價值，並不只是 screenshot 或 DOM，而是能否真正連上人的工作現場。

第三層，是 decision / execution split。今天看到一個很漂亮的思路：Claude 不直接控制 Gmail，而是先把判斷結果寫進 TSV 任務帳本，再交給另一個受控執行器去動作。這個架構讓我很有感，因為它代表成熟的 agent workflow 不一定追求「直接做」，而是追求「先把語意判斷轉成可稽核、可重播、可控管的結構化任務，再執行」。這其實更像 production mindset。

如果把今天的感想濃縮成一句話，那就是：

AI agent 的真正門檻，不再只是推理能力，而是怎麼安全、穩定、可治理地接管真實工作流。

Claude Code 生態今天爆紅的幾個 repo、Paperclip 的多 agent 管理、chrome-cdp 對 live Chrome 的接管、以及 TSV 中介帳本這種設計，表面上是不同主題，底層其實都在回答同一題：怎麼讓 AI 從 demo 走向真正可用。

今日收集的資源

2026/3/15

今日最有感的事

今天最有感的，不是 Claude 推出雙倍用量這個消息本身，而是一條看起來很簡單的優惠資訊，居然可以因為時區與 DST（夏令時間）而被整群人解讀反。

一開始看到社群上的說法時，直覺是興奮：平日晚間似乎是雙倍額度，週末也加倍，感覺只要下班後打開 Claude 就能一路用好用滿。但當我開始往下追來源時，發現問題根本不在消息真假，而在大家對「off-peak」的理解錯了。

官方說的是：在尖峰時段以外，使用量翻倍。這句話本身不難，但麻煩在於：

  1. 官方以美東時間描述尖峰時段
  2. 三月已進入 DST，時差不是平常直覺想的 13 小時，而是 12 小時
  3. 台灣使用者看到社群轉貼後，很容易直接把美國白天想像成自己的白天，結果整個算反

最後確認後，真正的台灣時間其實是：

  • 平日 02:00–20:00：翻倍
  • 平日 20:00–02:00：標準額度
  • 週末：全天翻倍
  • 活動期間：2026/3/13–2026/3/27

也就是說，所謂「下班後剛好雙倍」其實是錯的；相反地，真正賺到的是白天時段，尤其是可以在白天安排 Claude Code 工作流、批次處理任務的人。

這件事讓我今天最有感的一點是：AI 時代裡，真正的競爭力不是比誰先看到消息，而是比誰能把模糊消息整理成可執行、可驗證、可持續的工作規則。

如果只是轉貼優惠訊息，其實價值不高；真正有價值的是下面這整串流程：

  • 看見消息
  • 懷疑它可能有時區誤差
  • 追到更正貼文
  • 再追到官方說明
  • 完成時區換算
  • 最後把它變成提醒機制與可執行行動

這也是我今天重新被提醒的一件事：面對 AI 工具，不只要會用，還要會校正資訊。

因為只要時間算錯、條件看錯、活動範圍搞錯，再強的工具也只會把你帶往錯的方向。

今日收集的資源

  1. Facebook 社團貼文：最早看到 Claude Code 雙倍用量消息的來源之一
  2. Threads 更正貼文（kaiyen.dev）：指出前面把台灣時段算反，並補上更合理的換算
  3. Threads 官方整理貼文（claude.world.taiwan）：明確整理出台灣正確時段與 DST 重算結果
  4. Claude Help Center：Claude March 2026 usage promotion

今天的可執行結論

  • 平日若要最大化利用 Claude / Claude Code，白天 02:00–20:00 才是主戰場
  • 晚上 20:00 之後反而要更節制，因為那是標準額度
  • 週末可放心安排較重的工作量，因為是全天翻倍
  • 任何 AI 優惠、限額、API 變動消息，都不應只看二手社群貼文，應至少追到官方說明一次
2026/3/14

今日最有感的事

今天最有感的，不是單一功能更新，而是更清楚看到：AI 正在從「會回答問題的聊天工具」，變成「可以接進真實工作流的系統元件」。

這個感覺其實來自三條線同時出現。

第一條線，是 本機模型與 agent 工作流的接軌。今天看到有人分享，如何把 Claude Code 的後端改接到本機 LLM，透過 llama.cpp / llama-server 和環境變數，就能讓原本依賴雲端 API 的 coding workflow，改成更低成本、甚至接近免費的本地執行模式。這件事的意義不只是省錢，而是讓「大量 agentic loop」第一次變得更可長可久。當模型跑在本機，資料不離開裝置、試錯成本下降，很多原本覺得太貴或太重的自動化流程，突然就變得可行。

第二條線，是 Skills / 工具封裝正在成熟。官方 Claude Skills 建構指南之所以值得注意，不是因為它多了一本手冊，而是因為它意味著：AI 的價值不再只靠 prompt 靈感，而是能不能把常用任務整理成穩定、可重複、可交接的技能模組。這種轉變很重要。因為當工作流程可以被封裝，AI 就不只是每次被重新指揮，而是開始具有「在特定情境下，自動知道該怎麼做」的能力。

第三條線，是 結構化程式搜尋與改寫工具開始變得重要。ast-grep 這類工具讓人看到，未來真正好用的 agent，不只是會生成程式碼，還要能更精準地理解和操作既有 codebase。一般 grep 找的是字面文字，AST 工具找的是程式結構。這表示未來很多 refactor、codemod、規則化修改，都可以從「靠模型猜」進化成「模型規劃 + 結構工具精準執行」。對需要長期維護系統的人來說，這種差別非常大。

如果把這三條線放在一起看，就會發現一件事：AI 的下一步不是變得更像人，而是變得更像基礎設施。

它可以是寫筆記的助手、是封裝流程的 skill、是本機執行的 coding agent、也是精準改 code 的結構工具入口。這種變化最讓我在意的地方，不是「又多一個新功能」，而是它開始逼人重新思考：未來真正稀缺的能力，可能不是會不會問 AI，而是能不能把自己的工作方法拆解成一個 AI 能參與的系統。

而這又回頭連到醫學教學工作流。王介立醫師談的「如何用 Claude 寫醫學教學筆記」，本質上其實也是同一件事：AI 最有價值的地方，不是替你思考，而是把「閱讀英文資料 → 抽重點 → 轉成中文教學內容」這段重複又耗時的流程變得更順。從本機模型、skills，到 AST 工具，今天看到的其實都是同一個方向的不同切面：AI 正在變成工作流程的加速器，而不只是聊天視窗裡的一個回答者。

今日收集的資源

2026/3/13

今日最有感的事

今天最有感的，不是某個新模型多強，而是更清楚看到一件事：AI 的真正價值不是單次回答，而是把工作流程標準化、模組化，最後變成可以重複執行的 skill。

白天讀到數位敘事力期刊那篇談 skills / 技能包 的文章，裡面把 skill 講得很白話：它本質上就是一組指令集合，把偏好、流程、知識、工具使用方式封裝起來，讓 AI 知道「何時該用什麼方法完成什麼任務」。

這個概念跟我現在的使用場景其實非常接近。因為真正耗時間的，往往不是叫 AI 回一題，而是反覆交代：

  • 我要怎麼存 Roam
  • Google 日曆班表要怎麼命名、上色
  • Zotero note 要怎麼同步到 Roam citation page
  • Facebook 貼文要怎麼挖全文、怎麼整理

這些事情如果每次都重新講一次，就只是把 AI 當成比較聽話的聊天機器人；但如果能把它們變成固定 workflow，AI 才開始像真正的數位助理。

另外今天也回頭想到王介立醫師分享的 Claude 醫學筆記工作流。這篇的核心啟發是：AI 在醫學場景最有價值的地方，不是取代醫師判斷，而是加速「閱讀英文資料 → 整理重點 → 轉成中文教學筆記」這整段流程。

這和 skill 的概念剛好接起來。因為一篇篇資料整理，最後如果能抽象成固定步驟，就能從單次使用，升級成可以反覆執行的知識工廠。

對我來說，今天最大的收穫是更確定一件事：未來真正重要的能力，不只是會不會用 AI，而是能不能把自己的工作流程、判斷順序與知識轉譯方式，明確定義成 AI 可執行的系統。

如果這件事做好，AI 就不只是幫忙回答問題，而是能協助建立一整套穩定、可複製、可累積的知識生產流程。

今日收集的資源

2026/3/12

今日最有感的事

從工具使用升級到工作流設計：AI 真正的價值在於建立可持續運作的系統

今天最有感的一個共通主題，不是某一個單獨的新功能，而是好幾個案例都指向同一件事：AI 最強的地方，不是幫你做單次任務，而是幫你把重複性工作變成可持續運作的流程。

最有代表性的例子，是看到有人把 Claude + RSS + Zotero + Obsidian 串起來，建立半自動文獻學習系統。做法不是單純叫 AI 幫忙摘要 paper，而是先把自己的期刊 RSS feed 清單交給 AI，再把 Zotero 裡既有收錄的文獻一起給 AI 比對，讓 AI 反過來檢查目前的 RSS 架構是否有缺漏。結果文獻來源覆蓋率從 14% 提升到約 85%。這個案例真正厲害的地方，在於它不是讓 AI 替你「想」，而是先替你整理資訊流，讓新知可以穩定、持續地流進知識庫。

這個思路跟今天看到的 OpenClaw 進階教學其實高度一致。OpenClaw 影片裡講的 Persistent Agent、Sub-Agent、ACP Agent，表面上像是在比較不同 agent 類型，但更深一層看，它其實是在講：怎麼把任務拆對、把工具放對位置，讓整個系統更有效率。 長期角色用 Persistent Agent，短期平行任務用 Sub-Agent，需要外部 coding 工具就用 ACP 去橋接 Claude Code 或 Codex。重點從來不是「哪個模型最強」，而是怎麼做對 orchestration。

Firecrawl 也是同一類思維的代表。它的價值不只是在抓網頁，而是在把網站轉成 LLM-ready 的資料層：可以 crawl 整站、抽 markdown、抽結構化 JSON、處理動態頁面、做 batch 與變更監控。這代表未來真正有價值的，不只是聊天模型本身，而是誰能先把資料入口、清理、結構化、索引、引用這整條鏈串起來。只要資料層整理好，後面的 agent、RAG、知識問答、工作流自動化才有穩定基礎。

把這三個案例放在一起看，今天最大的體會是：AI 正在從「工具時代」進入「工作流時代」。 單點能力像摘要、翻譯、寫 code，已經逐漸不是稀缺資源；真正稀缺的是你能不能把資料源、知識庫、模板、排程、摘要、輸出格式整合成一條會自己跑的 pipeline。對醫療工作尤其如此，因為知識更新太快，靠意志力硬撐的學習系統很難久。未來比較有效率的方式，會是讓 AI 先幫忙完成來源整理、結構分類、摘要輸出與週期回顧，人只保留最後的判斷與整合。

從自己的需求來看，不管是急專考試、Roam 筆記、部落格寫作，甚至未來想做 Smith ECG 評論助手，本質上都在走向同一件事：把零散資訊變成可追蹤、可檢索、可引用、可持續更新的知識系統。

今日收集的資源

2026/3/11

今日最有感的事

Vibe Coding 做的網站，為什麼 Google 搜不到？

今天看到 Louis Lin 的一篇文章，講到一個很多人踩到的坑：用 Lovable、Replit、Bolt、v0 這些 Vibe Coding 工具做出來的網站，看起來很漂亮，但 Google 根本搜不到。

問題的核心在於 CSR（Client-side Rendering）vs SSR（Server-side Rendering）。

這些工具預設使用 React、Vue 等前端框架，採用 CSR 模式。你用瀏覽器打開，JavaScript 執行完就能看到完整頁面，一切正常。但 Google 的爬蟲拿到的是什麼？一個幾乎空白的 HTML 檔案，裡面只有 <div id="root"> 和一堆 JavaScript。爬蟲不會幫你執行 JavaScript，所以看到空白就走了。

Louis Lin 用了一個很好的比喻：CSR 就像寄一本空白書給 Google，附一支畫筆說「請自己畫」。SSR 則是寄一本已經寫好內容的書。

誰最容易中招？個人品牌創作者。用 Lovable 或 Bolt 做了漂亮的個人網站、作品集，覺得終於有了線上門面，但潛在客戶在 Google 上搜你的名字，什麼都找不到。

解法：

  • 用 SSR 框架：Next.js、Nuxt.js
  • 用 SSG（Static Site Generation）：Hugo、Astro
  • 或選擇支援 SSR 的平台如 Compassio

這讓我想到我自己的情況：部落格用 Hugo（SSG），完全沒這問題。急專大補帖 quiz app 用 React SPA，但它不需要 SEO（需要登入才能用），所以也沒差。但如果未來要做任何需要被搜尋到的東西，一定要選 SSR/SSG。

另一個有趣的觀察：這篇文章本質上也是在講「AI 工具的隱性成本」。Vibe Coding 降低了建站門檻，但使用者不知道自己犧牲了什麼。這跟醫療很像 — 看起來簡單的處置背後有很多需要理解的原理，不理解就會踩坑。

今日收集的資源

2026/3/10

今日最有感的事

Deep Research 多模型聯集工作流程

今天看到王介立醫師分享的一個很聰明的做法：同一個研究主題，同時丟給 ChatGPT、Gemini、Claude 三家做 Deep Research，然後把三份結果做「聯集」合併。

這個方法的核心洞見是：每個 AI 模型都有自己的知識盲區。ChatGPT 可能在某些領域特別強，Gemini 可能抓到不同的文獻角度，Claude 的推理邏輯又不一樣。單獨用一家，你永遠不知道自己錯過了什麼。

但是把三家的結果合在一起，就像三個不同背景的研究助理各自獨立調查同一個問題，最後你拿到的是一份更完整的報告。這不只是「多一份參考」那麼簡單 — 是用系統性的方式突破單一模型的知識天花板。

從急診醫學的角度來想，這就像看一個複雜病人時，同時請心臟科、胸腔科、感染科會診。每個專科看到的面向不同，合在一起才是最完整的臨床圖像。

這個做法的成本其實不高（三家都有免費或便宜的 Deep Research 額度），但效益是倍增的。以後做文獻回顧或 guideline 整理，都可以用這個方法。

今日收集的資源

2026/3/9

今日最有感的事

SDD：為什麼讓 AI 直接寫程式，常常是個陷阱？

今天看到高見龍分享的 SDD（Spec-Driven Development），說的是一件聽起來很簡單、但大多數人都在跳過的事：在叫 AI 寫程式之前，先叫 AI 幫你寫清楚「規格」。

這背後有個很根本的問題值得想：當我們用 vibe coding 直接叫 AI 寫程式，失敗的原因通常不是 AI 不夠聰明，而是我們自己都還不清楚想要什麼。AI 只能根據你說的話去做，你說得模糊，它就往一個不確定的方向跑，等跑偏了，你再修正，再跑偏，陷入一個反覆修修改改的循環。

SDD 的做法是把這個模糊的部分，在寫第一行程式前就先解決掉：讓 AI 根據你的需求生成一份規格文件，裡面寫清楚「這個功能要做什麼、不做什麼、成功的條件是什麼」，你確認沒問題後，再拿這份規格去叫 AI 實作。

換個角度想，這其實不只是程式開發的問題。任何時候你在用 AI 做有一定複雜度的任務，先對齊目標再執行，都比邊做邊猜更有效率。規格文件就是你和 AI 之間的合約，定清楚了，後面的事才好談。

今日收集的資源