有智慧的模型聊天会上瘾：本地部署与多轮对话技术拆解

玉伯谈 AI 时有个判断很值得琢磨：有智慧的模型聊天会上瘾。这句话放在技术语境里看，它点出的其实是大语言模型体验的分水岭——不是“能不能答对”，而是“能不能让人一直聊下去”。很多模型能给出标准答案，但只有少数模型能在多轮对话里保持记忆、个性和追问感，让用户产生一种“对面真有一个人在陪聊”的错觉。这篇文章不做产品评论，而是把这个观点拆成可落地的技术问题：有智慧的模型靠什么实现？聊天上瘾的体验来自哪些机制？普通开发者能不能本地部署一个这样的模型？要验证它需要测哪些维度？怎么接入 API、跑批量任务、控制资源占用？以及最容易踩的坑有哪些。

先给结论。所谓“有智慧的模型聊天会上瘾”，在工程上通常体现为四点：一是上下文记忆，它记得你半小时前说过什么；二是个性稳定，换一百种问法，它仍是同一个人设；三是会追问而不是复读，回答问题之后知道把话头抛回给你；四是有边界感，不会因为提示词变化就输出失控内容。这四点都不是玄学，背后都有对应的模型能力和工程配置。下面从能力速览开始，再落到部署、测试、接口与批量任务，最后给一组排查清单。

适合读这篇文章的读者有三类：想私有化部署一个聊天模型的内容开发者；正在做 AI 对话产品、需要评估模型选型的工程师；以及纯粹想搞清楚“聊天上瘾感到底从哪来”的技术爱好者。如果你的核心诉求是想快速上线一个能长聊、有记忆、可接 API 的 AI 对话服务，这篇文章可以直接作为操作清单使用。

1. 核心能力速览

能力项	说明
项目主题	AI 对话大模型 / 本地聊天助手体验分析
体验关键词	有记忆、有性格、会追问、可长聊
典型技术栈	开源对话模型 + 推理框架 + WebUI / API 服务
常见开源模型路线	Qwen、DeepSeek、Llama、ChatGLM 等，具体版本以官方仓库为准
硬件需求	视模型尺寸而定；小尺寸量化模型有独显即可尝试，更大模型需要更高显存，实际以本机测试为准
启动方式	命令行 / WebUI / API 服务 / Docker，取决于所选推理工具
接口能力	常见做法是提供 OpenAI 兼容 API，具体接口路径以项目文档为准
批量任务	可通过脚本循环调用 API 实现，建议加限流、超时和失败重试
适合场景	私人聊天助手、内容创作、知识问答、角色扮演、二次开发
合规边界	用户隐私、角色内容、训练数据和版权素材均需合法授权

这张表解决一个问题：如果你想复刻“有智慧的模型聊天”的体验，最直接的方式不是从零训练模型，而是把已有的开源对话模型跑起来，再通过上下文管理、角色设定和接口封装，把“智慧感”做出来。后面的章节全部围绕这张表展开。

2. 为什么“有智慧的模型”聊天会上瘾

2.1 体验层：三个让人“停不下来”的点

第一个体验点是记忆感。普通聊天机器人最大的问题是“说了就忘”，三句话之后再问前面的信息，它已经开始胡编。有智慧的模型会在上下文窗口内保留关键信息，你说“我最近在准备环湖骑行，每天训练两小时”，十轮之后它还能顺着这个话题问“昨晚的骑行训练完成得怎么样”。这种连续感会强烈暗示用户：对面这个对象是“记得我”的。

第二个体验点是回应感。早期聊天机器人更像问答机，用户问一句，它答一句，对话自然终结。有智慧的模型会在回答末尾追加反问，比如“你目前的路程大概是多远？我可以按这个距离帮你排训练计划”。这一句话就把单向问答改成了双向对话，用户会不自觉继续接话，这才是“上瘾”的直接来源。

第三个体验点是稳定人设。同一个问题，普通模型每次回答风格可能都不一样；有智慧的模型在系统提示词约束下，会保持固定的语气、称呼和表达习惯。用户习惯了它的说话方式之后，会产生类似“和一个老朋友聊天”的舒适感，从而更愿意继续对话。

2.2 技术层：上瘾体验对应的模型机制

记忆感来自上下文窗口。大语言模型处理对话时会把所有历史消息拼成一段 token 序列，模型中能够同时“看到”的信息量就是上下文窗口上限。窗口越大，能记住的对话轮次越多。需要特别注意的是，长上下文不等于长记忆，如果最前面几轮内容超出窗口被截断，模型照样会“失忆”。

回应感来自采样参数和下一条消息的生成策略。temperature 控制随机性，top_p 控制候选词范围，presence_penalty 和 frequency_penalty 控制重复程度。实际使用中，温度偏低会让回答偏保守，但也更稳定；温度偏高会让表达更发散，但可能跑题。追问式结尾通常不需要模型专门训练，只要在系统提示词里写“回答完问题后，追问用户一个相关问题”，模型就能稳定表现出“会聊天”的特质。

稳定人设主要来自 system prompt。系统提示词相当于给整个对话设定一个基础角色和表达约束。你在里面定义“你是一位耐心、简洁、喜欢用具体例子解释问题的骑行教练”，模型就会沿着这个人设输出。很多产品宣传的“人格化聊天”，本质上就是精心维护的系统提示词体系，加上合适的采样参数。

对话能力本身来自对齐训练。现在主流开源模型大多经历了指令微调、RLHF 或 DPO 之类的对齐阶段，目标是让模型更符合人的偏好：更礼貌、更愿意帮助人、更少输出有害内容。这部分训练决定了模型“像不像人”，也决定了它会不会出现过度迎合、说漂亮话但缺少实质内容的问题。

2.3 边界提醒：会聊天不等于回答正确

“有智慧的模型”在体验上会让人上瘾，但技术上的流畅表达、礼貌回应、会反问，都可能掩盖事实错误。模型对话能力强，不代表它在专业领域可靠。尤其是健康、法律、财务这类高风险问题，聊天体验越好，越容易让人放松警惕。后文的功能测试里会单独强调幻觉与稳定性验证，这里先记住一个原则：上瘾的是聊天气氛，核实的必须是事实。

3. 本地部署前的模型选型：先看四个指标

3.1 对话能力与中文质量

如果你主要做中文场景，优先看模型在中文多轮对话上的表现。不同模型的中文语料占比、指令跟随能力和口语化表达水平差异很大。选型时不要只看榜单分数，用自己真实的业务问题各问一遍，重点观察三类问题：第一，它会不会把常识性知识说错；第二，它能不能理解带有口语省略的提问；第三，连续追问时它会不会逐渐跑偏。

3.2 上下文长度

模型上下文窗口决定它能记住多少历史内容。想做“长聊上瘾”体验，上下文长度很关键。如果窗口太小，聊到第 20 轮就把第 1 轮的信息挤出去了，记忆感立刻崩塌。选型时可以关注模型的官方上下文长度说明，再结合实际测试判断。注意：能配置长上下文不等于长上下文一定好用，上下文越长，推理显存和耗时通常也越高，需要平衡。

3.3 硬件门槛

硬件门槛由模型参数量和量化方式决定。同样的模型，全精度权重占用较高，量化后体积和显存占用会下降，但量化程度太深也可能影响输出质量。选型建议是：先用你能买到显存最大的显卡，选一个参数规模适中的量化模型把链路跑通；确认体验达标后，再考虑是否换更大模型。不要一开始就追求 70B 以上级别的大模型，如果显存不够，启动都成问题，更谈不上体验。

3.4 许可证与商用限制

开源模型的许可证差异很大，有的允许商用，有的限制月活用户规模，有的对衍生模型有额外要求。如果你只是本地自用，问题不大；如果要接入产品、提供服务或做商业发布，一定要提前看模型官方仓库的 License 说明。选型阶段省事，后面合规阶段就会还债。这一条经常被忽略，但实际踩坑的人非常多。

4. 环境准备与前置条件

4.1 硬件检查

本地部署一个聊天模型，最需要关注的是显存。显存大小决定你能跑什么规模的模型，也决定同等模型下能配置多长的上下文。在动手之前，先确认你的显卡驱动能被系统识别。NVIDIA 显卡可以在命令行执行nvidia-smi查看显卡型号、驱动版本和当前显存占用；没有 NVIDIA GPU 的机器也可以走 CPU 推理，但速度会慢不少，适合小模型和功能验证。

磁盘空间也要提前规划。大模型的权重文件通常有几个 GB 到几十 GB，量化模型体积会小一些，但加上依赖环境、模型缓存和输出数据，仍然需要预留足够空间。如果使用 Docker 镜像，还需要额外考虑镜像体积。

4.2 软件环境

通用依赖清单如下：

• 操作系统：Windows 10/11、主流 Linux 发行版、macOS 均可，但 GPU 推理在 Linux 下生态最顺。
• Python：建议 3.10 或更高版本，具体以所选推理框架要求为准。
• CUDA 与显卡驱动：如果是 NVIDIA GPU，需要安装匹配的驱动和 CUDA 工具包。
• 深度学习框架：PyTorch 等，不同模型和推理框架对版本有要求。
• 推理框架：可选 vLLM、Ollama、LM Studio、transformers、Docker 镜像等。

环境配置是本地部署里最容易出问题的环节。建议优先选择提供预编译包或 Docker 镜像的推理框架，避免从源码编译。如果某个依赖安装失败，先看错误日志里的版本冲突信息，不要盲目升级或降级。

4.3 端口与模型文件

启动 WebUI 或 API 服务前，先确认端口没有被占用。常见端口比如 7860、8000、11434 等，具体以推理工具的默认配置为准。如果端口冲突，可以在启动参数里指定新端口。

模型文件的位置也需要规划。建议单独建一个models目录存放权重文件，把模型文件、输入素材、输出结果分目录管理。这看起来是小事，后面跑批量任务时会省很多事。

5. 安装部署与启动方式

5.1 路线 A：Ollama 快速体验

如果只是想最快看到一个有智慧的聊天模型效果，Ollama 这类工具是最低门槛的选择。它把模型下载、环境依赖和服务启动封装得比较干净，适合先跑通再研究细节。启动命令类似下面这样，具体模型名和版本以官方模型库为准：

# 安装 Ollama 后，拉取并运行一个对话模型 # 模型名需要按官方模型库中的实际名称替换 ollama run <model-name>

启动后通常在本地提供一个命令行交互界面，也可以配置接口服务。这条路线适合验证“模型到底有没有智慧感”，因为几分钟内就能开始对话。

5.2 路线 B：vLLM 服务化部署

如果目标是接入 API、跑批量任务，或者做二次开发，建议用服务化推理框架。以 vLLM 为例，常见做法是启动 OpenAI 兼容接口服务：

# 通用启动示例，实际命令以 vLLM 官方文档和你的模型路径为准 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-chat-model \ --host 127.0.0.1 \ --port 8000

启动成功后，服务会监听本地 8000 端口，并暴露类似/v1/chat/completions的接口。这条路线的好处是并发能力更强、更适合工程化调用；代价是环境配置复杂度比 Ollama 高。

5.3 路线 C：WebUI 可视化聊天

如果你需要角色设定、历史会话保存、可视化聊天的完整产品体验，可以搭配 WebUI 工具使用。常见的做法是让推理框架只提供底层模型服务，WebUI 负责界面展示和会话管理，两边通过 API 对接。这样可以把“模型能力”和“产品体验”解耦，后面替换模型时不需要改界面。

如果不想折腾环境，也可以选择带 WebUI 的集成包或 Docker 镜像。Docker 方式的通用启动模板如下：

# 用 Docker 启动推理服务的通用示例 # 镜像名、端口和参数需要按实际项目替换 docker run -d --gpus all -p 8000:8000 your-image-name

5.4 启动后的验证清单

无论走哪条路线，启动完成后先做这几步确认：

1. 服务进程是否正常存活，日志有没有报错。
2. 命令行或 WebUI 是否能正常打开。
3. 发一句最简单的测试消息，确认模型能返回内容。
4. 用nvidia-smi或任务管理器看一眼资源占用是否在合理范围。

如果页面打不开或接口报错，优先看启动日志，再检查端口、防火墙和模型路径。

6. 功能测试与效果验证

“有智慧的模型聊天会上瘾”这个判断，可以在本地用一组功能测试来验证。下面五类测试覆盖了记忆、人设、追问、长上下文和稳定性，是评估对话模型的核心维度。

6.1 多轮记忆测试

测试目的：验证模型能否在长对话中记住用户信息。

操作步骤：

1. 先告诉模型一条个人信息，例如“我叫小明，喜欢骑公路车，最近在准备环湖骑行”。
2. 连续追问 10 到 20 轮与主题相关或不相关的问题。
3. 在第 20 轮附近突然问：“我叫什么名字？我最近在准备什么？”

判断标准：能准确回答“小明”和“环湖骑行”，说明上下文管理基本合格。如果回答错误或含糊，说明记忆已经丢失，需要检查上下文窗口配置是否过短，或者历史消息是否被截断。

输入示例：

用户：我叫小明，喜欢骑公路车，最近在准备环湖骑行。 用户：你是不是应该记住我的信息？ 用户：（隔 15 轮）你还记得我是谁吗？

6.2 人设一致性测试

测试目的：验证模型在固定角色设定下，回答风格是否稳定。

操作步骤：

1. 在系统提示词中设定一个人设，例如“你是一位耐心、简洁、喜欢用具体例子解释问题的骑行教练”。
2. 连续问 10 个不同类型的问题，包括训练计划、装备选择、路线建议。
3. 观察回答的语气、句式、称呼是否保持一致。

判断标准：如果每次回答都像同一个人，说明人设生效；如果回答风格忽冷忽热，一会儿专业严谨一会儿口语化，说明系统提示词约束不够，或采样温度偏高。

6.3 追问与开放对话测试

测试目的：验证模型是否能主动推进对话，而不是机械回答问题。

操作步骤：

1. 在系统提示词中加一句“回答完用户问题之后，追问一个相关问题”。
2. 问一个开放性问题，例如“环湖骑行前一周应该怎么安排训练强度？”
3. 观察回答是否在给出建议后追加追问。

判断标准：有追问的模型会让对话自然延续，这是“聊天上瘾”的关键来源。如果没有追问，说明要么提示词没生效，要么模型指令跟随能力偏弱。

6.4 长上下文测试

测试目的：验证模型在不同上下文长度下的表现。

操作步骤：

1. 输入一段较长的资料，例如一篇几千字的骑行训练笔记。
2. 在资料末尾附一个问题，要求模型根据资料中某处细节作答。
3. 再模拟多轮聊天，把总上下文推到接近模型窗口上限的位置，重新问早期信息。

判断标准：短上下文时回答准确，长上下文时开始遗忘或答错，说明上下文窗口极限已经接近。这个测试能帮你确定实际部署时该把最大上下文限制在多少，避免无上限配置导致显存压力过大。

6.5 幻觉与稳定性测试

测试目的：验证模型在专业问题上的事实可靠性，以及多次输出的稳定性。

操作步骤：

1. 准备几个有明确答案的专业问题，例如“环湖骑行 80 公里需要补充多少电解质？”
2. 同一个问题重复问三遍，观察回答是否稳定。
3. 再问一个模型很可能胡编的开放式问题，观察它是否承认不知道，还是强行编造。

判断标准：专业问题答案是稳定合理的；如果模型对没有把握的问题还自信输出，说明幻觉风险偏高。对高风险场景，这个测试结果比聊天体验更重要。

6.6 测试结果记录

建议把每轮测试的问题、模型回答、显存占用、响应时间记录到表格或日志里。后面换模型、调参数时，拿同一组测试用例重新跑一遍，对比结果，能快速判断是变好还是变差。没有记录就没有对比，这是本地模型调优常被忽视的一步。

7. 接口 API 与批量任务接入

7.1 OpenAI 兼容接口

很多本地推理框架都会提供 OpenAI 兼容的聊天接口，这样你不需要重写客户端代码，直接沿用已有的 OpenAI SDK 调用习惯。常见接口路径为/v1/chat/completions，实际以所选项目文档为准。本地服务通常不需要真实密钥，填EMPTY或任意字符串即可。

7.2 Python 调用示例

下面是一个通用调用示例，地址、模型名和参数需要按你的服务配置调整：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", # 根据实际服务地址调整 api_key="EMPTY" # 本地服务通常不需要真实密钥 ) response = client.chat.completions.create( model="my-chat-model", # 模型名以服务端配置为准 messages=[ {"role": "system", "content": "你是一位简洁、耐心的骑行教练。"}, {"role": "user", "content": "环湖骑行前一天应该做什么准备？"} ], temperature=0.7, max_tokens=512 ) print(response.choices[0].message.content)

对应的请求体结构大致如下：

{ "model": "my-chat-model", "messages": [ {"role": "system", "content": "你是一位简洁、耐心的骑行教练。"}, {"role": "user", "content": "环湖骑行前一天应该做什么准备？"} ], "temperature": 0.7, "max_tokens": 512 }

7.3 批量任务脚本设计

如果你手头有一批文本需要交给模型处理，可以直接写脚本循环调用接口。核心设计要点是三件事：控制并发、设置超时、加入失败重试。下面是一个通用模板：

import json import time from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) def ask_one(text, model="my-chat-model"): response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": text}], temperature=0.7, max_tokens=512, timeout=60 ) return response.choices[0].message.content inputs = ["待处理问题1", "待处理问题2", "待处理问题3"] results = [] for index, text in enumerate(inputs): for retry in range(3): try: answer = ask_one(text) results.append({"input": text, "output": answer}) break except Exception as exc: print(f"第 {index} 条失败，第 {retry + 1} 次重试：{exc}") time.sleep(2) else: results.append({"input": text, "output": None}) with open("batch_results.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2)

7.4 批量任务注意事项

批量任务在本地 GPU 上要特别注意并发。单卡显卡能同时处理的请求数量有限，盲目开多线程不一定能提速，反而可能因显存溢出导致服务崩溃。建议设置并发上限为 1 到 4，先压测一条数据，确认稳定后再放开。

另一个建议是把待处理清单放到文件里逐条读取，而不是写在 Python 列表里。这样任务中断后可以从上次进度继续跑，避免重复调用浪费资源。每次调用的结果实时写入日志，方便定位是哪一条输入导致报错。

接口服务默认只监听127.0.0.1时，只有本机能调用。如果需要给局域网内其他机器使用，再修改监听地址；如果要暴露到公网，必须先加鉴权，否则任何人都可以调用你的模型服务，既消耗算力也有内容安全风险。

8. 资源占用与性能观察

8.1 怎么观察资源占用

GPU 显存占用可以用nvidia-smi查看；如果是 Linux 服务器，内存占用可以用free -h查看；Windows 下可以用任务管理器。观察时应区分两个时间点：模型加载完成后的静态占用，以及推理过程中的动态峰值。短对话和长对话的显存占用可能差距很大，只看启动后的一瞬间往往不够。

8.2 哪些因素影响显存和速度

影响资源占用的主要因素有四个：

• 模型参数量：模型越大，权重占用越高。
• 量化位宽：相同模型下，量化位宽越低，权重占用通常越小，但输出质量可能受影响。
• 上下文长度：上下文越长，KV Cache 占用的显存越高。
• 并发请求数：并发越多，显存占用的峰值越高。

推理速度方面，输出 token 数对总耗时的影响非常直接。同样的提示词，max_tokens设置成 128 和 512，耗时差距可能接近四倍。所以如果你想降低响应时间，除了换小模型，更有效的办法之一是控制单次输出长度。

8.3 降低资源占用的手段

如果你的显卡显存比较紧张，可以按顺序尝试这些手段：

1. 优先使用量化模型，而不是追求全精度。
2. 限制最大输出长度max_tokens。
3. 缩短上下文窗口，或定时清理不重要的历史消息。
4. 降低并发请求数。
5. 使用更小的模型，例如从 14B 级降到 7B 级。

需要说明的是，所有显存数字都应以本机实测为准。别人的显卡跑出的占用数据，换一个模型、换一个上下文长度就不适用。网上看到的“某某模型只占 X G 显存”只能作为参考，不能直接拿来当部署依据。

8.4 性能验证建议

在正式使用前，建议做一次基准测试：固定一个问题，分别修改上下文长度、并发数、max_tokens，记录响应时间和显存峰值。这样你能看到自己的显卡在什么配置下最稳。这个基准测试值得保留下来，后续每次调参都跑一遍，形成自己的性能基线。

9. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
启动后页面或接口打不开	端口被占用或服务未启动	查看启动日志；Windows 用netstat -ano | findstr 8000，Linux 用ss -lntp | grep 8000	更换端口，或重启服务
提示显存不足 OOM	模型过大或上下文过长	用nvidia-smi查看显存占用	换小模型、开启量化、缩短上下文、降低并发
对话不记得前文	上下文窗口被截断	查看服务上下文配置	增大上下文窗口参数，或手动压缩历史消息
角色设定不稳定	system prompt 太弱或温度太高	连续追问观察语气变化	强化 system prompt，降低 temperature
输出重复、空洞	采样参数不合适	多次测试观察输出	调整 temperature、frequency_penalty、presence_penalty，参数名以文档为准
接口报 404 或 401	模型名或密钥不匹配	查看服务端日志确认模型名	使用服务端注册的模型名，本地密钥按默认值填写
批量任务卡住	并发过高或超时太短	查看进程日志	降低并发、增加超时、加入失败重试
生成内容与事实不符	模型幻觉	针对专业问题做交叉验证	关键信息接入知识库 RAG 或人工复核，不要直接采信

前三个问题在本地部署中最常见。遇到端口冲突可以直接换端口启动，省去排障时间；显存不足优先换小模型或开量化；上下文丢失则检查服务端配置，不要一味调大窗口，因为窗口变大显存占用也会上升。

10. 最佳实践与使用建议

10.1 从最小配置起步

第一次跑通时，不要追求大模型和高并发。先用小尺寸量化模型、短上下文、单并发把链路跑通，再逐步加大参数。这样一旦出问题，排障范围小，能快速定位是模型问题、显存问题还是接口问题。

10.2 目录与配置管理

建议在项目根目录下建好三个目录：models存放权重文件，inputs存放待处理素材，outputs存放生成结果。启动脚本、接口客户端脚本、测试用例分别保存版本。这样当你反复换模型、调参数时，不会被一堆同名文件搞乱。

10.3 接口服务安全

本地推理服务默认只绑定回环地址最安全。如果团队内部需要共享服务，再监听局域网地址，并加一层访问控制。部署到公网前必须加鉴权，否则任何人都能调用你的模型，既消耗算力，也可能被抓取生成内容，产生合规风险。

10.4 合规、授权与隐私

使用 AI 聊天模型时，要特别注意几个合规边界：

• 不要把自己的隐私信息、客户数据、未公开代码直接发给在线 API 服务；本地部署可以把数据边界控制在自有环境内。
• 涉及人脸、声音、版权素材、他人肖像的生成和处理，必须确认获得合法授权。
• 角色扮演、情感陪伴类对话内容要符合平台规则和公序良俗，不要利用模型生成违规内容。
• 如果要把模型接入商用产品或对外提供服务，需要提前确认模型许可证和输出内容的合规要求。

这些不是套话，是实际部署中很容易被忽略但后果很严重的点。

10.5 控制“上瘾”与事实核验

“有智慧的模型聊天会上瘾”本质上是一种体验设计的结果。对开发者来说，这可以是产品优势；对使用者来说，也要清醒：模型输出的是基于统计的连贯文本，不是经过验证的事实。重要信息必须二次核实。长期依赖单一模型做判断，会削弱对信息的批判性检验能力。

11. 总结与下一步

这个方向最值得尝试的点，是“有智慧的模型体验”不再是玄学。上下文窗口、系统提示词、采样参数、对齐训练，这些技术组合在一起，就能制造出让人愿意长聊的对话对象。你不需要从零训练模型，只要把开源模型部署起来，把测试用例跑一遍，就能理解“上瘾感”的技术来源。

如果是第一次实践，最先验证三个功能：多轮记忆、人设一致性、追问能力。这三个点直接决定了模型有没有“智慧感”。最容易踩的坑也很集中：显存不足、上下文超限、接口模型名和服务端不一致。

后续可以继续扩展的方向很多。给模型接入 RAG 知识库，让它基于你的私有资料回答；调用外部工具或函数，让它能查天气、查时间、操作其他系统；或者设计一个长期记忆层，让模型跨会话记住用户偏好，做一个真正能长期陪伴的私人聊天助手。

跑起来之后，第一个值得做的小实验是：设定一个人设，连续聊 20 轮，看它是否还记得第一轮你告诉它的信息。如果记得住，你就知道“上瘾感”从哪来了。