「你這系列講的都是跟 AI 協作時真的發生過的事，那應該直接把對話紀錄貼出來最有說服力吧？」
這個問題我在動筆前也問過自己。這系列從 Day 01 開始，每一篇案例都宣稱「這是真實發生過的事」——但如果打開任何一篇去看，會發現裡面沒有一句話是逐字複製貼上的對話紀錄，全部經過改寫。這聽起來像是打了自己的臉：既然都改寫了，還能叫「真實案例」嗎？
答案是可以，但前提是搞清楚「真實」這個詞在這系列裡指的是什麼——真實指的是模式跟結論忠於實際發生過的事，不是文字本身逐字忠於某一次對話。 今天這篇要講清楚這個分寸怎麼拿捏，以及為什麼要這樣做，而不是圖方便直接貼對話紀錄。
直覺上，貼出真實對話紀錄好像是最有力的證據——時間戳、原始措辭、雙方來回，看起來鐵證如山。但這個直覺忽略了三個實際的問題。
第一個問題最直接：逐字對話裡幾乎一定夾帶著不該公開的細節——可能是某個工具的內部路徑、某個專案的真實名稱、某次任務裡帶到的敏感資訊。要把這些全部挑乾淨，比重寫一個乾淨版本還累，而且很容易漏。這系列前面幾天講過的「人工複查會系統性漏掉某一類問題」，同樣的風險在「逐句審查一份對話紀錄」這件事上一樣存在，甚至更嚴重，因為對話紀錄比程式碼更容易夾帶隨口帶出的細節。
第二個問題比較容易被忽略：逐字對話裡混雜了大量跟案例核心無關的雜訊——來回確認、打字習慣、跟主題無關的插話。讀者要從這堆雜訊裡自己挖出「這個案例真正在講什麼」，體驗反而比讀一段整理過的敘事更差。一篇好的案例文章，價值不在「呈現了多少原始資料」，在「幫讀者省下了篩選原始資料的力氣」。
第三個問題最根本，也是這系列從 Day 01 就一直在講的主題句延伸：一份逐字對話紀錄的可信度，只在它實際涵蓋的那個特定情境裡成立——如果讀者的專案、工具鏈、團隊習慣跟這份對話發生的情境不一樣，逐字紀錄反而會讓讀者誤以為「照著做就好」，卻沒意識到中間有一大段脈絡是對不上的。抽象成通用案例，是把「這件事在我的情境下怎麼發生」轉譯成「這件事在什麼樣的結構下會發生」，後者才是能被搬到別的專案的東西。
用一組對照來看這個差異：
❌ 逐字複述真實對話：
「使用者說：『這個 script 抓到一個真的存在的問題』，
我回覆：『對，我立刻修正...』」
→ 讀者只看到一次性的、綁定在特定情境的互動，
不知道這個模式在自己的專案裡會用什麼樣子出現，
而且很可能夾帶了不該公開的細節卻沒被發現
✅ 抽象成通用案例：
「一支負責檢查某類規則的 script 第一次執行，
就抓到一個人工複查從未發現過的問題——
因為那類問題的樣態不符合人腦掃視時會注意的模式。」
→ 保留了「自動化檢查抓到人工複查漏洞」這個可遷移的因果結構，
讀者能直接判斷這個模式跟自己手上的專案像不像
一個案例值不值得寫進文章，關鍵不是它多具體、多像真的截圖，是它的因果結構能不能被搬到另一個完全不同的專案上還站得住腳。 如果抽象掉所有識別資訊之後，這個案例的道理就垮了，那代表它本來就不是一個真正可遷移的教訓，只是一次巧合。
實務上，寫一篇案例文章前，可以問自己幾個問題：
這個案例的「誰」重要嗎？ 如果案例的說服力來自「這是某個具體人物/專案做的判斷」，那這個案例本身就有問題——技術教訓的說服力該來自邏輯本身站不站得住，不該來自「這是誰說的」。把「誰」換成泛稱，如果道理還成立，代表原本就抽對了層次。
這個案例的具體數字/名稱重要嗎？ 大部分情況下不重要，重要的是相對關係（例如「規則變多之後，某條舊規則被套用的頻率下降」比「規則從 12 條變成 340 條」這種精確數字更值得留下——後者容易變成一個讓讀者誤以為「門檻是 340 條」的假標準）。
拿掉所有識別資訊之後，讀者還能不能理解「為什麼會這樣」？ 這是最後一道檢查——如果答案是不能，代表改寫過程把因果關係本身也一起洗掉了，不是單純去識別化，是把案例寫壞了，需要重新想一個更本質的敘事方式，而不是硬把識別資訊塞回去。
回想你上一次想拿一個真實案例來說服別人：你當時提供的是原始截圖/紀錄，還是整理過的敘事？如果拿掉所有時間、地點、人名，這個案例講的道理還站得住嗎？
明天要誠實面對這套方法論的邊界：Skill、CLAUDE.md、Memory 這一整套機制，解決不了哪些問題。
iThome鐵人賽
看影片追技術