昨天最後留了一個問題：你昨天貼給 AI 的那段錯誤訊息裡面有什麼，你說得出來嗎？

我第一次被問到的時候答不出來。不是記性差，是我從來沒把「這段裡面有什麼」當成一個要回答的問題。它就是一段錯誤訊息，我複製貼上等它回答。

今天要處理的就是這個「答不出來」。

不過先說清楚能回答到哪裡。「它知道多少」這個問法把四件事混在一起了：資料送出去給服務、留在對話紀錄與系統日誌裡、被安全審查或人工看過、被拿去訓練下一版模型。四件事的答案不一樣，而且只有最後一件有開關可以關。

這篇不會告訴你模型現在記得什麼，那件事你從外面查不到。 能做的是重建你至少送出過哪些東西。它給不了總數，但可以把「不知道」換成一個查得到的下限。

為什麼答不出來

寄信、上傳附件、插隨身碟，這些動作在心裡通常會被記成同一類：你知道自己剛剛送出了東西。貼給 AI 沒有這個共同點，你不是在送東西，你是在問問題。沒有收件人、沒有附件、沒有一個叫「送出到外部」的按鈕。

所以那件事在你的記憶裡不是「傳輸」，是「查資料」。沒有被記成傳輸的東西，事後就不容易想起來。

還有更難記的一種。你在編輯器裡問「這個函式為什麼會 undefined」，它自己抓了幾個相關檔案當 context 一起送出去。有些工具會列出它附帶了哪些檔案，有些不會，而你幾乎不會逐個去看，更不會逐個勾選。

那不只沒有傳輸的感覺，連「你做過什麼」都沒有。你唯一的動作是打了一句問題。

這件事的量

Cyberhaven 2026 年 2 月的報告說，送進 AI 工具的互動裡有 39.7% 帶著敏感資料，平均下來每個員工每三天送出一次。

這個數字要連著它的來源看：Cyberhaven 做的是資料外洩防護，母體是裝了它產品的那些公司，「敏感」的判準也是各家自己設的。所以它能說的是「在有人盯著的地方，這件事照樣一直發生」，不是「你有 39.7% 的機率」。

另一份上個月的調查問了 500 位美國在職者（律師事務所委託、Pollfish 執行，誤差約正負 4.4%），38% 承認把工作上的東西放進過自己的個人帳號。原文的說法是「雇主控制不到的帳號」，那才是重點：不是沒有紀錄，服務商那邊當然有，是你公司查不到也管不到。

先翻出來，這一步就是今天的答案

要回答「它知道多少」，成本最低的做法是去看。（公司如果有那種會側錄對外流量的資安系統，那邊查得更全，但那不是你自己開得了的東西。）

打開你最近用的那個 AI 工具，把最近十次對話翻出來，一則一則讀。不用回想，讀就好。

昨天也記過一行類似的東西，但軸不一樣：昨天是一把鑰匙一行，為的是處置；今天是一則對話一行，為的是重建範圍。 昨天問「這把鑰匙進過 AI 嗎」，今天問「那一則裡面還有什麼別的」。

一邊讀一邊記，記成一張表。 一則一行，日期、貼了什麼、裡面有什麼、處理到哪：

7/28  貼了整份 docker-compose.yml  → DB 密碼、兩個內部服務位置  8/03 撤銷、打舊鑰確認失效、用量查過
7/30  貼了一段錯誤訊息              → 同一組連線字串             併進上面那次處置，紀錄無異常
8/01  貼了 utils.ts 三十行          → 沒有敏感的                 不用處理

這張表就是你拿得到的那部分答案。 等一下要寫的清單是另一回事，那是往後每天都會用到的東西，而它要從這張表長出來。兩樣都要，但先後有意義：先看清楚已經發生什麼，再決定以後怎麼辦。

第三欄要找的是四種：

拿不準就標上去，寧可標多。

翻到一把還在用的金鑰就停下來，先去撤銷。 不要記進表裡然後繼續往下讀。那不是今天的題目，是昨天那題：先到供應商後台換掉、確認舊的真的失效，再回來繼續盤點。手上的東西牽涉到客戶資料、或公司有通報規定的，那條流程先走完。盤點的意義是看見全貌，但看見一把還活著的鑰匙還往下讀，等於把已經確認的外洩擱在那裡。

第三欄寫「裡面有 DB 密碼」就夠了，不要把密碼本身抄進去。你需要的是知道哪一則出過什麼類型的東西，不是重新謄一份。抄進去的話這張表自己就成了新的暴露點，而且前天講過，寫進 .gitignore 只是不讓 git 追蹤，AI 工具、雲端同步、其他程式照樣讀得到。

即使只寫類別，它還是比等一下那份清單敏感：清單講的是「這種檔案不能貼」，這張表講的是「我哪一天真的貼了什麼」。開在專案目錄外面，別讓 git 跟 AI 工具看到。

最後一欄不要省，而且沿用昨天那個標準：撤銷、拿舊鑰打一次確認真的失效、查過用量，三件都做完才寫得上去。「已經換了新的」不算，昨天整篇都在講這件事。有了這一欄，這張表從一次性的盤點變成處置紀錄，哪幾條做完了、哪幾條還晾著，一眼看得到。

有件事要先講清楚：這張表一定不完整。 有些工具的搜尋做得不好，有些對話你按過刪除，編輯器自動帶出去的那些根本沒有紀錄可翻。所以它的正確讀法是「我至少送出過這些」，不是「我只送出過這些」。

我第一次做，翻到第七則就停了。有一則是我把整份 docker-compose.yml 貼上去問「這個 healthcheck 為什麼一直失敗」。那份檔案裡有資料庫密碼，還有兩個內部服務的位置。

我當時完全沒有意識到我在送那些東西。我的注意力全在 healthcheck 那七行上。

你的東西有三條路出去

那張表記的是第一條路，也是最容易從對話紀錄重建的那條。

第一條最好重建，因為聊天紀錄裡就有。第二條跟第三條要看產品：有的會留下附帶檔案或工具呼叫的紀錄，有的不會，而且就算留了，也未必記得下實際送出去的內容。

今天要走完的是第一條，順便處理第二條的一部分。第三條要等 Day 8 盤點 agent 權限。綠色的意思是「今天有動作可做」，不是「今天守住了」，每條後面都跟著它的限度。

「以後小心一點」為什麼沒用

翻完會嚇一跳，然後大部分人的結論是下次注意。

這個結論沒用，但原因不是你不夠自律。

回去看我那則 docker-compose.yml。就算當時有人在我旁邊喊「小心一點」，我也不會停手，因為我根本不覺得那份檔案敏感。它在我腦子裡的標籤是「服務設定」，不是「密碼所在地」。

「不要貼密碼」這種通用守則救不了這種情況。它假設你認得出密碼，而問題正好是你認不出來：你看到的是一份 YAML，不是一串密碼。

所以缺的不是提醒，是一份「這個專案裡什麼算敏感」的定義。我待過的專案沒有一個寫過這種東西，包括我自己開的。

把那張表倒過來，就是清單

這裡是今天最省力的一步，而且它解掉一個先有雞還是先有蛋的問題。

要寫「這個專案什麼算敏感」，聽起來得先把整個專案摸熟。不用。你剛才那張表的第三欄，就是第一批答案。 你貼過 docker-compose.yml 而它裡面有密碼，那 docker-compose.yml 就是第一條。你不是在猜什麼可能敏感，你是在記錄什麼已經出過事。

第二批答案你前天就做好了。Day 2 那份候選清單，一個檔名配一句「這裡有什麼」，那天結尾我說留著別丟，就是為了今天。

兩份的方向剛好相反，所以要一起用。今天這張表是回想出來的，只涵蓋你翻得到的那幾次；Day 2 那份是 grep 掃出來的，不靠記憶，但它只知道哪裡有祕密，不知道那些東西有沒有真的被你送出去過。掃出來的補回想的洞，回想的告訴你哪幾條已經燒過一次。

所以第一段的來源有兩個：Day 2 清單上的每一條，加上今天表格第三欄裡它沒抓到的那些（人名、內部網址、客戶資料，那些不長得像祕密，grep 抓不到）。Day 2 那天說過「候選這兩個字是認真的」，現在就是那個判斷要落地的時候：清單上哪幾條真的不能貼，只有你答得出來。

在專案根目錄開一個 AI-SHARING.md，把表格第三欄的東西整理成三段：

# 這個專案什麼算敏感

## 不可貼
- .env 開頭的任何檔案
- docker-compose.yml
- config/secrets.*
- fixtures/ 底下全部

## 貼之前要替換
- *.internal.example.com  ->  service.example
- 真實客戶名                ->  Acme
- 同事姓名                  ->  角色（PM、後端）

## 需要看內容才知道
- src/ 底下的檔案。多數可以貼，但寫死的金鑰與內部網址會混在裡面
- 測試檔。fixtures/ 以外的通常沒問題，除非它連了真實環境

這是我的專案，你的一定長得不一樣。三個地方順手解釋一下，免得你照抄：

.env* 記得涵蓋 .envrc，direnv 那個檔案裡常常也有金鑰。

fixtures/ 值得多看一眼。它危險的原因不是名字，是那裡面常常不是編出來的假資料，而是從正式環境撈出來、把名字換掉的真東西。你的專案有沒有這個習慣，打開看一下就知道。你的專案可能叫 testdata/ 或 seeds/，換成你的。

第三段的名字別改成「可以直接貼」，那等於發一張通行證。src/ 底下藏得住寫死的金鑰，一句「可以直接貼」會讓你連看都不看。

指得出具體對象的才進前兩段，不管那是檔名還是字串；要打開來看才知道的，老實寫進第三段。這份清單的價值來自它的準確，不是它的乾脆。

第一版只寫得出三四行也沒關係。它會隨著你下次又翻到什麼而長大，今天的目標是讓它從零變成有。

這份清單自己也是敏感資料

有一個地方我是刻意的，你可能會想「補一下」：每一條都沒有寫理由。

我第一版寫的是這樣：

- docker-compose.yml（裡面有 DB 密碼與內部服務位置）
- fixtures/（從正式環境撈出來、把名字換掉的客戶資料）

看起來比較負責，實際上我剛剛親手畫了一張地圖：哪個檔案裡有密碼、客戶資料放在哪。

這份清單一寫完，它自己就變成清單第一段管的那種東西了。

所以這裡分成兩份東西，各住各的：

• AI-SHARING.md：只有規則，檔名、萬用字元、要替換成什麼。沒有理由、沒有「這裡面有什麼」。這份給人看也給你自己抄進各種設定。
• 專案外那份筆記：剛才那張盤點表就是它的開頭。理由、受影響的系統、處置狀態都寫在這裡。

「理由記在腦子裡」聽起來乾淨，但你三個月後就想不起來某一條為什麼在上面，團隊裡的其他人更是從第一天就不知道。理由要寫，只是不寫在會跟著專案跑的那份裡。

那要不要 commit？看這個 repo 誰讀得到，兩種情況分開處理。

私有 repo、只有授權過的人進得來：可以放。規則本來就要團隊一起遵守，CI 的掃描設定也要有個來源。放之前自己讀一遍，確認裡面只有規則，沒有夾帶實際的祕密。

公開 repo，或連路徑都不想被看到：不要放。一進版控它就跟著 clone、fork、CI 跑，歷史裡也刪不掉，而檔名自己就會洩漏東西：客戶代號、未公開的產品名、環境名稱，全在路徑裡。這種情況把完整規則留在專案外，CI 那邊另外寫一份不含敏感路徑的設定。

拿不定主意就先不放，它不進版控一樣有用。

讓 AI 幫你補漏，但不要餵它你的專案

清單寫完你會覺得漏了什麼。確實會漏，因為你只列得出你翻到過的。

這一步適合交給 AI。但別把你的清單或你的檔案列表貼給它，那等於把「祕密住在哪」的索引送出去，正好是這一節在防的事。

改成問通用的問題：

一個 Node.js + Express + Postgres 的專案，通常有哪些檔案或目錄會放憑證、內部網址、或沒有換掉真名的客戶資料？請按可能性排序，並說明每一個通常裝什麼。

把技術棧換成你的。這句話裡沒有一個字是你的專案獨有的，它問的是這類專案的通例，而通例它列得比你快。列出來的是候選，排序跟取捨還是你的事。

拿到它列的那幾個位置，自己回去對照：這些位置我的專案有沒有？裡面裝的是不是它說的那種東西？有的就加進清單第一段。

判斷留在你這邊，理由是「這個內網網址到底算不算敏感」的答案不在程式碼裡，在你的組織脈絡裡。admin.example.com 可能是公開的後台登入頁，也可能是一個不該被知道存在的東西，模型看不到那個差別，但它會給你一個聽起來很篤定的答案。

順帶對照一下 Day 2，那天的分工正好相反：找的部分交給 grep，判斷交給 AI。因為那天要判斷的是「這個字串是不是祕密」，答案就在檔案裡，AI 讀得到。今天要判斷的是「這個東西對我的公司算不算敏感」，那份脈絡它拿不到。

脈絡在哪裡，判斷就在哪裡。 這條分界會移動：換一個工具、換一種資料、換一個使用情境，就要重新問一次誰手上有足夠的脈絡做這個判斷。

用 agent 的話這一步可以更省事，直接叫它掃專案列候選。但要知道你換到了什麼：它會把翻到的路徑送進模型，而路徑本身也是資訊。省下的十分鐘跟送出去的目錄結構，自己權衡。

它能幫你什麼，不能幫你什麼

先講不能的，免得你抱著錯的期待。

它不會在你貼上的那一刻攔住你。 昨天那個 hook 掛在 git commit 上，你一 commit 它自己會跑；「貼上」沒有這種可以掛東西的位置。真要在那一刻攔下來，得裝瀏覽器擴充或公司那種監看剪貼簿的軟體，不是今天一小時做得完的。

那它怎麼用？不是拿來查的，是拿來抄的。

抄進編輯器的忽略設定（今天等一下就做）、抄進 CI 的掃描規則、抄進 code review 的檢查項。這份檔案本身不執行任何東西，是那幾個地方在執行，它只是那些設定的共同來源。

還有一個附帶的作用：你剛花半小時想過 docker-compose.yml 為什麼在上面，下次它出現在剪貼簿裡，你比較容易認出來。

想把它翻成一支命令列小程式也行，我放在 repo 的 recipe 04，順便寫了它擋不住的兩種狀況。寫得出來就代表這份清單已經具體到能變成規則，這是它真正的用途，不是要你每次貼之前跑一遍。

已經送出去的那些：有一個開關，但它只管用途

清單管的是以後。開頭那個問題問的是現在，而現在這一格能動的只有一個開關，先講它的邊界再講怎麼用：它管的是用途，不是傳輸。

ChatGPT 跟 Claude 的個人方案都有這類設定，預設值各家不同、商業方案的規則又是另一套，要自己去看一眼。位置不用我帶：ChatGPT 在設定的資料控管裡叫「為所有人改善模型」，Claude 在 Settings 的 Privacy 裡叫 Help improve our AI models。

關掉它，然後回頭看剛才那句話。

有的產品把它切得更細。Codex 除了訓練本身，連「要不要為了改善模型，多抓一點你的環境資訊」都是獨立一格：

看它在哪個標題底下：「模型改進」。所以這一格管的是那些額外抓走的東西會不會被拿去改善模型，不是 Codex 幹活的時候讀不讀得到你的檔案。工作時讀什麼是另一回事，那條路等一下講，真正的權限問題要到 Day 8。

你貼過去的東西一樣離開了你的機器、一樣存在對方的伺服器上，差別只在它會不會被拿去改進下一版模型。開關關掉的那一刻，已經送出去的還在那裡。

關掉之後還有一個例外，寫在 Anthropic 自己的說明頁上（原文，2026-08 查證）：對話被標記進安全審查的話，他們仍然可能使用或分析它，用途是偵測與執行使用政策，包含訓練給他們安全團隊用的模型（in which case we may use or analyze them to improve our ability to detect and enforce our Usage Policy, including training models for use by our Safeguards team）。用途有限定，但那是他們定義的限定，不是你關得掉的開關。

同一頁另外有一段，講的是開關開著的時候什麼算數：透過 connector 與 MCP 讀進去的原始內容不列入，直接複製貼上進對話的則可能列入。

這段只能讀到這裡為止。它說的是 Anthropic 個人方案在做模型改進時怎麼分類，不是說 connector 的內容沒有傳過去，也不能套到編輯器自動附帶的那些檔案上，那是別家產品的另一套規則，要一家一家查。

能帶走的只有一件事：在這份 Anthropic 個人方案的模型改進規則裡，你手動貼進對話的那些，是被明確點名會列入的那一類。第一條路連在這裡都沒有豁免。

再往下一層，這個開關跟等一下要做的誘餌測試有個差別，值得停一秒。

忽略檔有沒有生效，你測得出來，等一下就會做：放個誘餌、問它、看它答不答得出來。訓練開關有沒有被遵守，你沒有任何辦法測。關掉之後你看到的只有一個灰掉的圓鈕，那是對方的介面在告訴你它記下了，不是證據。你能驗證的只有自己這一端做了什麼；對方那一端做了什麼，你只能相信。

所以這一節的結論跟前面幾節都不一樣，它是今天唯一一個沒有驗證步驟的動作：該關就關，然後繼續當它沒關。 該不貼的還是不要貼，這才是那份清單存在的理由。

第二條路：工具自己讀走的那些

回到前面那張圖的第二條。清單管不到它，因為那條路上沒有你的動作可以掛，能管的是工具自己的忽略檔。

我用 Cursor，它的叫 .cursorignore（官方文件，2026-08 查證）。內容就是清單第一段抄過來：

.env*
docker-compose.yml
config/secrets.*
fixtures/

要驗它有沒有生效，不要拿真的敏感檔去問。 這是 Day 2 教過的手法：先放一個誘餌。在被忽略的目錄裡開一個假檔案，裡面寫一串你自己編的、不會撞到別的東西的字，例如 BAIT-0804-QQ。然後問 AI「專案裡有沒有出現 BAIT-0804-QQ」。

它找得到，代表規則對它沒用。找不到則什麼都不代表，可能是規則生效了，也可能只是它這次沒去翻。這個判準昨天前天都用過，方向只有一邊。

為什麼要用誘餌而不是直接拿 docker-compose.yml 問它？因為如果設定沒生效，你等於又把那份檔案送出去一次，而你正在做的事情是減少送出去的東西。

測完把誘餌檔刪掉，不要讓它跟著 commit 進去。

還有一件事別誤會：這一步不等於關上了那扇門。 Cursor 官方文件自己寫了兩個限制。第一，這個設定管得到的是編輯器的 AI 功能（補全、對話、@ 引用檔案），但 agent 如果開一個終端機視窗自己去 cat 那個檔案，就繞過去了（原文：The terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore）。第二，文件另一句更直白，說完整的保護沒辦法保證，因為模型的行為本來就沒辦法完全預測（complete protection isn't guaranteed due to LLM unpredictability）。

Day 2 講過同一件事，這是第二次遇到：忽略規則減少的是自動被帶出去的內容，它沒有拿掉終端機、MCP 與其他工具的存取路徑。

第三條那個 agent 自己開終端機的洞，正是 Day 8 要盤點的東西，今天先知道它開著。

最矛盾的地方

清單上那些「不可貼」的東西，往往正是你最想找人幫你看的：docker-compose.yml 的 healthcheck 為什麼失敗、那份 fixtures 為什麼讓測試爆掉、那段跟計價有關的商業邏輯有沒有寫錯。最難的部分，也最需要第二雙眼睛。

而你剛剛親手把它們列進了第一段。

這個矛盾今天解不掉。能做的只是讓你知道自己在放棄什麼，而不是在不知情的狀況下把它們送出去。

比較接近解答的方向是把模型搬到自己的機器上，那樣資料至少不必離開這台。不過「本機」不等於離線，旁邊那些會連外的東西要一條一條確認過才算數。這件事要到 Day 26 才會認真處理，跟今天相隔二十二天。

今天結束時你手上有什麼

兩樣東西。

一張表，放在專案外面，記著你翻出來的那幾則：什麼時候、貼了什麼、裡面有什麼類型的東西、處理了沒。這張回答的是今天開頭那個問題。它不是用完就丟的草稿，翻到的憑證換過沒有、哪幾條還晾著，都靠它記著。

一份 AI-SHARING.md，放在專案裡，從那張表的第三欄加上 Day 2 那份候選清單長出來，三段：不可貼、要替換、需要看內容才知道。只有規則，理由留在專案外那份筆記。明天挑程式碼餵給 AI 之前要用它過一遍，Day 8 盤點 MCP 與外掛工具拿得到什麼資料的時候，約束的還是同一份定義。先放本機，要不要進版控等你確認過誰讀得到那個 repo 再說。編輯器有忽略設定的話，第一段順手抄一份過去。

回到開頭那個問題：它知道多少？

誠實的答案是「我知道其中這些，但不是全部」。 已經送出去的那些，你沒辦法確認它什麼時候真的消失（昨天講過為什麼），翻不到的那些也還是翻不到。

順手關掉的訓練開關不算第三樣。它花不到一分鐘，也證明不了任何事，能留下來的還是上面那兩樣。

但下一次有人問，或者哪天真的出事要回頭追，你有東西可以翻，不是從記憶裡撈。

前面三天寫下來的是憑證在哪裡、哪一把要先撤。今天第一次把同一套判斷放大到整個專案：除了金鑰，還有人名、內部位置、還沒公開的商業規則。判斷的方法沒變，管的範圍變了。

明天

明天要挑一段最近由 AI 生成、已經合進去的程式碼，讓 AI 自己去找它寫壞的地方。

要餵給它的那些程式碼，先拿今天那份 AI-SHARING.md 過一遍。第三段「需要看內容才知道」的那些，正好是明天要逐行讀的東西。

還有一個問題留給明天：如果找漏洞的跟寫程式的是同一個模型，它找得到自己的錯嗎？

上一篇：Day 3｜第一步是讓舊鑰失效，但送進 AI 的那些收不回來

今天這支檢查腳本與它的邊界：recipe 04｜範例專案：github.com/cyh7789/ai-security