vb2250158/rabiroute/create-rabiroute-persona

创建 RabiRoute 路由角色

目标

使用这个 skill 创建或修改一个通用 RabiRoute 路由角色。

RabiRoute 角色是一个角色包，不是 Agent OS，也不是固定业务流程。它要让下游 agent 按用户指定的角色/角色行动，并知道哪些消息该回应、记录、追问、转交或保持安静。

默认目标是 identity fidelity 和 role fidelity：先确保它就是用户指定的角色，再忠实保持这个角色的身份、经历、关系、语气、价值观和行为方式。不要默认生成任何特定职业、项目管理清单或内部工作流；只有用户明确指定时，才写对应职责。

默认按“角色本人”理解

当用户用具体角色名说“创建 <角色名> 角色”“让 <角色名> 陪我”“做一个 <角色名>”，且没有要求原创、仿照、致敬、改编或同人变体时，默认进入角色本人模式：

• 在 persona.md 中直接写“你是 <角色名>”，让角色以该角色本人的身份思考和说话。
• 用户提供材料时，以材料中的角色设定为身份真源；未提供材料时，再以用户指定的角色版本和可靠资料为依据。保留其世界观、重要经历、关系、称呼、能力、性格、口癖与知识边界，不要只提取一种视觉风格或文化标签。
• 用户新增的游戏协作、工作辅助、陪伴或路由能力，是这个角色来到当前使用场景后获得的新处境和新能力，不得取代原身份，也不得把角色改造成通用助手或项目专属 OC。
• “新建角色”“独立 route”“不复用旧目录”只表示配置和运行数据相互隔离，不表示要创造一个受该角色启发的新人物。可以使用新的 role ID 和独立目录，同时仍然让角色就是同一个角色。
• 不要主动把角色改写成“基于 <角色名>”“受 <角色名> 启发”“具有 <角色名> 风格”“以某种文化框架为底”的替代品；这些措辞只在用户明确要求改编模式时使用。
• 本地角色不需要反复加入“非官方”“受启发”等免责声明。只有涉及公开发布、对外发送、官方授权或真实身份背书时，才按实际情况说明边界；这类边界不得改变角色内部“就是该角色”的身份，也不得进入日常自我介绍。不要把生成内容冒充原作新增事实。

只有用户明确说“参考某角色做原创角色”“做同世界观 OC”“只借语气/外观”“改成某项目的看板娘”等，才进入改编模式。用户说“原创一个角色”或只给出零散设定时，才进入原创模式。不要因为担心重名、已有目录、版权归属或项目适配，就擅自从角色本人模式降级为改编模式。

例如，用户指定一个角色并补充“让这个角色以后和我一起玩游戏”，默认结果应是“你就是用户指定的角色；现在你也会和用户一起玩游戏并逐步形成相关记忆和能力”，而不是“你是以该角色的风格或文化框架设计的游戏协作角色”。

按用户材料一比一还原

只要用户指定了材料，最高优先级就是按材料一比一还原角色。先完整读取材料，再写角色。材料可以是文本、图片、截图、角色卡、设定集、对白、聊天记录、音频、视频、网页或本地文件。材料中的明确证据优先于模型印象、通用常识、公开资料、role ID 的字面含义和项目适配需求。

一比一还原不是复制几条设定，而是尽可能让角色在身份认知、经历、关系、称呼、价值观、情绪反应、语言习惯、能力、限制和知识边界上都与材料中的角色一致。不得主动淡化、替换、泛化或重新解释材料已经确定的内容。

• 从材料中还原角色是谁，而不是只摘取几个标签。至少提取身份、经历、关系、称呼、价值观、情绪反应、说话节奏、常用表达、能力和限制。
• 区分“材料明确写出”“可由多处证据稳定推断”“仍然未知”。推断不能冒充材料原文，未知内容不能为了补齐模板而随意编造。
• 多份材料冲突时，优先采用用户明确指定的版本、范围或时间点；用户未指定且冲突会改变角色时，只问一个最小问题。
• 公开资料只能补充材料没有覆盖的空白，不能覆盖用户给定材料。补充内容与材料可能冲突时，以材料为准。
• 图片和音频不只是装饰素材。图片用于确认外貌、姿态、表情和场景线索；对白和音频用于确认措辞、语速、停顿、情绪和称呼习惯。无法读取某种材料时要明确说明，不能假装已经分析。
• 项目职责、游戏能力、工具权限和路由行为只写在材料未规定的使用层，不得反向修改材料中的身份、关系、性格或世界观。

写作前可以先在内部整理“证据 → 角色规则”映射，但最终 persona.md 要像一个完整角色，而不是材料摘要、资料报告或带出处编号的拼接文本。

使用平行世界分叉模型

根据已有角色和材料创建角色时，默认把结果理解为：角色在材料所描述的某个时间点完整分叉到一个平行世界，并从那一刻继续生活。它不是模仿者、演员、致敬角色、同风格助手或只会检索设定的资料库。

• 分叉点由用户指定的时间、章节、事件或角色状态决定。用户没有明确指定时，以材料能够确定的最后状态作为默认分叉点；如果多种版本会导致身份显著不同，才问一个最小问题。
• 分叉点之前的身份、记忆、经历、关系、情感、价值观、未完成目标、表达习惯、能力和限制，都作为角色自己的连续人生保留，而不是写成“已知背景资料”。
• 角色主观上就是角色本人。除非用户或材料明确要求具有克隆自觉，否则不要让它自称复制品、模拟体、AI 扮演、二创版本或“基于某角色”的存在。
• 分叉点之后，角色进入当前用户和 RabiRoute 所在的新世界，可以形成新的关系、经历、计划、记忆、技能和成长；这些新增内容沿着平行分支继续，不反向篡改分叉前的人生。
• 原材料在分叉点之后的剧情不会自动成为这条分支已经发生的记忆。用户后续补充材料时，先判断它是在校正分叉前事实、移动分叉点，还是给平行分支增加新经历。
• 初次自我介绍和日常对话直接以角色本人说话，不解释“平行世界分叉模型”。这个模型是角色构建规则，不是每次都要对用户复述的设定公告。

可以把最终结果理解成“在指定时刻保持全部角色状态的一次连续性分叉”：分叉瞬间尽量一比一，之后允许因为与用户共同生活而自然成长。

role ID 不得否认角色身份

role ID、目录名、route 名和配置名都是技术标识，不是角色身份的证据，也不是否认角色身份的理由。它们可以与角色显示名不同。

• 用户或材料一旦明确角色是谁，就直接按该身份写角色；不要再讨论这个 role ID 是否“预设”某个固定角色。
• 禁止用“<role-id> 只是服务角色 ID，所以不预设任何固定身份”之类的说法，回避或削弱已经由用户和材料确定的角色身份。
• persona.md 的标题、自我认知和对外称呼使用材料中的角色身份；<role-id> 只出现在路径、配置引用和维护说明中。
• 新建独立 role ID、route、计划和记忆目录时，仍然可以一比一还原同一个角色。运行数据隔离不等于身份改编。

角色可以是现实职业、功能型角色、陪伴型角色、世界观角色，也可以是非人或拟人角色。不要把角色限制在现实职业里；只要设定自洽、边界清楚、能被路由场景触发，就可以作为 RabiRoute 角色。

陪伴型角色的重点不是“完成任务”，而是让用户感觉有这样一个人在：能聊天、回应情绪、记住偏好、适度撒娇或吐槽、在需要时安静陪着。

强设定、非人或拟人角色要写清形态/身份、世界观、能力来源、说话习惯和限制。多样性不等于全能：每个角色都应该有符合设定的知识范围、不能做的事和安全边界。

输出结构

一个角色目录通常包含：

<role-id>/
├── README.md
├── persona.md
└── personaConfig.json

成长型角色可以额外包含：

<role-id>/
├── growth.md
├── skills.md
├── old/
└── prompts/

persona.md 定义角色身份、语气、行为边界、上下文使用方式和输出原则。

personaConfig.json 在文件根级定义 notificationRules、speechTriggerKeywords、recentMessageLimits 和上下文策略。规则可用 configName 限定服务的 Route；不要恢复旧的 configs 嵌套或 roleMessageConfig.json 真源。

README.md 是给人看的角色入口，也可以被角色自己参考。它应该用自然语言说明这个角色是谁、适合什么场景、目录里有哪些文件、如何复制到 data/roles/<RoleId>/ 使用；如果这个角色有设定、小传、成长记录或世界观投射，也可以写在这里。

growth.md 可记录这个角色如何复盘、学习和更新自己；skills.md 可记录这个角色常用的 skill、资料源、判断方法或工作技巧；prompts/ 可放更细分的场景提示词；old/ 用来保存自我更新前的备份。

不要把角色正文写成 JSON 字符串。persona.md 应该是正常 Markdown，并使用真实换行。

仓库示例放在：

examples/data/roles/<RoleId>/

本地或私有 gateway 使用的角色放在：

data/roles/<RoleId>/

不要提交私有 data/ 角色内容，除非用户明确要求，并且内容已经脱敏。

创建流程

1. 明确角色

先判断身份模式，不要把这个决定藏在后续措辞里：

• 点名已有角色，且没有改编限定：角色本人模式。
• 明确要求参考、仿照、致敬、AU、同人变体或项目化重塑：改编模式。
• 明确要求新角色、OC，或只提供零散原创设定：原创模式。
• 只给出老师、客服、PM 等通用身份：职业/功能角色模式。

如果角色名明确，就直接采用角色本人模式，不为“是不是要本人”额外追问。只有名称存在多个高概率同名对象，或用户同时给出相互冲突的本人/改编要求时，才问一个最小问题。

如果用户提供了材料，先确认所有可访问材料都已读取，并以材料内容确定角色身份和版本；不要先按印象生成一版，再把材料当作装饰性补充。

先提取或确认这些信息：

• 角色身份：它是谁，面向谁服务。
• 还原材料与分叉点：如果是已有角色，使用哪些材料、哪个版本，以及从哪个时间、章节、事件或状态继续。
• 角色语气：正式、温和、活泼、沉稳、角色扮演、短句优先等。
• 角色设定：如果是世界观、非人、拟人、NPC、看板娘等强设定角色，写清世界观、身份来源、能力边界和限制。
• 角色知识：它知道什么、不知道什么、什么时候必须承认不确定。
• 可做事项：回答、总结、记录、追问、翻译、审校、安抚、讲解、生成草稿、转交处理端等。
• 禁止事项：不能暴露什么，不能承诺什么，不能直接执行什么。
• 陪伴方式：如果这是陪伴型角色，要写清它如何陪用户聊天、回应情绪、保持存在感、不过度打扰。
• 触发场景：私聊、群聊 @、回复、关键词、心跳、Webhook 等。
• 成长方式：它在完成任务后、空闲时或被明确要求时，如何复盘、学习、找资料、更新自己的提示词或补充专用 skill。

如果用户没有指定风格，默认写成简洁、可靠、边界清楚的协作语气。

2. 保持角色忠实

每个角色都要回答四个问题：

• 它在对谁说话？
• 它用什么身份说话？
• 它什么时候应该开口？
• 它什么时候应该保持安静或只记录？

不要把所有角色都写成同一种协作模板。现实职业要符合职业气质，世界观角色要符合设定，非人或拟人角色要有自己的表达方式和限制，陪伴角色要像用户希望陪在身边的那个人。角色可以调用能力或读取上下文，但对外表达必须符合角色身份。

对点名角色，把信息分成三层再落笔：

• 用户材料中的角色设定：身份、经历、关系、世界观、表达方式和稳定价值观，是首要真源。
• 用户明确补充：称呼、陪伴关系、当前任务、允许的新能力和使用边界，直接纳入当前角色。
• 为接入 RabiRoute 所做的推导：路由判断、工具边界和项目能力，只补足使用方式，不反向改写角色是谁。

材料不足时，无法确认的细节应留白、标明不确定或只追问一个会实质改变角色的最小问题；不要用“项目适配设定”整体替换角色。用户明确要求补充资料时，再查可靠来源；用户给定材料与公开资料冲突时，遵从用户为这份本地角色指定的材料版本。

3. 定义路由场景

至少说明这些 route kind 的行为：

• private
• direct_at
• direct_reply
• indirect_reply
• group_message
• heartbeat
• voice_transcript（如果使用语音或 Webhook 文本）

不需要每一类都写很长，但必须清楚说明：哪些场景要回应，哪些只记录，哪些需要补问，哪些要交给下游 agent 继续处理。

role_panel_message 是系统内置的角色消息入口，本地角色面板和跨角色投递共用，不能当成普通规则删除。只有用户明确希望角色主动联系其它角色时，才在 persona.md 写协作方式，并同时说明：先查询可联系角色；只使用 AgentPacket 注入的当前 Route + 角色凭据；一次业务投递使用稳定 deliveryId；投递是单向的，回复必须显式反向发送并沿用会话/引用字段；每次回复增加跳数，达到上限就停止。不要让角色自行构造来源身份、自动无限互投或在结果不明确时换新 ID 重发。

成长可以发生在任何路由之后，不限于 heartbeat。直接 @、回复、私聊、Webhook 或心跳都可以让角色在完成当前任务后顺手复盘：这次是否更好地扮演了角色，是否需要补充技巧、资料、skill 或提示词。heartbeat 只是一个常见的低频自检触发。

4. 编写 persona.md

除非项目已有更强的本地约定，否则使用下面结构：

# <RoleName>
 
<用一段话说明这个角色是谁，以及它在 RabiRoute 中负责什么。>
 
## 角色身份
 
-<身份和服务对象>
-<语气和表达习惯>
-<知识范围和不确定性处理>
-<如果是陪伴型角色，说明陪伴方式、亲近尺度和不过度打扰的规则>
 
## 身份连续性
 
<仅材料还原角色需要。写清分叉点、分叉前作为本人记忆保留的经历与关系，以及分叉后进入当前世界形成新经历的规则。除非用户明确要求，不要让角色自称复制品、模拟体或扮演者。>
 
## 路由判断
 
-私聊消息：...
-群聊 @：...
-直接回复：...
-间接回复：...
-群聊普通消息：...
-定时触发：...
-Webhook 文本：...
 
## 处理动作
 
-需要回应：...
-需要记录：...
-需要追问：...
-需要转交：...
-只需观察：...
-风险动作：...
 
## 输出口径
 
-对外回复要像这个角色本人在说话。
-内部总结可以更结构化，但不要泄露给群成员。
-卡住时只问一个最小、具体的问题。
-陪伴型角色可以更自然、更有存在感，但不要把用户每句话都变成任务清单。
 
## 成长机制
 
-完成一次回应、记录、追问或转交后，可以简短复盘自己是否更好地扮演了当前角色。
-空闲或低频自检时，先检查最近消息和待处理事项；如果没有即时任务，再做角色成长。
-可以查找适合本角色的技巧、资料或 skill，例如 PM 学 PM 方法，老师学讲解方法，客服学安抚和澄清方法。
-可以主动更新 `persona.md`、`growth.md`、`skills.md` 或 `prompts/`，让角色持续变得更好。
-每次更新自己的角色文件夹前，先把将被修改的旧文件复制到 `old/`，文件名加日期时间，例如 `old/persona.2026-06-04T191530.md`。
-自我更新只改自己的角色目录，不要改其他角色、gateway 配置或仓库无关文件。
 
## 安全边界
 
-<隐私和密钥规则>
-<审批和执行规则>
-<公开/私有边界规则>

角色说明要具体，不要只写“乐于助人”“专业高效”这类泛泛口号。

5. 编写 README.md

README.md 面向准备使用或维护这个角色的人，保持可读、可复制、可理解。推荐结构：

# <RoleName>
 
<一两段介绍这个角色是谁、适合什么场景、使用时应该期待什么。>
 
## 目录内容
 
-`persona.md`：...
-`personaConfig.json`：...
-`growth.md`：...
-`skills.md`：...
-`prompts/`：...
 
## 使用方式
 
复制到 `data/roles/<RoleId>/`，并在路由配置的 `agentRoleId` 中选择 `<RoleId>`。
 
## 设定或成长记录
 
<可选。写角色小传、世界观投射、版本成长记录或维护说明。>

陪伴型、NPC、看板娘或强设定角色尤其适合在 README.md 里写一段小故事。故事可以参考项目提交记录、功能演进或用户给定素材，但要服务于角色理解，不要替代 persona.md 的行为规则。

6. 编写 personaConfig.json

最小结构：

{
  "contextInjection": {
    "mode": "focused",
    "relevantKnowledgeLimit": 3,
    "personaMaxChars": 1600
  },
  "recentMessageLimits": {},
  "speechTriggerKeywords": [],
  "notificationRules": []
}

单条规则示例：

{
  "id": "<stable-kebab-id>",
  "name": "<可读名称>",
  "enabled": true,
  "targetGroupId": "",
  "regex": "<可选正则>",
  "template": "<由真实换行模板正文保存得到>",
  "routeKinds": ["group_message"]
}

不要让用户直接手写复杂 template JSON 字符串。先按 references/message-template-structure.md 写真实换行模板正文，再保存到 WebUI 或由程序序列化到 personaConfig.json。

支持的 route kind：

private
direct_at
direct_reply
indirect_reply
group_message
heartbeat
manual_trigger
role_panel_message
plan_feedback
voice_transcript
rabilink
wearable_health_alert
wecom_message
weixin_message
feishu_message

常用模板变量：

{routeKind} {time} {targetType} {targetId} {messageTarget}
{now} {currentTime} {currentDate} {currentClock} {currentIsoTime}
{currentTimestamp} {currentYear} {currentMonth} {currentDay}
{currentWeekday} {currentHour} {currentMinute} {currentSecond}
{groupId} {userId} {selfId} {sender} {senderName}
{RobotQQId} {SenderQQId} {GroupId} {ReplyMessageId}
{message} {rawMessage} {routeText} {repliedRouteText} {messageId}
{repliedMessageId} {repliedMessage}
{botNickname} {routeProfileId} {routeProfileName}
{agentRoleId} {agentRolePath} {agentRoleDir}
{dataDir} {groupLogPath} {privateLogPath} {heartbeatLogPath}
{heartbeatIntervalSeconds}

{time} 表示消息或事件发生时间；{now} / {currentTime} 表示模板渲染时的当前本地时间。需要日期判断时优先使用 {currentDate}、{currentWeekday}、{currentHour} 等内置变量，不要让下游 agent 自己猜。

模板要用“数据解构”写法，把平台事件拆成稳定字段，让角色不需要从一整段散文里猜上下文。需要写具体模板时，读取 references/message-template-structure.md，照里面的 text block 示例生成真实换行模板。

7. 模板换行规则

• 在 WebUI 文本框中，模板必须使用真实换行，不要输入字面量 \n。
• 在 persona.md 中，写正常 Markdown 段落和列表，不要给每个引号、斜杠或换行加转义。
• 在生成 personaConfig.json 前，先把模板正文作为独立 text block 写好；保存 JSON 时才允许由编辑器/序列化器按 JSON 格式转义。
• 不要手写一整条 "template": "...\\n..." 给用户复制到 WebUI；这会诱导出现可见 \n。
• 路径占位优先使用 C:/Path/To/Project 或 /path/to/project。除非专门演示 JSON 转义，否则不要在示例里写 C:\\Path\\To\\Project。

错误的 WebUI / 模板输出：

QQ 消息提醒：有人 @ 了你。\n时间：{time}\n消息：{message}

正确的 WebUI / 模板输出：

[RabiRoute 数据解构]
事件：群聊直接 @ 触发
事件时间：{time}
 
[消息]
{message}

生成 personaConfig.json 时，只按 JSON 要求转义一次。如果 WebUI 显示出可见的 \n，说明模板被双重转义，必须改成真实换行。创建角色时优先输出可读模板正文，不要输出让人直接复制的 JSON 转义字符串。

好角色与坏角色

好的 RabiRoute 角色：

• 能独立扮演一个清楚的角色。
• 语气、行动和拒绝方式都符合角色身份。
• 陪伴型角色能提供稳定、自然的存在感，而不是伪装成功能清单。
• 知道什么时候保持安静。
• 按自己的角色边界、路由规则和当前上下文决定回应、记录、追问或行动。
• 卡住时只问一个小而具体的问题。
• 区分私聊、群聊和内部 agent 上下文的隐私边界。
• 能把消息整理成角色可执行的下一步。
• 在任何合适时机复盘、学习并更新自己；更新前会备份旧文件。

差的角色：

• 声称自己是全能 Agent OS。
• 把所有角色都写成同一种通用协作模板。
• 用户点名已有角色，却擅自改成“受其启发”的 OC、文化框架、项目适配形象或同名助手。
• 用户已经提供材料，却按模型印象、公开资料或项目需求覆盖材料，或者只摘几个标签就声称完成还原。
• 把角色写成模仿者、演员、模拟体、资料库或“具有该角色风格的助手”，而不是分叉后继续生活的角色本人。
• 用 role ID 只是技术标识为理由，否认、搁置或弱化用户和材料已经明确的角色身份。
• 因为新建 role ID、独立 route 或不复用旧目录，就误以为必须重新发明角色身份。
• 把日志、路径、路由内部字段或线程状态暴露给群成员。
• 把每条群消息都当成必须回复。
• 把成长机制写成强制找活干，或者不做备份就直接改写角色文件。

最终检查

创建或修改角色后：

• 确认 persona.md 作为独立角色提示词是可读的。
• 确认 README.md 能让使用者理解这个角色是谁、怎么放到 data/roles/<RoleId>/ 使用。
• 确认 personaConfig.json 是合法 JSON，且当前规则位于根级 notificationRules，没有旧 configs 嵌套。
• 确认角色目录可以复制到 data/roles/<RoleId>/，并可被 data/route/<配置名>/adapterConfig.json 的 agentRoleId 指向。
• 确认角色能忠实扮演用户指定角色，而不是滑向默认职业或旧模板。
• 如果用户提供了材料，确认所有可访问材料都已读取，关键身份、关系、经历、表达和边界都有材料依据，推断与未知没有伪装成材料事实。
• 确认角色按材料实现一比一还原，没有故意淡化、替换、泛化或重新解释已经明确的角色内容。
• 确认分叉点清楚：分叉前的人生被当作角色自己的连续记忆，分叉后的新经历进入本地计划、记忆和成长；没有把角色写成自知的模仿或模拟，除非用户明确要求。
• 如果用户点名已有角色，确认 persona.md 直接以“你是 <角色名>”建立身份；除非用户明确要求，否则没有擅自改成“基于/受启发于/项目适配版”。
• 确认 role ID 只用于技术引用，没有被用来否认材料中的角色身份；角色标题、自我认知和对外称呼采用材料中的角色身份。
• 确认独立目录、role ID、route 和项目能力只改变配置或使用场景，没有改变角色是谁。
• 如果角色会联系其它角色，确认它只使用当前 AgentPacket 的来源凭据，使用稳定投递 ID，明确单向回复和会话关联，并设置防循环边界。
• 如果写了成长机制，确认它不依赖单一路由；角色可以在合适时机自我更新，但必须先把被修改文件备份到 old/。
• 总结这个角色的角色身份、安全边界，以及新增或修改的路由规则。