我用2000篇文檔蒸餾了自己，結果只得到了一個低質RAG

當 Codex 與飛書文檔碰撞，數字分身計劃卻暴露了 AI 的認知鴻溝。本文作者將 2000 多份工作文檔喂給 AI，試圖打造能替代決策的'數字分身'，最終得到的卻只是低質 RAG 系統——它能檢索顯性知識，卻無法復刻人類判斷中那些未言明的隱性邏輯。

———— / BEGIN / ————

最近跑路了，為了方便交接，我用 Codex 調用飛書 CLI，把自己過去寫過、參與過、沉淀過的 2000 多篇飛書文檔和 Axure 原型全部拉了下來，讓 AI 做解析，再基于這些內容構建了幾層索引。

簡單說，就是想把過去幾年的“我”蒸餾出來，做成一個數字分身。

跑路后，業務就可以對著這個分身問一些問題，比如：“這個功能當時為什么這么設計？”、“XX系統里某個能力是怎么考慮的？”

這個想法聽起來挺美好。

畢竟文檔都在，原型都在。

按理說，只要把這些東西喂給 AI，它不就能接住我的歷史經驗了嗎？

但實際用下來，我發現它沒有變成“我”，只變成了一個低質 RAG。

為什么它只是一個低質 RAG

這個蒸餾項目本質上只是把文檔做成知識庫，再接一個問答入口，它最多解決“找得到資料”的問題，很難“像這個人一樣判斷問題”。

RAG 論文里講的 retrieval augmented generation，本質上是讓模型在生成時檢索外部知識，用來增強知識密集型任務的表現。但檢索增強不等于判斷增強。

它能把資料拿過來，不代表它知道資料之間誰更新、誰覆蓋誰、誰只是草稿、誰才是當前口徑；更不代表它知道這件事為什么這么做，以及到底該由誰負責。

所以我說它是一個低質 RAG，主要體現在三個特點上。

第一個特點，是只能檢索結論，不能理解判斷。

它能根據問題找到相關文檔，但不知道為什么這個功能當時要這么設計。比如業務問一個活動功能為什么沒做，RAG 可能會找到活動方案、需求評審記錄、某個版本范圍說明，然后拼出一個回答。

但在游戲行業里，一個活動規則為什么沒有做某個能力，通常不是只看最終方案就能理解的。

• 可能不是產品忘了，而是當時版本排期不允許；

• 可能是海外 SDK 的能力邊界沒開放；

• 可能是活動目標只是短期拉活，不值得把長期系統能力做進去；

• 也可能是運營、研發、發行、合規之間已經做過一次權衡。

文檔里可能只寫了最終方案：“本期暫不支持 XX 功能。”但人腦里記住的往往是另一層內容：“當時為什么暫不支持。”前者是結論，后者才是判斷。

所以它經常只能回答“資料上寫了什么”，不能回答“當時為什么這么判斷”。

第二個特點，是能模仿人的口吻，但分不清責任邊界。

最經典的一次，是業務問它海外 SDK、活動項目里某個功能是怎么回事，為什么沒有記錄。

數字分身回答得很順，甚至還很有擔當，大概意思是：“這個功能我當時沒有考慮到位。”

看起來是不是挺像一個離職同學在認真復盤？但問題是，這個項目根本不是我的項目。

真是人在家里坐，鍋從天上來。

更尷尬的是，相關記錄其實在索引文檔里也能找到。也就是說，它不是完全沒有資料，而是沒有理解清楚“這件事是誰負責的”、“我在里面扮演什么角色”、“這個問題應該歸因到哪里”。

第三個特點，雖有知識索引，但索引不到足夠深的隱性知識。

一開始我以為，數字分身做不好，可能只是索引沒建好。比如 chunk 切得不合理，向量檢索召回不準，元數據不夠細，Axure 原型解析得不完整，文檔之間的關聯沒有建起來。

但是在我嘗試了幾輪后，問題并未被解決。因此，我覺得，更底層的問題是：就算索引建得更好，它索引到的也主要是文檔里的顯性知識。

比如 PRD 寫了功能規則，會議紀要寫了本次結論，Axure 原型畫了頁面狀態，復盤寫了這次活動的數據結果。這些內容有用，但它們不等于一個人做判斷時真正調用的全部知識。

真正難復刻的是那些沒有寫深、甚至沒有寫出來的隱性知識。

比如一個活動功能為什么沒做，文檔里可能只寫“本期暫不支持”。但實際判斷里，可能還有一串背景：當時海外 SDK 還沒開放對應能力，研發排期已經被版本節點卡死，活動本身只是一次短期驗證，做成長期系統能力反而不劃算，運營側也接受用人工方式先兜一版。

這些才是產品經理腦子里真正用來判斷的東西。

這些內容很少會完整寫進文檔。

Michael Polanyi 在《The Tacit Dimension》里有一個很經典的說法，大意是：人知道的東西，往往比能說出來的更多。

這就是所謂的隱性知識。

放到這里，就是文檔記錄了“當時怎么做”，但沒有完整記錄“為什么這么做”、“為什么不那么做”、“誰能為這個判斷負責”。

所以，當我把 2000 多篇文檔喂給 AI 時，我其實只是把一堆顯性知識喂給了它。但我希望它復刻的，是一個會把顯性知識、隱性知識和當前環境放在一起判斷的人。

這中間差的，不是多建幾層索引就能完全補上的。這件事有解嗎？

那么這件事有解嗎？

我覺得有優化空間，但還沒到能說“已經有成熟解決方案”的程度。因為它不是單純的 RAG 問題。RAG 本身解決的是“讓模型回答時能引用外部知識”。

這個方向當然有價值。

IBM、TechTarget 等很多資料也都提到，RAG 在企業里常見的問題，集中在檢索不準、chunk 切分不合理、上下文窗口限制、復雜關系理解不足、知識過期和治理困難這些方面。

這些問題可以繼續優化。比如把文檔清洗得更好，補充元數據，區分版本、負責人、適用范圍；或者用知識圖譜、GraphRAG 之類的方式，把文檔之間的項目、功能、系統、人員、時間關系建出來，避免 AI 只在一堆碎片里做相似度匹配。

但這些優化，更多是在把“檢索資料”做得更準。它不一定能解決“復刻判斷”。

因為一個人的判斷里，還有大量文檔里沒有寫出來的隱性知識。

也就是說，就是我不能只把文檔交給 AI，還得想辦法把當時沒寫出來的判斷理由、責任邊界、業務環境補出來。

所以這件事到最后，已經不只是一個個人數字分身的問題了。

它其實指向了 AI 更大的方向：不是讓機器替代人，而是把人腦里那些原本說不清、寫不全、卻真正決定判斷的東西，一層層拆出來，再慢慢交給 AI 去學習。

這也是為什么我覺得，今天的低質 RAG 只是開始。它離真正的“我”還很遠，但它已經把下一步該往哪走，露出來了。

未來的 AI，不一定會先學會怎么說得像人，但它大概率會先學會，像人一樣理解知識、理解邊界、理解環境，最后再去理解判斷。

本文來自公眾號：檸檬餅干凈又衛生 作者：檸檬餅干凈又衛生

不想錯過 AI 新趨勢，也想結識志同道合的伙伴？長按識別二維碼，免費加入AI 共學交流群，一起學習、一起玩轉 AI！