美化概览

而是先帮你建立对“美化”这件事的整体认识。

你会先弄清这几个关键问题：

• 为什么会有“美化”
• 为什么状态栏会掉格式
• 正则、JSON、标签交互分别适合做什么

如果你是第一次接触角色卡美化，建议先看完这页，再决定从哪篇教程开始。

为什么会有美化

美化的目的，不是为了把内容做得更花哨，而是让模型生成的内容更适合阅读，也更适合交互。

模型擅长生成文本，但文本生成出来之后，未必就是更清楚、更好用的展示形态。

最早期的做法，通常只是借助 Markdown 做一些基础排版，例如：

• 标题
• 列表
• 加粗
• 引用
• 代码块

这套方式足够轻量，也足够稳定，适合处理大多数纯文本内容。
但当需求开始变成状态栏、卡片、面板、按钮，甚至更进一步的交互时，Markdown 的表达能力就会逐渐不够用了。

美化方案发展史

1. Markdown 排版

这是最早也最基础的方式。

优点很明显：轻量、好写、稳定。

但它更像“排版”，不是“界面渲染”。
一旦要做复杂 UI，能力就明显不够了。

2. 让 AI 直接输出 HTML 和 CSS

后来很多用户开始直接让 AI 输出 HTML 和 CSS。
这样做出来的效果，确实会比纯 Markdown 丰富很多。

但问题也很快出现了：

• 首先要把 HTML 告诉 AI，然后 AI 每次照着输出和更新
• 一来一回，上下文里塞进大量标签和样式，Token 消耗很高
• 模型一边生成内容，一边还要维护复杂结构，负担很重
• 聊天一长，模型注意力会明显下降

也就是说，这条路能做出效果，但成本太高，不适合长期使用。

3. 正则美化

再往后，正则美化慢慢成了主流方案。

它的思路是：

1. 先让模型输出一段相对稳定、相对简单的文本结构
2. 再用正则把这段文本匹配出来
3. 最后替换成 HTML 和 CSS

相比“直接输出整套 HTML”，它前进了一大步：

• 模型返回的正文可以更简洁
• 页面样式可以交给前端处理
• 作者可以复用固定模板

但随着需求越来越复杂，正则方案也暴露出几个问题。

1. 编写门槛高

用户不仅要理解匹配规则，还要理解捕获组、贪婪匹配、非贪婪匹配、边界和转义。
这对大多数用户并不友好。

2. 维护成本高

模板里经常要写 $1、$2、$3；字段一多，可读性会迅速下降，调试也很麻烦。

字段增减、顺序变化，正则和模板往往都要一起改。很多时候，连提示词也要跟着改。

3. 对返回格式过于敏感

很多用户问“为什么聊着聊着状态栏掉了”。根源其实很简单：

渲染依赖模型返回固定格式，但模型并不一定每次都能完整、稳定地返回那套格式。

一旦少一个字段，整条正则就可能失效。

比如你本来要求模型返回：

<时间位置>
  <时间>第 3 天 / 夜晚</时间>
  <地点>中央医院</地点>
</时间位置>

然后你用正则去匹配：

/<时间位置>[\s\S]*?<时间>([\s\S]*?)<\/时间>[\s\S]*?<地点>([\s\S]*?)<\/地点>[\s\S]*?<\/时间位置>/g

只要模型出现下面任意一种情况，就可能匹配失败：

• 漏了某个标签，某个标签没闭合
• 字段顺序变了
• 中间插入了不该有的文本

一旦没匹配上，前端就拿不到完整结果，用户看到的效果就是：
状态栏没了、卡片没了，或者只剩一段原始文本。

4. 性能风险更高

很多用户会让 AI 帮忙生成正则，但不同正则的质量差异很大。

写得好的时候还能用，写得差的时候，性能和稳定性都会明显下滑。

复杂正则如果写得不稳，容易造成高回溯，带来卡顿、发热，严重时甚至会把浏览器拖死。

5. 流式体验不理想

正则通常要等一整段可匹配文本返回后，才能成功替换。

如果中途格式不完整，界面就很难稳定地逐步显示出来。

4. JSON 美化

于是，问题开始变得更清楚：
真正困难的，不是“怎么把文本替换成 HTML”，而是“怎么让模型稳定返回可渲染的数据”。

我们开始探索将美化方案从“文本匹配”转向“结构化数据”。

JSON 美化的核心思路是：

1. 让模型返回结构化 JSON 数据
2. 平台根据 type 匹配对应模板
3. 再把字段渲染到 HTML 和 CSS 里

这一步的变化，不只是换了一种写法，而是把“依赖整段文本精确匹配”改成了“依赖结构化字段渲染”。

为什么更推荐 JSON 美化

JSON 美化解决的，不只是“更好看”，而是“更适合长期使用”。

1. 数据和模板分开了

模型负责返回数据，模板负责决定怎么展示。
这样分工更清楚，维护也更轻松。

2. 字段本身有语义

比起 $1、$2、$3，title、location、weather 这类字段名更直观。
作者更容易维护，模型也更容易理解和更新。

3. 不再强依赖字段顺序

正则经常依赖“第一个是什么、第二个是什么、顺序有没有变”。
JSON 更偏向“这个字段叫什么、有没有值”，对顺序不那么敏感。

4. 更适合流式渲染

相较于正则需要等到整段文本能被完整匹配后才替换，JSON 更适合边返回、边补全。
只要能先识别出 type 并命中模板，页面就可以更早进入可渲染状态，后续字段再逐步补全。

5. 掉格式问题更少

平台对 JSON 美化做了额外处理，例如：

• 按 type 绑定模板
• 使用模板引擎渲染字段
• 在渲染层隔离样式
• 对不完整 JSON 做尽量可用的修复和回退

这些处理不能保证模型永远不出错，但能显著降低“因为一点格式波动就整块不显示”的概率。

6. 更适合扩展

当你想增加字段、拆分模块、做插槽嵌套、补交互时，JSON 的扩展空间会比正则更自然。

标签交互指令是什么？

标签交互指令不是单独的一种美化方案。

更准确地说，它是“交互层”。

它负责的是：

• 点击发送消息
• 提交表单
• 切换类名
• 显示 / 隐藏元素

它可以配合：

• JSON 美化产出的 HTML
• 正则美化替换出来的 HTML
• 原始 Markdown 中可保留的 HTML 结构

所以这章里三篇教程的关系并不是完全平级：

• 正则美化：偏文本匹配与替换
• JSON 美化：偏结构化渲染
• 标签交互指令：偏交互增强

我该选哪种方案

可以直接按这个思路选：

需求	更适合的方案
只做基础排版	Markdown
兼容旧角色卡，或做少量固定替换	正则美化
新建角色卡、状态栏、卡片、结构化 UI	JSON 美化
需要点击、切换、提交、发送等交互	标签交互指令

新建角色建议

如果你是在新建角色卡，而不是兼容旧卡，优先从 JSON 美化 开始。

如果只是给现有 HTML 补一点轻量交互，再继续看 标签交互指令。