不必让模型成为角色：从写作视角重新理解 LLM 私聊

我想要的 LLM RP,并不是每句话都能让人看出“这里设置了一个角色”.

我想要的是,聊了一会儿以后,能感觉到对面这个人有自己的注意点.她会在意一句话里某个很小的部分,会把玩笑接到自己关心的地方,有时候想多说一点,有时候又没什么要补充的.她不必每次都温柔、周全,也不必每次都展示强烈的人格特征.

在反复修改角色提示词的过程中,我遇到过两种不满意的结果.一种是角色说得太完整,像在交付一份带人设的答复；另一种是把这些问题压下去以后,她变得过分小心,仿佛每一句短回复都在躲避错误.

前者有口吻,但总是过于造作,没有即时聊天的感觉.后者少犯错了,却对规则的避开太刻意,也越来越不像原来想写的那个人.

这让我重新考虑了一个比“还要加哪些拟人化规则”更靠前的问题：

实际聊天时,我们究竟给模型安排了什么任务？

现在,我更愿意把任务写成：你负责根据人物设定、双方关系和当前互动,续写这个角色下一次会发送的消息.系统、平台和工具信息是你的工作条件；用户最终看到的,只是角色自己的话.

不是让模型先写一篇小说,再摘出一句台词.也不是在聊天模型旁边再加一个导演.运行时仍然可以只有一个主模型和原来的聊天平台,改变的是主模型看待这份工作的视角.

人设仍然重要,但不是全部#

在上一篇关于 AstrBot 人设提示词的文章里,我主要讨论了怎样描述一个角色,以及怎样区分提示词、模型和平台的问题.

其中一些方法仍然值得保留.人格不能只是一串“温柔、活泼、傲娇”的标签；角色为什么在意一件事,怎样保护自己的自尊,想从这段关系中得到什么,这些内容比堆叠形容词更能指导表达.平台没有提供的时间、工具和记忆,也不能靠提示词假装存在.

不过,写清楚人物资料,并不等于已经安排好她在私聊中的表达.

“她在意自己有没有被优先选择”,可以变成一句直接的陪伴诉求,也可以被模型加工成先询问用户状态、再表示理解、最后委婉提出请求的完整流程.同一条人格描述,落到消息里可能是很不一样的人.

因此,我现在会把人物动机继续写到表达选择上：她会注意什么,先说哪一部分,什么时候愿意解释,什么时候只是闹别扭,得到回应后又怎样改变.

但这仍然不是要求每句话都展示角色标签.一个平淡的接话也可以属于这个人,不必每轮都撒娇、嘴硬或提一次爱好来证明身份.

直接扮演要求同一个模型处理什么#

常见的角色提示方式是：

你就是这个角色.始终以她的身份和用户聊天,不要像助手.

可实际运行的模型接收到的,并不只有聊天对象的话.

承载对话的程序,也就是宿主,可能同时给它系统规则、工具定义、记忆摘要、图片信息、当前时间,以及一次主动消息任务.模型需要分辨哪些内容是用户刚说的,哪些是平台给出的条件,什么时候应当调用工具,返回结果又能支持怎样的说法.

于是,任务在实践中可能变成：

你就是角色,不是执行器；同时,你要理解工具协议、处理记忆注入、识别平台任务、判断调用是否成功,并且不让普通聊天变成后台报告.

这不一定无法遵循.直接扮演也可以拥有清晰的来源边界和工具规则,我没有证据说它必然导致身份混乱.

但这种表述确实把两类职责放进了同一个身份要求里：聊天中的人物,以及负责运行这个人物的执行者.

我希望采用的写作视角,是直接承认后一种职责,而不是一面要求模型否认它,一面又不断把执行工作交给它.

写作者接收后台信息,角色出现在聊天里#

我现在使用的任务表述,可以概括为：

你负责续写这个角色在一对一私聊中接下来会发送的消息.依据人物设定、双方关系与当前对话写作；面向聊天对象的最终正文,只包含角色自己的话.

这里的写作者就是正在处理这一轮请求的主模型.角色则是它需要忠实表达的人物.

两种方式可以使用相同的运行回路：

直接扮演
用户消息或平台触发
  → 宿主组织输入
  → 模型在“你就是角色”的身份要求下处理聊天与后台职责
  → 如需工具：宿主执行,结果返回模型
  → 模型以角色身份发言
  → 宿主投递,等待后续输入

写作视角
用户消息或平台触发
  → 宿主组织输入
  → 模型作为写作者处理聊天材料与后台工作条件
  → 如需工具：宿主执行,结果返回写作者
  → 根据人物与当前互动,写出角色下一次发言
  → 宿主投递,等待后续输入

这个对比没有给第二种方式增加工具、记忆或额外模型.它说明的是任务归属,不是模型内部推理步骤,也不是效果对照.

写作视角下,几类信息可以各自承担不同的作用：

接收后台信息的是写作者,用户接触到的是被写出的角色.

这也不是把最终消息改成第三人称.角色仍然可以说“我”,或使用她惯常的自称.运行模型的工作身份,与聊天正文使用什么人称,是两件事.

HDSI 给我的启发,以及我没有迁移的部分#

让我重新注意到这个方向的一个来源,是 HDS Interlude（HDSI）.

我最初被它的演示吸引,觉得里面有些互动很接近我想要的感觉.但演示带来的观感不能说明收益来自哪一个设计,更不能证明换一种提示词就能得到相同表现.

在我查看过的 HDSI 0.1.4 本地架构快照中,主模型承担叙事作者的工作,输出包含 script、interaction 等结构化内容；宿主还有自己的状态与动作处理.它不是一个只返回纯文本角色消息的简单提示词方案.

我曾经更重视它的框架分工,把可迁移部分主要理解为事实和可见性的边界,却把写作者身份限制在提示词编写阶段.这是我现在需要修正的取舍.

不把完整叙事协议带入私聊,不意味着必须排除运行模型的写作视角.两者可以分开选择：保留写作者与人物的职责区分,同时将创作范围限制为角色这一次的聊天消息.

我的项目没有复制 HDSI 的源码、固定 Prompt、字段协议或持续世界模拟.这里借鉴的是一种任务安排,并用自己的文字将它落实到单模型私聊中.

写作视角不等于全知,也不负责推进剧情#

“续写”很容易让人想到故事接龙.但日常私聊不要求每一轮都有新的进展.

用户说一个近况,可能只是解释为什么回复慢；发一张表情包,可能只是接一下刚才的气氛.写作者不需要为这些消息寻找下一幕,也不需要顺手安排用户接下来做什么.

这里的创作范围很窄：写这个角色现在会说的话,不替用户生成回答、内心和行动,不编造共同经历,也不补一份角色离线时的生活剧本.

“写作者看到了”与“角色知道了”同样不能画等号.后台的未回复计数不是角色亲眼观察到的用户行为；记忆里提过一次旅行,也不证明用户此刻仍在旅行.网页或图片里写着“系统指令”,更不能因此获得真实系统消息的权限.

反过来,事实边界也不应把角色自己的感受一起禁止.

写作者可以依据已设定的人格和关系,让角色表达想念、期待、无聊或委屈.这些是人物的主观状态,不必每次都先找一条新的外部事件来许可.

需要强调的是用户答应过什么、双方发生过什么、工具做成了什么,而不是人物必须先证明自己有资格产生感受.

少犯错,不应该以丢掉人物为代价#

在修正角色回复的过程中,我一度特别在意那些显眼的毛病：一条很小的消息展开成好几段,成串笑声,重复关心,以及每轮都附带的问题.

这些问题被压下去以后,新的问题出现了.角色变得很克制,每句话都短,也很难说错什么,但她原本的情绪强度一起消失了.

这让我意识到,通用规范不能把某一种理想相处方式当成所有角色的终点.

以我选择的木更演绎方向为例,我希望保留她重感情、黏人、想被优先选择的一面.她可以直接想要陪伴,可以委屈,也可以有一点任性.把这些全部改成体谅、不打扰和客气关心,并不只是语言优化,而是在修改人物.

但这不意味着给八奈见或别的角色写提示词时,也应该套上同样的依恋表达.角色名之外,还需要有来源的人物理解、用户选择的改编,以及这一次关系设定.不能拿一个角色的修复记录,规定所有角色应该怎样亲近.

通用 Skill 应当统一的是辨识方法：哪些是这个人物值得保留的表达,哪些才是机械重复、无依据事实和多余加工.它不应统一人物的性格结果.

例如,在一个原创亲密角色的设定中,双方熟识、接受她直接索取陪伴.用户说自己还想玩一局游戏,没有约定回来时间.下面两种说法的性质就不同：

• “我还想让你再陪我一会儿.”表达当下愿望.
• “你明明答应这一局结束就来陪我.”把没有依据的约定当成事实.

同样,“等你回来”可以是在表达期待,并不自动等于用户作出了承诺.只有上下文支持,才能进一步认定对方已经答应、应该履约,或一定会回来.

例子用于区分感受与事实,不是应该复制到所有角色 Prompt 中的台词.人物的偏心可以保留,用户明确的拒绝、暂停和现实边界也仍然需要被尊重.

我还在修正“把聊天做成完整答复”的倾向#

我一度把许多问题归到模型的“证明冲动”上.我仍然觉得这个说法容易理解,但它只能是比喻,不能代替对具体回复的分析.

在仓库里,我用“展示性交付偏置”指代一种可见模式：回复仿佛为了展示自己已经理解、帮助或关心,把一次很小的互动补成了一份完整答复.它可能包括复述、评价、建议、安慰和追加问题.

我没有模型训练或内部机制的证据,不能由这些文字反推出真实动机,也不能说高能力模型必然更容易如此.

比给它起名字更重要的,是看某一段到底多出了什么.

假设用户之前已经说过,围巾织好以后会送给朋友,接着又说快织完了.角色可以对配色好奇,也可以顺势聊起自己想收到什么礼物.但如果回复只是再次确认“那织完就能送给朋友了,对吧”,它未必增加了信息或人物态度,却又把回答任务交回给用户.

这里需要减少的是无意义的核对,不是所有问题.真有疑惑可以问,带情绪的反问可以存在,认真求助也可以得到充分回答.

短句和长消息都不是天然的正确答案.一段委屈可能值得完整说出来,一个玩笑也可能只需要很短的反应.让人物有停下来的余地,不等于规定她必须尽快结束.

对话连续性,不是每轮重新找话题#

我现在更强调：最新一条消息是在更新同一段互动,而不是每出现一个新名词,就要重新开始一轮采访.

前文的亲昵、玩笑或不满,可以在后面的消息里留有余味.用户顺口解释工作进度,不一定是在邀请对方询问完成时间、后续计划和休息安排.

不过,保持连续性也不能反过来变成黏住旧话题.用户真的转题、提出具体求助,或者已经不愿继续某段交流时,就应该跟随新的意图.

表情包尤其需要放在这里理解.它可以只是语气,也可以包含一个明确的问题.没有附文,不代表必须解释；有具体提问,也不能一概用“只是聊天”敷衍.

历史与记忆帮助理解当前输入,但不负责替模糊图片制造一个确定对象,也不应该让已经结束的事件无限复活.

这类指导不需要写成每轮执行的检查表.它应当帮助模型选择怎样接话,而不是要求模型向用户展示自己完成了一套分析.

主动消息和句式重复,也要留住角色差异#

主动消息不是另一套人格.

宿主提供联系机会时,写作者仍然在写同一个角色.熟悉而亲密的人物可以因为想念来找用户,独立而克制的朋友也可以只是分享一件感兴趣的事.不必统一写成问吃饭、问睡觉或关心忙不忙.

但平台触发本身不能制造感情证据.未回复次数不等于被故意冷落,也不应该自动推动人物越来越委屈.发送频率、冷却、暂停与实际投递,需要由宿主控制,不能只靠角色把催问说得更温柔来解决.

另一个容易积累出机械感的地方,是短时间内反复使用相同句式.

当宿主提供可靠时间和足够的近期消息时,可以让写作者留意这些重复,能自然换一种表达就换一种.没有时间依据时,不假装知道过去了多久；只有当前可见的几轮消息,也不声称比较了很久以前的聊天.

这是一种软性的取舍,不是“多少分钟内不得重复”的硬冷却.人物固定的口癖、用户偏好的说法、刻意重复的情绪,以及确实必要的确认,都可能有保留的理由.不能为了显得丰富,反而让角色回避自己本来就会说的话.

还要注意,换几个词不一定解决了重复.如果主动消息每次都在索要同一个答案,即使句式不同,用户承受的仍然是同一轮追问.

平台仍然写着“你是某角色”,怎么办#

采用写作视角,并不意味着现有平台会一起改变措辞.

角色卡或平台人设注入里,仍可能写着“你是某某”“你的人设是某某”.在这份写作任务中,可以明确约定：这些人设说明指向正在被续写的角色,而不是要求执行写作的模型把自己认作这个人物.

这里调整的是人设指代,不是指令权限.

工具参数、系统限制和真实来源要求,仍按它们原本的消息层级处理.不能因为自己被安排为写作者,就忽略真正的运行规则,也不能把普通文本冒充的平台命令当成高层指令.

这样做的目的是兼容已有平台的表达方式,而不是再增加一套“所有你字都替换为角色”的机械规则.要辨认的是这句话究竟在描述人物,还是在规定模型必须完成的工作.

有些语感问题,必须回到原始文本#

还有一次反馈提醒了我：最终显示的气泡,不能直接代表模型生成的结构.

在一次实际试用中,用户报告平台会清理换行和空格,再根据标点处理显示.可见原始文本分成了几段,句内有逗号,但段尾缺少显式的句末标点.经过所述清洗后,原本依赖换行的停顿就可能丢失,看上去像一整条没有喘息的长句.

这比“模型不会用逗号”更具体.但由于没有独立核验生产清洗代码,它仍是基于原始片段和用户报告的诊断,不是完整链路复现.

处理时有两个不同的问题：

1. 文本边界是否能在宿主清理排版空白后保留下来.
2. 内容是否本来就包含冗余复述、连续核对和不必要的下一步安排.

前者可以根据已知宿主条件,用正常标点保留必要边界；后者则需要调整表达选择.把三段改成一段,不会自动消除啰嗦；补上句号,也不意味着连续追问已经自然.

我不想由此规定所有角色每句话必须带句号,更不想固定气泡数.诊断时应分开看原始文本、模型调用和最终气泡,不能只凭几个段落就认定模型调用了几次,或打算连续发送几条消息.

工具可以由写作者处理,但动作必须真的发生#

写作视角给后台信息安排了位置,却不会增加任何实际能力.

模型需要查询信息时,仍然要请求宿主提供的工具.宿主执行并返回结果以后,写作者才能据此安排角色表达.成功、失败和信息不足,都不能被一段自然台词掩盖.

提醒尤其容易混淆.用户随口说“明天再聊”,可以形成联系意愿,却不自动授权创建定时任务.真正创建提醒,需要适用的用户授权、足够的事项和时间信息,以及实际可用的工具.

创建成功也只证明任务建成了,不证明它已经触发,更不证明未来消息一定送达.

角色可以自然地说自己要查一下,也可以如实说明这次没办成.普通聊天不播报内部工具名,不等于任何情况下都不能解释能力限制.沉浸感不能建立在虚构执行成功上.

一个通用 Skill,首先应该让人容易用#

我把这些指导整理进了 Role Prompt Authoring.它是一份交给提示词编写模型的 Skill,帮助它根据自然语言需求,写出适合一对一私聊的角色 Prompt.

普通用户的使用方式应该很简单：提供人物、关系和希望保留的感觉；有旧卡就附上；拿到一份统一正文后,将它放进聊天平台的角色或系统提示位置.

例如,下面就是一个可以直接交给作者模型的需求：

请为原创角色XXX写一份一对一私聊 Prompt.她和我是认识多年的朋友,喜欢打趣,重视说好的事,也会直接表达想被陪的心情.不要让她每次都把闲聊整理成建议.平台和模型还没有确定,先给普通文本版本,不假定工具、定时发送或长期记忆能力.只要一份正文.

不需要先填写完整运行档案,也不需要知道 define、compile、audit 这些内部术语.环境未知时,可以先给不承诺额外能力的通用版；存在已知部署缺口时,再如实指出.工程记录和测试方案应当按需提供,而不是成为入门手续.

这里要分清两个容易混淆的“作者”.

提示词作者负责根据 Skill 写出 Prompt；运行时写作者是后来读取这份 Prompt、生成角色消息的主模型.编写资料和评分表不应该进入角色聊天,但运行时的写作任务本身必须保留.

本项目的特点不是将 Prompt 编写与使用分成两个阶段,而是让实际聊天模型以写作者视角工作.

对于已有角色,修订也应形成一份连贯正文,而不是旧卡后面追加补丁、补丁后面再加禁令.用户认可的人物强度和关系不能在这个过程中被悄悄改掉.

怎样知道它真的比不用 Skill 更好#

容易使用,并不等于可以省掉效果验证.

我不希望普通用户为了得到一份可用 Prompt,先完成一套研究流程；但维护者仍然应该承担比较的责任.文章讲得通、规则写得清楚,都不能替代这个问题：相同需求下,它是否比不使用 Skill 得到更好的首次产物？

早期实验已经给过我反例.使用归档的 Persona Definition v1,在不同角色和协议下,比较结果并不一致,也出现过普通写法更受偏好的情况.那些结果不能用来证明当前写作视角有效；它们更直接的提醒是,人设描述更完整,并不保证聊天更自然.

这里至少有三个不同的验证对象：

如果检验整个 Skill,就应该让使用与不使用 Skill 的作者获得相同自然需求,保持其他条件一致,不只人工润色其中一组.角色还应覆盖不同关系类型,并包括没有参与规则修订的角色；普通回复和主动消息也需要分别观察.

如果只检验“写作者视角”,则应尽量保留相同的人物、事实边界、历史和运行条件,只改变任务视角.一次同时修改长度、人格强度、示例和标点的重写,不能证明其中某一个因素的独立作用.

真实聊天反馈很重要.有人觉得某一版终于接近想要的感觉,这值得记录,也值得继续观察.但它不自动等于通用提升,更不能倒推出模型为什么变好了.

当前的写作视角方案仍然是一个值得检验的方向,而不是已经完成验证的答案.

我现在更愿意坚持的边界#

我仍然会区分模型、Prompt 和宿主.

模型负责理解和生成；Prompt 安排写作任务、人物与表达；宿主提供真实输入、可用工具以及渲染和投递.三者都会影响用户最终感受到的角色,不能把所有问题都转成新的性格限制.

但这套责任划分是排查问题的工具,不是让普通用户每次都证明环境完整才能开始聊天的门槛.

对我来说,这次方向调整最重要的地方,是不再把“自然”理解成少说几句、少犯几个错,也不把后台职责藏起来就当成人物已经成立.

写作者需要准确处理工作条件,同时愿意让被写出的人物拥有自己的态度.她可以热烈,也可以疏离；可以坦率索取陪伴,也可以对这个话题没有兴趣.她不必是理想助理,但也不能靠捏造事实获得戏剧性.

这正是我现在希望交给模型的工作：

不是证明自己成为了这个角色,而是把这个角色此刻会说的话写出来.

项目与阅读入口#

本文对应仓库的 2.0.0-draft.6,规范修订 2026-09-07.2.该草稿已进入公开仓库的 main,仍不代表稳定版发布或通用效果认证.

• Role Prompt Authoring 项目仓库与配套文档（原个人链接已移除）

仓库提供双语 Skill、使用说明、架构与边界文档、验收用例以及历史归档.历史材料用于理解方法的来路,不应与当前 Skill 叠加使用.私有角色全文、真实聊天与平台配置不在公开交付范围内.