營運與維護 · 實作指南
看起來相同的客戶名，為什麼比對失敗？
用字元正規化處理姓名表示差異，同時保留原文、客戶編號與人工合併邊界。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 香港粵語逐字稿 · 澳門粵語逐字稿
案例備忘：同名，不一定同碼
設想一家美國餐飲配送公司的客戶匯入：網頁表單中的 José 與舊系統匯出的 José 看起來相同，精確比對卻失敗，AI 因而建議建立新客戶。這是虛構情景。先別讓模型改拼寫；請開發者檢查字元表示，問題可能來自一個帶重音字元與“字母加組合重音”的不同編碼。
依已核准文章重繪的解說示意圖。
拆開看，再決定怎麼比
同一個 é 可以寫成 U+00E9，也可以寫成 U+0065 加 U+0301。兩串原始值不相等；把雙方轉換為 NFC 後，這對表示可以相等。Unicode 定義了這種規範等價，JavaScript 的 normalize("NFC") 可用於轉換。[S1][S2] 這不是把所有看起來像的文字都變成同一個名字。
依已核准文章重繪的解說示意圖。
一條紀錄，保留三個位置
建議把原始姓名、用於比較的鍵、穩定客戶編號分開儲存。原文用於展示與核對；比較鍵由明確規則生成；編號負責關聯訂單。兩邊都按同一規則生成鍵，不要只處理新表單。比對結果只是一條候選線索，不能據此覆蓋客戶原名，也不能把兩個同名客戶自動合併。若多個編號落入同一個比較鍵，輸出碰撞清單，而不是選第一條。原文保留也方便負責人撤銷錯誤規則並重新計算鍵。
依已核准文章重繪的解說示意圖。
規則選擇卡：NFC 還是 NFKC？
對本文這類規範等價差異，可評估 NFC。NFKC 還會摺疊某些相容差異，例如圈號數字與普通數字；它不是“更強所以更好”。Unicode 明確提醒，不應對任意文字盲用相容正規化。[S1] 產品編號、契約原文和姓名欄位應分別約定，不能共用一個萬能清洗開關。
依已核准文章重繪的解說示意圖。
這條線必須留著
正規化不是去重音、轉小寫、翻譯，也不是身份驗證。視覺相似的字元仍可能不同；W3C 的字串比對工作草案也說明了這一侷限。[S3] 如果團隊另加忽略大小寫或重音的搜尋規則，應單獨說明，並展示多個候選，不要把寬鬆搜尋直接變成寫入或合併權限。
依已核准文章重繪的解說示意圖。
桌面演練：應相等，也應不相等
上線前準備三組測試：預組合與組合重音形式應按所選 NFC 規則判定為相符；Jose 與 José 不應僅因 NFC 就相等；兩個姓名完全相同但客戶編號不同的紀錄仍須保留。再檢查匯入、檢索與回寫的原文是否保真。這是建議的驗收計劃，不代表已在你的系統執行。
依已核准文章重繪的解說示意圖。
交給負責人的是決定，不是清洗按鈕
讓業務負責人核准每個欄位的比較規則，再由開發者紀錄規則版本、保留原文並列出碰撞候選。試執行先只輸出建議：找到哪個編號、依據是什麼、哪些情況無法確定。驗收重點不是“重複減少了多少”，而是該找到的能找到，不該合併的沒有被誤合併。
依已核准文章重繪的解說示意圖。