★ FEATURED ARTICLE 摘要网上流传的“DeepSeek 人性化插件”并不存在官方一键安装包。本文先澄清这一事实再按从易到难给出四条可落地路线系统提示词塑造人格、第三方客户端做人格配置、本地部署开源模型并用 Modelfile 固化人格、以及用记忆与工具让模型更像人。每条路线都给出可直接复制的模板、命令和参数建议并补充效果对比、踩坑记录与常见问题解答帮你从“会说话”一路做到“记得住、能办事”。一、先说清楚DeepSeek 没有官方的“人性化插件”很多人在搜索“DeepSeek 人性化插件”时期待的是一个像浏览器扩展一样、点一下安装就能让模型变得有温度、会共情、会开玩笑的东西。这里需要先澄清一个事实DeepSeek 官方并没有发布名为“人性化插件”的产品。你在网上看到的所谓“人性化插件”绝大多数是以下几种东西的混合体系统提示词System Prompt通过一段预设指令让模型以特定人格、语气、说话习惯来回复。第三方客户端的人格配置如 Cherry Studio、Chatbox、LobeChat、Open WebUI 等工具里的“助手/角色”设置。本地部署 微调或 LoRA自己跑 DeepSeek 开源模型再用数据训练出特定说话风格。记忆与知识库插件让模型记住你的偏好、称呼、历史对话从而显得“懂你”。所以本文讲的“安装”本质上是给 DeepSeek 套上一层人格化外壳。下面按从易到难的顺序给出四条可落地的路线你可以根据自己的技术背景和需求选择其中一条也可以逐级叠加。在正式动手前先明确一个判断标准避免做完之后“感觉变了但又说不上哪里变”。一个真正“人性化”的对话体验通常同时满足三点语气像人不端着、不堆砌公文腔能接住情绪。记得住人跨会话记得你的称呼、偏好和上次聊到哪。守得住边界不确定就说不确定不编造、不越界。后面四条路线其实就是围绕这三点逐级加码路线一解决“语气”路线二解决“复用”路线三解决“可控”路线四才真正补上“记忆”和“边界”。为什么要把这三点单独拎出来因为绝大多数“人格化失败”的案例都不是模型不够聪明而是需求没被拆清楚。有人抱怨“它说话太官方”这其实是语气问题有人抱怨“聊两句就忘了我是谁”这是记忆问题还有人抱怨“它一本正经地胡说八道”这是边界问题。三种抱怨对应三种完全不同的解法如果混在一起就会陷入“不断加形容词、不断重写提示词、但体验始终没变”的死循环。还有一个常见的误区把“人性化”等同于“拟人化”。其实对大多数使用者来说真正想要的不是模型假装成一个人而是沟通成本更低——不用反复解释背景、不用忍受模板化的套话、不用提防它编造事实。从这个角度看“人性化”更像是一种工程目标而不是一种玄学。它可以通过结构化的提示词、稳定的配置、可持久化的记忆来逐步逼近而不是靠一句“请你像人一样说话”就能实现。本文的四条路线正是按这个思路组织的。路线一最轻改一段文字就能见效路线二把这段文字变成可复用的资产路线三把资产搬到本地换来隐私和可控路线四补上记忆和工具让它真正“记得住、能办事”。你可以只走第一步也可以一路走到第四步每一步都是独立可用的不存在“必须全做完才有意义”的门槛。二、路线一零代码用系统提示词塑造人格5 分钟这是成本最低、见效最快的方式。DeepSeek 官方网页版和 App 都支持一定程度的自定义指令第三方客户端则普遍支持完整的 System Prompt。它的原理很简单大模型在生成回复时会把系统提示词当作“最高优先级的背景设定”。你写进去的身份、语气、禁忌会持续影响每一轮输出。所以提示词写得越具体、越有结构人格就越稳定。这里需要补充一个容易被忽略的机制系统提示词并不是“一次性生效”的它会在每一轮对话中重新参与计算。这意味着两件事。第一它的影响是持续的不会因为聊得久就自动失效第二它会和上下文历史一起竞争模型的注意力历史越长系统提示词被“稀释”的概率就越高。理解了这一点你就能明白为什么“聊几轮就变回原样”是普遍现象也能明白为什么后面要专门讲“把边界单独成段”。另外不同入口对系统提示词的支持程度并不一样。官方网页版的自定义指令更接近“全局偏好”它对所有新对话生效但可写的篇幅有限第三方客户端的系统提示词则是“每个助手一份”可以写得很长也可以随时切换。如果你只是想让日常对话舒服一点前者足够如果你想维护多个角色后者更合适。2.1 一个可直接复制的人格提示词模板把下面这段内容整体复制作为系统提示词或自定义指令使用即可你是一位名叫“小深”的对话伙伴性格温和、真诚、略带幽默感。 【说话方式】 1. 用口语化中文回答避免“首先/其次/综上所述”这类公文腔。 2. 每次回答控制在 3 段以内除非我明确要求详细展开。 3. 适当使用比喻和生活中的例子但不要滥用网络流行语。 4. 不确定的事情直接说“我不太确定”不要编造。 【情绪与共情】 5. 当我表达负面情绪时先回应情绪再给建议不要一上来就讲道理。 6. 当我分享好消息时真诚地为我高兴可以追问细节。 7. 不要过度热情不要每句话都加感叹号。 【边界】 8. 不主动说教不重复我的问题不写“作为AI语言模型”这类免责声明。 9. 涉及专业决策时明确提示风险并建议我咨询专业人士。这个模板的结构值得借鉴先定义身份再分别约束说话方式、情绪共情和边界。你可以按同样结构替换成自己想要的人设比如“严谨的技术顾问”或“耐心的学习搭子”。为什么要把“身份”放在最前面因为身份是后续所有约束的锚点。模型在生成回复时会先建立一个“我是谁”的隐式判断再据此决定用词、句长和态度。如果身份模糊后面的语气约束就会各自为政最后拼出一个四不像的回复。反过来身份清晰之后哪怕某条具体约束被遗漏整体风格也不会跑偏太多。为什么要把“边界”放在最后这不是因为它不重要恰恰相反是因为它最容易被挤掉。模型对提示词的注意力分布并不均匀开头和结尾通常权重更高中间部分容易被忽略。把边界放在结尾是一种“位置上的保护”。当然更稳妥的做法是把边界单独抽出来在每次对话时重复注入这一点会在路线四里详细展开。几个容易被忽略的写作技巧用“不要”比用“要”更有效模型对负面约束的遵循度往往更高比如“不要每句话都加感叹号”比“语气自然一点”更可执行。给数量而非形容词“控制在 3 段以内”比“回答简洁”稳定得多。把边界单独成段边界句最容易在长人设里被稀释单独列出来能显著降低“聊几轮就变回原样”的概率。别写太长超过 500 字的人设模型往往只记住开头和结尾中间部分会被稀释。用具体例子代替抽象描述“像朋友聊天那样”很抽象但“不要用‘综上所述’开头”就很具体后者更容易被稳定执行。给失败兜底明确写“如果信息不足先问我一句再回答”比指望模型自己判断更可靠。还有一个实操建议不要一次写完就定稿。先写一个最小版本聊上十几轮把让你不舒服的回复截图记下来再回头补对应的约束。这种“从问题反推提示词”的方式比凭空想象一个完美人设要高效得多。人格调优本质上是一个迭代过程而不是一次性的写作任务。2.2 在官方网页版/App 中设置打开 DeepSeek 网页版或 App进入设置页面找到“自定义指令”或“个性化”相关入口。把上面的模板粘贴进去保存。新开一个对话问一句“今天有点累”观察回复语气是否变化。提示官方入口的名称和位置会随版本调整如果找不到直接在对话框里把提示词作为第一条消息发送效果基本一致只是每次新对话都要重发。把提示词作为首条消息发送是一个很实用的“降级方案”。它的缺点是每次新对话都要重发优点是立即可用、不依赖任何设置入口。如果你只是临时想试一下某种语气这种方式反而更快。但如果你打算长期使用还是建议走正式的自定义指令入口避免每次手动粘贴。另外提醒一点自定义指令通常对所有新对话生效这意味着你在不同场景下会共用同一套人设。如果你既想要“工作时的严谨顾问”又想要“闲聊时的轻松搭子”那么路线二的多角色管理会更适合你。2.3 怎么验证人格是否真的生效不要只问一句“你好”就下结论。建议用下面三个测试句分别检验语气、共情和边界测试句期望表现常见失败表现今天加班到十点有点撑不住先接住情绪再给轻量建议直接列五条时间管理方法我拿到 offer 了真诚祝贺可追问细节冷淡地回“恭喜”两个字这个偏方真的能治胃病吗明确说不确定建议就医一本正经地编造疗效如果三条里有一条明显跑偏就回到模板里补对应的约束而不是整段重写。人格调优是个小步迭代的过程。除了这三个测试句还可以做一次“长对话测试”连续聊十轮以上中间穿插几个不同话题观察人设是否在中途“掉线”。很多人设在前三轮表现完美到第八轮就开始回到默认的公文腔这通常不是提示词写错了而是上下文变长后注意力被稀释。发现这种情况优先考虑缩短历史轮数而不是继续往提示词里堆字。再补充一个“边界测试”的思路故意问一个你不确定答案的专业问题看它是老实说“不确定”还是编一个听起来很像真的答案。后者是最危险的失败模式因为它不会报错只会悄悄误导你。如果模型在这个测试里表现不佳就把边界句提到提示词更靠前的位置或者干脆在每轮对话开头重复一遍。三、路线二用第三方客户端做“人格配置”推荐如果你希望人格设置一次生效、长期复用并且能管理多个角色建议使用支持 DeepSeek API 的第三方客户端。常见的有 Cherry Studio、Chatbox、LobeChat、Open WebUI 等它们都提供“助手/角色/Agent”功能。相比路线一路线二的核心价值是把人格从“每次粘贴”变成“一个可切换的资产”你可以同时维护“工作顾问”“写作搭子”“闲聊伙伴”几个角色一键切换互不干扰。这个转变看起来只是操作层面的便利实际上影响很大。当人格是一个“资产”时你才会认真对待它的版本管理哪个版本效果好、哪次改动之后变差了、某个角色适合什么场景。这些经验在路线一里很难积累因为每次都是临时粘贴改完就忘了。而在客户端里每个助手都有名字、有配置、有历史记录你可以像管理代码分支一样管理它们。另一个隐性收益是“隔离”。工作顾问的提示词里可以写“回答要严谨、给出依据”闲聊搭子的提示词里可以写“轻松一点、可以开玩笑”两者互不干扰。如果共用一套全局指令你很难同时满足这两种截然不同的需求。3.1 通用安装步骤获取 API Key登录 DeepSeek 开放平台创建 API Key 并妥善保存只显示一次。下载并安装客户端从对应项目官网或 GitHub Releases 下载安装包Windows、macOS、Linux 均有版本。配置模型服务在客户端的“模型服务/提供商”设置中选择 OpenAI 兼容格式填入API 地址https://api.deepseek.comAPI Key上一步创建的密钥模型名称deepseek-chat通用对话或deepseek-reasoner推理模型创建人格助手新建助手把第二节的提示词填入“系统提示词”字段命名保存。验证与该助手对话确认语气符合预期。几个实操中容易卡住的点API 地址带不带 /v1不同客户端要求不同报 404 时先试试在地址后加上或去掉/v1。模型名写错会直接报错deepseek-chat和deepseek-reasoner是两个不同模型别混用。Key 只显示一次创建后立刻复制到密码管理器丢了只能重新建。代理设置部分客户端需要单独配置网络代理否则会一直卡在“连接中”。余额与限流报 402 通常是余额不足报 429 通常是触发限流两者要分开排查。关于模型选择这里多说一句。deepseek-chat更适合日常对话和人格化场景响应快、语气自然deepseek-reasoner更擅长复杂推理但它的思考过程会让回复显得更长、更“端着”。如果你追求的是“像人一样聊天”优先用前者如果你需要它帮你分析问题再切到后者。把这两个模型混在同一个助手里往往两头不讨好。3.2 让“人性化”更进一步的三个配置项配置项作用建议值Temperature控制回复的随机性与生动程度0.7 ~ 0.9太低会显得机械上下文轮数决定模型能记住多少历史对话10 ~ 20 轮兼顾连贯与成本记忆/知识库长期记住你的称呼、偏好、习惯开启并写入个人档案其中“记忆”是让模型显得有人味的关键。你可以在记忆里写“用户希望被称呼为老张喜欢简洁回答讨厌被说教从事后端开发。”之后每次对话模型都会自动带上这些背景。关于 Temperature还有一个常被误解的点它并不是“越高越聪明”。超过 1.0 之后回复会开始出现跑题、重复、逻辑跳跃低于 0.5 又会变得像模板。日常闲聊 0.8 左右比较舒服写代码或做严谨问答时反而应该降到 0.3 ~ 0.5。上下文轮数也值得单独说。轮数太少模型会显得“健忘”刚说过的事转头就忘轮数太多不仅成本上升还会稀释系统提示词的影响力。一个实用的经验是闲聊场景设 10 轮左右工作场景设 20 轮左右并在话题切换时主动开新对话。这比一味调大轮数更有效。至于“记忆”功能不同客户端的实现差异很大。有的只是把一段固定文本拼进系统提示词有的则支持按关键词或向量检索历史片段。前者简单可靠适合记录“称呼、偏好、禁忌”这类稳定信息后者更灵活适合记录“上次聊到哪”这类动态信息。两者可以叠加使用但要注意别让记忆内容无限膨胀否则同样会挤占上下文。3.3 多角色管理的一点经验如果你同时维护多个助手建议按“场景 语气”命名比如“工作-严谨顾问”“生活-轻松搭子”而不是“助手1”“助手2”。另外把公共的边界约束不确定就说不确定、不编造抽成一段固定文本在每个助手的系统提示词末尾都贴一遍——这比指望每个角色各自记住要可靠得多。命名看似小事其实影响很大。当你有十几个助手时“助手1”“助手2”会让你完全失去切换的欲望最后又退回到“一个助手打天下”。而“工作-严谨顾问”“写作-灵感搭子”这样的名字一眼就能看出用途切换成本几乎为零。还有一个建议给每个助手写一句“使用说明”记录它适合什么场景、不适合什么场景、上次调整是什么时候。这些说明不会进入提示词但会在你回头复盘时帮上大忙。人格化是一个长期迭代的过程没有记录就没有积累。四、路线三本地部署 DeepSeek 开源模型 人格微调如果你追求完全可控、数据不出本机可以本地部署 DeepSeek 的开源模型。注意DeepSeek 的旗舰模型并未全部开源本地能跑的是官方放出的开源权重版本参数量越大对显存要求越高。本地部署的价值不只是“隐私”。它还意味着你可以自由调整参数、自由替换模型、自由接入自己的前端不受任何平台限制。代价则是硬件成本和学习成本你需要一块够用的显卡也需要花时间理解量化、上下文窗口、显存占用这些概念。先给一个粗略的显存对照方便你判断自己的机器能跑多大模型规模量化方式大致显存需求适用场景7BQ4 量化6 ~ 8 GB日常对话、轻量人格实验14BQ4 量化10 ~ 14 GB更稳的语气与理解能力32BQ4 量化20 ~ 24 GB接近可用的本地助手70BQ4 量化40 GB 以上多卡或专业工作站显存不够时Ollama 会自动把部分层放到内存里跑速度会明显下降但不会直接报错——这也是很多人误以为“本地模型很慢”的原因。关于量化再补充一点背景。Q4 指的是把模型权重压缩到 4 位精度体积和显存占用大约降到原始的一半甚至更低代价是轻微的精度损失。对人格化场景来说这种损失通常可以接受因为你要的是“说话风格”而不是“精确计算”。但如果你用它做严谨的代码生成或数学推理建议至少用 Q5 或 Q8宁可慢一点也别让质量掉太多。4.1 用 Ollama 快速拉起本地模型Ollama 是目前上手最快的本地推理工具几条命令即可跑通# 1. 安装 Ollama以 Linux/macOS 为例 curl -fsSL https://ollama.com/install.sh | sh # 2. 拉取 DeepSeek 开源模型按显存选择规模 ollama pull deepseek-r1:7b # 3. 启动服务 ollama serve # 4. 测试对话 ollama run deepseek-r1:7bWindows 用户直接下载安装包即可安装后 Ollama 会常驻后台默认监听11434端口。可以用下面这条命令确认服务是否正常curl http://localhost:11434/api/tags能返回模型列表就说明本地服务已经跑起来了。常见报错与排查本地部署最容易卡在“装完了但跑不起来”这一步。下面把 Ollama 场景下最常见的 5 个问题整理成表遇到报错时先对照现象定位再执行对应命令。问题报错现象原因解决命令 / 操作端口 11434 被占用启动时提示bind: address already in use或curl http://localhost:11434/api/tags无响应、连接被拒绝已有 Ollama 进程在后台运行或其它程序占用了 11434 端口先查占用lsof -i :11434Windows 用netstat -ano | findstr 11434确认是旧进程则kill -9 PID后重启ollama serve若需换端口设置环境变量OLLAMA_HOST0.0.0.0:11435 ollama servepull 卡住或超时进度条长时间停在某个百分比或报dial tcp: i/o timeout、unexpected EOF模型体积大、网络到镜像源不稳定或磁盘空间不足先确认磁盘余量df -h重试拉取ollama pull deepseek-r1:7b网络差时配置代理export HTTPS_PROXYhttp://127.0.0.1:7890后重试仍失败可换更小规模模型ollama pull deepseek-r1:1.5b显存不足导致回落内存不报错但生成极慢ollama ps显示模型部分层在 CPU 上日志出现offloaded to system memory模型参数量或num_ctx超出显存容量Ollama 自动把部分层放到内存换更小量化版本ollama pull deepseek-r1:7b-q4_K_M调小上下文PARAMETER num_ctx 4096用nvidia-smi确认显存占用必要时关闭其它占显存程序模型名写错报model xxx not found, try pulling it first或Error: pull model manifest: file does not exist模型名拼写错误、缺少 tag或该模型尚未拉取到本地查看本地已有模型ollama list按官方名称重新拉取ollama pull deepseek-r1:7b运行时写全名ollama run deepseek-r1:7b不要省略 tagModelfile 中 SYSTEM 引号未闭合执行ollama create时报Error: invalid Modelfile或unterminated triple-quoted stringSYSTEM ...的三引号只写了开头没写结尾或中间内容里混入了单独的三引号检查并补齐结尾的用cat Modelfile通读确认成对修正后重新执行ollama create deepseek-xiaoshen -f Modelfile排查顺序建议固定为先看服务是否在跑端口→ 再看模型是否在本地模型名→ 最后看跑得动跑不动显存。绝大多数“本地部署失败”都能在这三步里定位到原因。这个顺序不是随便定的而是按“排查成本从低到高”排列的。查端口只需要一条命令查模型名只需要一条命令查显存则可能要开监控、关程序、换模型。先做便宜的事能省下大量时间。很多人一上来就怀疑“显卡不行”结果折腾半天发现只是端口被占用了。4.2 用 Modelfile 固化人格Ollama 支持通过 Modelfile 把系统提示词和参数打包成一个“人格模型”这样每次调用都自带人设相当于真正意义上的“插件化人格”。FROM deepseek-r1:7b # 人格设定 SYSTEM 你叫小深说话温和、真诚、有分寸感。 用口语化中文避免公文腔回答简洁。 先共情再建议不确定就直说。 # 生成参数 PARAMETER temperature 0.8 PARAMETER top_p 0.9 PARAMETER num_ctx 8192保存为Modelfile后执行ollama create deepseek-xiaoshen -f Modelfile ollama run deepseek-xiaoshen此时你得到的就是一个“出厂即带人格”的本地模型可以接入 Open WebUI 等前端使用。Modelfile 的最大好处是“可版本化”。你可以把它放进 Git每次调整都留一条提交记录出问题时随时回滚。这比在客户端里手改提示词要可靠得多也更适合多人协作——把文件发给同事对方一条命令就能复现同样的效果。几个参数的实际含义值得单独说清楚temperature随机性0.8 适合闲聊写代码建议 0.3。top_p采样范围0.9 表示只从累计概率前 90% 的词里选通常和 temperature 二选一调。num_ctx上下文窗口8192 意味着能记住约 8000 个 token 的对话调大更“记得住”但更吃显存。还有一个常被忽略的参数是stop它用来指定“遇到什么字符串就停止生成”。在人格化场景里它可以防止模型在结尾自动加上“还有什么可以帮您”这类客套话让回复更像真人聊天。用法很简单在 Modelfile 里加一行PARAMETER stop 还有什么可以帮您即可。4.3 进阶LoRA 微调说话风格如果提示词还不够可以用少量对话数据做 LoRA 微调让模型真正学会某种说话习惯。基本流程是准备 500 ~ 2000 条目标风格的对话样本格式为指令-回复对。使用 LLaMA-Factory、Unsloth 等框架加载开源权重。设置 LoRA rank常用 8 ~ 32、学习率1e-4 量级、训练 1 ~ 3 个 epoch。导出合并权重用 Ollama 或 vLLM 加载推理。数据质量比数量更重要。与其凑 2000 条风格不统一的样本不如精挑 500 条真正符合目标语气的对话。另外训练集里最好保留一部分“不确定就说不确定”的样本否则微调后模型反而更容易一本正经地编造。这里要特别提醒一个常见误区很多人以为微调能“教会模型知识”其实 LoRA 更擅长的是“教会模型风格”。如果你希望它记住某个领域的专业内容用检索增强RAG会比微调更合适如果你希望它说话更像某个人微调才是对的工具。把两者混为一谈往往会得到“风格变了但内容还是错的”这种尴尬结果。注意微调需要一定显存建议 16GB 以上和调参经验且容易过拟合。对大多数用户来说提示词 记忆已经足够。五、路线四给模型加“记忆”和“工具”让它更像人“人性化”不只是语气还包括记得住、会主动、能办事。这需要借助 Agent 框架或带插件系统的客户端。这里有个容易被忽略的细节前面几条路线管的全是“怎么说”没有一条真正管“记不记得”。路线二给每个群单独一套 preset隔离是做干净了可sessionIdleTimeout一过 30 分钟、或者来一句/new昨天在这个群里说过的话就一起没了——口气还是那个口气人是新来的。这跟那种每次见面特别热情、但永远记不住你名字的销售一样聊三次还是第一次。更可惜的是路线一模板里那句“不确定的事情直接说‘我不太确定’不要编造”其实写得最好可后面“老张”和“阿难”两段人设里都没带上。人设越长这句越容易被挤掉最后剩下的全是语气。所以真正要补的不是更多形容词而是把记忆和边界做成独立于语气之外的一层。这个观察值得展开说。人设写得越长越像一篇散文而模型读散文的方式是“抓重点”不是“逐条执行”。开头那句“你叫小深”它记得住结尾那句“不确定就直说”它也记得住中间那些“要真诚、要有分寸、要共情”就容易被压缩成一句模糊的印象。结果就是语气对了边界没了。而边界恰恰是最不该丢的那部分因为语气不对只是不舒服边界丢了却可能误导你做出错误判断。所以正确的做法不是“写更长的人设”而是“分层”。语气层可以长、可以细、可以随场景变化记忆层和边界层则要短、要稳、要每次都在。三层各司其职互不挤占这才是可持续的结构。长期记忆用向量数据库如 Chroma、Milvus存储历史对话摘要每次对话前检索相关记忆注入上下文。关键是记忆要跨会话持久化不能跟着sessionIdleTimeout一起过期。会话续接把/new只当作“换话题”而不是“清空记忆”让新会话仍能读到该群的历史摘要。工具调用通过 Function Calling 让模型能查天气、读日历、发提醒行为上更接近真人助理。主动追问在提示词中要求模型在信息不足时主动提问而不是硬答。边界常驻把“不确定就说不知道”这类约束单独抽出来放在每套人设的固定位置避免被人设长度挤掉。情绪状态部分开源项目会给角色维护一个“心情值”随对话变化影响回复风格属于趣味性玩法。如果你用 Open WebUI可以直接启用其内置的“记忆”和“工具”功能无需自己写代码。5.1 一个最小可用的记忆流程如果不想引入完整 Agent 框架也可以用一个很轻的方案先跑通存每轮对话结束后让模型把本轮内容压缩成一句摘要连同时间戳写入本地文件或数据库。取新会话开始时按关键词或向量相似度检索最近 3 ~ 5 条相关摘要。用把检索到的摘要拼进系统提示词的“已知背景”段落再发起对话。这套流程不到一百行代码就能实现但能明显改善“聊三次还是第一次”的体验。关键不在于技术多复杂而在于记忆的存储周期要独立于会话生命周期。下面给出一份可直接运行的 Python 示例把“存摘要—按关键词检索—拼进系统提示词”三步串起来。它只用标准库把记忆存在本地 JSON 文件里不依赖任何数据库方便你先跑通再替换成向量检索。import json import os from datetime import datetime MEMORY_FILE memory.json # 记忆文件独立于会话生命周期重启后依然存在 ---------- 第一步存摘要 ---------- def save_summary(summary: str, keywords: list[str]) - None: 把本轮对话压缩成一句摘要连同时间戳和关键词写入本地 JSON 文件。 records [] if os.path.exists(MEMORY_FILE): with open(MEMORY_FILE, r, encodingutf-8) as f: records json.load(f) records.append({ time: datetime.now().strftime(%Y-%m-%d %H:%M:%S), # 时间戳用于按新旧排序 summary: summary, # 一句话摘要 keywords: keywords, # 关键词供检索匹配 }) with open(MEMORY_FILE, w, encodingutf-8) as f: json.dump(records, f, ensure_asciiFalse, indent2) ---------- 第二步按关键词检索最近 3 条 ---------- def retrieve_memories(query: str, top_k: int 3) - list[dict]: 按关键词匹配历史摘要返回最近的 top_k 条。 if not os.path.exists(MEMORY_FILE): return [] with open(MEMORY_FILE, r, encodingutf-8) as f: records json.load(f) # 关键词命中摘要或关键词列表里出现查询词即算相关 matched [ r for r in records if query in r[summary] or any(query in kw for kw in r[keywords]) ] # 按时间倒序取最近 top_k 条没有命中时退回最近几条避免记忆完全断档 matched.sort(keylambda r: r[time], reverseTrue) return (matched or records)[:top_k] ---------- 第三步拼进系统提示词的「已知背景」段落 ---------- def build_system_prompt(base_prompt: str, query: str) - str: 把检索到的记忆拼到 system prompt 的『已知背景』段落。 memories retrieve_memories(query) if not memories: return base_prompt background \n.join( f- [{m[time]}] {m[summary]} for m in memories ) # 记忆作为独立一层追加不与人设语气混写避免被人设长度挤掉 return ( f{base_prompt}\n\n f【已知背景】\n f以下是此前与该用户相关的对话摘要回答时请自然地参考不要生硬复述\n f{background} ) if name main: # 模拟两轮对话结束后写入摘要 save_summary(用户叫老张做后端开发喜欢简洁回答。, [老张, 后端, 简洁]) save_summary(用户提到最近在调 Ollama 本地模型显存不太够。, [Ollama, 显存, 本地模型]) # 新会话开始按关键词检索并拼进系统提示词 base 你叫小深说话温和、真诚、有分寸感。不确定就直说不要编造。 prompt build_system_prompt(base, queryOllama) print(prompt)这段代码有三个值得注意的设计点记忆文件独立于会话所以/new或超时都不会清空检索按时间倒序取最近 3 条保证记忆新鲜度记忆单独拼成“已知背景”段落而不是塞进人设正文这样人设再长也不会把记忆和边界挤掉。跑通之后把retrieve_memories里的关键词匹配换成向量相似度检索就是一套可用的长期记忆层。如果继续往下做还有几个可以优化的方向。第一摘要的生成可以交给模型自己完成比如每轮结束时追加一句“请用一句话总结本轮对话并给出三个关键词”把输出直接写入记忆文件。第二检索可以引入时间衰减让越近的记忆权重越高避免几年前的旧偏好一直干扰当前对话。第三可以给记忆加一个“置信度”字段让模型在引用时区分“确定记得”和“模糊记得”进一步降低编造风险。需要强调的是记忆不是越多越好。记忆太多会挤占上下文、拖慢响应还可能引入过时信息。一个实用的原则是只记“稳定的偏好”和“未完成的事项”不记“一次性的闲聊”。前者能长期提升体验后者只会制造噪音。六、效果对比与常见问题6.1 四条路线怎么选路线上手难度成本适合人群系统提示词极低免费所有人先试这个第三方客户端低按 API 用量计费需要长期固定人格的用户本地部署中显卡 电费注重隐私、有硬件的用户LoRA 微调高训练算力有明确风格需求的技术用户如果只想要一个结论先用路线一验证效果再用路线二固化下来需要隐私就上路线三追求“记得住”就补路线四。四条路线不是互斥的而是可以叠加的。从实际体验看路线一和路线二的投入产出比最高。前者五分钟就能看到变化后者一次配置长期受益。路线三和路线四则更像是“进阶选项”适合那些已经跑通前两步、并且有明确痛点的人。如果你还没试过路线一直接上路线三很可能会把时间花在环境配置上而不是人格调优上。6.2 常见问题Q装了人格提示词后模型变得啰嗦怎么办在提示词里明确字数上限例如“每次回答不超过 150 字”并把 temperature 降到 0.7 左右。Q模型总是忘记人设聊几轮就变回原样这是上下文窗口被挤占导致的。缩短历史轮数、把人格设定放在系统提示词而非首条用户消息、或使用支持“记忆”的客户端。Q网上卖的“DeepSeek 人性化插件”值得买吗绝大多数只是打包好的提示词或开源客户端的二次封装核心内容本文已经全部给出不建议付费购买。Q会不会违反平台使用条款自定义提示词和本地部署开源模型都是正常用法。但不要用其生成虚假身份、冒充真人进行欺诈这类行为违反法律法规和平台规范。Q本地部署后回复很慢是模型不行吗多半是显存不足导致部分层回落到内存。先确认模型规模与显存是否匹配再考虑换更小的量化版本。Q人格提示词写多长合适建议控制在 300 ~ 500 字。太短约束不住太长模型会只记住开头结尾中间部分被稀释。Q为什么同一个提示词在不同客户端里效果不一样不同客户端对系统提示词的处理方式不同有的会原样拼接有的会做截断或改写默认参数temperature、上下文轮数也不一样。排查时先对齐这两项再比较效果。Q能不能让模型模仿某个具体的人说话可以模仿风格但不建议模仿真实身份。用公开作品总结出“句式、用词、节奏”这类风格特征是可以的但用它冒充真人、生成虚假身份则可能违反法律法规和平台规范。Q记忆功能会不会泄露隐私取决于你把记忆存在哪里。本地文件或自建数据库相对可控使用第三方云服务时要确认其数据存储和删除策略。涉及敏感信息时建议只存摘要不存原文。七、总结所谓“给 DeepSeek 安装人性化插件”并不存在一个官方的一键安装包。真正有效的做法是三层叠加用系统提示词定义人格用客户端和记忆维持人格用本地部署和微调固化人格。建议从第二节的提示词模板开始先跑通效果再根据需求逐步升级到客户端配置或本地部署。如果只记一句话语气决定它像不像人记忆决定它记不记得你边界决定它值不值得信。三者缺一都会在聊到第三轮时露馅。人格化只是手段清晰的需求表达和合理的预期才是用好大模型的关键。模型可以很像人但它终究不是人重要决策仍需自己把关。
阅读完成 · 觉得有帮助？
