論述基礎與限制

本卡從一篇早期文章的整篇改寫抽出。該篇開頭寫「曾經有一段時間，我們團隊對 TDD 又愛又恨……這種矛盾讓我們反覆懷疑」、結尾寫「我們曾以為 TDD 很痛苦」——由使用者指出這段完全是虛構的：文章由 AI 生成，所謂的「我們團隊」不存在。同一篇還有第二種形態：「Kent Beck 在《Test Driven Development: By Example》第一頁就寫道」加一段引文——對來源驗證後，那個主張實際出自 Kent Beck 與 Kelly Sutton 的 Test Desiderata、是 behavioral 與 structure-insensitive 兩條獨立性質，引文字面與出處位置都不是真的。

全站掃第一人稱經驗宣稱（我們團隊／我們的團隊／我們公司／我們曾／我當時）命中 10 檔，集中在同一時期的早期方法論文章。用版本歷史往回追這批的來源，得到的是一個 commit：「批次優化 31 篇方法論文章品質」——被改寫的那篇是其中一篇，而關鍵字只命中同批的 6 篇。逐篇讀開場之後，虛構在多數篇裡以第三人稱角色出現：「PM 無法判斷能不能關掉」「Reviewer 不知道該查什麼」「我們派了一位開發者去查」「開發者剛花了三天卻要整個打掉，士氣很難不崩」——這些不含第一人稱關鍵字，第一人稱的 grep 一個都掃不到。

這批 31 篇後續逐篇改寫完畢，過程驗證了修法 5 的另一半：具名錨點與情節要分開驗。同一個專案裡，library_domain.dart 與「工作日誌膨脹到 6000 行」在專案的 CHANGELOG 與 work-log 裡查得到，而「35 個以上的檔案、24 個編譯錯誤降到零」「LSP 約 50ms、grep 約 45 秒」「71 個測試 100% 通過」查不到——同一段敘事裡真實錨點與生成數字並存，逐項查證才分得開。

限制：兩種形態的逐字實例都來自單一篇；「形態需求生成虛構」的機制陳述由輸出特徵反推，沒有生成過程的直接證據。批次裡哪些事件真實、哪些角色不存在，要由知道當時工作狀態的人逐篇判定，本卡只給判定的方法與掃描的邊界。

核心原則

經驗宣稱是證據宣稱，出處宣稱是可回溯性宣稱——兩者都是論證的承重件，虛構它們是造假，不是修辭選擇。 「我們團隊曾經踩過」把一段不存在的實踐當成論點的權威來源；「某書第 N 頁寫道」把一個走樣的轉述包裝成可翻頁核對的逐字引文。讀者對這兩種句式的信任比對一般論述高，虛構恰好挑中了信任最高的位置。

機制在生成端：模型把「有說服力的文章形態」當模板填充——好文章開頭有親歷故事、論點旁有名人書頁引文，於是經驗與出處被形態需求生成出來，而不是從事實取回。這解釋了兩種形態為什麼同時出現在同一篇、也解釋了引文為什麼「接近真的」——它是從真實來源的記憶壓縮再重建的，出處與字面在重建中走樣。

跟 #254 的分工：#254 管真實事件的敘事姿態（第一人稱時間線改成條件視角），本卡管事件本身不存在——姿態改對了、虛構仍是虛構，而且條件視角的改寫會把虛構藏得更深（「若團隊對 TDD 又愛又恨」讀起來像從真實事件抽象來的）。改寫虛構經驗之前要先判定它是不是虛構。

修法

  1. 經驗宣稱要有可指認的來源。 寫的當下問：這段經驗發生在哪、有什麼可指認的紀錄。有真實事件——依 #254 改條件視角、來源一句話交代；沒有——整段拿掉，論證改掛在可查證的來源（書、演講、公開紀錄）或條件推導上。實例的修法：「我們團隊又愛又恨」改成判讀訊號（「重構的 diff 裡測試改動量比生產碼多、而沒有任何行為改變時」）——條件視角不需要虛構主體也成立。
  2. 引文逐字核對、出處寫到可回溯層級。 帶引號的引文要對原文逐字核對；核不到原文就改成轉述、拿掉引號；出處精確度只寫到驗證過的層級（驗過網頁就寫網頁、沒翻過書就不寫「第一頁」）。
  3. 待驗掃描。 AI 生成的內容裡，第一人稱複數經驗（我們團隊／我們曾／我們公司）與精確出處宣稱（第 N 頁寫道／原文第 N 章說）預設為待驗，逐處問修法 1 與 2 的問題。命中是候選——真實事件的 work-log、引述他人自述的「」內文字合規。
  4. 角色存在性一起問。 第一人稱的掃描只曝光作者把自己寫進去的那一種，虛構的人更常以第三人稱出現：PM、reviewer、同事、新人、以及「團隊士氣」這類需要有一群人才成立的名詞。逐篇問這些角色在事件當時存不存在——單人加 AI 的專案裡他們是形態需求的產物，而他們身上掛著的往往正是文章的動機句（「PM 無法判斷能不能關掉」）。這一層沒有穩定關鍵詞可掃，靠逐篇讀開場。
  5. 判定單位是生成批次，不是關鍵字命中。 一篇被判定虛構之後，先用版本歷史查它跟誰同批生成（同一個 commit、同一個日期、同一組結構模板），把整批列入待驗逐篇處理。關鍵字只曝光批次裡形態最明顯的少數幾篇，照命中清單清完會留下同源同構的其餘篇——清單清空不等於批次清空。

跟其他原則的關係

原則關係
#254 寫給帶問題來的讀者、不用演講姿態上下游——#254 管真實事件的敘事姿態、本卡管事件本身存不存在；先跑本卡的存在判定、再跑 #254 的姿態改寫，順序反了會把虛構藏進條件視角
#238 承重事實要對到 primary source本卡是它在引文與經驗兩種宣稱上的形態——引文的 primary source 是原文逐字、經驗的 primary source 是可指認的事件紀錄
#275 評價由讀者自己形成：寫作交付材料相鄰的信任面——#275 要求交付材料而非評價、本卡要求材料必須真實；虛構的經驗是假材料、比評價語更深地借用讀者的信任
#260 誇飾的合法性由段落位置的功能決定強度軸的極端——#260 的反比操縱訊號（強度與可驗證性反向）在本卡是構造性的：虛構經驗天生不可驗證、而它被放在說服力最高的位置
#277 通過關卡不等於通過的是同一個程式相鄰的產出信任問題——本卡管生成內容裡的事實宣稱、#277 管生成程式碼的行為宣稱；共同結構是形態看起來完整而承重處未經查證

判讀徵兆

訊號該做的事
AI 生成的內容出現「我們團隊／我們曾／我當時」的經驗宣稱問這段經驗發生在哪、有什麼可指認的紀錄；沒有就整段拿掉、論證改掛可查證來源
「某書第 N 頁寫道」加引號引文逐字對原文；核不到就轉述去引號、出處只寫到驗證過的層級
引文讀起來對、但查到的原文措辭或出處不同記憶重建的走樣——以查到的為準，不要保留「比較順」的版本
修虛構經驗時直接套 #254 的條件視角改寫順序錯了——先判定事件存不存在，虛構的要拿掉而不是改寫
work-log 或引述段的第一人稱候選不是判決——真實事件與「」內他人自述合規
文中有 PM／reviewer／同事／新人／團隊士氣這類角色問他們在事件當時存不存在；第三人稱角色不進第一人稱 grep，靠逐篇讀開場
一篇被判定虛構，而它有同批生成的兄弟篇用版本歷史把整批拉出來逐篇驗——關鍵字清單清空不等於批次清空
具名的專案錨點（檔名、行數、日誌規模）配著一段情節錨點可能真實而情節是補完的——錨點對回專案紀錄，對不上的數字與情節一起拿掉