AI協作

這個題目是訂閱區的歐陽醫師許願的。他說得很準：認真看 AI 運行的資料夾，好像都才幾十 MB，但是電腦容量就是被吃掉一大半。 這件事我自己也遇到很多次了。我的 C 槽 953 GB，過去一個多月每隔幾週就快滿一次，每次都是跟 Claude 說「幫我清理」，清完過陣子又滿回來。這次我們不清了，改成把一個多月來每一次清理的對話全部翻出來對帳，算清楚是誰一直長回來。 查出來四層，照體積排序。其中一層是我們自己開源出去的工具，這個下面會老實講。 一、雲端同步：檔案被讀一次，就永久回到你的電腦 這台電腦的 OneDrive 雲端有大約 400 GB。檔案設成「僅雲端」之後，檔名在、圖示在，不佔空間。但只要有任何程式打開那個檔案，同步軟體就會把它下載回本機，而且除非你自己把它釋放回雲端，它就會一直佔著空間。 八月十七號那次大掃除清出 382 GB。四天後回頭看少了 56 GB，其中課本 PDF 那幾個資料夾自己回到本機 45 GB。 這件事的怪，怪在因果被切斷了。吃掉容量的那個動作，跟長出來的那些檔案，看起來完全沒關係。你翻遍 AI 的資料夾，當然只有幾十 MB。 我們怎麼把它抓出來的 這一段是這篇最想分享的：不是我自己會查，是我跟 Claude 一起把範圍縮小的過程。 第一步，先問清楚機制。 我請他上網查「OneDrive 在什麼情況下會自動把僅雲端的檔案下載回本機」。查回來的答案是：只要有程式開啟那個檔案就會，不必真的讀內容。這一句話後來就是破案關鍵。 第二步，一個一個排除。 每關掉一個嫌疑犯就重新量一次本機佔用： Windows 搜尋索引：停掉六分鐘，佔用沒變化 檔案總管縮圖、防毒掃描、Google Drive、iCloud、Synology Drive：都排除 OneDrive 自己重抓：手動把二十個檔案標成「釋放空間」，六分鐘內一個都沒有被抓回來 排到這裡，OneDrive 本身的嫌疑就洗清了。它只是執行者，不是發動者。 第三步，我提了一句話，方向就轉了。 當下我們一直在找「現在正在跑的東西」，可是我想到：這些下載搞不好是幾個小時前下的指令留下來的，那支程式可能還活著，只是沒人注意。 我把這句話丟給他，他回頭去翻還在執行中的舊程序，當場抓到兩支： 下午五點二十某個 AI session 下的 find 指令，尾巴接了 head，本來只要前二十筆。head 拿夠了自己結束，前面的 find 卻沒有跟著死，一路跑了五個小時，回抓 19 GB 抓它的同時，另一個 session 又下了一支掃全機的 find，三分鐘再吃掉 6 GB 兩支都殺掉之後，回抓當場歸零。 ...

上週幫一群麻醉科的醫師朋友上了一堂 AI agent 上手課。課後回饋很有意思：「權限框與 auto mode」同時出現在兩張名單的前段，投「最有收穫」的人很多，投「沒聽懂」的人也很多。代表這東西重要，但一堂課的節奏講不完。這篇把它一次講完整。 還沒裝起來的朋友，可以先看從零開始用 AI agent那篇，裝好再回來。 權限框是什麼：它動手之前，先舉手 第一次叫 Claude Code 或 Codex 整理資料夾，最不習慣的就是它一直跳框問你「可以嗎？」。 這個框其實是整套系統最重要的安全設計：AI agent 要動你電腦裡的東西之前，必須先讓你點頭。框裡通常有三個部分： 它想跑的指令：一行終端機指令，像 ls、mkdir、rm 它自己的白話解釋：指令下面那一兩行，說明它想做什麼、為什麼 你的選項：同意這次、同意以後都不用問、拒絕 你不需要會終端機指令。你只需要看得懂那行白話解釋，然後判斷「合理嗎」。看不懂的時候有兩招： 看不懂它想幹嘛的兩招 直接回它：「用五歲小孩能懂的方式解釋你現在要做什麼」（英文縮寫叫 ELI5，Explain Like I’m 5，AI 都看得懂） 把那行指令複製，貼給網頁版的 AI 問「這個指令會做什麼？有風險嗎？」 四種模式：按 Shift+Tab 切換 每一步都問你，等它做完一件事你可能按了二十次同意。所以 Claude Code 提供好幾種模式，按 Shift+Tab 就能輪流切換，畫面上會顯示目前在哪個模式。日常用得到的是這四個： 模式 它會怎樣 什麼時候用 default（預設） 每個會改到東西的動作都先問你 剛開始建立信任的階段 plan mode 只能讀、不能寫，先研究再給你一份計畫 想先看它打算怎麼做；要碰重要資料的第一步 accept edits 檔案編輯自動放行，跑指令仍會問 改稿、寫筆記這類編輯密集的工作 auto mode 系統自動判斷每條指令危不危險：安全的直接放行，危險的攔下來問你 日常主力 （Claude Code 其實還有更多模式，像給無人值守環境用的 bypass permissions，那些跟日常上手無關，先不用管。） auto mode 為什麼反而比較安全：警報疲勞 臨床的人對 alarm fatigue 都不陌生：monitor 什麼都叫，叫久了大家聽到聲音只是伸手把它按掉。權限框也一樣。當每一個框都要你同意，你很快就會停止閱讀，變成反射性按同意。這時候「每步都問」給你的不是安全，是安全感。 ...

先講結論，五句話： 用腳本自動化批次抓病歷，不是灰色地帶。只在臨床照護必要範圍、只碰自己照護的病人、用完不留存，跨過這條線，法規要求醫院留得下每一筆存取與複製紀錄。 台灣沒有 HIPAA 十八項那種清單。我們的標準是「無從辨識特定個人」這個結果，刪滿十八項不等於完成去識別化。 只要還原用的代號對照表還在你電腦裡，你手上那份遮完的病歷就不能當匿名資料看，它仍有間接識別的可能，屬於假名化而不是匿名化。 往外送的順序只有一種：本機模型優先，院內部署次之，境外商業模型最後，而且送之前要先看自己醫院的規範。 真的要往外送，別送「遮過的病歷原文」，送「重寫過的臨床問題」。讓一段紀錄被還原的不是欄位，是敘述的唯一性。 下面把推論過程攤開。 這篇的起點，是上一篇 chart-scrub（病歷去識別化工具）發文後，黃祥瑋醫師在留言提了兩件很重要的事：一是自動化把病歷抓下來收集通常是違規的，只是看醫院有沒有在抓；二是即便符合 HIPAA 十八項，他個人還是不會把資料送到雲端或境外。 這兩句都站得住，而且背後都有具體的法源。我把條文一條一條查回全國法規資料庫核對現行版本，順著「抓病歷、遮病歷、送病歷」這條動線整理在下面。 一、抓病歷：法律看的不是工具，是範圍 用 AutoHotkey 複製跟手動 Ctrl+C 複製，在法條上沒有分野。法律真正在意的是範圍：你抓的是不是自己照護的病人、是不是照護必要、抓完有沒有留下來累積。 先講最實際的一層：這件事留得下紀錄。醫療機構電子病歷製作及管理辦法（111 年 7 月 18 日修正）第 13 條要求，病歷的存取、增刪、查閱、複製，連同執行人員、時間、內容，都要保存完整紀錄；第 4 條還要求系統要有異常使用的因應措施。誰在什麼時間複製了哪些內容，法規要求院方必須留得下來。至於院方實際能看到多細、能不能直接算出你複製了幾筆，要看各院 HIS 與稽核設定，條文不保證這件事。祥瑋說的「看醫院有沒有在抓」，制度上就是這個意思：痕跡一定在，抓不抓是各院的執行。 而且實務上最先找上門的，通常是自己醫院，法院排在很後面。醫院這幾年一直被要求把資安做起來（醫院屬於資通安全管理法的「緊急救援與醫院」關鍵基礎設施領域，個別醫院可經衛福部指定為關鍵基礎設施提供者，被指定的要提出資安維護計畫），端點監控與異常告警愈做愈普遍。醫院也有義務管人：醫院個人資料檔案安全維護計畫實施辦法要求總床數一百床以上的醫院（公立醫院準用）依業務需要設定存取權限、跟所屬人員約定保密義務、把個資使用紀錄至少留存六個月。批次抓病歷最可能的劇本，是資安告警、約談、院內懲處，一路都還沒碰到刑法。 那刑法呢？大家最常聽到的是刑法第 359 條，這條值得把構成要件講完整，因為它常被簡化成「用腳本抓就是犯罪」，那不是條文寫的。它要同時滿足三件事才成立。第一是「無故」：取得紀錄欠缺正當理由。臨床照護必要範圍內調自己病人的病歷，是有授權的；超出照護必要、碰到不是自己照護的病人，授權基礎才會被質疑。第二是取得的要是「他人」電腦系統的電磁紀錄：帳號是你的，不代表資料是你的，你對那批資料有沒有處分權限要個案認定。第三是「致生損害於公眾或他人」：這個獨立要件最常被漏掉，成立與否要能說明損害是什麼，複製了不等於當然有損害。所以用自己的帳號不等於免責，大量複製也不等於當然犯罪，中間那片灰色地帶，不值得拿職業生涯去測試。我沒有找到醫師用本人 HIS 帳號批次下載病歷的公開判決，這裡只能講風險方向，不能講定論。 最後一層是個資法。病歷是個資法第 6 條的「特種個資」，原則禁止蒐集、處理、利用，只有六款例外能開門（例外長什麼樣，第四節講研究的時候會攤開）。臨床照護本身有法源，這不是問題；問題出在「抓下來累積成一個資料集」的那一刻：複製、儲存、輸出在個資法上都算「處理」，從那一刻起你就需要一個答得出來的例外，而「我自己想研究」不在清單裡。 所以抓病歷的安全範圍就是一句話：只在臨床照護必要範圍、只碰自己照護的病人、用完不留存。自動化只是把這件事做快，沒有改變它的性質；範圍守得住，工具隨你選。 二、什麼才算「去識別化」 台灣看結果，不看清單 先介紹 HIPAA 十八項。HIPAA 是美國 1996 年的《健康保險可攜性與責任法案》，它的 Safe Harbor 規則列了一張清單：姓名、比州更小的地理區域、跟個人有關的日期、電話、Email、身分證號、病歷號、保險號、帳號、證照號碼、車牌、裝置序號、網址、IP、生物特徵、臉部照片、其他任何唯一識別碼，十八類刪乾淨，再加一個常被忘記的第二條件：機構沒有實際知情，認為剩下的資訊單獨或與其他資料結合仍能辨識個人。兩個都滿足，法律上就「視為」完成去識別化（地理與日期各有細節例外，這裡不展開）。它最大的好處是可操作：照清單做完，大部分情況就有明確依據，不用逐案猜。 台灣沒有這張清單。我們的門檻在個人資料保護法施行細則第 17 條，寫的是「以代碼、匿名、隱藏部分資料或其他方式，無從辨識該特定個人」。那是結果標準，不是清單標準：法律不管你刪了幾個欄位，只問最後那段文字指不指得回一個人。刪滿十八項，不等於在台灣已經完成去識別化。 復健科的人對這件事要特別有感。罕見診斷，加上特定術式，加上就診年月，加上哪一家醫院，四項湊起來常常就足以回推到一個人，而這四項沒有一項在十八項清單裡。真正把人認出來的，常常是整段敘述的唯一性，而不是某個特定字串。 這個結果標準的天花板，是憲法法庭 111 年憲判字第 13 號，就是 2022 年 8 月的健保資料庫案。它講的去識別化標準，理由第 54 段的原文是「使一般人採取當時存在技術與合理成本，在不使用額外資訊時，不能識別特定當事人」。要注意這份判決審查的對象：它處理的是個資法第 6 條第 1 項但書第 4 款下的健保資料庫利用，所以才會一併要求限定醫療衛生目的、限定主體（公務機關或學術研究機構）、統計或學術研究的必要性，以及獨立監督機制。這是那個案子的整組理由，不是任何人把病歷去識別化之後都要打勾的通用條件。不過放在那個脈絡下讀，方向仍然很清楚：去識別化本身不是免死金牌，它是跟目的限制、監督機制包在一起才站得住的。個人把去識別化的資料丟給境外商業模型，這兩個配套剛好都是零。 ...

門診遇到一個有意思的個案，想查一下教科書怎麼講、想跟 AI 對一對自己的鑑別診斷有沒有漏掉什麼。這件事我幾乎每週都在做。 但病歷不能就這樣貼上去。 這跟「我信不信任那家 AI 公司」是兩回事。資料一旦離開這台電腦，它去了哪裡、留多久、被誰看過，就不再是我能決定的事。所以我想要的不是一個更好的承諾，是一個機械上的動作：在資料離開之前，先把身分拿掉。 我把自己在用的那套整理乾淨、開源了，叫 chart-scrub。 程式碼：github.com/drpwchen/chart-scrub 線上試用：drpwchen.github.io/chart-scrub（整頁在你的瀏覽器裡跑，什麼都不會上傳） 它做什麼 一筆門診紀錄丟進去： 病歷號碼：1234567 姓名：王大明 出生：1971/03/05 主訴：右肩痛三個月，夜間痛醒。王大明表示上個月在李阿嬤介紹的推拿館推過。 電話 0912-345-678，住新北市板橋區文化路一段100號5樓。 出來變成： [代號 PT-0001，55歲] 病歷號碼：PT-0001 姓名：PT-0001 出生：[55歲] 主訴：右肩痛三個月，夜間痛醒。PT-0001表示上個月在[稱謂]介紹的推拿館推過。 電話 [電話]，住[地址]。 臨床內容一個字沒動，身分不見了。 為什麼不是直接遮成「[姓名]」就好 這是整件事我最先想通的地方。 如果只是把名字換成 [姓名]，那同一個病人下次回診、下下次回診，三筆紀錄之間就沒有任何東西把他們串起來了。可是「這個人三個月前打過針、當時有效、這次又痛回來」，這種前後對照本來就是臨床判斷的一部分，弄丟了，剩下的資料就沒什麼討論價值。 所以第一層做的是定向抽換：這個人變成 PT-0001，下次回診他還是 PT-0001。代號對回真名的那張表，只存在我自己電腦上的一個 SQLite 檔，不進雲端、不進筆記庫、也不會給任何 AI 讀。 生日也一樣：直接刪掉可惜，換算成年齡剛好。臨床要的是「55 歲」，不是那個日期。 第二層：一張寧可多遮的網子 定向抽換只能處理「我知道他是誰」的那個人。紀錄裡還會有一堆我事先不知道的東西：電話、身分證、地址、順口提到的其他人。 第二層就是一組正規表示式規則，把這些東西通通遮掉。設計取向很單純：寧可多遮。偶爾誤遮一個醫學名詞，代價是我重看一次；漏掉一個名字，代價大得多。 有一個順序上的細節，是實作時才想清楚的：定向抽換一定要在通用規則之前跑。反過來的話，名字已經先被遮成 [姓名] 了，代號就再也接不上去，跨次就診的那條線也就斷了。 機器自己驗自己 寫完之後我最不放心的是：它到底有沒有真的遮乾淨？ 所以最後一步是殘留檢查：程式跑完，拿它自己知道的每一個真名、每一個病歷號，回頭搜自己剛產出的那份輸出。只要有一個活著，這筆就判定失敗、離開碼給 2，我不會拿去用。 另外還有兩個訊號是抓「漏網」的形狀：一個中文姓名黏在已經被遮掉的身分證旁邊、以及長得像身分證卻沒被遮的字串。這兩種都不是「我知道他叫什麼」，而是「這個位置本來就該有東西被處理掉」。 這件事的通則 自動化最怕的不是失敗，是安靜地成功。所以每一段自動化的最後，都值得補一個「回頭檢查自己」的動作，而且要讓它有辦法大聲喊失敗。 開源的過程中，抓到自己三個 bug 這部分我覺得比工具本身有意思。為了公開，我補了測試、逐條檢查，結果揪出三個原本在用的版本就有的問題，而且三個都是那種不會報錯的失敗。 第一個：我習慣的手寫格式是「身分證號＋姓名」擠在同一行。但實際的紀錄常常長這樣： 陪同者 A123456789 李小華 程式抓到的姓名是 「陪同者」，不是李小華。因為規則寫成「身分證號旁邊的 2 到 4 個中文字」，而「陪同者」剛好也是三個中文字，還排在前面。結果就是：一個角色詞被登記成病人，真正的名字反而漏掉。修法是要求姓名的第一個字必須是常見姓氏。 第二個：醫院系統匯出的文字檔編碼很雜，UTF-8、UTF-16、Big5 都遇過，所以程式會一個一個試。問題是一個 Big5 檔用 UTF-16 去解，不會出錯，會解出一堆亂碼。而亂碼不會命中任何一條規則，所以程式一路跑到底、印出「全數通過」，實際上它什麼都沒遮到。修法是：只有在檔案真的帶著 UTF-16 的標記時才用 UTF-16 去解。 ...

前幾天一個剛開始用 AI 寫程式的學妹問我一個很好的問題：她讓 AI 直接開她的瀏覽器做事，可是密碼都存在瀏覽器裡，這樣到底安不安全？ 我覺得這個問題值得拆成兩層來看，因為大家常常把它們混在一起擔心。認真查完之後，我把答案做成了一個開源工具，文末會介紹。 第一層：密碼存在哪裡 這層其實好解決。不管你是用 Apple 鑰匙圈還是 Bitwarden，只要是專門的密碼管理器，加上重要帳號都開了兩階段驗證（2FA），密碼本身就是安全的。別把密碼記在記事本、別用同一組打天下，這層就過關了。 順帶一提，如果你是把密碼存在 Chrome、靠 Google 帳號同步，要小心：只要有人能登入你的電腦帳號，就能把你存的密碼全部看光，這其實滿危險的。學妹用的是鑰匙圈，這層沒問題。 第二層才是重點：你讓 AI「控制」了你的瀏覽器 這代表它是用你已經登入的身分在操作。你的網銀、你的信箱、你的券商，對它來說都是開著的門。 我用的那套是 Kimi WebBridge。工具本身通常是乾淨的，我實際查過它的控制端：daemon 只綁在本機 127.0.0.1，區網或外網的其他機器連不到；沒有任何對外連線，不會把資料往外送；帶惡意來源的網頁想從瀏覽器裡偷呼叫它，會被擋掉。這部分可以放心。 真正的風險是另一件事，叫 prompt injection：AI 拿著你的登入身分，萬一去讀到一個藏了壞指令的網頁，有可能被牽著鼻子走。它不是被駭，它是太聽話。而它手上握著你所有登入中的網站。 平心而論，這類 AI（像 Claude）本身對 prompt injection 是相當警覺的，最近甚至容易反過來疑神疑鬼、動不動覺得自己被下指令了。但與其把要害帳號的安全全押在它每次都判斷正確，不如多加一道機械上的鎖：把最要命的幾個網站（網銀、券商、Gmail）直接擋在 AI 碰不到的地方，讓它就算被騙也走不進去，其他日常網站照常幫我做事。 直覺的做法沒有用：網站存取權白名單 瀏覽器的擴充套件設定裡有一個「網站存取權」，可以把擴充限制成「只能在特定網站」運作。直覺上把它設好就安全了。 實測結果：攔不住。設好白名單之後，叫 AI 開一個清單外的網站，它照樣進得去、讀得到內容、跑得了 JavaScript。 原因在技術層：這類 AI 瀏覽器控制工具走的是瀏覽器的偵錯介面（chrome.debugger API）在驅動頁面，而「網站存取權」那層設定只管一般的內容注入，管不到偵錯介面。所以那個設定頁面會讓你以為有圍籬，實際上這類工具根本不從那道門走。 順帶說明一下，不是每套工具都這樣：像 Claude in Chrome 是逐個網站問你同意的設計。但只要擴充的權限清單裡有 debugger（WebBridge 這類全站授權的工具就是），逐站白名單就是裝飾品。 真正有效的那道鎖：瀏覽器政策層 往下挖一層，答案在企業環境常用的瀏覽器政策（policy）：ExtensionSettings 裡的 runtime_blocked_hosts，可以對指定的擴充封鎖指定的網站。 這道是真的擋得住的。我把自己的網銀、券商、Gmail 一共 13 個登入網址設進去實測：AI 一碰被封的網站就直接吃到 Cannot attach to this target，連頁面都讀不到；沒被封的網站則完全不受影響，日常那些自動化照常跑。兩個方向都要測，這道鎖才算數。 兩個實作上的細節： 只封精確的網址，不用 *.整個網域 這種萬用字元。 封 *.esunbank.com.tw 會連信用卡活動頁一起封掉，而信用卡活動頁、線上表單這類，往往正是你想留給 AI 幫忙的地方。要封的是「登入後能動錢的那個網址」，不是整家銀行。 macOS 有一個陷阱：defaults write 寫進去的政策沒有用，而且是無聲失敗。 實測它在 chrome://policy 會顯示「有效」，但等級只是「建議採用」，AI 照樣進得去；政策要放在 /Library/Managed Preferences 底下、等級顯示「強制」，才真的擋得住。驗證標準要看等級，不是看政策有沒有出現。 做成開源工具：kimi-webbridge-lockdown 這個設定要手動改登錄檔（Windows）或系統政策檔（macOS），有點門檻。所以我把它做成了一鍵設定的工具，開源出來： ...

先說結論 我們自己的做法是：月薪 5 萬的人，借 100 萬、10 年期、利率 2.5%，一次全部投入，配置抓 80:20 股債比，其中 0050 佔總資產一成，其餘是全球股債 ETF。假設是這樣抓的：這個配置的歷史序列（1997 年起、含亞洲金融風暴與網路泡沫，後面方法段會講）實質年化報酬是 5.72%，我們抓 6%，比歷史略高一點；通膨歷史平均 1.4%，我們抓 3%。這兩個假設各自把勝率往哪邊推，文章後面會誠實拆開來給你看。評估年限跟貸款年限一樣，10 年。 用真實市場資料模擬兩萬條路徑，結果是： 89.6% 的路徑，最後贏過「不借錢、把同樣月付金拿去定期定額」 中位數淨賺 83 萬，最好的 5% 淨賺 241 萬，最差的 5% 是倒賠 7 萬 而最值得看的是這個：就算落到最差的 5%，也只比定期定額少 10 萬；而最好的 5% 是多 145 萬 下檔輸的幅度很小，上檔贏的幅度很大——這才是這件事真正的樣子，不是「勝率九成」四個字。 先講清楚這個 89.6% 該怎麼讀 它是兩萬條隨機路徑跑出來的估計值，本身帶有抽樣誤差：二項標準誤約 ±0.2 個百分點，95% 區間大約是 89.2% 到 90.0%。換一組亂數種子，小數點後那一位就會跳動。所以請把它讀成「約九成」，不要讀成精確到 0.1%。這篇文章後面所有的數字都適用同一句話。 以下先把完整的報告講完（我們的條件、結果全貌、方法與前提、誰不該做），最後再講這題我是怎麼用 AI 算了三遍、又怎麼發現 AI 算錯的。 完整報告 結果全貌：從最好到最差，一次攤開 先看這筆交易到底賺不賺。下圖的淨損益 ＝ 期末實質資產 − 你為貸款付出的實質成本，從最差的 5% 到最好的 5% 整個範圍攤開（都是換算成今天購買力的實質金額）： ...