小丁的家

分類: 🧠 失智照顧

  • 照護者 4.5 年死亡風險 +63%:那篇 lifestyle 是寫給你的

    重點摘要

    • Schulz 1999 JAMA:有心理壓力的失智照護者,4.5 年內全因死亡風險 +63%(RR 1.63, p<.05)
    • Norton 2010 Cache County Study:配偶失智的人,自己得失智風險 6 倍(HR 6.0,男性 11.9 倍)— 跟帶 APOE ε4 同等級
    • Lancet Commission 2024 列 14 個 modifiable factor 可預防 45% 失智,多數作用在 midlife(45-65)。媒體寫給失智長輩的 lifestyle,該套在 40-65 歲照護者身上
    • Xie 2013 Science:睡眠時大腦 β-amyloid 清除速率為清醒時 2 倍。被夜遊吵醒 = 直接累積失智病理蛋白
    • 台灣長照喘息補助重度年 21 天 / 48,510 元 — 文獻顯示 respite dosage 不夠,但先用,再呼籲制度往上加

    那篇健康遠見的「非藥物逆轉失智」文一看完,我有個荒謬的念頭:這篇真正的目標讀者其實是我,不是我媽。

    我 43 歲,媽媽失智 2 年(CDR 2 中度),當 primary caregiver 半年。媽媽現在連自己今天吃過飯沒都不記得,叫她做「結構化認知訓練」是天方夜譚。但我自己 — 中年、慢性壓力、睡眠剝奪、social isolation 越來越嚴重 — 完美命中文章的「目標族群」每一條。

    更狠的是,文獻早就講過,失智照護者本身就是 cognitive decline 的高風險族群。媒體寫給失智病人的 lifestyle,套在病人身上太晚,套在照護者身上剛好。這篇是寫給跟我一樣狀態的照護者看的,同行對同行。

    三個數字打中你

    1. Schulz 1999 JAMA:照護者 4.5 年死亡風險 +63%

    1999 年 JAMA 那篇 Caregiver Health Effects Study(Schulz & Beach)是這個領域的奠基論文。819 個 66-96 歲 spousal caregiver,1993-1998 prospective cohort。結果:有「mental/emotional strain」的照護者,4.5 年內全因死亡風險 RR=1.63(95% CI 1.00-2.65)。

    關鍵發現是:純照護沒事,「照護 + 心理壓力」才致命。無壓力照護者 RR=1.08,沒有顯著意義。

    我半年前剛接手時,以為照護是「累」的問題 — 睡不好、肩頸痛、沒時間運動。Schulz 那篇告訴我:累不會死,持續性的「心累」才會。覺得無望、覺得卡住、覺得做什麼都不夠 — 這些感受才是 4.5 年後上墓碑那個變數。

    2. Norton 2010:配偶失智 → 自己得失智風險 6 倍

    Cache County Study(J Am Geriatr Soc 2010):2,442 人(1,221 對夫妻),65 歲以上,追蹤中位 3.3 年。結果:配偶有失智的人,自己 12.6 年內得失智的 HR=6.0(95% CI 2.2-16.2, p<.001)。男性更慘,HR=11.9;女性 HR=3.7。已校正年齡、性別、APOE 基因、社經地位。

    重點是這個風險強度跟帶 APOE ε4 同等級。APOE ε4 是失智症最強的單一基因風險因子,而「配偶失智」這個社會 / 心理因子可以打到同樣的強度。

    機制上不難理解:慢性壓力 → HPA axis 失調 → cortisol 持續性升高 → hippocampus(富含 glucocorticoid receptor)樹突回縮、神經新生減少、突觸可塑性受損。Cortisol diurnal slope 變平,可以在臨床診斷失智前 10 年就預測。

    3. Xie 2013 Science:睡眠不足 = 直接累積 amyloid

    Xie et al. 2013 Science 那篇 glymphatic system 研究,做完之後改變整個失智 / 睡眠領域:睡眠時大腦 interstitial volume 擴大 60%,β-amyloid clearance 速率為清醒時的 2 倍。AQP4 knockout 後 amyloid clearance 降 65%。

    翻譯成照護者語言:我這半年每天被媽夜遊 / 找廁所 / 喊叫吵醒 2-3 次,完整睡眠週期被打碎。我自己的 brain clearance 還在做事嗎? 文獻說大概沒有。長期下來 amyloid 累積就是物理上累積。

    這不是抽象研究,是寫在我身體裡的事。

    為什麼是你:中年介入 > 老年介入

    Lancet Commission 2024 dementia prevention update 列了 14 個 modifiable risk factor,理論上若全部處理可預防 45% 的失智案例。但這個 45% 是 if-all-eliminated 上限。實際上 Commission 明說:

    • 4 個因子從 late-life 上移到 midlife:抽菸、憂鬱、physical inactivity、糖尿病。意思是 Commission 改了 frame,認為這些因子「在中年介入比老年介入有效」。
    • 2024 比 2020 版多 2 個新因子:LDL 膽固醇升高(midlife, PAF 7%)+ 未矯正視力損失(late life, PAF 2%)。
    • 已驗到的個別 PAF:聽損 midlife 7%、LDL midlife 7%、less education early life 7%、抽菸 midlife 5%、社會孤立 late life 5%、憂鬱 midlife 3%、視力 late life 2%。

    記者每次都寫「給失智長輩做」,但 Lancet 明明說 midlife。那就是 43 歲的我。4 個因子從老年上移到中年的事實,等於 Commission 官方說「該介入的是你,不是你媽」。

    5 個照護者真實可執行版本(對應原文章 lifestyle 清單)

    1. 運動 150 分鐘/週 — 照護動作可計入

    Connell et al. 2019 J Aging Res 報告 dementia caregiver 8 週運動介入(1 小時/週 group session + 個別 coaching + text):介入組 physical function、HRQOL、burden、depression 都顯著改善。AFISDEMyF Spain RCT 用「自主走路、preferably 住家附近」做設計。

    實踐:不用上健身房。推輪椅去公園、陪走、洗澡搬抱都算 moderate intensity。把「結構化運動」reframe 成「caregiving 動作 + 每天 20 分鐘自家附近步行」。週末早上趁媽還沒醒的 30 分鐘出去走也算。

    2. 飲食 — 兩餐合一

    媒體會建議照護者煮 MIND / 地中海飲食給失智長輩吃。實務上失智長輩到了中度通常飲食偏好固化、咀嚼能力下降、不會配合新飲食。重點不是分頭煮兩套,而是媽吃軟食 + 我吃硬食,基底相同 — 燕麥、堅果、橄欖油、莓果、深色葉菜、魚。一鍋煮、不同質地。

    MIND 飲食的優勢正是這種家庭級實踐性。注意:MIND 飲食 2023 NEJM RCT 主要終點是 null(詳見 5 紅旗拆解文),所以期待別放在「逆轉失智」,放在「降三高 / 維持體重 / 對心血管有 solid 證據」。

    3. 睡眠 7-8 小時 — 分階段策略

    夜間遊走是 caregiver sleep disruption 主因,造成 burnout 並加速 institutionalization。三類介入方向:

    1. 科技:床鋪離床 alert、smart home monitor、AirTag 縫進她常穿外套。能在第一時間醒,但不必整夜 hypervigilant。
    2. 行為:睡前廁所 routine、白天日光暴露 30 分鐘調 circadian、傍晚不安排刺激活動。
    3. Overnight professional care:台灣對應就是夜間臨托 / 住宿喘息。每週 1-2 個夜晚靠喘息服務睡飽,比追求「每天 7-8 小時連續」現實得多。

    不要追「每天連續 7-8 小時」(妄想),改追「每週至少 2 個 full night」。

    4. 社交互動 — 線上 peer 有 RCT 證據

    照護者最容易社會孤立 — 你的朋友圈裡沒人 24 小時被綁在家,聊天主題沒交集,慢慢就斷了。但 RCT 證據顯示線上 peer support 有效:

    • 軍方 caregiver(n=212)online peer support,3 個月後 perceived social isolation 顯著下降(JMIR 2020)
    • n=1,640 depression caregiver RCT:online self-help vs treatment as usual,psychosocial distress 顯著下降

    關鍵 actionable insight:不用見面 = 不用安排媽的代班。半夜手機開個 caregiver Discord / Line 群,文獻支持有用。你的 isolation 不是命中註定的,你只是需要找到能對上頻率的人。

    5. 聽力檢查 — Lancet 最強單一因子之一

    Lancet 2024 hearing loss midlife PAF=7%,跟 LDL 並列最高的可改變因子。意思是單做這一件事,理論上能讓自己失智風險降 7%。43 歲就該做基線 audiogram,如果有 mild loss 也要矯正 — 助聽器在 midlife 介入的 cost-effectiveness 是最高的之一。

    這是 Lancet 給中年人最 cost-effective 的單一動作,卻是台灣 40+ 健康檢查通常會跳過的項目。

    喘息服務:Underdose 但先用

    台灣長照 3.0 喘息補助:

    • 適用:已評估為長照需要等級 2 級以上,主要照顧者需休息時申請
    • 輕中度(2-6 級):32,340 元/年
    • 重度(7-8 級):48,510 元/年
    • 自負額:第一類 0%、第二類 5-10%、第三類 16-30%
    • 服務型態:居家、日間照顧、住宿型機構、巷弄站、夜間臨托

    學術文獻(Vandepitte 2016 systematic review)對 respite 效果是 mixed result。但仔細看:不是 respite 沒用,是 dosage 太低。台灣重度年 21 天(48,510 元 / 一天約 2,300 元抓),平均一週只夠 0.4 天 — 文獻說 respite 要有意義需要持續性 dosage,目前制度是 underdose。

    不要因為「研究說 mixed」就不用。先申請,把現有資源用滿,再呼籲制度往上加。給自己每週 0.4 天的喘息也比 0 天好。撥 1966 評估、找 A 個管員(個案管理員)幫你跑流程。

    誠實 frame:你倒下會怎樣?

    我沒查到「primary caregiver 突然失能 / 死亡後,失智 patient outcome」的 hard cohort data。文獻沒做這個研究,因為 caregiver 倒下後 patient 通常直接進機構,變成「另一個 patient cohort」,trace 不到。

    但反向推:Cache County 6 倍 + Schulz 63% + Norton spouse caregiver dementia 風險強度 = APOE ε4 級。caregiver 倒下不是 hypothetical,是統計上必然會發生的事件。差別只在什麼時候、以哪種形式。

    你媽倒下後會怎樣不在文獻裡,但你會怎樣 — 文獻寫死了。

    結語

    那篇健康遠見的文章,把 lifestyle 寫給「想替失智長輩做點什麼」的家屬。但 lifestyle 介入要有效,要在症狀出現前 15-20 年介入。對你媽已經太晚(詳見 時序窗口文),但對你剛剛好。

    不要把照護者自救當成「自私」 — 你是整個家庭的 SPOF(single point of failure)。一個 43 歲 caregiver 倒下,失智 patient + 配偶 + 子女整個系統會崩潰。把那篇給你媽看的 lifestyle 文,自己拿來執行。

    我從今天開始,每週至少兩個 full night,40 歲後第一次去做 audiogram,加一個 caregiver 線上群。明年這時候再寫一篇回顧。

    相關閱讀

  • 健康新聞 6 倍效果:5 道檢驗識破媒體 spin

    重點摘要

    • 2026-05-25 健康遠見「非藥物逆轉失智 6 倍」報導,有 5 個紅旗可拆
    • 紅旗 1:作者 Majid Fotuhi 開診所賣 12 週療程、2025 剛出新書,但文章只寫他是「JHU 博士」
    • 紅旗 2:「6 倍」是把 within-group 改善除以 between-group 延緩,不同單位不同對照,統計上不成立
    • 紅旗 3:藥物試驗的 primary endpoint 是 CDR-SB / iADRS,文章偷換成 secondary 的 ADAS-Cog
    • 紅旗 4:MIND 飲食 2023 NEJM RCT 是 null 結果,文章完全沒提
    • 紅旗 5:三高目標數值(HbA1c <7%、BP <130/80、LDL <2.6)是中年人指引,套到失智老人會增加跌倒、低血糖、過度治療風險

    2026-05-25 健康遠見刊了一篇「早期阿茲海默症能逆轉?新研究:非藥物生活方式 1 年改善效果是新藥 6 倍」,作者伊佳奇,自稱「認知症整合照護專家」。標題夠震撼,所以朋友轉給我。我花了一個下午查證,結果是這篇有 5 個地方禁不起拆。

    這篇不是要打作者,是要把「家屬看到健康新聞該怎麼自己驗證」這套工具給你。5 道檢驗 30 秒可以做完,每個讀者都能用。後面 5 個小節各拆一個紅旗,最後給你一份「讀者自查清單」。

    紅旗 1:作者的商業利益沒揭露

    文章說 Majid Fotuhi 是「約翰霍普金斯大學馬吉德・福圖希博士」,讀者讀到這會自動腦補「中立學術權威」。但實際身份盤點:

    • Johns Hopkins 的職稱是 adjunct professor of Mind/Brain Institute(兼任教授)+ affiliate staff at JH Hospital — 不是 full faculty。Krieger School 官網目錄列為兼任。
    • 本職是 NeuroGrow Brain Fitness Center(McLean, VA)的 Medical Director,販售 12 週「Brain Fitness Program」療程、Brain Coaching、Q-EEG Brain Mapping、Neurofeedback。官網不公開報價,需電話詢問。
    • 著有至少 4 本商業書,包含 2025 年 5 月剛出版的 The Invincible Brain(Harper Wave),副標題寫:「Johns Hopkins Neuroscientist’s 12-Week Program to Reverse Cognitive Decline」 — 直接呼應 AAN 2026 abstract 內容。
    • 付費 keynote speaker(A-Speakers 經紀;個人網站有 Book to Speak CTA)。

    他的研究結論「生活方式 = 6 倍藥效」,直接行銷他自己的 12 週療程跟新書。這是教科書級利益衝突。在學術期刊投稿時,這種程度的 COI 必須在 disclosure section 揭露;一篇給大眾的科普文,不揭露就是誤導讀者。

    讀者自查:看到「某某博士」就 Google 三個關鍵字:name + clinic / book / NCT 編號。再 LinkedIn 看實際職稱是 full / associate / adjunct。adjunct 在美國通常等於「掛名兼課」,跟 tenure 等級差很多,跟「全職研究員」更不是同一回事。

    紅旗 2:「6 倍效果」不是研究發現,是比較謬誤

    AAN 2026 abstract 原文(Medscape、Psychiatry Advisor 多家報導)寫的是:

    • 5 項生活方式 RCT 的 ADAS-Cog 改善 1.3-2.6 分(實驗組自己 baseline → endpoint 的變化,within-group)
    • 抗澱粉樣蛋白藥物在 CDR-SB 上 延緩下降 22-35%(實驗組 vs 安慰劑下降速度差,between-group)

    把這兩個數字相除得「6 倍」,在統計上不成立。三個 fatal 問題:

    1. 單位不同:ADAS-Cog 是認知測驗分數,CDR-SB 是臨床失智評分,根本不是同一把尺。
    2. 比較對象不同:生活方式是「實驗組變好」(沒有對照組變化作分母),藥物是「實驗組相對安慰劑下降速度的差距」 — 一個是 absolute change,一個是 relative slowing。
    3. 對照組設定不同:生活方式 RCT 的對照組是「lifestyle 教育單張」,藥物 RCT 的對照組是 placebo + 接受時 standard of care。基準線不可比。

    更狠的是:兩邊 effect size 其實都很小。Walsh et al. 2022 在 Lancet 指出 lecanemab 的 CDR-SB 0.45 分差距低於 minimal clinically important difference(MCID 0.98-1.63),病人可能感覺不到。FINGER trial 的 NTB Cohen’s d 是 0.127。兩邊都不漂亮,只是 Fotuhi 挑了讓比值最大的算法。

    讀者自查:看到「X 倍效果」先問 3 件事:(1) 兩邊量表單位一樣嗎? (2) 都對安慰劑 vs 都對自己 baseline? (3) 絕對差距是多少?「相對 600%」可能只是 0.1 分 vs 0.6 分。Cochrane plain language summary + GRADE 框架可以查證據等級。

    紅旗 3:Primary endpoint 偷換成 secondary

    每個正式臨床試驗在 ClinicalTrials.gov 上都有預先註冊的 primary endpoint(主要終點)。看試驗結果要看這個指標,因為它是試驗設計時就決定的「成功標準」。看別的指標叫 secondary endpoint analysis,可以參考但不能用來下結論。

    藥物 Primary endpoint 結果 文章引用的
    Lecanemab (CLARITY-AD, NEJM 2023) CDR-SB 延緩 0.45 分 / 27%, p<0.001 ADAS-Cog(secondary)
    Donanemab (TRAILBLAZER-ALZ 2, JAMA 2023) iADRS 低/中 tau 群組延緩 35.1%, p<0.0001 ADAS-Cog(secondary)

    文章只引「ADAS-Cog 延緩 1.3-1.5 分」,因為生活方式 RCT 用 ADAS-Cog。換量表才能比 — 但這違反試驗預先註冊原則,而且讓藥物看起來比實際差。讀者看到「ADAS-Cog 才改善 1.3 分」會覺得藥很爛,卻不知道藥物的主要評分是另一個指標,而且兩個指標上都達到顯著。

    讀者自查:搜尋「lecanemab NCT」找到 NCT03887455,點進 ClinicalTrials.gov 看 Primary Outcome Measures 欄位。媒體引用的指標如果不是這個,就是被偷換。這在學術新聞上算常見手法,讀者要有警覺。

    紅旗 4:Null result 隱藏(MIND 飲食)

    文章把 MIND 飲食列為「健腦飲食」推薦,但完全沒提這個方法在嚴格 RCT 下的結果。

    • 觀察性研究(Morris et al. 2015, Alzheimer’s & Dementia):嚴格遵守 MIND 飲食者失智風險降 53%。但觀察性研究有 healthy user bias — 嚴格執行健康飲食的人,通常其他健康行為也較好。
    • RCT(Barnes et al. 2023, NEJM, n=604, 3 年):MIND vs control diet(兩組都有 mild caloric restriction),主要終點全球認知 z-score 變化兩組無顯著差異。MRI 上白質高訊號變化、海馬體體積、灰白質總量也無差。兩組都改善,說明可能是「減重」效果而非「特定飲食」效果。

    文章列 MIND 為推薦但完全跳過 2023 NEJM RCT 結果。只引觀察性研究等級證據,屬於 cherry-picking(選擇性引用)。這在科普寫作的學術誠信標準上算嚴重瑕疵。

    讀者自查:看到任何「X 飲食預防失智」的推薦,Google「[方法] RCT」或「[方法] randomized controlled trial」。如果只找到 observational study 沒有 RCT,或 RCT 是 null,就要降一級信任。Google Scholar 加關鍵字「null」、「no effect」、「failed」會找到反面結果。

    紅旗 5:臨床指引族群不匹配(把年輕健康人指引套到失智老人)

    這是這篇文章最危險的一段。它列了一組三高目標數值,讀起來像「越嚴越好」,但套到失智老人會反向有害。

    血糖 HbA1c <7%

    ADA 2026 Standards of Care 第 13 章(Older Adults)明確寫:對有顯著認知 / 功能限制、frailty、嚴重合併症的老人,「less stringent glycemic goals may be appropriate」,並建議降階(deintensify)會造成低血糖的藥物。一般共識:

    • 健康老人 HbA1c < 7.0-7.5%
    • 中度失能 < 8.0%
    • 失智 / 末期 < 8.5%

    而嚴重低血糖會使失智風險增加 2 倍(propensity-score matched cohort, Diabetes & Metabolism Journal)。失智老人因厭食、體重下降、無法遵醫囑,本來就是低血糖高風險族群。緊密控糖反而加速跌倒 + 認知下降(MDPI Int J Mol Sci 2023 review)。把「<7%」套到失智老人是真實傷害。

    血壓 <130/80

    SPRINT-MIND 確實顯示 SBP <120 降低 MCI 風險,但 SPRINT 試驗排除了 frail 跟機構化長者。ESC 2024 建議 ≥85 歲或中重度 frailty 用 <140/90 mmHg(不是 <130/80)。AHA/ACC 2025 對 frail 族群建議「個別化、不給數字目標」。

    LDL <2.6 mmol/L

    2.6 mmol/L(≈ 100 mg/dL)是 2018 ACC/AHA 舊版的初級預防中度風險閾值。次級預防(已有 ASCVD)目標是 <1.4 mmol/L(55 mg/dL)。對沒有 ASCVD 病史的失智老人套 2.6 mmol/L 沒有強證據,可能導致 statin 過度處方(肌肉痛、跌倒風險、罕見認知副作用)。

    讀者自查:看到任何健康數字目標,先查兩件事:(1) 這個目標來自哪個 guideline、哪個族群?(初級 vs 次級預防;<65 vs ≥80) (2) 有沒有「老人 / frail / cognitive impairment」專章?ADA Standards of Care、NICE、AHA/ACC 都有老人專章,常常數字放寬。

    5 道檢驗 — 讀者自查清單

    1. 作者商業利益:Google 三組關鍵字 name + clinic / book / NCT。LinkedIn 看 full / associate / adjunct。賣什麼跟講什麼一致 = 自動扣 3 分可信度。
    2. X 倍效果拆算法:兩邊量表 / 對照組 / 時間窗是否可比?絕對差距多少?Cochrane / GRADE 查證據等級。
    3. Primary endpoint:ClinicalTrials.gov 查 NCT 編號的 Primary Outcome Measures。媒體引用的指標不是這個 = 被偷換。
    4. Null result:Google「[方法] RCT null」。觀察性 positive + RCT null = 降一級信任。
    5. 族群匹配:數字目標來自哪個 guideline 哪個族群?老人 / frail / cognitive impairment 專章有沒有放寬?

    結語

    不要看到「博士 + 倍數 + 新藥對比」就轉發。5 道檢驗 30 秒可做完,守住自己跟家人。

    這篇不是要打伊佳奇,他寫過的失智科普很多,我也讀過。但這篇 GVM 文的問題是把一個有 COI 的 AAN abstract 包裝成「研究新發現」,然後給失智家屬看 — 後果是讀者可能停藥、可能砸錢買認知訓練 app、可能照搬三高目標害到家人。家屬本來就在資訊弱勢,媒體再 spin 就是雪上加霜。

    學會自查,你才不會每次都被推著走。

    相關閱讀

  • 為什麼「非藥物逆轉失智」報導對中度家庭已經太晚

    重點摘要

    • 「非藥物逆轉失智」報導,RCT 證據集中在中年預防(45-65)跟 MCI 輕度認知障礙兩個窗口
    • FINGER trial 的 Cohen’s d 是 0.13(小效果);US POINTER 是 0.029 SD/年;SPRINT-MIND 把 MCI 風險降 19%(HR 0.81)— 都是「延緩」不是「逆轉」
    • 中度失智 CDR 2+ 沒有任何 high-quality RCT 顯示介入能改善認知。Tau 像 prion 沿神經迴路擴散,神經元死了就是死了
    • MIND 飲食 2023 NEJM RCT 是 null。MCI 自己有 14-31% 自然回復率 — 任何沒對照組的「我介入後好了」故事都不能歸因
    • 「逆轉」這個詞在主流 RCT 文獻幾乎不出現,主要從 Bredesen 商業協議來,加拿大失智症學會直接稱為 false hope

    2026-05-25 早上有人轉了一篇健康遠見的文章給我,標題是「早期阿茲海默症能逆轉?新研究:非藥物生活方式 1 年改善效果是新藥 6 倍」。我點開看,第一個念頭是:這篇文章對我媽完全沒用,但讀者不會知道為什麼。

    我 43 歲,媽媽失智 2 年(CDR 2 中度),我當 primary caregiver 半年。我同時是這篇文章「目標讀者」的兩個極端 —— 既是潛在預防族群(中年),又是已經錯過窗口的家屬。所以我特別敏感:同樣一句「生活方式可以逆轉失智」,對這兩個人講話是完全不同的事。

    這篇拆給看到類似報導、想替家裡長輩做點什麼的人。我不爭論「lifestyle 有沒有效」(有,但很溫和),我爭論的是「對誰、在哪個時間點有效」。時序維度講清楚,才不會有人因為一篇報導誤判處方。

    三個時序窗口:中年、MCI、中度失智

    失智不是一天形成的。從病理上看,β-amyloid 累積大約在症狀出現前 15-20 年開始,tau 蛋白擴散與神經元喪失則是更晚的事。lifestyle 介入會打在這條時間線的哪個位置,決定了它有沒有意義。

    窗口 對象 RCT 證據 效果性質
    1. 中年預防 45-65 歲、無症狀 FINGER、US POINTER、SPRINT-MIND 統計顯著但 effect size 小
    2. MCI / 早期 AD 輕度認知障礙、CDR 0.5 SPRINT-MIND 子分析;MIND diet RCT 是 null 降風險 / 延緩進展,不是逆轉
    3. 中度失智 CDR 2+ 已確診中度、ADL 受損 無 high-quality RCT 顯示認知改善 運動降跌倒,但不改善認知 / QoL

    窗口 1:中年預防 — 效果存在,但比媒體寫的小很多

    FINGER trial(芬蘭,2015 Lancet)

    1,259 名 60-77 歲、有 CAIDE 認知衰退風險但尚未失智的芬蘭人,做 2 年多模介入(運動、飲食、認知訓練、血管風險管理)。主要終點 NTB Z-score:介入組 +0.20、對照組 +0.16,組間每年差距 0.022(95% CI 0.002-0.042, p=0.030)。

    統計上顯著,但 Cohen’s d ≈ 0.13 — 在效應量分類裡屬於「小效果」(d < 0.2)。換句話說,FINGER 證明 lifestyle 介入比不介入好一點點,不是脫胎換骨。AAIC 2025 報告 11 年追蹤顯示,堅持下來的人衰退較慢,但「堅持下來」是另一個篩選效應。

    US POINTER(美國,2025 JAMA)

    FINGER 的美國真實世界擴大版:2,111 人、平均 68.2 歲、五個學術中心。比較 structured(結構化、定期 group session)vs self-guided(自主執行)兩組。主要終點 global cognitive composite 每年變化:structured +0.243 SD vs self-guided +0.213 SD,組間差 0.029 SD/年(p=0.008)。

    注意這個 trial 兩組都改善,只是 structured 多一點點。差異在小數點第二位。媒體常把這種結果寫成「結構化訓練有效」,但要看清楚:對照組不是「什麼都不做」,而是「自己做」 — 兩種都比躺平好。

    SPRINT-MIND(2019 JAMA)

    9,361 名高血壓老人，比較積極控壓(收縮壓 <120)vs 標準控壓(<140)。MCI 風險降 19%(HR 0.81, p=0.01),MCI + probable dementia 合併終點降 15%(HR 0.85, p=0.02)。但 probable dementia 單獨終點未達顯著(trial 被提前終止 3.3 年,事件數不夠)。

    這是中年血壓控制最有力的 RCT 證據之一。但要記住:介入的是血壓,不是「lifestyle」廣義概念。三高管理是 Lancet Commission 2024 列入的 14 個 modifiable risk factor 之一,跟泛泛說「健腦飲食」是不同等級的證據。

    窗口 2:MCI — 證據比預期弱,自然回復率高

    MCI(輕度認知障礙)被叫做「黃金介入期」,但實際 RCT 證據比想像中弱。最關鍵的兩個事實:

    1. MIND 飲食 RCT 是 null。Barnes et al. 2023 NEJM,604 人 3 年隨機試驗,MIND vs control(兩組都有 mild caloric restriction),主要終點全球認知 z-score 變化兩組無顯著差異,MRI 上海馬迴體積、白質高訊號變化都無差。兩組都改善 — 可能是「減重」而非「特定飲食」效果。媒體報導 lifestyle 介入時通常只引 2015 觀察性研究(Morris et al.),不提這篇 RCT。
    2. MCI 有 14-31% 自然回復率。最新 2025 systematic review pooled 31%(48 篇研究、31,876 人),社區族群更高、診所族群較低(約 14%)。意思是:就算不介入,有相當比例 MCI 患者會自己回到 normal。任何沒對照組的「我吃了 X、做了 Y,我媽 MCI 好了」故事,在科學上幾乎不能歸因。

    窗口 3:中度失智 — 沒有 RCT 證據,有機制解釋

    這是我最在意的部分,因為這是我媽現在的階段。

    2023 systematic review 結論:沒有 moderate- 或 high-certainty 證據支持多模式 lifestyle 介入能改善 mild-to-moderate dementia 的全球認知。運動在中度失智階段仍能降低跌倒風險(RR 0.69, 95% CI 0.55-0.86),但對認知、死亡率、QoL 都無顯著改善。

    機制上的解釋很直接:tau 蛋白在 AD 早期從 transentorhinal cortex 開始,像 prion 一樣沿神經迴路 hierarchical 擴散 — hippocampus → 邊緣系統 → 聯合皮質 → 初級感覺皮質。Tau 跟神經元喪失、區域萎縮的相關性比 β-amyloid 更強。中度失智(CDR 2)時 hippocampus 已經顯著萎縮,tau 已經擴散到聯合皮質。

    講白話:神經元死了就是死了,lifestyle 介入沒有任何機制能讓 hippocampus 重新長出來。這不是悲觀,是物理。中度失智階段做運動、社交、聽力矯正仍然有意義(降跌倒、降日落症候群、維持基本功能),但目標是降危害不是恢復認知。如果家屬抱著「逆轉」期待去做,失敗時的挫折感會壓垮整個家庭。

    「逆轉」這個詞,在主流 RCT 文獻幾乎不出現

    我做完上面這些 cross-check 後發現一件事:認知科學跟失智 RCT 的主終點,寫的都是 slowing decline(延緩衰退)、preventing incidence(預防發病),沒有人寫 reversal(逆轉)。

    「Reversal of cognitive decline」這個詞主要從 Dale Bredesen 的 ReCODE 協議來。他發表的 reversal 系列論文都是 case series(10-100 人、無對照組、無隨機化、無 blinding),被 Lancet Neurology、Theoretical Medicine and Bioethics、UCSF Memory Center 公開批評為「shares the hallmarks of second-rate science」(UCSF 神經科 Joanna Hellmuth)。加拿大 Alzheimer Society 直接發官方聲明:「Bredesen Protocol offers false hope of reversing Alzheimer’s disease」。

    而這個協議收費 USD$1,399 起,還有額外療程費用。商業誘因強到讓「逆轉」這個詞成為行銷話術。家屬看到「逆轉失智」四個字,我建議先問:

    • 是 RCT 還是 case series?
    • 對照組有沒有?
    • 對象是 MCI 還是已確診失智?
    • 如果是失智,CDR 幾分?

    對家屬的實際 action,按窗口分

    如果你自己是窗口 1(中年 45-65,沒有症狀)

    Lancet Commission 2024 列了 14 個 modifiable factor,理論上若全部處理可預防 45% 的失智案例。但這個 45% 是 if-all-eliminated 的上限,不是你一個人做就有的。已知個別 PAF 最高的幾個:聽損 midlife 7%、LDL 膽固醇 midlife 7%、less education early life 7%、抽菸 midlife 5%、社會孤立 late life 5%。

    動作清單:中年血壓控制(SPRINT-MIND 證據)、聽力檢查(Lancet 列為單一最高 PAF 之一)、戒菸、規律運動、社交、地中海式飲食方向。不必追特定品牌療程,基本盤做齊就贏 80% 的人。

    如果家人在窗口 2(MCI / 早期 AD)

    把窗口 1 的事情都做,加上規律回診追蹤、考慮加入正在進行的 RCT(不是私人診所自費療程)。但要心理建設:就算介入,效果是「降低 19% 進展到失智的風險」(SPRINT-MIND),不是讓她「變回 5 年前的樣子」。期待值設低一點。

    如果家人在窗口 3(中度失智 CDR 2+)

    三件事:

    1. 三高管理改老人指引版本。HbA1c 目標放寬到 7.5-8%(失智老人壓 <7% 增加低血糖風險 → 跌倒 → 加速認知下降);BP 目標 <140/90 即可。回診時跟醫生確認個別化目標。
    2. focus on 降危害,不是恢復認知。維持每日散步(降跌倒)、固定睡眠作息、社交刺激(居服員、家人陪伴)、聽力矯正(若有聽損)、有事做(整理衣物、看相簿)。這些不會「逆轉」,但會讓現在這段時間品質好一點。
    3. 家屬自己的 lifestyle 反而更重要。失智照護者的死亡風險、cognitive decline 風險都是 elevated 族群。你倒下,媽媽沒人接。這部分我另寫一篇 照護者自救文。

    媒體報導沒寫的事

    那篇健康遠見的文章,把 Majid Fotuhi 在 AAN 2026 的 abstract 包裝成「JHU 博士證明非藥物 6 倍於新藥」,但沒提:

    • Fotuhi 自己開 NeuroGrow Brain Fitness Center,賣 12 週療程,2025 剛出新書副標題就是「12-Week Program to Reverse Cognitive Decline」
    • 那個 abstract 是年會 poster,不是 peer-reviewed 論文
    • 「6 倍」是把不同量表、不同時間窗、不同對照組的數字硬除出來的,在統計上不成立
    • 文章推薦的 MIND 飲食,2023 NEJM RCT 結果是 null,完全沒提
    • 列的三高目標數值套到失智老人會增加跌倒風險

    這 5 個紅旗的完整拆解,我寫在另一篇 健康新聞 5 道檢驗。

    結語

    「非藥物 lifestyle 介入有效」這句話是對的,但它的對象是還沒失智、或剛輕度認知障礙的人。對於已經中度失智的家庭,媒體把這種報導推到我們眼前,是好意但是錯位的善意 — 會讓家屬覺得「我是不是不夠努力」、「我是不是來不及」。

    來不及就是來不及。承認這件事,反而讓我們可以把力氣放在現在這段時間怎麼過好:降危害、維持品質、不讓家屬倒下。逆轉是不可能的,但每一天的尊嚴是。

    相關閱讀

  • 我的家庭照顧 14 個 HTML 工具:dementia-care monorepo + 實戰使用指南

    重點摘要

    • dementia-care monorepo 是 14 個 HTML/Python 工具的 personal toolkit:圍繞「家人照顧」這件事,自家用為主,朋友(藥師)+ 社區照護者也用得上。
    • 起源:照失智媽媽 2 年急速進展 + 育兒 2023 年出生女兒,前面有 15 年照爸爸 stroke 失能 secondary 經驗。每天遇到 friction 就寫一個小工具。
    • 上位 mission:「讓整個家忙起來」(ambient engagement,Marx & Cohen-Mansfield 2010 循證概念)—— 工具不是治療,是降低照護者啟動 friction。
    • 共用 spec:純前端、單檔 HTML、0 CDN、0 build、離線可用、繁體中文、大字大按鈕、SVG emoji favicon、GitHub Pages 部署。
    • 5 條自我約束(2026-04-28 後):凍結新 sub-project 60 天 / commit cap 20/天 / 每週一個下午全關 / 0 CDN 機器化守門 / 不主動推工具只分享方法。
    • 跨專案 lessons:純黑白對白內障是錯的 frame、圖書館 ≠ 景點 precision contract、Google Maps fallback default pin 陷阱、Selenium 驗證 self-use 例外、物件 literal 尾逗號讓整頁 blank。

    dementia-care monorepo 是 14 個圍繞家庭照顧的 HTML/Python 工具集,過去半年累積。為什麼會有這個 repo?照失智媽媽,順便做給太太、藥師朋友的太太、社區照護者用 ——「自家工具集 + 經驗分享」,不是 community product。

    這篇是這個 monorepo 的全面整理:14 個工具的分工、起源故事、共用設計原則、5 條自我約束、5 條跨專案踩坑 lessons。給想做類似 personal toolkit 的人參考,也給之後的我自己回頭看為什麼這樣設計。

    為什麼會有這個 monorepo?

    結構上設計給:白天只有你跟長輩、家屬 backup 0、商業 app 都假設你有時間引導。我家 timeline:

    • 15 年照父親 stroke 失能(secondary,媽媽是 primary,2024 過世)
    • 2024 起媽媽輕度失智 → 2 年急速進展到中重度
    • 2023 出生女兒進入 toddler 階段
    • 太太是藥師、有正職,白天無法 backup
    • 過去半年我變 primary caregiver

    每天遇到 friction(媽媽問同樣問題第 50 次 / 居服員交班沒交集 / 回診忘記想問什麼 / 女兒週末沒地方去) —— 直接寫一個小工具,不寫 spec、不開會、不等 backlog。半年累積 14 個。

    上位 mission 是「讓整個家忙起來」。對應的循證概念是 ambient engagement(Marx & Cohen-Mansfield 2010 “Engagement of Persons with Dementia”):環境引發的活動 vs 人引發的活動,失智長輩參與有意義活動的「量」與認知衰退斜率負相關。工具不是治療,是降低照護者啟動 friction —— 讓 engagement 在沒人陪伴的疲累照護日實際發生。

    14 個工具分四大類

    🧠 失智照護生態系(主線資料閉環)

    工具 類型 說明
    陪伴小幫手 v1 互動遊戲 15 個認知訓練遊戲,8 級難度滑桿自動選 10 個顯示
    陪伴小幫手 v2 試驗版 推薦式首頁 + 照護者陪伴指南 + 今日摘要分享
    白板 OCR Bot Telegram Bot 每日白板照 → Gemini 3 Flash(box-index 策略,磁鐵在第幾格)→ iDempiere Z_momSystem
    就診小幫手 Web App 回診前 prep:抓 iDempiere 異常、症狀分類、診間錄音

    👶 兒童 + 親子

    工具 類型 說明
    小朋友學習樂園 學齡前互動 1-6 歲 23 個活動,4 年齡層自適應深度
    週末出遊地圖 親子景點 全台 22 縣市 850+ 景點 + 多點路線規劃
    托嬰幼兒園手冊 方法論 0-6 歲托嬰中心 + 幼兒園選擇方法論(4 種類型對照,評估 SOP)

    📖 生活方法論手冊

    手冊 主題
    care-handbook 長照手冊:找居服員 / 日照 / 喘息 / 機構 / 看護工 / 失智專屬支援系統
    home-handbook 家中照護手冊:13 項物理改動 + 早午晚 SOP + 援手系統 awareness
    home-handbook-classic 家中照護手冊舊版(保留作對照,新版改用 home-handbook)
    garden-handbook 家庭園藝手冊(可食 + 觀葉 + 觀花 + 根莖類,陽台/窗邊/室內)— 對失智長輩是 behavior redirection 工具
    pet-handbook 家中寵物生活手冊(貓/狗/兔/鳥/魚/烏龜)—「會主動靠近的家人」,失智長輩 + 小孩雙受惠
    mindset 心法手冊 — 6 條視角(失智不是失能 / 用加法對抗減法 / 躁動不是無聊 / 動線是功能可及性 / 誠實版優於善意包裝 / 手冊是網狀不是清單)

    🧃 飲食 / 健康

    • health-drinks:**19 款醫療營養品 + 嬰幼兒配方 + 高蛋白補充品**並排比較(180-280ml 容量範圍。三重使用者:Tom 自家、藥師朋友、藥局客戶)

    失智照護主線:資料閉環長什麼樣?

    14 個工具裡 4 個是失智照護核心,串成一條 daily/weekly 閉環:

    [居服員 / 我]
    ↓ 拍白板照傳 Telegram
whiteboard-ocr-bot
    ↓ Gemini 3 OCR + 人工 confirm
iDempiere Z_momSystem(每天一筆紀錄)
    ↓ REST API
mom-clinic-companion
    → 回診前產出「今天要問醫生的 3 件事」

    白板每天記錄媽媽 餐食 / 用藥 / 行為事件 / 睡眠時數。OCR Bot 把照片轉成結構化資料寫進 iDempiere(自家 ERP-as-PHR,Z_momSystem 表 12 欄位)。回診前 mom-clinic-companion 比對「上次回診 → 今天」vs「上上次回診 → 上次回診」兩個 window,抓變化顯著項目給神經科醫師看具體事件,不是「最近狀況不太好」這種模糊描述。

    這條主線運轉半年,媽媽每月回診從「我也不知道要說什麼」變成「上週三晚上她突然找不到回家的路」這種具體 evidence。神經科醫師根據具體事件調藥,比根據家屬情緒描述準確很多。

    共用設計原則 — 為什麼都是單檔 HTML?

    14 個工具共用同一套 spec:

    • 單檔 HTML:HTML + CSS + JS 全塞 `index.html`,不拆檔。對 backup / 修改 / 分享(直接寄一份)極友善。
    • 離線可用:所有資源 inline(SVG favicon、base64 圖、不依賴 CDN)。山區農場、長輩家 wifi 弱 都能跑。
    • 0 CDN 強制:禁止任何 fonts.googleapis / cdnjs / unpkg / jsdelivr / Google Analytics / 外部 script。原因:使用者打開網頁時瀏覽器會從使用者裝置直接發請求到 CDN 伺服器,洩漏 IP + User-Agent + 時間給第三方,違反 COPPA(兒童)/ GDPR-K / 個資法。有專屬 CI workflow `monorepo-cdn-ban.yml` 機器化守門(2026-04 加),違反即擋 push。**Caveat**:`health-drinks` 因為較早期建置仍用 Chart.js + Google Fonts CDN,是 monorepo 唯一例外,計畫之後遷移成 inline。
    • 0 build step:不進 npm、不進 webpack。寫完開瀏覽器看,改完 commit push 30-60 秒 GitHub Pages 部署。
    • 繁體中文 + 大字大按鈕:觸控友善,最小點擊區 48×48px。
    • SVG data URL emoji favicon:離線也有 tab icon。

    低視力對比:原本以為「純黑底 + 純白字 = 最大對比 = 最適合低視力長輩」,後來發現對中度白內障(monorepo 主場景)會因 forward light scatter 引發 halation/glare —— 21:1 是 over-shoot,不是越高越好。Evidence-based 替代:米白底深字(#222 on #f5f5f5)/ 深底淺字(#e8e8e8 on #1a1a1a)/ 字級 ≥ 24px / line-height ≥ 1.6。維持 WCAG AAA(7:1+)但消除極端 glare。

    5 條自我約束(2026-04-28 後加)

    跨 6 domain expert review 共識項。寫進 CLAUDE.md 變強制規則,我自己做時也守:

    1. 凍結新 sub-project 60 天(到 2026-06-30):14 個已過載,主軸佔比 < 35%。6 個月 450+ commits(`git log –since=’2025-11-01’`),「持續產出 = 情緒迴避」紅旗。例外:只允許 archive / 整併 / 刪除。解凍後若仍想開新工具,先在 blog 寫一篇「為什麼這值得開一個工具」,沒寫完不開。
    2. Commit cap 20 / 天 (soft warning):超過 20:pre-commit hook 跳對話框問「今天你媽吃幾餐、女兒抱了你幾次、你笑了幾次」。失智照護者 burnout 是 monorepo 結構性 SPOF —— Tom 倒下 = mom-clinic 朋友家屬可能誤診 = 整個生態系凍結。
    3. 每週一個下午全關:不寫 code、不寫 blog、不規劃 feature。陪女兒、發呆、睡覺都行。「讓整個家忙起來」mission 不該包含 Tom 自己一刻不停。
    4. 0 CDN 機器化守門:`.github/workflows/monorepo-cdn-ban.yml` 自動掃所有 *.html。違反即擋 push。不再靠人記得。
    5. 不主動推工具,只分享方法:工具是 personal toolkit,維護優先順序看當下需要。不主動推給陌生使用者(避免讓人對「會被維護」產生錯誤期待)。朋友(藥師)是「資訊交流」不是「使用者」,不發配工具帳號。方法寫成 blog,blog 才是擴散渠道(這篇就是)。

    5 條跨專案踩坑 lessons

    1. 純黑白對白內障是錯的 frame

    「最大對比 = 最適合低視力」是錯的。對白內障(monorepo 主場景)forward light scatter 引發 glare,21:1 反而降可讀性。WCAG 21:1 是 物理可量化(luminance ratio),「適合低視力」是 臨床效果(可讀 + 不疲勞 + 不誘發 glare),兩者不是同一件事。Evidence-based:米白底深字 / 深底淺字 / 字級 24px+ / line-height 1.6。

    2. 圖書館 ≠ 景點:precision contract

    不同 place category 對 precision 容忍度不同。景點(公園 / 山林 / 老街)area centroid 1-2 km 噪音 OK(本身就大);圖書館 = 單一建築,1 km 偏差 = 不同樓棟 = 錯,不能套同一條 fallback 規則。對「single building」類,寧可 entry 數量少(精確) 也不要 area centroid(誤導 user)。

    3. Google Maps fallback default pin 陷阱

    Google Maps geocoding 找不到地址時不會回 error,而是 silent fallback 回最後一個成功 query 的 cached coord。kids-weekend 跑 23 筆 Playwright 有 3 筆全部 fallback 到同一個 [24.9790, 121.4579]。必跑 sanity gate:縣市 bounding box 比對。任何 geocoding pipeline 必須有 downstream sanity check —— 不能信「200 OK + 有 @lat,lng」就當作對的。

    4. Selenium 驗證 self-use 例外 ≠ photo scraping hard violation

    Google Maps Platform ToS 是合約不是法律,enforcement profile 對「自用 / 非商業 / 中等規模」幾乎為零。判斷不是 binary —— 看(1) self-use vs 商業化 (2) 一次性 vs 持續性 (3) 文字 vs 照片 三維度。kids-weekend 圖書館 geocode 落在「self-use + 一次性 + 文字座標」三個都 OK 的格子,屬技術性 ToS issue。但 photo extraction + redistribute 仍是 hard violation(著作權法 §91 §92),商業化應升級付費 API。

    5. 物件 literal 尾逗號讓整頁 blank

    2026-04-21 kids-companion 整頁 blank 事故:新增 IMG 物件忘記前一筆尾逗號,SyntaxError 整頁掛。單檔 HTML 沒 webpack 兜住,JS 一錯整頁 die。寫 lint script (`scripts/lint_places.py`)機器化檢查每筆 entry 結尾。

    為什麼不對外推銷?

    因為這是 tier 2 personal toolkit 不是 community product。三個原因:

    1. 維護順序看自家當下需要:某天我家 schedule 變、媽媽病程變、女兒入學,工具優先順序就變。對外推銷會建立「會被維護」期待,實際上我可能突然停某個工具 —— 對 user 不公平。
    2. SPOF 問題:14 個工具只有我一個 maintainer,我倒下整個 stop。對外推 = 對外承諾,承諾兌現不了 = 信譽損傷。
    3. 方法 vs 工具:方法可以用文字傳承,擴散性高;工具 binding 在我家 schedule + 我家硬體 + 我家數據格式。方法寫成 blog,工具留給有能力 fork 改的人。

    朋友(藥師)是「資訊交流者」不是「使用者」 —— 我跟她討論失智用藥,她跟我討論病人家屬,但我不發給她工具帳號讓她依賴我的伺服器。她想用就 fork,改成她家用。

    給想做類似 personal toolkit 的人的建議

    1. 明確 scope = self-use:這個 frame 鎖死所有設計決定 —— 不做 user account、不做 paywall、不對外推銷、不收 review。Scope 一變,所有 compliance / privacy / 合規 trade-off 全變。
    2. 單檔 HTML 是 personal toolkit 的甜蜜點:0 build / 0 server / 直接寄一份檔案 / 純前端 / 離線 / GitHub Pages 免費部署。技術簡單到不會卡住做事的人。
    3. 0 CDN 是隱私底線:任何外部 fonts / analytics 都洩漏 user IP。家庭應用(兒童 / 醫療 / 失智)不能讓 Google 知道你家在訪問什麼工具。寫 CI workflow 機器化守門,不靠人記得。
    4. 每個工具對應一個 friction:不要先想「我要做什麼工具」,要想「我每天卡在什麼」。卡在交班 → OCR Bot;卡在回診 → mom-clinic;卡在週末 → kids-weekend。
    5. 政府開放資料 > 商業 API scraping:libstat / data.gov.tw / TGOS 對台灣應用是乾淨 source,合規且持久。每個 domain 找對應的政府 source(圖書館 / 醫院 / 學校 / 古蹟)。
    6. self-use 工具不是免責令:Photo extraction、持續性 production scraping、商業化 仍是 hard violation。判斷 framework 看 (1) self-use vs 商業 (2) 一次性 vs 持續性 (3) 文字 vs 照片 三維度。
    7. 給自己自我約束:照護者 burnout 是結構性 SPOF。commit cap、每週全關一下午、凍結新 sub-project,這些不是「強制症」是「對抗持續產出 = 情緒迴避」的 hard rule。

    —— 工具實戰判斷與用法 ——

    三層分工:Handbook、工具、專業

    使用 monorepo 之前,先建立三層分工的觀念:

    層 作用 對應 monorepo 頻率
    Handbook 認識系統、申請流程、SOP 學習 care-handbook / home-handbook / childcare-handbook 階段性(剛確診、要申請居服員)
    工具 每日操作、降低啟動 friction 陪伴小幫手 / OCR Bot / mom-clinic / kids-weekend 每日 / 每週
    專業 診斷、用藥、急救、法律 神經科 / 精神科 / 1966 / 1925 / 119 / 共照中心個管師 回診 + 突發事件

    實戰原則:剛確診先讀 handbook(2-3 天密集吸收),3 個月後 handbook 慢慢變參考書,工具變每日操作,專業在事件發生時 escalate。

    7 個照顧場景對應工具速查

    場景 主要工具 配合 handbook
    失智剛確診那週 無工具(handbook 為主) home-handbook P0 + care-handbook 申請流程
    居服員每天交班 白板 OCR Bot home-handbook 居家日 SOP
    媽媽情緒不好想做點事 陪伴小幫手 v2(推薦)/ v1(自選) —
    回診前一晚 mom-clinic-companion —
    週末帶孩子去哪 kids-weekend(住哪 → 路線) —
    孩子在家想做活動 kids-companion(2-6 歲 4 年齡層自適應) — (kids-companion 自己分齡)
    第一次申請長照 無工具(handbook 為主) care-handbook 7 步 SOP + 援手系統

    場景 1:失智剛確診那週 — handbook 為主

    剛確診那週不要急著上工具。先做 5 件事(home-handbook P0 章節):

    1. 法律 P0:輔助宣告 / 監護宣告 / 預立醫療決定 — 趁失智長輩仍有意思能力時辦,過了會難辦
    2. 醫療 P0:確認確診醫院 + 預約共照中心 + 申請重大傷病卡
    3. 防走失:愛心手鍊 / GPS / 鄰里通報網
    4. 物理改動 13 項(home-handbook 列清單):防滑地墊 / 衛浴扶手 / 廚房瓦斯總開關 / 大門感應…
    5. 申請長照:1966 → 照管專員到府評估 → 失能等級 → 服務媒合(care-handbook 7 步 SOP)

    這週不要碰工具。一邊吸收 handbook,一邊處理法律醫療 P0,一邊跟家人討論分工。工具是後面 2-3 個月開始有居服員 / 日照排班後才會用得上。

    場景 2:居服員每天交班 — 白板 OCR Bot

    白板 OCR Bot 解決交班斷層:居服員早上來、下午走;家屬晚上接手 — 中間 8 小時居服員紀錄不傳給家屬,神經科回診也說不清楚。

    實際流程:

    1. 家裡放一塊白板,居服員每天用筆寫紀錄(餐食 / 用藥 / 行為事件 / 睡眠)+ 用磁鐵標記固定欄位的選項
    2. 居服員下班前 / 我經過時拍照傳 Telegram bot(`telegram_bot.py`)
    3. Bot 走 `ocr_pipeline.py` → Gemini 3 Flash Preview API,**用 box-index 策略**(磁鐵在第幾格)避開手寫中文字元 OCR — human-as-verifier 設計
    4. 手機收到 bot push 訊息「請確認」,3 秒過目即可。錯了直接改文字回傳
    5. 自動寫入 iDempiere Z_momSystem(每天一筆 row,12 個欄位)
    6. 家屬晚上看 iDempiere 知道白天發生什麼,銜接夜間照護

    另也支援 📝 文字訊息 → 加時間戳(早 / 晚 / 大夜班)append 到當天備註欄;`/status` `/today` 指令查當天/累積狀態。`whiteboard-ocr-bot/index.html` 是純前端 demo 版本(模擬對話流程,不連網不傳資料),正式版要 Python + iDempiere REST API 跑在自家 server。

    關鍵 design:box-index 策略 + human-as-verifier 不是全自動。Gemini OCR 對手寫長輩字跡不一定 100%(尤其用藥名稱),所以白板用固定欄位 + 磁鐵 — Gemini 只要識別「第幾格有磁鐵」這種離散 boolean,不用識別自由手寫,大幅降低錯誤率。

    場景 3:媽媽情緒不好想做點事 — 陪伴小幫手 v2

    陪伴小幫手有 v1 / v2 兩版本並存:

    情境 用 v1 還是 v2?
    媽媽心情好,自己想挑 v1(10 格遊戲卡讓她挑)
    媽媽疲累 / 不擅選擇 / 照護者也累 v2(一鍵推薦「今天一起做這個好嗎」)
    想知道對長輩說什麼話帶遊戲 v2(每遊戲 3 條陪伴指南)
    想記錄今天玩了什麼貼 LINE 給家人 v2(每日摘要一鍵複製)

    v2 推薦邏輯:依時段(早 / 午 / 晚 / 深夜)+ 最近玩過避免重複 + 當前難度自動挑一個遊戲。次要選項「換一個 / 我想自己選」字級縮小、無底色,降低照護者選擇癱瘓 — 是給疲累照護者的設計。

    難度滑桿 1-8 對應方式(`v1 CLAUDE.md` 規格):

    • 1-2 輕度:遊戲篩選後較難(辨識變化小、選項多),語音只朗讀題目
    • 3-6 中度:遊戲難度中等,語音朗讀題目 + hover 選項唸出
    • 7-8 重度:遊戲篩選後最簡單(選項少、對比大),語音朗讀題目 + 所有選項,重複一次

    遊戲庫(`GAME_LIBRARY`)15 個遊戲每個有 `min`/`max` 範圍,`selectGames(level)` 從符合範圍的遊戲中隨機抽 10 個顯示首頁。選擇難度時看當週實際狀況試,不是越難越好 — 失智長輩做不到會挫折,做太簡單會無聊。

    場景 4:回診前一晚 — mom-clinic-companion

    失智回診最大的問題是「**最近狀況不太好**」這種家屬模糊描述,神經科沒辦法調藥。mom-clinic-companion 讀 iDempiere `Z_momSystem` 表(白板 OCR Bot 寫入的),把 raw data 歸納成照護者可以記住、可以問的內容。

    實際 4 個 sections(`mom-clinic-companion/index.html` H2):

    1. 🚨 值得跟醫生討論的 — 規則引擎自動比對「上次回診 → 今天」vs「上上次回診 → 上次回診」兩個 window,找變化顯著項目
    2. 💭 這一個月媽媽發生過 — 從白板 OCR Description 欄抓症狀關鍵字
    3. 📋 這次要問醫生 — 從上面兩區一鍵「加進問題」,手動補其他
    4. 🎙️ 診間錄音 — 醫師講話 STT 轉字,回家同步回 iDempiere

    核心設計是回診日期感知:`APP.visits` 是回診日期 array,`computeWindows()` 產生最新兩段比對區間 — 因為實際回診頻率不規則(通常每月,有時兩週),按日曆切會不準。

    場景 5:週末帶孩子去哪 — kids-weekend(MAP 工具)

    kids-weekend 是 monorepo 裡最大的 MAP 工具:全台 22 縣市 851 筆親子景點 + 路線規劃(`STATE_VERSION` 3,單檔 HTML ~700KB)。解決的具體問題是「從家出發 X 公里範圍內,有什麼順路可以串成一日」 —— 媽媽社團、IG 收藏、Google Maps 我的清單,都做不到「按距離 + 順路 + 一鍵多點導航」這件事。

    1 題 wizard 是 deliberate 砍簡 — 從 4 題到 1 題

    2026-04 砍簡前,wizard 有 4 題:住哪 + 天氣 + 年齡 + 範圍。實測發現 user(太太、藥師朋友)80% 都直接 next 跳過後 3 題:

    • 天氣晴雨:家長自己抬頭看,問了多餘
    • 年齡:每筆景點 entry 已有 `ages: [‘0-2′,’2-3′,’3-6’]` 標籤,filter UI 之後再勾就好
    • 範圍:**家庭多在 20 km 內**(自家 + 朋友家實測 4 個月),預設 20 km 一拉就動

    所以剩 1 題:**「住哪?」**(GPS 一鍵 / 縣市 + 區下拉)。設完直接看推薦清單,範圍可拉滑桿改 5-400 km。砍題目比加 feature 更重要 —— personal toolkit 的設計訓練。

    實際 6 步使用流程

    1. 設家 — 第一次選,之後 `localStorage[kidsWeekendState]` 記住。GPS 一鍵會 reverse geocode 成「📍 新北土城」(不顯示醜的經緯度)
    2. 看推薦清單 — 預設 20 km 內景點,室內/戶外/觀光工廠/博物館/公園/海邊/廟宇/老街全混合
    3. 篩 filter — 晴天/雨天/0-2 歲/室內/避開人多/避開假日塞車黑名單
    4. 勾比較籃 — 1-3 個目的地加入比較籃
    5. 看路線預覽 — corridor 演算法找順路景點(預設 5 km corridor,`STATE.preferences.corridorWidthKm`)+ 計算多點總公里 + 拖 ⋮⋮ 換站順序
    6. 一鍵 Google Maps 多段導航 — 直接丟 Maps app(`maps.google.com/dir/?…` URL),不用手動複製貼

    實例(README 範例):「搜尋觀音山設目的地 → IKEA 新莊距路線 0.44 km ➕ 加入 → 五股 ➕ 加入 → 想加林口三井但 5.13 km 擦邊 → corridor 拉到 6 km → 拖 ⋮⋮ 把林口移到第 1 站 → 一鍵 Google Maps」。

    Place precision contract:景點 vs 圖書館 fallback 策略

    kids-weekend 的距離計算 priority(`getPlaceCoords()` line 2354):

    1. 先查 `PRECISE_COORDS[place.id]` — 有就用
    2. 沒有 → fallback `getCoordsFromArea(place.area)` 取「縣市 + 區」中心點(`TAIWAN_DISTRICTS` lookup,286 個區 centroid)
    3. 都沒有 → null,distance filter 排除

    但圖書館不能 fallback 區中心(本文上方「跨專案 lesson 2」)。圖書館是單一建築,1 km 偏差 = 不同樓棟 = 錯。所以 2026-04-30 圖書館 wave A→C 擴點時,**沒有精確 coord 的圖書館直接 drop,不入庫**(reject 連江縣文化處 / 桃園兒童文學館 / 高雄新興閱覽室 3 筆,因為 Google Maps fallback 到 default pin)。

    Metadata flag 系統 — 怕感冒 / 怕塞 / 失智注意

    每筆景點除了基本欄位(name / area / ages / types / hours / website),還帶 metadata flag 給推薦邏輯參考:

    Flag 含意 影響
    `elder_friendly: true` 長輩友善(平緩、無障礙、有座位) 失智 + 親子混合家庭優先推薦
    `weekend_jam: true` 假日塞車黑名單(陽明山 / 九份 / 淡水) 勾「避開塞車」會排除
    `dementia_caution: true` 失智長輩慎入(動物園 / 大型賣場 / 高 crowd 易迷路) 混合家庭手動觀察
    `crowd: ‘low|mid|high’` 人潮 enum UI「🤧 避開人多景點」剔除 high

    851 筆景點怎麼累積 — 5 wave + 圖書館 wave A→C

    景點不是一次抓進來的,分 wave 增量。每 wave 對應「家附近還缺什麼類型」的 surface gap:

    Wave 主題 +景點
    v3.11 base 親子館 / 公園 / 觀光工廠 主軸 ~770
    v3.12 0-2 歲友善 補嬰幼兒場域(托嬰中心 / 兒童美術館) +8
    v3.13 觀光工廠 DIY 體驗 + 雨天首選 +12
    v3.14 露營區 Glamping + 渡假農場 +10
    v3.15 雲嘉南高屏 南台灣覆蓋補齊 +14
    圖書館 wave A→C(2026-04-30) 縣市總館 + 親子閱覽室 + 文學/繪本 +33

    圖書館 wave 走獨立 pipeline:libstat 國家圖書館抓政府公開資料 → OSM Overpass strict verify(`amenity=library` POI 全台 853 個)→ Google Maps Selenium geocode 補不足 → 縣市 bbox sanity 過濾 → 通過才入庫。三條 source 各補不同覆蓋率,合規(政府開放資料 0 ToS)+ 精確(building-level coord)。

    每個 wave 的關鍵 lesson:**對應實際 user gap,不盲目擴量**。盲目擴點會稀釋信號(user 搜「週末去哪」跳出一堆樓上閱覽室,反而難用)。圖書館 wave 砍 46 筆閱覽室因為「樓上小空間 ≠ destination」,只進 33 筆 high-value。

    場景 6:孩子在家想做活動 — kids-companion

    kids-companion 是 2-6 歲兒童平板學習 app,核心設計是「自適應深度 (Adaptive Depth)」 —— 同一內容,不同年齡,不同深度。4 個年齡層各有版本:

    • toddler(幼幼班 1-2 歲):選項 2、語音題目+選項重複、目標字 140px、無拖拉
    • small(小班 3-4 歲):選項 2-3、語音題目+選項、目標字 120px
    • middle(中班 4-5 歲):選項 3-4、語音題目+hover、目標字 100px、可拖拉
    • large(大班 5-6 歲):選項 4-6、只朗讀題目、目標字 80px

    使用流程:設角色 emoji + 年齡層(toddler/small/middle/large) → 首頁活動卡 → 系統依年齡層自動調選項數 / 字級 / 互動方式。設計哲學在 brain memory `project_kids_companion_philosophy.md`。

    跟陪伴小幫手 v1/v2 關鍵差異:Web Speech API pitch 設定不同。kids-companion `pitch: 1.2`(高頻活潑感吸引兒童);陪伴小幫手 v1/v2 都已校正成 `pitch: 0.95`(老年聽力 presbycusis 高頻損失,低頻反而清楚)。同 API 不同設定,因為使用者生理不一樣。

    場景 7:第一次申請長照 — care-handbook 7 步 SOP

    長照申請新手最大的痛點:不知道要打給誰、要準備什麼、評估會問什麼。care-handbook 直接給 7 步 SOP:

    1. 打 1966(長照專線,免費)→ 報長輩姓名 + 縣市 + 失智症
    2. 等照管專員到府評估(通常 1-2 週內)
    3. 準備評估會問的:長輩 ADL/IADL 量表自評 + 失智診斷書 + 重大傷病卡(如有)
    4. 失能等級判定(2-8 級)→ 對應給付額度
    5. 服務媒合(居服員 / 日照 / 喘息)→ 排面試
    6. 居服員 / 日照面試 SOP:重點問題、紅旗信號、簽約注意事項(handbook 列詳細 checklist)
    7. 失智專屬支援:申請共照中心 + GA07 家屬訓練諮商給付碼 + 巷弄失智據點(這條在 care-handbook 獨立章節,大多家屬不知道)

    handbook 不取代 1966,是讓你打 1966 之前知道要問什麼。直接打 1966 也可以,但你會發現照管專員講的有些聽不懂(BA / CA / GA01-07 給付碼),先看 handbook 心裡有底再打。

    場景 8:選托嬰中心 / 幼兒園 — childcare-handbook

    childcare-handbook 是托嬰中心 + 幼兒園選擇方法論手冊(0-6 歲),不是「找最便宜」「找最近」這種比價工具,而是教**怎麼系統性評估** —— 在報名截止前知道「該看哪些點、該準備哪些東西、該追蹤哪些時間」。

    4 種托育類型(0-2 / 2-6 歲分流)

    • 托嬰(0-2 歲)3 類型:公托 / 準公共 / 私立
    • 幼兒園(2-6 歲)4 類型:公幼 / 非營利 / 準公共 / 私立

    5W1H 評估方法論(Who / What / When / Where / Why / How)

    Handbook H1「🎯 5W1H 評估方法論」拆 5 個 H2:你家是誰 / 選哪一類 / 什麼時候動 / 距離與動線 / 決策框架。每個維度有具體 checklist。

    核心 family mode:`sandwich`(三明治世代) — 全域狀態 `STATE.familyMode` 有 4 個值:`normal` / `sandwich`(同時照顧失智長輩 + 幼兒)/ `dual_income` / `single_parent`。**Tom 家是 sandwich**,工具設計 deliberately 給三明治世代設想:選離長輩家近 vs 離公司近的 trade-off、晚接送對失智長輩晚餐 SOP 的影響、公幼接送時間跟長輩日照時間怎麼對齊。

    state(`localStorage[childcareHandbookState]`):`childAge` enum + `familyMode` enum + `favorites` 收藏園所類型 + `checklist` 文件 / 行動完成度。可匯出匯入 JSON。

    場景 9:陽台種菜 / 觀葉 / 觀花 — garden-handbook

    garden-handbook 是家庭可食 + 觀葉 + 觀花 + 根莖類種植手冊,涵蓋陽台、窗邊、室內盆栽。每個 plant 一個 entry,**統一 10-section 結構 + 5W1H 總覽 + 購物籃匯入**。

    為什麼 garden 在失智照護 monorepo 裡?

    因為 repo 上位 mission「讓整個家忙起來」(ambient engagement)—— 用植物讓家裡有生長中的東西、每天互動的動作、可採可賞的成果。對失智長輩,種植是 behavior redirection 的有效工具:她躁動時遞她澆水器,「來,我們去澆花」是個比「坐下休息」更不抗拒的指令,因為她可以「做有意義的事」。

    10-section 結構 + 5W1H + 規劃模式

    每個 plant entry 統一格式:

    • 5W1H 5 秒總覽:`renderPlantOverview()` 從 meta + sections 自動抽 6 行摘要(怎麼種 / 多久收成 / 適合哪些家)
    • 10-section 結構:選盆 / 選土 / 種法 / 澆水 / 採光 / 病蟲害 / 採收 / 留種 / 失敗訊號 / 跟其他植物搭配 — 每株都這 10 段
    • 規劃模式:設定頁 toggle 開啟,filter 按「家庭模式 / 季節 / 採光」推薦對應 plant
    • 購物籃匯入:一鍵把該 plant 需要的盆/土/工具加入購物清單(連到 brain memory `feedback_starter_kit_ordering.md`「基礎設施先,活體後」原則)

    state:`localStorage[gardenHandbookState]` — 最愛 / 購物籃 / 規劃模式 / 照護級數 / memos,可匯出匯入 JSON。

    場景 10:讓家有「會主動靠近的成員」 — pet-handbook

    pet-handbook 是家中寵物生活手冊,按 6 個物種分類:**貓 / 狗 / 兔 / 鳥 / 魚 / 烏龜**。每物種下有多個 topics(親訓 / 飼料 / 醫療 / 訓練)。

    跟 garden 的 frame 區別 — 寵物是會主動靠近的家人

    核心定位:寵物是會主動靠近你的家人。跟植物不一樣 —— 他會自己跳上你腿、用頭頂你手、發出呼嚕聲。他不是被動被照顧的對象,**是家庭成員**。

    對失智長輩尤其重要 —— 當她大腦退化、溝通困難,一個會自己靠近的生命,是「她還被需要、她還存在」的證明。garden 是 ambient(植物在那裡),pet 是 active(寵物來找你)—— 兩者並用補不同層次的 family vitality。

    對小孩:寵物從小同住的孩子發展(empathy / 責任感 / motor skills)有 evidence-based 好處。混合家庭(失智長輩 + 幼兒 + 寵物)是 monorepo 主場景之一。

    場景 11:照護判斷迷茫時 — mindset(6 條視角)

    mindset 是「心法手冊」 — 不是 SOP、不是 checklist,是一位失智照護者面對新狀況時,腦袋裡跑的判斷視角。中英雙語(zh + en),開源歡迎其他家屬補充。

    6 條視角

    • 視角 1:失智不是失能 — 她不是壞了,是用不一樣的方式運轉
    • 視角 2:用加法對抗減法 — 認知衰退是減法,加新刺激抵銷
    • 視角 3:躁動不是無聊 — 行為背後通常有具體 trigger(尿急、肚子餓、燈太亮)
    • 視角 4:動線是功能可及性 — 她做不到不一定是失能,可能是動線設計
    • 視角 5:誠實版優於善意包裝 — 不要編故事騙她,她感受得到
    • 視角 6:手冊是網狀不是清單 — 沒有「按順序做完」這種事

    caveat 自註:Handbook 自己寫了「⚠️ 不要把任何視角當絕對」 —— 「這 6 條視角是我寫家中照護手冊時用的判斷方式,不是失智照護的真理」。比如「視角 2 加法對抗減法」跟主流的「懷舊治療(Reminiscence Therapy)」(用過去記憶喚起情感連結)有衝突。Tom 在文章明文承認這個衝突。

    這個工具不解決具體問題,而是在其他工具給不了答案時,**回頭問:我用什麼 frame 在想這件事?** Handbook 是網狀的,在失智路上某些時刻會用上。

    場景 12:長輩 / 病人 / 嬰兒選營養品 — health-drinks

    health-drinks 是19 款醫療營養品 + 嬰幼兒配方 + 高蛋白補充品的並排比較工具(180-280ml 容量範圍)。**不是市售飲料**,是給病人 / 長輩 / 嬰兒喝的營養補充品(葡勝納 / 完膳 / 安素 / S-26 / 倍速益 / 康健等)。

    三重使用者

    • Tom 自家 — 失智媽媽吞嚥退化階段選低糖高蛋白配方
    • 藥師朋友 — 跟客戶解釋「葡勝納原味跟菁選香草」差別時要快速比成分
    • 藥局客戶 — 拿出手機看比較表自己挑(藥師沒空講)

    資料流:拍包裝 → AI 擷取 → 手填 drinks.js

    每加新飲品的流程:

    1. 藥局買回來拍包裝側標籤
    2. AI(Gemini / Claude)從圖片擷取營養成分
    3. **手填**到 `data/drinks.js`(brain memory `health-drinks-data-entry.md` 「拍標籤說『加進去』就全填,包含微量元素,不可自行省略」原則 — `feedback_nutrition_label_fulldata.md` lesson)
    4. UI 並排比熱量 / 糖 / 鈉 / 蛋白質 / 脂肪 / 維生素 / 礦物質

    monorepo 唯一 CDN 例外:health-drinks 較早建置仍用 Chart.js + Google Fonts CDN(Noto Sans TC)。圖表呈現用 Chart.js 4,字體用 Noto Sans TC。違反 monorepo 0 CDN 強制規定 —— 計畫之後遷移成 inline,但目前留著作為「歷史包袱」example。新工具不准走這條路。

    何時不該用工具,直接找專業

    工具看到「預期外的 pattern」就停用,改找專業。具體訊號:

    訊號 該找誰 為什麼
    突然拒食 ≥ 3 天 神經科 / 急診 可能是 UTI / 吞嚥退化 / 譫妄,不是「沒胃口」
    行為驟變 24 小時內 急診先排除 UTI 中老年 UTI 常表現為譫妄不是發燒
    跌倒 119 / 急診 頭部撞擊、髖關節骨折看似輕微會延遲爆發
    照顧者撐不住 1925 安心專線 / 共照中心個管師 Burnout / 預期性悲傷有專業 evidence-based 支援
    小孩發燒 ≥ 39°C 連 2 天 兒科 / 急診 tools 不會幫你看川崎 / 流感 / 腸病毒

    原則:工具是 baseline 操作,異常事件外溢就 escalate。不要用「我家工具上看了沒問題」當不去看醫生的理由。

    工具互鎖:資料閉環怎麼運作

    14 個工具裡不是每個都獨立。失智照護核心 4 個工具串成 daily/weekly 閉環:

    每天:
[居服員 / 我] 寫白板 → 拍照傳 Telegram
    ↓
[白板 OCR Bot] Gemini OCR + confirm
    ↓
[iDempiere Z_momSystem] 每天一筆紀錄

每月:
[mom-clinic-companion] 拉一個月紀錄
    ↓
產出回診清單 → 神經科看具體 evidence
    ↓
醫師調藥決定寫回 iDempiere

每月共照中心月聚:
[care-handbook 援手系統] 個管師有資料看可以諮詢
    ↓
社工 / 物理治療 介入決定

    關鍵設計:資料只進 iDempiere 一次,各工具讀同一個 source。不是 OCR Bot 一個資料庫、mom-clinic 另一個資料庫 — 那會分裂。所有寫入收斂到 iDempiere,所有讀取從 iDempiere 出來。

    iDempiere 是台灣 open source ERP,我把它當 PHR (Personal Health Record) 用。對家庭規模 overkill,但有 Z_table 自訂 + REST API + audit log 的 enterprise 級資料管理,這條主線運轉半年沒掉資料。

    不是處方,是 invitation

    這套工具不是處方。每家狀況不同 — 有的家有外籍看護工、有的家三代同堂家屬 backup 充足、有的家在偏鄉服務不完整。我家是「白天 solo + 配偶藥師有正職 + 兒女幼小 + 父母 secondary 經驗 15 年」這個極窄 niche,所以工具 design 偏向「降低 solo 啟動 friction」。

    如果你家狀況跟我接近,這套工具開箱可用;不接近,把它當「一個照護者怎麼設計自家工具」的 reference,fork 改成你家用的。原始碼在 GitHub,部署在 tm731531.github.io/dementia-care。

    有相關問題歡迎在 blog 留言 — 工具不主動推,但方法 / 經驗 / 踩過的坑歡迎交流。

  • 失智家人確診後的第一週,先做這 5 件事(法律/醫療/防走失 完整清單)

    核心原則

    • 法律跟醫療有「清醒窗口」,錯過就要打官司補救
    • 物理改造(扶手、夜燈、白板)永遠可以補
    • 第一週只做前 5 件,其他延後

    失智家人剛確診,要做的事情太多容易失序。這份清單按時間緊迫性排,越早做越好的放前面。每一項標明為什麼要做、不做會怎樣、具體步驟。

    第一週(5 件事)

    1. 意定監護契約 · 法院公證

    • 要做什麼:帶她去戶籍地地方法院公證處簽契約,指定你當她未來的監護人
    • 為什麼:台灣 2019 民法新增制度。她清醒時指定 = 她說了算;不做的話日後要打「監護宣告官司」
    • 前提:本人要能簽字、能答話(清醒窗口)
    • 費用:
      • 意定監護(清醒時做):NT$1,000-3,000(公證費)
      • 監護宣告(沒做意定的後備方案):NT$6,000-18,000 = 法院宣告費約 NT$1,000-3,000 + 精神科鑑定費 NT$5,000-15,000(還要等 3-6 個月)
    • 順便做:預立醫療決定書(插管/急救意願)
    • 時間成本:一個下午

    2. 每家銀行設「親屬代理人」

    • 要做什麼:帶她到每家銀行臨櫃,設定「常用代理人」或「親屬代理人」
    • 為什麼:失智診斷書送銀行 = 帳戶凍結(銀行依規定保護她)。沒設代理人,電費醫藥費保險理賠錢動不了
    • 前提:本人親自簽名
    • 範圍:所有銀行 + 郵局(老人家最多帳戶的)
    • 同時拿到:印鑑、存摺、網銀密碼

    3. 神經科初診 + 拿診斷證明

    • 要做什麼:這週內掛神經科,做 MMSE/CASI/CDR 基線測驗,當下就跟醫生要書面診斷證明
    • 為什麼:基線越早做,半年後醫生才能判斷退化速度。診斷證明是所有補助/權力的入場券
    • 診斷證明能啟動的事:
    用途 效益
    身心障礙手冊停車證、大眾運輸半價、稅務減免
    長照 2.0 申請照服員、喘息服務、輔具補助
    保險理賠長照險、失能險
    意定監護家事法庭要求
    所得稅免稅額每年可省幾萬
    • 注意:鎖定一位神經科醫師長期追,不要醫院跳來跳去,病歷無法累積
    • 費用:診斷證明影印費 NT$100-200

    4. 身份文件交接 + 備份

    • 要做什麼:趁她清醒,問清楚所有文件/帳號的位置,拍照備份到家庭文件夾(Google Drive + 紙本)
    • 為什麼:她忘了密碼、印鑑藏哪、保單編號,你日後什麼都動不了
    • 🔑 印鑑章 + 印鑑證明(戶政事務所辦)
    • 🆔 健保卡、身分證、護照、戶口名簿正本
    • 🏦 銀行存摺、保單正本、定存單
    • 🏠 房屋權狀、地政文件
    • 💰 網銀、股票帳戶、保險 app 的帳號密碼

    5. GPS 追蹤 + 門禁警報

    • 要做什麼:裝 AirTag + 門窗感應器 + iPhone 家庭共享位置
    • 為什麼:失智初期最大風險是走失 — 她體力好能走遠,判斷力已退化,走出社區就回不來
    • 具體清單:
    設備 數量 費用 用途
    AirTag2 顆NT$2,000皮夾 + 常穿外套縫口袋
    Aqara 門窗感應器1 組NT$300夜間開門推播到 iPhone
    iPhone 家庭共享位置全家免費外出時定位

    第二週 – 第一個月(補強清單)

    前 5 件有清醒窗口的急迫性,這些沒有(她失智後你也能處理),但都要做:

    台灣長照制度硬資訊(按流程順序)

    1. 打 1966 長照專線(免費) — 撥過去預約居家評估,約 1-2 週後照管專員到府。準備好:診斷證明影本、身分證、健保卡、家屬聯絡方式。這是啟動長照 2.0所有服務的入口。詳見 長照 3.0 完整申請流程。
    2. 找當地失智共同照護中心(免費) — 台灣每縣市都有,衛福部網站可查。提供個案管理師(免費 1 對 1 諮詢)、家屬支持團體、照顧技巧課程。比網路亂查資料有用很多。
    3. 申請身心障礙手冊(戶政事務所)— 需診斷證明。核發後有:停車證、大眾運輸半價、稅務減免、身障生活補助(依程度 NT$4,872-8,836/月)。
    4. 啟動喘息服務補助(長照 2.0 底下) — 輕中度每年最高 NT$32,340、重度最高 NT$48,510(2024 年級距),可用於短期住宿式 / 日間照顧 / 居家照顧,讓你喘口氣。很多家屬都不知道這個有。
    5. 保單盤點 — 查她被保過什麼險,長照險/失能險/重大疾病險符合條件直接啟動。

    居家硬體改造

    • 浴室防滑扶手 + 夜間動線夜燈 — 防跌倒
    • 瓦斯爐改電磁爐 / IH — 避免忘記關火
    • 清潔劑、刀具、酒類上兒童鎖 — 防誤食/誤用
    • 藥盒固定位置 — 一週 7 格藥盒貼冰箱門,有日期刻字
    • 白板 6 欄位每日紀錄 — 睡眠/精神/陪伴/活動/排泄/飲食,每晚填。這會是下次回診跟醫生對話的 baseline

    最後順序提醒

    錯誤順序:先花兩週裝夜燈扶手,結果第三週銀行帳戶凍結,錢動不了。

    正確順序:第一週跑法院 + 銀行 + 神經科,文件交接完、GPS 裝好;第二週以後再做家裡硬體改造。

    相關工具(免費開源)

    相關文章

  • 失智長輩為什麼一直到處走:她在找的不是這個家

    重點摘要

    • 失智長輩最常出現的畫面不是躁動、不是忘記 —— 是抱著疊好的衣服到處走。我花了半年才懂這個動作在講什麼。
    • 她拿著抹布到處走、拿著澆花器到處走、晚上獨自跑去找親戚家 —— 都是同一件事:她在找家。
    • 她腦袋裡的家大概率不是我這間公寓,是她童年在遠方那個家族小餐館。
    • 家族的長輩當年也失智過,那時候家族女性長輩同時撐起生意跟家 —— 我是這個家族第三代做這件事的人。
    • 家裡 11 項環境改造,底層是一件我一開始沒想到的事 —— 幫一個想回家的人指路。

    晚上,家裡的長輩抱著剛疊好的衣服,在家裡走來走去。

    她不是要去衣櫃。衣櫃就在那邊,她看得到。她也不是迷路 —— 我們家就這麼大,她閉著眼睛都走得完。她抱著那疊衣服,緩慢地、有目的地從客廳走到房間再走回來。

    這個畫面我看了很多次,半年後我才慢慢想明白 ——她在找一個你可能不知道的地方。這篇是我這半年陪她的筆記,從一個失智長輩「到處走」的畫面開始,繞到一間遠方 50 年前的家族小餐館,最後回到我自己這一代。

    如果你想看這半年我做了哪些硬體改造、踩過哪些誤會(早餐、日照、白內障),請看前作 《失智照顧半年的三個誤會》。這篇是那篇的下篇 —— 講我慢慢發現,她到底在找什麼。

    「到處走」不是一個症狀,是三個畫面的疊加

    我照顧她這半年,有三個畫面一直重複出現:

    • 我請她擦桌子 —— 她拿著抹布到處走。
    • 我請她澆花 —— 她拿著澆花器到處走,找不到水龍頭。
    • 她疊完衣服 —— 她抱著疊好的衣服到處走。

    一開始我以為是三個不同的狀況,各自處理。後來把這三個畫面並排,才發現它們是同一個症狀 —— 只要她手上有東西、但不知道「下一個動作該去哪」,她的大腦就會輸出「走」。

    「到處走」是她的大腦在找一個地方。不是隨機的。

    黃昏症候群不是躁動,是想出門

    1 月的時候,我發現她一到傍晚就會變得比較焦慮、想往外走。

    如果我帶她中午出門,下午可以順利回來。但如果我傍晚或晚上帶她出去,她就會在外面待著不想回來,怎麼牽都難帶回去。所以我把外出時段改到中午,晚上的長照只負責給飯。

    這個醫學上叫日落症候群(Sundown Syndrome),失智長輩很常見。但我想在這篇講一個更具體的事件:

    2025 年年底,她失智已經很明顯,晚上她獨自出門,跑去一位還在的親戚家過夜。

    這件事的分量,不是她「走失」。她沒走失 —— 她自己找到那家人的家、跟對方說要住、住了一晚。她在失智的狀態下,仍然記得:

    • 有這個人
    • 知道對方住哪裡
    • 有強烈的動機要去找對方

    她在找的,是她的手足、她童年家庭裡剩下的那個人。

    這件事發生之後,我才慢慢接受一個事實 —— 她要回的那個家,不是我這間公寓。

    她最早的家 —— 一個遠方的家族小餐館

    她的童年不在這個家,不在這個城市,甚至不在這個國家。

    更精準地說,是一個家族在異鄉開的小餐館。移民、異地、同鄉圈、家族事業 —— 這是那個時代東亞很常見的家族形態。

    那家餐館是家族長輩開的。她不是「在那裡工作」,是在那裡面長大。高中的時候她還幫忙家裡做一些雜務跟外送。

    那家餐館是家族幾個兄弟姊妹共同的童年。她是其中一個夾在中間的孩子。

    當我意識到這件事的那一瞬間,很多事情開始合在一起:

    • 她失智之後還能完美地疊衣服 —— 做過多年母職,疊衣服是幾萬次重複過的動作。
    • 她失智之後剝蒜頭剝豆芽也沒問題 —— 家族餐館後廚從小到大的前置動作。
    • 她以前算帳能力很好 ——那可能不是後來學的,是從小看家族生意收銀延伸出來的手感。算錢+分類+歸檔的手,根在童年場景裡。
    • 她現在失智會「到處走」—— 在家裡繞、拿著東西走、晚上想出門 ——如果她腦袋裡的「家」是那個遠方的家族餐館,那她不是在迷路,她在找回去。

    失智這件事在醫學上有很多說法,但這個病最殘忍的地方是 —— 它會把一個人帶回她最早的家,然後讓她發現那裡的人都不在了。

    這個家的女人,輪流做這件事

    但這個故事還有更深的一層。

    她的父親 —— 家族上一代的男性長輩 ——當年也失智了好幾年。

    我不知道具體什麼時候,我沒親眼見過;是家族親戚後來告訴我的。那位長輩失智後,家族的女性長輩接手了整個家業,同時:

    • 照顧失智的伴侶
    • 經營家族生意
    • 帶好幾個年齡差距很大的小孩

    當時那位女性長輩做的事,跟我現在做的事是一樣的:讓一個失智的人有事可做、讓家裡安全、讓自己還有力氣撐下去。她那個年代沒有 ChatGPT、沒有日落症候群這個詞、沒有長照中心 —— 她只有一家店、一群小孩、跟堅持。

    而我現在照顧的這位長輩,就是在這個畫面裡長大的中間那個孩子。

    她這輩子後來也做了多年母職、煮飯、幫家裡算帳、照顧伴侶。她的人生模式,其實是在複製她母親的模式 —— 當那個撐家的女人。她自己可能沒特別意識到,但身體記得。

    上一代女性長輩撐她丈夫 → 我這一代照顧的長輩當年撐她丈夫 → 我現在撐她。

    這個家的女人(跟我這個第三代)輪流做這件事,已經第三輪了。

    11 項環境改造,本質是幫她指回家的路

    這半年我在家改了大概 11 項硬體。當我把這 11 項放在「她在找家」這個框架下看,意義整個不一樣:

    改動 表面做了什麼 底層意義
    廁所門拆成布簾 避免她找不到廁所 給她一個看得到的「這裡是廁所」訊號
    家具改成迴圈路線 讓她方便走 給她一個不用決定方向的路徑
    衣服故意打散在沙發邊(不能被她看到我擺) 製造「要整理」的任務 給她一個她熟悉的「工作站」
    大門用隔音棉大量遮蔽 不讓她容易看到/聽到出口 降低她晚上出門找家的衝動
    外出時段改中午 避開黃昏症候群 在她想出門之前就先帶她出去
    剝蒜頭/剝豆芽/疊衣服 這三個活動 讓她身體有事做 把她最早的肌肉記憶還給她

    最後那一條,其實是整個故事的核心。剝蒜頭、剝豆芽、疊衣服 —— 這不是我發明的「失智活動」,這是她的身體從童年那個家族場景帶出來的東西。她現在用這些動作在找她的家。我只是幫她搭了一個半新半舊的場景,讓她手上的動作不會被現代生活打斷。

    你能為失智長輩做的事,可能不是你以為的那些

    我不是失智專家。我只是一個照顧者,半年的時間、一位長輩、一個家。

    但這半年我學到最重的一件事是:失智長輩需要的不是「我們這個世界的合理」,是「她那個世界的錨」。

    你有沒有想過:

    • 她年輕時最常做的手部動作是什麼?
    • 她童年住的是什麼樣子的家?
    • 她還記得誰的名字?你可不可以讓那個人出現一下(電話、視訊、短暫拜訪)?
    • 她腦袋裡的「家」有哪些味道、聲音、顏色?你家能不能留一點這些?

    我現在每天剝蒜頭給她做。她坐在那邊,手自己會動。她不會告訴我她在想什麼,但我知道她坐在童年那個家族餐館的後廚裡,父親還在、母親還在、哥哥姐姐都還年輕、她十幾歲、沒人失智、家還是完整的。

    那個家我去不了,但我可以讓她的手,替她回去一趟。

    🔧 我還寫了一些工具

    這半年我除了改家,還寫了幾個工具給自己用。規則跟我改家是同一條 —— 把決定從疲憊的大腦外包到系統。只是一個對失智長輩、一個對照顧者自己。

    背後還有一個我自架的 iDempiere 開源 ERP,讓紀錄可以統一、一致、事後找得到 pattern。工具清單、資料閉環設計、為什麼不用 Firebase/Supabase —— 這些都寫在 上篇的「同一條規則,我用在自己身上」章節。

    這半年我還整理了兩本 handbook,補「我改家」的兩個延伸方向 —— 園藝讓家有在生長的東西、寵物讓家有主動靠近的家人。不是一般園藝書/寵物書,是失智照護家庭特有的考量:

    • 📗 家庭園藝手冊 — 可食植物(地瓜葉、九層塔…)+ 觀葉植物(虎尾蘭、黃金葛…)。每個 entry 附「失智照護 3 級應用」,例如為什麼地瓜葉的澆水 ritual 比其他活動有效、虎尾蘭為什麼是照顧者的喘息後援
    • 📙 寵物手冊 — 6 物種 × 每種 7 topics + 失智照護 × 寵物選擇 matrix(哪些物種不建議失智家庭新養,例如大型犬運動量、烏龜 50-100 年壽命的接班問題)。含「人畜共通疾病 × 失智長輩特殊風險」跟「每月驅蟲藥注意」兩篇照護者實用章節

    寫在最後

    家族的男性長輩失智,女性長輩撐了好幾年。我現在照顧的這位長輩是那個畫面裡的中間小孩。現在輪到我。

    這個家的女人,輪流做這件事,做了三代。但我可能是第一個能寫下來的人 —— 不是因為我比較聰明,是因為我這一代有鍵盤、有部落格、有能力把這些事公開。

    如果你家也有失智長輩,我希望這篇文章幫你看到一件事 —— 她抱著東西走來走去的時候,不要只是嘆氣。她在找一個地方。那個地方你可能不知道在哪,但你知道這件事之後,你做的每一個改動都會不一樣。

    謝謝你看到這邊。

    延伸閱讀:《失智照顧半年的三個誤會:從菠蘿麵包、日照失敗到白內障》(上篇)、我之前另一篇失智照護相關文章、《日落症候群:6 大預防策略》。

  • 失智照顧半年的三個誤會:從菠蘿麵包、日照失敗到白內障

    重點摘要

    • 誤會一:早餐要吃什麼 — 我給菠蘿麵包是因為我自己這樣吃,後來才發現要換成燕麥、雞蛋、香蕉。
    • 誤會二:日照送不進去就算了 — 送日照失敗三次後我差點放棄,後來才發現真正要偷的是「日照在做什麼」。
    • 誤會三:她在廁所地上拉大便 = 失智退化 — 我煩惱了快三個月,最後真相是白內障,她看不到白色馬桶。
    • 半年 11 項環境改造,底層只有一條規則:她大腦掉的不是動作,是「下一步去哪」的能力。

    2025 年 10 月,我開始介入家裡長輩的失智照顧。那時候家裡給藥很亂,「什麼藥都早上一次給」,我看不下去就分成早、晚、睡前。這個小小的介入起頭之後,後面半年我改了家裡大概 11 項硬體、定了兩套 SOP、試過失敗過十幾個活動。

    但這篇不是講 SOP,是講我誤會過的三件事。失智照顧這半年,我發現最需要被寫下來的,不是我做對了什麼,是我以為是 X、其實是 Y 的那三個轉彎。每個轉彎都讓我重新理解這個病。

    誤會一:以為她就跟我吃一樣的早餐

    最早我給她的早餐是菠蘿麵包。原因很簡單 —— 因為我自己就這樣吃。我甚至沒想過這是個決定。

    但失智的人需要的營養不是「什麼都沒有的澱粉」。我後來改成:

    • 無糖豆漿
    • 雞蛋(用煮蛋器前一晚設定 P3、定時 9.5 小時,隔天早上自動煮熟)
    • 燕麥片(麥片盒上的圓蓋一滿匙)

    這個誤會之所以重要,不是因為菠蘿麵包「不營養」。而是這是我半年下來第一個、也最小的那個轉彎 —— 我發現照顧失智的人,不能用「我習慣這樣」當標準。她的需求跟我不一樣,我必須先承認這件事。

    後面所有比較大的誤會,其實都是這個誤會的延伸版本。

    誤會二:送日照送不進去,就算了

    2025 年 12 月中。那時候我最怕的事情是她一整天躺著 —— 怕她越躺著失智越快。

    我嘗試送她去日照中心,失敗了。家屬帶去她就回頭、大吵,根本進不去。我差一點就結論:「日照不適合她,這條路斷了。」

    但我停下來想一個問題:日照中心到底在做什麼?

    我去看了幾家、觀察他們的日常。我發現他們在做的事其實不特別:

    • 看影片
    • 做手作
    • 重新認識一些東西
    • 一直詢問每個個案的背景,想從中找出蛛絲馬跡讓這位長輩多做一點

    最後這一條是我偷到的方法論 ——日照中心其實在做的,就是「找出這個長輩一輩子做過最多的動作,然後讓她在這裡做」。

    我回家重新看她。她這輩子做了很多年家務,洗衣、疊衣服是幾十年的日常。我做了個實驗 —— 給她一籃衣服讓她疊。

    五分鐘之內疊好,大小、尺寸、方向跟以前一模一樣。

    所以我沒有放棄日照,我把日照的邏輯搬回家。我的做法不是什麼厲害的概念 —— 就是分散她的注意力、讓她的身體有點事情做。這個做法後來叫出了一整套「在家可以做的事」:

    我試過的活動 結果 失敗的樣子
    剝蒜頭 ✓ 主力 —
    剝豆芽 ✓ —
    疊衣服 ✓ —
    洗碗、洗鍋子 ✗ 自動放棄
    澆花 ✗ 找不到水龍頭,拿著澆花器到處走
    擦桌子 ✗ 拿著抹布到處走
    分豆子(綠豆+黃豆) ✗ 最早一次成功,後來都撒在一起當結束

    失敗的那些,每一個畫面都幾乎一樣 ——她手上拿著工具,但不知道下一步去哪。成功的那些,每一個畫面也都一樣 ——坐著、東西就在眼前、手自己會動。

    這裡藏了一個規則,等等會用到。

    誤會三:她在廁所地上拉大便 = 失智退化

    2026 年 1 月開始,最嚇人的事情發生了。

    她開始到處拉大便。甚至已經在廁所裡了,她還會拉在地板上。我煩惱了快三個月。那三個月我懷疑過:

    • 她是不是失智退化更快了?
    • 她是不是在抗議什麼?
    • 是不是腸胃出問題?

    那段時間很多人告訴我應該要加藥。我幾乎要聽進去了。如果我去加藥,我現在可能還在誤會裡。

    長照人員那句話,把我從醫療路線拉回來

    轉折是我家的長照人員的一句話。她跟我說:

    「可以帶她去日照試試看。」

    我立刻回:「她之前去日照失敗。」

    她說:「可以讓長照人員來幫忙帶,不用家屬帶 —— 因為之前是家屬帶失敗的,你們要區分清楚。」

    這句話把問題整個翻過來 —— 我以為失敗的是「日照這條路」,她指出失敗的其實是「家屬帶的這個方式」。剛好家附近今年新開一家日照,我們決定試。

    日照入照前要體檢。

    體檢當天,0.3 的視力

    體檢當天,視力測出 0.3。是誰都看得出來視力差。我當天馬上掛眼科。眼科醫生看了,確認白內障。

    所有的拼圖這一刻合起來:

    • 她在廁所地上拉大便,不是她失禁、不是退化、不是抗議。是她看不到白色馬桶。
    • 她去陽台、廚房小便,是她找不到廁所。白色的家具她分不出輪廓。
    • 白色水煮蛋放在白色衛生紙上,她不吃;紅殼蛋她會吃。看不到 = 不存在。

    前三個月我的方向全錯。真相是體檢意外撞到的。如果不是長照人員那句 reframe,我可能還在加藥的錯誤路徑上。

    白內障之後的環境改造

    確認白內障之後,我做了一系列視覺改造:

    • 馬桶加上彩色圈(同顏色她看不到)
    • 廁所門拆掉改成布簾(看到布簾後面的輪廓,她直接進去,不用「推開門」這個步驟)
    • 白色水煮蛋改放在有顏色的盤子上

    這三個小動作做下去之後,她廁所拉地板的問題大幅改善。

    半年學到的那條規則

    回頭看,這三個誤會背後都指向同一件事 ——她大腦掉的不是動作,是「下一步」的能力。

    這個「下一步」有兩層:

    1. 感知層的下一步:她看不到馬桶、看不到白色蛋 —— 看不到 = 不存在 = 沒有下一步可走。
    2. 認知層的下一步:她拿著抹布找不到「去哪擦」,拿著澆花器找不到「水龍頭在哪」,疊完衣服不知道「放進哪個衣櫃」 —— 所以她就抱著疊好的衣服到處走。

    這半年的 11 項環境改造,底層其實是同一件事:把她該做的決定,從她大腦外包到物理空間。

    改動 外包了哪個「下一步」
    廁所門拆成布簾 不用決定「要不要開門」
    馬桶彩色圈 「坐這裡」直接看得到
    家具擺設改成迴圈 不用決定「往哪走」
    定時器開燈/風扇 不用決定「現在該開了嗎」
    故意打散衣服在沙發邊 「這裡要整理」的訊號讓環境去發
    紅殼蛋取代白殼蛋 「這裡有食物」的視覺訊號

    如果我早點知道這條規則,前三個月的廁所問題可能一個月就解了。但沒辦法,規則是被我誤會三次之後才長出來的。

    給其他照顧者的三個提醒

    1. 不要用「我習慣這樣」當起點 —— 菠蘿麵包給她,是因為我自己這樣吃。這是誤會的源頭。
    2. 路徑失敗不代表方向失敗 —— 家屬帶日照失敗,不代表日照不能用。這個 reframe 我是從長照人員那邊聽到的,我自己想不出來。
    3. 行為異常(尤其是大小便)先排除感官問題 —— 不要第一時間想「失智退化」或「加藥」。先帶去眼科、耳科體檢。我花了三個月才做這件事。

    🔧 同一條規則,我用在自己身上

    這條「把決定外包」的規則,對照顧者自己也一樣 —— 甚至更關鍵。

    照護這件事最難的不是體力,是精神力。一天裡真正能好好做決定的時間有限,所以我寫工具的核心邏輯就這三句:

    1. 我要拯救為數不多的精神力、專注力、時間 — 每個決定都不該讓大腦再跑一次
    2. 紀錄是我的習慣,統一跟一致化才能修正 — 沒有結構化資料就沒有 pattern
    3. 最花精神的不是執行,是「每天要想話題」 — 陪伴不是體力活,是創意活

    這三句話各自長出了三組工具。

    動機 1:精神力有限 → 每個工具省掉一個決定

    當下會耗掉精神力的事 我的外包方案
    每天跟她玩什麼? 陪伴小幫手 v1 — 15 遊戲 × 8 難度,不用自己設計今天玩哪個
    每天要跟她聊什麼? 陪伴小幫手 v2 — 一鍵推薦 + 45 條陪伴指南
    居服員白板寫了什麼要人工歸檔? 白板 OCR Bot — 拍照 → Gemini OCR → 自動寫進系統
    回診前要熬夜翻月報? 就診小幫手 — 規則引擎跑異常,5 分鐘前打開看「這次要問醫生的 3 件事」
    在藥局當場查營養品成分? 健康飲品分析 — 21 款並排、per 100ml 自動換算
    想用植物讓她每天有事做? 但我不懂園藝 家庭園藝手冊 — 可食植物 + 觀葉植物,每個 entry 附失智照護 3 級應用(地瓜葉為什麼適合、虎尾蘭給照顧者喘息)
    想養寵物陪她,但不知道會不會變負擔 寵物手冊 — 6 物種(貓/狗/兔/鳥/魚/龜)× 每種 7 topics + 失智照護 × 寵物選擇 matrix(含哪些物種不建議失智家庭新養)

    動機 2:統一跟一致化 → 為什麼背後要有一個 iDempiere

    很多人看到「Telegram Bot + Gemini OCR + 規則引擎 + iDempiere」會覺得是技術炫技。真正的理由很單純:

    我的記性不夠,系統必須替我記 —— 而且要記成「事後找得到 pattern」的形式。

    紀錄要「統一、一致」的意思不是「我每天記得寫」,是「欄位格式永遠一樣,系統才能跨天比對」。這件事 Excel 做不到(欄位亂加)、Notes App 做不到(算不了)、Notion 做不到(沒 schema 強制)。必須是結構化資料庫。

    為什麼我選 iDempiere,不是 Firebase / Supabase / Airtable?

    iDempiere 本質是開源 ERP,拿來當失智照護後端聽起來怪,但三個點全部打中我要的:

    1. AD(Application Dictionary)設計 —— 擴充像加 Excel 欄一樣快

    新增欄位不用寫 SQL、不用跑 migration。在 AD 裡拉一個欄位,UI、REST API、報表全部自動生出來。失智照護的追蹤項目會一直變動:這個月發現血壓要追、下個月發現排便規律要量化、再下個月發現情緒要分早晚。AD 讓我加欄位就像加一欄 Excel,但拿到的是完整的資料庫 + API + 權限系統。

    2. 內建 REST API —— 我不用寫 backend

    加完欄位 GET /api/v1/models/Z_momSystem?$filter=... 立刻可用。不用管驗證、不用管 serialization、不用管 CORS(裝個 filter 就好)。我的工具裡沒有一行 backend 程式碼是我寫的 —— 前端直接 call iDempiere API。這讓我的精神力可以花在真正的問題上(規則引擎、UI、使用情境),而不是重新發明一個 backend。

    3. 開源 + 自架 —— 資料不出家

    整個系統跑在我自己的伺服器,沒有任何 SaaS 在中間,沒有「你的資料被拿去訓練 AI」的疑慮。這一條對我來說比效能還重要。前面提過,家人的資訊不能丟到我不知道的雲端去 —— 這不是偏執,是第一原則。Firebase/Supabase 方便,但資料在別人家。

    這三點組合起來讓擴充變得很快。每發現一個新痛點,通常半天內就能多一個 iDempiere 欄位 + 一個前端小工具連上去。這是為什麼這條工具鏈在半年內可以長出四個工具,而不是我每做一個新工具就要自己刻一套 backend。

    資料流(閉環長這樣)

    居服員每天在廚房白板寫 12 個追蹤項目
(夜間活動 / 睡眠 / 早/午/晚餐 / 活動 / 外出 / 陪伴 / 排泄 / 洗澡 / 情緒 / 異常事件)
         ↓
我用手機拍白板 → Telegram Bot → Gemini OCR 辨識磁鐵位置
         ↓
寫進 iDempiere Z_momSystem(每天一筆 × 12 個結構化欄位)
         ↓
30 天累積 → 規則引擎跑 4 種異常偵測:
  · window comparison(當前窗口 vs 上窗口差異)
  · co-occurrence(同日多症狀同時出現)
  · streak(連續 N 天某狀態)
  · chronic(本月累積超過門檻)
         ↓
回診前 5 分鐘打開就診小幫手 → 「這次要問醫生的 3 件事」

    這個閉環其實在前面的白內障故事裡出現過 —— 如果沒有 iDempiere 裡 30 天的結構化資料,體檢撞到 0.3 視力之後,我在眼科問不出什麼具體問題。規則引擎讓那些「感覺她最近怪怪的」的模糊印象,變成「她這兩週排泄時間比上個月晚了 2 小時」這種醫生能用的資訊。

    動機 3:最花精神的是每天要想話題 → 為什麼 v2 長那樣

    這一條是我半年下來最深的自我反省。

    我寫 v1 的時候假設「照護者會從 10 格遊戲裡挑一個」。半年後我發現 —— 我自己就是那個不想挑的人。

    「每天要想新話題、新遊戲、要怎麼陪她」這件事,會把一天剩下的精神力全部吃光。不是陪伴本身累,是每天從零開始想要怎麼陪這件事累。

    所以 v2 不是新遊戲,是「系統替你挑」:

    • 依時段 + 當前難度 + 最近玩過的 → 直接推薦一個
    • 每個遊戲配 3 條陪伴指南(進入時說什麼、答對時說什麼、完成時說什麼)= 45 條可說的話
    • 完成後自動產生 LINE 可貼的每日摘要(給沒在現場的家人看)

    v2 的核心不是新功能,是對 v1 假設錯誤的反省 —— v1 假設大腦有能量挑,v2 假設大腦沒能量挑。

    這個 v1 → v2 的演化,跟我在家把衣服「打散在沙發邊讓她自己去整理」是同一個動作 —— 把「要做什麼」的訊號從大腦拿出來,放到環境/系統裡。

    底線:為什麼全部都是純前端 + 自架後端

    • 純前端 HTML + JavaScript,手機打開就用,沒 App 要裝
    • 沒帳號、沒廣告、沒追蹤
    • 資料不會上傳到任何地方(就診小幫手的 iDempiere 是跑在我自己的伺服器上,不是雲端 SaaS)

    家人的資訊不能丟到我不知道的雲端去。這是第一原則。

    工具總集(持續擴充):https://tm731531.github.io/dementia-care/
    原始碼:https://github.com/tm731531/dementia-care

    這篇是上篇,講我在照護這件事上的學習曲線。下篇《失智長輩為什麼一直到處走:她在找的不是這個家》講的是這半年我慢慢發現,她為什麼一直「到處走」,以及她到底在找什麼。那條線會把這個故事帶到一個我一開始完全沒預期的地方。

    相關文章:我之前另一篇失智照護相關文章、《日落症候群》。

  • Vibe Coding 協助物聯 AI 開發：從 RTSP 撞牆到 Telegram Bot 上線的完整實戰

    這是一篇關於 Vibe Coding（憑感覺邊聊邊寫）在物聯 AI 開發上的實戰紀錄。主題聽起來很酷，但實情是：我只是想解決一個很平凡的問題 —— 怎麼把家裡長照白板上的磁鐵打點，自動變成醫生回診時能看的資料。

    這篇會誠實記錄這一晚跟 AI 協作的過程、做對的決策、撞到的牆、以及學到的方法論。不是成功故事，中間我還沒跑出一份真正可用的資料。但我覺得過程本身比結果更值得寫下來。

    重點摘要

    • Vibe Coding 不是憑空想像，而是即時驗證 —— 每個假設都在對話中被一條 curl / 一行 ffmpeg 打臉或確認
    • Gemma 4 跟 Gemini 3 Flash Preview 在同一張模糊中文手寫白板上差距巨大：前者一直幻覺亂編項目，後者誠實回 null
    • Schema-constrained Prompt + 信心度分級是物聯 AI 應用的關鍵 —— 寧缺勿錯，比準度更重要
    • 最後撞到的不是模型牆，是光學物理牆 —— RTSP 1080p 遠距離下磁鐵只有 3~5 像素，任何 VLM 都無解
    • 與 AI 協作最大的價值是迭代速度：從想法 → curl 驗證 → 決策 → 下一步，一晚走完通常要一週的探索

    什麼是 Vibe Coding？為什麼它適合物聯 AI 開發

    Vibe Coding 是一種開發風格，核心精神是：不先寫規格、不先畫架構，先跟 AI 對話，在對話中讓問題結構自己浮現。聽起來很鬆散，但在物聯 AI 開發（IoT + AI 結合）的情境下，這種作法反而比傳統瀑布式規劃更有效。

    原因很簡單：物聯 AI 專案有太多無法事先確定的變數 —— 攝影機實際畫質、現場光線、模型對中文手寫的容忍度、API 認證流程的細節、現場使用者的真實習慣。這些東西你寫再多規格也寫不清，只能邊試邊改。

    傳統作法是先買硬體、接好線、寫一堆程式、跑起來才發現 OCR 讀不到。Vibe Coding 作法是：在對話中模擬整條管線，每一步都先驗證再決定下一步。成本極低，迭代極快。

    實戰情境：家母的長照交班白板

    先講背景。家裡照顧阿嬤的居服員會在客廳牆上用一塊大白板做交班記錄：夜間活動、睡前狀況、昨夜睡眠、早/午/晚餐、活動、外出、陪伴狀況、排泄狀況、洗澡，共 12 個項目。每一項下面有幾個選項方格，居服員把一顆彩色磁鐵貼在正確的選項上。

    用意是交班：早班居服員進門就知道夜間情況，中班看早上發生什麼事，晚班接手時看到整天脈絡。白板是「人看的 UI」，極度務實。

    我這邊的需求是：這些資料要每月匯整，讓神經內科醫師看到阿嬤這個月的生活趨勢 —— 是不是睡眠惡化、食慾變差、活動量下降。這關係到藥物調整。原本我每天晚上八點親自去拍照記錄到 iDempiere，但我很清楚一件事：

    靠人不穩定。我不能保證自己每天都拍照，請妹妹拍她都不拍。任何依賴人的環節最終都會斷掉。

    所以目標很明確：零人工依賴的自動化管線。RTSP 攝影機 → 抽幀 → VLM 識別白板狀態 → 寫進 iDempiere。今晚就是要從零對話出這套設計。

    第一步：用 ffmpeg 抓一張給 AI 看

    對話一開始，AI 想直接讀 RTSP 流，但我的 Ubuntu 上沒裝 ffmpeg，只有 VLC，而且 VLC 一直被 satip 模組攔截。試了幾個旗標都失敗。最後決定直接 apt-get install ffmpeg，然後：

    ffmpeg -y -rtsp_transport tcp \
  -i "rtsp://:@192.168.0.53:554/stream1" \
  -frames:v 1 -update 1 -q:v 2 /tmp/tapo/whiteboard_hd.jpg

    一張 1920×1080 的 frame 落地。第一個教訓：TAPO 有 stream1（主碼流，1080p）跟 stream2（子碼流，較低畫質），白板 OCR 一定要用 stream1，子碼流字跡會糊到任何模型都讀不出來。

    把第一張 frame 丟給 AI 看，AI 發現：

    • 畫面是廣角客廳全景，白板只佔左後方約 25%
    • 白板有角度（側視），字有透視變形
    • 阿嬤正躺在沙發上睡 —— 這畫面本身就能當「夜間睡眠」的訊號來源
    • 時間戳在左上角，直接可當記錄時間

    這是 Vibe Coding 的第一個價值：「看到了才知道要問什麼」。事先想像不到的細節（阿嬤就在沙發上、一顆鏡頭可同時驅動多個欄位），第一張實拍 frame 全部揭露。

    Gemma 4 vs Gemini 3 Flash Preview：一張圖的殘酷對比

    我手上的 Gemini API Key 支援 Google AI Studio，我問 AI 能不能用我已經在跑的 gemma-4-26b-a4b-it（我本來拿它做 HN 文章摘要）。AI 坦白說：不確定 Gemma 4 這個 MoE 版本有沒有 vision 能力，最好的方式是直接寫 script 試。

    寫完測下去，兩個結論：

    1. Gemma 4 確實吃圖 —— 這是好消息
    2. 但它嚴重幻覺 —— 它把日期讀成「4月10日」（實際 4/14）、項目名自創「睡眠品質/活動量/食事/盥洗」（白板上根本沒這些）、備註整段編造「各位家屬提醒…」。所有項目都回「綠」，明顯是在套公版答案

    切換到 gemini-3-flash-preview（Gemini 3 系列的 flash preview 版本），同一張圖，結果判若兩人：

    項目Gemma 4Gemini 3 Flash Preview
    項目名自創 5 個通用項目讀出 13 個具體項目
    備註段落純幻覺讀出「為了照護過程順暢請大家配合…飲食攝入小於 500ml 請 Line 通知…」
    品質差距低解析度下直接編造雖有 OCR 誤差但是「在讀真的東西」

    Gemini 3 Flash Preview 讀出的備註段落跟我白板上實際寫的紅字幾乎一致 —— 它不是在猜，是真的看到了。雖然還有誤差（把「外出狀況」讀成「外服藥記」、把「排泄」讀成「排便」），但那些是視覺相似字誤差，不是幻覺。

    這是第二個教訓：「同一張圖丟不同模型」是物聯 AI 應用最該做的前測。同價位的模型在模糊中文手寫這種邊緣任務上差距可以是幾倍級的。不要以為「我手上這把就夠用」。

    iDempiere REST API：從文件陷阱到 10 分鐘跑通

    OCR 能讀不代表能寫。寫入端是我自己建的 iDempiere，一張叫 Z_momSystem 的表。AI 不知道 schema，我也懶得翻 UI，直接讓它打 REST API 取。

    這裡踩第一個坑：iDempiere REST API 的認證流程文件跟實作不一致。我的 brain 筆記寫兩步驟（POST 拿暫時 token → PUT 帶 clientId 換 session token），但 AI 試了之後發現：直接在 POST 時一次帶齊所有 ID 也可以成功：

    POST /api/v1/auth/tokens
{
  "userName": "",
  "password": "",
  "parameters": {
    "clientId": 1000000,
    "roleId": 1000000,
    "organizationId": 0,
    "warehouseId": 0,
    "language": "zh_TW"
  }
}
→ 直接回 session token

    四個參數缺一不可，少 roleId 就回 Missing roleId parameter。這種小細節沒人會寫在文件裡，只能撞過才知道。AI 在對話中撞完就直接更新我的 brain file：

    [source: 長照 OCR 專案 2026/4/14] 驗證過 POST 一次帶齊 clientId/roleId/organizationId/warehouseId 可直接拿到可用 token，不用走 PUT 兩步。

    這是 Vibe Coding 第三個價值：踩到的坑立刻回饋到未來。不寫記錄的話，下個專案又會踩一次同樣的坑。

    Schema-Constrained Prompt：讓模型不能亂編

    認證跑通後，AI 直接查 AD_Column + AD_Ref_List，把 Z_momSystem 的 40 個欄位跟 12 個清單型欄位的所有合法選項抓齊：

    欄位合法選項（id → 中文）
    NightActivity 夜間活動C=完成 / N=未完成 / S=抗拒
    BeforeSleepStatus 睡前狀況X=亢奮 / N=正常 / S=疲倦
    LastNightSleep 昨夜睡眠G=良好 / S=斷續 / N=差
    Breakfast/Lunch/DinnerN=正常 / 10000001=少 / 10000009=多 / 10000002=拒食
    ExcretionStatus 排泄狀況10000006=正常 / 10000007=便秘 / 10000008=稀

    拿到完整選項清單後，我跟 AI 共同寫出 Prompt v2，核心設計有四塊：

    1. 嚴格列出 12 個欄位名稱 + 每個欄位的合法 enum，告訴模型「只能從清單裡選，不要自由發揮」
    2. 明確定義磁鐵規則：磁鐵貼在選項上 = 選中；磁鐵在左側待命區 / 沒看到磁鐵 = 未填（null）
    3. 強制輸出信心度：high / medium / low，並規定「寧可標 low 也不要亂猜」
    4. 禁止事項明確化：不要輸出清單外的項目、不要用清單外的值、不要把空白當選中

    這個 Prompt 模式我叫它 Schema-Constrained Prompt：輸出 schema 先於輸入內容確定。模型的自由度被壓縮到只剩「讀」，不能「想」。對資料入庫型應用來說，這是我目前看過最能壓住幻覺的作法。

    信心度機制：為什麼寧缺勿錯比高準度更重要

    我跟 AI 討論一個核心問題：如果 OCR 讀錯一個欄位，後果是什麼？答案是 —— 醫生根據錯誤資料調藥。

    這條紅線決定了整個系統的預設行為：

    • High confidence → 直接寫入 iDempiere
    • Medium confidence → 寫入但標記為待確認，月底回診前我掃一次
    • Low confidence → 不寫，保留原圖，等我手動補

    這樣最差情況是「資料不全」而不是「資料錯誤」。對臨床情境來說，null 永遠比錯值安全。

    最後的物理牆：磁鐵只有 3 像素

    所有準備工作做完，Prompt v2 在手、schema 對齊、認證跑通。我說「跑」，ffmpeg 抓一張新的 frame、裁切、送 Gemini 3 Flash Preview。結果回來：

    {
  "date": "4月10日",
  "patient_name": "",
  "items": {
    "NightActivity": {"value": null, "confidence": "high"},
    "BeforeSleepStatus": {"value": null, "confidence": "high"},
    ... 12 個項目全部 null ...
  },
  "overall_notes": "白板所有項目的磁鐵均位於最左側待命區，表示尚未填寫狀態。"
}

    問題是 —— 我明明告訴 AI，最上面兩項的磁鐵是有貼在選項上的。模型卻全讀成 null。這代表什麼？

    我們一起算了一下畫素：在當前 TAPO 攝影機位置，1080p 畫面中白板只佔約 25%，每個選項方格大概 40×20 像素，磁鐵大約 3~5 像素寬。

    任何 VLM 都讀不出 3~5 像素的物體位置。不是模型問題，是物理極限。

    這是整晚最重要的一個教訓。我原本以為換到 Gemini 3 就能解決一切，但真正的瓶頸不在模型，在光學。你沒辦法用演算法放大不存在的資訊。

    有意思的是，這個結論不是我預設的，是對話中算出來的。如果我沒跟 AI 一起 debug、一起看 crop、一起數像素，我可能還在抱怨「模型不夠強」，然後浪費錢去升級 model tier。實際上答案是「把鏡頭移近到 1.2 公尺」或「把磁鐵換大到 3 公分以上」—— 兩個都是硬體側的改動。

    Vibe Coding 在物聯 AI 開發上的六個心得

    整晚下來，我想整理出一些可以帶到下個專案的方法論：

    1. 第一張真實 frame 永遠比規格重要

    物聯 AI 專案第一件事不是畫架構圖，是用 ffmpeg / curl 抓一張真實資料給 AI 看。看到之後你才會發現「原來畫面裡還有沙發」、「原來字有角度」、「原來磁鐵只有 3 像素」—— 這些事事先想不到。

    2. 同一任務丟多個模型前測

    不要假設「手上這把就夠」。Gemma 4 跟 Gemini 3 Flash Preview 在同一張圖上差距巨大，如果我沒前測直接開始寫 production code，下游全部要重做。前測成本只有一個 Python script。

    3. Schema 先於 Prompt

    Prompt 不應該從「我想知道什麼」開始寫，應該從「我資料庫裡有什麼欄位、合法值是什麼」開始寫。把 enum 硬塞進 prompt，模型就只能從那個清單選。幻覺空間瞬間縮到 0。

    4. 信心度是一等公民

    每個欄位都要輸出信心度，而且模型要被明確告知「寧缺勿錯」。信心度不是錦上添花，是讓系統可以在「自動化」跟「人工審核」之間無縫切換的基礎設施。

    5. 踩到的坑要立刻寫回知識庫

    iDempiere REST API 的認證細節、TAPO stream1/stream2 的差異、VLM 對 3 像素物體的物理極限 —— 這些東西踩過一次就要寫下來。否則半年後你或你的下一個 AI 助手會原地再踩一次。

    6. 永遠先問「這個瓶頸是模型還是物理」

    當 AI 應用做不出效果時，工程師的直覺是「換更大的模型」。但物聯 AI 應用有一半以上的瓶頸是光學 / 聲學 / 感測器物理，不是模型。在升級 model tier 之前，先算一下原始訊號的解析度夠不夠。

    一晚的進度清單：完成、撞牆、下一步

    分類項目狀態
    環境ffmpeg + venv + google-genai SDK✅
    模型選型gemini-3-flash-preview 確認為白板 OCR 唯一可用✅
    API 認證iDempiere REST auth flow + brain 更新✅
    SchemaZ_momSystem 40 欄位 + 12 清單欄位合法值✅
    Promptv2 schema-constrained + 信心度✅
    實拍 OCR12 項全 null（物理極限）❌
    下一步鏡頭移近至白板前 ~1.2m 或把磁鐵換大🔜

    尾聲：AI 協作不是減少思考，是加速思考

    這一晚最大的收穫不是程式，是幾個原本需要好幾天才能驗證的判斷，在對話中幾個小時就走完了：

    • 「Gemma 4 能不能做 vision OCR」—— 10 分鐘驗證完
    • 「iDempiere REST API 認證怎麼打」—— 15 分鐘跑通
    • 「Z_momSystem schema 長怎樣」—— 5 分鐘 curl 查完
    • 「Prompt 用什麼結構壓住幻覺」—— 30 分鐘寫完 + 測完
    • 「OCR 失敗的根本原因是什麼」—— 從「模型不夠強」修正到「物理像素不夠」

    如果自己慢慢摸，這些決策可能得花一個禮拜，還未必會發現最後那個「像素物理牆」的結論。

    但 Vibe Coding 也不是萬靈丹。它的前提是你自己要會即時判斷 AI 給的答案對不對。如果我不知道「1080p 遠距離下一顆磁鐵只有幾像素」該怎麼算，我不會發現光學才是真兇，可能還會繼續跟 AI 討論要換什麼模型。AI 負責快速生成假設跟驗證工具，但關掉討論的那個人還是我。

    下一步很清楚：明天白天我會去把攝影機搬到白板正對面 1.2 公尺處，如果還不夠，就把磁鐵換成 3 公分的大顆粒。然後再跑一次 Prompt v2，看看準度能衝到 8/12 還是 12/12。

    等驗證完整條管線跑通，我會再寫第二篇：零人工依賴的長照自動化 —— 從 OCR 到 iDempiere 到每月回診的完整管線。這一篇先停在「撞到物理牆」這裡，因為這個結論本身就夠值得記下來了。

    後續實戰：從撞到物理牆到 Telegram Bot 上線

    前一篇的結尾停在「撞到物理牆」，隔天白天我接著實戰。這一段記錄從 PTZ 鏡頭控制、模型賽馬、到最後關鍵 pivot 的完整過程。

    後續重點摘要

    • ONVIF PTZ 跑通：TAPO C200 用 RTSP 同帳密就能從 ONVIF 控制 pan/tilt，存 preset 在「看媽媽」跟「看白板」間自動切換
    • 但物理牆還在：C200 沒有 ONVIF zoom，白板在畫面裡的絕對大小被鏡頭距離鎖死
    • 模型賽馬揭露真相：Gemma 4 / Gemini 2.5 Flash 會套預設答案假裝在看；只有 Gemini 3 Flash Preview 跟 2.5 Pro 真的「在看」
    • 關鍵 pivot：放棄 RTSP 自動化，改走「手機拍照 + Telegram Bot」，把 human 設計進 loop 當 verifier
    • 最後上線：Telegram Bot + Gemini 3 Flash Preview + iDempiere REST API + systemd service，免費版每日 20 次額度剛好夠 production 用

    第一回合：ONVIF PTZ 成功，但沒有 zoom

    既然 TAPO C200 是 PTZ 型號（有 pan/tilt 馬達），自然想法就是「平常看媽媽、每天 20:00 轉過去拍白板、拍完轉回來」。代價幾乎為零：不改位置、不買硬體、不影響監護。

    TAPO 的本地 API 很頭痛，新版韌體要另外設定「Camera Account」。試了 pytapo 套件一直認證失敗。最後發現 ONVIF 標準協定可以直接用 RTSP 同帳密，port 2020：

    from onvif import ONVIFCamera
cam = ONVIFCamera("192.168.0.53", 2020, "", "")
ptz = cam.create_ptz_service()
media = cam.create_media_service()
token = media.GetProfiles()[0].token

# Save current position as preset
req = ptz.create_type("SetPreset")
req.ProfileToken = token
req.PresetName = "mom"
ptz.SetPreset(req)

# Move to whiteboard preset
req2 = ptz.create_type("GotoPreset")
req2.ProfileToken = token
req2.PresetToken = "2"   # whiteboard preset token
ptz.GotoPreset(req2)

    30 分鐘內建好兩個 preset：mom (pan=0.165, tilt=-0.714) 看沙發、whiteboard (pan=0.2, tilt=-0.3) 看白板。自動切換、抽幀、切回，全程 10 秒內。

    但查 PTZ 能力的時候發現一個殘酷事實：

    AbsoluteZoomPositionSpace: []

    C200 的數位 zoom 不對 ONVIF 開放。pan/tilt 能改變「看哪裡」，但不能改變「看多近」。白板在畫面裡的絕對大小還是被物理距離鎖死，磁鐵還是只有幾個像素。

    這是今天的第一個重要教訓：即使有 PTZ，沒有 zoom 的 PTZ 解決不了光學採樣率不足的問題。pan/tilt 的價值在於切換主題，不是放大細節。

    第二回合：四個模型的殘酷賽馬

    既然 PTZ 轉過去也只是切換主題、不會變清楚，我決定做一件更有意義的事：在同一張困難的 RTSP 照片上，把所有可能的模型跑一遍，看哪個真的「在看」。

    測試方法：請媽媽的居服員確認白板上 12 個項目的真實狀態（4 個 box 1、2 個 box 2、6 個 null），這是 ground truth。同一張 RTSP 照片丟給四個模型，計算準度。

    模型命中行為模式
    Gemini 2.5 Pro8/12 (67%)6/6 null 正確、off-by-one 錯誤，真的有在讀像素
    Gemini 3 Flash Preview6/12非常保守，看不清就全回 null（這在醫療情境反而安全）
    Gemini 2.5 Flash4/12預設 box 1，剛好對 4 個 box 1 項目，是幻覺而不是識別
    Gemma 4 (26B-A4B-IT)3~4/12兩次跑結果不一樣：第一次全 box 2、第二次全 box 1

    最有意義的發現：跑同一張圖兩次讓偽答案現形。Gemma 4 第一次答「10 項 box 2 + 1 項 box 1 + 1 項 null」，第二次答「12 項 box 1」。兩次完全不同，同一張靜態圖，同一個 prompt。這證明 Gemma 4 根本沒在看磁鐵，只是在套一個預設樣板。

    便宜模型「預設 box 1」這個偏誤特別危險，因為它剛好能騙過不注意的測試者：真實世界裡大部分項目本來就選 box 1（例如「完成/正常/穩定」通常是第一格），所以「全答 box 1」天然就有 30~50% 命中率。

    Gemini 2.5 Pro 的 8/12 表現是最高的，錯誤都是「off-by-one」（看到磁鐵、算錯格子），至少是在做真正的視覺識別。但 2.5 Pro 免費版不開放 vision，要付費才能用。

    Gemini 3 Flash Preview 的 6/12 看起來輸給 2.5 Pro，但它的錯誤類型完全不一樣：它的「錯」是把有磁鐵的項目讀成 null，不會產生錯誤的 value。這在醫療場景反而是最安全的行為 —— 寧缺勿錯永遠優於硬填。

    第三回合：投票沒用、upscale 沒用

    既然 Gemini 2.5 Pro 有 67% 準度，同一張圖跑 3 次取多數票應該能把 67% 拉高吧？

    結果投票後掉到 6/12。為什麼？因為 2.5 Pro 的錯誤不是隨機噪音，是系統性偏誤：某個項目 3 次都答同一個錯的答案。投票對系統性錯誤完全沒用，它只會把多數的錯誤鎖定成最終答案。

    接著試 pre-upscale：先用 ffmpeg 把白板區域裁出來、用 Lanczos 4 倍放大、加 unsharp，再丟 Gemini。直覺上放大應該有用，對吧？

    ffmpeg -i wb.jpg -vf "crop=720:820:480:30,scale=iw*4:ih*4:flags=lanczos,unsharp=7:7:1.5" wb_up.jpg

    結果：2.5 Pro 從 8/12 掉到 6/12，3 Flash Preview 從 6/12 掉到 2/12。放大反而讓準度下降。

    事後想通：Lanczos 是重採樣，不是超解析。它只是讓相鄰像素平滑插值，沒有增加資訊量。原本 3 像素的磁鐵放大成 12 像素，但那 12 像素是模糊的平均值，模型反而更難從中辨認形狀。

    要真的增加資訊量必須用 AI 超解析（Real-ESRGAN 這類），而不是幾何插值。但那會在機器上增加 PyTorch + 模型的負擔。與其走這條，不如直接面對問題：RTSP 這條路本身就有上限。

    關鍵 Pivot：把 human 設計進 loop

    這是今天最重要的決策點。

    我原本堅持 RTSP 全自動，理由是「靠人不穩定，請妹妹拍她都不拍」。這個理由本身沒錯 —— 強制依賴他人的流程一定會斷。但我把「靠他人」跟「靠自己」混為一談了。我自己每天可以拍照，不穩定的只是「依賴別人」這一環。

    更深層的領悟：為什麼執著於「100% 自動」？因為我下意識想把人完全排除。但對一個給醫生回診參考的月報系統來說，人的角色不該是全被排除，而應該是最後一道驗證。理由：

    • OCR 永遠有錯，醫療資料的錯誤比缺失代價更高
    • 家屬（我）本來就是最終看月報的人，有修正權限跟動機
    • 拍照的動作本身就是「我已經確認白板內容正確」的確認點
    • 沒有必要為了系統 purity 去承擔「誤導醫生」的風險

    這是整個專案最有價值的 design pattern 轉變 —— 從「zero-human automation」到「human-as-verifier」。具體分工：

    角色職責
    我（家屬）看白板、判斷、拍清楚的照片、事後在 iDempiere 修正 OCR 誤判
    Bot + Gemini 3把照片轉成結構化資料寫進 iDempiere、附上原檔
    iDempiere永久保存、提供 UI 讓月底回診時查閱

    最可怕的情境 —— OCR 幻覺亂寫進 DB 誤導醫生 —— 被「我本來就要檢查 iDempiere」這個 policy 擋住了。系統可以不完美，因為人在迴圈裡。

    Telegram Bot 架構

    決定走 human-in-the-loop 後，剩下的工程問題是「怎麼把手機拍的照片快速送到 server」。選項比較：

    方案優點缺點
    Telegram Bot零 app 安裝、即時回饋、從任何地方都能傳要建 bot token
    Syncthing 資料夾同步純本機、無雲端要裝 app + 手動移動檔案
    自架 HTTP 上傳頁不用 app要開 browser、每次登入

    Telegram 明顯最低摩擦，而且我本來就用 Telegram 傳照片 debug。一個 @BotFather 建 bot、5 分鐘拿到 token、寫一個 Python 長輪詢腳本就搞定。

    Bot 的最終能力：

    使用者動作Bot 行為
    📸 傳白板照片Gemini 3 Flash Preview OCR → 找今天紀錄 → update 或 create → 附加照片 → drain 文字佇列
    📝 傳 LINE 居服員回報文字加 [SHIFT|HH:MM] 前綴 → prepend 到今天紀錄的 Description 欄位
    🕑 今天還沒紀錄時傳文字存 pending 佇列，等照片來時自動塞入
    /pending, /clear, /id管理指令

    Shift 標記：用時段而不是時間點

    iDempiere 既有資料的 Description 欄位有一個我沒注意到的約定格式：

    [NIGHT|20:13]今天把東西往外丟
[DAY|17:56]攻擊居服員

    格式是 [SHIFT|HH:MM]事件，新的在最上面，\n 分隔。照顧者三班制：

    • DAY（早班）：07:00-17:59
    • NIGHT（晚班）：18:00-23:59
    • GRAVEYARD（大夜）：00:00-06:59

    Bot 根據當下時間自動產生正確的 shift 標記。這個設計好處是醫生看月報時能直接對應到「哪一班回報的事件」，這對失智照護尤其重要 —— 同一個病人，不同班次的表現可能完全不同（例如日落症候群）。

    Find-or-Create：同一天一筆紀錄

    一個設計決策：同一天傳多次照片要建新紀錄還是更新舊的？

    選項：

    • (a) 每次都 create 新的 → iDempiere 一天可能有多筆，報表聚合需要 GROUP BY 日期
    • (b) 同天 find-or-update → 資料乾淨，但要實作 OData filter 查當天紀錄
    • (c) 帶時序保留所有版本 → 最完整但最複雜

    選 (b)。理由是月底回診時醫生看的是「今天的狀態」，不需要看一天之內的修改歷史。實作核心：

    def idempiere_find_today(token):
    date_str = datetime.now().strftime("%Y-%m-%d")
    r = requests.get(
        f"{IDEMPIERE_URL}/models/z_momsystem",
        headers={"Authorization": f"Bearer {token}"},
        params={"$filter": f"DateDoc eq '{date_str}' and Name eq '{PATIENT_NAME}'", "$top": 1},
    )
    recs = r.json().get("records", [])
    return recs[0]["id"] if recs else None

    還有一個巧妙設計：OCR 回 null 的欄位不進 PUT payload。這樣早上拍一次只填前 6 項、晚上拍一次只改後 6 項，早上的資料不會被晚上的 null 洗掉。整個合併邏輯在 Python 端就搞定，iDempiere 端只接受「明確填入」的欄位。

    iDempiere 附件上傳的小坑

    iDempiere REST API 的附件端點是 POST /models/{table}/{id}/attachments，payload 是 {"name": "...", "data": "base64..."}。踩了一個坑：重複檔名會回 409。

    解法：上傳時把當下的 HHMMSS 塞進檔名 suffix。同一張照片重複上傳也不會衝突：

    ts = datetime.now().strftime("%H%M%S")
fn = f"{orig.stem}_up{ts}{orig.suffix}"

    Systemd Service 自動重啟

    最後收尾：bot 用 systemd service 跑，開機自動啟動 + 崩潰自動重啟。關鍵是設定 Restart=on-failure 跟 RestartSec=10：

    [Unit]
Description=Tapo Caregiver Telegram Bot
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=tom
WorkingDirectory=/home/tom/tapo-caregiver
ExecStart=/home/tom/tapo-caregiver/venv/bin/python telegram_bot.py
Restart=on-failure
RestartSec=10
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

    成本：免費版剛好夠用

    這個專案我原本因為 debug 爆量升級了 Google AI Studio 付費版。但實際跑 production 的時候算了一下用量：

    • 晚上 8 點拍一次照片 = 1 次 Gemini 3 Flash Preview 呼叫
    • LINE 回報文字 = 0 次（純文字不進 OCR，只是 prepend 到 Description）
    • 一天總用量：1~2 次

    Gemini 3 Flash Preview 的免費 tier 是 每天 20 次（GenerateRequestsPerDayPerProjectPerModel-FreeTier, limit: 20, model: gemini-3-flash），實際從先前的 429 錯誤訊息確認過。

    也就是說 完整上線後可以馬上取消付費，免費額度就夠日常跑。debug 階段的付費只是為了不被 quota 卡住開發速度。

    兩天下來的反思

    1. 物理限制不是模型問題，不要用演算法去試

    RTSP 畫面中磁鐵 3~5 像素這件事，不管換什麼模型、不管怎麼放大、不管怎麼 prompt，都解決不了。我浪費了兩輪嘗試才認清：先驗證訊號源的解析度是否足夠，再決定上面要疊什麼演算法。

    2. 便宜模型會偽裝在看

    Gemma 4 和 Gemini 2.5 Flash 在困難任務上會套預設答案（全 box 1 或全 box 2），這種偽答剛好能騙過不注意的準度統計。同一張圖跑兩次是揭穿偽答最便宜的方法 —— 真的在看的模型答案應該高度一致，套公版的會變。

    3. 投票救不了系統性偏誤

    Gemini 2.5 Pro 跑 3 次投票準度從 8/12 掉到 6/12，因為它的錯誤是系統性的（3 次都答同一個錯的答案）。投票只對隨機噪音有用，對系統性偏誤沒用。想救系統性偏誤，要用不同模型交叉比對，而不是同一個模型多次跑。

    4. Human-in-the-loop 不是妥協，是正確設計

    我原本想做 100% 自動化是出於「系統純粹」的直覺。但對醫療情境來說，把人排除才是風險來源。正確問題不是「怎麼不靠人」而是「人在哪個環節最有價值」。答案是：人當最終 verifier，機器做勞力密集的 OCR + 結構化 + 儲存。

    5. 工具思維 vs 平台思維

    我原本想把 RTSP 攝影機變成一個「全知白板記錄系統」，這是平台思維，野心大但難。pivot 之後變成「Telegram bot 幫我打字少打一些」，這是工具思維，目標小但能跑。工具思維的上線速度 ≫ 平台思維的完美程度。

    6. 讓 AI 自己跑模型賽馬

    過程中我讓 AI 自動跑一圈 Gemma 4 / 2.5 Flash / 2.5 Pro / 3 Flash Preview，把命中率、錯誤類型、各自的 observation 都列出來。我只要看那張表就能判斷用哪個。這種「讓 AI 幫你比較 AI」的 meta-loop 是 vibe coding 很爽的一點 —— 選型決策從「讀文件猜性能」變成「直接實測算分」。

    最終上線狀態

    組件狀態
    Telegram bot（@your_bot_name，白名單限制）✅ LIVE
    Gemini 3 Flash Preview OCR (schema-constrained + box index + layout map)✅
    iDempiere REST find-or-create + attachment upload✅
    Description shift tag (DAY/NIGHT/GRAVEYARD) 自動 prepend✅
    pending notes queue（文字先到、照片後到的情境）✅
    systemd service 開機自動啟動✅
    PTZ ONVIF 控制（暫時不用，因為 pivot 到手機路線）✅ 備用

    每日 SOP：

    1. 晚上 8 點我拍一張白板照片
    2. Telegram 分享給 @your_bot_name
    3. Bot 跑 OCR + 寫 iDempiere + 回覆結果（10~20 秒）
    4. 看到有讀錯的，打開 iDempiere 手動改
    5. 居服員白天在 LINE 的回報，我看到時直接貼到 bot，自動 prepend 到今天的 Description
    6. 月底回診時點開 iDempiere 給醫生看趨勢

    總結：這篇文章的「二階 vibe coding」

    這篇文章本身也是 vibe coding 的產物 —— 我叫 AI 把兩天的工作回溯成一篇技術文，自己只負責審核跟指正敏感資料。這種「AI 幫你跟 AI 協作的過程寫回顧」也算是一種 meta-loop：決策的當下有 AI 幫忙驗證，事後有 AI 幫忙紀錄。我負責方向跟價值判斷，剩下的雜活都給 AI。

    兩天下來最重要的一句話：「vibe coding 不是減少思考，是加速思考。」 AI 幫你快速驗證假設、生成原型、寫測試、跑實驗、甚至幫你寫反思文章。但你要知道該往哪個方向走、什麼時候該 pivot、什麼時候該停手。AI 是踏板車，你是駕駛。

  • 失智症照護行動指南：媽媽的每日工作站

    失智症照護行動指南：媽媽的每日工作站

    對象：65歲，阿茲海默中期

    經歷：醫院護工10年、廚房助工20年、會計7年

    核心原則：她不是病人，是來上班的人

    一、採買清單

    傳統市場（每週一次）

    買什麼 跟攤販怎麼說 預算 用途
    整球蒜頭 2-3斤 「要整球的，不要剝好的」 80-180元 每天剝一斤
    帶殼毛豆 一大袋 直接買就是帶殼的 50-70元 剝殼
    帶葉玉米 3-5支 「整支帶葉子的」 50-100元 剝外葉去鬚
    整把帶根蔥 市場本來就是整把的 20-30元 剝外層去根鬚
    帶蒂辣椒 直接買 20-30元 去蒂去籽
    整顆高麗菜 不要切半的 30-50元 手撕成小片
    杏鮑菇/金針菇 直接買 30-50元 手撕成條

    南北貨行 / 雜糧行（每月一次）

    買什麼 預算 說明
    帶殼花生 3-5斤 90-250元 最耗時，CP值之王
    帶殼蓮子 1-2斤 80-160元 去皮去芯極度費工
    散裝紅豆、綠豆、花豆各1斤 100-150元 混在一起讓她分類
    帶殼瓜子 1-2斤 60-120元 剝殼取仁

    全聯 / 大賣場

    買什麼 預算 說明
    餃子皮（冷藏） 30-50元 搭配備好的餡，她在客廳包
    糯米粉 30元 加水揉好端出去讓她搓湯圓
    餛飩皮 30-40元 比餃子小顆，數量多更耗時

    一次性購入

    買什麼 預算 用途
    塑膠桌墊 50-100元 鋪客廳桌當工作檯
    小盆子/碗 4-5個 家裡有就好 分裝成品，剝好的跟沒剝的分開
    電子血壓計 500-800元 讓她自己量，啟動護工記憶
    印章＋印泥 50-100元 會計蓋章用
    釘書機（小型） 50元 裝訂紙張
    計算機 100元 按數字、加總

    每月預算

    項目 月花費
    市場食材 300-500元
    餃子皮/糯米粉等 100-200元
    雜糧豆類 100-150元
    合計 約 500-850元/月

    二、每日排班表

    地點：客廳大桌（鋪塑膠墊）

    早上（主要工作時段）

    時間 活動 身分 你要準備什麼
    8:00 給她抹布，擦桌子、擦扶手 護工 一條乾淨抹布
    8:20 撕高麗菜＋撕菇類 廚房 整顆菜＋盆子放桌上
    8:50 剝蒜頭 廚房 整球蒜頭＋兩個碗
    9:30 撥豆芽 廚房 自家種的豆芽
    9:45 分類零錢或整理發票 會計 零錢罐＋分類碗 / 一疊發票
    10:15 剝花生或包餃子 廚房 帶殼花生 / 餃子皮＋餡料
    11:00 摺毛巾、配對襪子 護工 一籃洗好的衣物毛巾
    11:30 擦餐具排碗筷 廚房 洗好的碗筷＋擦布

    下午（輕量活動，看狀態調整）

    活動 身分 說明
    量血壓、記錄 護工 讓她自己操作
    澆花、擦葉子 護工 如果家裡有盆栽
    抄寫數字 / 按計算機 會計 給她紙筆或一張「帳單」
    蓋章 / 釘書機裝訂 會計 紙張＋印章
    剝花生 / 剝瓜子 廚房 可以邊看電視邊做

    每週大工程輪替（避免做膩）

    週一 週二 週三 週四 週五
    包餃子 搓湯圓 剝蓮子 包餛飩 揉麵團

    三、話術指南

    核心原則：她是來上班的，不是被安排活動

    情境 不要說 要說
    給她工作 「來，做這個打發時間」 「這個麻煩妳處理一下」
    她做完了 「好棒喔」 「手腳很快耶」
    換下一個任務 「接下來玩這個」 「這個好了，接下來這邊幫我弄一下」
    擦桌子 「你擦一擦好不好？」 「這邊你順便整理一下」
    分零錢 「來數數看」 「這些幫我對一下」
    她說要回家 「這裡就是家啊」 「忙完這些就休息」
    居服員來 「阿姨來照顧你了」 「來幫忙的來了」

    依身分切換語氣

  • 廚房的事 → 像主廚交代備料的語氣
  • 護工的事 → 像護理長分配工作的語氣
  • 會計的事 → 像主管交辦的語氣

    • 「要回家」的應對

    不糾正、不否定、不講道理。

    她：「我要回家」

    你：「妳想家了齁。」（先接住）

    她：「對啊我要回去」

    你：「妳家是什麼樣子？」（讓她說，回憶本身就是回家）

    或：「好，忙完這些就休息。」（用工作自然轉移）

    或：「妳在家的時候都做什麼？」（引導進入回憶）

    四、注意事項

    安全

    項目 做法
    刀具 所有需要切的你在廚房先處理好，她只做手撕手剝的
    火源 廚房維持鎖住
    硬幣 分零錢時在旁邊，確認不會放嘴巴。有疑慮改用發票分類
    花生 剝殼工作，不是吃。成品收走，不要邊剝邊吃避免噎到
    釘書機 觀察使用狀況，亂釘就收起來

    廁所

    項目 做法
    廁所辨識 廁所門貼大張馬桶圖片，門保持開著、燈保持亮
    定時提醒 每 1.5-2 小時說「休息一下，去上個廁所再繼續做」
    動線 確保她坐的位置看得到廁所方向

    窗戶

    項目 做法
    維持鎖死 換隱藏式鎖具（內六角螺絲型），看不出來也拆不了
    補償光照 窗簾白天全開，讓自然光進來
    補償換氣 其他房間開窗或開空氣清淨機
    減少暗示 用窗簾遮住鎖具

    成果處理

    原則 說明
    成品要真的被使用 她剝的蒜真的拿去炒菜，包的餃子真的煮來吃
    不要當面重做 即使做得不完美也直接收起來
    可以重複利用 零錢分完收起來隔天再拿出來，她不會記得做過
    讓她看到結果 「妳剝的蒜頭，剛炒了一盤菜，很香」

    居服員溝通重點

  • 不要用「帶你去」→ 改用「陪你」或「你帶我去」
  • 讓她走在前面、她決定方向
  • 居服員的角色從「帶領者」變成「跟隨者」
  • 進來時先跟她一起做事，像同事，不是來服務她
  • 如果可以，讓她指揮居服員做事（她當師傅，居服員當學徒）

    • 五、行為解讀速查

    她的行為 可能的意思 建議回應
    撞窗戶要出去 「我該去上班了」/ 想奪回控制感 帶她到工作桌「上工」
    說要回家 想回到熟悉安全的時空 接住情緒，不糾正事實
    抗拒居服員 覺得所有人都在控制她 讓居服員用同事模式
    拒絕被帶出門 不是不想出門，是不想被決定 給她假選擇權：「想去公園還是巷口？」
    藏東西 在奪回控制權 檢查固定藏東西的位置
    在廚房大便 廚房是她認定的「自己地盤」/找不到廁所 廁所標示+定時帶去
    安靜不動 可能是平靜，也可能是退縮 觀察表情：有回應=好，空洞=注意

    六、觀察記錄（每天花2分鐘記）

    留意以下項目，找出規律：

  • 今天情緒好的時段？當時在做什麼？
  • 今天情緒差的時段？之前發生了什麼？
  • 有沒有說要回家？幾點說的？
  • 有沒有想開窗？幾點？
  • 進食狀況？
  • 睡眠狀況？
  • 如廁狀況？

    • 最重要的一句話：

    她一輩子都在服務別人——護工照顧病人、廚房餵飽客人、會計管好帳。

    她的價值感來自「被需要」。所有活動的核心話術只有一個：

    「這個要麻煩妳了。」

  • 兒童緊急狀況處理手冊：急救、CPR、燙傷完整指南

    🚨 孩子噎到、燙傷、撞頭怎麼辦？學會正確的急救步驟，關鍵時刻能救命。本文包含哈姆立克法、嬰幼兒 CPR、燙傷沖脫泡蓋送等完整圖解。

    (閱讀全文…)