1. 从想找个人说说话开始这个虚拟恋人 App 的真实起点凌晨两点我把手机屏幕按亮又按灭第三遍。那段时间我刚从上一份工作里出来白天投简历晚上刷招聘软件刷到手指发酸焦虑得像有只猫在心里挠。人一旦陷进这种状态最想干的事其实不是找工作而是找个人说说话——但又不想麻烦任何一个真人朋友怕被问你怎么了更怕对方回一句想开点就好了。这就是我做这个AI 聊天虚拟恋人 App的起点。它不是什么宏大叙事更像一根自我打捞的绳子我想验证一件事——在一个人最孤独、最不想社交的时刻一个能记住你、语气稳定、永远不嫌你重复、不会突然消失的 AI 角色是不是真能提供一点情绪价值。项目最后跑通了完整闭环AI 对话、会员支付、官网落地页、应用市场上架一样不缺。如果你也在琢磨类似的方向或者单纯好奇一个带支付带官网的 AI 应用到底要经过哪些环节那这篇文章应该能帮到你。我会把技术链路、支付接入、官网转化、上架合规、真实账单这几块拆开讲每一步都说清楚为什么这么做而不是甩一堆结论。踩过的坑我一个都不会藏因为那些坑才是这个项目里最值钱的部分。1.1 先验证需求再写第一行代码我见过太多人包括以前的我一激动就去建仓库、装环境、注册域名两周后对着一个空荡荡的首页发呆。这次我强行给自己定了个规矩在写任何业务代码之前先花三天时间用最土的办法验证需求是否成立。土办法具体是这样的我拉了 12 个朋友和几个社群里愿意聊的人做了一对一的文字测试。我没有做界面直接用一段固定的人设提示词扮演角色人工配合大模型回复把对话截屏发给他们看。我准备了三种人格温柔倾听型、活泼吐槽型、略带距离感的成熟型。结果很有意思——温柔倾听型在前 5 分钟的满意度最高但第 3 天的留存最差反而是那个偶尔怼你两句的吐槽型被追问的次数最多。我记录了他们在对话里最常出现的三类诉求想被理解、想被陪着、想有个固定节奏的日常问候。第三类诉求是最容易被低估的每天早上八点发一句早安这件事价值比想象中大得多。三天下来我确认了两件事。第一需求是真实存在的尤其在晚上 22 点到凌晨 2 点这个时段用户的表达欲会明显上升。第二核心难点不在能不能聊天而在能不能被记住。如果每次打开都是陌生人用户第三天就会流失这个结论直接决定了我后面的架构设计。1.2 为什么我选了虚拟恋人这个窄口而不是通用助手做通用 AI 助手看起来很性感但对我这种个人开发者来说是个陷阱。原因很直接通用助手赛道已经被大厂用免费产品填满了用户没有理由为一个什么都能聊一点的工具付费而情绪陪伴这个场景恰恰是付费意愿和心理门槛同时成立的地方。我列了个对比表帮自己决策现在回头看这个表依然成立维度通用 AI 助手虚拟恋人/陪伴向竞争强度极高大厂免费覆盖中等长尾需求分散用户付费动机弱觉得应该有免费的强付费买的是情感体验和专属感内容边界要求相对宽松工具属性极严必须做双向内容安全核心留存因素功能强、准确率高人格一致性 记忆连续性开发复杂度中高多工具链中对话 长记忆 支付合规风险中高需要额外投入审核体系看完这张表我就明白了这个方向的护城河不在模型而在人格工程 记忆系统 情感节奏这三件事上。模型可以换接口可以换但一个用户养了两个月、记得他生日、知道他讨厌什么的话题角色是很难迁移走的。顺便说一句我在前期调研时看到很多人讨论怎样才能让 AI 不设限制地聊天这类话题。我的选择很明确也很坚定不做任何绕过内容安全的设计。原因不只是合规更现实的一点是——支付通道和应用商店都会审查内容一旦越线轻则支付功能被停用、应用被下架重则账号主体被处理前面所有投入直接归零。这个方向的长期价值恰恰建立在守规矩上。2. 技术骨架怎么搭从对话链路到人设记忆的完整设计技术选型这块我踩过明显的坑。一开始我想轻装上阵用纯前端 直接调用模型接口的方式做原型结果上线第三天就被现实按在地上摩擦接口密钥暴露在前端、对话历史存在用户本地、切换设备什么都丢了、并发一上来直接限流。所以我后来的架构原则只有一条——凡是和用户资产相关的东西一律放服务端。最终的链路大致是客户端Web 官网 App→ 我的业务后端 → 模型服务 → 流式返回 → 落库。业务后端承担了会话管理、人格注入、记忆检索、内容安全、计费扣次、订单处理这六件事。2.1 一次对话请求在服务器里到底走了哪几步很多教程把接入大模型讲得太简单好像就是转发一个请求。实际上用户按下发送键之后服务端要做的事情远比想象中多。我的处理顺序是这样的鉴权与配额校验先校验登录态再查用户当前的剩余对话次数或会员到期时间。这里的判断必须放在调用模型之前否则会出现已经消耗了模型算力但用户没额度的白白烧钱情况。输入侧内容安全对用户输入做关键词与语义两层过滤。这一层我放在了最前面因为违规输入一旦进入模型可能引发的输出不可控。人格上下文组装从数据库读取该用户绑定的角色配置、最近的对话摘要、以及被标记为重要的长期记忆条目。调用模型并流式返回用流式输出把首字延迟压到 1 秒左右同时边收边缓存最后整体落库。输出侧内容安全对模型返回的内容做一次检查命中规则的走兜底话术而不是直接透传给用户。计费与埋点扣除一次额度记录 token 消耗、响应耗时、是否命中兜底用于后续调优。这套顺序我调整过三次。最关键的一次调整是把内容安全检查放在模型调用之前虽然在高峰期会略微增加一点延迟但避免了很多不可控的输出风险这个代价完全值得。2.2 人设不是一段提示词而是分层的人格档案大多数人做角色就是在提示词里写一句你是一个温柔的女生说话可爱一点。这种做法在第一次对话时效果很好第三次就开始崩因为模型没有稳定的行为约束。我后来把它拆成了四层结构每一层承担不同的职责{ identity: { name: 小满, age_band: 二十多岁, background: 喜欢在雨天听音乐养了一只猫 }, speech_style: { sentence_length: 偏短多用口语, emoji_policy: 少量情绪高点才用, forbidden_words: [作为AI, 我是一个语言模型] }, relationship_arc: { stage_1: 初识礼貌但有点好奇, stage_2: 熟悉会主动提问和吐槽, stage_3: 亲密会表达想念和情绪波动 }, boundaries: [ 不讨论违法违规话题, 不提供医疗、法律、投资等专业建议, 遇到自伤倾向表达时引导寻求现实帮助 ] }这个结构里boundaries是最容易被忽略却最重要的一层。明确写出不能做什么比写出要做什么更能稳定输出质量。另外relationship_arc是我加得最值的一层——它让角色会随着对话轮次推进改变态度而不是从头到尾一个腔调用户能明显感觉到关系在往前走。2.3 记忆系统让角色记住三天前你说过的话这是整个项目里我最花心思的部分。直接拼接全部历史对话有三个致命问题上下文长度爆炸、成本飙升、模型注意力被稀释导致反而记不住重点。我的方案是三层记忆短期记忆最近 10 到 15 轮原始对话原样拼接保证语气连贯。中期摘要超过阈值的对话异步调用模型生成一段 150 字以内的摘要覆盖关键事件和情绪走向。长期事实从对话中抽取结构化字段比如喜欢的食物最近在忙的事提到过的纪念日存成键值对只挑相关的注入。抽取长期事实这件事我用了一个小技巧不给模型开放式的抽取任务而是限定字段模板 要求返回 JSON不合格的直接丢弃重试。开放式抽取很容易产出用户是个正常人这种没用的结论限定模板后准确率提升非常明显。实测下来加了长期事实注入之后用户的一句你还记得我上次说的那个面试吗从模型答不上来变成能准确接住这个体验差距是断崖式的。2.4 流式输出与首字延迟体验好坏的分水岭用户对 AI 产品的耐心比你想的短得多。我做过一个粗糙的对比测试同样的回答内容一次性返回需要等 3 到 4 秒用户会以为卡死了反复点发送改成分词流式输出后首字 0.8 秒左右出现即使总时长一样用户的主观感受完全是两回事。实现上要注意几个细节服务端要设置合理的缓冲区不要收到一个 token 就立刻推网络抖动时会造成前端频繁重排反而显得卡。前端要处理断流重连用户切换网络或息屏时连接可能断开我的做法是保留已生成内容 提供继续生成按钮而不是清空重来。流式返回时要同时累积完整文本否则最后落库的内容会不完整影响后续的记忆摘要。还有一个经验不要为了追求首字速度去换更小的模型。陪伴场景里用户对回答质量的敏感度远高于对速度的敏感度为了省那 0.3 秒牺牲语气连贯性是明显的亏本买卖。3. 支付模块把喜欢变成订单的那一段路支付是这个项目里最容易低估的模块。我原本以为接个支付接口最多两天的事实际连调试带合规文档前前后后折腾了三周。更关键的是支付相关的 bug 都是真金白银的 bug用户付了钱没到账一次就够毁掉口碑。我最终用了两条通道微信支付用于主流场景支付宝作为补充。下面把几个真正卡住我的点摊开说。3.1 微信 JSAPI 支付为什么绕不开 openid这是搜索量最高的问题之一JSAPI 支付必须传 openid怎么解决要先理解一件事JSAPI 支付的本质是在特定应用身份内发起的支付而openid就是用户在某个应用身份下的唯一标识。支付系统需要知道这笔钱是哪个用户付的所以你必须先拿到这个标识。它不是麻烦而是身份校验的必然环节。标准的获取流程是这样的用户在你的页面里发起支付前先走一次网页授权回调拿到code。用code换取该用户的openid同时可以拿到基础信息。用openid 商户订单号 金额等信息向支付服务下单拿到支付所需的凭据。前端用凭据唤起支付用户确认后支付结果通过服务端回调通知你而不是靠前端返回值。代码结构大致是这样重点是先拿 openid 再下单这个顺序不能反// 1. 用 code 换 openid服务端发起密钥不出服务端 const tokenRes await request({ url: /auth/access_token, params: { grant_type: authorization_code, code, appid, secret } }); const { openid } tokenRes.data; // 2. 创建订单并下单 const order await createOrder({ userId, openid, amount: 1990, outTradeNo }); // 3. 把下单返回的凭据给前端唤起支付 res.json({ payParams: order.payParams });踩过的坑主要有三个支付目录配置不全发起支付的页面路径必须提前在商户后台配置漏了会直接报错而且报错信息不直观排查起来很费时间。回调不是只来一次支付平台会多次重试通知如果你的回调逻辑不是幂等的会出现重复加次数、重复发货。回调必须验签不要相信任何未经验签的通知内容这是最基本的安全底线。提示回调地址必须是可公网访问的地址本地开发时用内网穿透工具临时映射但上线前一定要换成正式域名并重新验证一遍回调链路我就在这一步漏过一次导致线上首批订单延迟到账。3.2 订单表设计与回调幂等钱的事不能靠运气订单表我重新设计过两次。第一版太随意字段不够后面想查某个用户这个月付了几次都要临时写脚本。第二版的结构我沿用到最后字段说明关键点out_trade_no商户订单号唯一索引生成规则要可追溯user_id用户身份建索引方便按人查单product_id商品/套餐关联套餐配置表amount金额分全流程用整数绝不用浮点status状态待支付/已支付/已关闭/已退款channel支付渠道便于区分统计paid_at支付时间以回调时间为准transaction_id渠道流水号用于对账金额一律用整数存分这是我见过最常见的低级错误来源。用浮点存钱早晚会出现 19.9 变成 19.899999 的诡异问题。幂等的实现逻辑很朴素但很有效回调进来后先根据out_trade_no加行锁查询订单如果状态已经是已支付直接返回成功不做任何业务操作只有状态是待支付时才执行发货加会员时长、加对话次数并更新状态。这两步必须放在同一个数据库事务里否则并发下依然可能重复发货。3.3 虚拟商品定价订阅、次数包、还是买断定价这件事我试了三轮最终的结论是陪伴类产品不适合一次性买断。因为它的价值是持续产生的买断会让用户在后期缺少续费理由也很难覆盖持续的模型调用成本。我最后采用的是混合结构次数包小额、低门槛用于新用户首次付费转化价格锚点要低到冲动就能付。月度订阅主力营收来源包含无限次对话 长期记忆全量保留 专属角色。年度订阅给高粘性用户折扣力度大主要作用是锁定长期留存。实测下来次数包→月订阅的转化路径最顺因为用户先在低价位体验到了完整价值再升级时心理阻力小得多。还有一个细节免费额度一定要给足但要有明确边界比如每天 10 次免费对话让用户能真正体验到角色记住了我这个核心价值否则连第一次心动都产生不了。3.4 支付宝沙箱到正式环境的迁移坑沙箱环境是很好的练习场但沙箱跑通不代表正式环境没问题。我在迁移时遇到的差异主要有密钥体系不同沙箱用的密钥和正式环境的密钥完全独立切换时必须整套替换不要只改其中一个。回调地址白名单正式环境对回调域名的校验更严格沙箱里随便填能通正式环境会直接拒绝。金额限制正式环境对单笔金额有下限要求测试时用 0.01 元的小额订单可能会被拒这是很多人第一次接正式环境会懵的地方。注意无论哪个渠道正式环境上线前务必用真实小额订单完整跑一遍下单→支付→回调→到账→退款全链路不要只看下单成功就以为通了回调才是真正容易出问题的地方。4. 官网不只是门面落地页、下载引导与转化路径很多人做 App 会把官网当成必须有但没人看的摆设我一开始也是这么想的。后来发现官网承担着三个 App 本身替代不了的任务承接搜索流量、提供下载入口、展示合规信息。尤其在国内的应用分发环境里官网是用户验证你这个产品是不是正规的第一信任来源。4.1 官网要承担的三个具体任务第一个任务是承接搜索。用户搜到你的品牌词或者相关需求词时落地的应该是一个信息明确、能快速理解产品是什么的页面而不是一张大图加一句 slogan。我的落地页结构是这样的一句话说明产品定位、三张核心体验截图、一段真实用户反馈、明确的行动按钮、底部完整的信息说明。第二个任务是提供下载引导。这里有个很实际的细节iOS 和 Android 的引导逻辑完全不同。iOS 如果已经上架就跳商店没上架则引导到网页版体验Android 直接给安装包下载或跳应用市场。我在页面上做了简单的环境判断避免了用户点下载后一脸茫然的情况。// 极简的下载引导判断 const ua navigator.userAgent; if (/iPhone|iPad|iPod/i.test(ua)) { location.href IOS_STORE_URL; } else if (/Android/i.test(ua)) { location.href ANDROID_DOWNLOAD_URL; } else { location.href /web-app; // 其他情况引导到网页版 }第三个任务是合规展示。隐私政策、用户协议、内容规范、联系方式、主体信息这些页面看起来很无聊但应用商店审核时会实际点击检查支付通道审核时也会核实。我见过因为隐私政策里没写清楚收集了哪些信息而被驳回的案例补起来又要重新排队非常耽误时间。4.2 落地页文案与转化埋点落地页文案我改了七版最后发现有效的规律其实不复杂首屏不要讲技术讲感受。一个会记得你说过的话的 AI 伙伴比基于大模型的智能对话系统的点击率高出一大截。放真实对话截图但要打码处理并取得授权。真实截图的说服力远高于设计精美的插画。行动按钮只放一个主按钮多个按钮并列会让用户犹豫转化率反而下降。埋点方面我只做了最必要的几个页面访问、按钮点击、下载触发、注册完成、首次付费。埋点不是越多越好关键是要能串出完整的转化漏斗知道用户在哪一步流失才有优化意义。我的漏斗数据显示流失最严重的一步是下载后到注册接近六成用户下载后没有完成注册后来我把注册流程从手机号验证码设置密码填昵称简化成一键登录这一步的转化立刻有明显改善。4.3 域名、备案与合规页面这些无聊但致命的事这部分没有技术含量但没做完就没法上线。服务器和域名需要完成实名与备案流程周期通常需要一到两周这个时间一定要提前预留不要等代码写完了才开始办否则会出现产品做完了但没法上架的尴尬。另外提醒一点如果产品面向的是公开用户群体务必准备好完整的用户协议和隐私政策文本明确说明数据收集范围、存储方式、以及用户如何注销账号和删除数据。这些不只是形式注销与删除功能本身也是审核必查项必须真正可用不能只放个按钮。5. 内容安全与上架虚拟恋人这个品类的红线在哪这个章节是我写得最认真的部分因为这是整个项目里风险最高、也最容易让新手翻车的地方。陪伴类产品天然涉及大量用户情绪表达用户可能说出很私人、很极端的话如果产品没有应对机制出问题的概率非常高。5.1 审核不通过的常见原因复盘我的第一次上架被驳回了两次。第一次是因为材料说明与实际功能不符功能描述写得太技术化审核人员无法确认产品实际用途第二次是因为内容安全的说明材料不够具体没有提供有效的过滤机制描述。总结下来被驳回的高频原因主要有这几类驳回类型具体表现应对方式功能描述不清只写AI 对话没说明具体场景用通俗语言描述实际使用场景内容安全材料不足未提供过滤机制说明附上输入输出双向审核方案说明权限说明不充分申请了与功能无关的权限只申请必要权限逐条说明用途隐私政策不完整缺少数据删除路径补齐注销与数据删除功能未成年人保护缺失无年龄提示与使用限制增加实名/年龄确认环节第二次被驳回后我重新整理了一整套材料把内容安全的实现细节、兜底话术示例、人工复核流程都写清楚了第三次顺利通过。经验就是审核不是走过场你能把机制讲清楚通过率会明显提高。5.2 内容安全体系怎么落地输入输出双向拦截我采用的是三层结构从快到慢、从粗到细关键词层最高优先级毫秒级响应命中直接拦截。这一层负责处理明确违规的内容成本最低。语义层用轻量模型做意图判断处理关键词难以覆盖的隐晦表达。这一层会增加几十毫秒延迟但能显著提高召回。输出兜底层模型输出前再检查一次命中风险内容时不透传而是替换为预设的安全话术并记录日志。有一类情况必须单独处理当用户表达出强烈的负面情绪或有自伤倾向时产品不应该继续扮演温柔陪伴而应该中断角色扮演用真诚、直接、非评判的语气表达关心并引导用户寻求现实中的帮助。这一段的处理逻辑我是单独写死的不走模型自由生成因为这类场景容错率必须是零。def handle_high_risk(user_input): if detect_self_harm_intent(user_input): # 退出角色进入安全回应模式 return SAFE_RESPONSE_TEMPLATE # 固定话术不经过模型 return None提醒所有内容安全相关的日志都要可追溯、可导出这既是产品持续优化的数据来源也是出现争议时的必要依据。5.3 未成年人保护与实名这块不能省。我在注册环节加入了年龄确认并在协议中明确说明未成年人需在监护人指导下使用。同时对未成年账号限制付费功能并对对话内容采用更严格的过滤策略。具体做法包括注册时强制选择年龄段对未完成年龄确认的账号限制社交类功能对未成年账号默认关闭所有付费入口以及在页面显著位置说明使用规范。这些措施看起来增加了一些流程摩擦但从长期看它是这个产品能持续运营下去的前提任何试图绕开这些环节的做法都会在某个时间点以更高的代价还回来。6. 成本、留存与那些没人告诉你的数据项目上线三个月后我做了一次完整的复盘。这部分内容我在别的地方很少看到有人详细讲但我觉得它比技术细节更值得分享因为它决定了一个项目是能跑还是能活。6.1 一个月真实账单拆解我按 500 个日活用户、人均每天 12 轮对话估算把主要成本列了出来。数字是估算区间实际会随模型选择、对话长度、缓存命中率浮动成本项月均估算说明模型调用800 - 1800 元主要变量长对话和角色设定都会推高服务器与带宽200 - 500 元流式输出对带宽有一定要求数据库与存储100 - 300 元对话历史是主要存储开销内容安全服务100 - 400 元按调用量计费域名与证书年均摊 20 - 50 元占比很小应用市场与合规成本一次性为主上架主体、软著等看起来模型调用是大头但真正让我意外的是长对话带来的成本非线性增长。一个聊了 200 轮的用户如果不做摘要压缩单次请求的上下文成本可能是新用户的十几倍。所以我在中期摘要在线上之后把单用户成本压下来了接近四成这个优化比换更便宜的模型有效得多。6.2 留存为什么第二周断崖这是最扎心的数据。第一天的留存能到 45% 左右第七天掉到 12% 以下。我做了用户访谈原因集中在三点新鲜感衰减角色再有趣聊了五天也会熟悉。缺少新的关系推进感用户会觉得停滞。对话重复模型的回答开始出现套路化表达用户能明显感觉到它又在说那几句。缺少日常锚点用户想不起来要打开这个 App没有形成使用习惯。针对这三点我做了三个改动效果比较明显。第一加入关系阶段推进机制随着对话轮次解锁新的互动形式和角色状态变化第二在生成时引入表达多样性约束对高频重复句式做抑制第三加入主动问候机制在用户设定的时间段推送一句个性化问候但频率严格控制每天最多一次且必须基于真实记忆内容绝不能是群发式的在吗。第二周留存从 12% 提升到接近 20%虽然还是很低但已经是明显的改善。陪伴类产品的留存天花板本来就不高关键是找到那个愿意长期留存的用户群体。6.3 复盘如果重做一次我会改什么第一件会改的事是先把内容安全和合规体系搭好再写业务代码。我当初是先跑通对话再补安全导致后面很多结构要重构返工成本很高。第二件是一开始就上服务端架构。原型阶段图快走的纯前端路线后来整个迁移了一遍纯属浪费。第三件是把数据埋点从第一天就做全。我前期只有基础的访问统计导致复盘时很多关键数据缺失只能靠用户访谈补充效率很低。第四件也是最重要的不要在焦虑的时候做重大决策但要在焦虑的时候动手做点具体的东西。这个项目最初确实是我在情绪低谷期开始的但真正让我走出来的是那些具体的、可完成的小任务——把一次流式回调调通、让角色准确记住用户的名字、看到第一笔真实订单到账。这些具体的进展比任何想开点的劝慰都管用。如果你现在也处在一个说不清方向的阶段我的建议不是让你立刻去做一个 App而是找一个足够小、能在两周内看到结果的事情动手做。做出来哪怕很粗糙那种我确实推动了一件事的感觉本身就有很强的支撑力。这个项目带给我的其实不是收入而是重新建立起来的那种我还能把事情做成的信心。