为什么开场白决定了角色卡的可移植性

开场白是模型收到的第一条上下文，也是用户看到的第一段文本。它同时承担两个职责：为 AI 定调，为用户建立场景。写得不好，换一个前端就崩。

开场白为什么会在不同前端失效

不同前端对 greeting 的处理逻辑并不一致：

• 上下文注入方式不同：部分前端把 greeting 作为 assistant 消息，部分作为 system 或 user 消息，直接影响模型对”谁在说话”的判断。
• 变量与宏支持不同：{{char}}、{{user}} 等占位符在 SillyTavern 中通用，但其他前端可能只解析其中一部分。
• 截断策略不同：上下文窗口吃紧时，有的前端优先裁剪 greeting，有的优先裁剪历史记录。
• 多开场白（alternate greetings）的切换入口不同：SillyTavern 允许在 UI 中切换，其他前端可能默认只读第一条。

结论很直接：如果你的开场白依赖某个前端的特有行为，它就不是可移植的。

可移植开场白的四条硬规则

规则一：自包含，不依赖外部设定

开场白应当在不读取 description、personality、scenario 的情况下依然成立。模型可能只拿到 greeting 这一段。

• 用一到两句话交代地点、时间、当前动作。
• 明确写出角色的语气特征，而不是让模型去 character book 里推断。
• 避免”如前所述""按照设定”这类指向外部字段的表述。

规则二：只使用通用占位符

{{char}} 和 {{user}} 是跨前端兼容性最好的两个宏。其他宏（日期、随机数、变量运算）在多数前端中行为不一。

写法	可移植性	说明
{{char}} / {{user}}	高	主流前端均支持
硬编码角色名	中	换名或做变体时需重写
自定义变量宏	低	前端差异大
时间/随机函数	低	结果不可复现

建议：正文里用 {{char}}，需要强调名字时再硬编码一次，两者混用最稳。

规则三：长度控制在 80–150 词

太短，模型缺乏场景锚点；太长，在上下文紧张的前端会被优先裁剪，或在移动端造成阅读负担。

• 第一段：场景与动作，2–3 句。
• 第二段：角色开口，1–2 句对白，带明确语气。
• 结尾：留一个开放动作或问题，把主动权交给用户。

规则四：准备 2–4 条备选开场白

备选开场白不是重复，而是覆盖不同的进入方式：

• 场景变体：同一角色，不同地点或时间。
• 关系变体：初见 / 旧识 / 对立。
• 节奏变体：动作切入 / 对白切入。

把它们写进卡片的 alternate greetings 字段。支持切换的前端（如 SillyTavern）会直接列出；不支持的前端至少能读到第一条，不会报错。

实战示例：Kaelen the Wandering Blade

以 Kaelen the Wandering Blade 这张卡为例。角色是一名不带阵营的流浪剑客，语气克制、句子短、少用形容词。它的主开场白遵循了上述规则：

• 场景自包含：雨夜、路边酒馆门口、剑未出鞘。
• 只使用 {{char}} 和 {{user}}。
• 全文约 110 词，结尾是一个动作而非提问，避免强迫用户按固定方向回应。
• 备选开场白覆盖”白天官道相遇”与”雇主委托”两种关系起点。

这张卡在 SillyTavern 与 MiniTavern 应用中的表现差异主要来自前端渲染，而非 greeting 本身——这正是可移植写法要达到的效果。

导入前的自检清单

在把卡片分发出去之前，逐项确认：

• 开场白脱离 description 仍能读懂
• 只含 {{char}} / {{user}} 两类宏
• 长度在 80–150 词之间
• 结尾不强制用户走向
• 至少两条备选开场白
• 在至少两个不同前端中实测过

结语

开场白是角色卡里最容易被低估、又最影响跨前端体验的部分。把它写成自包含、宏通用、长度克制的文本，卡片才能真正跟着用户走。

如果你希望在同一套卡片上验证 SillyTavern 之外的运行效果，可以在 MiniTavern 的 iOS/Android 应用、Web Tavern 或 Chrome 扩展中直接导入测试，也可以到 MiniTavern 角色卡市场看看 Kaelen the Wandering Blade 这类按可移植标准制作的卡片。