开场白不可移植的三个真实原因

• 宏与占位符不一致：{{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 这类结构清晰的卡片作为对照样本。