V2/V3 酒馆角色卡通常把主要设定放在 data 对象内。你最常接触的不是程序参数，而是决定角色“是谁、在哪里、怎样开口”的文本字段。
{
"spec": "chara_card_v2",
"spec_version": "2.0",
"data": {
"name": "角色名称",
"description": "角色背景与设定",
"first_mes": "新对话开场白",
"tags": ["标签"]
}
}上面只是最小示意，不代表完整角色卡。实际文件还可能包含备选开场、创作者备注、扩展数据和角色世界书。
基础身份与管理字段
name角色名称
酒馆列表和对话中显示的名字。尽量简洁稳定，避免把整段称号都塞进名称。
影响：显示、宏替换、对话称呼creator创作者
记录角色卡作者或发布者。它主要用于署名和来源管理，不直接决定扮演。
影响：归档与来源识别character_version角色版本
作者自定义的卡片版本，如 1.2、重制版。它和 chara_card_v2 的规范版本不是一回事。
影响：更新管理tags标签
题材、关系、风格等分类词。酒馆可能用它筛选角色，但通常不会直接加入提示词。
影响：检索与分类creator_notes创作者备注
作者写给使用者的说明，常包含推荐模型、预设、玩法和授权范围。
影响：使用指导，不一定进入模型上下文决定角色怎样扮演的字段
description角色描述
通常是角色卡的主体：身份、外貌、成长经历、能力、习惯、与用户的关系都可能写在这里。很多模板会把它稳定地放进上下文，所以内容应该明确、有层次，避免互相矛盾。
常见问题：设定太长、重复、同时要求相反行为personality性格
集中描述性格与行为倾向，例如克制、嘴硬、谨慎、好奇。它不是必填；有些作者会把性格完全写进 description。
编辑建议：用可观察的行为描述代替空泛形容词scenario故事场景
说明角色与用户所在的位置、关系、时间和当前事件。它回答“故事从哪里开始”，但不会像开场白那样直接显示为消息。
编辑建议：写清人物关系、地点和当前目标开场白、备选开场与对话示例
first_mes第一条消息 / 开场白
创建新对话时角色主动发出的第一条消息。优秀的开场白会同时给出环境、角色动作、说话语气和用户可以接住的剧情钩子。
直接可见，会强烈影响后续回复风格alternate_greetings备选开场白
同一角色的其他开局。酒馆支持时，可以在新建对话时选择不同场景，不用复制多张角色卡。
数组字段，数量可以是 0mes_example示例对话
用几轮虚拟对话展示角色怎样说话、怎样描写动作、回复多长。示例越贴近实际想要的风格，模型越容易模仿。
注意：示例不是历史聊天记录“你好，你来了。”
缺少地点、关系与可继续的事件。“雨声敲着档案室的窗。她把刚拆开的信压在桌下，抬眼看向迟到的你：‘门锁好了吗？’”
提供环境、动作、关系暗示和回复钩子。系统提示与控制字段
| 字段 | 常见中文名 | 主要用途 | 注意事项 |
|---|---|---|---|
system_prompt | 系统提示 | 给角色附加总体扮演指令 | 实际是否启用取决于酒馆和预设 |
post_history_instructions | 历史后指令 | 放在聊天历史之后的补充要求 | 位置靠后，可能对当前回复影响更直接 |
extensions | 扩展字段 | 保存特定工具或插件的数据 | 不认识的扩展不要随意删除 |
有些预设会忽略角色卡自带的系统提示，有些会把它插入固定位置。遇到“字段里明明有，聊天却不生效”，先检查预设和提示词管理，而不是立刻认定角色卡损坏。
character_book：角色自带世界书
character_book 是跟随角色卡一起分享的世界书。常见条目包含：
- keys
- 触发关键词。聊天中出现相关词时，酒馆可能把条目内容加入上下文。
- content
- 真正插入的背景设定，例如地点说明、人物关系、规则和秘密。
- enabled
- 条目是否启用。关闭的条目通常不会触发。
- insertion_order
- 多个条目同时触发时的顺序或优先级信息。
本站解析结果会显示世界书条目数量，并把条目标题、关键词和内容整理到“角色世界书”折叠区。完整结构仍可在 JSON 中查看。
编辑角色卡字段的四条建议
- 先备份：保留原始 PNG 和导出的 JSON，避免无法恢复。
- 一次只改一类：先改开场或场景，再观察聊天变化，不要同时大改所有字段。
- 减少矛盾而非盲目缩短：有效设定可以长，真正的问题是重复和冲突。
- 不懂的扩展先保留：extensions 可能被特定插件使用，删除后不一定能自动重建。
解析你手上的酒馆角色卡
一边看真实字段，一边对照这份中文说明。
角色卡字段常见问题
哪些字段是必须填写的？+
规范允许的字段很多，但真正决定基础使用体验的通常是 name、description 和 first_mes。空字段可以存在，只是角色信息会更少。
字段越长，角色就越好吗？+
不一定。过长、重复或矛盾的文本会浪费上下文。清晰、一致、与目标玩法相关，比单纯堆字数重要。
JSON 可以直接用记事本修改吗？+
可以，但必须保持合法 JSON 格式，并注意编码、引号和逗号。修改前务必备份；要重新嵌入 PNG，还需要支持写入角色卡数据的工具。