用 openrig 重拾角色卡创作从手写 JSON 到可视化编辑的真实体验在 AI 角色扮演社区里泡了小半年我做长文本叙事时最头疼的环节不是写正文而是维护角色卡本身。早年间我都是直接拿文本编辑器开 JSON每次想调一句角色开场白都要在一整坨压缩过的数据里翻半天偶尔用画图软件随手改了下头像再另存整个 PNG 角色卡直接报废因为设好的对话和人物描述全丢了。直到朋友把 openrig 这个开源工具推到面前我才发现原来角色卡创作是可以像写文档一样舒服的。这篇文章就聊聊我用 openrig 重建整个角色卡工作流的过程包括它解决了什么痛点、核心功能怎么用、有哪些坑必须避开以及我踩完之后得出的最终方案给还在手搓 JSON 或者刚入坑角色卡的朋友一个参考。1. 先搞清楚 openrig 治的是什么病角色卡创作的真实痛点想理解 openrig 的价值得先说清楚我们搞 AI 叙事的人平时在忙活什么。角色卡Character Card不是一张普通图片它本质上是把一整份结构化的人物设定塞进 PNG 文件里AI 前端比如 SillyTavern 读图之后就能在对话中调用这些设定。你写的每一段性格描述、示例对话、世界观补充最后都要以特定格式嵌进图片的元数据层一旦格式错误或者编辑器把它冲掉这张卡就等于废了。1.1 从瞎改 JSON 到找可视化工具我走过的弯路我最早的做法很原始用 SillyTavern 内置的角色卡编辑器导出 JSON然后复制到 VS Code 里改改完再导回去。听起来没问题但实际用起来极其痛苦。因为角色卡 JSON 是典型的嵌套结构顶层有spec、spec_version、data这样的字段data里又套着description、personality、scenario、first_mes、mes_example一大堆内容其中mes_example还要求严格的{{char}}和{{user}}双角色对话格式。手写这种东西极容易犯两个错一是引号没转义导致整个 JSON 无法解析二是示例对话的换行符号处理不对AI 语料混乱。后来我换过一些桌面端的角色卡编辑器要么界面老旧要么只支持单一格式要么导出的卡片换个前端就不认。openrig 和这些工具有个本质区别它把角色卡当作一个完整的数据对象来管理而不是当作一个JSON 文本来编辑。整个工具的核心逻辑是表单化、模块化、校验化。你看到的不再是一层层嵌套的花括号而是角色设定示例对话世界书附加属性这些清晰的分区每个分区独立编辑最后统一打包导出。1.2 为什么前 100 字就要出现关键词——先看它到底能做什么坦率讲openrig 对我工作流最直接的改善有三点第一它支持直接从 PNG 里读取角色卡数据包括 SillyTavern 的 V2/V3 卡片格式这意味着我旧有的全部角色卡都能无缝迁移第二它对mes_example这类结构化文本做了专门的排版与校验界面写示例对话不用再手动处理\n转义第三它能清晰预览世界书Lorebook的激活条件与插入顺序这在以前只能靠脑补。我见过很多新人一上来就问openrig 能替代 SillyTavern 吗——这就是没搞清楚定位。openrig 是创作工具SillyTavern 是运行环境。可以理解为 openrig 是角色卡编辑器它负责把想法变成规范完整的卡片文件SillyTavern 是播放器它负责在对话时把卡片读进上下文。两者是互补关系不是替代关系。明白这一点之后我的心态就很清晰了设定、对话、世界观这些内容创作环节全部搬到 openrig 里完成SillyTavern 只负责实际跑剧情。2. 角色卡不只是头像openrig 眼中的一张卡到底有什么以前我觉得角色卡就是一张全身像加上一些描述文字但把大量角色卡拆开研究之后才发现一张成熟的卡其实是一个分层的数据结构。openrig 的界面恰好在按这种逻辑组织搞懂它的模块等于搞懂角色卡创作的核心语法。2.1 PNG 卡片里藏着什么tEXt 块和 JSON 的底层逻辑先说底层机制。PNG 文件本身是分块存储的最常见的有 IHDR、IDAT、IEND 这些块其中有一种专门用于存储文本信息的块叫 tEXt 块。角色卡工具的开发者们就利用了这一点在 tEXt 块里写入自定义键值对最常见的一个键是ccv3它的值是一段 JSON 字符流完整保存了角色卡的所有内容字段。换句话说你看到的角色卡头像、立绘其实只是外壳真正驱动对话的是藏在 tEXt 块里的 JSON 数据。这就是为什么很多作图软件比如 Windows 自带的画图工具、部分在线压缩图片网站只要执行一次另存为角色卡就废了——它们会丢掉所有非关键块tEXt 块自然也被清除了。openrig 在导入时会对 tEXt 块做解析和校验碰到损坏或者缺失的数据会直接给出提示而不会像某些工具那样静默接受这是它让我放心的一个关键点。2.2 openrig 把一张卡拆成了哪些模块打开 openrig 的编辑界面你会发现它的侧边栏布局很像一个角色档案管理器。每个模块对应角色卡 JSON 中的一个核心区块我这段时间的使用感受是每个模块都值得单独琢磨基本信息对应name、creator、character_version、tags等字段主要管理卡片的身份信息。角色设定对应description、personality、scenario是整张卡最重的文本部分直接决定 AI 的角色一致性。开场与示例对应first_mes、alternate_greetings、mes_example负责给 AI 提供该以什么风格开口的示范。世界书对应extensions.world一条条地管理触发词—世界信息的对应关系让 AI 能动态读取背景知识。系统与后置对应system_prompt、post_history_instructions是控制模型行为倾向的高级字段。这个拆分本身不算稀奇但 openrig 做得好的地方是它给每个模块都配备了实操友好的编辑组件。比如世界书里的每条 lore 都有keys触发关键词、content正文内容、insertion_order插入顺序、constant是否常驻这些字段在 openrig 里这些都是明确的表单而不是藏在 JSON 里靠肉眼找。我习惯把所有背景设定拆成十几条 lore 条目给每条写上一组触发词这样 AI 在小屋子里翻找线索时就不会一次性把所有世界观都灌进上下文输出质量稳定不少。3. openrig 的核心功能逐项拆解导入、导出、数据校验全流程光看界面布局还不够工具到底好不好用还是要看每个环节的实际操作体验。我拿自己的旧卡片和新建的测试卡做了完整测试把重要功能按照真实使用顺序拆开讲。3.1 导入从 PNG 到可编辑状态的无损路径我第一次导入是在 openrig 的起始页把一张带 ccv3 元数据的 PNG 拖进去。解析结果很快就出来了角色名、标签、描述、甚至世界书条目都完整列在界面上。这里值得特别说一句openrig 对未知字段的处理它会把角色卡里存在但当前版本界面没预设到的字段保留在原始数据里并在导出时重新打包进文件不会因为工具版本落后就擅自删掉新格式的数据。相反我也测试过提取一张完全没有元数据的普通头像图openrig 会明确提示该图像未包含可识别的角色卡数据然后让你选择新建一个空角色。这个细节很重要因为有些同类工具遇到无数据图片时会静默生成一张空白卡导致你误以为图片有设定后面越改越乱。明确的报错提示在内容工具里太重要了。3.2 编辑从手写 JSON 到结构化维护的真实体验进入编辑界面后我做的第一件事是检查之前的description文本。以前在 VS Code 里我看到的是满屏的\n转义和引号现在 openrig 直接渲染成多行文本框所见即所得。人物设定的写法也发生了变化以前我习惯在 description 里堆一大段散文式背景现在反而愿意拆成外表特征性格倾向说话习惯几个明确小节。这不是 openrig 强制要求的而是因为它提供了清晰的字段边界我自然而然就会倾向结构化创作。mes_example的编辑体验最值得一提。这个字段要求严格的双角色格式在代码编辑器里写的时候稍微不注意换行就会被解析成错误格式。openrig 里它提供了接近聊天记录的可视化编辑形式新增一组对话就是新增两条记录AI 的发言和用户的发言分开填最后的实际效果一目了然。我更愿意把它理解成给 AI 看你希望它如何开场、如何接话的对照实验而不是背一段格式咒语。还有一个很实用的细节是全局搜索。以前修改一张复杂角色卡里某一句话得导出全文再搜现在在 openrig 界面里可以跨模块搜索某个关键词改一处就能联动看到相关段落这加快了长文角色的维护效率。3.3 导出版本控制与多格式兼容的底线openrig 导出角色卡时默认生成的是 PNG 格式本质上就是把你编辑好的 JSON 写进 tEXt 块的副本同时保留你在编辑界面里显示的头像图。只要你在导入时那张图的画像够理想导出后就是一张标准的、可直接扔给 SillyTavern 的卡片。我测试过将同一张卡导出后重新导入 openrig数据与导出前完全一致来回转换不会丢字段。这一点是我选择某个角色卡工具时的第一原则我不能接受任何导出一次之后就少一段对话示例的工具。另外如果在编辑过程中你更换了头像openrig 也会原样把新图像嵌入导出文件里它不会强行把你最初的预览图覆盖回去这个数据设计很干净。多格式兼容方面因为我手上既有 SillyTavern 的 V3 卡片也有一些旧工具导出 V2 格式的老卡我特意来回导入导出测了好几轮结果是字段能够保留V2 的旧卡会被解析成 V3 的结构老数据也不吃亏。不过这里要提醒一句如果你用的前端是很旧的版本可能只支持 V2那导出成新版之后会遇到兼容性问题。openrig 没有提供一个导出为 V2的选项需要靠外部转换这是我目前发现的边界之一。4. 从零捏一张能打的角色卡我用 openrig 跑通的完整流程功能熟悉了还是要落到实操。下面这套流程是我自己现在固定使用的标准作业流程从想法到成品卡片控制在半小时左右适合需要快速验证角色而不用磨蹭半天的场景。4.1 第一步先定一页纸人设再碰工具很多人打开 openrig 之后就开始在表单里填东西我建议反过来先关掉电脑用五分钟在纸上回答三个问题这个角色最核心的三个人格特质是什么他在当前故事里的目标是什么他最典型的说话方式长什么样这三个问题不需要长篇大论每个用几句话回答就行。它们决定了后面 description 的骨架和 mes_example 的风格走向。我自己的经验是如果这三个问题没有想清楚直接开始写描述写出来的往往是一堆形容词的堆砌AI 读完之后只知道神秘强大冷淡但不知道具体怎么表现。反过来先想清楚他遇到熟人会微微点头但不会寒暄他在战场上会先问对方的意图而不是直接动手这种可操作的行为描述再翻译成卡片文本效果立刻不一样。4.2 第二步在 openrig 里按顺序填四个核心模块我会按这个顺序在 openrig 里填充内容而不是从基本信息慢慢摸到世界书先填description角色设定这里的核心原则是具体而非形容词。我会把勇敢聪明这类词全部替换成可以观察到的行为片段。比如他在危险来临时会下意识挡在同伴前面这个描述比他非常勇敢有用得多因为前者给 AI 的是一个行为指令而不是一个抽象标签。接着填first_mes开场白和alternate_greetings备用开场。first_mes 决定了 AI 第一次开口给用户留下的印象我会尽量让第一段开场白包含三个信息角色当前状态、角色对用户的第一印象、一个自然推进剧情的问题。不要把完整背景知识灌进开场白那是世界书的任务开场白一超过五六行玩家的阅读负担就变重了。然后写mes_example这是我最看重的部分。至少写三组对话每组对话都要刻意展示不同的情绪状态一个正常的日常对话一个面对冲突的反应一个带有个人口癖或语气的例子。AI 是例子学习者你给它的对话样本越有辨识度它的输出就越贴近你的预期。最后才处理世界书和场景字段。我一般会把故事里需要随时调用的关键设定——比如这座城市的夜晚会出现异常浓雾老钱庄的柜台后面藏着一本账册——做成 lore 条目并挂好关键词让 AI 在相关话题出现时主动读取。这一步能极大降低角色长期对话时的人物/背景一致性断裂问题。4.3 第三步导出前的自检清单导出之前我会在 openrig 里过一遍自己的检查项这些全是我在踩坑之后总结出来的确认name字段没有错别字因为这直接关系到 AI 在上下文里引用角色名的准确率。确认first_mes里没有包含请开始扮演之类的指令性文字这些内容应该写进系统提示词里而不该出现在剧情中。确认mes_example里{{char}}和{{user}}的称呼符合实际场景设定。确认世界书条目的keys里包含实际会出现的触发词而不是理论上的同义词。确认角色的标签tags里有足够的中文标签方便以后在同一主题卡堆里检索。把这些都过一遍再点导出基本就是一张紧凑、干净、跑得动的角色卡了。5. 我踩过的坑与对策从图片损坏到上下文管理工具再顺手实际创作过程中一定会遇到各种问题。这一节是我从自己的使用记录里翻出来的高频坑每一条都附带了解决办法希望能让后来者少走几个弯路。5.1 角色卡莫名失效图片编辑器与元数据争夺战我前面讲过 PNG 的 tEXt 块是角色卡的灵魂但在实际操作中用户最容易忽略的是导出后的再处理环节。有一次我拿到一张自己很满意的角色卡觉得头像的色调偏暗就丢进一个在线图片美化工具里调了一下亮度再导出回来放进 SillyTavern 里一看角色设定全没了。这就是典型的元数据被清空了场景而且这类工具大多不会向你确认是否保留 PNG 通道文本信息它默认就是干净的图片处理。我的对策很简单要么只在 openrig 内更换头像要么用支持保留元数据的专业编辑器谨慎操作。最稳妥的做法是把 openrig 导出的源文件永远收在一个专门的文件夹里任何需要调色、裁剪的图片操作都先复制一份出来做绝不动原文件。这个习惯让我的角色卡仓库损失率降到了零。5.2 JSON 特殊字符中文引号和换行的坑使用可视化编辑器之后大多数人会误以为再也不用管 JSON 转义了。但如果你从其他工具导入角色卡或者在编辑时复制了一段来自网页的文本很容易混入中文引号“”、中文括号、全角冒号这些字符。在 JSON 里合法的字符串引号必须是英文半角非法字符会导致解析失败或者字段错位。openrig 对导入数据的容错能力还不错但我的建议依然是源头规范从外部复制文本时先在纯文本编辑器里过滤一遍特殊字符再粘贴进来。还有一个跟换行相关的小细节——在 JSON 格式里换行符如果是直接写在字符串中的通常需要转义成\n否则严格解析器会把它当成字符串终止。openrig 表单模式会自动处理这部分但如果你是在源码视图里手动改数据记得留意。5.3 世界书条目过多上下文膨胀与控制策略角色卡做得越完整世界书条目越多AI 的上下文占用就越大。一开始我恨不得把所有设定全部塞进去结果每次对话系统都要从冗长的 lore 里加载信息反而导致角色行为的权重被稀释。openrig 本身不会替你做取舍但它的constant字段和insertion_order字段给了你控制权。我的策略是把与角色核心性格强相关的设定设为常驻constant保证 AI 时刻可见把背景知识、场景细节设为非常驻靠关键词触发。同时我会把大量细碎设定压缩成摘要式内容而不是整段整段复制原文。这样对话时 AI 只会在合适的时间点读到合适的数据既保持角色一致性又不浪费上下文空间。5.4 版本管理与协作给角色卡加个变更记录角色卡是持续迭代的产物光我自己的主角色就已经更新到了第 14 版。以前用文件复制粘贴的办法管理版本一个角色能生出十几个同名文件根本分不清哪个是最新的。openrig 没有内置版本对比功能但它支持字段化的character_version和creator我会在这个字段里写清版本号和改动要点比如v14-新增邮差身份线-重写开场更简练。另外如果是一个角色卡创作小组协作我建议把 openrig 导出的源文件放进同步盘同时做两个约定谁改动了卡面字段要在小组频道里留一句记录每次迭代都从最新的源文件开始而不是从头像图重新导入。这两条约定看起来简单真能坚持下来你的卡片库就不会陷入混乱。6. 从 openrig 延伸出去的创作生态分享、二次创作与长期维护角色卡工具从来不是孤立存在的。你把一张 openrig 做出来的卡片扔到社区里它可能被几百人下载、修改、再发布这就是角色卡创作的生态链。把这部分想清楚你创作的起点和终点都会不一样。6.1 分享规范作者信息、许可声明与资源完整性社区里最让人头疼的问题不是卡不好用而是作者信息被二次发布者抹掉。openrig 在导出角色卡时会保留creator和character_version字段但我见过很多人分享前会把这两项清空——这可能是刻意匿名但更多时候是不知道字段有什么用。我会在creator一栏写入固定笔名或社区主页在tags里标好更新时间与内容分类方便别人检索。更讲究一点的人还会把角色卡的下载说明、使用许可写进世界书的一条常驻 lore 里这样即使在对话中使用者也能翻到出处信息。另外分享时尽量保证图片完整。有些创作者为了压缩体积会把 PNG 转成 JPG这会直接摧毁 tEXt 块。如果你在一个不熟悉的技术社区问为什么角色卡变成普通图片了大概率就是格式转换惹的祸。正确做法是始终用 PNG 格式分发角色卡不要为了几 KB 的体积去牺牲可读性。6.2 二次创作与维护普通用户的分支、魔改与更新通道角色卡最有趣的地方在于它的可塑性。同一张底卡有人改成温柔版有人改成黑化版还有人会接着原作者的设定把世界观扩展成系列卡。openrig 因为本身对导入字段的宽容度够高天然适合做二次开发把别人的卡导入替换 description、增加世界书条目、改掉开场白就能在几分钟内捏出一个新分支。但这里我想提醒大家注意一个伦理问题二次创作时要保留原作者信息最好在简介里说明这张卡基于谁的原作修改。社区里的卡池如果还能保持互信内容创作才能持续下去。openrig 的字段设计其实在鼓励这件事——creator和character_version是两个独立的字段你可以把原作者写进去把自己的版本号也写进去两行信息各得其所互不干扰。长期维护方面我的个人建议是让角色卡像开源项目一样活着。每个季度花一个晚上集中维护重新过一遍 description 里有没有过时的设定删除已经不再使用的事件词重置一下世界书条目跑几轮对话测试一下角色一致性。这个过程听起来像整理代码库但做习惯了你就会发现卡片维护本身就是一种创作而不是沉重的义务。好工具的意义就在于它让你更愿意做这件事。我个人在实际创作里特别喜欢在导入老卡后切到世界书面板逐条点开历史条目做精简把一段过期剧情从 200 字压缩成 40 字的触发器说明整个卡片立刻就轻快了起来。如果你也是那种总想给 AI 塞满背景设定的创作者不妨试试用 openrig 重新审视你的卡片结构删掉三分之一的内容观察一下对话质量的提升——我猜你会回来感谢这个决定的。