系统保留标签
系统会自动解析的内置标签清单，创作时需要避开这些标签名以免功能失效
Storvia 平台会在 AI 每轮回复中自动解析一组系统保留标签，用于驱动状态同步、UI 渲染等内置功能。这些标签不是给作者直接使用的「美化标签」——如果你在指令中让 AI 把它们用作其他用途，或者在正则美化里自定义同名标签，会和系统行为冲突，导致功能失效。
本章列出所有保留标签，并说明常见的踩坑场景与正确做法。
本章列出的标签只能由系统驱动 AI 自动输出，作者不应在指令里要求 AI 在正文中使用它们，也不应在正则美化中创建同名规则。
状态保留标签清单
下表中的标签由系统在 <state> 容器内自动解析，对应 SDK 的状态模块（storvia.world / storvia.player / storvia.characters 等）。
| 标签 | 系统用途 | 对应 SDK 模块 |
|---|---|---|
<state> | 状态根容器，输出位置见下方说明 | — |
<world> | 世界状态（时间 / 地点 / 天气） | storvia.world |
<player> | 玩家属性（按分组） | storvia.player.state |
<character> | NPC 角色状态 | storvia.characters |
<item> | 物品 / 道具 | storvia.inventory |
<relation> | 角色之间的关系 | storvia.relationships |
<custom> | 扩展属性（自定义字段） | storvia.custom |
这些标签每轮由 AI 自动输出，由系统解析后自动写入对应模块。作者用 SDK 读取这些数据时，应通过 状态模块 提供的接口（如 storvia.state.get()、storvia.world.get()），不要尝试自己去解析 AI 的回复文本。
三类典型踩坑
1. 在指令里让 AI 把状态标签用于正文
❌ 错误做法：
请在每条回复开头用
<state>当前心情</state>标注角色心情。
这样写之后，AI 输出的 <state>...</state> 会被状态解析器当作状态数据吞掉，正文里看不到任何内容；同时由于格式不符合状态规则，状态解析也会出错。
✅ 正确做法：用其他非保留的标签名，比如 <mood> 或自定义标签：
请在每条回复开头用
<mood>当前心情</mood>标注角色心情。
然后在正则美化里给 <mood> 配置渲染规则。
2. 自定义标签名与保留标签冲突
❌ 错误做法：在正则美化的「自定义标签」里创建一条规则，让 <world> 渲染成世界观面板。
这会让正则美化和状态解析同时尝试处理 <world>，导致两者都异常。
✅ 正确做法：自定义标签起名时避开本章列出的 7 个保留名。例如想做世界观面板，可以用 <worldview> / <lore> / <setting> 等名字。
3. 让 AI 输出位置错误或嵌套不完整的 <state>
<state> 标签必须满足以下约束：
- 位置：沉浸（world）模式下
<state>...</state>位于整条回复的末尾；深度（advanced）模式下<state>紧跟正文内容之后，<options>块独立于回复内容、压轴在<state>之后 - 闭合：必须有完整的
</state>闭合 - 不嵌套：建议不要在
<state>内部再写一个<state>，也不要把<state>嵌套在<details>、<options>等其他标签里——平台不会对此做强制校验，但嵌套会导致解析异常
如果作者在指令里要求 AI 改变 <state> 的输出位置或格式（比如「请把状态写在开头」），系统会忽略该指令，但 AI 可能因此产生格式错乱，导致整轮 state 失效。
✅ 正确做法：不要在指令中干预 <state> 的输出方式，让系统自己管理。如需让某些数据进入状态系统，配置好对应的属性 / 关系 / 物品字段即可，AI 会自动写入。
另一类会被吞掉的内容：输出清洗
除了上面 7 个状态标签，平台还会在每条 AI 回复入库前做一轮静态清洗。以下内容会被无条件剥离，作者拿它们当自定义标签或提取边界会「静默消失」——正文里什么都不剩，也不会报错：
| 会被剥离的内容 | 说明 |
|---|---|
<disclaimer>…</disclaimer> | 连标签带内容整块删除 |
<Artistic Intent>…</Artistic Intent> | 同上 |
开头的 Storvia： / Storvia: | 只删回复最开头的这个角色前缀 |
\< \> \/ 里的反斜杠 | 部分模型会把标签转义成 \<tag\>，这里统一还原 |
前两个是某些越狱预设强制模型输出的「脱责声明」脚手架，属于纯噪音，平台一律不返回给玩家。
所以自定义标签名除了避开 7 个状态保留名，还要避开 disclaimer 和 Artistic Intent。这两个比状态标签更难排查——状态标签至少会让状态解析出错有迹可循，这两个是彻底无声消失。
在自定义输出格式中如何避坑
如果你希望 AI 输出结构化内容供 SDK 解析（参考 指定输出格式），推荐使用 XML 标签 + 正则提取。起标签名时只需做一件事：
标签名不要落在下面这 9 个名字里： 7 个状态保留名
state/world/player/character/item/relation/custom， 加 2 个会被输出清洗剥离的disclaimer/Artistic Intent。
任何其他名字（<title> / <summary> / <reply> / <choice> / <card> 等）都是安全的。
<attr> 和 <value> 是状态解析器在 <state> 内部使用的子标签。它们只在 state 块里有特殊含义，<state> 块之外同名标签不受影响，可以正常用作自定义标签——但为了阅读清晰，仍建议换个名字。
美化预设标签的边界
平台另外提供了一组 美化预设标签 ——<scenario> / <narration> / <bubble> / <system> / <details> / <options> 等，详见 预设标签。
这些预设标签是给作者使用的，可以在指令中要求 AI 使用，也可以在正则美化里自定义渲染样式。它们和本章的"状态保留标签"用途不同：
| 类型 | 谁来输出 | 作者能否在指令里要求 AI 使用 | 作者能否在正则美化里改样式 |
|---|---|---|---|
| 状态保留标签 | 系统驱动 AI 自动写 | ❌ 不能 | ❌ 不能 |
| 美化预设标签 | AI 在正文中输出 | ✅ 可以 | ✅ 可以 |
| 作者自定义标签 | AI 按指令输出 | ✅ 可以 | ✅ 可以（需正则匹配） |
不确定某个标签名是否安全？只要不在本章列出的 9 个名字（7 个状态保留名 + disclaimer / Artistic Intent）里，就可以放心使用。