Apr 2, 2026

去識別化對照表：如何安全地分享技術文章中的程式碼

這篇文章解釋這個部落格背後的一個關鍵機制：如何把真實專案經驗寫成公開文章，又不洩漏任何內部資訊。

🎯 前言

寫技術部落格最有價值的內容是真實經驗。但真實經驗往往綁著真實的資料庫名稱、客戶名稱、內部系統名稱。

直接發出去？不行，這是公司機密。全部改成假資料？可以，但你怎麼確保每次都改乾淨？

我的做法是建立一份去識別化對照表（Anonymization Map）——一個記錄所有「真實值 → 替換值」映射的檔案，放在 git 裡追蹤。

這個做法解決了三個問題：

一致性：同一個客戶名稱，每篇文章都用同一個替換值
可檢查：寫完文章後可以用 grep 掃描，確認沒有漏掉的真實值
AI 友善：把對照表寫進 CLAUDE.md，讓 Claude 自動使用正確的替換值

📂 對照表的結構

我的對照表是一個 Markdown 檔案（docs/CLAUDE_ANONYMIZATION_MAP.md），用表格整理所有替換規則：

## 資料庫相關

| 原始值 | 替換值 | 類型 |
|--------|--------|------|
| `prod_db_001` | `demo-org-1` | 資料庫名稱 |
| `prod_db_002` | `demo-org-2` | 資料庫名稱 |

## 帳號密碼

| 原始值 | 替換值 | 類型 |
|--------|--------|------|
| `admin_user` | `demo` | 測試帳號 |
| `P@ssw0rd!` | `Demo@123` | 測試密碼 |

按類別分組，每個類別一張表。我的專案中分了這些類別：

類別	包含什麼
資料庫相關	資料庫名稱、連線字串
帳號密碼	測試帳號、密碼、API key
機構/客戶名稱	客戶公司名、機構名
AWS/S3	Bucket 名稱、Profile 名稱
Issue 編號	內部 issue tracker 的編號
專案/模組名稱	專案代號、模組名稱、Session 變數
業務術語	領域專有名詞
參數名稱	API 參數、表單編號
檔案路徑	專案目錄結構

🔧 建立對照表的方法

步驟 1：盤點所有識別性資訊

從你的專案中列出所有「如果被外人看到，能辨識出這是哪家公司、哪個專案」的資訊：

✅ 要替換：
- 公司名稱、客戶名稱
- 資料庫名稱（通常包含公司簡稱）
- 帳號密碼（即使是測試用的）
- S3 bucket、AWS profile
- 內部系統名稱、專案代號
- Issue 編號（可以反推內部系統）
- 特定業務術語（可以推斷產業）

❌ 不需替換：
- 通用技術名詞（Docker、MySQL、PHP）
- 標準 port 號碼（80、3306、9000）
- 開源套件名稱
- localhost、127.0.0.1
- SQL 語法、程式碼結構

原則：替換「是誰」的資訊，保留「怎麼做」的技術細節。

步驟 2：設計替換值

替換值要符合幾個原則：

原則	好的範例	壞的範例
看起來像真的	`demo-org-1`	`xxx`
有語意	`OrganizationA`	`aaa`
不重複	每個原始值有唯一替換值	全部用 `test`
方便 grep	`AppSystem`（容易搜尋）	`app`（太常見，搜不到）

最後一點特別重要：如果替換值太常見（像 app、test、user），你沒辦法用 grep 檢查文章中是否還殘留真實值。

步驟 3：建立「保留項目」清單

明確列出不需要替換的項目，避免過度替換：

## 保留項目（技術細節，不需替換）

- Docker 相關設定
- PHP 版本 (7.4)
- MySQL 版本 (5.7)
- Port 號碼 (80, 3306, 9000, 9003)
- Composer 套件名稱
- SQL 語法範例
- Git 指令
- localhost

這個清單看起來多此一舉，但在和 AI 協作寫文章時非常重要——Claude 會知道哪些技術細節可以原封不動保留。

🤖 和 CLAUDE.md 整合

對照表的最大價值在於和 AI 協作時自動生效。

在 CLAUDE.md 中加上這段：

## 去識別化要求

**重要**：文章不得包含真實內部資訊。
所有真實名稱與數值必須依照 `docs/CLAUDE_ANONYMIZATION_MAP.md` 中的對照表進行替換。

禁止使用：
- 真實資料庫名稱
- 真實帳號密碼、客戶名稱、專案名稱

主要替換值：
- `demo-org-1`、`demo-org-2` — 資料庫名稱
- `demo` / `Demo@123` — 測試帳號密碼
- `AppSystem` — 專案名稱
- `OrganizationA`、`OrganizationB` — 客戶名稱

這樣每次 Claude 幫你寫文章時，它會自動使用對照表中的替換值，不需要你每次提醒。

✅ 發布前的自動檢查

對照表最實用的地方是發布前掃描。你可以寫一個簡單的腳本，檢查文章中是否殘留真實值：

#!/bin/bash
# check_anonymization.sh
# 檢查文章是否包含未去識別化的真實值

FILE=$1
ALERT=0

# 從對照表提取所有原始值
REAL_VALUES=(
  "prod_db_001"
  "prod_db_002"
  "admin_user"
  "P@ssw0rd!"
  # ... 從對照表中列出所有原始值
)

for value in "${REAL_VALUES[@]}"; do
  if grep -q "$value" "$FILE"; then
    echo "⚠️ 發現未替換的真實值: $value"
    ALERT=1
  fi
done

if [ $ALERT -eq 0 ]; then
  echo "✅ 檢查通過，未發現真實值"
fi

更進階的做法是搭配 Claude Code Hooks，在 Claude 寫完文章時自動執行檢查：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash scripts/check_anonymization.sh"
          }
        ]
      }
    ]
  }
}

📋 對照表的四個替換原則

整理成四條規則，方便記憶：

原則	說明
完全替換	所有識別性資訊，一個都不能漏
保留技術	架構、語法、配置模式原封不動
簡化範例	複雜的業務邏輯改為通用描述
保持真實	技術細節和問題描述保持真實性

第四點最重要：去識別化不是虛構。技術文章的價值在於「真的遇到這個問題、真的這樣解決」。你只是把「誰」的部分換掉，「怎麼做」的部分完全保留。

💡 維護建議

對照表要放進 git

對照表本身不包含原始值的完整上下文，單獨看只是一張映射表。放進 git 追蹤有幾個好處：

新增替換規則時有歷史記錄
多篇文章引用同一個替換值時保持一致
AI 工具可以直接讀取

新增規則的時機

每次寫新文章時，如果碰到對照表中沒有的識別性資訊，先更新對照表，再寫文章。不要想著「等一下再加」——你會忘記。

Issue 編號也要替換

這是容易忽略的一點。內部 issue 編號（例如 issue-385）看起來無害，但如果你的 issue tracker 是公開的（或未來變成公開的），別人可以透過編號找到對應的內部討論。

統一替換成 issue-001、issue-002 這種序列編號即可。

🎉 結語

去識別化對照表不是什麼高深的技術，就是一張映射表。但它解決了一個很實際的問題：讓你能安全地把真實經驗寫成公開文章。

沒有這張表，你會在「要不要分享」和「會不會洩密」之間猶豫。有了這張表，你只需要照著替換，然後用 grep 確認一次就好。

如果你也在考慮寫技術部落格，但擔心洩漏公司資訊，試試建一份你自己的對照表。一旦建好，寫文章的心理門檻會低很多。

📎 相關文章：