基于聊天记录构建数字人格：工程化实践与隐私优先方案-编程阁

1. 项目概述：从聊天记录到“数字人格”的工程化实践

你有没有想过，把和某个重要的人的聊天记录，变成一份可以“对话”的数字档案？这听起来像是科幻电影里的情节，但今天，借助开源工具和一点工程化思维，我们完全可以自己动手实现。我最近深度体验并扩展了一个名为Persona-Distill-skill的项目，它的核心目标正是如此：将你与朋友、亲人或任何人的聊天记录，通过一套标准化的流程，提炼成一个结构化的“角色资料包”。这个资料包不仅能还原对方的说话方式、交流习惯，甚至能模拟出陪伴感，用于本地聊天、辅助编程，或是作为AI Agent的“记忆”核心。

这个项目脱胎于perkfly/ex-skill的思路，但进行了大幅度的工程化增强。它不再是一个简单的脚本，而是一套包含数据导入、结构化构建、本地部署和跨平台适配的完整工具链。最吸引我的是它的设计哲学：“工程代码公开，个人数据本地保留”。这意味着所有处理你敏感聊天数据的核心逻辑都在你的本地机器上运行，生成的资料包也可以完全离线使用，从根本上避免了隐私泄露的风险。无论是想做一个私人的纪念性聊天机器人，还是希望让AI编程助手（如Cursor、Claude Code）更了解你的协作风格，这个项目都提供了一个极具实操性的起点。接下来，我将拆解整个流程，分享从零构建一个“数字人格”所需的关键步骤、避坑心得以及深度定制的可能性。

2. 核心思路与方案选型：为什么是“资料包”而非“模型”？

在开始动手之前，理解这个项目的底层逻辑至关重要。它走的不是训练一个专属大模型的“重”路线，而是提示词工程（Prompt Engineering）和上下文构建（Context Building）的“巧”路线。简单来说，它不改变模型本身，而是通过精心设计的提示词和喂给模型的“记忆”材料，来引导模型模仿特定角色的言行。

2.1 传统微调 vs. 上下文构建

为什么选择后者？这背后有几个现实的考量：

成本与门槛：训练或微调一个模型需要大量的计算资源、高质量的数据和专业知识。而上下文构建只需要你有一份聊天记录和一个能运行开源代码的电脑（甚至配置不错的笔记本都可以）。
灵活性与安全性：模型一旦训练，其“人格”就固化了。而通过提示词和资料包，你可以随时调整角色的细节，或者完全切换另一个角色，只需更换资料包文件即可。所有敏感数据始终停留在本地，无需上传到任何第三方服务器。
效果的可解释性：模型是个黑盒，你很难知道它为什么突然说出一句不符合人设的话。但资料包是纯文本文件，你可以直接查看和编辑memory.md（记忆）和persona.md（人设），精准地调整内容来影响输出。

Persona-Distill-skill项目正是将这种“上下文构建”的思路工程化了。它定义了一套标准的资料包结构（meta.json,memory.md,persona.md等），并提供了自动化工具，帮你从杂乱的原始聊天记录中提炼出这些结构化的信息。

2.2 项目架构与接口分工

项目的架构设计清晰地分离了关注点，这也是其能稳定运行的关键。它将与AI模型的交互分成了三条独立的通道：

文本聊天通道 (TEXT_*)：这是本地网页聊天应用的核心。它负责处理用户的输入，结合资料包生成符合角色性格的文本回复，并管理表情包发送策略、拟真回复节奏等。它的目标是提供流畅、拟人的对话体验。
资料补全通道 (ENRICH_*)：这是构建资料包的“大脑”。当你导入原始聊天记录后，这部分逻辑会调用AI模型，自动从对话中总结人物性格、关键事件、说话习惯等，并填充到persona.md和memory.md中。它的目标是“理解”聊天记录，并将其结构化。
语音合成通道 (TTS_*)：这是可选的增强功能。如果配置了语音接口，它可以将文本回复转换成语音，甚至尝试克隆特定的声线（需要相应的模型和服务支持），让聊天体验更加沉浸。

这种分工的好处是，你可以为不同的任务选择最合适的模型。例如，资料补全可能需要理解能力更强的模型（如DeepSeek），而文本聊天可能对响应速度和对话流畅性要求更高（如硅基流动的模型）。项目内置了对 DeepSeek、硅基流动(SiliconFlow)、火山引擎(豆包) 等国内可用API的支持，并提供了灵活的配置方式。

实操心得：模型选择策略在初期构建资料包时，我强烈建议使用ENRICH_*通道配置一个能力较强的模型（如DeepSeek-V3）。因为资料补全的质量直接决定了最终角色的“像不像”。而在日常本地聊天时，TEXT_*通道可以选用响应更快、成本更低的模型。项目代码中内置了优先级回退逻辑，即使某个接口失效，也能自动尝试其他备用选项，保证了服务的可用性。

3. 实战第一步：聊天记录的获取与预处理

万事开头难，而构建数字人格的第一步——获取干净、可用的聊天记录——往往是最大的难点。不同的聊天平台数据格式千奇百怪，直接处理原始数据如同大海捞针。

3.1 主流平台导出方案

项目文档中提到了几个关键工具和思路，这里结合我的实战经验展开说明：

对于微信（最复杂但最常用）：官方并不提供方便的聊天记录导出功能。项目推荐配合使用hicccc77/WeFlow这个开源工具。它的原理是通过备份恢复的方式，解析微信Android版的加密数据库，最终将聊天记录导出为可读的JSON、TXT或HTML格式。这个过程需要一点动手能力，主要是配置ADB（Android调试桥）和处理备份文件。关键点在于：确保导出的文本中，对话双方的消息有明确的区分标识（比如发送者昵称）。WeFlow导出的格式通常能被本项目的构建器很好地识别。

对于QQ：相对微信，QQ的导出友好一些。你可以尝试在PC版QQ中，右键点击好友或群聊的聊天窗口，选择“导出消息记录”，通常可以导出为txt或html格式。导出的html文件可能包含大量前端标签，本项目自带的解析器可以处理一部分，但最稳妥的方式还是先将其转换为纯文本或结构清晰的json。

对于其他平台（Telegram, Discord等）：许多平台本身就提供了数据导出功能（通常位于隐私设置或账户管理页面），格式可能是json或csv。你需要做的是，将导出的数据整理成一种简单的交替格式：一行发送者，一行消息内容。或者，更直接一点，手工复制粘贴有价值的对话部分，保存成一个纯文本文件。

3.2 数据预处理的核心技巧

拿到原始数据后，不要急着扔给构建器。花半小时做预处理，效果能提升一倍。

脱敏与清洗：删除所有电话号码、身份证号、具体住址等绝对隐私信息。可以使用文本编辑器的查找替换功能，用[电话]、[地址]等标记替代。同时，清理掉大量的系统通知（如“你已添加了XXX”）、红包记录、转账信息等无关噪音。
格式标准化：确保聊天记录是纯文本格式（.txt）。如果从html或json导出，你可能需要写一个简单的Python脚本提取出“发送者”和“消息内容”两个字段，然后按行存储。一个理想的预处理后文本格式如下：
```
[你] 今天天气真好 [TA] 是啊，适合出去玩 [你] 有什么推荐吗？ [TA] 去爬山吧！我上次去的那个地方很不错。
```
这里的[你]和[TA]就是构建器用来区分对话双方的标识符，你需要在构建命令中通过--name和--target参数告诉它哪个标识对应谁。
媒体文件整理：如果希望角色能“发送”表情包，你需要提前将聊天中用到的表情包图片（通常是GIF或PNG）收集起来，放在一个单独的文件夹里（例如emojis/）。同样，如果有重要的图片、语音转文字稿（transcripts.json），也一并归类。构建器会将这些媒体文件复制到资料包的memories/media/目录下，并在记忆中创建引用。

避坑指南：微信数据导出使用WeFlow时最常见的失败原因是手机备份不完整或加密。务必在手机上开启“USB调试”和“备份密码为空”（如果设置了备份密码，需要在WeFlow中配置）。如果导出失败，可以尝试换一个时间点或重启手机/电脑再试。另一个捷径是：如果聊天记录不多，直接在手机微信上长按消息多选，然后合并转发到“文件传输助手”，再在电脑上复制粘贴出来，虽然笨拙但有效。

4. 核心构建流程详解：从数据到人格档案

预处理完成后，就进入了最核心的环节——运行构建器，生成角色资料包。项目提供了两种构建模式：直接模式和项目工作区模式。对于大多数初次使用者，我推荐从直接模式开始，流程更清晰。

4.1 直接模式构建步骤

假设你已经准备好了名为chat_with_ta.txt的预处理文件，你的昵称在文件中标记为[我]，对方的昵称标记为[TA]。

打开终端，进入项目目录，执行以下命令：

python tools/universal_builder.py \ --name "我" \ --slug "my_ta" \ --target "TA" \ --chat-source "chat_with_ta.txt"

让我们拆解每个参数的作用：

--name “我”：指定聊天文件中代表你自己的标识符。构建器需要知道哪些话是你说的，这样才能把对方说的话剥离出来作为学习样本。
--slug “my_ta”：这是资料包的唯一标识符，也是后续在本地聊天界面中访问的“房间号”。建议使用英文、小写和下划线组合。
--target “TA”：指定聊天文件中代表目标角色的标识符。这是构建器重点分析的对象。
--chat-source “chat_with_ta.txt”：预处理好的聊天记录文件路径。

执行命令后，构建器会开始工作。它会做以下几件事：

解析对话：读取文件，根据name和target分离出双方的对话。
初步分析：统计对话轮数、常用词汇、发言频率等基础信息。
调用AI补全（如果配置了ENRICH_API）：这是灵魂一步。构建器会将目标角色的所有发言，连同一些分析指令，发送给你配置的AI模型（如DeepSeek），要求模型总结出该角色的性格、说话风格、背景故事、兴趣爱好等。这部分内容会被写入persona.md。
提取关键记忆：同时，AI模型也会从对话中提取出重要的、具体的事件或话题（例如，“2023年一起去的迪士尼”、“讨论过养猫的利弊”），并将其结构化地写入memory.md。
整理媒体文件：如果你在命令中通过--media-dir参数指定了媒体文件夹，构建器会将其中的文件复制到资料包中。
生成配置文件：最终，在exes/my_ta/目录下，你会得到一整套完整的资料包文件。

4.2 生成的文件结构及其作用

进入exes/my_ta/目录，你会看到如下文件，每一个都肩负重任：

meta.json：资料包的元数据，包含角色名、slug、创建时间、对话统计信息（总条数、起止时间等）。这是快速索引文件。
persona.md：角色的灵魂文件。这里定义了TA是谁。内容通常包括：
- 基本身份：虚构的姓名、年龄、职业（从聊天中推断或赋予）。
- 核心性格：是外向还是内向？是理性还是感性？幽默还是严肃？
- 语言风格：说话是喜欢用长句还是短句？有没有口头禅（如“真的吗”、“笑死”）？标点符号的使用习惯（比如喜欢用“~”或者“。。。”）？
- 背景知识：TA可能对什么领域感兴趣（游戏、电影、音乐、某个学科）？
- 关系定义：TA与“你”（即用户）是什么关系？朋友、伴侣？这种关系下的典型互动模式是怎样的？
memory.md：角色的记忆库。这里记录了具体的事件和对话片段。格式可能是列表或简短的叙述，例如：
- “2023年10月，曾一起抱怨过周一上班的痛苦。”
- “讨论过最喜欢的电影是《星际穿越》，并分享了观后感。”
- “TA表示自己不喜欢吃香菜。” 这些记忆会在聊天时，被作为上下文的一部分提供给AI模型，从而使回复更具个性化和连续性。
SYSTEM_PROMPT.md：系统指令。这是一个更技术化的文件，它定义了AI模型在扮演这个角色时应遵循的最高层规则。例如：“你正在扮演[角色名]。你必须严格基于提供的persona和memory进行回复，模仿其语言风格和知识范围。不得以AI助手的口吻说话。”
SKILL.md/AGENT_PROMPT.md：技能或Agent提示词。这两个文件是为AI编程助手（如Cursor、Claude Code）准备的。它们将persona和memory的信息，转化为这些助手能理解的“技能”描述，告诉助手：“当用户以某种方式提问时，你应该以这个角色的视角和知识来回答。”

4.3 项目工作区模式

当你需要管理多个角色，或者希望对一个角色进行多次迭代构建时，项目工作区模式更合适。它会在data/目录下为每个slug创建一个独立的工作区，存放原始聊天文件、中间处理结果和最终资料包。

# 初始化一个工作区 python tools/project_data_builder.py --init --slug my_ta # 将聊天文件放入工作区并构建 (假设聊天文件已放在 data/my_ta/raw/chat.txt) python tools/project_data_builder.py --slug my_ta --name “我” --target “TA”

这种模式的好处是文件管理清晰，并且构建脚本会自动在工作区内寻找raw/,media/等标准子目录，适合自动化处理。

核心技巧：如何提升资料包质量？构建器的AI补全步骤 (ENRICH_*) 的效果，极大依赖于你提供的聊天记录质量。除了预处理，你还可以通过“喂”给构建器更优质的指令来引导AI。具体方法是：在运行构建器之前，编辑tools/profile_autofill.py中发送给AI的提示词模板（通常以PROMPT_TEMPLATE或ENRICH_PROMPT为名）。你可以更详细地要求AI总结哪些方面，例如：“请特别关注角色在表达情绪时使用的语气词和表情符号”，“请总结角色在讨论工作/学习时的专业术语和表达习惯”。通过微调这个提示词，你可以让生成的persona.md更贴合你的需求。

5. 本地聊天应用的部署与深度使用

资料包构建完成，相当于有了角色的“灵魂”和“记忆”。下一步，就是为这个灵魂创造一个可以对话的“身体”——本地聊天网页应用。这个基于FastAPI的应用，是我认为本项目中最具匠心、体验最好的部分。

5.1 环境配置与启动

首先，确保你已安装所有依赖：pip install -r requirements.txt。核心依赖是fastapi和uvicorn。

接下来，配置模型API密钥。这是让应用“活”起来的关键。项目支持环境变量和本地配置文件两种方式。对于初学者，我推荐使用本地配置文件，因为它更直观。

复制示例配置文件：cp config/providers.local.example.json config/providers.local.json
编辑config/providers.local.json，填入你从相应平台获取的API密钥。例如，如果你使用硅基流动(SiliconFlow)，配置可能如下：

{ "siliconflow": { "api_key": "你的-siliconflow-api-key", "text_model": "deepseek-ai/DeepSeek-V3-0324", // 用于文本聊天的模型 "enrich_model": "deepseek-ai/DeepSeek-V3-0324", // 用于资料补全的模型 "tts_model": "siliconflow/your-tts-model" // 用于语音合成的模型 } }

重要提示：API密钥安全务必确保providers.local.json文件被添加到.gitignore中，避免不慎提交到公开仓库。这个文件应该永远只留在你的本地机器上。

启动应用：
```
uvicorn apps.local_chat.app:app --host 127.0.0.1 --port 7860 --reload
```
--reload参数表示代码修改后会自动重启，方便开发调试。
打开浏览器，访问http://127.0.0.1:7860。你应该能看到一个简洁的聊天界面。在输入框下方的“角色”选择处，输入你之前构建资料包时使用的slug（例如my_ta），然后就可以开始对话了。

5.2 特色功能解析：拟真交互的奥秘

这个本地聊天应用不仅仅是把资料包丢给API然后返回结果，它做了大量细节优化来提升拟真感。

1. 表情包面板与智能发送：界面左侧有一个可折叠的表情包面板。如果你在构建资料包时导入了emojis/文件夹，这里就会显示对应的表情图片。点击任意一张，它会作为一条真实的消息发送出去，就像你在微信里发表情一样。后端收到这条“图片消息”后，会结合上下文生成一句符合角色的、对应该表情的文本回复（例如，你发了一个“笑哭”的表情，角色可能会回复“哈哈哈你怎么这么搞笑”）。

2. 拟真回复节奏与消息合并：真实的聊天不是机器人式的秒回。这个应用模拟了两种人性化延迟：

思考延迟：根据资料包中分析出的角色平均回复时间，进行一定比例的缩放，模拟“正在输入...”的状态。
追发合并：如果你在短时间内快速发送多条消息，应用会智能地将它们合并后再交给AI模型处理，然后生成一个连贯的、回应了所有要点的回复。这避免了AI对每条消息都进行独立、割裂的回应，使得对话流更加自然。

3. 浏览器本地历史记录：所有聊天记录都使用浏览器的localStorage保存在本地，刷新页面或关闭浏览器后也不会丢失。这完全是一个离线功能，进一步保障了隐私。

4. 可选的语音接口：如果你在配置中启用了TTS_*相关设置，并提供了支持语音合成的API（如某些平台的TTS服务），那么角色就可以“开口说话”了。结合“声线克隆”技术（需要服务商支持），理论上可以逼近真实的声音，但这部分功能对资源和API的要求较高，属于进阶玩法。

5.3 配置详解与故障排查

应用的配置文件和环境变量优先级较高。主要的配置集中在apps/local_chat/config.py和你的providers.local.json中。

常见问题排查：

页面打开后无法选择角色/提示“未找到资料包”：
- 检查exes/目录下是否存在以你的slug命名的文件夹。
- 检查apps/local_chat/config.py中的EXES_ROOT_PATH变量是否指向正确的exes/目录路径。
发送消息后长时间无响应或报错：
- 首先检查终端里uvicorn服务器的日志，看是否有API调用错误。
- 最常见的原因是API密钥错误、额度不足或网络问题。确认providers.local.json中的密钥和模型名填写正确。
- 确认你使用的模型服务商是否可用，以及模型名称是否与提供商支持的列表匹配。
回复内容不符合角色性格：
- 首要检查persona.md和memory.md的内容是否准确、丰富。如果内容太单薄，AI没有足够的信息来模仿。
- 检查SYSTEM_PROMPT.md是否足够强硬地限定了AI的行为。可以尝试加强提示词，例如：“你必须忘记你是一个AI助手，你现在就是[角色名]，严格按照以下性格和记忆对话。”
- 尝试在聊天界面的系统输入框（如果有）中，临时输入更具体的角色指令。

深度定制：修改前端界面与交互逻辑如果你对默认的聊天界面不满意，可以深入apps/local_chat/static/和templates/目录修改前端代码（HTML, CSS, JS）。例如，你可以改变UI主题、增加消息类型（如语音消息）、修改消息气泡样式等。后端逻辑主要在apps/local_chat/app.py和services/目录下，你可以调整消息处理流程、延迟算法等。这需要一定的Web开发基础，但为本项目带来了极大的可扩展性。

6. 跨平台应用：让角色成为你的AI助手“技能”

资料包的强大之处在于其“宿主无关”的设计。你不仅可以在本地网页中和TA聊天，还可以将这个资料包导入到各种AI编程助手和CLI工具中，让它们也具备这个“角色”的视角和知识。

6.1 在Cursor/Claude Code中使用

Cursor和Claude Code这类“AI结对编程”工具，通常支持自定义的“技能”或“上下文”。Persona-Distill-skill生成的AGENT_PROMPT.md或SKILL.md文件就是为此准备的。

操作方法：

在Cursor中，打开设置，找到“Custom Instructions”或“Agent”相关设置。
将AGENT_PROMPT.md文件的内容完整地粘贴进去。这个文件通常包含了persona.md和memory.md的精炼摘要，以及明确的指令，告诉AI助手：“当用户以朋友身份询问某类问题时，请以[角色名]的视角和知识库来回答。”
保存后，当你向Cursor提问时，它就会尝试模仿该角色的口吻和知识来回答。例如，如果你构建了一个“资深程序员朋友”的角色，当你问“这个bug怎么解决？”时，Cursor的回复可能会带上这个角色的说话习惯和特定的技术倾向。

6.2 在Codex、Gemini CLI等工具中使用

对于通过命令行交互的AI工具（如一些封装了OpenAI API的CLI工具），你可以将SYSTEM_PROMPT.md和memory.md的内容作为对话的“系统提示词”和“初始上下文”来使用。

基本思路：启动CLI工具时，或在与工具的交互会话中，首先设置系统提示词（即SYSTEM_PROMPT.md的内容），然后将memory.md中的关键记忆作为第一条用户消息发送，以此来初始化对话背景。之后，你的每次提问，AI都会在这个角色背景下进行回应。

6.3 效果评估与调优

将角色资料包应用于不同宿主时，效果可能有所差异，这取决于宿主工具对长上下文的处理能力、对系统提示词的遵循程度等。

调优技巧：

精简提示词：AGENT_PROMPT.md可能过长，对于有上下文长度限制的工具，需要你手动提炼最核心的性格特点和记忆要点。
强化指令：在提示词开头使用醒目的标记，如### 重要指令 ###，并采用更强制性的语言，如“你必须...”、“禁止你...”。
分场景使用：不必在所有对话中都启用角色。可以针对特定类型的问题（如情感建议、创意讨论）才切换到该角色模式，这样能获得更专注、更高质量的模仿。

7. 伦理、隐私与项目边界探讨

在享受技术带来的乐趣和便利时，我们必须清醒地认识到其边界。Persona-Distill-skill项目在README中明确强调了“仅供学习与研究参考，严禁用于任何非法用途”，这是一个负责任的声明。

隐私是生命线：这个项目的架构设计本身就体现了对隐私的重视——所有数据处理都在本地完成。但作为使用者，我们仍需注意：

知情同意：构建他人的数字人格，理论上应获得对方的明确同意。这涉及个人数据和形象的使用权。
数据安全：妥善保管包含真实聊天记录的原始文件、构建出的资料包以及API配置文件。避免将这些数据存储在云盘公开目录或分享给不信任的人。
使用界限：这个工具创造的是一个基于历史数据的、静态的“影子”，而非真人。切勿将其用于欺骗、伪装身份或进行任何可能对他人造成伤害的互动。

技术的局限性：目前基于大语言模型上下文构建的“数字人格”，其“智能”本质上是模式匹配和概率生成。它可能会“遗忘”记忆中没有提及的细节，也可能在复杂逻辑推理上出现不符合人设的偏差。它更像一个高度定制化的聊天机器人，而非真正意义上的数字孪生。

这个项目为我们打开了一扇窗，让我们能以工程化的方式探索人机交互的新形态。无论是用于个人纪念、创意写作辅助，还是作为研究人机对话的案例，它都提供了一个强大而灵活的框架。最终，如何使用这把“锤子”，取决于挥舞它的人。保持敬畏，明确边界，才能让技术真正服务于人。

基于聊天记录构建数字人格：工程化实践与隐私优先方案