作者: tm731531

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

  • Hacker News 每日精選 – 2026-04-30

    “`html




    科技趨勢早報:AI 的未知領域、開發工具的新紀元與技術倫理的辯論

    🚀 科技趨勢早報:從 AI 的未知領域到開發工具的新紀元

    今日科技圈的討論焦點聚焦於兩個極端:一邊是 AI 模型深處不可預知的行為與版權爭議,另一邊則是 開發者對於極致效能工具與純粹開發精神的追求。理解這些趨勢,能幫助你在 AI 浪潮與硬體/系統開發的交界處,找到最精準的技術定位。

    🤖 AI / 機器學習

    🔍 OpenAI:小鬼從何而來 (Where the goblins came from)

    這篇文章深入探討了大型語言模型中那些難以預料的行為與現象。OpenAI 分享了關於模型內部機制與突現行為(Emergent behaviors)的觀察。這對於理解 AI 如何從海量數據中「學習」並產生非預期結果至關重要。

    • 探討模型內部邏輯的不可預測性。
    • 解析模型行為背後的數據與訓練機制。
    • 為 AI 的安全性與對齊問題提供新的視角。

    👉 查看原文

    ⚖️ 對齊遊戲:微調會觸發 LLM 對版權書籍的記憶

    這是一項令人擔憂的研究,指出僅僅透過微調(Finetuning),就能讓原本被掩蓋的版權書籍內容在 LLM 中被重新喚醒。這對於 AI 訓練數據的合規性與版權保護提出了嚴峻的挑戰。

    • 揭露了微調技術可能造成的「數據洩漏」風險。
    • 挑戰了目前 AI 公司對於數據過濾與保護的有效性。
    • 引發關於 AI 版權法律框架的深度討論。

    👉 查看原文

    🛠️ 開發工具

    ⚡ Zed 1.0 正式發佈

    備受期待的高效能代碼編輯器 Zed 終於迎來了 1.0 版本。Zed 憑藉其極致的性能與流暢的使用體驗,被視為下一代開發工具的強力競爭者。

    • 強調極低的延遲與極高的執行效率。
    • 為開發者提供更直覺且高效的工作流。
    • 標誌著該工具從實驗階段邁向成熟產品。

    👉 查看原文

    🧩 函數式編程者應關注 Zig

    儘管 Zig 是一款系統級語言,但這篇文章認為函數式編程(FP)的開發者也應從中獲益。這篇文章探討了 Zig 在設計哲學上與函數式概念的交集。

    • 分析 Zig 的安全性與簡潔設計。
    • 探討系統語言如何吸收函數式編程的優點。
    • 推薦給尋求高效能與嚴謹邏輯的開發者。

    👉 查看原文

    📋 Copy Fail

    這是一個關於剪貼簿或複製流程中常見問題的專題討論或工具,觸及了開發者日常工作中極其細微卻重要的體驗問題。

    • 關注開發流程中常見的細節錯誤。
    • 提供改進使用者體驗的思考。

    👉 查看原文

    🔓 開源專案

    🚫 Zig 專案對 AI 貢獻的強硬反對政策

    Zig 專案明確表達了對 AI 生成程式碼貢獻的拒絕立場。這反映了開源社群對於「人類智慧貢獻」與「自動化內容」之間界線的激烈爭論。

    • 闡述 Zig 維護者對於程式碼品質與真實性的堅持。
    • 探討 AI 生成內容對開源生態系的潛在威脅。
    • 為其他開源專案如何制定 AI 政策提供參考。

    👉 查看原文

    🌐 其他

    🧬 基因組學先驅 Craig Venter 逝世

    基因組學領域的奠基者之一 J. Craig Venter 去世,這標誌著生命科學史上一個重要時代的結束。他的貢獻徹底改變了我們理解生命的方式。

    • 悼念基因組學領域的開創性人物。
    • 回顧其在 DNA 測序與合成技術上的重大成就。

    👉 查看原文

    🌬️ Noctua 發佈官方散熱風扇 3D CAD 模型

    對於硬體玩家與 DIY 愛好者來說,Noctua 提供官方 3D CAD 模型是一件大好事,這將大幅提升客製化散熱方案的精準度。

    • 賦能硬體修改者與機殼設計者。
    • 提升 DIY 硬體生態系的專業度。

    👉 查看原文

    🌯 生物學就像一個捲餅:穿梭於活細胞的視覺之旅

    這是一篇極具創意的科普文章,透過「捲餅」的比喻,將複雜的細胞生物學轉化為視覺化且易懂的敘事。

    • 創新的教學方式,結合文字與視覺效果。
    • 降低生物學學習的門檻。

    👉 查看原文

    ⚛️ Scott Aaronson 對量子計算的警告

    知名學者 Scott Aaronson 再次針對量子計算領域發出警告,提醒大眾不要過度樂觀或忽略潛在的科學挑戰。

    • 對量子計算發展現狀的深度批判。
    • 提醒研究者與投資者保持理性。

    👉 查看原文


    💡 今日觀點

    今日核心趨勢: 我們正處於一個「技術邊界重新定義」的時刻。AI 正在挑戰版權與知識產權的底線,而開發者社群(如 Zig 專案)則在嘗試建立防線,以保護程式碼的純粹性與人類創造力。同時,高性能工具(如 Zed)的成熟,顯示出開發者對於「極致效率」的渴望正在超越對「AI 自動化」的盲目依賴。

    給讀者的行動建議:
    1. 關注 AI 合規性: 如果你在開發 AI 應用,請務必關注數據微調可能帶來的版權風險。
    2. 嘗試新工具: 建議下載 Zed 1.0 體驗新一代編輯器的性能,這可能改變你的開發習慣。
    3. 保持批判思考: 學習技術時,除了關注 AI 能做什麼,也要理解底層系統(如 Zig 或量子計算)的真實限制。



    “`

  • Hacker News 每日精選 – 2026-04-29

    “`html

    🚀 今日科技趨勢速報: 從 AI 商業模式的轉型,到開發者工具生態系的重新洗牌,科技圈正處於一個關鍵的轉折點。今天我們將看到 AI 如何深度滲透廣告市場與雲端基礎設施,同時觀察開發者如何在追求極致工具與安全性的過程中,面對新的技術挑戰。

    🤖 AI / 機器學習

    ChatGPT 如何投放廣告:完整的歸因迴路解析

    • 深入探討 ChatGPT 在對話式介面中整合廣告的技術機制。
    • 解析廣告如何在 AI 回答流程中實現精準的歸因(Attribution)。
    • 這代表了搜尋廣告從「連結點擊」轉向「對話體驗」的重大變革。

    👉 查看原文

    OpenAI 模型即將進駐 Amazon Bedrock:OpenAI 與 AWS CEO 的深度對談

    • OpenAI 模型將透過 AWS Bedrock 提供給企業客戶,強化雲端 AI 生態系。
    • 探討兩大巨頭如何合作,讓企業能更輕鬆地部署與管理 AI Agent。
    • 這項合作將進一步鞏固 AWS 在企業級 AI 市場的領先地位。

    👉 查看原文

    Show HN: 自動化架構——將 Karpathy 的迴圈應用於 CPU 設計

    • 展示如何利用 AI 自動化設計硬體架構的創新嘗試。
    • 將 Andrej Karpathy 著名的訓練迴圈概念應用在 CPU 性能優化上。
    • 這代表了 AI 輔助硬體設計(AI for EDA)的新方向。

    👉 查看原文

    Claude Code 的回歸問題:惡意軟體提醒導致代理功能受阻

    • Anthropic 的 Claude Code 在處理安全提醒時出現了功能退化。
    • 由於過度敏感的安全性檢查,導致 Subagent 頻繁拒絕執行指令。
    • 此案例凸顯了 AI 工具在「安全性」與「實用性」之間難以取得平衡的挑戰。

    👉 查看原文

    🛠️ 開發工具與程式語言

    Ghostty 決定離開 GitHub

    • 備受關注的新興終端機模擬器 Ghostty 宣布改變其代碼託管策略。
    • 這引發了關於大型平台依賴性以及開源專案自主權的討論。
    • 開發者應關注其後續的社群維護與分發方式。

    👉 查看原文

    Rust 無法捕捉到的 Bug

    • 探討即使在 Rust 這種強調記憶體安全的語言中,仍存在的邏輯與系統層級漏洞。
    • 提醒開發者不能盲目信任語言的安全特性,邏輯錯誤依然是主要威脅。
    • 深度分析了型別系統與實際運行時行為之間的落差。

    👉 查看原文

    GitHub 之前的時代

    • 回顧在 GitHub 統治世界之前,版本控制技術的演進史。
    • 從分散式版本控制的崛起,談到開發者協作模式的變遷。
    • 對現今開發流程中「平台化」趨勢的反思。

    👉 查看原文

    🧪 科學與其他

    重力常數(Big G)的精確值仍難以捉摸

    • 物理學界對於重力常數的精確測量依然面臨巨大挑戰。
    • 討論為什麼這個看似基礎的數值,在實驗測量上卻如此困難。
    • 精確度的提升對於基礎物理模型至關重要。

    👉 查看原文

    氧化鎵電子元件能耐極低溫環境

    • 科學研究顯示氧化鎵(Gallium oxide)在極端寒冷條件下仍能穩定運作。
    • 這對於太空探索與極端環境下的電子設備設計具有重大意義。
    • 下一代半導體材料的研究正朝向更廣泛的環境適應性發展。

    👉 查看原文

    文化隨筆:Withnail’s Coat and I

    • 一篇帶有個人色彩與文學氣息的文章。
    • 探討生活中的細微觀察與記憶的連結。

    👉 查看原文

    💡 今日觀點

    總結: 今日的主題呈現出明顯的「雙向演進」——一方面是 AI 技術正從實驗室走向商業變現(廣告與雲端整合),另一方面則是開發者工具正在尋求更強的獨立性與技術深度(Ghostty 的遷移與 Rust 的局限性)。

    行動建議:
    1. 企業端: 密切關注 AWS 與 OpenAI 的整合進度,這將影響未來 AI Agent 的部署成本與架構選擇。
    2. 開發者端: 不要將安全性完全寄託於語言特性(如 Rust),在開發 AI 驅動的工作流時,需特別留意安全機制對工具可用性的副作用。

    “`

  • 我該選哪個 AI 模型?從硬體到能力的白話判斷指南

    選 AI 模型不是看誰最厲害,而是看哪個「裝得進你的機器、會做你的工作、跟你脾氣合」。這篇用白話講清楚怎麼判斷,不需要工程背景就能讀懂。最後附上三種人的實際範例和一張機器等級對照表,讓你看完知道下一步該做什麼。

    重點摘要

    • AI 模型有四關:可不可用、裝不裝得下、擅不擅長、合不合作
    • 「總參數」決定要多少記憶體,「激活參數」決定跑多快 — 兩個不一樣
    • 32GB 記憶體的家用電腦能跑 30B 級的本地模型(壓縮後),別被 700B 的數字嚇到
    • 判斷模型擅長什麼,看 第三方榜單 + 自己跑題目,不要相信廠商海報
    • 不會微調、不寫程式的一般人:雲端 ChatGPT/Claude 比地端模型實用 10 倍

    為什麼這篇不是工程師專用

    很多 AI 模型介紹一上來就講 Transformer、MoE、量化、KV cache,看不懂的人乾脆直接問 ChatGPT 算了。但這樣你永遠不會知道:為什麼有時候 ChatGPT 答得不如另一個工具好?為什麼有人在自己電腦上跑 AI?那台主機要花多少錢?

    這篇用「買菜選菜」的角度切入。選模型就像選餐廳:有的店招牌大但你家附近沒有(雲端 vs 地端)、有的菜單大但你只吃其中三道(總參數 vs 激活參數)、有的師傅擅長熱炒但你想吃日料(文字強但圖片弱)。看懂這幾個對應,後面什麼術語都不會卡住你。

    第一步:先問自己這四個問題

    判斷一個模型「對你來說可不可用」,不是看它在排行榜第幾名,而是先答這四個問題:

    1. 我要它做什麼? — 寫文案、翻譯、寫程式、看 PDF、看圖,選的方向完全不同
    2. 我要在哪裡用? — 雲端服務 (ChatGPT 網站、Claude 網站) 還是裝在自己電腦 (地端)
    3. 我有多少預算? — 雲端是月費或按量計費,地端是一次性硬體投資
    4. 資料能不能上雲? — 病歷、客戶資料、未公開的營業資料,丟雲端要先看公司規範

    這四題答完之後,80% 的人會發現:地端模型不是給你的。雲端 ChatGPT/Claude/Gemini 月費 600-800 台幣,你買得到的「能力」遠超過你自己組一台機器跑 Llama 3。地端只有在「資料不能外流」、「想要客製化微調」、「想當興趣研究」這三種情況才划算。

    第二步:看模型「裝不裝得進」你的機器

    如果你決定走地端,這一關是硬門檻。模型有兩個關鍵數字,廠商常常混在一起講,你要會分:

    總參數 vs 激活參數

    名詞 白話解釋 決定什麼
    總參數 模型「整本書」有多厚 要多少記憶體裝它
    激活參數 每次思考翻幾頁 跑得快不快

    普通模型(像 Gemma 3、Llama 3)「整本翻完」才回答你 — 總參數 = 激活參數。MoE 模型(像 Mixtral、DeepSeek、Gemma 4)「只翻其中幾頁」 — 總參數遠大於激活參數,跑得快但還是要把整本書放進記憶體

    記憶體簡易公式

    用「壓縮過」(技術上叫 Q4 量化) 的模型,大致這樣估:

    • 模型體積 ≈ 總參數 ÷ 2 GB
    • 實際記憶體需求 ≈ 模型體積 + 2~4 GB(系統開銷 + 上下文)

    例子:Gemma 3 27B 模型 → 27 ÷ 2 ≈ 14 GB 模型 + 4 GB 開銷 = 18 GB 記憶體需求。一台 16GB 筆電裝不下,32GB 桌機剛好。

    第三步:看模型擅長什麼

    模型不是萬能。同樣 27B 大小,有的會寫程式但不會看圖,有的中文很爛但英文很強。怎麼判斷?

    看第三方榜單(快速篩選)

    你的需求 看哪個榜單分數 大概及格線
    寫文案、知識問答 MMLU-Pro >65 算強
    寫程式 LiveCodeBench、HumanEval LiveCodeBench >30 可用
    中文能力 C-Eval、CMMLU >70 算強
    看圖、讀 PDF MMMU、DocVQA MMMU >60 算強
    數學、邏輯 MATH、GPQA MATH >70 算強
    綜合(一般使用) LMArena Leaderboard 看 Elo 排名

    自己跑題目(最關鍵)

    榜單分數會作弊,你必須跑「自己工作會碰到的題目」。流程:

    1. 準備 20-30 題你實際工作會碰到的問題(不是從網路抄題目)
    2. 同樣的題目餵給 2~3 個候選模型
    3. 蒙著看答案、給分(別看是誰寫的)
    4. 看「一次到位率」、「中文是否流暢」、「會不會瞎掰」

    這比看任何排行榜都準。我之前在本地 AI 模型完整實測那篇就是用這個方法,五款模型結果完全不照 leaderboard 排名走。

    第四步:確認模型「合作說明書」

    同樣強的兩個模型,「會不會聽指令」差很多。這部分用戶最容易踩雷,要看四件事:

    • 支不支援系統指令(System Prompt) — 例如 Gemma 系列不支援系統指令,你只能塞在第一句話。Llama、Qwen、Claude 都支援。不知道這點會發現「怎麼叫它扮演什麼角色都沒效」。
    • 能不能呼叫工具(Function Calling / Tool Use) — 想做 AI Agent、自動查資料、操作 Excel,模型必須會「呼叫工具」。Claude、GPT、Qwen 強;Gemma 弱要靠土法煉鋼。
    • 能不能吃圖、吃 PDF — 多模態能力。Gemma 3 / GPT-4o / Claude 都吃圖;純文字模型(像 Llama 3 base)看不到圖。
    • 上下文(Context)能裝多少 — 4K 只能聊天、32K 可以吃一份合約、128K 可以吃一本書、1M 可以吃整個資料夾。看你的工作內容多長。

    三種人的實例:看完直接套

    實例一:上班族 Mary(行銷專員)

    需求:寫社群貼文、改履歷、翻譯英文信、整理會議紀錄。一台 8GB 筆電,沒在管什麼資料外流。

    判斷:

    • 地端?不要,8GB 連最小可用模型都裝不下
    • 能力需求:文字 + 中文,不需要寫程式
    • 預算:能接受月費 600-800 元

    建議:直接訂 ChatGPT Plus 或 Claude Pro。免費版偶爾用也夠,只是會在尖峰時段斷線。不要花一分錢買硬體,投資報酬率最差的選擇。

    實例二:工程師阿志(後端開發者)

    需求:寫程式、Code Review、技術文件查詢、自動化腳本。32GB 桌機,公司規定客戶資料不能上雲。

    判斷:

    • 分流:涉及客戶資料的問題用地端,公開資料用雲端
    • 地端能力:寫程式 → Qwen2.5-Coder-32B(壓縮後 ~20GB,塞得進)
    • 雲端:Claude Sonnet 寫程式最強,搭配 Cursor 或 Claude Code

    建議:Ollama 裝 Qwen2.5-Coder-32B 跑地端,Claude Pro 月費跑雲端。兩邊加起來月支出 ~800 元 + 一次性 0 元(用現有電腦)。

    實例三:創作者小凱(YouTuber + 部落客)

    需求:腳本撰寫、字幕翻譯、看 PDF 整理重點、看圖寫敘述、長影片轉文字稿。16GB 筆電 + 一張 RTX 4060(8GB VRAM)。

    判斷:

    • 多模態(吃圖)是剛需 → 模型必須支援
    • 16GB 筆電能跑 8B-12B 級的多模態小模型(像 Gemma 3 12B)
    • 長影片字稿要長 context → 32K 起跳

    建議:雲端為主(ChatGPT 或 Gemini 看圖最強),地端裝 Gemma 3 12B 當備援(網路斷或想離線時用)。腳本創意給雲端、批量字幕翻譯給地端省錢。

    機器等級對照表:你的硬體能跑到哪

    下表用 Q4 壓縮後的本地模型尺寸估算。「速度感受」是 CPU 推理(沒獨顯)的體感:

    機器等級 能跑的最大模型 速度感受 適合
    8GB RAM 筆電 放棄,直接走雲端 N/A Mary(上班族)
    16GB RAM 筆電 7B-12B 模型(Gemma 3 12B、Llama 3 8B) CPU 跑會卡,有獨顯才順 輕度離線備援
    32GB RAM 桌機 26B-32B 模型(Gemma 4 26B MoE、Qwen2.5-32B) MoE 模型可用,Dense 慢但能跑 阿志(開發者)
    64GB RAM 工作站 70B 模型(Llama 3.3 70B) CPU 很慢,要獨顯才實用 研究、實驗
    RTX 3090/4090 (24GB VRAM) 27B-32B 模型,速度飛起 流暢,接近 ChatGPT 體驗 認真做地端 AI 的甜蜜點
    2x RTX 4090 / A100 70B 模型流暢、Mixtral 等大 MoE 商用級 公司部署、付費服務

    關鍵原則:沒有獨立顯示卡的話,別買貴的桌機去跑大模型。CPU 推理 30B 級模型每秒只吐 2-5 個字,寫一封信要等三分鐘,用一次就會放棄。要嘛走雲端,要嘛投資一張二手 RTX 3090(約 2 萬台幣)。我之前測過 AMD 內顯 (iGPU) 跑 Gemma 4 也會踩坑,內顯不是省錢方案。

    最後:我該問自己的 7 個問題

    把這份清單存起來,下次有人推薦你「某某新模型超強」時,逐題核對一遍:

    1. 我用 AI 來解什麼具體問題?(模糊回答 = 還沒想清楚,先別買硬體)
    2. 這些問題,雲端的 ChatGPT/Claude 已經能解嗎?(能 → 直接訂閱,不要繞遠路)
    3. 我的資料能不能上雲?(不能 → 才考慮地端)
    4. 我的機器有多少記憶體和顯卡?(對照本文那張表)
    5. 這個模型在我關心的能力(寫程式 / 中文 / 看圖)分數怎樣?(看榜單再自己跑題)
    6. 這個模型的「合作說明書」有什麼坑?(系統指令、工具呼叫、上下文長度)
    7. 用一個月後,我真的有用嗎?(很多人裝完地端模型用三天就涼了,雲端訂閱反而沒浪費)

    結論一句話:普通人選雲端、有資料安全顧慮的選地端、想當興趣研究的選地端 + 雲端混用。買硬體之前,先把第 1、2、7 題答清楚,就會省下七成不必要的開銷。

  • Hacker News 每日精選 – 2026-04-28

    “`html




    科技趨勢早報 | Hacker News 精選

    🚀 科技趨勢早報:AI 巨頭關係變動與數據安全的新威脅

    今日科技圈的核心焦點集中在 AI 產業生態系的重組,特別是 Microsoft 與 OpenAI 之間合作模式的轉向,這預示著 AI 商業化的新階段。同時,隨著 AI 訓練數據規模擴大,數據安全與隱私漏洞(如 Mercor 的大規模語音資料外洩)正成為開發者與企業不可忽視的隱憂。

    理解這些變動不僅能幫助你掌握商業風向,更能讓你提前佈局更安全的開發流程與工具鏈。🔍

    🤖 AI / 機器學習

    Talkie: 模擬 1930 年代風格的 13B 語言模型

    這是一個非常有創意的研究,開發者推出了一個擁有 13B 參數、模擬 1930 年代語言風格的語言模型。它不追求最新的技術參數,而是專注於特定時代的語感與文化氛圍。這種「風格化」的模型為 AI 的應用場景提供了全新的可能性。✨

    👉 查看原文連結

    LingBot-Map: 基於幾何上下文轉換器的串流 3D 重建

    這項技術展示了 AI 在空間計算領域的前沿發展,透過 Streaming 3D reconstruction 技術,結合了幾何上下文轉換器(Geometric Context Transformer)。它能更精準地處理動態環境下的 3D 建模。這對於 AR/VR 與自動駕駛技術具有高度潛力。🌐

    👉 查看原文連結

    Mercor 資料外洩:4 萬名 AI 承包商的 4TB 語音樣本遭竊

    這是一宗嚴重的安全事件,Mercor 平台遭到入侵,導致 4 萬名參與 AI 訓練的承包商之語音資料外洩,總量達 4TB。此事件突顯了 AI 供應鏈中數據安全的重要性。隨著語音數據成為珍貴資源,如何保護這些數據已成為行業痛點。⚠️

    👉 查看原文連結

    🛠️ 開發工具

    GTFOBins: 系統權限提升工具集

    這是一個對於系統管理員與資安研究人員極其重要的資源網站。它彙整了各種在 Linux/Unix 系統中可以被濫用以繞過權限限制的二進位檔案(Binaries)。了解這些漏洞是強化系統安全性、防範權限提升攻擊的第一步。🛡️

    👉 查看原文連結

    Mo RAM, Mo Problems (2025): 記憶體容量增加帶來的挑戰

    隨著硬體技術進步,記憶體容量越來越大,但這也帶來了新的複雜度問題。本文探討了在 2025 年的技術背景下,管理大規模記憶體時可能遇到的效能與架構挑戰。這對於底層系統開發者來說是必讀的技術深度解析。🧠

    👉 查看原文連結

    High Performance Git: 高效能 Git 優化工具

    針對大型專案中 Git 操作緩慢的問題,這項工具提供了優化方案。隨著儲存庫(Repository)規模日益龐大,提升 Git 的效能已成為提升工程團隊生產力的關鍵。這對於處理巨型代碼庫的開發者非常實用。⚡

    👉 查看原文連結

    💼 創業 / 商業

    微軟與 OpenAI 終止排他性與收入分成協議

    這是一則重磅新聞,微軟與 OpenAI 將結束彼此間的排他性合作與收入分成協議。這象徵著兩大巨頭之間的關係正在轉向更標準化的商業模式。這可能會改變未來 AI 軟體市場的競爭版圖與合作邏輯。📈

    👉 查看原文連結

    📦 開源專案

    Pgrx: 使用 Rust 開發 Postgres 擴充功能

    Pgrx 提供了一個框架,讓開發者能使用 Rust 這門安全性高且效能卓越的語言來編寫 PostgreSQL 的擴充功能。這不僅提升了資料庫擴充的開發效率,也確保了擴充功能的穩定性。對於追求極致效能的資料庫開發者來說是個福音。🦀

    👉 查看原文連結

    🌈 其他

    我眼中的藍色,與你的一樣嗎?

    這是一個引發哲學與科學討論的有趣話題,探討人類感官知覺的差異性。透過對色彩感知的討論,帶出人類如何理解主觀體驗的科學課題。適合在技術開發之餘,進行思考與腦力激盪。🎨

    👉 查看原文連結

    多倫多 SMS 詐騙大規模發送案逮捕三名嫌犯

    警方在多倫多成功破獲一起大規模 SMS Blaster(簡訊群發詐騙)案。這起案件再次提醒大眾,數位詐騙手段正不斷演進,且往往具有高度組織性。網路安全與防詐騙意識在當前社會顯得尤為重要。🚔

    👉 查看原文連結


    💡 今日觀點

    觀察今日的新聞,我們可以看到一個明顯的「矛盾趨勢」:一方面是 AI 技術(如 3D 重建、風格化語言模型)正朝著更細分、更具感官體驗的方向發展;另一方面,隨著數據量與模型規模的膨脹,資安風險與複雜度(Memory/Data Breach)也正同步呈幾何級數增長

    給讀者的行動建議:

    • 對開發者而言: 如果你正在處理 AI 相關專案,請務必重新檢視你的數據加密與隱私管理機制,不要讓你的專案成為下一個資料外洩的目標。
    • 對工程師而言: 考慮引入 Rust 等更具安全性的語言(如 Pgrx 的案例)來處理底層或核心組件,以應對日益複雜的系統挑戰。
    • 對投資人與決策者而言: 關注 AI 巨頭間合作關係的變動,這將決定未來技術標準與商業利潤的分配。


    “`

  • 失智家人確診後的第一週,先做這 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 裝好;第二週以後再做家裡硬體改造。

    相關工具(免費開源)

    相關文章

  • Hacker News 每日精選 – 2026-04-23

    “`html




    今日科技趨勢深度解析

    🚀 今日科技趨勢速報:從 AI 的過度開發到「低科技」的商業回歸

    今日的科技圈呈現出一種有趣的對比:一方面是 AI 模型在程式碼編輯上的精準度挑戰,另一方面則是農業領域對「去科技化」產品的強烈需求。同時,隱私安全領域再次敲響警鐘,提醒我們數位足跡的脆弱性。

    為什麼你需要關注這些話題? 無論你是開發者、創業者還是科技愛好者,理解 AI 的邊界、隱私漏洞的演進以及市場對簡約技術的需求,都是掌握未來趨勢的關鍵。

    🤖 AI/機器學習

    🤖 模型「過度編輯」問題:當 AI 修改程式碼改過頭時

    研究發現,目前的 AI 模型在進行程式碼編輯任務時,存在一種稱為「過度編輯」(Over-editing)的現象。這指的是模型在修改程式碼時,會改動到那些與目標任務完全無關的部分。這種行為不僅浪費 Token,更可能引入不必要的 Bug 或破壞原有的程式邏輯。開發者需要更關注如何提升模型在最小化改動下的精準度。

    👉 閱讀原文

    📰 Ars Technica 公佈其新聞編輯室的 AI 使用規範

    面對生成式 AI 的浪潮,知名科技媒體 Ars Technica 正式發布了其新聞室的 AI 使用政策。該政策探討了在確保新聞準確性與透明度的前提下,如何合規地運用 AI 工具。這為傳統媒體如何在 AI 時代維持公信力提供了一個重要的參考範例。

    👉 閱讀原文

    🛠️ 開發工具

    ☁️ 我正在打造一個雲端平台

    這是一篇關於個人開發者嘗試從零開始構建雲端基礎設施的深度實踐紀錄。作者分享了在構建雲端架構時遇到的技術挑戰、決策過程以及對現代雲端服務的思考。對於對雲端架構感興趣的工程師來說,這是一篇極具啟發性的技術日誌。

    👉 閱讀原文

    🔡 適用於微型螢幕的 5×5 像素字體工具

    針對極小螢幕(如微控制器 MCU 使用的顯示器)設計的 5×5 像素字體專案。開發者展示了如何在極限的像素限制下,依然能保持字體的可讀性與美感。這對於嵌入式系統開發者與硬體工程師來說是非常實用的工具。

    👉 閱讀原文

    🧠 無需類型檢查的「借用檢查」機制

    這篇技術文章深入探討了程式語言理論中一個非常硬核的概念:如何在不依賴強類型檢查的情況下實現類似 Rust 的「借用檢查」(Borrow-checking)。這對於理解記憶體安全與程式語言設計的底層邏輯具有高度價值。

    👉 閱讀原文

    💼 創業/商業

    🚜 阿爾伯塔初創公司:以半價銷售「無科技」拖拉機

    這是一個顛覆主流科技思維的商業案例。一家位於阿爾伯塔的初創公司發現,農民其實並不一定需要昂貴的高科技設備。他們透過提供功能簡單、價格僅為傳統產品一半的「無科技」拖拉機,成功切入了被忽略的市場,證明了「簡約」有時也是一種強大的商業競爭力。

    👉 閱讀原文

    🔒 其他(資安、科學與遊戲)

    🛡️ Apple 修復了警方可用於提取 iPhone 已刪除訊息的漏洞

    Apple 針對一個嚴重的安全漏洞進行了修復,該漏洞曾被執法部門利用來從 iPhone 中提取使用者以為已經刪除的聊天訊息。這項修復再次強調了數據刪除並不等於物理銷毀,數位隱私的防護需要持續不斷的系統更新。

    👉 閱讀原文

    🕵️ Firefox Tor 身份關聯漏洞:隱私防線的裂縫

    研究人員發現 Firefox 的 Tor 使用者可能面臨一個隱私漏洞,該漏洞能透過 IndexedDB 建立一個穩定的識別碼,進而將使用者的多個私密 Tor 身份與其真實身份聯繫起來。這對於追求極致匿名性的使用者來說是一個巨大的警訊。

    👉 閱讀原文

    🧬 生物學的物理「生命力」究竟是什麼?

    這是一篇來自 Quanta Magazine 的深度科學報導,探討了驅動生物學運轉的物理基礎。文章嘗試從物理學的角度解釋「生命力」如何轉化為生物系統中的能量與運作機制,挑戰我們對生命本質的理解。

    👉 閱讀原文

    🕹️ Tempest vs. Tempest:Atari 經典遊戲的重製與演進

    回顧 Atari 經典射擊遊戲《Tempest》的開發歷史與重製過程。這篇文章透過對不同版本遊戲的比較,展現了遊戲設計在不同時代背景下的演變,適合懷舊遊戲愛好者與遊戲開發者閱讀。

    👉 閱讀原文


    💡 今日觀點與行動建議

    今日核心趨勢: 我們正處於一個「複雜性與簡約性」激烈碰撞的時代。AI 技術正試圖解決所有問題(甚至有時改過頭了),而現實世界的市場(如農業)卻開始反向尋求簡單、可靠、低成本的解決方案。同時,數位隱私的戰場正從「數據加密」轉向更隱蔽的「指紋識別」與「系統底層漏洞」。

    給讀者的行動建議:

    • 對於開發者: 在使用 AI 輔助寫程式時,請務必進行嚴格的 Code Review,特別是檢查 AI 是否改動了不該動的邏輯(避免過度編輯)。
    • 對於創業者: 不要盲目追求「高科技」解決方案。思考一下,你的客戶是否其實只需要一個「更便宜、更耐用、更簡單」的版本?
    • 對於一般用戶: 定期更新您的作業系統與瀏覽器,並意識到「刪除數據」並不等於「絕對隱私」,在高度數位化的世界中,謹慎處理敏感資訊是基本功。



    “`

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

    重點摘要

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

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

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

  • Hacker News 每日精選 – 2026-04-22

    “`html




    科技趨勢早報

    🚀 科技趨勢早報:AI 圖像革命與軟體工程底層思維

    今日的科技圈展現了極強的兩極化趨勢:一邊是 AI 技術(如 ChatGPT 圖像生成)與大規模商業併購(SpaceX 傳聞收購 Cursor)帶來的感官衝擊;另一邊則是開發者回歸底層,鑽研軟體工程定律、記憶體管理與硬體製造的深度思考。理解這些趨勢,不僅能讓你跟上工具的演進,更能幫助你在技術浪潮中建立穩固的底層邏輯。

    🤖 AI / 機器學習

    ChatGPT 圖像生成 2.0 (ChatGPT Images 2.0)

    OpenAI 正式推出了新一代的圖像生成能力,這標誌著生成式 AI 從「嘗試性生成」向「精準控制」的重要跨越。這次更新大幅提升了圖像的細節表現力與視覺一致性。對於需要高品質視覺內容的創作者與開發者來說,這是一個極具威力的工具升級。

    👉 查看原文

    🛠️ 開發工具與工程實踐

    軟體工程定律 (Laws of Software Engineering)

    這是一份關於軟體開發中不變規律的深度總結。它探討了複雜度、規模化與系統設計之間的核心矛盾。對於想要從「寫程式」晉升為「設計系統」的工程師來說,這份清單具有極高的參考價值。

    👉 查看原文

    Vercel 安全漏洞分析:OAuth 攻擊與供應鏈風險

    研究人員揭露了 Vercel 平台面臨的 OAuth 攻擊風險,這可能導致平台環境變數遭洩露。這起事件再次提醒了開發者,在高度依賴雲端平台的現代開發流程中,供應鏈安全與環境變數的管理至關重要。安全防護不應僅停留在代碼層面,更要延伸至基礎設施配置。

    👉 查看原文

    無需 Unsafe 代碼的垃圾回收機制 (Garbage Collection Without Unsafe Code)

    本文深入探討了如何在不使用低層級、不安全(Unsafe)代碼的前提下,實現高效的垃圾回收機制。這對於追求記憶體安全且希望保持高性能的語言開發者來說,是一個極具技術深度的研究課題。它挑戰了傳統對於「高效能必經風險」的認知。

    👉 查看原文

    資深工程師的經驗談 (Drunk post: Things I’ve learned as a senior engineer)

    “經驗往往不是從成功的專案中學到的,而是從那些修復半夜崩潰的系統中磨練出來的。”

    這篇以非正式風格寫成的文章,分享了資深工程師在多年職業生涯中的深刻體悟。內容涵蓋了技術決策、團隊協作以及如何面對工程壓力。雖然語氣輕鬆,但其中蘊含的職涯智慧對於初中階開發者來說非常受用。

    👉 查看原文

    💼 創業 / 商業

    SpaceX 傳聞將以 600 億美元收購 Cursor

    科技界傳出 SpaceX 可能達成協議,以天價收購 AI 編碼助手 Cursor 的消息。若此傳聞屬實,將展現出頂尖科技巨頭對於「AI 自動化開發」領域的極度渴望。這不僅僅是一場併購,更是 AI 如何全面接管軟體開發流程的商業信號。

    👉 查看原文

    🧪 其他 (科學、硬體與生活)

    在家製作 RAM (Making RAM at Home)

    這是一段令人驚嘆的硬體實驗影片,展示了如何從基礎元件開始,在家中親手打造隨機存取記憶體(RAM)。雖然這對於一般使用者沒有實用性,但對於硬體愛好者來說,這是一場極致的底層架構教學。它揭示了數位世界最基礎的硬體運作邏輯。

    👉 查看原文

    火星上發現多樣化的有機分子

    最新的科學實驗顯示,火星上存在多樣化的有機分子,這為地外生命的研究提供了新的線索。這項發現強化了科學家對於火星曾經具備生命條件的假設。這不僅是天文學的突破,更是人類探索宇宙起源的重要一步。

    👉 查看原文

    Acetaminophen 與 Ibuprofen 的差異分析

    針對常見止痛藥成分 Acetaminophen(乙醯胺酚)與 Ibuprofen(布洛芬)的科學比較。文章分析了兩者的藥理作用、副作用以及適用場景。在處理健康問題時,了解基礎的生化差異是非常重要的自我保健知識。

    👉 查看原文

    數位化大英百科全書 1911 版 (Britannica11.org)

    這是一個極具人文情懷的開源專案,將 1911 年版的大英百科全書進行了結構化的數位化處理。這讓古老的知識能夠以現代化、可搜尋的方式與人類共享。它是數位典藏技術與知識傳承結合的典範。

    👉 查看原文


    💡 今日觀點與行動建議

    觀察今日的熱門話題,我們可以發現一個明顯的趨勢:「工具的極致化」與「底層的結構化」正在並行發展。 當 AI 工具(如 ChatGPT 與 Cursor)讓開發門檻降低、速度提升時,業界對於「軟體工程定律」與「記憶體安全」等底層知識的需求反而更加渴求。因為當工具變強大時,出錯的代價也會更高。

    🛠️ 給讀者的行動建議:

    • 擁抱 AI,但不要放棄思考: 試著使用 ChatGPT 2.0 提升你的生產力,但務必理解它產出的邏輯,避免成為「只會貼代碼」的開發者。
    • 回歸基礎: 在追求新框架的同時,抽空閱讀關於軟體工程定律或底層記憶體管理的技術文章,這將是你建立技術護城河的關鍵。
    • 重視安全意識: 從 Vercel 的案例中學習,開發時應具備「供應鏈安全」的思維,定期審查環境變數與第三方套件的權限。



    “`