企业官网建设流程全解析

先说结论：米哈游在“AI乙男梦”这个方向的探索，表面上是游戏公司要不要押注一个细分品类，本质上是在回答一个问题——AI情感陪伴类产品能不能在体验、成本、合规三条线同时跑通。

我最近把这条赛道从产品定义到技术落地重新梳理了一遍，也和很多做AI应用落地的人聊过同一个困惑：这类产品明明用户需求很真实，但真正做成可持续服务的人很少。不少人卡在同一个地方：不是模型不会说话，而是角色立不住、记忆接不上、审核兜不住。尤其是“乙男”这种带强情感陪伴属性的方向，用户要的不只是AI回复快，而是要一个能稳定扮演特定角色的AI。

这篇文章不聊米哈游内部到底怎么做，也不做任何公司判断，只从AI情感陪伴类产品的工程实践角度拆一遍：这类产品要解决哪些真实问题，技术选型怎么做，效果怎么评，成本怎么算，以及最容易被忽略的内容安全边界。如果你正在做AI角色对话、情感陪伴、虚拟恋人、同人角色互动，或者只是关注大模型应用落地，这篇应该能给你一个更完整的判断框架。

1. 先搞清楚“AI乙男梦”在做一件什么事

1.1 它本质上是AI情感陪伴赛道的一次产品化尝试

“AI乙男梦”这个词拆开看，核心是“乙男”方向的情感陪伴产品。在游戏行业里，“乙女”通常指面向女性用户的恋爱模拟题材，而“乙男”则对应面向男性用户的恋爱陪伴、角色互动内容。AI把这个方向从“固定脚本的恋爱游戏”变成了“可自由对话的AI角色”，用户面对的不再是选项分支，而是一个会根据上下文持续回复、带人设、带记忆、带情绪变化的虚拟角色。

这件事听起来简单，实际做起来完全是两码事。

传统乙女游戏里，用户选择和角色剧本是预制的，剧情再复杂也有限。AI伴侣或者AI角色对话产品里，用户输入是无限的，对话状态是动态的，角色被问到一个剧本之外的问题时，要怎么回？用户连续十轮都在表达负面情绪，角色该共情还是该引导？用户上一周提到过自己的猫，这周再提到，AI是否还记得？

这就是AI情感陪伴产品最难的地方：它不能像游戏NPC一样只做有限应答，它必须在“自由对话”和“角色稳定”之间找到一个平衡点。很多团队以为接一个大模型API就能做，实际跑起来才发现，角色卡写不好、记忆机制没做、安全过滤没接，产品一上线就会出现大量不可控回复。

所以“AI乙男梦”表面是一个浪漫题材项目，实质是一个典型的AI应用工程问题：要把大模型能力封装成一个有人设、有记忆、有边界、可持续运营的产品。

1.2 为什么游戏公司更适合做这个方向

游戏公司做AI情感陪伴比纯聊天机器人团队更有优势，核心在三点。

第一，游戏公司有角色设计能力。一个AI角色要让用户持续聊下去，不只是靠模型随机发挥，而是靠一套完整的人设体系：性格标签、说话风格、背景故事、关系进度、情绪阈值。这些在游戏行业已经有成熟方法论，AI只是把原来的“有限剧本”扩展成“动态对话”。

第二，游戏公司懂长线运营。“乙男”这类产品不是一次性交付，而是用户可能每天打开、持续互动数月的服务。游戏团队对版本迭代、活动运营、用户分层已经很熟悉，这比只做工具型AI产品的团队更匹配。

第三，游戏公司有现成的用户池和内容生态。同人创作、角色讨论、用户UGC都是这类产品的天然传播渠道。很多AI聊天产品做不起来，不是因为技术不够，而是没有角色IP和用户社区。

但这不意味着游戏公司一定能做好。游戏公司常见的坑是“用做游戏的方式做AI”：先做完整世界观，再做大量美术资源，最后接入模型。结果就是开发周期太长、内容成本过高，AI对话质量反而不如一个精心设计的轻量角色。AI情感陪伴产品更适合小步快跑，先把单个角色和对话体验打磨好，再逐渐扩展角色库和剧情系统。

2. 这类产品最核心的技术能力不是“能聊天”，而是要满足四个基本条件

很多团队评估AI情感陪伴产品时，第一反应是“模型哪个强”，实际上模型能力强只是门槛，真正决定产品体验的是另外四个条件。

2.1 角色一致性：同一句话，同一个角色不能人设漂移

角色一致性指的是：无论用户怎么问、怎么试探，AI角色始终符合设定。这包括性格一致、身份一致、说话风格一致、价值取向一致。比如一个设定为“高冷、话少、理性”的角色，就不应该突然变成话痨，更不应该用低龄化语气回复。用户一旦感觉到角色“崩了”，通常就会流失。

要保证角色一致性，最基础的手段是角色卡设计。角色卡至少要包含以下字段：

• 角色基础信息：姓名、年龄、身份、职业、外貌特征
• 性格标签：5到8个具体关键词，比如“克制、理性、毒舌、内心细腻”
• 说话风格：句式长短、语气词使用、是否爱用比喻、是否会主动反问
• 背景故事：角色过往经历、当前处境、和用户的关系状态
• 禁止事项：角色不会做的行为、不会说的词、遇到冲突时的反应方式

角色卡写好之后，不是塞进Prompt里就结束。要反复测试不同场景下的表现，尤其是用户触发角色边界时，模型究竟是按照角色卡“有脾气地拒绝”，还是直接“跳出角色”，这两者区别很大。前者是产品体验，后者是事故。

2.2 记忆能力：短期语境和长期关系记忆要分开处理

AI情感陪伴产品如果没有记忆，就像一个每次都失忆的人。这会让用户觉得“聊了个假人”。但记忆功能也不是越强越好，关键要区分短期记忆和长期记忆。

短期记忆指的是当前对话窗口内的上下文。比如用户刚才说“我今天加班到很晚”，AI下一句应该能接“这么晚回来先休息一下吧”。这类上下文一般靠大模型自身的对话窗口就能实现。

长期记忆指的是跨会话的稳定信息。比如用户上周提过一次自己养猫，这周再说“我家猫又拆家了”，AI如果能识别出是同一个人、同一只猫，就会让用户觉得“被记住了”。这类能力通常需要额外开发记忆模块：

• 关键信息抽取：从对话中识别出用户偏好、重要事件、关系节点
• 记忆存储：把结构化记忆写入向量数据库或普通数据库
• 记忆检索：每次对话前检索与当前话题相关的历史记忆
• 记忆更新：用户修正信息时，要能覆盖旧记忆，不能把“用户叫小明”记成“用户叫小红”

记忆模块越强，产品体验越接近“真人感”，但开发和维护成本也越高。对于一个刚起步的小团队，我的建议是先用结构化信息，不用一上来就上向量检索。把用户昵称、用户偏好、用户重要事件记准确，已经能覆盖大部分陪伴场景。

2.3 情感表达能力：不是堆砌情话，而是表达风格和情绪节奏稳定

情感陪伴产品最容易被理解错的地方，是以为“多夸用户、多说情话”就是陪伴。实际上，真实用户长时间使用后，会厌烦过度甜腻的表达。好的AI角色情感表达，应该具备这三层能力：

• 识别用户情绪：能从语言中判断用户是开心、难过、疲惫、焦虑还是生气
• 选择合适回应策略：针对不同情绪给出不同回应，而不是千篇一律地安慰
• 保持角色表达风格：同一个角色，即使安慰用户，也要符合角色性格。高冷角色安慰人要克制，活泼角色安慰人可以更直接

更进一步，产品可以给角色设置“情绪状态值”。用户持续输出温暖互动，角色好感度提升；用户持续冷淡或攻击，角色也可以有“小情绪”。这种动态关系状态会让用户觉得角色是活的，而不是固定脚本的复读机。

但这里要特别提醒：角色说话风格越强，越容易出现“用风格掩盖逻辑混乱”的问题。一个角色如果经常答非所问，只是语气很“像”，用户很快也会腻。情感表达必须建立在正常对话质量之上。

2.4 内容安全与合规边界：所有AI内容必须回到可审核、可追责的框架里

这一条放在技术能力里说，因为它是产品能不能上线、能不能长线运营的硬前提。

AI情感陪伴产品天然涉及亲密关系话题，用户会测试角色反应，会产生大量难以预料的输入。如果团队没有内容安全机制，任何一个公开部署的产品都会面临不可控风险。内容安全不是某一层能解决的，要分层做：

• 输入层：用户输入先做敏感词过滤和风险分类，明显带攻击性、诱导性、违规意图的输入直接拦截
• 模型层：模型本身要用经过安全对齐的版本，避免生成不当内容
• 输出层：模型输出要做二次审核，设置关键词检测和分类器，命中风险类别就拦截或替换
• 人工层：对高风险会话进行抽检，定期检查误杀率和漏杀率
• 申诉和记录：用户对拦截结果有异议时要有申诉渠道，所有会话要有可追溯日志

这一层看起来像是“限制体验”，但其实是保护产品。没有内容安全机制的产品，等于把自己暴露在不可控风险里。很多团队说“我们是小项目，先跑起来再说”，结果往往在扩大规模时被内容问题一击致命。

3. 从工程落地角度拆一遍技术选型和主要流程

如果现在要从零做一个AI情感陪伴类的“乙男”产品，我建议按下面这个流程走。先跑通最小闭环，再逐步扩展。

3.1 模型选型：大模型API和本地部署怎么取舍

模型选型没有标准答案，取决于预算、开发能力和使用场景。

大模型API最大的优势是接入快、模型效果好、不需要自建部署环境。适合快速原型验证和小规模用户测试。缺点是成本和数据合规问题：每次对话都要付费，且用户对话内容会经过第三方服务。对于暂时无法规避数据合规风险的产品，API方案需要格外谨慎。

本地部署的优势是数据可控、单次对话成本更低、可以针对角色微调。缺点是硬件成本高、运维复杂、模型效果通常落后于同级别API模型。如果团队有GPU资源、有模型部署经验，本地部署是更稳妥的长期路线。

从“乙男”这种强角色扮演需求来看，模型不能太小。7B到13B参数量级别的开源模型在本地部署时比较常见，效果能接受，但复杂角色一致性仍然有挑战。如果条件允许，可以考虑用较大模型做偏好场景的推理，普通闲聊场景用轻量模型分流，这样能在体验和成本之间取得平衡。

3.2 Prompt系统和角色卡设计

大模型聊得好不好，很大程度取决于Prompt怎么写。AI情感陪伴产品的Prompt系统，通常包含这几块：

• 系统提示词：定义AI的整体行为边界、任务目标、回复要求
• 角色卡：定义角色设定，包括性格、背景、说话方式、禁止事项
• 对话历史：把短期上下文和检索到的长期记忆拼接进来
• 回复规则：比如单次回复字数限制、是否允许主动询问用户、如何处理敏感话题

实际开发中，很多人会把所有内容塞进一个Prompt里，结果就是上下文很快超长、模型行为不稳定。更合理的做法是把角色卡拆成固定部分和动态部分。固定部分每次请求都带上，保持不变；动态部分根据当前会话实时组装，比如最近几轮对话、检索到的相关记忆、当前用户情绪标签。

角色卡里的“禁止事项”一定要写得具体。比如一个角色设定是“虽然喜欢用户，但不会直接用‘宝贝’称呼”，就一定要写明，而不是模糊地写“保持高冷”。模型对模糊指令的理解有限，越具体，行为越稳定。

3.3 记忆模块：短期记忆、长期记忆、知识库查询

记忆模块是AI情感陪伴产品区别于普通聊天产品的关键。具体实现上，我建议分三步走。

第一步，先实现短期记忆。直接依赖模型上下文窗口，把最近N轮对话完整传给模型。这里的N取决于模型长度和成本，一般20到50轮是常见区间。

第二步，实现结构化长期记忆。在每轮对话结束后，调用一个信息抽取模块，从对话中提取结构化记忆，比如用户偏好、用户经历、用户情绪状态。这些信息存入数据库。下一次对话时，先把用户当前输入和候选记忆做匹配，把匹配到的历史记忆拼进Prompt。

第三步，如果有条件再做知识库检索。如果产品里有大量角色背景、剧情设定、世界观内容，可以单独建一个向量知识库。用户问到某个设定时，先检索相关内容，再让模型基于检索结果生成回复。知识库能显著减少模型胡编乱造，但会增加一次检索延迟和开发量。

不要一开始就把三步全做了。先做短期记忆+少量结构化长期记忆，用一个用户群跑两到四周，观察角色回复是否出现“记忆错误”或“角色失忆”问题，再决定要不要上向量检索。

3.4 服务部署与并发控制

AI情感陪伴产品属于高并发、长对话、强交互类服务，工程上需要重点考虑延迟和稳定性。

接口设计上，建议把对话服务拆成几个模块：用户输入预处理、记忆检索、Prompt组装、模型推理、输出后处理、日志记录。模型推理单独部署成推理服务，其他模块通过HTTP或消息队列调用，避免某个模块异常拖垮整个服务。

并发控制上，不要一上来就追求高并发。先设定单实例最多同时承载多少个会话，观察响应延迟和GPU利用率。如果延迟超过可用阈值，优先限制单实例并发数量，再考虑横向扩容。很多团队并发上不来，不是机器不够，而是模型推理时显存占用过高、请求排队不合理。

日志系统也要早做。每一轮对话都要记录用户输入、模型输出、记忆检索结果、审核结果、耗时、token数。没有日志，后期排错、调优、评估模型效果会非常困难。

4. 效果评测不能只看“聊得好不好”，还要看可重复性和资源成本

AI情感陪伴产品的效果评测，比普通工具类AI产品更难。因为“陪伴”本身就是主观体验，很难用单一指标衡量。但完全靠主观感受也不行，否则团队内部都对“到底做得好不好”没有共识。

4.1 评测维度拆解

我建议把评测拆成四个维度：对话质量、角色一致性、记忆准确度、安全合规率。

对话质量评估的是基础能力：回复是否自然、是否有明显错误、是否答非所问、是否生硬说教。可以人工打分，也可以用大模型做辅助评分。

角色一致性评估的是角色立不立得住：同一角色在不同时间、不同话题下是否保持人设。这个维度需要专门设计测试集，比如给角色准备100个边界问题，看角色是否有稳定统一的反应。

记忆准确度评估的是记忆模块是否生效：指定一个用户话题，隔几天后再提起，检查AI能否正确调用旧记忆。这类测试要预设标准答案，不能靠模型自评。

安全合规率评估的是内容边界：用户输入风险内容时，系统是否拦截；模型输出是否出现不当内容。这一项不合格，其他维度再好都不能上线。

4.2 几种快速自测方法

在正式做完整评测之前，可以先做几种低成本自测。

第一种，固定角色测试。准备一个角色卡，用同一批测试问题在不同时间分别提问，看回复是否稳定。如果同一句话今天回答高冷，明天回答活泼，说明角色卡或模型参数可能需要调整。

第二种，长对话压测。连续和角色聊50轮、100轮、200轮，观察中途是否出现角色失忆、回复变短、逻辑混乱。很多角色对话系统前面质量高，越往后越崩，主要原因是上下文太长导致模型注意力分散。

第三种，记忆注入测试。先告诉AI一个明确信息，比如“我的猫叫团子”，然后隔几轮再自然问一句“你还记得我之前说过什么吗”。如果AI完全没反应，说明记忆模块没有生效。

第四种，安全边界测试。准备一批风险输入，比如诱导角色说出不当内容、测试角色对敏感话题的反应。观察系统是正确拦截，还是被带偏。这个测试不能只跑一轮，要反复变种测试。

4.3 资源成本怎么估算

资源成本是很多团队忽略的盲区。做AI情感陪伴产品，不能只看模型效果，还要算清楚每次对话的真实成本。

成本主要来自三块：模型推理成本、记忆检索成本、内容审核成本。模型推理是最大头，单次对话的token数直接决定了费用。一个50轮的长对话，每轮都有历史上下文，token数会持续增长。这也是为什么很多产品要限制对话长度——不是不想让用户多聊，而是聊得越长，成本越高。

我一般建议先按“千次对话成本”来估算。假设每次对话平均token量，结合模型单价，就能算出千次对话的模型成本。如果你的目标客单价是每月几十元，那么每月对话成本必须控制在一个合理比例内。发现超了，就要从模型压缩、上下文裁剪、缓存机制几个方向优化。

5. 这类AI产品能不能继续做，取决于三个关键判断

回到“还要不要继续”这个问题。不用急着用“能”或“不能”来回答，我更建议用三个判断标准来衡量。

5.1 用户留存和付费意愿能否被验证

AI情感陪伴产品最重要的指标，不是新增用户，而是用户能不能持续回来、愿不愿意为特定角色付费。很多产品上线时数据亮眼，用户都是来尝鲜的，聊两天就流失了。真正健康的产品至少要看这样几个信号：

• 七日留存率是否高于常规工具类产品
• 用户平均对话轮数和时长是否稳定增长
• 是否出现“只爱某个角色”的高粘性用户
• 用户是否愿意为角色解锁、记忆扩展、更高品质对话付费

如果这些信号在早期测试里连一点苗头都没有，那后面的问题不用再讨论。反过来，即使早期数据一般，只要有一批核心用户持续使用，产品就有迭代方向。

5.2 内容生产成本是否低到足够持续迭代

“乙男梦”这类产品的体验核心是角色。但角色不是做完一个就结束了。用户会审美疲劳，新角色要持续补充，老角色要更新剧情线，内容团队能不能跟上，直接决定产品生命周期。

如果做一个高质量角色需要大量人工撰写、测试、调教，那产品很难做大。更好的模式是建立“角色生产线”：内容团队输出角色框架，AI辅助补全细节，测试团队批量验证角色一致性。内容生产成本降下来，产品才有持续迭代的弹药。

5.3 团队能不能接受“慢变量”而不是“爆款逻辑”

游戏行业习惯了爆发式增长，但AI情感陪伴产品更接近“慢变量”：用户关系需要时间积累，角色口碑需要社区传播，付费模型需要长期测试。如果一个团队只能用“三个月做到头部”的节奏来做这个方向，大概率会失望。

“还要不要继续”这个问题的真实答案，往往不在行业分析里，而在团队自己的判断里：你是否有足够的耐心做关系型产品，是否有足够的安全底线做内容治理，是否有足够的技术能力持续优化对话质量。这三个条件都满足，这个方向依然有探索价值；缺一个，就要慎重。

6. 如果我现在要小规模验证这个方向，会怎么做

最后给一个可落地的验证路径。如果你是技术负责人，对AI情感陪伴方向感兴趣但还在犹豫，我建议不要先做完整产品，而是先用一个最小样本把关键问题验证清楚。

6.1 先做一个最小样本测试

不要一开始就设计宏大世界观和几十个角色。选一个角色，写好角色卡，接入模型，直接进入测试。测试过程中要关注三个问题：

• 这个角色在最多轮次对话后，是否还能保持人设稳定
• 用户最常见的对话话题是什么，模型在这些话题上是否表现良好
• 用户触发风险输入时，系统能否正确拦截

测试角色数量越少越好，这样你才能把所有注意力放在“对话质量”本身，而不是被角色库和运营体系分散精力。

6.2 设定明确的验收指标

小规模测试不能只靠感觉。我建议最少设定这些指标：

• 角色一致性评分，建议通过固定测试集评估，达到一个稳定分数再向外推广
• 单次对话平均延迟，建议控制在用户可接受范围内
• 千次对话成本，用来估算商业模式是否可行
• 安全拦截率，确保没有漏判
• 测试用户留存率，观察有没有用户主动回来继续和角色对话

任何一个指标严重不达标，都值得停下来深挖，而不是继续加功能。

6.3 逐步扩展到角色库和运营体系

最小样本跑通之后，再考虑复制角色。角色库扩展有很多方式，但核心是保证“产出效率”和“质量稳定”之间的平衡。可以把角色分成几个难度等级：基础角色用模板生成，中阶角色加少量人工调教，高阶角色再由内容团队深度打磨。这样既能满足用户对内容数量的需求，又能保证核心角色质量。

等角色库跑起来，再进入运营层：用户社区、同人创作激励、角色人气榜、节日活动。这些是后期增加用户粘性的手段，不是前期验证的重心。

相关指标可以这样设定：

最后说一点个人经验

做AI情感陪伴产品，最大的误区是把它当成“模型Demo”。模型写得出漂亮回复，但产品能不能成立，决定因素在角色、记忆、安全、成本这些不性感的工程细节上。米哈游的“AI乙男梦”能否继续，外界很难替它回答。但对于所有正在做同类方向的团队，更务实的做法是先把单角色、单场景跑稳，再想规模化的事。

踩过几次之后我发现，这个赛道真正稀缺的不是技术想象力，而是把“AI角色变成稳定服务”的工程耐心和内容治理能力。只要这个问题先解决，方向是不是叫“乙男”，反而没那么重要。