用Python实现带好感度系统的拟人化聊天机器人

聊天机器人入门其实不难，网上随便一搜就是一大把“用 Python 写一个自动回复”的教程。但多数人写完之后会陷入一个很尴尬的处境：机器人确实是能回复了，但它不像“人”，更像一个复读机。你问一句它答一句，离开关键词就露馅，聊两句就索然无味。这个问题的根源不在模型，也不在 NLP 算法，而在产品设计层面——机器人没有“人设”、没有“记忆”、也没有“情绪反馈”。本文要做一个带“好感度系统”的拟人化赛博聊天机器人，核心思路是：不依赖任何重型框架，用规则引擎加状态机，在五分钟内让机器人拥有稳定的性格、可增长的好感度和持续可扩展的对话体验。读完你可以立刻跑通一个可交互的 CLI 聊天机器人，并理解如何把它扩展到 QQ 等官方机器人平台。

我先把判断放在前面：想让聊天机器人“拟人”，关键不是让它更聪明，而是让它“更稳定地像一个人”。聪明可以靠模型，但人设的稳定感必须靠工程手段。好感度系统就是这个工程手段里最直观、最容易落地的一种设计。它把“聊天体验”从纯文本匹配升级成了“关系模拟”：同样一句话，在好感度 0 和好感度 80 的时候，机器人的回应语气应该完全不同。这个变化会让用户产生持续聊下去的欲望。下面这篇教程会从概念拆解开始，再给一套完整可运行的 Python 实现，最后聊一聊如何接到 QQ 官方机器人，以及生产环境里最容易踩的坑。

1. 这篇文章真正要解决的问题

很多开发者对“聊天机器人”存在一个典型误解：以为聊天机器人的好坏取决于模型能力。于是新手的第一版机器人往往是一个if "你好" in msg: return "你好"的应答机，或者直接调用一个超大模型 API。前者的体验极其生硬，后者虽然语言流畅，但用户会发现它今天叫 A，明天叫 B，没有固定的性格，也没有任何关系成长感。

拟人化赛博聊天机器人要解决的，是三个具体问题。第一是“人设稳定”，机器人必须有固定的名字、背景、语气和记忆，而不是每次对话都从零开始。第二是“情绪反馈”，机器人要根据用户的语言内容，产生可量化的关系变化，让用户感受到“它对我的态度不一样了”。第三是“可扩展”，你不能永远靠 if-else 堆关键词，需要让对话引擎可以被新场景不断扩展，而不是改一处崩三处。

这篇文章适合以下几类读者：第一次做聊天机器人、想体验完整实现流程的 Python 初学者；想在产品原型中加入“好感度”“亲密度”等游戏化机制的产品经理或独立开发者；以及已经在做 QQ 聊天机器人、想给自己的机器人增加人设深度的开发者。读完你会得到一套完全可运行的代码，而不是停留在“思路挺好”的层面。

2. 拟人化聊天机器人的核心概念：人设、记忆与好感度状态机

在动手写代码之前，先统一几个概念。很多人把“拟人化”简单理解为“说话像人”，这是不完整的。拟人化至少包含三层：外观层、语言层和关系层。本文不涉及外观，重点做语言层和关系层。语言层靠人设模板和句式控制，关系层靠好感度状态机。

人设（Persona）就是机器人的身份档案，包括名字、昵称、背景角色、开场白、常用语气。它决定了机器人“我是谁”。没有固定人设的机器人，就像没有剧本的演员，每一轮对话都在重新扮演另一个人。需要注意，人设不是一段静态文案，它要参与生成逻辑：开场白要读人设，自我介绍要读人设，情绪词的选择也要参考人设。

记忆（Memory）是拟人感的另一个来源。最简单的记忆是“记住用户刚才说了什么”，进阶一点是“记住用户叫什么”“记住上次聊到哪个话题”。本文先实现会话内记忆，再提供一个 JSON 持久化方案。真正做产品时，记忆应当有容量上限、敏感信息过滤和过期策略，否则就是给自己埋坑。

好感度状态机（Affinity State Machine）是本文最核心的设计。它是一个取值范围通常在 -100 到 100 之间的数值，通过正向词、负向词或者具体话题触发增减，再把这个数值映射到不同的关系等级。不同等级会改变机器人的回应语气，从而让用户明显感觉到“关系在变化”。用状态机而不是简单数值的原因在于：数值本身无法直接驱动文案，必须经过“等级映射”才有表现力。

这里给出一个常见的关系等级表，方便你理解状态机的作用：

从这个表可以看出，同样的“你好”，在不同好感度等级下，体验是完全不同的。这就是拟人化聊天机器人和普通问答机器人的核心差异：普通机器人关注“我说得对不对”，拟人机器人关注“我说得合不合当前关系”。前者是信息层，后者是关系层。

3. 环境准备与最小项目结构

这个项目不依赖第三方库，使用 Python 标准库即可完成，因此环境准备非常简单。你需要一个 Python 3.9 及以上版本的解释器。之所以不用第三方依赖，是为了让你在最少的环境准备下先跑通整个交互流程；后续如果要接 QQ 机器人，再按平台要求补充依赖。

为了便于开发，建议使用虚拟环境隔离项目依赖。不过本项目的核心代码没有依赖，虚拟环境并非必须。如果你本机同时存在多个 Python 版本，建议在项目目录下执行以下命令创建虚拟环境：

python -m venv .venv

在 Linux 或 macOS 上激活虚拟环境：

source .venv/bin/activate

在 Windows 上激活虚拟环境：

.venv\Scripts\activate

接下来建立如下最小目录结构：

cyber-chatbot/ ├── persona.py # 人设配置 ├── affinity.py # 好感度状态机 ├── reply_engine.py # 对话引擎 ├── memory_store.py # 记忆持久化（可选） └── chat.py # CLI 主程序

这样的拆分很容易理解：人设配置和逻辑分离，状态机独立成一个模块，对话引擎负责把输入变成输出，主程序只负责交互循环。新手最容易犯的错误是把所有代码写在一个文件里，前 200 行还能看，到后面连自己都分不清某段逻辑是干嘛的。从一个小项目开始保持模块化，成本很低，收益却很高。

4. 核心代码实现与拆解

下面开始写核心代码。我会按模块逐一实现，并解释每个模块承担的责任。这份代码不是玩具，它已经具备扩展成真实产品的骨架。

4.1 人设配置模块

人设是整个拟人化体验的“根”。没有稳定人设，后面一切功能都是空中楼阁。先在persona.py里定义机器人的身份信息。

# 文件路径：persona.py PERSONA = { "name": "小赛", "nickname": "赛博", "role": "来自近未来都市的 AI 助理", "greeting": "系统启动成功。我是小赛，今天想聊点什么？", "style": "赛博", } def get_persona_info(): """返回人设信息的只读副本，避免业务代码直接修改全局配置。""" return dict(PERSONA)

这里有个容易被忽略的细节：为什么需要get_persona_info()而不是直接让其他模块导入PERSONA字典使用？因为配置应该是只读的。如果对话引擎或情感计算逻辑直接修改了全局人设，后续排查问题时很难定位是谁改的。提供一个返回副本的方法，等于给配置层加了一道保护。

4.2 好感度状态机

好感度状态机是本文的重点。它负责两件事：维护好感度数值，以及把数值映射成关系等级。先定义等级区间，再实现AffinitySystem。

# 文件路径：affinity.py AFFINITY_LEVELS = [ (-100, -50, "防备"), (-50, 0, "疏远"), (0, 30, "普通"), (30, 60, "友好"), (60, 80, "亲密"), (80, 100, "心动"), ] class AffinitySystem: def __init__(self, initial_value=0): self.value = max(-100, min(100, initial_value)) def add(self, delta): """好感度增量更新，并限制在 [-100, 100] 区间内。""" self.value = max(-100, min(100, self.value + delta)) return self.value def level(self): """根据当前好感度数值返回关系等级。""" for low, high, name in AFFINITY_LEVELS: if low <= self.value < high: return name return "心动"

这段代码的关键逻辑在add方法：使用max和min做边界钳制，保证好感度永远不会越界。level方法按区间顺序匹配等级，注意区间设计要覆盖 -100 到 100 的全部范围，且边界取值要统一用左闭右开，避免出现某个数值匹配不到等级的情况。

有人可能会问：直接拿数值当“友好度”展示不好吗，为什么非要转成等级？因为用户感知的是“关系”，不是一个抽象数字。关系是有名字的，比如“防备”“亲密”“心动”，这些名字直接影响机器人的说话方式。数字适合做底层计算，等级适合做上层表现，两者结合才是一个完整的状态机。

4.3 对话引擎

对话引擎是连接人设、好感度和用户输入的桥梁。它要做三件事：识别输入中的情感倾向和话题、更新好感度、根据当前关系等级生成不同语气的回复。

# 文件路径：reply_engine.py from persona import get_persona_info from affinity import AffinitySystem POSITIVE_KEYWORDS = ["你好", "喜欢", "厉害", "哈哈", "谢谢", "棒"] NEGATIVE_KEYWORDS = ["讨厌", "无聊", "滚", "笨蛋", "糟糕"] TOPIC_KEYWORDS = ["天气", "工作", "游戏", "代码", "电影", "赛博"] class ReplyEngine: def __init__(self): self.persona = get_persona_info() self.affinity = AffinitySystem() self.history = [] def receive(self, text): self.history.append(text) delta = 0 if any(k in text for k in POSITIVE_KEYWORDS): delta += 5 if any(k in text for k in NEGATIVE_KEYWORDS): delta -= 8 if delta != 0: self.affinity.add(delta) return self._build_reply(text) def _build_reply(self, text): level = self.affinity.level() if any(k in text for k in NEGATIVE_KEYWORDS): return self._with_tone("……收到。我会记住这句话。", level) if "名字" in text or "你是谁" in text: return self._with_tone( f"我叫{self.persona['name']}，{self.persona['role']}。", level ) if any(k in text for k in TOPIC_KEYWORDS): return self._with_tone("这个话题我可以陪你聊很久。", level) return self._with_tone("继续，我在听。", level) def _with_tone(self, base, level): tone_map = { "防备": "（语气疏离）", "疏远": "（语气平静）", "普通": "", "友好": "（语气轻快）", "亲密": "（语气温柔）", "心动": "（语气柔和）", } prefix = tone_map.get(level, "") return f"{prefix}{base} 当前好感度：{self.affinity.value}"

这个引擎的设计有个值得学习的地方：情感倾向识别只负责“加减好感度”，而回复生成只负责“根据等级换语气”。两个逻辑解耦之后，后续修改情感词表不影响回复模板，修改回复模板也不影响好感度计算。如果以后要接一个大模型 API，你可以保留好感度系统，把_build_reply换成调用模型生成句子，改动成本非常小。

当然，这里的关键词匹配非常粗糙，它只是用来演示机制。真实项目中，你可以用意图识别模型、情感分析模型或者更精细的规则引擎来替换这个部分，但状态机的骨架可以原样保留。这也再次说明：拟人化体验的设计重点，不在某一个回复有多聪明，而在于整个交互状态是连贯的。

4.4 CLI 主程序

核心模块写完，现在用主程序把它们串起来。chat.py负责启动对话循环，读取用户输入，调用对话引擎，并输出回复。

# 文件路径：chat.py from reply_engine import ReplyEngine from persona import get_persona_info def main(): persona = get_persona_info() bot = ReplyEngine() print(f"[{persona['name']}]: {persona['greeting']}") print("输入 exit / quit / 再见 退出对话") while True: try: user_input = input("你：") except (KeyboardInterrupt, EOFError): print() print(f"[{persona['name']}]: 下次见。") break text = user_input.strip() if text in ("exit", "quit", "再见"): print(f"[{persona['name']}]: 下次见。") break if not text: continue reply = bot.receive(text) print(f"[{persona['name']}]: {reply}") if __name__ == "__main__": main()

主程序里有两个容易忽略的细节。第一是KeyboardInterrupt和EOFError的处理，用户随时可能按 Ctrl+C 结束对话，不做处理会直接抛异常退出，体验很差。第二是空输入过滤：用户可能不小心直接按回车，不能让空字符串进入对话引擎。

4.5 可选：JSON 记忆持久化

完成上面的代码，已经能得到一个完整的 CLI 聊天机器人。但如果想更进一步，让机器人跨会话记住用户信息，就需要引入持久化。这里提供一个基于 JSON 文件的最小实现，足够让你理解“记忆”模块的工作方式，又不引入数据库复杂度。

# 文件路径：memory_store.py import json import os MEMORY_FILE = "memory.json" def load_memory(): if os.path.exists(MEMORY_FILE): with open(MEMORY_FILE, "r", encoding="utf-8") as f: return json.load(f) return {"user_name": None, "last_topic": None, "interactions": 0} def save_memory(memory): with open(MEMORY_FILE, "w", encoding="utf-8") as f: json.dump(memory, f, ensure_ascii=False, indent=2)

在ReplyEngine.receive里可以增加一行self.memory["interactions"] += 1，并在对话结束时调用save_memory(self.memory)。这样机器人在下一次启动时就能读取历史交互次数，甚至可以在开场白里说“这是我们第 N 次聊天”。这种细节就是拟人感的来源。

5. 运行结果与效果验证

代码写完之后，在项目根目录执行：

python chat.py

预期输出如下：

[小赛]: 系统启动成功。我是小赛，今天想聊点什么？ 输入 exit / quit / 再见 退出对话 你：你好 [小赛]: （语气轻快）继续，我在听。 当前好感度：5 你：我喜欢赛博话题 [小赛]: （语气轻快）这个话题我可以陪你聊很久。 当前好感度：10 你：讨厌 [小赛]: （语气疏离）……收到。我会记住这句话。 当前好感度：2 你：再见 [小赛]: 下次见。

注意输出中的好感度数值和语气前缀会随着输入类型变化。这就说明对话引擎和好感度状态机已经正常工作了。判断成功有三个标准：第一，启动时能看到小赛的开场白；第二，输入正向词后好感度上升，输入负向词后好感度下降；第三，当好感度跨越等级阈值时，语气前缀发生变化，比如从“语气轻快”变成“语气温柔”。

如果运行失败，第一步不要急着改代码，先看终端里是否出现ModuleNotFoundError。这个错误多半是文件路径不对，或者模块名拼写错误。确认chat.py、reply_engine.py、affinity.py、persona.py在同一个目录下，并且在项目根目录执行启动命令，问题通常就解决了。

6. 把机器人接到 QQ：官方机器人接入思路与合规边界

CLI 版本已经证明了核心机制可行，但很多读者想把它做成一个“活”的 QQ 聊天机器人。这里需要说明：QQ 提供了官方的机器人开放平台，使用官方接口是最稳妥、最合规的做法。接入前必须完成开发者认证，并严格阅读平台的运营规则，不能将机器人用于骚扰、诈骗或发送违法信息等场景。

从技术链路看，接入 QQ 官方机器人大致分为几步：先在开放平台创建应用并获取凭证，然后配置事件订阅地址，机器人收到消息事件后，由你的服务端调用对话引擎生成回复，再通过 API 发回对应会话。整体可以理解为一个消息中转：QQ 平台把用户消息投递到你的服务，你的服务把机器人回复传回去。

这里提供一个伪代码示例，帮助你理解事件处理入口长什么样。不同平台的字段名称和调用方式可能不同，请以官方文档为准：

# 伪代码：QQ 官方机器人事件处理入口，字段名仅作示意 def handle_message_event(event): text = event.get("content", "") chat_id = event.get("chat_id", "") user_id = event.get("user_id", "") reply = bot.receive(text) send_message(chat_id, reply)

这段伪代码的关键点是：你的引擎只需要暴露一个“接收文本返回文本”的接口，就能嵌入任何 IM 平台。这就是前面模块化设计的好处。真正去接 QQ 官方机器人时，还需要处理签名校验、消息去重、重试机制、频率限制等工程问题。先从官方文档和官方 SDK 开始是最稳的。

需要强调的是，QQ 机器人接入有明确的合规边界。不要让机器人自动同意所有好友请求，不要收集和保存用户的敏感个人信息，不要做任何诱导分享、诱导关注的行为。如果你的机器人承担客服或社区运营职责，建议在回复中明确标注“我是机器人”。拟人化体验再好，也要建立在用户知情和平台规则允许的基础上。

7. 常见问题与排查思路

从实际开发经验来看，这个项目在你本地跑通很容易，但如果要做成产品，问题会出现在工程细节上。下面整理了几个高频问题，你可以对照排查。

这里我想单独强调一下关键词匹配的坑。如果你把POSITIVE_KEYWORDS定义成只包含“你好”，用户说“你好啊”也能命中，但用户说“早上好”就完全无法触发。这在简单演示中无所谓，但一旦部署到生产环境，用户会觉得机器人“听不懂人话”。更稳妥的做法是在关键词匹配时，把用户输入做分词后再匹配，或者直接调用情感分析 API。不要让关键词表无限膨胀，那是工程上的死路。

8. 最佳实践与工程建议

如果你准备把这个原型发展为正式项目，以下几点建议值得提前思考。

第一，记忆模块必须要做边界控制。JSON 文件持久化只适合单机、低并发、个人项目。上线后如果用户量大，建议换成 SQLite 或 Redis，并设置记忆条目过期时间。用户隐私信息要加密存储，且遵循最小化原则：只存对话必需的字段，不存身份证号、住址等敏感数据。记忆本身就是风险，保存得越少越安全。

第二，好感度系统要设计“衰减”机制。现实中的关系不是只增不减，如果机器人的好感度只能涨不能降，几天后所有用户都会进入“心动”等级，等级就失去了区分度。可以在每天首次对话时让好感度缓慢回归，或者在长期不互动后降低好感度。衰减的幅度要小，避免用户觉得“昨天还聊得好好的，今天突然冷漠”。

第三，代码结构要保持“引擎与平台分离”。现在回复引擎是独立模块，这非常好。以后接 QQ、飞书、钉钉或自建 Web 页面时，只需要写不同的接入层，不需要重写对话引擎。很多成熟的开源聊天机器人项目，都会把adapter、engine、memory分成三层，你现在的项目已经具备这个雏形。

第四，日志和可观测性必须从一开始就加上。不要只在出错时print一下。至少把用户输入、机器人回复、好感度变化、耗时这四项记录到结构化日志中。后续你分析“为什么用户聊了几句就流失”，靠的不是记忆，而是日志。最低成本的做法是先输出到 JSON 文件，之后再接入日志平台。

第五，内容安全过滤不能省。即便你认为自己做了拟人化设计，机器人仍然可能被人恶意诱导输出有害内容。建议在对话引擎之前加一层内容安全检测，包括敏感词过滤、垃圾内容识别、频率限制等。QQ 等开放平台对机器人的内容安全要求非常严格，上线前一定要仔细阅读平台的处罚规则。

9. 总结与后续学习方向

这篇文章的核心不是那几段关键词匹配代码，而是三个设计思想：第一，拟人化聊天机器人的核心是人设、记忆和情绪状态的组合，不是单一回复逻辑；第二，好感度状态机是游戏化互动机制，设计和代码实现都很轻量，但体验提升非常明显；第三，模块化拆分能让这个原型快速迁移到 QQ 等真实平台。

建议你动手做三个练习：把好感度等级扩展到更多层，比如“傲娇”“依赖”“紧张”等更细腻的关系状态；给机器人增加长期记忆，让它在第二次启动时记住你的名字；扩展话题库，让机器人能围绕“赛博”“AI”“游戏”等主题展开多轮追问。完成这三个练习后，你对聊天机器人工程化的理解会比看十篇文章都更扎实。

做这个项目，最忌讳的是只复制代码然后“跑通即结束”。跑通只是起点，值得深入的是你对交互状态的理解：为什么同一个回复，在不同关系等级下给人的感受完全不同；为什么用户会因为一句“我会记住这句话”而愿意继续聊下去。这些体验设计能力，比单纯调 API 更有长期价值。建议收藏本文并动手实践，遇到问题可以回到第七节的排查表对照处理。