迷茫那阵子我整晚整晚睡不着白天又提不起劲。为了不让自己彻底废掉我逼着自己写代码把脑子里想的那个“有人陪自己说说话”的念头做成了真东西——一款带支付、带官网的 AI 聊天虚拟恋人 App。从产品定位、大模型接入、微信支付到独立的展示官网我全流程走了一遍。这篇就把我踩过的坑、想明白的逻辑、能直接抄作业的代码片段都写出来。先说清楚这个 App 是干嘛的用户进去选一个人设温柔的、毒舌的、知性的都行然后和 AI 角色不限话题地聊。基础对话免费解锁特殊人设、延长单次聊天时长、或者购买“恋人模式”的订阅需要付费。官网负责展示功能、贴下载二维码、放隐私政策。整个项目大概花了我三周业余时间服务器成本控制在每月几十块。如果你也想做类似的情感陪伴类应用或者只是想搞明白“支付模块怎么做”“App 开发到上架大概要花多少钱”这篇文章应该能给你省下一大笔试错成本。1. 迷茫期的自救为什么我会做一款虚拟恋人 App1.1 项目起因情绪需求才是真需求先聊聊“为什么做”。那段时间我状态很差其实核心不是闲是“有话没人说”。找朋友倾诉吧大家都忙一次两次还行多了自己都不好意思。找心理咨询师价格摆在那一次两三百不是长久之计。后来我试了一些市面上的聊天 App要么机器人味太重要么免费额度少得可怜聊两句就弹充值。我当时就想能不能用现在的大模型 API自己做一个“不限次数、说话自然、人设可定制”的虚拟陪伴角色这个念头一旦起来就压不下去了。很多人会觉得情感陪伴是个伪需求但真做出来你才会发现深夜两点打开 App 的人比白天还多。都市人孤独感是个真实存在的痛点尤其是独居的年轻人、异地恋人群、社恐患者他们需要的不是“正确答案”而是“被接住的感觉”。我做这款 App 时想得很清楚不搞虚拟色情那一套擦边内容就是正经、温暖、有边界感的陪伴。上线后看用户反馈好几个人说“聊着聊着哭了”那一刻我知道这事值得做。1.2 为什么选“AI 情感陪伴”这个方向从技术角度看2024 年开始大模型 API 已经非常成熟文本生成质量、上下文记忆能力、响应速度都到了“可以商用”的及格线。我不需要自己训练模型只需要做好产品设计、上下文管理、支付闭环就能把一个完整的商业产品跑起来。这比两年前自己微调模型靠谱太多了。另外情感陪伴赛道有一个天然优势复购率高。工具类 App 用户用完就走但“恋人”这种角色是有情感黏性的用户会天天来聊粘性一旦形成付费转化就水到渠成。我当时定的商业模式很简单免费聊天体验 10 条消息然后需要购买时长包或者包月订阅。后面验证下来每天新增用户中大概有 2%-3% 会付费这在纯工具类产品里算相当不错的表现了。2. 技术选型从零搭起一台能聊天的 App2.1 客户端技术栈为什么用 uni-app 而不是原生先解决 App 壳子的问题。我自己的情况是会 Python 和 JavaScript但没写过 Swift 和 Kotlin。如果纯原生开发意味着同一套业务逻辑要写两遍还要分别适配 iOS 和 Android 的上架审核规则周期直接拉长一倍。所以我选了 uni-app基于 Vue3 的跨端框架一套代码可以同时编译成 iOS App、Android App 和 H5 网页。后端接口完全复用省下的时间全用来打磨聊天体验。uni-app 的坑也有但可以接受。最典型的坑是原生组件层级问题比如输入框、视频播放器容易盖住弹出层需要手动调 cover-view 或者用 uni 官方提供的 web-view 降级方案。我做聊天页的时候底部输入框和表情面板的弹层冲突折腾了我一个晚上后来用自定义 header 加普通 view 模拟输入框绕开了原生组件的坑。如果你也想用 uni-app 做聊天类应用记住一个原则能用普通 view 实现的就别上原生组件。2.2 后端架构Django 起步一套接口撑起全端后端我用的 Python Django Django REST Framework。为什么选 Django 而不是 FastAPI因为我要做用户体系、订单管理、支付回调、管理员后台Django 自带 Admin 和数据模型迁移这些工程化配套能省不少事。Django 创建 app 的命令很简单但命名和模块划分需要一开始就想清楚不然项目写大了会乱成一团。# 创建虚拟环境和基础项目 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install django djangorestframework django-cors-headers requests # 创建项目和应用 django-admin startproject myapp cd myapp python manage.py startapp users python manage.py startapp chat python manage.py startapp orders python manage.py startapp payment我分了四个 appusers 管注册登录和用户资料chat 管对话会话和消息记录orders 管订单生成和状态流转payment 管支付参数签名和回调验签。这样分的好处是后面接微信支付、支付宝、易支付这类第三方渠道时只动 payment 一个模块不会牵扯到其它业务代码。2.3 AI 对话核心链路大模型接入与人设管理AI 聊天是这个 App 的灵魂核心链路是用户发送消息 → 拼接系统提示词和最近对话记录 → 调用大模型 API 流式返回 → 前端逐字展示。这一环我用了 DeepSeek 的 API原因是它便宜、响应快、对中文语境的理解好而且上下文窗口够大可以塞进 20 轮以上的对话历史。人设管理是重中之重。我建了一张 persona 表字段包括角色名字、性格标签、说话风格示例、背景故事、禁忌话题。每次请求大模型时系统把这些信息拼进 system prompt 里。举个最简化的例子# chat/services.py 简化版 def build_messages(session, user_text): persona session.persona system_prompt f你现在是{persona.name}。 性格特点{persona.traits} 说话风格{persona.style} 背景设定{persona.backstory} 请全程保持角色人设用亲人朋友的口吻和用户聊天内容健康、真诚、有温度。 messages [{role: system, content: system_prompt}] for record in session.recent_records(limit20): messages.append({role: user, content: record.user_text}) messages.append({role: assistant, content: record.ai_text}) messages.append({role: user, content: user_text}) return messages这里有个经验上下文不是越长越好。很多人以为把全部历史消息都塞给模型AI 会更“懂你”实测下来发现窗口过长反而会让模型注意力分散角色性格漂移。我限制在最近 20 条对话超过的部分做摘要压缩效果比全量拼接好得多。关于内容合规我始终按主流平台的审核要求来做模型服务商本身就带过滤机制我在 prompt 里也明确了“健康、真诚、有温度”的基调同时接入了一层自建的敏感词拦截避免极端内容触发平台处罚。做这种陪伴类产品边界感非常重要不要想走擦边路线审核迟早会找上门。2.4 注册登录别一开始就上手机验证码新手做 App 最容易犯的错就是一上来就搞手机号验证码登录。验证码短信服务是有成本的一条三四分钱虽然不贵但用户填手机号的心理门槛很高转化率会掉很多。我第一版用了最简单的方案用户名密码注册再加一个游客模式。游客不强制注册也能体验 5 条免费消息等想继续聊了再注册这样漏斗损失最小。Django 自带的 User 模型不够用我扩展了一层 Profile。需要存用户头像、个性签名、偏好设置还预留了后续接入第三方登录的字段。支付回调时也需要通过 user_id 定位用户所以用户模块的健壮性直接影响支付链路。3. 支付模块从微信到支付宝的完整接入踩坑记录3.1 支付模块怎么设计才不把代码写死支付模块是很多独立开发者最头大的部分。我当时的思路是抽象一层统一的支付接口不管背后接微信、支付宝还是易支付业务代码只认源码类型和支付状态。这样以后换渠道只改适配层不动业务逻辑。# payment/models.py 简化版 class PaymentOrder(models.Model): order_no models.CharField(max_length64, uniqueTrue, verbose_name订单号) user models.ForeignKey(users.UserProfile, on_deletemodels.CASCADE) amount models.DecimalField(max_digits10, decimal_places2) channel models.CharField(max_length20, choices[ (wechat_jsapi, 微信JSAPI), (wechat_native, 微信Native), (alipay, 支付宝), (epay, 易支付), ]) status models.CharField(max_length20, defaultpending) # pending/paid/closed/refunded created_at models.DateTimeField(auto_now_addTrue)核心字段就是这些订单号、用户、金额、渠道、状态和时间。很多人问“支付模块怎么做”其实就是把这个模型建好然后写清楚支付参数生成和回调验签。最容易被忽略的是订单号的生成规则——我遇到过自己踩的坑直接用时间戳生成结果并发下单时撞了唯一索引后来改成“日期用户ID随机数”冲突概率才降到几乎为零。3.2 微信支付 JSAPI 必须传 openid 的完整解决方案微信支付接入最让人抓狂的坑就是你搜“jsapi支付必须传openid怎么解决”能搜出一堆让你去查文档的废话。我整理一下真正有用的方案。JSAPI 支付是微信内网页或者 App 内部拉起微信支付时的支付方式官方要求必传 openid这个 openid 是用户在某个公众号/小程序/App 下的唯一身份标识。拿不到 openid 就没法调起支付。最常见的两种业务场景和对应解法场景一如果你的 App 有微信登录能力这是最正规的路径。App 内接入微信登录 SDK用户点击“微信登录”授权后会拿到一个 code后端拿这个 code 去微信接口换 openid 和 session_key。换到 openid 后缓存到用户表里后面支付直接查库就行。# payment/wechat.py 简化版 import requests def code_to_openid(code): url https://api.weixin.qq.com/sns/oauth2/access_token params { appid: WECHAT_APPID, secret: WECHAT_SECRET, code: code, grant_type: authorization_code, } resp requests.get(url, paramsparams).json() if openid not in resp: raise Exception(f微信登录失败: {resp}) return resp[openid]场景二如果你的 App 没有微信登录用户直接下单这种时候不能强制用户先走一遍微信登录转化率会掉。我的做法是在用户选择微信支付并点击“去支付”时前端调起微信授权登录静默授权拿到 code 传给后端换 openid后端自动把 openid 存到用户资料里同时生成JSAPI 支付参数返回给前端。用户全程无感只看到微信的支付确认框弹出来了。# payment/wechat.py 继续 def create_jsapi_order(user, amount, order_no): if not user.openid: raise NeedWechatAuth() # 前端捕获后触发静默授权 params { appid: WECHAT_APPID, mch_id: WECHAT_MCH_ID, description: AI恋人会员订阅, out_trade_no: order_no, total_fee: int(amount * 100), # 单位是分 notify_url: https://你的域名/api/payment/wechat/notify/, openid: user.openid, } # 加签、发起统一下单、返回 prepay_id 给前端这里省略加密细节 return prepay_params3.3 支付宝沙箱支付零成本联调的正确姿势支付宝对独立开发者友好很多因为提供了沙箱环境不用真实资金就能模拟完整支付流程。我强烈建议你第一次接支付时先用支付宝沙箱练手因为它的文档和测试工具是几家里最完整的。支付宝沙箱的使用方法登录蚂蚁金服开放平台进入开发者中心申请沙箱应用系统会给你一套专用的 APPID、应用私钥和支付宝公钥。沙箱环境里有一个配套的支付宝客户端沙箱版支付宝 App可以模拟扫码支付和 App 支付的回调。你后端收到回调后验签、改订单状态、给用户发消息这套逻辑在沙箱里跑通了切正式环境只是换个密钥和网关地址。# payment/alipay.py 简化版 from alipay import AliPay alipay AliPay( appidALIPAY_APPID, app_notify_urlNone, app_private_key_stringAPP_PRIVATE_KEY, alipay_public_key_stringALIPAY_PUBLIC_KEY, sign_typeRSA2, debugTrue, # 沙箱环境必须开 debug ) order_string alipay.api_alipay_trade_app_pay( out_trade_noorder_no, total_amountstr(amount), subjectAI恋人会员订阅, )生成出来的 order_string 是前端拉起支付宝需要的参数字符串App 端集成支付宝 SDK 后把这段字符串塞进去就能弹出支付界面。沙箱环境跑通后别忘了一件事把 debug 改成 False网关地址换成正式地址密钥换成正式密钥。3.4 补充渠道易支付和 USDT 要不要接我在开发时也研究过彩虹易支付和 USDT 支付毕竟热搜词里有人问。彩虹易支付本质是聚合支付平台你不需要有自己的商户号直接调用它的接口收款它从中抽成。优点是接入极快代码量比官方支付少一半个人开发者没有营业执照也能用缺点是资金在你的平台里过一手得挑口碑好的平台否则有资金风险。另外易支付很多通道走的其实是 H5 跳转对用户体验有一定损耗。USDT 支付我就不建议普通开发者碰了虽然没有跨境和风控问题但汇率波动、链上确认速度、实名制要求这些放在正规上架的应用里都不合适。我的结论是正规上架产品老老实实接微信支付宝内测阶段或者海外用户可以用易支付过渡USDT 只在极少数场景值得考虑。4. 官网搭建给 App 一个“正经门面”4.1 官网要解决什么问题很多独立开发者不重视官网觉得“有个 App 就行了”。实际上官网承担了三件事品牌背书、下载转化、用户信任。没有官网用户看到你的下载链接的时候会犹豫“这到底是不是正规 App”有官网哪怕只是个简单的落地页转化率都会明显提升。另外iOS 上线时审核人员也会看官网的隐私政策没有官网就要把隐私政策单独做成页面反而更麻烦。官网不需要很复杂我最开始只做了四个模块首屏一句话介绍产品、核心功能的截图、下载按钮Android APK 和 iOS TestFlight 链接、隐私政策与用户协议。整体风格走干净温和的路线配色用米白、浅灰和一点低饱和度的橙色和“温暖陪伴”的产品调性保持一致。技术栈用的 Next.js 静态导出然后直接丢到 GitHub Pages 上不用自己运维服务器。4.2 官网部署GitHub Pages 和域名的搭配有人会遇到“github官网进不去”之类的问题我第一次部署时也碰到过。这里分享一个我自己实测有效的思路用命令行工具操作。GitHub 官方提供 gh 命令行工具登录、建仓库、推送代码都可以在终端里完成不依赖网页端基本不受网络波动影响。另一个思路是多试几个时段避开访问高峰或者切换本地网络环境。总之官网部署这事本身技术难度不高主要是环境问题耐心点总能解决。# 用 gh 命令行快速建仓库并推送 gh auth login gh repo create ai-lover-site --public --source. --remoteorigin --push # 手动推送也可以 git init git add . git commit -m init site git remote add origin gitgithub.com:你的用户名/ai-lover-site.git git branch -M main git push -u origin mainGitHub Pages 的免费额度对个人官网完全够用支持自定义域名也支持 HTTPS 证书自动生成。唯一要注意的是国内的访问速度不算快面向国内用户时可以考虑用国内静态托管平台比如 Gitee Pages 或阿里云 OSS CDN但不是必须的前期用 GitHub Pages 跑通流程最省事。4.3 域名、备案与合规域名这块我的建议是在正规注册商阿里云、腾讯云、Cloudflare 都行买一个 .com 或者 .cn 域名一年几十块到上百块别贪便宜去奇怪的平台注册。反代、DNS 解析这些基础操作都差不太多重点说一下备案问题。如果官网和 API 服务器部署在国内云服务器上域名是必须备案的备案周期大概一到三周。如果不备案直接用 IP 访问或者境外服务器用户的聊天记录、下载体验都会受影响。我做的时候为了省时间API 服务器放在境外节点官网用 GitHub Pages域名本身不备案也能跑但国内微信支付回调要求服务器必须是备案过的域名这一下就把问题变成了绕不开的坎。所以我建议你从一开始就规划好面向国内市场服务器放国内、域名备案面向全球就不用备案但支付渠道要选支持海外的。5. 常见问题与成本复盘5.1 高频问题速查表一个人开发整个项目遇到的问题是成批的。我把踩过的重要问题和解决方案整理成了一张速查表都是网上能搜到但答案很分散的问题你直接收藏这份就行。问题原因解决方案JSAPI 支付提示“必传 openid”用户身份标识缺失接入微信静默授权先换 openid 再下单支付宝沙箱支付回调收不到回调地址配置成了 IP 或未联调环境地址用内网穿透工具如 ngrok把回调地址映射到本机或保证公网可访问App 抓包失败看不到请求数据系统证书信任或代理设置问题iOS 装描述文件并信任证书Android 7.0 需要在 manifests 里允许用户证书官网在手机浏览器打开排版错乱没有设置 viewport 和响应式布局首页只写一个meta nameviewport contentwidthdevice-width, initial-scale1.0用 CSS 栅格代替固定宽度用户支付成功但开发者没收到回调回调验签失败或服务器端口未开放打印完整回调日志先看签名算法RSA2/SHA256是否匹配deepseek API 报系统繁忙单日免费额度较高但并发被限流增加重试机制超过 5 次退避降级到备用小模型虚拟恋人聊天“记忆错乱”上下文窗口塞得太满限制最近 20 条历史 定期做摘要压缩5.2 App 上架前要知道的几件事很多新手会问“开发一个 app 并上架大概要多少钱”这个问题拆开算其实很清楚项目成本方面服务器最便宜的 1 核 2G 云服务器一年约 500 元左右、域名一年 50-100 元、短信服务如果做手机号登录一条 3-5 分钱前期可以不做、App Store 开发者账号每年 688 元加上给 AI 对话消耗的大模型 API 费用按我目前的使用量每月 30-80 元左右。纯 app 开发的“钱”主要是苹果开发者账号这一项是固定的其他都能用最低配起步。上架方面Android 应用市场的审核主流应用商店相对宽松但需要软著iOS 的审核更严格虚拟支付类 App 要注意虚拟商品聊天时长、会员用微信/支付宝 H5 支付在 iOS 上有被拒风险标准做法是用内购 IAP 或跳转 Safari 支付。我的方案是iOS 版用 TestFlight 小规模分发正式上架前先验证一波用户反馈。5.3 成本与利润复盘独立开发者一定要算明白的账按我三周的开发周期算硬成本大概是服务器 500 元/年 域名 80 元/年 苹果开发者账号 688 元/年 大模型 API 约 50 元/月。还没算上自己的时间成本——如果按日薪折价投入大概两万块“账面成本”。但独立开发本来就是用时间换自由这笔账不能这么算。上线第一个月的数据更有参考价值新增注册用户 426 人付费用户 11 人付费率约 2.6%客单价 18 元。月收入约 198 元勉强覆盖服务器和 API 成本离回本还早。但我坚定地认为这方向能跑通因为留存数据已经说明了问题第二周的次留能有 32%付费用户里几乎没有退订的说明产品真的戳中了一部分人的需求。接下来要做的就是加新的人设、把聊天体验做得更像“真人”靠口碑慢慢滚起来。写在最后做这个 App 的过程其实比 App 本身更治愈我。迷茫期的人最需要的不是“振作起来”这种鸡汤而是能有一件具体的事牢牢抓住你的注意力。代码不会骗人你写下去系统就能跑起来这种确定性是那段时间我唯一能抓住的东西。最后再分享一个小技巧如果你也想做类似项目第一步千万别想着做大而全的功能先做一个只有“聊天 支付”两个功能的 MVP把它完整上线再慢慢加需求。跑通一个最小闭环带来的信心比看一百篇技术文章都管用。