角色卡 V2 與 V3 對比：變更內容以及如何遷移。角色卡 V2 與 V3：
變更了什麼，又該如何遷移。

如果你曾經從某個客戶端匯出一張角色卡、再匯入另一個客戶端，然後 眼睜睜看著一半欄位消失 —— 開場白被截斷、lorebook 不見了、自訂 提示詞被靜默丟棄 —— 那你已經遇到了 V1 / V2 / V3 的問題。Tavern 角色卡格式是社群共同的遺產。沒有單一委員會、沒有版本化的 schema 註冊處，也沒有任何一個平臺以完全相同的方式實作每個鍵。

對多數創作者來說這原本不重要 —— 直到你開始維護一份必須同時存活 於 Chub.ai、 RisuAI、 以及朋友自架的 SillyTavern 的角色卡庫。送錯版本就等於丟掉花了好幾小時寫的成果。本文會走 過每個版本新增了什麼、哪些地方可以放心用 V3、以及如何在不弄壞 東西的前提下完成遷移。

V1 角色卡是最初的 Tavern 格式：一份 JSON 透過 PNG 的 tEXt 區塊（關鍵字為 chara） 嵌入，並以 Base64 編碼。schema 是扁平且極簡的 —— 大致只有 name、 description、 personality、 scenario、 first_mes 以及少數同層欄位。它撐起了社群好幾年，也讓多數平臺至今仍把它 當成相容回退。

但 V1 沒有為 lorebook、備選開場白、或任何關於作者與調教模型的 結構化中繼資料留空間。所有「進階」內容只能塞進 description 的散文裡。這正是 V2 想填補的缺口。

V2 沿用 PNG tEXt 的傳遞方式，但把 payload 包進一個頂層信封：

{
  "spec": "chara_card_v2",
  "spec_version": "2.0",
  "data": {
    "name": "...",
    "description": "...",
    /* every real field lives under data */
  }
}

這層巢狀就是頭條變更 —— 只認扁平結構的舊客戶端會什麼都看不到， 這也是為什麼 V2 角色卡幾乎都會額外保留一份 V1 風格的頂層欄位 作為相容墊片。

在 data 之下，V2 引入了一批創作者開始依賴的欄位：

• character_book —— 直接內嵌在角色卡內的 lorebook，擁有自己的條目、關鍵字、 觸發順序與插入深度。
• alternate_greetings —— 一組備選開場訊息，可隨機或由使用者挑選。
• tags、 creator、 character_version —— 為畫廊與作品溯源準備的結構化中繼資料。
• system_prompt 與 post_history_instructions —— 為 system 訊息與類 jailbreak 的尾端指令準備的明確欄位， 取代過去硬塞進 description 的習慣。
• 從 V1 沿用、語意更乾淨的欄位： personality、 scenario、 mes_example、 first_mes。
• extensions —— 一個自由形式的物件，任何平臺都可在此放私有設定。這也是 V3 後來據以擴展的逃生艙口。

從平臺面來看，V2 在 2026 年仍是相對安全的預設選擇。 SillyTavern 視之為正典，Chub.ai 同時儲存與分發 V2，RisuAI 也支援大部分 V2 表面，僅少數欄位以其自家 UI 慣例詮釋。如果 你今天必須挑一種格式做跨平臺分發，答案仍是 V2。

V3（標識為 spec: "chara_card_v3"） 最好理解為精修而非重寫。它在 V2 信封上疊加少量新能力， 並收緊先前未明確規定的部分。多數創作者會碰到的新表面包括：

• assets —— 一種與角色卡並行宣告額外媒體（表情、替換立繪、音訊） 的方式，免去依賴平臺特有的 sidecar 檔案。
• group_only_greetings —— 僅當角色被載入到群組聊天時才出現的開場白，1:1 不會觸發。
• nickname —— 一個用於對話中顯示、與正式角色名分離的短稱呼。
• creator_notes_multilingual —— 一個以語系為鍵的作者註解對應表，讓同一張角色卡能同時呈現 EN、JA、ZH 版本的作者評論，而不必擇一隱藏其他。
• source —— 一個明確的出處 URL（或 URL 列表），用於角色卡衍生自或 重混既有作品的情境。
• Schema 型別略為收緊 —— 陣列就是陣列，可選欄位明示，V2 一些 string-or-array 的歷史曖昧也被釘死。

誠實的提醒：V3 仍在沉澱。不同平臺實作不同的子集，規格本身也 仍在公開演進。SillyTavern 在 V3 覆蓋面領先；其他平臺只實作 部分功能，並對不認識的鍵悄悄回退到 V2 語意。這也是為什麼一個 知道哪些鍵能在哪些平臺存活的 linter 會非常有用 —— 而這正是 我們正在把 tavernai.cards 打造成的位置。

多數 V2 → V3 的遷移是機械式的：升 spec、 加上新的可選鍵、就送出去。會出錯的地方相當可預測：

1. extensions 底下的自訂鍵。 V2 允許任何平臺在此寫任何東西。當你遷移到 V3，其中一部份 自訂鍵現在有了一等公民的對應欄位（例如 asset 引用），其他 則沒有。粗暴合併會讓同一筆資料同時存在兩處，而不同平臺對 優先順序的選擇又不可預期。
2. 多語欄位。 creator_notes_multilingual 是 V3 新增的。不認識它的平臺會回退到純文字的 creator_notes 欄位。如果你只填了多語對應表、卻把純文字欄位留空，舊客戶端 將什麼也顯示不出。
3. PNG tEXt 編碼。 歷史慣例是把 UTF-8 JSON 以 Base64 編碼後放進名為 chara 的關鍵字。出乎意料多的 bug 來自某些工具直接寫入未編碼的 UTF-8，或在嵌入前剝掉非 ASCII 字元。如果你的角色卡在一個 平臺能乾淨開啟、在另一個平臺卻悄悄損毀，原因通常就在這裡。
4. 內嵌與外部 lorebook。 character_book 跟著角色卡走 —— 對可攜性是好事，對共享世界觀則痛苦。如果三張 角色卡共用一份 lorebook、又都採用內嵌維護，你就有三份要同步 的副本。多數團隊最終會想要一份正典的外部 lorebook，再加上 一份精簡內嵌副本作為回退。
5. assets 中的相對路徑。 V3 的 asset 引用可以是相對或絕對，而規格並未完全釘死解析 基準。各平臺的假設不同。如果你的角色卡會跨平臺流通，使用 絕對 URL（或內容雜湊）會更穩妥。

tavernai.cards 正是為這套工作流而生：以單一可信來源維護你的角色卡名冊、 對 V2 與 V3 規格同時做 lint、再以特定平臺真正理解的形態匯出。

• Lint —— 在你發布前先抓出缺失的開場白、過時引用、平臺不相容的欄位。
• 自動遷移 —— V1 到 V2 到 V3，附上你可以審閱的 diff，而不是一個黑箱 覆寫。
• 多平臺同步 —— 把同一張角色卡以各平臺各自的方言推送到 Chub、RisuAI 與 SillyTavern。
• V2 / V3 雙向匯出 —— 從同一個來源同時產出 V3 角色卡與 V2 相容版本。