caretaiwan

---

原作者脈絡

以下段落保留原作者文字，用來說明原型階段的研究、產品決策與停止點。目前維護分支的規則以 docs/ 為準。

關於作者

我是一名平面設計師（7-8 年專業資歷）——不是傳統工程師。這個專案展現的是：一個具備產品思維的設計師，搭配 AI 開發工具（Claude Code），再給自己時間深入研究，能做到什麼程度。

我並不是在宣稱我能從零寫出 production 等級的程式碼。我宣稱的是：我研究了一個真實的社會問題、做了產品決策、透過 AI 結對程式設計推動整個開發、為自己的產品做了資安稽核，並且知道何時該收手。這就是這個專案要展現的能力組合。

TL;DR

我研究了台灣約 22 萬名外籍家庭看護的工作處境，歸納出 5 個系統性挑戰（手機使用受限、慢性疲勞、合約範圍模糊、社群信任落差、權力不對等），然後用 Claude Code 推動一個雙端產品的開發：

• 看護端 PWA：日常活動記錄 ＋ 家屬溝通工具——3 秒記錄（生命徵象、用藥、跌倒、進食、睡眠、排便）含看護備註、多位長者醫護資訊卡、完整可離線的 PWA。
• 家屬端 LINE Bot：6 位數配對碼、簽章驗證的 webhook、看護主動分享記錄時才推播通知。

接著我依 OWASP ＋ 台灣個資法做了一次結構化資安稽核，產出 15 項發現的報告，並修補了全部 11 項高／嚴重等級的問題。

範圍決策：早期版本曾包含一套 50 情境的醫療分流資料庫，附具名來源引用。我在對法律風險做威脅建模後移除了它：一個平面設計師（我）透過 AI 工具發布醫療建議，即使加了免責聲明，只要出一次不良後果 → 50-300 萬元訴訟 ＋ 永久的姓名搜尋負面紀錄，風險不成比例。溝通／記錄這一層，本身就有真實價值，不需要綁那個風險。知道什麼「不該」做，也是能力的一部分。 醫療內容的研究仍保留在 git 歷史與個人研究筆記裡，留給有能力扛起法律責任的 NGO 夥伴接手。

原作者階段曾嘗試接觸 NGO 合作路徑。此處不代表中揚資訊目前已取得任何協會背書或合作關係。

---

為什麼做這個

問題場景

台灣有 約 22 萬名外籍家庭看護，多數來自印尼、越南、菲律賓，在剝奪了許多一般勞工保障的勞動契約下工作。他們通常是：

• 家中唯一會注意到失能長者細微病況變化的人
• 24 小時待命、休息有限
• 中文只夠勉強生存——醫療術語、方言、地方口音都是落差
• 出事時不是決策者——決策權在家屬，而家屬往往人在遠方
• 早已把智慧型手機和 Facebook／Zalo 當成連回家鄉的生命線

我先做的研究

我花了不少時間在「讀」而不是「寫程式」：

• 臺北市政府的三語看護手冊（中文 ＋ 英、印、越；2022）
• 高雄長庚 × 高市府的失智照護 Q&A（130 頁、三語）
• 臺北市《守護記憶》失智手冊（88 頁）
• 台灣移工聯盟（MENT）、TIWA、勞工局的報告

我把研究結果拆成 5 個挑戰（每個在寫任何程式之前，都先寫了一份深入備忘）：

#	挑戰	關鍵洞察
1	手機使用受限	看護的手機常被雇主沒收／限制。APP 必須能在 15 秒的偷瞄裡用完，不靠通知、不要多餘介面。
2	慢性疲勞	資訊密度會殺死使用率。倒金字塔式分流（現在「該做什麼」）勝過參考書式的內容。
3	合約範圍蔓延／模糊	看護常被要求做合約外的事。APP 應該提供資訊，但不在勞雇糾紛中選邊。
4	社群信任落差	看護是跟 FB／Zalo 社群求證，而不是官方。APP 取代不了社群——它該產出能在 FB 分享流程中存活的可分享卡片。
5	權力不對等	勞工無法在沒有風險的情況下對雇主提出異議。把資料存在家屬帳號裡的工具，會複製這種不對等。資料共有權是一項功能，不是加分項。

這 5 點形塑了底下每一個產品決策。

---

APP 裡有什麼

看護端（PWA）

• 3 秒記錄：6 種記錄類型（體溫、排便、睡眠、跌倒、吃藥、吃飯），含 5 個一點即填的快捷短語 ＋ 自由文字看護備註
• 多位長者醫護資訊卡（用藥、過敏、聯絡人、醫師）——是看護自己輸入的資訊性資料，不是醫療建議
• 今日摘要 widget——顯示當日筆數 ＋ 已分享給家屬幾筆
• 緊急電話快捷頁——119 ／ 110 ／ 1955（移工權益）／ 0800-474-580（失智照護）／ 113（保護專線）
• 透過 Service Worker 的完整離線支援（靜態資源 cache-first、導覽 network-first）
• 加密備份檔（PBKDF2 ＋ AES-GCM 256），讓備份檔可安全分享
• 可安裝 PWA、深色模式、Lucide React 圖示、自訂設計 token
• 無分析、無追蹤器、無第三方 JS

家屬端（LINE Bot）

• LINE Messaging API channel；webhook 採 HMAC-SHA256 簽章驗證
• 6 位數配對碼（32 字元字母集、移除易混淆字）含 24 小時有效期
• 防劫持保護：只有當 paired_line_user_id IS NULL 時綁定才會成功（Postgres 層級檢查）
• 速率限制：每個 LINE userId 每 5 分鐘最多 5 次嘗試（in-memory）
• 由看護按下「送出給家屬」開關（預設關閉）才觸發推播

資安與隱私

• 全程 HTTPS、安全標頭（HSTS、X-Frame-Options、Permissions-Policy）
• POST 端點同源檢查（在 SameSite cookie 之外再加一層 CSRF 防護）
• 錯誤訊息已淨化（不洩漏 DB schema）
• 加密備份檔格式（PBKDF2-SHA256 20 萬次迭代 ＋ AES-GCM 256-bit）
• 稽核日誌表含 IP 去識別化（末段歸零、IPv6 截斷）
• 被遺忘權 API ＋ UI 按鈕（個資法第 11 條合規）
• LINE userId 永不暴露給前端 JS（沒有 XSS 外洩路徑）
• 捲動鎖定的雙重同意流程——首次使用者必須展開隱私政策與服務條款兩個摺疊區、各自捲到最底，「我同意」按鈕才會啟用。版本記錄在 localStorage，政策更新會重新詢問。

完整稽核報告：SECURITY_AUDIT.md。15 項發現、11 項已修、4 項附威脅建模理由刻意延後。

---

維護分支架構

中揚資訊維護分支的目前架構請看 docs/engineering/ARCHITECTURE.md。正式部署方向以 VM / Docker 為主，不綁定特定雲端供應商。

下面段落描述原作者原型階段的實作，保留作為歷史脈絡。

原作者原型技術堆疊

層	選擇	為什麼
框架	Next.js 16（Turbopack）＋ React 19	App Router 做乾淨的路由切分；Server Actions 處理 OAuth 登入流程（Auth.js v5 需要）
認證	Auth.js v5（next-auth@beta）＋ LINE provider	多數看護唯一已經有的登入方式
資料庫	Supabase（Postgres ＋ REST）	免費方案夠做原型；SQL 對 schema 很誠實
推播	LINE Messaging API	比 push notification 阻力低（iOS PWA 幾乎不支援推播）
樣式	Tailwind 4 ＋ Lucide React	這個規模不需要設計系統框架
部署	Vercel	原作者原型部署方式
PWA	手寫 Service Worker	不用第三方 PWA 套件——快取策略完全可控

我刻意「不」用的

• 不用狀態管理函式庫——useState ＋ localStorage 就夠；這個 APP 主要是表單與清單
• 不做分析——隱私優先；之後若需要使用數據，再明確埋點
• 不用 CSS-in-JS runtime——Tailwind 編譯掉、沒有 runtime 成本
• 不用 Supabase Auth——LINE Login 本來就必須有；再疊一層 Supabase Auth 等於要管兩套身分系統

---

關鍵決策與取捨

1. LINE Bot vs. Web Push

iOS PWA 的 Web Push 在使用者把圖示加到主畫面之前都不可靠，就算加了也很脆弱。多數台灣家庭本來就 24 小時在用 LINE。選 LINE 移動了隱私邊界（LINE 公司看得到訊息），但換來更高的送達率與對家屬零安裝阻力。

我在隱私政策裡明確記錄了這個取捨。

2. service-role ＋ 認證檢查 vs. Supabase RLS

我選了 service-role 搭配嚴格的伺服器端認證檢查，而不是 RLS。RLS 架構上更乾淨，但會需要把 APP 改成用 anon-key ＋ 自訂 JWT 簽發——多日的重構，換來的真實安全提升有限，因為 service-role 本來就只在伺服器端。

我把它標為 production 的 Phase B TODO，威脅建模理由寫在稽核報告裡。

3. localStorage 加密：刻意不做

我考慮過用 WebCrypto 把 localStorage 裡的個資靜態加密。威脅建模後發現：任何能讀到 localStorage 的、有裝置存取權的攻擊者，也能讀到放金鑰的 IndexedDB。那是做做樣子，不是真正的保護。

我改做了加密備份檔（PBKDF2 ＋ AES-GCM ＋ 使用者通關密語）——這才防到最實際的威脅：備份 JSON 檔不小心透過 Email／雲端硬碟外流。

4. 從醫療內容轉向

最初的 v1 包含 50 個情境，附紅／橘／綠分流與處置步驟，引用具名的台灣醫療來源。在評估法律風險後——即使有免責聲明，由非醫療背景作者透過 AI 發布的醫療內容會造成直接責任——我移除了它。

這個轉向把產品從「醫療參考 ＋ 記錄」重新定位成「記錄 ＋ 家屬溝通工具」。剩下的功能面（記錄、醫護資訊卡、家屬推播）完全不涉及醫療建議——就只是看護輸入的資料，以及一個受控的分享管道。這是本質上完全不同的風險輪廓。

研究與內容草稿仍留在 git 歷史與個人研究筆記裡，留給任何有能力妥善扛起法律責任的 NGO 夥伴。

5. 停在作品集，不走商業

這是最難的決定。這個 APP 能用。我大可推政府採購（台北市勞動局有移工工具的預算）。

但從「朋友能用」走到「公開上架、政府採購的服務」，實際的合規工程是：

• 個資保護管理制度（PIMS）——每年 3-10 萬元顧問費
• ISO 27001——一次性 5-15 萬
• 滲透測試——每年 1.2-3 萬
• 隱私／服務條款律師審閱——3-5 萬
• 24 小時待命維運

---

Built With

• linebot
• next.js
• pwa