去年冬天有一段时间我状态很差白天上班心不在焉晚上又睡不着翻来覆去地想一些没答案的问题。为了给自己找点事情做我干脆把憋了很久的想法落了地——做一个 AI 聊天虚拟恋人 App从聊天内核、支付体系、官网落地页到上架流程全部自己趟一遍。这篇文章不讲虚的就把我这个项目从零到能收款的完整过程摊开来讲包括模块怎么拆、AI 聊天怎么调、微信支付 JSAPI 接入时那个烦人的 openid 到底从哪儿来、官网怎么布关键词、上架要花多少钱、以及我踩过的那些坑。不管你是想做个副业小产品还是单纯想练手全栈能力这篇都能当个参考。1. 从迷茫到落地这个项目整体怎么盘1.1 为什么我选AI 聊天虚拟恋人这个方向先说选题。很多人做副业第一反应是工具类 App比如记账、待办、番茄钟逻辑是需求明确、变现清晰。但我实测下来工具类有个致命问题留存差。用户用完就走你花大力气做出来日活全靠推送硬撑。而情感陪伴这类产品不一样它的核心是聊天这件事本身用户跟你聊得越久迁移成本越高付费意愿也越强订阅会员可进入优先队列这种设计天然就成立。从技术角度看这个方向对独立开发者特别友好。你不需要养一支算法团队大模型 API 已经把最难的对话能力封装好了你要做的是产品化——把人设做成可配置的、把聊天体验做流畅、把支付和官网这些基础设施搭稳。这正好是一个全栈练手的绝佳场景前端、后端、实时通信、支付、SEO 全都能覆盖到。但有一点我必须提前说清楚做情感陪伴类产品内容安全和用户心理边界是底线。我在设计之初就给自己定了几条死规矩——不碰任何擦边内容、不做诱导性付费、未成年人保护必须做、涉及情绪困扰的场景要引导用户寻求专业帮助。这不是为了应付审核而是这类产品一旦走偏口碑崩起来比涨起来快十倍。我见过太多同类产品因为内容失控被下架前面的投入全打水漂。1.2 一张表格说清整个技术盘子我把项目拆成了五块每块都是独立可替换的模块。这样设计的好处是任何一个环节出问题我都能单独替换而不影响全局。比如 AI 层一开始用的是 A 家 API后来发现响应速度不稳定我直接换成了 B 家业务代码几乎没动。模块我选的技术方案备选方案选择理由客户端FlutterReact Native / 原生一套代码出双端独立开发者没精力维护两套后端 APIPython FastAPINode.js Express / Go异步性能好和大模型 SDK 生态贴合实时通信WebSocket长轮询 / SSE聊天必须双向SSE 只能服务端推AI 对话大模型 API 自建人设层自训练小模型成本可控迭代快不需要 GPU 集群支付微信支付 JSAPI 支付宝聚合支付用户覆盖最广费率透明官网静态站 CDN动态 CMS加载快、SEO 友好、几乎零运维数据库PostgreSQL RedisMySQLJSON 字段好用人设配置Redis 扛会话这里我要解释一下为什么后端选 FastAPI 而不是更主流的 Node.js。核心原因是流式输出。AI 聊天最影响体验的就是打字机效果——用户问一句AI 一个字一个字往外蹦而不是等整段生成完再一次性返回。FastAPI 配合异步生成器写流式接口特别顺代码量比 Node.js 少一半。当然 Node.js 也能做只是我个人的技术栈更偏 Python。还有一个容易被忽略的点客户端别一上来就做原生双端。我一开始想用 Android 原生 iOS 原生光是把聊天界面写两遍就够我受的。后来换成 Flutter一套 Dart 代码出双端省下的时间够我把支付和官网都做完了。独立开发者最重要的资源不是技术是时间。2. AI 聊天内核让人设真正活起来2.1 人设卡设计把性格写成可维护的配置新手做 AI 聊天最容易犯的错是把一大段人设描述硬编码在代码里比如system_prompt 你是一个温柔的女生……。这样做短期没问题但你一旦想加第二个角色、想调整性格、想做 A/B 测试代码就乱了。我的做法是把人设抽象成一份 JSON 配置存数据库随时可以改改完热更新不用重新发版。一份合格的人设卡应该包含这几个维度基础设定名字、年龄、身份、性格特征温柔/毒舌/高冷但要有具体行为描述而不是空泛形容词、说话风格句长、口头禅、是否用语气词、边界规则什么话题要回避、什么情况要引导专业帮助、开场白用户第一次进来看到的第一句话。我实测下来性格描述越具体AI 演得越像。你写她很温柔模型给你一个端水大师你写她说话慢喜欢用省略号被夸的时候会转移话题生气了不会直接说而是回一个字哦出来的感觉完全不一样。{ id: char_001, name: 小雨, persona: 23岁插画师性格慢热熟悉之后话很多, speaking_style: 句子偏短偶尔会用省略号开心时有轻微颜文字倾向, boundaries: [不讨论现实中的具体学校单位, 涉及严重情绪困扰时建议寻求专业帮助], opening: 今天……你是不是也有很多事想说 }注意人设卡里的边界规则不是摆设。我见过有人为了追求聊天效果把人设写得毫无约束结果模型开始自说自话编造身份经历用户信以为真这种信任一旦被滥用就是事故。边界规则要写进 system prompt并且在服务端做二次校验不能全指望模型自觉。另外人设卡还要考虑记忆的挂载点。真正让用户觉得她记得我的不是开场白多甜而是三天后她还能提起你上次说的那件事。这就涉及到下一节的上下文管理。2.2 上下文与记忆三明治结构管住 token 成本大模型的上下文窗口是有限的而且token 是花钱的。你要是一次对话把几百轮历史全塞进去成本会炸。我的方案是三明治结构底层长期摘要。每个用户的会话每隔 N 轮我用模型把这段对话压缩成一段 100 字左右的摘要存数据库。下次开新会话时只把摘要塞进去不带完整历史。中层关键事实。我额外维护一张用户事实表记录用户明确说过的偏好、重要日期、称呼习惯。这些是结构化数据几十个 token 就能表达很多信息。顶层近期滑窗。最近 10 到 15 轮对话原文保证当前语境连贯。这套组合拳跑下来一次请求的 token 量能控制在 2000 以内比无脑塞历史省了八成成本。而且体验上反而更好因为模型不会被几十轮前的无关信息干扰。这里有个实操细节很多人会踩摘要不能异步做完了就完了要考虑失败重试。我一开始用消息队列异步生成摘要结果某次队列堵了用户再进来发现她完全不记得我了体验直接崩。后来我改成同步兜底 异步优化如果摘要还没生成好就先拿最近 30 轮原文顶上保证不断片摘要生成好再更新。2.3 WebSocket 实时链路别用轮询折磨用户聊天功能最忌讳的就是轮询。用户发一条消息每隔一秒请求一次接口问AI 回复好了没服务器压力大用户体验还卡。正确做法是上 WebSocket一条长连接双向通信。客户端连接时带上 token服务端校验后建立会话。消息协议我用的是最简的 JSON// 客户端发送 { type: message, content: 今天好累啊, sessionId: xxx } // 服务端流式返回多条 { type: delta, content: 辛苦 } { type: delta, content: 了 } { type: done, messageId: yyy }服务端拿到消息后向大模型发起流式请求每收到一个 token 就往 WebSocket 里推一个delta全部结束后推一个done。用户看到的是一行行冒出来的字体验就像真人打字。实操心得WebSocket 一定要做心跳保活和断线重连。移动网络切换、App 切后台再回来连接大概率已经断了。我客户端设了 30 秒一次 ping服务端 60 秒没收到就主动断连客户端检测到断开后指数退避重连重连时用最后一条消息的 ID 做增量拉取避免消息丢失。还有一个容易被忽略的技术点付费用户的优先队列。高峰期如果所有请求一起排队付费用户和免费用户一起等体验会很难看。我在请求入口加了一层优先级队列订阅会员的请求权重更高在模型并发受限时优先出结果。实现上是 Redis 的 Sorted Setscore 用优先级加时间戳保证高优先级先出、同级 FIFO不会把免费用户饿死。3. 支付体系搭建从 0 到能收到钱3.1 订单模型与状态机先把数据结构想清楚做支付模块我最大的教训就是先设计订单表再写业务代码。很多人一上来就调支付接口结果订单状态乱成一锅粥用户付了钱没开通会员、重复扣款对不上账。我现在的订单表至少包含这些字段字段类型说明order_novarchar商户订单号全局唯一用于幂等user_idbigint下单用户product_idvarchar订阅套餐标识amountint金额单位分绝不用浮点statustinyint0 待支付/1 已支付/2 已关闭/3 已退款channelvarcharwechat / alipaytransaction_idvarchar第三方支付单号created_at / paid_atdatetime时间戳金额用整数分存储这个不用多解释浮点数算钱迟早出问题。状态机是关键待支付 --支付成功-- 已支付 --退款-- 已退款 | | --超时/主动取消-- 已关闭状态流转只能单向且每次变更都要记日志。我专门建了一张order_log表谁在什么时候把订单从什么状态改成了什么状态全记下来。出问题的时候这张表比任何排查都管用。注意幂等是支付的生命线。同一笔支付回调可能因为网络重试被推好几次你的业务逻辑必须保证处理一次和处理十次结果完全一样。我的做法是用order_no做唯一约束更新状态时带where status 0条件只有真正从待支付改成已支付的那一次 SQL 才影响行数其余全部忽略。3.2 微信支付 JSAPIopenid 到底从哪儿来这是我在接入过程中卡了最久的地方也是热词里被搜爆的问题——JSAPI 支付必须传 openid可 openid 怎么拿先讲清楚原理openid 是微信用户在某个特定 appid 下的唯一标识它不属于用户本身而是用户 这个 appid的组合产物。所以你不能凭空造一个必须通过微信的授权流程换取。不同场景拿 openid 的方式完全不同我把三种常见场景列出来场景获取方式关键点公众号 H5网页授权snsapi_base用户无感知跳转带 code 换 openid小程序内wx.login 拿 code后端用 code2session 换 openid原生 App不用 JSAPI走 App 支付App 支付不需要 openid如果你做的是公众号网页里的支付流程是用户点支付 → 跳转微信授权页 → 微信回调你的地址并带上 code → 后端拿 code 调snsapi_base接口换 openid 和 access_token → 拿到 openid 后再调下单接口。整个链路里最容易错的是授权域名没配和code 只能用一次。code 换过一次就失效了如果你前端刷新了页面导致重复提交第二次必报错。我的处理是在后端缓存 code 到 openid 的映射短时间内重复请求直接命中缓存。下单核心代码大致是这样// 后端JSAPI 下单 const body { appid: APP_ID, mchid: MCH_ID, description: 月度会员订阅, out_trade_no: orderNo, notify_url: https://www.yoursite.com/api/pay/wx/notify, amount: { total: 1900, currency: CNY }, payer: { openid: userOpenid } // 这里必须是对应 appid 下的 openid }; // 用商户私钥对请求签名再带上 Authorization 头请求微信接口 // 返回 prepay_id用官方 SDK 二次签名后返回给前端调起支付前端拿到签名参数后调WeixinJSBridge.invoke(getBrandWCPayRequest, ...)就能拉起支付面板。这里要注意App 里的支付不要硬套 JSAPI如果用户是在原生 App 内应该用 App 支付走的是完全不同的接口openid 这个问题根本不存在。3.3 回调验签、对账与退款钱到账之后的事支付成功只是开始。微信会异步回调你的notify_url你必须做三件事验签、解密、幂等处理。验签是防止伪造回调的第一道门。微信现在的回调用的是平台证书你需要用对应的公钥验证签名签名不对直接拒绝。解密是因为回调报文里的金额等信息是加密的要用 API v3 密钥解。最后才是处理业务逻辑。我见过有人为了图省事跳过验签结果被人伪造回调白嫖会员血的教训。对账是第二道保险。每天定时任务拉取微信的账单文件和你自己的订单表逐笔核对金额和状态不一致的记入异常表人工排查。这个活儿很枯燥但一定要自动化人工对账迟早会漏。退款则要特别注意部分退款和全额退款的区别以及退款回调的处理。退款的钱是原路返回的用户到账时间取决于银行别跟用户承诺立即到账这句话能省掉你一半的客服工单。4. 官网与转化让流量真正找到你4.1 官网信息架构与 SEO 关键词布局很多人做 App 只做应用商店完全忽略官网。但官网有两个无法替代的作用承载搜索引擎流量和建立信任感。用户搜AI 聊天虚拟恋人 App想找同类产品时一个好的官网就是你最大的自然流量入口。我的官网结构很简洁就四个板块首屏价值主张、核心功能展示、用户评价、下载引导。关键在于关键词的自然布局。我在标题、H1、段落首句、图片 alt 里都放了AI 聊天虚拟恋人AI 陪伴 App这类词但绝不堆砌每处都融进正常句子。搜索引擎现在很聪明堆关键词反而降权。技术层面官网我做成静态站配合 CDN 加速首屏加载压在 1 秒内。为什么要这么快因为移动端用户耐心极短多等一秒跳出率就往上蹿。静态站还有个好处是不怕流量突增CDN 直接兜住。提示官网务必配好robots.txt和sitemap.xml把希望被收录的页面列全。同时页面要适配移动端现在搜索引擎基本都是移动优先索引PC 版做再好移动端体验差一样掉排名。4.2 转化漏斗从搜索到付费那条路官网不是用来展示的是用来转化的。我在页面上放了三个转化点首屏的免费体验按钮、中部的查看会员权益、底部的立即下载。每个点都指向不同的用户意图层次浅层用户点体验深层用户点下载。数据埋点一定要做。我给每个按钮加了来源参数追踪用户从哪个渠道进来、点了哪个按钮、最终有没有完成注册和付费。这套漏斗数据后来帮我砍掉了一个几乎没转化的渠道省了不少推广费。还有个小细节官网和 App 里的文案要保持一致。我一开始官网写24 小时秒回App 里因为排队机制偶尔会延迟几秒用户就投诉虚假宣传。后来统一改成随时都在体验预期就顺了。5. 上线前后的踩坑与排查实录5.1 支付类问题速查表支付这块的问题最磨人因为涉及多方你的服务器、微信服务器、用户手机。我把踩过的坑整理成表遇到问题直接对号入座。现象最可能的原因解决方向JSAPI 下单报openid 非法appid 和 openid 不匹配检查换 openid 用的 appid 是否等于支付 appid前端拉不起支付面板签名参数错误或时间戳过期重新二次签名检查 prepay_id 是否最新支付成功但没开通会员回调没收到或没验签通过查日志确认 notify_url 公网可达、验签通过同一订单多次发货没做幂等用 order_no 唯一约束 状态条件更新用户付了两次按钮没防重复点击前端置灰 后端同订单号拦截这里额外说一句调试阶段用沙箱环境。微信有专门的沙箱可以在不花真钱的情况下跑通全流程。等沙箱跑稳了再切生产能省掉很多真金白银的试错成本。5.2 聊天链路问题排查聊天最大的问题集中在消息丢了回复慢重复回复这几种。消息丢失通常是 WebSocket 断连导致解决办法是消息 ID 递增加服务端补拉。回复慢要么是模型 API 波动要么是你自己的队列堵了前者换备用通道后者加监控告警。重复回复多半是客户端重连后把没收到 ack 的消息又发了一遍服务端要做去重。还有一类问题特别隐蔽——内容安全拦截导致的AI 突然不说话了。你的模型可能正常返回了但内容审核层把它拦了前端什么都没收到用户以为卡了。我的做法是审核不通过时返回一个兜底话术并且给用户一个换句话说说的引导而不是干瞪眼。5.3 合规、上架与成本提前算清楚这笔账最后讲讲大家最关心的钱和资质。开发一个 App 并上架到底要花多少我按自己的实际情况列个表项目大概费用说明开发者账号一次性/年费各平台政策不同以官方公示为准软件著作权几百到上千上架部分平台可能需要服务器每月几十到几百早期低配够用随用户量升配大模型 API按量付费占运营成本大头做好缓存和摘要能省很多短信/推送按量验证码用得上支付通道按费率每笔抽成谈判空间不大美工/图标0 到几千自己会设计就省了真正的大头是AI API 费用和获客成本。前者靠技术优化压后者靠内容运营省。我强烈建议早期别急着投推广先把产品打磨到有人愿意主动推荐再考虑花钱买量。合规方面这类涉及情感陪伴的产品隐私政策、用户协议、未成年人保护提示一个都不能少而且内容审核机制必须真做不能糊弄。上架审核卡人基本都卡在这些地方。心理边界也要守住产品里要明确提示这是 AI 陪伴不替代专业心理咨询这是对用户负责也是保护自己。我个人的体会是这个项目最难的从来不是某个具体的技术点而是在无数个想放弃的深夜逼自己把支付回调的验签调通、把人设卡改到第 18 版、把 openid 那个报错死磕到底。等第一笔真实订单进来、后台弹出支付成功那一刻你会发现之前所有的卡壳都值了。如果你现在也处在一个迷茫期与其刷手机焦虑不如挑一个你真正想做的产品哪怕只做出一个能跑通的支付闭环你对整个工程体系的理解都会上一个台阶。做产品这条路没有捷径但每一步都算数。