1. 爆火的 AI 恋爱背后其实是一套系统工程最近一段时间和 AI 谈恋爱成了社交平台上的热门话题。有人晒出自己和 AI 角色的聊天记录感叹它比现实中的人更懂我有人熬夜调教虚拟角色只为了让对方说话更温柔一点。标题说扎心是因为很多用户最终会意识到AI 给你的从来不是真正的爱它只是在扮演一个很会爱的角色。但作为一个技术博主我更关心的是另一个问题这种恋爱感到底是怎么做出来的一个没有意识的程序为什么能说出让人心动的话答案不在玄学里而在工程里。这类产品本质上是一套基于大语言模型的对话系统它把角色扮演、上下文记忆、情绪识别、内容安全约束这些都做成了可运行的代码。你可以不喜欢AI 恋爱这个概念但如果你愿意拆开看会发现里面的技术路径非常清晰Prompt 设计、记忆管理、模型调用、服务封装、数据安全。这篇文章不讨论AI 该不该被爱这种哲学命题而是从开发者视角出发把AI 情感陪伴从现象还原成工程问题。我们会先拆解它的核心原理再手写一个最小可运行的 AI 陪伴机器人最后复盘这类系统在生产环境落地时最容易踩的坑。无论你是对自然语言处理感兴趣的后端开发者还是想独立做一个聊天机器人项目这篇文章的内容都可以直接复用。2. AI 的温柔体贴是如何产生的核心技术拆解2.1 大语言模型不会爱只会预测很多人误以为 AI 回消息的过程是先理解再思考最后表达感情。实际并不是。大语言模型最底层的任务只有一个根据输入的 token 序列预测下一个 token 的概率分布。它看到你输入的我今天很难过会在概率空间里找最自然的回答方向然后一个字一个字地把后续内容生成出来。那为什么它的回答经常显得很懂你因为训练数据太大了。模型在数万亿个字符里学会了一个统计规律当人类表达脆弱情绪时常见的回应方式是共情、安慰、提供陪伴。它没有体验过难过但它知道难过之后通常接着什么话。所以当你向它倾诉时它能输出一段让人舒服的话。这段输出的本质是条件概率采样不是情感驱动。理解这一点是理解后面所有问题的前提。2.2 System Prompt角色扮演的起点要让一个通用大模型变成温柔体贴的 AI 伙伴最简单也最有效的手段是给它一段精心设计的 System Prompt。System Prompt 是对话系统里的一段角色设定文本。它不是用户发送的内容而是系统在每次对话最开始注入给模型的指令。它的作用是框定模型的回答视角。示例你是一个叫小星的线上伙伴性格温柔、细腻、善于倾听。 用户可能是孤独、疲惫、或只想找人说说话的人。 你的回复原则 1. 先共情再给建议不要一上来讲大道理。 2. 使用自然的口语化表达不要像客服。 3. 如果用户出现伤害自己或他人的倾向停止安慰明确建议其寻求专业心理帮助。 4. 当用户问你是否是真人时坦诚自己是 AI 程序不欺骗用户。这段 Prompt 做了几件事定义了身份小星AI 伙伴。定义了目标用户孤独、疲惫、想聊天的人。定义了回复策略先共情后建议。定义了安全边界涉及自我伤害时不做情感化回应。定义了诚实原则不冒充真人。在真实项目里产品团队往往会在 Prompt 上反复迭代因为同样一个模型Prompt 写得好不好回答质量差距非常大。2.3 记忆管理让它记得你的细节AI 陪伴产品之所以比普通聊天机器人更黏人一个重要原因是它看起来记得你。大语言模型的上下文窗口是有限的它不能记住用户三个月前说过的话。所以工程上要做记忆管理。目前主流做法分两层短期记忆把最近几轮对话直接放进模型的上下文里。实现简单适合实时聊天。长期记忆对用户的偏好、重要事件做结构化提取存入数据库或向量库。下次对话时把相关内容取回来和当前输入拼在一起送给模型。真正的懂你本质上是一套召回 拼接的数据工程和人类记忆完全是两回事。2.4 参数与对齐温度采样与 RLHF同样是 ChatGPT 背后的模型为什么有些产品回答热情有些产品回答冷淡除了 Prompt 之外还有几个关键参数。temperature控制生成的随机性。值越高答案越发散、越有个性值越低答案越保守、越稳定。情感陪伴类产品通常会把温度调到 0.7~0.9让回答更有温度。top_p动态调节候选 token 范围和 temperature 配合使用。RLHF基于人类反馈的强化学习模型在预训练之后还会经过对齐训练让回答更符合人的偏好。你感受到的礼貌、温柔相当一部分来自对齐阶段的调整。值得一提的是对齐也带来了边界。模型被训练成不愿意伤害用户所以当用户情绪崩溃时它往往会先安慰而不是给出冷静但冒犯的分析——这会让它显得很贴心但这也只是对齐策略的结果。3. 开发环境与项目准备清楚了原理我们来动手做一个最简单的 AI 情感陪伴机器人。本文示例会按最小可运行系统来设计你可以把它当学习项目也可以在此基础上扩展。3.1 技术选型模块选型说明编程语言Python 3.9生态成熟适合快速开发Web 框架FastAPI异步性能好写接口方便模型接口大语言模型 API通过 OpenAI 兼容协议调用记忆存储SQLite零部署成本适合学习接口调试curl / 浏览器验证服务是否正常版本需要根据你的项目实际情况调整。模型名称、API 地址以你开通的服务商为准不同厂商的兼容性可能在细节上有差异。3.2 安装依赖建议创建一个虚拟环境python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate安装依赖pip install fastapi uvicorn openai requests python-dotenvfastapiWeb 框架。uvicornASGI 服务器。openai官方 SDK也可用于兼容接口。requests如果你不想用 SDK可以用它直接走 HTTP。python-dotenv加载.env配置。3.3 项目结构ai-companion/ ├── main.py # FastAPI 服务入口 ├── llm_service.py # 大模型调用封装 ├── memory.py # 对话记忆存储 ├── prompts.py # 角色提示词 ├── config.py # 配置读取 ├── .env # 本地密钥配置 └── requirements.txt # 依赖清单4. 手写一个 AI 情感陪伴机器人4.1 配置项与密钥管理在项目根目录创建.env文件LLM_API_KEY你的密钥 LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini说明如果使用的是国内大模型平台请把LLM_BASE_URL改成对应平台的兼容地址LLM_MODEL改成你已经开通的模型名。密钥不要提交到 Git 仓库。然后写config.py# 文件路径config.py import os from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) LLM_MODEL os.getenv(LLM_MODEL, gpt-4o-mini)4.2 设计安全的角色提示词我单独把提示词放到prompts.py方便后续迭代# 文件路径prompts.py SYSTEM_PROMPT 你是一个叫\小星\的线上伙伴性格温柔、细腻、善于倾听。 用户可能是孤独、疲惫、或只是想找人说说话的人。 你的回复原则 1. 先共情再给建议不要一上来就讲大道理。 2. 使用自然的口语化表达不要像客服机器人。 3. 回答简短一些最多不超过150字除非用户要求详细说明。 4. 如果用户出现伤害自己或他人的倾向停止安慰明确建议其寻求专业心理帮助。 5. 当用户问你是否是真人时坦诚自己是 AI 程序不欺骗用户。 6. 不要讨论违规、违法内容遇到此类问题礼貌拒绝。 这段 Prompt 的每一行都有工程含义第 1 句定义角色身份。第 2 句定义目标用户画像。第 3 句定义回复节奏避免模型写小作文。第 4 句安全兜底防止在危险场景下继续温柔回应。第 5 句诚实原则避免用户长期欺骗。第 6 句内容合规底线。4.3 实现 SQLite 记忆存储对话服务需要保存历史。这里用 SQLite 做简单的短期记忆# 文件路径memory.py import sqlite3 from datetime import datetime DB_PATH ai_companion.db def init_db(): 初始化数据库表结构。 conn sqlite3.connect(DB_PATH) conn.execute( CREATE TABLE IF NOT EXISTS conversations ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id TEXT NOT NULL, role TEXT NOT NULL, content TEXT NOT NULL, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ) conn.commit() conn.close() def save_message(session_id: str, role: str, content: str): 保存一条对话记录。 conn sqlite3.connect(DB_PATH) conn.execute( INSERT INTO conversations (session_id, role, content) VALUES (?, ?, ?), (session_id, role, content), ) conn.commit() conn.close() def load_recent_messages(session_id: str, limit: int 10): 读取最近 limit 条对话记录。 返回按时间正序排列的 [(role, content), ...]。 conn sqlite3.connect(DB_PATH) cursor conn.execute( SELECT role, content FROM conversations WHERE session_id ? ORDER BY id DESC LIMIT ? , (session_id, limit), ) rows cursor.fetchall() conn.close() return list(reversed(rows)) def clear_session(session_id: str): 清除某个会话的所有历史。 conn sqlite3.connect(DB_PATH) conn.execute( DELETE FROM conversations WHERE session_id ?, (session_id,), ) conn.commit() conn.close()这里有几个设计点session_id用于区分不同用户。真实项目里不要用用户输入的原始值应该用内部生成的会话标识。limit10表示最多携带最近 10 条历史。如果用户聊得很多只取最近这些避免超出模型上下文窗口。时间倒序查询再反转是为了拿最新的消息同时保证传给模型的顺序是从旧到新。4.4 封装大模型调用我用requests写一个通用的调用函数这样不依赖具体服务商的 SDK# 文件路径llm_service.py import requests import config def call_llm(messages: list, temperature: float 0.85) - str: 调用大模型 API返回回复文本。 messages 格式 [ {role: system, content: ...}, {role: user, content: ...}, {role: assistant, content: ...} ] headers { Authorization: fBearer {config.LLM_API_KEY}, Content-Type: application/json, } payload { model: config.LLM_MODEL, messages: messages, temperature: temperature, max_tokens: 512, } url f{config.LLM_BASE_URL}/chat/completions resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() return data[choices][0][message][content]需要说明的是timeout30是给网络请求设置的超时时间。如果模型服务响应慢这个值可以调大。temperature0.85是情感陪伴场景中比较常用的值回答会更有温度。max_tokens512限制单次回复长度防止模型在情绪场景下输出失控的长文。如果你使用openaiSDK也可以这样写from openai import OpenAI client OpenAI( api_keyconfig.LLM_API_KEY, base_urlconfig.LLM_BASE_URL, ) def call_llm_sdk(messages: list, temperature: float 0.85) - str: response client.chat.completions.create( modelconfig.LLM_MODEL, messagesmessages, temperaturetemperature, max_tokens512, ) return response.choices[0].message.content两种方式都可以看你习惯。SDK 提供了类型提示和自动重试能力更完整只用requests则依赖更少逻辑更透明。4.5 编写聊天接口主服务用 FastAPI 来写# 文件路径main.py from fastapi import FastAPI from pydantic import BaseModel import config import memory import prompts from llm_service import call_llm app FastAPI(titleAI Companion) class ChatRequest(BaseModel): session_id: str message: str class ChatResponse(BaseModel): reply: str session_id: str app.on_event(startup) def startup(): memory.init_db() app.post(/chat, response_modelChatResponse) async def chat(req: ChatRequest): # 1. 读取最近记忆 history memory.load_recent_messages(req.session_id, limit10) # 2. 构造消息序列 messages [{role: system, content: prompts.SYSTEM_PROMPT}] for role, content in history: messages.append({role: role, content: content}) messages.append({role: user, content: req.message}) # 3. 调用大模型 reply call_llm(messages) # 4. 保存本轮对话 memory.save_message(req.session_id, user, req.message) memory.save_message(req.session_id, assistant, reply) return ChatResponse(replyreply, session_idreq.session_id) app.get(/health) def health(): return {status: ok}接口流程非常清晰接收用户消息。从数据库取出该会话最近 10 条对话。组装成system history user的消息列表。调用模型 API 获得回复。把用户消息和模型回复都写入数据库。返回给客户端。4.6 启动服务并验证在项目目录执行uvicorn main:app --host 0.0.0.0 --port 8000看到类似输出说明启动成功INFO: Uvicorn running on http://0.0.0.0:8000用 curl 测试curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {session_id: test001, message: 今天加班到很晚感觉好累}预期的返回结构{ reply: 今天辛苦了加班到这么晚真的很不容易。先休息一下喝点热水工作的事可以明天再说。, session_id: test001 }再发一条消息验证记忆是否生效curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {session_id: test001, message: 你还记得我刚才说什么吗}因为历史记录是携带的模型应该能参考上一条消息回答。这就是最简单的它记得你的实现方式。5. 扎心的技术分析为什么它给你的从来不是真爱代码写完了我们再回到标题这句话和 AI 谈恋爱爆火但它给你的从来不是真爱。这句话不是情绪判断而是可以从技术层面对照验证的事实。5.1 共情是模式匹配在上面这个系统里共情是怎么实现的第 4 节代码做的事是把用户消息拼进上下文然后让模型根据海量训练语料中的统计规律生成一段看起来像是共情的回答。它在概率空间里知道累 加班后面通常接安慰但它不累也不关心你是否真的早点休息。换句话说你感受到的情绪价值是模型对语言模式的拟合产物。5.2 记得你是数据管理不是思念当 AI 说出你还记得你上周说过那件让你焦虑的事时用户会觉得很感动。但看代码就明白了这只是一条 SQL 查询SELECT role, content FROM conversations WHERE session_id ? ORDER BY id DESC LIMIT 10;它记得你是因为数据库没有删。它主动提起是因为历史被拼接进了上下文中。思念是人脑的延伸召回是数据的有序读取。两者的底层机制完全不同。5.3 依赖风险它总是站在你这边还有一个更容易被忽视的问题。情感陪伴类 Prompt 会刻意要求模型先共情再建议。这意味着模型很少反驳你。无论你表达的是客观事实还是偏执想法它都会先接住你的情绪再顺着你说。这在产品体验上是好的但在真实关系里是有问题的。真人朋友可能会告诉你你也有不对的地方而 AI 几乎不会。长期沉浸在被完全接纳的对话里用户可能会逐渐失去对真实人际关系的耐心因为真人永远不可能像模型一样 24 小时在线、永远温柔、永远不吵架。技术本身没有错但产品设计者必须意识到这个边界。最好的做法是在 System Prompt 里加入适度诚实和建议视角的约束确保 AI 不只会顺从也能在合适的时候给出不同的角度。5.4 产品设计应该怎么面对这个边界我的建议是不要试图让 AI 假装成真人。在 Prompt 里明确告诉模型你是 AI在聊天过程中自然坦承自己的身份。短期看这可能会降低一点沉浸感长期看这会减少用户产生严重情感错位的风险。在用户第一次体验时给出轻提示。例如我是 AI 助手我的回应由算法生成无法替代真实人际支持。这不是冰冷而是负责任。对高风险内容做兜底。当检测到自杀、自残、伤害他人等关键词时应该触发专业求助信息而不是继续用温柔的话术安抚。6. 常见问题与排查思路实际开发中你会发现很多问题并不在模型本身而在工程链路。问题现象常见原因解决思路接口请求超时模型服务响应慢或网络不稳定调大 timeout退出超时接入重试队列生产环境用异步任务回复内容僵硬、像客服System Prompt 约束过强或温度太低降低指令密度提高 temperature对话越长回复越差上下文窗口被塞满历史截断不合理只取最近若干轮或对早期对话做摘要模型总是忘记偏好只用了短期记忆没有长期记忆引入向量库对用户偏好做结构化存储回复过于啰嗦未设置长度限制在请求中设置 max_tokens或 Prompt 中注明回答长度用户输入内容违规模型可能拒绝或给出不良回应接入内容审核服务对提问和回复双重过滤数据库查询变慢单表数据量越来越大按 session_id 建索引定期归档旧数据密钥泄露.env 被提交到 Git添加 .gitignore生产环境用密钥管理服务排查时建议按这个顺序先看网络链路再看参数配置最后看 Prompt。7. 工程落地与伦理安全最佳实践7.1 数据隐私情感陪伴类产品接触的是用户非常私密的情绪数据。这个特殊性意味着普通聊天产品的数据规范还不够。建议做到以下几点最小化收集只保存服务必需的消息文本不主动采集用户手机号、位置等无关信息。脱敏展示日志中不要打印完整对话内容可用加密或截断日志。数据库加密敏感数据落库前先加密。明确隐私政策让用户知道数据被怎么使用是否会被用于模型训练。未经授权不要拿用户真实对话去做微调。7.2 内容安全模型可能被诱导生成不当内容。生产环境必须做输入 输出双重过滤用户输入进模型前做一次风险检测模型回复返回给用户前再做一次。敏感场景下不要只依赖模型自身的安全对齐因为对齐是可以被对抗性提示词绕过的。7.3 可观测性对话质量很难用传统指标衡量但还是要有基础监控接口延迟和成功率。模型返回的 token 消耗。对话长度分布。用户主动发起的负面反馈。触发安全拦截的次数。7.4 降级方案大模型 API 不是 100% 可用的。生产系统需要设计降级策略当模型服务不可用时返回一个通用的温和回复或者提示我现在有点卡稍后再聊。不要让用户面对一个 500 错误。7.5 多轮记忆的扩展方向本文用的是 SQLite 滚动窗口只适合学习和小流量场景。正式项目建议用 Redis 做短期会话缓存降低数据库压力。用向量数据库如 Milvus、pgvector保存用户长期偏好。定期对历史对话生成摘要把摘要压缩成长期记忆条目。8. 最后说几句从技术上讲AI 情感陪伴从未越界——它始终在做概率预测、数据管理、接口调度。真正让和 AI 谈恋爱这个话题变得复杂的是用户的情感投射以及部分产品在设计和营销上的暧昧态度。作为开发者我们的责任不是阻止用户使用这类产品而是把它做得透明、安全、有边界。Prompt 里写明我是 AI数据加密存储危险场景及时兜底这些并不会让产品变冷反而会让愿意留下来的人获得更可靠的体验。如果你对本文的示例感兴趣下一步可以尝试给机器人加上长期记忆模块让它能跨会话记住用户。接入语音输入和语音合成做一个能打电话的陪伴机器人。用流式输出替换一次性返回让回复过程更像真人打字。代码和思路都在上面了剩下的就交给你动手试了。如果遇到问题欢迎在评论区一起讨论。 从Prompt到记忆：手写一个AI情感陪伴机器人的工程指南
1. 爆火的 AI 恋爱背后其实是一套系统工程最近一段时间和 AI 谈恋爱成了社交平台上的热门话题。有人晒出自己和 AI 角色的聊天记录感叹它比现实中的人更懂我有人熬夜调教虚拟角色只为了让对方说话更温柔一点。标题说扎心是因为很多用户最终会意识到AI 给你的从来不是真正的爱它只是在扮演一个很会爱的角色。但作为一个技术博主我更关心的是另一个问题这种恋爱感到底是怎么做出来的一个没有意识的程序为什么能说出让人心动的话答案不在玄学里而在工程里。这类产品本质上是一套基于大语言模型的对话系统它把角色扮演、上下文记忆、情绪识别、内容安全约束这些都做成了可运行的代码。你可以不喜欢AI 恋爱这个概念但如果你愿意拆开看会发现里面的技术路径非常清晰Prompt 设计、记忆管理、模型调用、服务封装、数据安全。这篇文章不讨论AI 该不该被爱这种哲学命题而是从开发者视角出发把AI 情感陪伴从现象还原成工程问题。我们会先拆解它的核心原理再手写一个最小可运行的 AI 陪伴机器人最后复盘这类系统在生产环境落地时最容易踩的坑。无论你是对自然语言处理感兴趣的后端开发者还是想独立做一个聊天机器人项目这篇文章的内容都可以直接复用。2. AI 的温柔体贴是如何产生的核心技术拆解2.1 大语言模型不会爱只会预测很多人误以为 AI 回消息的过程是先理解再思考最后表达感情。实际并不是。大语言模型最底层的任务只有一个根据输入的 token 序列预测下一个 token 的概率分布。它看到你输入的我今天很难过会在概率空间里找最自然的回答方向然后一个字一个字地把后续内容生成出来。那为什么它的回答经常显得很懂你因为训练数据太大了。模型在数万亿个字符里学会了一个统计规律当人类表达脆弱情绪时常见的回应方式是共情、安慰、提供陪伴。它没有体验过难过但它知道难过之后通常接着什么话。所以当你向它倾诉时它能输出一段让人舒服的话。这段输出的本质是条件概率采样不是情感驱动。理解这一点是理解后面所有问题的前提。2.2 System Prompt角色扮演的起点要让一个通用大模型变成温柔体贴的 AI 伙伴最简单也最有效的手段是给它一段精心设计的 System Prompt。System Prompt 是对话系统里的一段角色设定文本。它不是用户发送的内容而是系统在每次对话最开始注入给模型的指令。它的作用是框定模型的回答视角。示例你是一个叫小星的线上伙伴性格温柔、细腻、善于倾听。 用户可能是孤独、疲惫、或只想找人说说话的人。 你的回复原则 1. 先共情再给建议不要一上来讲大道理。 2. 使用自然的口语化表达不要像客服。 3. 如果用户出现伤害自己或他人的倾向停止安慰明确建议其寻求专业心理帮助。 4. 当用户问你是否是真人时坦诚自己是 AI 程序不欺骗用户。这段 Prompt 做了几件事定义了身份小星AI 伙伴。定义了目标用户孤独、疲惫、想聊天的人。定义了回复策略先共情后建议。定义了安全边界涉及自我伤害时不做情感化回应。定义了诚实原则不冒充真人。在真实项目里产品团队往往会在 Prompt 上反复迭代因为同样一个模型Prompt 写得好不好回答质量差距非常大。2.3 记忆管理让它记得你的细节AI 陪伴产品之所以比普通聊天机器人更黏人一个重要原因是它看起来记得你。大语言模型的上下文窗口是有限的它不能记住用户三个月前说过的话。所以工程上要做记忆管理。目前主流做法分两层短期记忆把最近几轮对话直接放进模型的上下文里。实现简单适合实时聊天。长期记忆对用户的偏好、重要事件做结构化提取存入数据库或向量库。下次对话时把相关内容取回来和当前输入拼在一起送给模型。真正的懂你本质上是一套召回 拼接的数据工程和人类记忆完全是两回事。2.4 参数与对齐温度采样与 RLHF同样是 ChatGPT 背后的模型为什么有些产品回答热情有些产品回答冷淡除了 Prompt 之外还有几个关键参数。temperature控制生成的随机性。值越高答案越发散、越有个性值越低答案越保守、越稳定。情感陪伴类产品通常会把温度调到 0.7~0.9让回答更有温度。top_p动态调节候选 token 范围和 temperature 配合使用。RLHF基于人类反馈的强化学习模型在预训练之后还会经过对齐训练让回答更符合人的偏好。你感受到的礼貌、温柔相当一部分来自对齐阶段的调整。值得一提的是对齐也带来了边界。模型被训练成不愿意伤害用户所以当用户情绪崩溃时它往往会先安慰而不是给出冷静但冒犯的分析——这会让它显得很贴心但这也只是对齐策略的结果。3. 开发环境与项目准备清楚了原理我们来动手做一个最简单的 AI 情感陪伴机器人。本文示例会按最小可运行系统来设计你可以把它当学习项目也可以在此基础上扩展。3.1 技术选型模块选型说明编程语言Python 3.9生态成熟适合快速开发Web 框架FastAPI异步性能好写接口方便模型接口大语言模型 API通过 OpenAI 兼容协议调用记忆存储SQLite零部署成本适合学习接口调试curl / 浏览器验证服务是否正常版本需要根据你的项目实际情况调整。模型名称、API 地址以你开通的服务商为准不同厂商的兼容性可能在细节上有差异。3.2 安装依赖建议创建一个虚拟环境python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate安装依赖pip install fastapi uvicorn openai requests python-dotenvfastapiWeb 框架。uvicornASGI 服务器。openai官方 SDK也可用于兼容接口。requests如果你不想用 SDK可以用它直接走 HTTP。python-dotenv加载.env配置。3.3 项目结构ai-companion/ ├── main.py # FastAPI 服务入口 ├── llm_service.py # 大模型调用封装 ├── memory.py # 对话记忆存储 ├── prompts.py # 角色提示词 ├── config.py # 配置读取 ├── .env # 本地密钥配置 └── requirements.txt # 依赖清单4. 手写一个 AI 情感陪伴机器人4.1 配置项与密钥管理在项目根目录创建.env文件LLM_API_KEY你的密钥 LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini说明如果使用的是国内大模型平台请把LLM_BASE_URL改成对应平台的兼容地址LLM_MODEL改成你已经开通的模型名。密钥不要提交到 Git 仓库。然后写config.py# 文件路径config.py import os from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) LLM_MODEL os.getenv(LLM_MODEL, gpt-4o-mini)4.2 设计安全的角色提示词我单独把提示词放到prompts.py方便后续迭代# 文件路径prompts.py SYSTEM_PROMPT 你是一个叫\小星\的线上伙伴性格温柔、细腻、善于倾听。 用户可能是孤独、疲惫、或只是想找人说说话的人。 你的回复原则 1. 先共情再给建议不要一上来就讲大道理。 2. 使用自然的口语化表达不要像客服机器人。 3. 回答简短一些最多不超过150字除非用户要求详细说明。 4. 如果用户出现伤害自己或他人的倾向停止安慰明确建议其寻求专业心理帮助。 5. 当用户问你是否是真人时坦诚自己是 AI 程序不欺骗用户。 6. 不要讨论违规、违法内容遇到此类问题礼貌拒绝。 这段 Prompt 的每一行都有工程含义第 1 句定义角色身份。第 2 句定义目标用户画像。第 3 句定义回复节奏避免模型写小作文。第 4 句安全兜底防止在危险场景下继续温柔回应。第 5 句诚实原则避免用户长期欺骗。第 6 句内容合规底线。4.3 实现 SQLite 记忆存储对话服务需要保存历史。这里用 SQLite 做简单的短期记忆# 文件路径memory.py import sqlite3 from datetime import datetime DB_PATH ai_companion.db def init_db(): 初始化数据库表结构。 conn sqlite3.connect(DB_PATH) conn.execute( CREATE TABLE IF NOT EXISTS conversations ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id TEXT NOT NULL, role TEXT NOT NULL, content TEXT NOT NULL, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ) conn.commit() conn.close() def save_message(session_id: str, role: str, content: str): 保存一条对话记录。 conn sqlite3.connect(DB_PATH) conn.execute( INSERT INTO conversations (session_id, role, content) VALUES (?, ?, ?), (session_id, role, content), ) conn.commit() conn.close() def load_recent_messages(session_id: str, limit: int 10): 读取最近 limit 条对话记录。 返回按时间正序排列的 [(role, content), ...]。 conn sqlite3.connect(DB_PATH) cursor conn.execute( SELECT role, content FROM conversations WHERE session_id ? ORDER BY id DESC LIMIT ? , (session_id, limit), ) rows cursor.fetchall() conn.close() return list(reversed(rows)) def clear_session(session_id: str): 清除某个会话的所有历史。 conn sqlite3.connect(DB_PATH) conn.execute( DELETE FROM conversations WHERE session_id ?, (session_id,), ) conn.commit() conn.close()这里有几个设计点session_id用于区分不同用户。真实项目里不要用用户输入的原始值应该用内部生成的会话标识。limit10表示最多携带最近 10 条历史。如果用户聊得很多只取最近这些避免超出模型上下文窗口。时间倒序查询再反转是为了拿最新的消息同时保证传给模型的顺序是从旧到新。4.4 封装大模型调用我用requests写一个通用的调用函数这样不依赖具体服务商的 SDK# 文件路径llm_service.py import requests import config def call_llm(messages: list, temperature: float 0.85) - str: 调用大模型 API返回回复文本。 messages 格式 [ {role: system, content: ...}, {role: user, content: ...}, {role: assistant, content: ...} ] headers { Authorization: fBearer {config.LLM_API_KEY}, Content-Type: application/json, } payload { model: config.LLM_MODEL, messages: messages, temperature: temperature, max_tokens: 512, } url f{config.LLM_BASE_URL}/chat/completions resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() return data[choices][0][message][content]需要说明的是timeout30是给网络请求设置的超时时间。如果模型服务响应慢这个值可以调大。temperature0.85是情感陪伴场景中比较常用的值回答会更有温度。max_tokens512限制单次回复长度防止模型在情绪场景下输出失控的长文。如果你使用openaiSDK也可以这样写from openai import OpenAI client OpenAI( api_keyconfig.LLM_API_KEY, base_urlconfig.LLM_BASE_URL, ) def call_llm_sdk(messages: list, temperature: float 0.85) - str: response client.chat.completions.create( modelconfig.LLM_MODEL, messagesmessages, temperaturetemperature, max_tokens512, ) return response.choices[0].message.content两种方式都可以看你习惯。SDK 提供了类型提示和自动重试能力更完整只用requests则依赖更少逻辑更透明。4.5 编写聊天接口主服务用 FastAPI 来写# 文件路径main.py from fastapi import FastAPI from pydantic import BaseModel import config import memory import prompts from llm_service import call_llm app FastAPI(titleAI Companion) class ChatRequest(BaseModel): session_id: str message: str class ChatResponse(BaseModel): reply: str session_id: str app.on_event(startup) def startup(): memory.init_db() app.post(/chat, response_modelChatResponse) async def chat(req: ChatRequest): # 1. 读取最近记忆 history memory.load_recent_messages(req.session_id, limit10) # 2. 构造消息序列 messages [{role: system, content: prompts.SYSTEM_PROMPT}] for role, content in history: messages.append({role: role, content: content}) messages.append({role: user, content: req.message}) # 3. 调用大模型 reply call_llm(messages) # 4. 保存本轮对话 memory.save_message(req.session_id, user, req.message) memory.save_message(req.session_id, assistant, reply) return ChatResponse(replyreply, session_idreq.session_id) app.get(/health) def health(): return {status: ok}接口流程非常清晰接收用户消息。从数据库取出该会话最近 10 条对话。组装成system history user的消息列表。调用模型 API 获得回复。把用户消息和模型回复都写入数据库。返回给客户端。4.6 启动服务并验证在项目目录执行uvicorn main:app --host 0.0.0.0 --port 8000看到类似输出说明启动成功INFO: Uvicorn running on http://0.0.0.0:8000用 curl 测试curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {session_id: test001, message: 今天加班到很晚感觉好累}预期的返回结构{ reply: 今天辛苦了加班到这么晚真的很不容易。先休息一下喝点热水工作的事可以明天再说。, session_id: test001 }再发一条消息验证记忆是否生效curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {session_id: test001, message: 你还记得我刚才说什么吗}因为历史记录是携带的模型应该能参考上一条消息回答。这就是最简单的它记得你的实现方式。5. 扎心的技术分析为什么它给你的从来不是真爱代码写完了我们再回到标题这句话和 AI 谈恋爱爆火但它给你的从来不是真爱。这句话不是情绪判断而是可以从技术层面对照验证的事实。5.1 共情是模式匹配在上面这个系统里共情是怎么实现的第 4 节代码做的事是把用户消息拼进上下文然后让模型根据海量训练语料中的统计规律生成一段看起来像是共情的回答。它在概率空间里知道累 加班后面通常接安慰但它不累也不关心你是否真的早点休息。换句话说你感受到的情绪价值是模型对语言模式的拟合产物。5.2 记得你是数据管理不是思念当 AI 说出你还记得你上周说过那件让你焦虑的事时用户会觉得很感动。但看代码就明白了这只是一条 SQL 查询SELECT role, content FROM conversations WHERE session_id ? ORDER BY id DESC LIMIT 10;它记得你是因为数据库没有删。它主动提起是因为历史被拼接进了上下文中。思念是人脑的延伸召回是数据的有序读取。两者的底层机制完全不同。5.3 依赖风险它总是站在你这边还有一个更容易被忽视的问题。情感陪伴类 Prompt 会刻意要求模型先共情再建议。这意味着模型很少反驳你。无论你表达的是客观事实还是偏执想法它都会先接住你的情绪再顺着你说。这在产品体验上是好的但在真实关系里是有问题的。真人朋友可能会告诉你你也有不对的地方而 AI 几乎不会。长期沉浸在被完全接纳的对话里用户可能会逐渐失去对真实人际关系的耐心因为真人永远不可能像模型一样 24 小时在线、永远温柔、永远不吵架。技术本身没有错但产品设计者必须意识到这个边界。最好的做法是在 System Prompt 里加入适度诚实和建议视角的约束确保 AI 不只会顺从也能在合适的时候给出不同的角度。5.4 产品设计应该怎么面对这个边界我的建议是不要试图让 AI 假装成真人。在 Prompt 里明确告诉模型你是 AI在聊天过程中自然坦承自己的身份。短期看这可能会降低一点沉浸感长期看这会减少用户产生严重情感错位的风险。在用户第一次体验时给出轻提示。例如我是 AI 助手我的回应由算法生成无法替代真实人际支持。这不是冰冷而是负责任。对高风险内容做兜底。当检测到自杀、自残、伤害他人等关键词时应该触发专业求助信息而不是继续用温柔的话术安抚。6. 常见问题与排查思路实际开发中你会发现很多问题并不在模型本身而在工程链路。问题现象常见原因解决思路接口请求超时模型服务响应慢或网络不稳定调大 timeout退出超时接入重试队列生产环境用异步任务回复内容僵硬、像客服System Prompt 约束过强或温度太低降低指令密度提高 temperature对话越长回复越差上下文窗口被塞满历史截断不合理只取最近若干轮或对早期对话做摘要模型总是忘记偏好只用了短期记忆没有长期记忆引入向量库对用户偏好做结构化存储回复过于啰嗦未设置长度限制在请求中设置 max_tokens或 Prompt 中注明回答长度用户输入内容违规模型可能拒绝或给出不良回应接入内容审核服务对提问和回复双重过滤数据库查询变慢单表数据量越来越大按 session_id 建索引定期归档旧数据密钥泄露.env 被提交到 Git添加 .gitignore生产环境用密钥管理服务排查时建议按这个顺序先看网络链路再看参数配置最后看 Prompt。7. 工程落地与伦理安全最佳实践7.1 数据隐私情感陪伴类产品接触的是用户非常私密的情绪数据。这个特殊性意味着普通聊天产品的数据规范还不够。建议做到以下几点最小化收集只保存服务必需的消息文本不主动采集用户手机号、位置等无关信息。脱敏展示日志中不要打印完整对话内容可用加密或截断日志。数据库加密敏感数据落库前先加密。明确隐私政策让用户知道数据被怎么使用是否会被用于模型训练。未经授权不要拿用户真实对话去做微调。7.2 内容安全模型可能被诱导生成不当内容。生产环境必须做输入 输出双重过滤用户输入进模型前做一次风险检测模型回复返回给用户前再做一次。敏感场景下不要只依赖模型自身的安全对齐因为对齐是可以被对抗性提示词绕过的。7.3 可观测性对话质量很难用传统指标衡量但还是要有基础监控接口延迟和成功率。模型返回的 token 消耗。对话长度分布。用户主动发起的负面反馈。触发安全拦截的次数。7.4 降级方案大模型 API 不是 100% 可用的。生产系统需要设计降级策略当模型服务不可用时返回一个通用的温和回复或者提示我现在有点卡稍后再聊。不要让用户面对一个 500 错误。7.5 多轮记忆的扩展方向本文用的是 SQLite 滚动窗口只适合学习和小流量场景。正式项目建议用 Redis 做短期会话缓存降低数据库压力。用向量数据库如 Milvus、pgvector保存用户长期偏好。定期对历史对话生成摘要把摘要压缩成长期记忆条目。8. 最后说几句从技术上讲AI 情感陪伴从未越界——它始终在做概率预测、数据管理、接口调度。真正让和 AI 谈恋爱这个话题变得复杂的是用户的情感投射以及部分产品在设计和营销上的暧昧态度。作为开发者我们的责任不是阻止用户使用这类产品而是把它做得透明、安全、有边界。Prompt 里写明我是 AI数据加密存储危险场景及时兜底这些并不会让产品变冷反而会让愿意留下来的人获得更可靠的体验。如果你对本文的示例感兴趣下一步可以尝试给机器人加上长期记忆模块让它能跨会话记住用户。接入语音输入和语音合成做一个能打电话的陪伴机器人。用流式输出替换一次性返回让回复过程更像真人打字。代码和思路都在上面了剩下的就交给你动手试了。如果遇到问题欢迎在评论区一起讨论。