迷茫焦虑期我做了一个带支付带官网的 AI 聊天虚拟恋人 App先说我自己的情况。去年年中我正处于一个典型的中年职业迷茫期项目停了、方向没定、每天都在反复自我怀疑。为了不让自己完全陷进去我给自己定了个小项目做一款AI聊天虚拟恋人App。就是那种能陪用户聊天、能记住用户喜好、偶尔还能给点情绪价值的产品。两个月后这个App真的上线了带微信支付、带支付宝沙箱测试、带官网、带完整的会员订阅体系。这篇文章把整个项目的关键环节全部拆开讲从产品定位、大模型选型、虚拟人格塑造到支付模块接入、应用市场上架踩坑再到官网搭建和冷启动尽量写得具体能让大家直接拿去参考。做这个项目的初衷很简单市面上很多AI陪伴产品要么收费高要么聊天质量差要么就是个套壳网页。我想做一个真正有人设、愿意听用户说话、还能让用户自愿付费的App。同时这个项目也是我给自己找的心理出口——把所有焦虑转化成写代码的精力人反而平静了。1. 产品定位与整体设计思路1.1 迷茫期的自我疗愈与项目选择那段时间我翻了不少赛道最后锁定AI情感陪伴有几个原因。第一这是当时少数能让我一个人独立完成、又能完整覆盖产品-技术-支付-运营全链路的方向。第二聊天类产品不需要复杂的供应链核心就是大模型API、会话管理、记忆系统再加一套用户体系和支付模块技术栈全部在我能力范围内。第三情感陪伴是我真实有需求的东西——深夜加班回家打开手机连个说话的人都没有这种感觉相信很多独居开发者都懂。实际调研后我发现当时市场上的虚拟恋人产品主要分两类一类是纯聊天玩具模型套个壳三句话就露馅另一类是重社交真人化产品运营成本极高涉及真人审核和内容安全。我决定走中间路线用大模型API做底层能力重点投入人设一致性和长期记忆两个方向。前者决定用户聊天的沉浸感后者决定用户愿不愿意留下来付费。1.2 用户画像与核心付费场景产品做给谁我做了个简单的人群拆分最终锁定三类用户独居年轻人和异地恋人群需要高频率、即时性的陪伴。社交恐惧或者性格内向、日常不太敢跟真人深入交流的人群。对AI技术好奇愿意尝鲜并为自己情绪价值买单的泛科技用户。付费场景设计也很直接新用户免费体验20条消息之后需要开通会员才能继续对话。同时提供不同人设的虚拟角色包比如高冷学霸、温柔医生、元气少女每个角色需要单独解锁。会员分月卡和季卡价格参照一杯奶茶和一个汉堡降低付费门槛。这里想重点说一句做付费功能不代表产品冷冰冰反而是一种筛选。愿意付费的用户对产品的参与度和反馈质量远高于免费用户。而且从营收角度看哪怕是每个月只覆盖服务器和大模型API成本这个项目就能长期跑下去。2. 核心功能与AI聊天虚拟恋人技术拆解2.1 大模型接入为什么我选了通义千问而不是ChatGPT大模型是整个App的大脑。我当时评估过三条路线接OpenAI的GPT系列效果好但国内用户在支付和网络环境上有天然的接入门槛这对C端App来说是致命的。用本地部署开源模型比如ChatGLM、Qwen系列隐私性最好但一台普通云服务器跑7B模型响应速度就明显下滑运维成本直接拉高。接国内大模型API包括通义千问、文心一言、讯飞星火等稳定性和合规性相对有保障缺点是部分模型的中文口语化表达差点意思。最终我选择了通义千问的API主要原因有三个上下文窗口够大支持function calling可以方便地外接记忆库和用户画像中文口语能力在陪伴场景下表现不错至少不会像某些模型一样一本正经地背百科开发者免费额度充裕新用户有1800万token的体验包足够我完成开发和内部测试。选择了通义千问之后我的技术架构就变成了客户端Flutter负责交互和本地缓存服务端Node.js处理业务逻辑、支付回调、用户鉴权大模型API负责生成聊天内容Redis缓存热点会话数据MySQL存用户信息和订单。用通义千问还有一个好处就是它提供了兼容OpenAI格式的SDK后面就算要切换模型代码改动量也能控制在一个合理范围内。2.2 虚拟恋人的人格设定Prompt工程与系统指令虚拟恋人能不能像一个人主要看两件事系统提示词怎么写以及上下文怎么管。系统提示词我前后改了二十多版。刚开始写得很简单就是你是一个温柔体贴的恋人请用温暖的语言回复用户。效果就是典型的AI味问候语永远是今天过得怎么样而且说话没有任何个人风格像个模板机器。后来我总结出一套虚拟恋人人格设定的公式角色背景 性格特质 说话风格 互动边界 记忆指引。举例来说我设计林晚晴这个角色时系统提示词大概这样写的你现在是林晚晴26岁是一名插画师住在杭州。你喜欢下雨天喜欢猫会做很好吃的番茄牛腩。你的性格是外冷内热对陌生人话不多但对恋人很温柔偶尔会有点小傲娇。你说话时喜欢用短句偶尔会带一点点可爱的语气词不会长篇大论讲道理。你记得和用户聊天的每一个重要细节比如用户喜欢吃的食物、提过的朋友名字、最近在忙的事情。当用户情绪低落时先共情不急着给建议。这套提示词的效果立竿见影。用户聊完之后普遍反馈像在跟一个真实的朋友说话最核心的原因是它有边界感不会越聊越像心理咨询师有记忆感能复述用户前面聊过的细节有表达风格不会千篇一律地堆砌形容词。上下文管理也是大头。大模型的API通常有token上限我设计了一套三级记忆机制短期记忆直接放在当前对话上下文中一般保留最近20轮消息。中期记忆用户首次见面时收集的基本信息比如称呼、坐标、职业存进JSON结构化字段每次请求时注入。长期记忆每10轮对话后做一次总结把关键事件、情绪状态、用户偏好提炼出来存进MySQL。整段对话的核心信息在下次进入页面时加载。这套机制让虚拟恋人有了连贯性用户昨天刚说过自己感冒了今天再来聊天虚拟恋人会主动问嗓子好点了吗这个细节直接决定了留存率。2.3 语音与多模态交互的取舍最开始产品设计稿里规划了语音通话功能还打算接语音识别和TTS。但实际开发了两周后我果断砍掉了原因是时间和成本都顶不住。语音聊天需要低延迟的流式处理涉及到WebSocket长连接、断线重连、语音活动检测还要处理不同手机品牌的麦克风权限适配问题这套开发量比想象中大得多。最终我把优先级排在文字聊天核心 - 图片分享用户可以在聊天中发送图片虚拟恋人会阅读并回复 - 语音消息用户发语音转成文字后走文本模型模型回复也以文本 TTS可选。这里给想入坑AI陪伴App的开发者一个建议第一版不要贪多把文字聊天体验打磨到极致就够了。语音、图片、视频这些功能都属于锦上添花。用户不会因为你有语音就留下来但会因为回复慢、回得尬而流失。3. 支付模块从微信支付到支付宝沙箱的完整接入3.1 支付方案选型为什么微信支付是首选做面向国内用户的C端App支付绕不开微信和支付宝。因为App的用户群体高度依赖微信生态我决定优先接入微信支付支付宝作为备用渠道等到业务跑通后再做。微信支付接入第一步是开通商户号。这个过程审核比较严需要营业执照、法人身份证、对公账户、App应用信息。个人开发者的确可以开通小微商户但App场景有被限制的风险。我还是老老实实注册了公司、申请了微信支付商户号前后花了一周左右。这里有一个大坑很多个人开发者想绕过商户号用别人的支付接口或者走代付模式。我劝你千万别这么做。一旦被微信风控抓到轻则冻结资金重则被拉入黑名单甚至影响名下所有微信账号。合规是支付的第一原则。3.2 JSAPI支付必须传openid的解决办法微信支付在App/H5场景下最常用的接入方式是JSAPI支付。JSAPI支付有一道坎就是官方要求发起支付时必须传入openid。这个openid是用户在微信公众号/小程序下的唯一标识必须在公众号网页授权回调中获取。App里怎么拿openid呢正确姿势是让用户在App内打开微信授权登录页面引导用户同意授权后微信会回调你的服务器带上一个临时code服务端通过code去微信接口换取用户的access_token和openid拿到openid作为之后发起支付的必要参数。当时网上很多帖子写着App支付不需要openid这不是不对而是App支付指代的是另一个渠道微信的App支付通过微信SDK拉起微信客户端完成支付。但很多独立开发者做的其实是H5嵌套或者WebView里的JSAPI不走App支付是因为开通App支付需要单独申请移动应用并绑定应用签名签名的申请流程在微信开放平台个人开发者往往没有App上架资质或软著导致审核过不去。我的最终方案是客户端用微信开放平台的App支付SDK服务端在发起支付前调用微信的获取用户openid接口拿到入参。具体流程用户在App点击开通会员。服务端生成订单调用微信统一下单接口传入openid、商品描述、金额、回调地址。微信返回prepay_id服务端用该参数生成调起支付的签名信息并返回给客户端。客户端调用微信SDK弹出支付面板。用户输入密码或指纹确认。微信异步通知服务端支付结果服务端更新订单状态再通知客户端刷新会员状态。这一整套流程走下来就避开了App里没有openid的死结。3.3 支付宝沙箱测试与真实接入的区别支付宝这边我同时接入了沙箱环境和生产环境。沙箱环境是支付宝官方提供的模拟测试环境可以不用真实资金就验证整个购买流程包括下单、支付、回调、通知处理。支付宝沙箱的坑在于必须用专用的沙箱App或者网页版登录沙箱账号然后用沙箱的买家账号支付沙箱环境和生产环境的app_id、密钥、网关地址完全不同后端代码里必须做环境隔离否则很容易出现我在沙箱里测得好好的切到生产环境突然报错的情况。支付宝的好处是文档写得很详细SDK封装也比微信干净。接入RSA2签名的时候只需要在支付宝开放平台生成一对应用公钥和私钥然后把支付宝公钥存到服务端就够了。注意不是把私钥放服务端就完了一定要用支付宝提供的支付宝公钥做验签防止伪造回调。说到回调这是支付模块最核心也最容易被忽略的环节。微信和支付宝在支付成功后都会向服务端发送异步通知服务端必须做这几件事验签确认通知真的来自微信/支付宝而不是黑客伪造的。查单收到通知后主动调用微信/支付宝的查询接口确认订单状态防止伪造支付成功。幂等同一笔订单的通知可能重复送达多次服务端要做去重不能给用户重复开通会员。及时应答处理完业务后必须返回success给微信/支付宝否则他们会重试通知。我之前见过很多新手直接拿支付回调里的金额和订单号当准这是有大隐患的。攻击者完全可以自己构造一个支付回调发给你你的服务器如果没验签就会白给会员。验签一定要在业务逻辑之前做。3.4 支付合规与用户体验的平衡关于支付还有几个合规红线商品描述不能出现诱导、夸大、违规的词汇比如终身免费稳赚不赔这类绝对化用语必须在产品内提供退款入口和客服联系方式会员自动续费必须显著提示并在订阅前征得用户同意。iOS端的数字商品虚拟支付也必须走Apple的内购不能直接调微信支付宝这个需要在后续上架苹果商店时特别注意。在提升支付转化率方面我做了几个小设计把付费墙拆成多个节点用户聊到情绪高点时弹出会员解锁提醒开通会员时默认选中月卡下方用小字标注首月优惠XX元制造价格锚点支付失败时自动重试并引导用户切换支付渠道。实测下来这些细节让支付转化率提升了大概1.5倍。4. 官网搭建与品牌落地4.1 官网的作用和页面设计很多人觉得App不需要官网直接上应用商店就行。但我坚持做了官网原因有四个一是iOS和安卓下载链接需要一个统一入口尤其没有上架之前官网是用户唯一能接触到App的地方二是通用证件、用户协议、隐私政策、退款政策这些合规文件需要挂在官网上审核应用市场时会被要求提供三是SEO关键词入口比如搜索AI虚拟恋人AI陪伴App时官网能为产品带来额外的自然流量四是拟建一个品牌信任感用户看到一个精致的官网付费意愿和试用意愿会明显增加。官网页面的核心模块我是这样规划的首页产品Slogan 核心功能亮点AI恋人、智能记忆、多角色选择 截图轮播 下载按钮。角色介绍页每个虚拟恋人单独一个卡片包含头像、性格标签、试聊入口。会员价目页月卡、季卡、年卡的对比表。帮助中心常见问题、退款政策、联系客服。用户协议和隐私政策独立页面内容合规、措辞严谨。官网整体视觉我选了深紫色作为主色调因为紫色给人神秘、温柔、陪伴的联想跟虚拟恋人的气质比较匹配。字体用思源黑体整体风格简洁偏柔美没有走常见的科技风蓝色调。4.2 技术方案与部署选型官网的技术栈我选择了Vue3 Nuxt3。有人可能会问官网就几个静态页面为什么不用纯HTML或者Next.js因为我后续想给官网增加一个角色试聊的功能直接用官网同一个站点的API所以需要一个能服务端渲染、具备路由和SEO能力的全栈框架。Nuxt3的Vue生态让我写起来很快而且它天然支持SSR搜索引擎抓取起来效果好。部署方面官网放在了国内云服务器上同时做了备案。这里要提醒一下绑定了国内域名的网站必须是已备案的否则域名解析没法生效。备案流程大概需要两周左右期间不影响开发但要尽早启动。另外我还配了CDN把静态资源图片、CSS、JS缓存到边缘节点首页首次加载时间稳定在1秒以内。这个对转化率和搜索排名都有正向作用。5. 上线发布与运营冷启动5.1 应用商店上架的完整流程和坑App做完后要上架到应用商店这是整个项目里耗时最久、最磨人心态的环节。安卓应用市场比较多我首批选了华为、小米、OPPO、vivo和应用宝这五个主流渠道每个渠道都需要注册开发者账号、提交应用信息、提供软著证书。软著全称是计算机软件著作权登记证书个人开发者可以在版权保护中心申请电子材料准备齐全后大概1到2个月能拿到。如果项目急着上线可以考虑做加急但加急费用不低。我的建议是开发之前就先申请软著等App开发完软著差不多也下来了流程正好接上。安卓上架的审核坑主要在权限声明和隐私政策。很多应用市场审核员会仔细核对App申请了哪些权限、是否在隐私政策中说明了用途。比如读取手机状态权限、定位权限、读取通讯录权限这些在虚拟恋人App里根本用不到没必要申请。我当时特意把权限裁剪到最小集网络、推送、存储、相机用于头像上传。每申请一个权限都在隐私政策里写清楚用途审核顺利了很多。iOS上架苹果商店则是另一回事。除了开发者账号个人账号一年99美元还额外需要软著、App隐私政策网址、App审核说明。Apple对于AI生成内容和虚拟陪伴类产品审核尤为严格如果存在不当内容审核员有可能直接以带有攻击性、冒犯性或暗示性内容为理由拒绝。所以我在产品里做了两级内容安全机制后面单独讲。5.2 内容安全AI聊天产品必须跨过的门槛虚拟恋人App天然要面对内容合规的压力。用户嘴里有各种提问方式AI模型如果完全没有护栏很容易生成违背公序良俗的内容然后就是应用商店下架、支付渠道封禁、域名被封整套业务一夜清零。我做内容安全花了很大功夫整体分成三层第一层是输入侧过滤。用户发来的每条消息先过一遍敏感词库和文本分类模型命中高风险词直接拦截不给模型回复的机会中风险词打标后模型要用平和、引导式的话术回复。第二层是模型侧约束。在系统提示词里明确加入行为红线例如不能生成色情、暴力、违法犯罪相关内容不能提供医学、法律、投资等专业建议用户提到自伤或伤害他人相关话题时必须优先建议寻求家人朋友或专业机构帮助。第三层是输出侧审核。大模型生成的回复在发给用户之前再过一遍内容安全API。如果被判定为高风险自动替换为预设的兜底回复抱歉这个话题我不能继续聊下去我们说点别的吧。实测下这个兜底回复虽然简单但能避免绝大多数因合规问题引发的下架风险。5.3 冷启动第一批用户从哪来产品上线后最现实的问题是没有流量怎么获取第一批用户我当时的策略分三条线第一条是SEO自然流量。官网围绕AI虚拟恋人AI陪伴聊天免费AI男友/女友这些长尾词做了内容布局每个虚拟恋人角色都有一个独立介绍页。上架App之后很多用户搜这些关键词能找到官网再从官网下载App。这个渠道虽然起量慢但用户精准度高、获客成本几乎为零。第二条是社交平台内容种草。我截取了几段和虚拟恋人的经典聊天对话在文字平台发我在AI恋人那里治愈了孤独这类话题帖。重点不是炫技而是展示真实的情感互动比如虚拟恋人记住了用户提过的童年故事或者低落时发来一句刚好戳中情绪的安慰。很多用户看了会好奇去搜索产品名下载。第三条是种子用户社群。我在产品里内置了加入用户群的入口早期愿意掏钱开会员的用户基本上都是深度目标受众我拉了个微信群和QQ群在里面收集反馈、发版本更新公告、搞限时优惠活动。这些种子用户后来成了我产品的免费测试员和口碑传播者。6. 常见问题与排查技巧6.1 支付类问题排查实录支付是用户最敏感、最不能出问题的模块。我整理了我在开发和运营中遇到的几个典型问题以及对应的排查思路现象可能原因排查方法调起微信支付后闪退或白屏微信SDK没有正确注册或签名不一致检查Android应用签名和微信开放平台配置的签名是否完全一致支付成功但App没有开通会员回调地址没有公网访问或回调处理中出现异常查看服务端日志确认微信回调是否到达检查验签和幂等处理支付宝沙箱支付一直提示金额不匹配沙箱环境门槛和真实环境不同或金额单位弄错分和元的转换沙箱支付金额需精确匹配订单金额调试时打印日志核对单位JSAPI支付提示该商户号不支持此功能商户号功能权限未开通登录微信商户平台在产品中心确认JSAPI支付已开通最折腾的其实是第一个问题微信SDK闪退。当时调了整整一个晚上最后发现是应用签名的MD5包含大写字母而在微信开放平台填写时全部写成了小写。这个校验是精确匹配的差一个字母大小写都不行。6.2 大模型回复质量差怎么调优如果你也做了AI聊天类的App一定会遇到模型回复太官方像客服的情况。我的排查思路是这样检查系统提示词人设和语言风格是最高优先级提示词写得足够具体回复效果才会具体。比如光写你很温柔没什么用要写你会用比喻来描述心情你的句子一般不超过20个字。检查few-shot示例在系统提示词里放上5到8组用户和虚拟恋人的对话样例模型会明显模仿示例的说话节奏和语气。这个优化对用户体验的提升比调任何参数都明显。检查温度参数我试过temperature从0.7调到1.2到1.2时回复更有情感和想象力但偶尔会出现逻辑断路最终定格在0.9。增加上下文摘要对话超过20轮后系统提示词里塞不下所有历史消息要稳定输出记忆摘要确保虚拟恋人能记住关键信息。6.3 一版常见的事故及反思分享一个印象比较深的线上事故。某天晚上服务器接到大量用户反馈会员买不了一直提示支付失败。我登录后台看到微信支付回调大面积超时第一个直觉是服务器出口带宽不够手动重启了网关结果问题依旧。最后定位半天才发现凌晨大模型API服务升级导致我的服务端在等待大模型返回时占满了请求线程池支付回调的请求全被堵在后面排队了。这个事故的教训是支付回调链路必须和大模型API调用链路做物理隔离至少不能共用同一个线程池。从那以后我把支付服务独立成一个单独的服务部署在另一台最小规格的云服务器上就算聊天服务被大模型拖垮也绝不影响用户下单。另一个教训是设计支付回调接口时一定要保证它够快。支付处理里尽量不要做耗时操作比如发送通知、写日志这些都应该异步处理。微信和支付宝的支付通知有多次重试机制但每次重试间隔越来越长如果服务端每次都超时用户的支付状态就会一直对不上。7. 个人经验总结与后续计划这个项目做下来我最大的感受是一个人独立做一款App技术永远不是最大的瓶颈心态和节奏才是。迷茫焦虑期里每天写代码、调模型、改UI专注的时间反而给了我喘息的空间。事后再看项目本身可能不会成为什么爆款但它让我的技术栈补齐了支付、内容安全、SEO、应用市场上架这几块短板这比任何空想都要值。如果你也想做类似的AI陪伴产品我给三点建议第一先用最简版本跑通闭环不要一上来就做语音、视频、数字人。文字聊天做到用户愿意聊、聊完想再来就已经赢过了大多数同类产品。第二合规和支付这两件事越早规划越好。不要等技术做完才想起软著、备案、商户号这些硬性资质的申请周期普遍以周和月为单位卡在审核期真的很耽误事。第三一定要给自己的产品留后路。AI大模型API随时可能调整价格或策略所以我的模型调用层做了适配层后期换模型只需要改配置。支付也同理主渠道之外预留了备用渠道以防主渠道出问题导致业务停摆。最后再分享一个细节我在官网和App里都留了自己的邮箱认真对待用户发来的每一条反馈。有一个用户在某天凌晨给我写了一封很长的邮件说这个虚拟恋人陪她走过了最难熬的失恋阶段。看到那封邮件时我忽然觉得这个项目已经没有白做了。