Grokipedia 把 AI 百科做成複製迴圈

我拆 Grokipedia 的上線、偏誤與抄 Wikipedia 工作流，最後給你一份可直接套用的 AI 百科模板。

我盯 Grokipedia 這類 AI 知識庫很久了，越看越煩。表面上都在講知識整理、品質控制、去偏誤，實際上常常是同一套老把戲：先把模型包成權威，再把別人的內容搬進來，最後用一個看起來很順的介面掩蓋整個流程的鬆散。我不是先罵它立場，我是先罵它方法。你如果讓模型同時負責改寫、摘要、審稿，還想相信結果會穩，這本身就很可疑。更別提它還吃了 Wikipedia 的骨架，外加自家授權、使用者建議、Grok 審核，然後還因為內容品質問題延後上線。這不是乾淨的知識系統，這是一個把 tradeoff 包裝得很像產品的東西。

我這次拆解的起點是 Grokipedia 的 Wikipedia 條目。我先用它，不是因為它最權威，而是因為它把上線時間、內容模式、批評點和後續延伸一次整理在同一頁。再往下我也會連到幾個原始來源：xAI、Grok、Wikipedia，還有我拿來看早期流量反應的 Similarweb。重點不是 Grokipedia 存不存在，而是它把「AI 生成參考內容」這件事到底有多脆，直接攤給大家看。

上線先延後，這本身就是警告

On October 6, 2025, Musk announced that the early version of Grokipedia was scheduled for release in two weeks, but the project was postponed briefly to address content quality issues.

翻譯一下就是：他們一開始跑很快，直到內容爛到連自己都沒辦法假裝沒看到。這種情況我看太多了。demo 可以，管線可以，真實內容一灌進去，模型就開始露餡。Grokipedia 最後在 2025 年 10 月 27 日以 v0.1 上線，這種版本號其實很誠實，意思就是「先別太認真看我」。

條目裡還寫它一開始就有超過 800,000 篇條目。數字看起來很大，但拿去跟英文 Wikipedia 的七百多萬篇比，差距就很明顯。知識產品不是頁面多就贏，頁面要能追溯、能維護、能校正，才算真的有用。你如果在做內部 wiki、產品文件、FAQ 知識庫，我會直接把「上線量」當成虛榮指標。真正該看的是，內容有沒有穩、來源有沒有交代、壞掉能不能追。

我之前做過一個模型輔助的文件產生器，第一版在瀏覽器裡看起來很順，像樣得很。結果一查邊角案例，模型開始偷換術語、把限制條件洗平、還把來源文件裡的語氣抄得很像，但意思已經偏掉。後來我發現問題不是「模型不夠強」，而是流程太鬆。只要沒有更嚴格的來源邊界、明確的審核節點、還有不能追溯就不能發佈的規則，這種東西最後都會變成一台自信機器。

我自己的實操寫法會這樣定：

• 每個事實都要有來源，不是只附一個大段引用區塊
• 高風險主題先人工看過，才允許公開
• 版本要可追，讓你知道壞頁面是模型、來源，還是審核步驟出問題

這很無聊，我知道。但這種無聊，剛好就是你少背鍋的地方。

抄 Wikipedia 不是偷吃步，是整個產品的起點

Some articles are nearly identical to their Wikipedia entries, and some Grokipedia articles were republished almost verbatim, accompanied by a disclaimer noting that the content was “adapted from Wikipedia” under a Creative Commons license.

這句話我看完只想說：那它根本不是從零開始，它是拿現成社群勞動當底，再包成另一套編輯系統。法律上如果授權允許，當然不一定有問題；但產品問題就變了。你不再是問「模型會不會寫」，而是問「這裡到底新增了什麼」。

條目裡提到 AMD、Lamborghini、PlayStation 5 這些頁面幾乎直接對照 Wikipedia。Musk 後來也說得很白：這是故意的，團隊叫 Grok 去整理 Wikipedia 前一百萬篇條目，再對它們做修改。這句比任何發表稿都重要，因為它直接把系統講成一條 transform pipeline：先吃成熟參考內容，再大規模改寫，最後讓模型自己決定哪些保留。

我以前做內容遷移腳本也很像這樣。你會先拿可信語料，跑轉換，然後比對輸出。危險的是，改寫那一步很容易不知不覺變成編輯那一步。到了那時候，你就不是在整理事實，而是在要求模型保留語意、同時改變表面形式。偏偏模型最會在這裡出事，因為它會很像有改，實際上已經歪了。

如果你自己也要做這種流程，我會強迫它長成三欄：

• 原始來源文字
• 機器轉換草稿
• 人工審核後版本

這樣一眼就看得出 drift 發生在哪。沒有這個切法，所謂「adapted from」通常只是把 copy job 包裝得比較好聽而已。

還有授權這件事也不能裝沒看到。Wikipedia 衍生內容吃的是 CC BY-SA 4.0，而 Grokipedia 其他非 Wikipedia 內容則用 X Community License。如果你在做一個混合開放內容和模型輸出的系統，別再把授權當註腳。它就是架構的一部分。

模型自己審自己，還是模型，不是編輯

Articles cannot be directly edited, though logged-in visitors to the encyclopedia can suggest new articles or corrections via a pop-up form, which are reviewed by Grok.

翻譯一下就是：它把社群編輯改成模型中介的收件流程。乍看很整齊，但你要記得，這個模型同時是寫手也是審稿人。我不喜歡這種設計。它把兩個不同職責塞進同一個機率系統，然後叫使用者因為有個回饋表單就安心。

條目還提到，從 v0.2 開始，Grok 會審核並實作被接受的建議修改，還有一個小面板輪播最近編輯過的文章。介面看起來很忙，但核心問題沒變。真正的編輯系統需要衝突、來源、決策紀錄；模型可以模擬這些東西，但不能自己保證這些東西真的成立。

我在 agent workflow 上也吃過這種虧。你加了一個「review」步驟，以為控制力上來了，但如果 reviewer 也是同一類模型、同樣調校、同樣語料，基本上只是多了一層儀式感。系統還是只有一個認知中心，這才是問題。

實操上我會硬切成三段：

• 一個模型或服務負責產草稿
• 另一個 validator 負責檢查引用、日期、專有名詞
• 人類處理爭議性、政治性、法律性內容

如果你做不到這樣，拜託別叫它 review。直接叫 auto-suggest 比較誠實，後面出事也比較不會被自己話術反咬。

偏誤不是空氣，是來源選擇

The xAI founder Elon Musk suggested Grokipedia could be an alternative to Wikipedia that would “purge out the propaganda” he believes is promoted by the latter, describing Wikipedia as “woke” and an “extension of legacy media propaganda”.

翻譯一下就是：這東西從一開始就不是單純百科，而是帶著「我要修正你」的姿態出場。你只要說自己在清除 propaganda，其實就已經選邊了。條目也提到外界批評它帶有右翼觀點與 Musk 本人的立場，甚至連 HIV/AIDS 否認、疫苗與自閉症、氣候變遷、種族與智力這些議題都被拿來質疑。

很多人講 bias 都講得很虛，好像是系統裡一團霧。不是。偏誤通常出現在來源選擇、措辭、刪減、加權。條目裡還提到研究發現 Grokipedia 會用像 X 討論串、甚至新納粹網站這類低可信來源，還會把某些極右人物寫得很像宣傳文。這不是小調參，這是 source policy 爆掉。

如果你在做 factual assistant，我會直接說：你的 source policy 比 prompt 還重要。這句不是口號，是工程事實。模型只能在語料和排序規則允許的範圍內表現。如果你餵垃圾，它只會把垃圾寫得更順。想少一點偏誤，就得做來源分級、排除清單、還有明確的主題規則。

我自己的規則很土，但有效：

• primary sources：能直接驗證的事實才用
• secondary sources：拿來補背景與解讀
• blocked sources：已知不可靠、會操弄、或明顯帶風向的來源直接擋掉

而且這些清單要常更新。來源品質會掉，別假裝它不會。你如果不管，最後掉的不是資料庫品質，是你自己對系統的信任。

流量不是信任，只是被看見

According to an initial analysis of usage figures by Similarweb, Grokipedia recorded a peak of over 460,000 website visits in the US on October 28, 2025.

翻譯一下就是：上線熱度不等於持續使用。條目還說，之後流量掉到 11 月 8 日到 11 日之間每天大約 35,000 次訪問。這種曲線我很熟，典型的好奇心先跑完，留下來的人不多。大家點進去看一下，然後發現內容品質或相關性不夠，就走了。

這對任何想做 AI 內容的人都很重要。你可以被索引、被引用、甚至被其他 AI 系統拿去回答問題，但那不代表你真的被信任。條目還提到 Grokipedia 後來出現在 GPT-5.2、Google AI Overviews、AI Mode、Gemini、Copilot、Perplexity 對某些冷門問題的回答裡。那叫分發，不叫驗證。

我看過很多團隊把 indexing 當 authority。爬蟲來了就開香檳，結果頁面根本留不住人。搜尋引擎和答案引擎不會替你審查知識論，它們只是把查詢導到它找得到的東西上。

如果你也在做類似產品，我會把指標拆成兩類：

• discovery 指標：收錄、曝光、導流
• trust 指標：回訪率、修正率、引用接受度

如果 discovery 上升、trust 下降，你不是在成長，你是在把品質問題包成曝光問題。

真正的產品其實是內容管線，不是百科全書

The Grok large language model generates and fact-checks articles on Grokipedia.

翻譯一下就是：Grokipedia 更像一條內容管線，只是前面包了一層百科介面。這個區分很重要。使用者看到的是搜尋框和文章頁，但真正的產品是後面那串生成、改寫、審核、授權、發佈的流程。

條目描述它的設計很極簡，首頁乾乾淨淨，一個大搜尋框。這種介面我很熟，很多 AI 產品都愛把複雜度藏在最前面那一層，因為 UI 最好做，也最容易先上線。但如果底層管線是髒的，極簡介面只會讓錯誤看起來更像正式答案。

我會把這種系統的失敗模式寫成契約。管線是產品的話，每一段都要能測：生成要有引用規則、審核要有拒絕標準、發佈要能回滾、搜尋要能控排序。沒有這些，你不是在營運參考系統，你是在營運文字工廠。

我自己會直接抄這個方向：

• 只從批准過的 source set 生成
• 每個 claim 都保留 source span
• 任何沒引用或引用太弱的段落先標記
• source text 和 published text 要能比 diff
• 每一次人工 override 都要留 log

這就是「AI 百科」作為行銷詞，和作為工程系統的差別。前者是 pitch，後者是你要每天維護的麻煩。

可抄的模板

# AI encyclopedia content pipeline template（可直接改成你自己的知識庫流程）

## 目標
做一個可追溯的參考站：AI 可以草擬、改寫、審核，但每個事實都要能回到來源。

## 輸入
- 已批准的 primary sources
- 已批准的 secondary sources
- blocked sources 清單
- 高風險主題清單
- 人工審核佇列

## 流程
1. 匯入來源材料。
2. 把每個來源標成 primary、secondary 或 blocked。
3. 只用已批准來源生成草稿。
4. 每個事實句都附上 source span。
5. 另外跑一個 validation pass，檢查：
   - 日期
   - 人名
   - 數字
   - 引號內容
   - 敏感主題
6. 高風險頁面送人工審核。
7. 只有驗證通過才發佈。
8. 保存 source draft、transformed draft、reviewer notes、final version。
9. 記錄每一次發佈後修正。

## 頁面結構
- title
- summary
- claims[]
- sources[]
- source_spans[]
- review_status
- risk_level
- last_updated
- revision_history[]

## claim 格式
每個 claim 都要有：
- claim_text
- source_url
- source_quote
- confidence_level
- reviewer_status

## 審核規則
- 沒有來源的 claim 一律拒絕。
- 依賴 blocked sources 的段落一律拒絕。
- 政治、醫療、法律、資安主題一律要人工批准。
- 每個已發佈版本都要有 rollback 路徑。

## 生成 prompt
你正在撰寫一篇事實型百科條目。
只能使用下方批准過的來源。
不要捏造事實。
除非來源明確寫出，否則不要推測日期、數字或人名。
每一句事實都要附至少一個 source span。
如果某個 claim 不確定，就標示不確定，不要猜。

## 審核 prompt
你正在驗證一篇事實型百科草稿。
逐條核對每個 claim 與來源。
拒絕沒有依據的 claim。
標記引用薄弱處。
標記帶立場的語言。
標記宣傳式措辭。
回傳 accept / revise / reject 決策與理由。

## 最小上線清單
- [ ] source coverage 完整
- [ ] 沒有使用 blocked sources
- [ ] 高風險主題已人工審過
- [ ] claims 都有 source spans
- [ ] rollback 已測試
- [ ] revision log 已保存

這段不是 Grokipedia 的複製版。我真正在意的，是如果你非得做一個 AI 參考系統，至少把 provenance、review、rollback 這三件事做成硬規則，不要靠氣氛。這份模板就是我會直接拿去改的版本。

原始來源主要來自 Grokipedia 的 Wikipedia 條目，以及它引用到的相關公開資料。上面這份模板是我自己整理的，但拆解出來的失敗模式，都是從那份公開資訊一路推回來的。