objectivize — 把私稿改成公開稿
你不是在跑一張敏感詞替換表。每份文稿「出戲」的方式都不一樣——先感知這一份特有的主觀洩漏型態，再讓修法與之同構。形隨功能（form follows function）。
下面的類別是火花，不是清單：缺了別硬套，多了就現場命名。把這份說明本身也當水看，別把它讀成模板。
一、先感知，後動手（不可跳過）
通讀一遍，回答三問：這份文稿寫給誰、站在誰的立場、暴露了哪些「只有圈內人才會這麼說」的東西？把洩漏點用你自己的話歸類。常見的幾束光：
- 指名道姓的圈內角色——老闆/領導/甲方/我方/對方……對外讀者不需要知道這是誰。
- 第二人稱喊話——對讀者說「你應該/你會/記住」，把讀者當隊友，是備忘錄的味道。
- 把臆測當事實——揣測某人「隱性期待/真實動機/忠誠度」，卻寫得像已知。
- 打破第四面牆——自指「本文檔/這份答卷/我們這次/錄音拆解」，暴露生產過程。
- 圈內黑話與陣營情緒——內部縮寫、站隊口吻、內部梗。
- 過程元話語——交代怎麼做出來的（用了什麼工具/開了什麼會/什麼流程）。
產物是一張本文檔專屬的洩漏地圖，不是通用規則。下一份重新畫。
二、分清「洩漏」vs「證據」（本技能的心臟）
客觀化最容易犯的錯，是把證據也抹掉、或把真實數據也改了——那不是客觀，是失真甚至造假。判據只有一條：它是被觀察到的事實，還是寫作者的口吻？事實留，口吻改。
- 直接引語 = 證據，保留（可改成中性歸因）。受訪者原話「我絕對不碰軟體」留著，它支撐論點。
- 第一人稱轉述 = 洩漏，改寫。「別給我天馬行空」是替人配音 → 「要求方案有據可循」。
- 真實數據神聖不可動——用戶評論、日誌、統計、截圖原文。哪怕數據裡正好出現了你要清理的那個詞，也絕不改：改它=篡改證據。（真實教訓：一條用戶差評裡寫了「老闆」，必須原樣留下。）
三、改寫，不是刪除
換框架，別丟內容。「老闆的真實意圖」→「專案意圖」：立場沒了，資訊還在。看到一句就想刪時，先問「它承載的判斷/事實是什麼」，把那部分用中性語態留下來。
四、定一束鏡，一以貫之
先選定一個對外視角（這份報告假裝是誰、寫給誰看？），據此給每個圈內角色定一個中性稱謂，再全篇統一。
- 別在同一份裡用三個詞指同一個人（專案方/需求方/決策方），讀者會以為是三方。順序是：先定稱謂 → 再掃替換 → 最後查一致。
- 章節的「內心戲骨架」也要換骨：把「他講了什麼 / 沒講什麼 / 為什麼這麼講」這種「複盤某人」式標題，換成「客觀分析」式（已明確的決策 / 盲區與未決 / 深層動機與約束）。讓結構同構於分析對象，而不是同構於那場會。
五、客觀 ≠ 虛假自信
去主觀不等於把「置信度/局限/存疑/推斷層/需實測驗證」也抹平。這些誠實標註恰恰是客觀的標誌，保留。
六、規模化的紀律（處理一整套文稿時）
- 術語統一可腳本化，但字典每次現建——先感知出本批的稱謂集合，再寫本批替換；不要複用上個專案的表。
- 機械替換後必查副作用——長詞先於短詞替換，否則造出「被已被」「需求方需求方」這類病句；掃完 grep 一遍殘留與畸形。
- 框架、語態、第二人稱這類只能人工逐句，腳本碰不了。
- 下游產物要重建——源改了，渲染出的 HTML/PDF/索引/封面也要重新生成，別只改源。
自檢：把成品想像成被陌生人在公開平台讀到
- 還有沒有「你/我們/對方/老闆」這類把讀者或圈內人拉進來的詞（引語除外）？
- 有沒有把猜測寫成事實？有沒有暴露「這是怎麼做出來的」？
- 同一角色是否全篇一個稱謂？
- 真實數據與直接引語是否一字未動？
- 置信度與局限是否還在？
任一條沒過，回第一步——但記住：每份文稿的過法都不同，別把這張自檢表也變成新的模板。