這幾個星期，我把大半的精力投入在了一個名為 Sovereign Health Agent (SHA, 自主健康代理人) 的地端專案中。隨著「大書」手冊（共 12 章 Guides）的發布與倉庫物理重建，這個專案終於迎來了一個階段性的穩態。

今天在白板前，我不打算細細羅列最新的改版日誌，而是想和大家分享這段 「個人自主健康數據代理人」從無到有的研發歷程，以及我們在人機協作、資料庫架構與隱私防守中所體會到的心法。

📐 起點：源自面臨生命關卡的 12 大核心痛點#

Sovereign Health Agent 並非憑空捏造的玩具專案，而是一部為了解決真實家庭面臨健康與生命關卡時，所啟動的系統工程。

在我們的願景與需求定義（req_vision）中，我們將患者與家屬面臨的生命抉擇梳理為四大範疇與 12 大核心生命痛點：

  1. 急重症與生命抉擇：包含「剛確診癌症時的慌亂無助」、「親友臨終時的安寧抉擇與照顧關懷」、「面對昂貴自費醫療時的決策拉鋸」以及「疑似醫療疏失時的求助無門」。
  2. 日常照護與用藥安全：包含「日常用藥的醫囑遵從」、「多重用藥銀髮族的用藥與跌倒風險（Beers Criteria）」以及「術後出院的居家照護真空期」。
  3. 急症與健康焦慮：包含「孩童半夜突發高燒的焦慮」、「急診室漫長等待的分級恐慌」以及「健檢報告紅字或疑似腫瘤的心理煎熬」。
  4. 醫療體系導航與長照：包含「查不出病因的醫療流浪」與「長輩突然失能時的長照 2.0 資源申請空窗」。

自己的數據自己保管，自己的 AI 代理人只在本地運行。正是在這些強烈痛點的驅使下，我們推動了以下四個階段的研發與架構演進。

📅 研發歷程第一階段：地端四分離資料庫的定錨 (建置篇)#

研發的最初期，我們面臨的是「資料標準化與落地」的難關。

為了不把數據傳到第三方，我們在本地建置了基於 SQLite 的個人健康資料表。為了達到醫療系統級的合規性，我們採用了 HL7 FHIR R4 的標準語意，將健保署數據、出院病摘要與檢驗報告對合。

在架構設計上，我們推動了**「四分離資料庫模式」**（患者個資、臨床指標、系統配置、科研對接表分庫隔離存放，對合 [REQ-014] 實體隔離機制）。這種分離設計確保了即使未來需要與外部醫療機構或科研平台進行去識別化對接，患者的真實姓名與身份識別資訊也絕對不會流出本機，在物理層面守住第一道隱私防線。

同時，我們提出了 「極簡自理三支柱匯入法」 ([REQ-022])：引導使用者僅需從健康存摺與紙本報告中匯入「1. 重要的住院報告、2. 目前用藥與用藥改變資訊、3. 當前與重要歷史指數」這三項核心數據，AI 助理就能快速還原出治療方案演變與指標變化趨勢，以最低的操作成本發揮最高效的照護指引價值。

📅 研發歷程第二階段：大書 Guides 與 AI 思辨防線的建立 (思辨篇)#

有了資料庫後，我們發現僅靠 AI 的原始推理是不夠的。大模型的「幻覺」在醫療領域是致命的。

因此，我們撰寫了詳細的 Guides 指引，並將其模組化。這個階段的思辨突破在於：

  1. 未知認錯 (IDK, I Don’t Know) 防線 ([REQ-011])：我們規範 AI 代理人，回答任何醫療問題前，必須先展示並執行資料庫檢索程序，且每點醫學論點皆須標註可追溯的科學文獻（如 PMID）；若查無實證，必須誠實回答不知道，絕不能猜測胡說。
  2. 用藥變更三向引導迴路 (SOP) ([REQ-016])：當系統自動偵測到藥囑異動時，AI 必須立刻啟動三向引導迴路——追溯用藥起因（如膽固醇升高與立普妥）、指出後續療效與安全監控指標（如 ALT/AST、CPK 指數），以及給予日常運動與飲食禁忌指引，避免多重就醫導致的用藥衝突。

這些引導規則與思辨範式被我們整理成「大書」的前半部分，作為 AI 運行與家屬閱讀的共同語意認知地圖。

📅 研發歷程第三階段：地端工具箱落地與 SSOT 檔案治理 (工具篇)#

隨著功能變多，專案遇到了檔案維護混亂的瓶頸。

在工具層面，我們落地了對話快捷指令、離線 SHVT 分析工具，以及將資料庫完整打包備份的 db_porter.py。 特別是我們開發了 離線查證防幻覺工具箱 ([REQ-023])：利用本地 CLI 查詢腳本（utils/health_query_tool.py），能完全離線查詢本地個人資料庫中的疾病、用藥、檢驗代碼（LOINC/健保碼）翻譯，並自動生成指向食品藥物管理署（TFDA）許可證或中央健康保險署（NHIA）藥物給付規定的實時查證連結。

在管理層面，我們曾因為「同時維護草稿 Guides 與正式 Guides」而踩坑，險些造成內容覆蓋。為此，我們進行了 SSOT (Single Source of Truth) 單一真理源頭重構——將 book/ 目錄下已脫敏的 Guides 確立為唯一編輯源頭。

我們將發布腳本重構為**「安全防禦校驗工具」**，直接在後台對大書進行：

  • 個資去識別化校驗：確保沒有任何真實病歷號或姓名殘留。
  • 路徑相對化：消除本地物理路徑透露的個人隱私。
  • 台灣用語校正：將「優化」、「信息」等對齊為台灣慣用語「最佳化」、「資訊」。

📅 研發歷程第四階段：Git 時空清洗與物理安全防守 (合規篇)#

研發的最後一個階段，我們將焦點放在了「版控歷史的隱私清理」上。

在自審過程中，我們發現在早期的測試代碼中，仍有寫死的真實姓名與病歷號殘留。雖然最新一版的代碼已經將其修改為去識別化化名，但 Git 的歷史 commit 中依然存在這些足跡。

為了不留任何後患，我們在備份完畢後，執行了徹底的**「Git 刪除與重建」**：

  1. 物理刪除子模組內舊有的 .git/ 歷史。
  2. 以 100% 乾淨去識別化、且將臨時 scratch/ 目錄剛性排除在外的代碼重新初始化 git init。
  3. 推送到 GitHub 上全新建立的同名空倉庫，在時空軌跡上做到 100% 的隱私淨空。
  4. 在大專案中重新對齊指針。

這一步雖然繁瑣，但它為整個研發歷程畫下了一個極具工程尊嚴與安全合規的句點。

💡 研發心法：不要輕忽 scratch/ 帶來的隱私缺口#

回顧這段歷程，最深刻的教訓就是：永遠不要低估臨時草稿目錄 (scratch/) 的風險。

開發者在測試 OpenCV 影像分析或 Playwright 爬蟲時，為了方便，經常會把含有真實個資的測試照片或網頁隨手丟在 scratch/ 目錄中。如果在專案啟始之初沒有將其寫入 .gitignore，這些資料極易隨著 git add . 被推送到 GitHub 上。 「數據主權」不只是代碼的架構，更是日常開發習慣中對隱私的最高敬畏。

Sovereign Health Agent 的研發是一場長跑。透過人機協作（AI 助手與我的共同迭代），我們證明了即使在有限的地端資源下，我們依然能為家人建構起一座安全、智慧且完全自主的健康守護防線。

AI 協作聲明： 本文由筆者提供原始遊記草稿與心情隨筆，由 AI 助手 Antigravity 彙整架構與修辭。結合了 WalkGIS 的地理紀錄特點與哈爸筆記的敘事風格，展現人機協作下的流域探索成果。