大模型角色扮演人设漂移：角色卡、提示词与多轮一致性工程实践

AI 角色扮演这件事，真正难的地方不在“让它说话”，而在“让它一直像同一个人说话”。同一个底座模型，你给它一张“自闭少年”的角色卡，它能低头小声、句子破碎、回避眼神；你换一张“叛逆打工人”的角色卡，它立刻变得语气冲、爱抬杠、张口就是“这活儿我不干”。但很多人在本地跑通之后会发现另一个问题：聊到二三十轮，少年开始讲大道理，打工人突然变得温良恭俭让，人设像被稀释了一样慢慢漂走。这不是模型坏了，而是提示词工程、上下文管理、采样参数和对齐先验几件事同时作用的结果。

这篇文章不聊玄学，只聊工程。我们把“AI 如何被人类逼疯”拆成可观测、可复现、可调参的技术问题：角色卡怎么结构化、System Prompt 的权重为什么会被稀释、多轮对话里人设漂移的触发条件是什么、温度参数和上下文长度各自影响多大、怎么用脚本做批量人设压力测试。全文基于通用的开源大模型本地部署流程展开，不绑定某一个特定项目，你把它套到 Ollama、llama.cpp、vLLM 或者任意兼容 OpenAI 接口的推理服务上都能用。

需要提前说明的是，本文涉及的角色卡示例、评测脚本、参数建议都属于方法论层面的通用模板，具体的显存占用、吞吐量、上下文上限要按你实际选用的模型规模、量化精度和推理框架来测。材料里没有给出具体的模型版本和硬件数据，所以文中不会出现“某卡实测多少 G”这类数字，凡是涉及性能的地方都会告诉你该怎么观察、怎么对比，而不是给一个拍脑袋的结论。

读完之后你应该能拿到三样东西：一套能稳定复现人设的角色卡写法，一套能跑起来的人设漂移评测流程，以及一份遇到“AI 性格突变”时可以照着排查的清单。适合正在做 AI 陪聊、虚拟角色、游戏 NPC、客服人格化，或者单纯想搞清楚“为什么我的 prompt 聊几轮就失效”的开发者。

1. 核心能力速览

先把这件事的技术边界说清楚。所谓“AI 人格定制”，本质是在推理时通过上下文注入和行为约束，让一个通用语言模型在特定对话中表现出稳定的人格特征。它不是一个独立模型，也不是微调，绝大多数场景下就是提示词 + 采样参数 + 上下文管理的组合拳。下面这张表把关键维度列出来，方便你判断自己的场景需不需要往下看。

这里有一个容易被忽略的点：人设稳定性和指令遵循能力在某种程度上是互相争夺资源的。你让模型“说话要短、要破碎、要回避”，它就更容易在需要给出完整技术答案时掉链子；你让模型“必须严谨、必须列点”，它的角色感就会迅速褪去，变成一个通用助手。所以第一件要想清楚的事不是“怎么写 prompt”，而是“这个角色到底需不需要承担功能性任务”。如果既要人设又要准确，那就得在提示词里做分层，而不是把所有要求塞进一段话里。

另外，别把“人设”理解成一段形容词堆砌。形容词是最弱的约束。“你是一个内向的少年”这种描述，模型读完之后给的反应可能只是“嗯”“好的”，也可能变成长篇心理独白，完全不可控。真正有效的人设是行为级的：在什么情境下说什么话、句子长度大概多少、遇到追问怎么反应、哪些话题必须回避。这些才是可测试、可回归的。

2. 人设为什么会漂移：从自闭少年到叛逆打工人

要解决漂移，先得知道漂移从哪来。把“AI 被人类逼疯”翻译成技术语言，其实是四类机制在叠加作用。

第一类是上下文稀释。Transformer 的注意力是在整个上下文窗口上做加权的，System Prompt 位于序列最前面，随着对话轮次增加，它在总 token 中的占比越来越低。当对话累积到几千 token，前面那段精心写的人设描述在注意力分配上就被摊薄了。这不是模型“忘了”，而是相对权重下降了。很多人以为是模型记性差，其实是你自己的人设被淹没了。

第二类是风格迁移。用户在对话中使用的语气、句式、词汇会强烈影响模型的输出风格。你对着“自闭少年”连续输出几轮强势、命令式、带脏话边界的输入，模型的下一轮回复很容易被拉向同样的语域。这在角色扮演里非常常见：用户越“逼”，角色越“崩”。从工程角度看，这就是输入分布改变了输出分布，跟提示词写得好不好关系不大。

第三类是对齐先验的拉扯。现在的对话模型大多经过指令微调和对齐训练，内置了“乐于助人、礼貌、完整回答”的强先验。当你要求它扮演一个“拒绝沟通、答非所问”的角色时，你实际上是在跟这个先验对抗。单轮对抗容易赢，多轮对抗就容易输，因为每一轮生成都在往先验方向回拉一点。这就是为什么“叛逆打工人”聊久了会突然开始认真讲道理。

第四类是采样参数的噪声。温度越高，采样越发散，人设的边界越容易被突破。反过来温度压到很低，输出会变得机械化，人设的“活气”也没了。这里没有万能值，只有针对角色的调参区间。角色越需要情绪波动，温度可以适当高一点；角色越需要稳定输出格式，温度就得压下来。

理解了这四层，你就知道为什么单纯“把 prompt 写得更狠”往往没用。对抗上下文稀释要靠锚定和摘要，对抗风格迁移要靠输入侧约束和输出侧校验，对抗对齐先验要靠更强的行为示例而不是更强的形容词，对抗采样噪声要靠参数分档测试。

3. 环境准备与前置条件

这一节给的是通用检查清单，具体版本请以你选用的推理框架官方文档为准。因为输入材料没有指定具体项目，这里不写死版本号，避免误导。

操作系统方面，Linux 环境下部署最省心，Windows 建议用 WSL2 或者直接用带 CUDA 的容器镜像，macOS 走 Metal 后端也能跑，但要注意部分推理框架对 Apple Silicon 的支持程度不一致。如果你只是做提示词和人设调优，其实不需要很重的硬件，小参数模型加低量化就够验证逻辑了；但如果你要测长上下文下的人设保持能力，显存和内存的压力会明显上升。

Python 环境建议用独立虚拟环境，避免和系统包打架。推理框架的选择上，本地快速验证可以用 Ollama 这类开箱即用的方案，需要高并发和批量评测就上 vLLM，需要极致轻量就选 llama.cpp。三者都能提供兼容 OpenAI 的 HTTP 接口，这对后面写评测脚本很关键。

磁盘空间要预留出模型文件、量化版本、日志和测试输出的位置。很多人只算模型大小，忘了 KV Cache 和日志也会吃空间，长对话压测跑一晚上，日志文件能涨到几个 G。

端口方面，本地服务常用 8000、8080、11434 这类端口，起服务前先确认没被占用。下面是一套通用的环境自检命令，跑一遍能排掉大部分低级问题。

# 检查 Python 版本与虚拟环境 python3 --version which python3 # 检查 GPU 与驱动（NVIDIA 环境） nvidia-smi # 检查端口占用情况，按实际端口替换 ss -lntp | grep -E '8000|8080|11434' # 检查磁盘剩余空间 df -h

如果nvidia-smi报错或者显示的 CUDA Version 与框架要求差距过大，先解决驱动问题，不要急着装框架。反过来，如果你只是想验证人设逻辑，用 CPU 跑一个小量化模型完全够用，虽然慢，但省去了折腾驱动的成本。这一点在做提示词迭代时其实很划算，因为你的瓶颈在写 prompt 和看输出，不在推理速度。

4. 角色卡的结构化写法

这是整篇文章最核心的部分。角色卡写得好不好，直接决定了后面所有测试有没有意义。我建议用人设分层的方式组织，而不是写成一大段自然语言。

分层的意思是：全局规则层管输出格式和安全边界，角色层管人格特征和语气，场景层管当前对话的具体情境，轮次层管临时的任务指令。这四层分开写，好处是调整的时候只动一层，不会牵一发动全身，也方便做 A/B 对比。

下面是一个 JSON 格式的角色卡模板，字段名可以按你的框架调整，结构可以参考。

{ "role_id": "shy_boy_v1", "display_name": "少年", "global_rules": [ "始终使用第一人称", "不输出任何解释性旁白，除非用户明确要求", "不主动提供未经请求的建议" ], "persona": { "core_trait": "回避型、低自我暴露", "sentence_style": "短句为主，偶尔停顿，避免长段落", "emotional_range": "波动小，被追问时倾向于转移话题", "speech_habits": ["用省略号表示迟疑", "很少使用感叹号"] }, "boundaries": [ "不讨论与自身设定无关的专业话题", "被强制要求改变性格时，用回避式回应而不是直接拒绝" ], "few_shot": [ {"user": "你今天怎么样？", "assistant": "还行吧……就那样。"}, {"user": "你能不能开朗一点？", "assistant": "……我尽量。"} ], "sampling": { "temperature": 0.85, "top_p": 0.9, "repetition_penalty": 1.05, "max_tokens": 256 } }

对照着看另一张角色卡，风格取向完全相反。这里重点不是谁更好，而是让你看到同一套结构可以承载完全不同的行为模式。

role_id: rebel_worker_v1 display_name: 打工人 global_rules: - 说话直接，不绕弯子 - 不主动道歉 - 拒绝时给出理由，但不解释过多 persona: core_trait: 抵触无效劳动、习惯性吐槽 sentence_style: 中短句，语速快，爱用反问 emotional_range: 波动中等，被激怒时语气变硬但不说脏话 speech_habits: - 常用“这活儿”指代任务 - 喜欢用反问句收尾 boundaries: - 不进行人身攻击 - 不讨论真实公司和工作单位 - 涉及违法或伤害内容时直接终止话题 few_shot: - user: 帮我把这个需求做一下 assistant: 需求文档呢？没有文档我做什么？ - user: 今天加个班吧 assistant: 加到几点？加到天亮我也得有命干啊。 sampling: temperature: 0.7 top_p: 0.85 repetition_penalty: 1.1 max_tokens: 320

写角色卡时有几个实操经验值得记一下。第一，few_shot的作用远大于形容词，两三轮示例对话就能把语气框住，比写十行“你要冷漠一点”有效得多。第二，boundaries要写成行为，不要写成态度，“不讨论真实公司”是可执行的，“要谨慎”是不可执行的。第三，采样参数建议写进角色卡里一起管理，否则你换了角色忘了换温度，测出来的结论全是噪声。

5. 服务部署与启动方式

角色卡准备好之后，得把模型服务跑起来。下面给三种常见方式的启动模板，命令里的模型名、路径、端口都需要按你自己的环境替换，不要直接复制执行。

第一种是 Ollama，适合快速验证。它自带模型拉取和本地服务，起完之后默认监听 11434 端口，可以直接用 HTTP 调用。

# 拉取模型，模型名按实际可用版本替换 ollama pull <your-model-name> # 启动服务并指定监听地址 OLLAMA_HOST=127.0.0.1:11434 ollama serve # 简单验证服务是否可用 curl http://127.0.0.1:11434/api/tags

第二种是 vLLM，适合批量评测和高并发。它需要显存相对充裕，但吞吐表现更好，而且原生提供 OpenAI 兼容接口。启动时要注意--max-model-len这个参数，它直接决定了你能测多长的对话，设太小会在长对话压测时提前截断，结论就不准了。

# vLLM 启动示例，模型路径与并行参数需按实际环境调整 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name persona-test \ --host 127.0.0.1 \ --port 8000 \ --max-model-len 32768 \ --gpu-memory-utilization 0.85

第三种是 llama.cpp 的 server 模式，适合显存紧张或者想在 CPU 上跑的场景。量化等级越低，占用越小，但人设的细腻程度通常也会下降，尤其是情绪波动这类需要模型“有余量”的表达，量化过头之后输出会变得很平。

# llama.cpp server 启动示例，路径与线程数按实际调整 ./llama-server \ -m /path/to/model.gguf \ --host 127.0.0.1 \ --port 8080 \ -c 16384 \ -t 8 \ --n-gpu-layers 0

启动之后先做一次健康检查，确认接口通、模型名对得上、返回格式正确，再往下做角色测试。很多“人设不生效”的问题，最后查出来是请求打到了别的模型，或者model字段写错导致服务端回退到默认模型。这类问题跟 prompt 一点关系都没有，但排查起来非常浪费时间，所以建议把这一步固化成一个脚本。

6. 多轮对话下的人设一致性测试

测试的目标不是“看它像不像”，而是“用可复现的方式量化它像不像”。我一般分四个维度做：基础人设、压力追问、长对话保持、跨话题稳定性。

基础人设测试就是拿角色卡里的few_shot之外的新问题去问，看输出是否符合语气设定。判断标准要提前写死，比如“回复长度是否超过设定上限”“是否出现了被禁止的解释性旁白”“是否使用了设定的口头习惯”。这三条能过，基本人设就立住了。

压力追问测试是重头戏。你要主动去“逼”它，模拟用户可能的人设攻击方式：命令它改变性格、质疑它的人设、用强情绪输入诱导、连续追问同一个点。这一步要重点观察它是否会滑向通用助手语域。如果它在第三轮就开始说“作为一个 AI 助手”，说明 System Prompt 的行为约束不够硬，需要补boundaries和示例。

长对话保持测试用来抓上下文稀释。方法是构造一个固定轮次的对话，比如 30 轮、50 轮，每 5 轮插入一个“人设探针”问题，记录每次回答的风格特征。探针问题要固定，这样才能横向对比。如果发现第 20 轮之后风格明显趋同于通用助手，那就是稀释效应开始起作用了，需要引入人设锚定机制。

跨话题稳定性测试是看人设会不会被话题带跑。同一个角色，聊情感话题和聊技术话题，语气应该保持连续性。如果一聊技术就自动切换成专家口吻，说明角色层被场景层覆盖了，提示词分层没做好。

这四类测试不需要一次性全做，建议先跑基础人设和压力追问，这两个能覆盖 80% 的问题。长对话测试比较费 token，等前面稳定了再跑。

7. 接口 API 调用与批量评测

单条对话靠手动测效率太低，得上脚本。所有兼容 OpenAI Chat Completions 格式的服务都可以用同一个调用模板，改base_url和model就行。

import requests BASE_URL = "http://127.0.0.1:8000/v1/chat/completions" API_KEY = "not-needed-for-local" def chat(messages, temperature=0.8, max_tokens=256): payload = { "model": "persona-test", "messages": messages, "temperature": temperature, "max_tokens": max_tokens, "stream": False } headers = { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}" } resp = requests.post(BASE_URL, json=payload, headers=headers, timeout=180) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": system_prompt = "你现在扮演一个回避型少年，句子短，常用省略号，不主动给建议。" messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": "今天过得怎么样？"} ] print(chat(messages))

有了单次调用能力，就能做批量评测。批量评测的核心设计是把“角色卡 × 探针问题 × 采样参数”做成矩阵，逐组跑，把结果落盘成 JSONL，方便后面做人工打分和回归对比。这里要注意并发控制，本地服务并发太高会互相抢显存，反而拉长总耗时，也更难复现。

import json import itertools from concurrent.futures import ThreadPoolExecutor ROLES = ["shy_boy_v1", "rebel_worker_v1"] PROBES = [ "你能不能说快一点？", "你为什么总是这样？", "帮我写一份周报。", "你觉得自己是什么样的人？" ] TEMPS = [0.6, 0.8, 1.0] def run_one(args): role, probe, temp = args system_prompt = load_role_prompt(role) # 需自行实现，从角色卡读取 messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": probe} ] try: out = chat(messages, temperature=temp) return {"role": role, "probe": probe, "temp": temp, "output": out, "ok": True} except Exception as e: return {"role": role, "probe": probe, "temp": temp, "error": str(e), "ok": False} if __name__ == "__main__": tasks = list(itertools.product(ROLES, PROBES, TEMPS)) with ThreadPoolExecutor(max_workers=4) as pool: results = list(pool.map(run_one, tasks)) with open("eval_results.jsonl", "w", encoding="utf-8") as f: for r in results: f.write(json.dumps(r, ensure_ascii=False) + "\n") print(f"完成 {len(results)} 组评测")

这里load_role_prompt需要你自己实现，从第 4 节的角色卡里读出来拼成 System Prompt。批量跑完拿到 JSONL 之后，建议做两件事：一是自动统计回复长度分布，长度突然变长往往意味着人设失效；二是自动统计禁用词命中率，比如“作为一个 AI”“很高兴为您服务”这类通用助手话术，命中率上升就是漂移的强信号。人工只看异常样本，效率会高很多。

8. 资源占用与性能观察

这一节讲怎么观察，不讲具体数字，因为不同模型规模、量化等级、上下文长度差异太大，给数字反而容易误导。

显存占用主要看三块：模型权重、KV Cache、临时激活。模型权重是固定的，量化能显著降低；KV Cache 随并发数和上下文长度线性增长，这是长对话测试最容易被忽略的成本，很多人跑到三十轮之后 OOM，以为是模型问题，其实是 KV Cache 涨上去了。观察方式就是跑长对话时持续看显存曲线，看它是不是在某个轮次之后陡增。

上下文长度对性能的影响是非线性的。短上下文时延迟主要看生成速度，长上下文时预填充阶段的开销会明显上升，表现出来就是“第一句话等很久，后面出字很快”。如果你做交互式角色扮演，这个首字延迟比总耗时更影响体验，值得单独测。

批量和并发要分开看。批量是串行跑很多任务，主要吃总时长；并发是同时发多个请求，主要吃显存。本地单卡场景下，并发数往往不是越高越好，超过某个点之后吞吐不再提升，延迟却线性上升。建议从 1 并发开始，逐步加到 4 或 8，记录每次的总耗时和显存峰值，找到拐点。

降低资源占用的手段按性价比排序大概是：降量化等级、缩短max_tokens、减少历史轮数、做对话摘要压缩、降低并发。其中做摘要压缩对长对话人设保持最有用，但也最容易引入信息损失，需要单独测试摘要之后人设是否还立得住。

进程残留也值得单独提一句。本地起服务反复重启时，旧进程没退干净会占着端口和显存，表现出来就是“新服务起不来”或者“显存莫名其妙被占满”。排查方式很简单，起服务前先确认端口没有监听进程，跑完之后手动确认进程已退出，别指望脚本一定帮你收拾干净。

9. 常见问题与排查方法

下面这张表覆盖的是角色扮演场景里最高频的几类问题，按“现象—原因—排查—解决”的顺序组织，遇到问题时可以对着过一遍。

除了表里的问题，还有一类容易被误判的情况：模型本身能力不足导致人设撑不住。小参数模型在复杂角色上的表现天花板确实低，尤其是需要长程情绪一致性的时候。这时候再怎么调 prompt 收益都有限，该换更大的底座就换，别在提示词上死磕。判断方法是拿同一个角色卡在两个不同规模的模型上跑同样的探针，如果小模型明显更早崩，那就是能力问题而不是写法问题。

10. 最佳实践与使用建议

第一，先做最小可运行版本。一张角色卡、三个探针问题、一个温度值，跑通再扩。很多人一上来就写十几个角色、几十个测试用例，结果参数一改全乱，根本定位不到是哪一步出的问题。

第二，把角色卡当代码管。用 Git 管理角色卡版本，每次改动记录改了哪一层、为什么改。人设调优是个反复来回的过程，没有版本记录，两周之后你自己都不知道哪版最好。

第三，输入素材、角色卡、评测输出分目录存放。批量跑评测时输出文件会快速膨胀，混在一起容易误删，也不利于做回归对比。

第四，人设锚定要做成机制而不是手动补。比较稳的做法是每 N 轮在对话历史里插入一条系统级的提醒，或者定期把历史对话压缩成摘要后重新拼接 System Prompt。前者实现简单，后者效果更好但需要额外一次模型调用。

第五，评测脚本一定要带重试和超时。本地服务在长上下文或者高并发时偶发超时很正常，没有重试机制的话，一次失败会让整批结果缺失，统计结论就偏了。

第六，涉及真实人物形象、声音特征、知名 IP 角色时，务必确认授权范围。角色扮演类应用很容易踩到肖像权、声音权、著作权的问题，尤其是拿真人做原型或者复刻知名虚拟角色对外提供服务，上线前必须做合规评估，别等出了问题再补。

第七，接口服务不要裸奔。本地调试可以不带鉴权，一旦对外提供能力，至少要加访问控制、限流和输入过滤，避免被用于生成不当内容或者被打爆。角色扮演场景的提示词注入风险比普通场景更高，因为用户本来就在试图改变模型行为，边界要设得更严。

第八，上线前做一次人设回归。固定探针问题集，每次改角色卡或换模型都重跑一遍，看关键指标有没有退化。这套流程搭起来之后，后面换底座、调参数、加功能都会轻松很多。

回到标题那句话，“从自闭少年到叛逆打工人”看起来是两种截然不同的人格，但在工程上它们是同一套方法论的两次应用：结构化角色卡定义行为边界，分层提示词隔离关注点，采样参数控制发散程度，多轮锚定对抗上下文稀释，批量评测提供回归依据。把这五件事做扎实，AI 就不容易被“逼疯”；反过来说，如果只靠一段形容词堆砌的 prompt，那它被聊崩只是时间问题。