標籤: GitHub Pages

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 留言 — 工具不主動推,但方法 / 經驗 / 踩過的坑歡迎交流。