先固定一份不含顧客資料的純文字範本，讓交接雙方對各自取得的文字計算 SHA-256，再核對完整結果。這能協助檢查貼入文字是否一致，但不能證明內容正確、來源可信或已經核准。
先約定這次核對哪些文字
把範本的起點、終點與佔位文字一起固定，才有可比較的基準。不要一方複製整張工單，另一方只複製回覆段落，最後把不同結果當成系統出錯。
例如客服要把「退款申請已受理」範本搬進知識庫，工單畫面還有客戶姓名、訂單號與處理人員簽名。先整理出專供交接的版本，將個案資料改成「〔訂單編號〕」等固定佔位文字，並約定從稱呼到結尾都包含在內。版號與核准日期可以另記在交接紀錄，不要每次複製時才決定是否加入。
這份底稿要另外保存。雜湊值是一串核對用的結果，不能代替原文；只留下結果，日後仍無從知道當時到底交了哪一份範本。
兩邊各自產生 SHA-256，別只轉貼同一串數字
交付者先對底稿計算，接收者再從知識庫取回文字自行計算。接收者若只把交付者傳來的雜湊值貼進紀錄，便沒有檢查搬移後的內容。
開啟 Hash 計算（MD5/SHA），把約定的純文字貼進輸入框；結果會隨輸入更新，不需要找「產生」按鈕。停止修改並等結果出現後，複製 SHA-256 那一列的完整值，連同範本版號記下來。頁面同時顯示其他演算法，核對時兩邊必須選相同一列。
目前工具會把輸入文字編碼後計算，沒有讀取檔案的按鈕。這與 W3C Web Cryptography 規格所區分的摘要運算相符：摘要用來得到資料的雜湊結果，不是簽章或內容審核。不要把 DOCX 檔名貼進來，再把結果說成該檔案的 SHA-256。
結果不同時，先找差異再決定是否接受
不同結果表示這次輸入的基準需要重新核對，不必立刻認定有人改壞內容。先保留雙方原樣取得的文字，檢查有沒有多貼標題、漏掉結尾、混入空白行或換了標點。
例如原文是「請於三個工作天內回覆」，搬移後成了「請於 3 個工作天內回覆」。意思可能接近，但字串已不同；是否允許這個改寫，要由範本負責人決定。行尾多一個空白、半形括號改成全形，也可能使核對失敗。
把兩份短文字放進文字差異比對，先按行找段落，再用字元模式檢查局部。不要為了讓數值一樣就先刪光空白，因為那可能掩蓋範本本來要求保留的格式。若決定統一換行或空白，應寫成共同規則，兩份都依同一規則處理，再產生新的基準。
把核對結果放回交接流程
交接紀錄至少保留範本版號、原文位置、複製範圍、演算法與雙方核對結果。完成後再從實際知識庫複製一次，確認比的是最後儲存的版本，而非編輯器裡尚未保存的草稿。
- 由內容負責人確認期限、聯絡方式與服務承諾是否仍適用。
- 由接收者查看知識庫的段落、連結與佔位文字，避免純文字相同卻漏掉操作連結。
- 若有修改，更新底稿與版號，再重做核對，不沿用舊值。
不要放入真實顧客資料來示範。個資遮蔽工具可協助處理部分格式，但輸出仍要人工確認；直接使用虛構範例通常更容易控管。雜湊工具也不提供範本保存或核准紀錄，這些資料要留在團隊既有的文件管理位置。
常見問題
兩邊 SHA-256 相同，就代表範本可以寄出了嗎？
不代表。相同結果可作為這次文字核對的依據，卻不會判斷退款期限、政策內容或主管授權。寄出前仍要完成內容審核。
能用這個頁面核對整份 PDF 或 Word 檔嗎？
不能。它計算貼入的文字，不讀取 PDF、DOCX 的檔案位元組。從文件複製出來的文字，也不包含完整排版與附件資訊。
空白輸入為什麼只顯示橫線？
目前頁面對空白輸入顯示「—」，不提供空字串的計算結果。先確認範本文字確實貼入，別把橫線記成雜湊值。
只核對開頭幾碼可以嗎？
交接時應保留並比較完整 SHA-256，不要只看開頭或截圖裡顯示的一小段。複製後也要檢查是否帶入其他演算法的值。
改了範本裡的連結文字，需要重算嗎？
只要核對範圍的文字有改動，就建立新結果；若只改連結背後的網址而顯示文字未變，純文字核對可能看不出來，所以連結目的地必須另行檢查。