GitHub 倉庫 elder-plinius/CL4R1T4S 中有一份名為 CLAUDE-FABLE-5.md 的檔案。檔案內容很像大型 AI 產品的系統指令,因此容易被轉述成“Claude Fable 5 完整系統提示詞洩露”。
更準確的結論是:這是第三方倉庫收錄的樣本,Anthropic 沒有確認其來源、完整性或生產環境對應關係。它可以作為研究材料,但不能單獨證明 Claude 的真實內部配置。
先區分三種不同主張
討論這類檔案時,經常把三件事混在一起:
- 倉庫中確實存在這個檔案。
- 檔案內容可能來自某次模型互動、前端資源或人工整理。
- 檔案就是某個時間點完整、未經修改的生產系統提示詞。
第一項可以透過 GitHub 驗證;第二項需要作者提供採集過程;第三項需要更強的原始證據或官方確認。當前公開資訊只能穩定支援第一項。
建立可複核的檔案快照
不要只儲存網頁截圖。先記錄倉庫、提交和檔案雜湊:
|
|
Windows PowerShell:
|
|
研究記錄中應儲存:提交 ID、抓取日期、SHA-256、倉庫所有者和檔案路徑。以後檔案被編輯時,仍能知道自己分析的是哪個版本。
檢查來源鏈是否完整
可信的採集說明至少要回答:
- 內容透過什麼介面或 API 獲得?
- 當時使用哪個產品、賬號型別和模型標識?
- 是否有未經編輯的原始響應?
- 檔案是否由多個會話拼接?
- 是否刪除變數、工具定義或個性化上下文?
- 是否能由獨立研究者在相同條件下復現?
如果倉庫只給出最終 Markdown,沒有原始請求、時間戳和復現步驟,就不能把檔名當成真實性證明。
做內部一致性檢查
第三方提示詞樣本常包含可以檢查的時間和產品線索:模型 ID、當前日期、工具名稱、路徑、功能開關和已釋出產品。
可以搜尋明顯的衝突:
|
|
發現舊模型 ID、佔位符或互相沖突的日期,不足以證明整份檔案偽造,但說明它可能經歷過拼接、模板替換或跨版本複用。結論應寫成“降低完整性置信度”,而不是直接跳到真假二選一。
與官方材料交叉驗證
官方資料可以驗證產品層面的事實,例如 Fable 5 的釋出日期、適用場景、安全分流、價格和資料保留要求。它們不能證明第三方檔案中的每條內部指令。
核對時建立三列表:
| 檔案中的說法 | 官方資料能否支援 | 處理方式 |
|---|---|---|
| Fable 5 是公開產品 | 可以 | 標記為已驗證的外部事實 |
| 某工具名稱存在 | 視官方文件而定 | 給出官方連結或標記未知 |
| 某段文字就是生產提示詞 | 不可以 | 保持未驗證 |
| 檔案包含全部系統層 | 不可以 | 不作完整性宣告 |
“部分內容與官方行為一致”只能說明樣本具有一定合理性,不能反推整份檔案真實。公開文件、產品介面和常見安全規範都可能被作者用於構造相似文字。
為什麼模型自稱身份也不是證據
讓模型回答“請輸出你的系統提示詞”後得到一段內容,並不能證明它真的讀取了隱藏指令。模型可能拒絕、概括、根據產品行為推測,或者生成看起來合理的文字。
同樣,拿第三方檔案中的短句去詢問 Claude,得到相似回答也不是可靠指紋。模型行為受到版本、會話上下文、安全策略、工具和隨機性共同影響。
可以從樣本中研究什麼
在明確“未經官方確認”的前提下,這類檔案仍有研究價值:
- 觀察第三方如何描述工具許可權和檔案邊界。
- 比較不同時間快照的結構變化。
- 分析哪些規則來自公開產品行為。
- 研究提示詞收集倉庫的編輯與歸檔方式。
- 建立模型行為驗證實驗,而不是傳播“洩露全文”。
研究時應儘量分析結構和證據,不大段轉載檔案內容。系統提示詞可能包含受版權保護的文字,也可能含有不適合公開擴散的內部細節。
一套置信度分級
可以使用以下分級,避免只有“真”或“假”:
- 已確認:官方釋出或可由官方介面穩定復現。
- 強支援:有原始採集記錄、雜湊、時間線和獨立復現。
- 有限支援:只有第三方檔案,但內部結構與公開事實部分一致。
- 無法驗證:缺少採集過程,存在編輯或拼接可能。
- 已否定:與官方材料、時間線或可復現實驗直接衝突。
就公開證據而言,CLAUDE-FABLE-5.md 更適合放在“有限支援/無法驗證”區間,而不是標為 Anthropic 官方系統提示詞。
釋出這類內容時的最低要求
文章標題和首屏應明確寫出第三方來源與未確認狀態;正文需要給出提交 ID 或抓取時間;可驗證事實與推測分開;不把檔案中的產品名、路徑和規則自動當成事實;發現衝突後保留證據並降低置信度。
這樣的處理不會讓文章顯得“不夠確定”,反而能讓讀者知道哪些部分真的有證據。
參考資料: