開場白不可移植的三個真實原因

在 2026 年，同一張 character-card 在 SillyTavern、MiniTavern 與各類 Web 前端之間的渲染差異，最常暴露問題的地方不是人設，而是開場白。一段在 SillyTavern 裡表現良好的 greetings，換到行動裝置或 Chrome 擴充功能後，可能出現佔位符未替換、第一人稱錯位，或首輪就把劇情推得過快。本文討論如何寫出跨前端可移植的開場白。

• 巨集與佔位符不一致：{{char}}、{{user}}、{{random}} 等巨集在不同 frontends 的支援程度不同，部分前端對巢狀巨集或自訂變數直接原樣輸出。
• 格式假設過強：依賴特定 Markdown 渲染、HTML 標籤或特殊分隔符的 greetings，在精簡渲染器中會遺失結構，甚至把標籤當正文顯示。
• 敘事節奏綁定單一模型：為某個模型調校過的開場長度與資訊密度，換模型後容易變成冗長鋪陳或資訊不足。

可移植開場白的三條硬規則

規則一：只用通用巨集，且全部顯式閉合

優先使用 {{char}} 與 {{user}}，避免依賴 {{random::...}}、{{pick}} 等可選巨集作為語意核心。若必須使用隨機內容，把它放在裝飾性位置，確保巨集失效時句子仍然通順。

• 錯誤範例：{{random:清晨,黃昏}}的光落在{{char}}肩上。 —— 巨集失效後句子斷裂。
• 正確範例：清晨的光落在{{char}}肩上。 —— 無巨集依賴，替換後語意完整。

規則二：把場景資訊寫進自然語言，而非格式

不要用縮排、表格、自訂標題層級來承載關鍵設定。跨 frontends 的 roleplay 體驗中，純段落加對話的 greetings 保真度最高。

寫法	可移植性	說明
純段落 + 引號對話	高	所有前端一致渲染
加粗/斜體強調	中高	多數前端支援，但勿承載語意
清單承載劇情	低	部分前端會重排或摺疊
HTML 標籤	低	常被轉義為可見文字

規則三：首輪只交付「鉤子」，不交付「劇情」

開場白的目標是建立場景、語氣與一個可回應的開口，而不是替使用者做決定。控制在 120–200 字，包含：一個空間錨點、一個角色動作、一句可被接住的對話。

• 空間錨點：讓使用者知道自己在哪、何時。
• 角色動作：體現性格，而非羅列設定。
• 可回應對話：以問句或半句留白結尾，降低使用者首輪負擔。

以 Captain Elara Voss 為例拆解

Captain Elara Voss 是一張適合示範可移植 greetings 的卡片：她的設定依賴權威感與克制語氣，而不是複雜世界觀。可移植寫法應避免引用具體艦船型號或專有名詞堆疊，改用行為與語氣傳達身分。

一個跨前端穩定的開場結構：

1. 一句環境描寫，不含巨集。
2. 一句 Elara 的動作，使用 {{char}}。
3. 一句直接稱呼 {{user}} 的對話，留出回應空間。

這樣在 SillyTavern 的完整渲染、行動裝置的精簡檢視、以及 Chrome 擴充功能的側欄中，輸出差異僅限於排版，不涉及語意。

上線前的跨前端自檢清單

• 在至少兩個 frontends 中各跑一次首輪，比對巨集替換結果。
• 檢查 greetings 中是否存在 HTML 標籤或自訂分隔符。
• 確認刪除所有裝飾性巨集後，段落仍然語意完整。
• 確認首輪沒有替使用者設定動作、台詞或情緒。
• 若卡片含多條 alternate greetings，逐條獨立驗證，而非只測第一條。

結論

可移植的開場白本質是「降低前端假設」：少用巨集、不用格式承載語意、首輪只給鉤子。把這三條固化為 character-cards 的寫作習慣，greetings 就能在 SillyTavern 與其它 frontends 之間穩定重複使用。

如果你希望在 iOS、Android 與桌面端快速驗證同一張開場白的渲染效果，可以在 MiniTavern 用戶端與 Chrome 擴充功能中分別試跑，並從 MiniTavern 角色卡市場取得 Captain Elara Voss 這類結構清晰的卡片作為對照樣本。