同事跳槽了、导师毕业了、前任走了——如何把一个人的表达方式、思维习惯与关系记忆，稳定地留在数字世界里？

人离开之后，最先留下来的通常是照片、聊天记录、语音、朋友圈、文档。
但真正会慢慢变模糊的，往往不是这些“材料”，而是更难描述的东西：

1. TA 说话时的停顿和语气
2. TA 看问题的方式
3. TA 面对冲突时的反应
4. TA 对一些小事的偏好和边界
5. TA 和你相处时，那些只有你们知道的细节

受到最近一些“蒸馏自己/前任”等开源项目的启发（见文末链接），我花了一周时间，尝试构建一个面向 AI 人格构建与分发的系统——姑且叫它“赛博灵魂”项目。
核心想验证的问题是：如果我们希望重要的人不必真正“离开”，能否把一个人的表达方式、人格轮廓和长期关系感，尽量稳定地编码进数字世界？

继续往下做，我发现这件事本质上不是“做个聊天机器人”，而是在做一套面向 AI 人格的产品系统。

---

一、为什么我觉得“聊天机器人”还不够

现在的大模型已经能回答很多问题了，但如果你真的想做一个“像某个人”的 AI，问题会立刻复杂很多。

一个普通聊天机器人，解决的是“这一轮怎么答”。
而一个像人的 AI，至少要解决下面几件事：

1. 它是谁，它的表达方式是否稳定
2. 它有没有持续的人格，而不是每轮都像临场发挥
3. 它能不能从资料里逐步沉淀出可复用的版本，而不是每次都重新拼 Prompt
4. 它能不能记住与创建者之间长期稳定的关系信息，而不是只靠短上下文
5. 它能不能真正发布出去，而不是永远停留在 Playground

也正是因为这些需求，这个项目一开始就不是按“做一个更好看的聊天框”来设计的，而是按“做一个 AI 人格构建与分发平台”来设计的。

---

二、系统定位：从“角色”到“产品”

如果用一句话概括，我会这样描述：
这是一套让用户把 AI 角色从概念变成产品的系统。

它覆盖的不是单点能力，而是一整条链路：

换句话说，它解决的不是“AI 能不能说话”，而是“这个 AI 角色能不能被稳定地构建、调试、发布、运营和接入业务场景”。

---

三、重点解决的几个工程问题

1. 人格不能一会儿像这样，一会儿像那样

如果把所有资料一次性喂给模型，模型大概率会给你一份“总结”，但不一定会给你一个稳定的人格。
所以项目没有走“一次生成、永久使用”的路线，而是做了版本化构建。每次构建产生的是一个版本，版本可以预览、发布、重建、回滚。

这件事看起来是产品功能，实际上是人格稳定性的工程前提——因为只有版本存在，才能谈：

• 本次构建有没有偏移
• 新资料有没有破坏旧人格
• 用户到底在用哪个版本对话

2. 资料人格 和 对话记忆 不能混成一锅

在系统设计里，构建出来的“人格版本”，和运行中沉淀出来的“长期记忆”，是两层东西。

前者解决的是：

• 这个灵魂的表达风格是什么
• 它更像怎样的人
• 它处理问题的方式是什么

后者解决的是：

• 创建者长期稳定的偏好是什么
• 他在意什么，不喜欢什么
• 哪些关系信息值得被持续记住

如果这两层不拆开，系统很容易变成“短期聊天污染长期人格”，最后越聊越乱。

3. 资料导入不能阻塞在前台

真实用户上传的资料并不总是干净的：有文本、有 URL、有文件，还有外部平台同步过来的消息。
这类任务天然适合走异步链路。
因此系统把资料解析、构建、知识图谱同步、长期记忆提取都放进了 Worker 队列，而不是让前端页面一直傻等。

这样做的好处很直接：

• 前台交互不会被大模型或解析耗时拖死
• 构建和解析失败可以重试
• 不同任务可以独立演化，不会互相卡死

4. AI 不是只在网页里活着

很多 AI 产品做完网页端就结束了，但如果一个人格只能待在网页里，它的使用边界就会很窄。
所以系统从一开始就考虑了连接器能力，当前方向是让角色可以通过连接器接入飞书、钉钉（测试中）。
这意味着“灵魂”不是一个页面对象，而是一个可以被分发和接入的运行单元。

5. 做产品，不只是做模型调用

一个真正要上线和运营的 AI 产品，不能只有模型 API 接口。
它还需要：

• 登录与身份体系
• 工作台
• 版本管理
• 审核流程
• 发布与下架
• 自定义模型配置

这些听起来“不性感”，但它们决定了这个系统是 Demo，还是一个可持续运营的平台。

---

四、当前整体架构

从实现上看，系统大致拆成了四层。

1. Web 工作台层

主要负责用户操作和状态呈现，包括：灵魂创建与编辑、资料导入、模型配置、构建与发布、对话调试、市场与审核管理。
前端技术栈是 React + Next.js。

2. 异步任务层

负责所有高耗时任务：资料解析、版本构建、知识图谱同步、长期记忆提取等。
由独立 Worker 承担，避免把大模型调用和重处理链路压在 Web 请求里。

3. 存储与检索层

底层保存灵魂、版本、资料、对话、长期记忆、图谱等对象，同时支持向量检索与结构化数据查询。
核心目标不是“存下来”，而是：

• 让不同类型的信息有明确边界
• 让运行时能按需召回
• 让构建态和对话态互不污染

4. 运行时

真正回答用户问题时，并不是只拿一段系统提示词，而是按需获取更多数据：

• 当前灵魂版本的人格内容
• 资料检索出的补充片段
• 创建者长期记忆
• 知识图谱中的稳定事实
• 当前会话历史

这一层决定了灵魂是不是既“像它自己”，又“知道该怎么回答当前问题”。

大致流程如下：

---

五、它和普通知识库产品有什么不同

我不认为这个系统是知识库的替代品，它更像是在知识库之上，再往前走了一步。

普通知识库更像：
“我有一堆资料，你帮我回答问题。”

而本系统更像：
“我想创建一个有设定、有风格、有长期演化能力的 AI 角色，让它以某种人格去使用这些资料。”

这里最大的差异，不在于有没有检索，而在于有没有人格主轴。
没有人格主轴，AI 只是会回答；有了人格主轴，它才更接近一个真正可运营的角色。

---

六、适用场景示例

目前验证了几类场景：

1. 产品顾问 / 品牌助理

例如给产品官网做一个“产品灵魂”，让它不仅知道功能，还能以统一口径介绍产品、引导配置、回答常见问题。
（示例对话截图略）

2. 专家型角色

把某个方法论、知识体系、工作经验沉淀为一个可交互的 AI 角色，而不是零散 FAQ。

3. 创作者人格 / IP 角色

让 AI 不只是“回答内容”，而是带着创作者自己的风格、语气和判断方式去表达。

4. 有情感投射的角色实验

例如前任、导师、朋友、同事等角色。这类场景很考验人格稳定性和长期记忆边界，也正是这类系统值得验证的地方。
（示例对话截图略）

5. 外部平台接入型机器人

不是只在网页聊天，而是接入飞书、钉钉后，作为一个真正的工作角色存在。当然效果还需要更多的改进与优化。

---

七、这类项目真正难的地方

做下来我越来越确定，AI 产品难的地方，从来不只是调模型。
真正难的是下面这些东西能不能同时成立：

• 体验上像一个产品，而不是几个能力拼起来
• 人格上持续稳定，而不是每次都重开
• 工程上可重试、可发布、可审查
• 业务上可分发、可运营、可接入

当前版本还只是第一版，后面还有很多事情要做——更完整的连接器生态、更好的多角色协同、更成熟的长期记忆控制、更完善的市场与运营能力。
但至少到这一步，它已经不是一个“聊天框”了，而是一个开始成形的 AI 人格产品底座。

---

八、一点延伸思考

如果你也在做 AI 产品，不妨思考一个问题：

你做的到底是“会回答的模型入口”，还是“可交付的 AI 角色系统”？

这两个方向看起来接近，实际上产品设计、工程结构、长期演化方式都完全不一样。
上面描述的系统是我对第二种方向的一次实践。

如果后面继续写这一系列文章，可能会继续聊：

1. 为什么版本化对 AI 人格系统很重要
2. 长期记忆为什么不能等于聊天记录
3. 为什么 AI 连接器会是下一阶段非常关键的一环

---

相关开源项目参考（灵感来源）：

• 同事.skill
• 前任.skill
• 永生.skill

（本文为技术实践分享，不涉及具体产品推广链接。）

---