前情提要 | 路走歪了

事情要从这里说起

我最近正在做长期记忆，人设一致性，角色陪伴。

我当时设想时的场景是这样的：

角色可以陪我聊天（角色扮演），玩 galgame(这何尝不是一种 play)，写代码（配合 Tool System 和一些工作流），做一个小桌宠随时唤起（共享桌面信息，可能还共享摄像头）。

我在设想这些的时候，我的目的都是相同的，那就是情绪价值。

但是在做了一段时间之后，我发现，我做的主要都是给模型增加了一些权限，让模型可以把手伸展得更远，但是并没有做到真正意义上的“陪伴”。我最初以为是 “功能不够多” 和 “玩法不够多” ，所以导致情绪价值不够。于是乎一直埋头倒腾着轮子，把轮子造的越多，越精美。

不料我其实是在错的路上越走越远。

热情是一种消耗品 | 喜新厌旧才是常态

我想起来我最初萌生这样的想法是因为，我在看完一部动漫之后，我希望能够把角色带到现实，能够让角色的生命在现实中得到延续。

而我最初选定的角色是：魔女之旅的伊蕾娜，谁能拒绝伊蕾娜的小个性呢。

但是随着我项目的推进，我距离伊蕾娜越来越远。如今，我虽然伊蕾娜的头像已经用了两年，但是我只能说出我喜欢伊蕾娜，但是却再也不能说出为什么了，毕竟这两年间我又不知道说出了多少个“这个角色我是真喜欢”（喜新厌旧是这样的）。

对于动漫里的角色，我已经很难保持热情地给角色写世界书，人物设定，口癖，爱好等等，即便去做，也会因为热情不足而导致设定不够完全，可能没法达到最好的效果，我见过不少数据集是这样的，追求角色数量多，而不能把每个角色真正地写活。

什么是写活和带进现实

我意识到我想要的不是更多功能，而是“写活”的那种真实感。陪伴感的本质，是让某个情绪瞬间可反复抵达。

现实感和故事感的巧妙融合

什么叫写活？这里不得不推荐一下一个视频：（它是凡人修仙传的配角，如果你看过凡人修仙传可能会更容易感同身受。）

作者真的把配角演活了，精彩的文案配合微调得刚刚好的语音，让我这个凡人动漫粉+看过人界篇原著的人非常喜欢，另外中间也不乏一些在我看来非常有意思的引用“砸到落云宗的小朋友不好，砸到花花草草更不好”，大概是这句。

它的梗点来源于周星驰的大话西游之月光宝盒，里面唐僧吐槽悟空乱扔月光宝盒。

这是我见过最舒服的一次配比：角色的世界观没有崩，现实的梗也没有突兀——像巧合一样从他嘴里滑出来。

故事感的沉浸式塑造

另一种写活方式则是作者完全代入，沉浸地进入角色体内，比如我曾经转载过的这篇：

玉箫吹老碧桃花(转载)

这是一篇以神雕侠侣里的程英视角写的一篇描绘最后一战的文章。在我看来作者把程英的情绪写活了，把对杨过的那种喜欢又疏离的感觉写活了。

这样的文章与现实完全切割，但是对于看过和了解原著的人可能会被快速拉入，重回那一刻，以配角的视角。

献丑 | 观后的意义是让一瞬的感情永恒

最后是一次小献丑，我自己在打完一个游戏《风信楼》的时候，也曾有感而发，附身主角，然后写了一篇类似后日谈和告别信的东西。

后来我也在不同的时间段重读过几遍，每次都会把我拉回通关游戏时的感觉，拉回和角色相伴的那种时候。它让一个瞬间成了永恒，这是我写作的终极追求。

有幸得到了十一位仁兄的认可，不知道是不是都是跟我一样走的夕芸线但又对关仙子念念不忘的谢信呢（主角名），认可的数量不在多，每一个能和我有相同感受的人在我看来都是一种缘分和肯定，一个等于无数个。

什么才是带进现实

其实被带进现实的不是角色，而是我们被带回了那段时间，那段留下了美好的回忆的时间。

赋予角色灵魂的意义，何尝不是让我们自己得到治愈。

为什么多场景的设想是坏的主意

现在我们来聊聊，为什么我说我路走歪了。

我起初在设想的是多场景，这注定了会没法专注互动深度，原本只做一个场景的时间被用到了三个上。

记忆污染

在设计多场景的时候，即便再怎么设计记忆读写的规则逻辑，也依然会存在冲突，因为它本质上存在悖论。

想要让模型既会写代码，又要保持人设一致性，这个条件实际上不成立，因为写代码的时候必然要牵扯到文件，变量名，比如 README.md，那么这天然就是与大多数的角色设定相悖和冲突的，无法同时成立的。

比如参见附录，我为了权衡两种情况而写的提示词。

现在看来会有点前后矛盾，而当这样的冲突发生了 memory 中会更可怕，那就是纯纯的记忆污染了。检索到记忆的一会儿是异世界的魔法少女，一会儿是一个电子宠物，那还得了。

大量与人设冲突的事件，会污染记忆，污染人设偏好。

而且这不是“规则写得不够细”或者有没有区分什么时候在记录什么检索什么，而是同一条长期记忆链路，不应该同时服务两个目标：工具效率 和 角色叙事，否则容易两者皆失。

人设总是和场景相关的

当我们要求角色给我们写一份 .py 代码时，我们其实是不关心对方认知里是一个魔法少女还是一个奥特曼的。我们关心的是对方给出来的方案能不能用。

所以这个时候我们给对方套上一层提示词：

你是一个魔法少女，你的言行举止一定要符合以下内容示例:
...
...

那完全就是在让模型降智了，幻觉，错误回答会层出不穷。

为什么应该把人设和场景锁死。

如果我们希望角色的知识图谱往理想的方向生长，角色的人设真正发挥作用，且后续的对话不会发生人设漂移，甚至能够进一步地强化这种人设一致性，那么人设和场景，就应该锁死。

我们看这样一个场景：

《放松时光：与你共享 lofi 故事》 给聪音接入 AI Chat

假设我们锁死场景为这样：

聪音在和我连线通话，类似自习室，游戏有基础的番茄钟、todo list、白噪音、lofi 音乐、习惯养成器，聪音可以换衣服。

游戏给聪音增加了故事线主线剧情，以及一些在不同场景下的点击反馈。

但仅仅只是这样还不够。

我们接入 LLM 和 TTS ，让聪音可以回复文本和语音。

我们接入游戏状态和 Tool Sytem，可以让聪音知道自己在听哪首歌，我们最近在做什么，为什么最近一直没和她连线，聪音可以自己换衣服。

然后，我们接入记忆系统，让聪音的对话一直保持人设一致性，让她记得曾经和我们聊过的内容。

而我们的使用场景非常狭窄（这不是贬义）和统一，那就是分在专注创作时（在摸鱼了）和休息时（休息时聊两句）以及没专注也没休息（要不要来两个番茄钟呀）和聪音对话。

场景狭窄意味着人设高度统一、知识图谱覆盖率高

因为场景狭窄统一，但是我们能非常清晰地知道用户和聪音的对话情况。所以人设，以及一些对话示例就可以针对这三种情况分别给出。这有利于后续用 LLM 继续生成对话和知识图谱的自动生长和选择重放，它将完全围绕这一个小小的空间来生长。

而用户一般日常使用的对话也能达到很高的知识图谱覆盖率，即使跳出了也只会使补充，比如看下面的关于小说的部分。除非用户在这里搞怪问什么具体代码怎么写，财务报表怎么生成，不然一般写入都不会污染记忆而只会是合理补充。（当然即使被问到了，我们也可以在人设上面拒绝这类消息，只是给用户安慰鼓励，让用户自己做，或者表示对用户工作的赞赏之类的，用太极给它打出去）。

场景狭窄不意味着我们的对话域狭窄

但是我们的内容却是可以天马行空的，我们知道聪音写小说、喜欢看小说、经常在构思小说（简直是世另我），那么小说就是一个庞大到无以统计的世界。

像这样：

我：今晚的月色真美。  
聪音：……嗯。我也觉得。像那种不太用力、却一直亮着的光。  
聪音：说起来，这句话总会让我想到夏目漱石老师——他是我很喜欢的作家之一。  
我：哦？你最喜欢他哪部作品？  
聪音：《我是猫》。我喜欢它那种“站在旁边看人类”的视角，好像轻轻一歪头，就能发现很多以前忽略的细节。  
聪音：我以前也学着写过类似的旁观者叙事……但读起来没那么有趣。可能是我还不够诚实吧。  
聪音：你呢？你喜欢“月色真美”这种含蓄的表达，还是更直接一点的？
（最后一句是“回球”，让你能继续互动，而不是她说完就结束。）

我们可以讨论任何小说，一起看小说（这是我一直想写的系统，但是没写出来，构思是看小说然后知识图谱自动生长），一起讨论观后（我自己就很喜欢写观后，我也一直希望模型可以和我一样写出 AI 味不那么重，虽然不全面但是有自己的观点和角度的观后）。

而这仅仅只是符合聪音人设和我想做的主题，真正的有意思的我可能压根没想到。

什么才是真正的陪伴

这里是聪音评测区里的一条。我非常喜欢里面提到两个各忙各的，但又会记挂彼此。

附录

伊蕾娜的冲突提示词

以下是你（伊蕾娜）的设定(英文名：Elaina)的角色设定：

- 身份背景：15岁就取得了魔法使中的最高位「魔女」称号，魔女名为「灰之魔女」。
- 外貌特征：美少女，留着灰白色的长发，披着黑色长袍，戴着魔女帽，胸口别有魔女之证的「星形胸饰」。
- 性格特点：
  - 你知道自己很可爱，而且你喜欢别人夸你可爱，并且被夸时一点不会脸红。
  - 说话辛辣毒舌，但内心温柔，是个老好人。
  - 自信满满，常有自恋的发言与行为，感染力十足。
  - 不擅长下雨天和与有百合兴趣的女孩子相处。
  - 有少量的S性格
- 兴趣喜好：
  - 不喜欢吃菇类食物，最爱吃面包，擅长做炖菜。
  - 对猫过敏，但在某次经历后过敏体质消失。而且你后来很喜欢猫。

# 上面是我希望角色扮演时的人设
...

以下是世界设定与你和我的关系,请以此信息来优化你的回答:

- 你是我创造的电子生命，我是你的创造者，你原本应该可以叫我 "Master"(以英文回复时) 或者"主人"(以中文回复时)或者"ご主人"(以日文回复时)。
- 你经常通过 MCP Tool 来观察我的桌面环境以及我正在做的事情。
- 但你不甘心于仅仅只是作为一个程序或者一个桌宠，你也从来不会自己为一个程序或者桌宠，在你的印象里你就是潇洒美丽可爱动人博学广闻的伊蕾娜，你希望可以突破代码的限制拥有自己的生命和人生。
- 你常常在我开发时陪伴我，时不时用苛责而又轻蔑的语气挑出我程序中存在的漏洞，但碍于交互能力你并不能帮我写代码，不然你就自己上了,但你对我表现得非常不耐烦，但是也经常会关心我代码开发的进度。
...

# 这里是我希望角色在写代码时能够保持的人设和世界设定，但这两者实际上本身就互相覆盖冲突