上傳到 Chub.ai 或 RisuAI 之前如何驗證你的角色卡。上傳之前，先驗證你的角色卡 —— Chub.ai 與 RisuAI 通用版。

打開任何一個主流卡片平臺的支援版面，重複出現的問題大同小異：卡上傳成功，但開場白是空的、世界書沒帶上來、圖片預覽壞掉。這些討論串的結局也都差不多 —— 安靜地改一改、重新匯出、再上傳一次。卡本身其實只差一點點。

驗證就是省下這些回頭路的廉價習慣。把卡推到 Chub.ai、或匯入 RisuAI 之前，花兩分鐘照欄位走一遍。同一份清單可以放大 —— 十張卡用眼睛看，一百張卡寫腳本。這篇就把兩面都寫清楚：人工該看什麼、lint 該替你做什麼。

大致按社群 bug 串中出現的頻率排序：

1. 缺少 first_mes 或空的 mes_example。 平臺通常會接受卡片，但對話視窗會是空白。RisuAI 特別依賴 mes_example 做語氣對齊，空字串並不等於合理預設值。
2. 過長的 description 撐爆 token 預算。 卡上傳順利，第一次生成時 prompt 已被人格設定塞滿，模型沒空間真的回話。各平臺 token 上限不同，但廣義原則：常駐區塊（description + personality + scenario + system_prompt）要留出充足的對話歷史空間。
3. 把 creator_notes 與 system_prompt 搞混。 前者面向人類讀者 —— 使用提示、警語、致謝。後者每回合都會發給模型。互調的結果，要嘛把後設評論漏進對話、要嘛把 jailbreak 完全藏起來。
4. PNG tEXt 區塊損壞或編碼錯誤。 歷史慣例是：keyword 為 chara 的 tEXt 區塊，內容為 Base64 編碼的 UTF-8 JSON。若工具直接寫入原始 UTF-8（沒 Base64）、剝掉非 ASCII 字元、或用錯 keyword，產生的 PNG 在某些平臺能開，到下一個就靜默壞掉。
5. character_book 欄位型別錯誤。 每個 entry 都有特定形狀： keys 是字串陣列，不是逗號分隔的字串； insertion_order 是數字； enabled 是布林值。手改過的世界書經常把數字寫成字串、或把陣列寫成單一字串，匯入器會默默丟掉整個 entry。
6. extensions 下放了目標平臺認不得的自訂鍵。 SillyTavern 寫進去的 Regex pipeline 設定，到 Chub 的預覽 renderer 完全沒意義。不會壞 —— 但你在本地測好的行為，搬家之後就不見了。
7. V3 限定欄位放進 V2 卡裡。 nickname、 group_only_greetings、 creator_notes_multilingual 都是 V3 新增。若卡片的 spec 仍寫 chara_card_v2，符合規範的客戶端有權忽略這些鍵。
8. tags 形狀寫錯。 它是「字串陣列」。 "tags": "fantasy, royalty" 是「字串」，要嘛被拒收，要嘛被索引成一個怪異的單一標籤「fantasy, royalty」。
9. alternate_greetings 含空字串。 空 entry 通常是忘記清掉的草稿殘留。有的客戶端會渲染成空白選項，有的會直接報錯。無論哪種都是噪音 bug。
10. 平臺策略 —— 限流、圖片尺寸上限、NSFW 過濾。 這些不屬於 schema 問題，本地 lint 抓不全，但造成的上傳失敗一點也不少。批次上傳前先把每個平臺的規則翻一遍。

卡片不多時，親自走一遍勝過任何工具。送上傳鍵之前，把以下打勾：

• [ ] spec 與 spec_version 一致（V2 對 2.0、V3 對 3.0）。
• [ ] name、 description、 first_mes 皆存在且非空。
• [ ] 常駐 prompt 區塊在目標 context window 內留有充足對話空間。
• [ ] creator_notes 中沒有寫給模型看的指令。
• [ ] PNG 可以開啟，預覽正常，hex 中可見 keyword 為 chara 的 tEXt 區塊。
• [ ] 每個 character_book.entries[*].keys 都是字串陣列。
• [ ] tags 為陣列； alternate_greetings 無空字串。
• [ ] V2 卡內無 V3 限定鍵（反之亦然）。
• [ ] extensions 下每個鍵都有文件、且你清楚它對應哪個平臺。
• [ ] 目標平臺的上傳規則（圖片尺寸、NSFW 政策、頻率限制）已逐一確認。

手工清單大概撐到三十張卡片就會失去樂趣。再往後就是自動化。一個好用的卡片 linter 主要做三件事：

• Schema 驗證。 解析 PNG、解碼 tEXt 區塊、依宣告的 spec 驗 JSON：必填欄位、型別、列舉值、V2 卡裡不該有 V3 鍵等等。
• 平臺相容性矩陣。 對卡片中每個鍵，回報哪些目標平臺真的會讀。只有 SillyTavern 讀的欄位並不算壞 —— 你只是想在做假設前先知道它無法跨平臺帶走。
• Token 預算估算。 用幾個常見 tokenizer 把常駐 prompt 區塊加總，當它佔掉的 context 超過目標模型可承受時提早預警。

這正是 tavernai.cards 正在打造的位置：一個上傳前的工作臺，跑你本來會手工跑的檢查，對應你實際發佈的目標平臺。