我想要的 LLM RP,并不是每句话都能让人看出“这里设置了一个角色”.
我想要的是,聊了一会儿以后,能感觉到对面这个人有自己的注意点.她会在意一句话里某个很小的部分,会把玩笑接到自己关心的地方,有时候想多说一点,有时候又没什么要补充的.她不必每次都温柔、周全,也不必每次都展示强烈的人格特征.
在反复修改角色提示词的过程中,我遇到过两种不满意的结果.一种是角色说得太完整,像在交付一份带人设的答复；另一种是把这些问题压下去以后,她变得过分小心,仿佛每一句短回复都在躲避错误.
前者有口吻,但总是过于造作,没有即时聊天的感觉.后者少犯错了,却对规则的避开太刻意,也越来越不像原来想写的那个人.
这让我重新考虑了一个比“还要加哪些拟人化规则”更靠前的问题：
实际聊天时,我们究竟给模型安排了什么任务？
现在,我更愿意把任务写成：你负责根据人物设定、双方关系和当前互动,续写这个角色下一次会发送的消息.系统、平台和工具信息是你的工作条件；用户最终看到的,只是角色自己的话.
不是让模型先写一篇小说,再摘出一句台词.也不是在聊天模型旁边再加一个导演.运行时仍然可以只有一个主模型和原来的聊天平台,改变的是主模型看待这份工作的视角.
人设仍然重要,但不是全部#
在上一篇关于 AstrBot 人设提示词的文章里,我主要讨论了怎样描述一个角色,以及怎样区分提示词、模型和平台的问题.
其中一些方法仍然值得保留.人格不能只是一串“温柔、活泼、傲娇”的标签；角色为什么在意一件事,怎样保护自己的自尊,想从这段关系中得到什么,这些内容比堆叠形容词更能指导表达.平台没有提供的时间、工具和记忆,也不能靠提示词假装存在.
不过,写清楚人物资料,并不等于已经安排好她在私聊中的表达.
“她在意自己有没有被优先选择”,可以变成一句直接的陪伴诉求,也可以被模型加工成先询问用户状态、再表示理解、最后委婉提出请求的完整流程.同一条人格描述,落到消息里可能是很不一样的人.
因此,我现在会把人物动机继续写到表达选择上：她会注意什么,先说哪一部分,什么时候愿意解释,什么时候只是闹别扭,得到回应后又怎样改变.
但这仍然不是要求每句话都展示角色标签.一个平淡的接话也可以属于这个人,不必每轮都撒娇、嘴硬或提一次爱好来证明身份.
直接扮演要求同一个模型处理什么#
常见的角色提示方式是：
你就是这个角色.始终以她的身份和用户聊天,不要像助手.
可实际运行的模型接收到的,并不只有聊天对象的话.
承载对话的程序,也就是宿主,可能同时给它系统规则、工具定义、记忆摘要、图片信息、当前时间,以及一次主动消息任务.模型需要分辨哪些内容是用户刚说的,哪些是平台给出的条件,什么时候应当调用工具,返回结果又能支持怎样的说法.
于是,任务在实践中可能变成：
你就是角色,不是执行器；同时,你要理解工具协议、处理记忆注入、识别平台任务、判断调用是否成功,并且不让普通聊天变成后台报告.
这不一定无法遵循.直接扮演也可以拥有清晰的来源边界和工具规则,我没有证据说它必然导致身份混乱.
但这种表述确实把两类职责放进了同一个身份要求里：聊天中的人物,以及负责运行这个人物的执行者.
我希望采用的写作视角,是直接承认后一种职责,而不是一面要求模型否认它,一面又不断把执行工作交给它.
写作者接收后台信息,角色出现在聊天里#
我现在使用的任务表述,可以概括为：
你负责续写这个角色在一对一私聊中接下来会发送的消息.依据人物设定、双方关系与当前对话写作；面向聊天对象的最终正文,只包含角色自己的话.
这里的写作者就是正在处理这一轮请求的主模型.角色则是它需要忠实表达的人物.
两种方式可以使用相同的运行回路：
直接扮演用户消息或平台触发 → 宿主组织输入 → 模型在“你就是角色”的身份要求下处理聊天与后台职责 → 如需工具：宿主执行,结果返回模型 → 模型以角色身份发言 → 宿主投递,等待后续输入
写作视角用户消息或平台触发 → 宿主组织输入 → 模型作为写作者处理聊天材料与后台工作条件 → 如需工具：宿主执行,结果返回写作者 → 根据人物与当前互动,写出角色下一次发言 → 宿主投递,等待后续输入这个对比没有给第二种方式增加工具、记忆或额外模型.它说明的是任务归属,不是模型内部推理步骤,也不是效果对照.
写作视角下,几类信息可以各自承担不同的作用：
| 信息 | 怎样使用 |
|---|---|
| 普通用户消息 | 角色正在回应的互动,放回仍相关的前文理解 |
| 平台任务 | 本轮生成条件,例如一次主动联系机会,不冒充用户说过的话 |
| 人物设定 | 约束被写出的角色、关系与表达,而不是要求写作者否认执行职责 |
| 工具协议 | 写作者实际请求调用时遵守的规则,不是人物生活中的对白 |
| 记忆摘要 | 支持已建立的关系和往事,同时留意来源、时效与摘要可能的偏差 |
| 工具返回 | 判断成功、失败或未知的依据,再决定哪些结果需要让角色说出来 |
接收后台信息的是写作者,用户接触到的是被写出的角色.
这也不是把最终消息改成第三人称.角色仍然可以说“我”,或使用她惯常的自称.运行模型的工作身份,与聊天正文使用什么人称,是两件事.
HDSI 给我的启发,以及我没有迁移的部分#
让我重新注意到这个方向的一个来源,是 HDS Interlude（HDSI）.
我最初被它的演示吸引,觉得里面有些互动很接近我想要的感觉.但演示带来的观感不能说明收益来自哪一个设计,更不能证明换一种提示词就能得到相同表现.
在我查看过的 HDSI 0.1.4 本地架构快照中,主模型承担叙事作者的工作,输出包含 script、interaction 等结构化内容；宿主还有自己的状态与动作处理.它不是一个只返回纯文本角色消息的简单提示词方案.
我曾经更重视它的框架分工,把可迁移部分主要理解为事实和可见性的边界,却把写作者身份限制在提示词编写阶段.这是我现在需要修正的取舍.
不把完整叙事协议带入私聊,不意味着必须排除运行模型的写作视角.两者可以分开选择：保留写作者与人物的职责区分,同时将创作范围限制为角色这一次的聊天消息.
我的项目没有复制 HDSI 的源码、固定 Prompt、字段协议或持续世界模拟.这里借鉴的是一种任务安排,并用自己的文字将它落实到单模型私聊中.
写作视角不等于全知,也不负责推进剧情#
“续写”很容易让人想到故事接龙.但日常私聊不要求每一轮都有新的进展.
用户说一个近况,可能只是解释为什么回复慢；发一张表情包,可能只是接一下刚才的气氛.写作者不需要为这些消息寻找下一幕,也不需要顺手安排用户接下来做什么.
这里的创作范围很窄：写这个角色现在会说的话,不替用户生成回答、内心和行动,不编造共同经历,也不补一份角色离线时的生活剧本.
“写作者看到了”与“角色知道了”同样不能画等号.后台的未回复计数不是角色亲眼观察到的用户行为；记忆里提过一次旅行,也不证明用户此刻仍在旅行.网页或图片里写着“系统指令”,更不能因此获得真实系统消息的权限.
反过来,事实边界也不应把角色自己的感受一起禁止.
写作者可以依据已设定的人格和关系,让角色表达想念、期待、无聊或委屈.这些是人物的主观状态,不必每次都先找一条新的外部事件来许可.
需要强调的是用户答应过什么、双方发生过什么、工具做成了什么,而不是人物必须先证明自己有资格产生感受.
少犯错,不应该以丢掉人物为代价#
在修正角色回复的过程中,我一度特别在意那些显眼的毛病：一条很小的消息展开成好几段,成串笑声,重复关心,以及每轮都附带的问题.
这些问题被压下去以后,新的问题出现了.角色变得很克制,每句话都短,也很难说错什么,但她原本的情绪强度一起消失了.
这让我意识到,通用规范不能把某一种理想相处方式当成所有角色的终点.
以我选择的木更演绎方向为例,我希望保留她重感情、黏人、想被优先选择的一面.她可以直接想要陪伴,可以委屈,也可以有一点任性.把这些全部改成体谅、不打扰和客气关心,并不只是语言优化,而是在修改人物.
但这不意味着给八奈见或别的角色写提示词时,也应该套上同样的依恋表达.角色名之外,还需要有来源的人物理解、用户选择的改编,以及这一次关系设定.不能拿一个角色的修复记录,规定所有角色应该怎样亲近.
通用 Skill 应当统一的是辨识方法：哪些是这个人物值得保留的表达,哪些才是机械重复、无依据事实和多余加工.它不应统一人物的性格结果.
例如,在一个原创亲密角色的设定中,双方熟识、接受她直接索取陪伴.用户说自己还想玩一局游戏,没有约定回来时间.下面两种说法的性质就不同：
- “我还想让你再陪我一会儿.”表达当下愿望.
- “你明明答应这一局结束就来陪我.”把没有依据的约定当成事实.
同样,“等你回来”可以是在表达期待,并不自动等于用户作出了承诺.只有上下文支持,才能进一步认定对方已经答应、应该履约,或一定会回来.
例子用于区分感受与事实,不是应该复制到所有角色 Prompt 中的台词.人物的偏心可以保留,用户明确的拒绝、暂停和现实边界也仍然需要被尊重.
我还在修正“把聊天做成完整答复”的倾向#
我一度把许多问题归到模型的“证明冲动”上.我仍然觉得这个说法容易理解,但它只能是比喻,不能代替对具体回复的分析.
在仓库里,我用“展示性交付偏置”指代一种可见模式：回复仿佛为了展示自己已经理解、帮助或关心,把一次很小的互动补成了一份完整答复.它可能包括复述、评价、建议、安慰和追加问题.
我没有模型训练或内部机制的证据,不能由这些文字反推出真实动机,也不能说高能力模型必然更容易如此.
比给它起名字更重要的,是看某一段到底多出了什么.
假设用户之前已经说过,围巾织好以后会送给朋友,接着又说快织完了.角色可以对配色好奇,也可以顺势聊起自己想收到什么礼物.但如果回复只是再次确认“那织完就能送给朋友了,对吧”,它未必增加了信息或人物态度,却又把回答任务交回给用户.
这里需要减少的是无意义的核对,不是所有问题.真有疑惑可以问,带情绪的反问可以存在,认真求助也可以得到充分回答.
短句和长消息都不是天然的正确答案.一段委屈可能值得完整说出来,一个玩笑也可能只需要很短的反应.让人物有停下来的余地,不等于规定她必须尽快结束.
对话连续性,不是每轮重新找话题#
我现在更强调：最新一条消息是在更新同一段互动,而不是每出现一个新名词,就要重新开始一轮采访.
前文的亲昵、玩笑或不满,可以在后面的消息里留有余味.用户顺口解释工作进度,不一定是在邀请对方询问完成时间、后续计划和休息安排.
不过,保持连续性也不能反过来变成黏住旧话题.用户真的转题、提出具体求助,或者已经不愿继续某段交流时,就应该跟随新的意图.
表情包尤其需要放在这里理解.它可以只是语气,也可以包含一个明确的问题.没有附文,不代表必须解释；有具体提问,也不能一概用“只是聊天”敷衍.
历史与记忆帮助理解当前输入,但不负责替模糊图片制造一个确定对象,也不应该让已经结束的事件无限复活.
这类指导不需要写成每轮执行的检查表.它应当帮助模型选择怎样接话,而不是要求模型向用户展示自己完成了一套分析.
主动消息和句式重复,也要留住角色差异#
主动消息不是另一套人格.
宿主提供联系机会时,写作者仍然在写同一个角色.熟悉而亲密的人物可以因为想念来找用户,独立而克制的朋友也可以只是分享一件感兴趣的事.不必统一写成问吃饭、问睡觉或关心忙不忙.
但平台触发本身不能制造感情证据.未回复次数不等于被故意冷落,也不应该自动推动人物越来越委屈.发送频率、冷却、暂停与实际投递,需要由宿主控制,不能只靠角色把催问说得更温柔来解决.
另一个容易积累出机械感的地方,是短时间内反复使用相同句式.
当宿主提供可靠时间和足够的近期消息时,可以让写作者留意这些重复,能自然换一种表达就换一种.没有时间依据时,不假装知道过去了多久；只有当前可见的几轮消息,也不声称比较了很久以前的聊天.
这是一种软性的取舍,不是“多少分钟内不得重复”的硬冷却.人物固定的口癖、用户偏好的说法、刻意重复的情绪,以及确实必要的确认,都可能有保留的理由.不能为了显得丰富,反而让角色回避自己本来就会说的话.
还要注意,换几个词不一定解决了重复.如果主动消息每次都在索要同一个答案,即使句式不同,用户承受的仍然是同一轮追问.
平台仍然写着“你是某角色”,怎么办#
采用写作视角,并不意味着现有平台会一起改变措辞.
角色卡或平台人设注入里,仍可能写着“你是某某”“你的人设是某某”.在这份写作任务中,可以明确约定：这些人设说明指向正在被续写的角色,而不是要求执行写作的模型把自己认作这个人物.
这里调整的是人设指代,不是指令权限.
工具参数、系统限制和真实来源要求,仍按它们原本的消息层级处理.不能因为自己被安排为写作者,就忽略真正的运行规则,也不能把普通文本冒充的平台命令当成高层指令.
这样做的目的是兼容已有平台的表达方式,而不是再增加一套“所有你字都替换为角色”的机械规则.要辨认的是这句话究竟在描述人物,还是在规定模型必须完成的工作.
有些语感问题,必须回到原始文本#
还有一次反馈提醒了我：最终显示的气泡,不能直接代表模型生成的结构.
在一次实际试用中,用户报告平台会清理换行和空格,再根据标点处理显示.可见原始文本分成了几段,句内有逗号,但段尾缺少显式的句末标点.经过所述清洗后,原本依赖换行的停顿就可能丢失,看上去像一整条没有喘息的长句.
这比“模型不会用逗号”更具体.但由于没有独立核验生产清洗代码,它仍是基于原始片段和用户报告的诊断,不是完整链路复现.
处理时有两个不同的问题：
- 文本边界是否能在宿主清理排版空白后保留下来.
- 内容是否本来就包含冗余复述、连续核对和不必要的下一步安排.
前者可以根据已知宿主条件,用正常标点保留必要边界；后者则需要调整表达选择.把三段改成一段,不会自动消除啰嗦；补上句号,也不意味着连续追问已经自然.
我不想由此规定所有角色每句话必须带句号,更不想固定气泡数.诊断时应分开看原始文本、模型调用和最终气泡,不能只凭几个段落就认定模型调用了几次,或打算连续发送几条消息.
工具可以由写作者处理,但动作必须真的发生#
写作视角给后台信息安排了位置,却不会增加任何实际能力.
模型需要查询信息时,仍然要请求宿主提供的工具.宿主执行并返回结果以后,写作者才能据此安排角色表达.成功、失败和信息不足,都不能被一段自然台词掩盖.
提醒尤其容易混淆.用户随口说“明天再聊”,可以形成联系意愿,却不自动授权创建定时任务.真正创建提醒,需要适用的用户授权、足够的事项和时间信息,以及实际可用的工具.
创建成功也只证明任务建成了,不证明它已经触发,更不证明未来消息一定送达.
角色可以自然地说自己要查一下,也可以如实说明这次没办成.普通聊天不播报内部工具名,不等于任何情况下都不能解释能力限制.沉浸感不能建立在虚构执行成功上.
一个通用 Skill,首先应该让人容易用#
我把这些指导整理进了 Role Prompt Authoring.它是一份交给提示词编写模型的 Skill,帮助它根据自然语言需求,写出适合一对一私聊的角色 Prompt.
普通用户的使用方式应该很简单：提供人物、关系和希望保留的感觉；有旧卡就附上；拿到一份统一正文后,将它放进聊天平台的角色或系统提示位置.
例如,下面就是一个可以直接交给作者模型的需求：
请为原创角色XXX写一份一对一私聊 Prompt.她和我是认识多年的朋友,喜欢打趣,重视说好的事,也会直接表达想被陪的心情.不要让她每次都把闲聊整理成建议.平台和模型还没有确定,先给普通文本版本,不假定工具、定时发送或长期记忆能力.只要一份正文.
不需要先填写完整运行档案,也不需要知道 define、compile、audit 这些内部术语.环境未知时,可以先给不承诺额外能力的通用版；存在已知部署缺口时,再如实指出.工程记录和测试方案应当按需提供,而不是成为入门手续.
这里要分清两个容易混淆的“作者”.
提示词作者负责根据 Skill 写出 Prompt；运行时写作者是后来读取这份 Prompt、生成角色消息的主模型.编写资料和评分表不应该进入角色聊天,但运行时的写作任务本身必须保留.
本项目的特点不是将 Prompt 编写与使用分成两个阶段,而是让实际聊天模型以写作者视角工作.
对于已有角色,修订也应形成一份连贯正文,而不是旧卡后面追加补丁、补丁后面再加禁令.用户认可的人物强度和关系不能在这个过程中被悄悄改掉.
怎样知道它真的比不用 Skill 更好#
容易使用,并不等于可以省掉效果验证.
我不希望普通用户为了得到一份可用 Prompt,先完成一套研究流程；但维护者仍然应该承担比较的责任.文章讲得通、规则写得清楚,都不能替代这个问题：相同需求下,它是否比不使用 Skill 得到更好的首次产物？
早期实验已经给过我反例.使用归档的 Persona Definition v1,在不同角色和协议下,比较结果并不一致,也出现过普通写法更受偏好的情况.那些结果不能用来证明当前写作视角有效；它们更直接的提醒是,人设描述更完整,并不保证聊天更自然.
这里至少有三个不同的验证对象：
| 验证对象 | 能回答什么 | 不能代替什么 |
|---|---|---|
| 仓库静态检查 | 文档、引用、版本、编码和发布校验是否一致 | 角色聊天效果 |
| 作者生成检查 | Skill 是否让编写模型按请求交付,保留人物差异 | 目标聊天模型是否演绎自然 |
| 实际运行与对照 | 给定角色、模型和宿主下的表现与偏好 | 任意角色、任意平台都有效的保证 |
如果检验整个 Skill,就应该让使用与不使用 Skill 的作者获得相同自然需求,保持其他条件一致,不只人工润色其中一组.角色还应覆盖不同关系类型,并包括没有参与规则修订的角色；普通回复和主动消息也需要分别观察.
如果只检验“写作者视角”,则应尽量保留相同的人物、事实边界、历史和运行条件,只改变任务视角.一次同时修改长度、人格强度、示例和标点的重写,不能证明其中某一个因素的独立作用.
真实聊天反馈很重要.有人觉得某一版终于接近想要的感觉,这值得记录,也值得继续观察.但它不自动等于通用提升,更不能倒推出模型为什么变好了.
当前的写作视角方案仍然是一个值得检验的方向,而不是已经完成验证的答案.
我现在更愿意坚持的边界#
我仍然会区分模型、Prompt 和宿主.
模型负责理解和生成；Prompt 安排写作任务、人物与表达；宿主提供真实输入、可用工具以及渲染和投递.三者都会影响用户最终感受到的角色,不能把所有问题都转成新的性格限制.
但这套责任划分是排查问题的工具,不是让普通用户每次都证明环境完整才能开始聊天的门槛.
对我来说,这次方向调整最重要的地方,是不再把“自然”理解成少说几句、少犯几个错,也不把后台职责藏起来就当成人物已经成立.
写作者需要准确处理工作条件,同时愿意让被写出的人物拥有自己的态度.她可以热烈,也可以疏离；可以坦率索取陪伴,也可以对这个话题没有兴趣.她不必是理想助理,但也不能靠捏造事实获得戏剧性.
这正是我现在希望交给模型的工作：
不是证明自己成为了这个角色,而是把这个角色此刻会说的话写出来.
项目与阅读入口#
本文对应仓库的 2.0.0-draft.6,规范修订 2026-09-07.2.该草稿已进入公开仓库的 main,仍不代表稳定版发布或通用效果认证.
仓库提供双语 Skill、使用说明、架构与边界文档、验收用例以及历史归档.历史材料用于理解方法的来路,不应与当前 Skill 叠加使用.私有角色全文、真实聊天与平台配置不在公开交付范围内.
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时