AI 協作下的文件去識別化：從內部版到對外版的方法論

發表於 2026-07-03 分類於 AI

內部 PRD 寄給客戶前，你確定裡面沒有殘留報價、技術債註記、內部代號嗎？靠肉眼檢查，我可以告訴你：一定會漏。

前言

做 B 端產品的 PM 都遇過這個場景：手上有一份寫得很完整的內部 PRD，裡面有技術債註記（「這段是舊架構硬接上去的，之後要重寫」）、內部估算（「大概兩天」「排進下一輪再做」），甚至同事的真心話（「這需求怪怪的」）。現在客戶要 review，你得產一份「對外版」。

以前的做法是複製一份、手動刪。結果每次都漏——不是漏掉一句報價未定（其實我也不知道為什麼報價會落到我身上，當時的身分明明是產品經理），就是漏掉一個內部 Jira 單號。後來我把整套流程規則化，交給 AI 執行，才發現去識別化這件事，值得一套方法論。

第一條紅線：不可直接編輯對外版。

兩個版本各自演化，一定會漂移——內部版改了第 5 章，對外版忘了跟；對外版臨時加了一段客戶要的說明，內部版沒有。所以規則是：每次要產對外版，都以「當下的內部版」為 source，重新套一次改寫規則產出。對外版是 build artifact，不是可編輯的文件。

把「內部才能看的東西」窮舉成分類表，每一類都有明確動作：

移除（整段刪）：技術債註記、報價與合約狀態、內部成本估算（人天／人月／工時）、sprint 與 backlog 詞彙、內部檔案路徑、內部 Jira 單號、公司內部評語。
改寫（換用語）：最後通牒式的語氣換成中性的階段描述；決策來源去個人化——不寫「某某說」，寫成依會議結論；內部的商務進度狀態換成雙方視角的說法，不暴露單邊的內部判斷。
保留（不要過度去識別化）：真正的第三方廠商名（客戶需要知道資料流經過誰）、需求編號如 FR-03（客戶 review 留言要有錨點）、資訊性的警示標記。

「保留」這區塊很容易被忽略——去識別化做過頭，文件會變得沒資訊量，客戶反而看不懂。遇到「這算內部評語還是技術描述？」的歧義，規則是先問人，不要讓 AI 自行決策。

規則表寫得再完整，純靠「套規則」還是會漏。我的實測經驗：某一版對外文件跑了 4 輪 grep 才乾淨。

所以流程最後有一道強制關卡：用 grep 掃描對外版，pattern 涵蓋所有已知的內部用語——技術債、人天數字、sprint、內部路徑、輪次標記等等。有 hit 就必須逐項處理，掃到乾淨為止。

更重要的是回饋迴圈：這份 grep 清單不是窮舉，是 baseline。如果人工 review 時又抓到新類別的殘留，就回頭把 pattern 補進規則檔和 grep 清單，下次自動 catch。規則檔是活的。

讓 AI 做改寫有一個特有風險：它會「合理化」。內部版寫「金流廠商」，AI 很可能自作聰明補成某家常見的金流公司名——但你們家接的根本不是那家。

所以有一條專門的紅線：不可憑印象腦補第三方廠商名。內部版寫什麼就是什麼，不確定就回頭問人。去識別化是「拿掉資訊」的工程，任何「補上資訊」的動作都是事故。

最後說個 meta 的事：你現在讀的這篇文章，本身也是跑過同一套流程才發出來的——移除、改寫、保留，最後再掃一輪殘留。

方法論能吃自己的狗糧，大概就是它成立的最好證明。如果你手上也有一份不太敢直接外寄的內部文件，歡迎聊聊你是怎麼處理的。