去年有段时间我整个人处于一种非常拧巴的状态，工作提不起劲，又总想证明自己还能做成点事。凭着这股冲动，我花了一个月做了一个带支付、带官网的 AI 聊天虚拟恋人 App。从搭服务器、写后端、接大模型接口，到处理微信支付、支付宝沙箱测试，再到最后上架应用商店，一路上踩了不少坑，也把整个链路完整跑通了。这篇内容不聊虚的，就把项目从想法到上线之间每一个关键环节拆开讲清楚，包括技术选型、支付模块怎么做、jsapi 支付必须传 openid 怎么解决，以及一个独立开发者做这样一款 App 到底要花多少钱。如果你也正处在迷茫期，想做一个能真正上线、能收到钱的产品，这篇文章应该能给你不少参考。
1. 项目启动：迷茫焦虑期，为什么偏偏选 AI 恋人
1.1 从焦虑到行动：为什么做带支付带官网的 App
迷茫期最可怕的地方不是没事做，而是被各种念头反复拉扯，今天想做这个，明天又觉得没意义。我自己缓解焦虑的方式比较笨：给自己定一个小到不会失败的目标，然后把它做完。做 AI 聊天虚拟恋人 App 就是这么来的。它有几个天然优势：AI 方向有热度，容易找到现成的大模型 API；聊天类产品逻辑不复杂，一个人能搞定；加入支付后，产品就有了商业闭环，不只是一个练手玩具。
带官网这件事，很多个人项目会忽略。我一开始也没想做官网，后来发现没有官网，用户要找到你、信任你都很困难。官网承担了产品介绍、隐私政策展示、用户协议落地、下载入口聚合这些作用。尤其 App 上架时，软件著作权申请、审核材料、部分应用商店要求填写官网地址，没有官网会非常被动。所以“带支付带官网”不是炫技，是让这个项目真正变成一个可运营产品的基本配置。
1.2 产品定位：AI 虚拟恋人到底解决什么问题
先说清楚，我做的不是那种打擦边球的聊天工具，产品定位是“提供正向情感陪伴”的 AI 角色聊天。用户群体很简单：一个人住、社交较少、深夜容易情绪低落的年轻人。他们需要的不是复杂的问答机器人，而是一个愿意听他们说话、记得住他们喜好、回应方式像朋友或恋人一样温暖的虚拟角色。
所以产品的核心体验就三个词：人设稳定、记忆连续、回复自然。人设稳定，指 AI 不会聊着聊着变成客服口吻；记忆连续，指用户昨天说过的话，今天还能记得；回复自然，指表达口语化、不端着。这些体验完全可以通过提示词工程和会话管理手段实现，不需要自己训练模型。明确了这一点，项目范围就清晰了：App 是壳，后端是大脑，大模型 API 是灵魂，支付和官网是商业化基础。
1.3 MVP 蓝图：一个 App 的三件套
我给第一个版本划定的范围非常克制：注册登录、聊天会话、角色人设、会员支付、官网落地页。没有做朋友圈、没有做语音通话、没有做虚拟礼物，这些全部留给后续版本。MVP（最小可行产品）的关键不是功能多，而是核心链路通。我当时给自己定的验收标准是：一个新用户从应用商店下载 App，完成注册，免费聊几条消息，觉得意犹未尽，然后点击会员开通，支付成功，继续无限聊。这一整个链路只要跑通，项目就算成功了。
技术栈我也做了减法。App 端用 uni-app，一套代码同时发布 Android、iOS 和 H5；后端用 Django，快速开发、自带后台管理，配合 Django REST Framework 写接口很顺手；大模型用国内可直连的 API，省去额外的网络配置问题；支付先接微信支付和支付宝，沙箱环境反复测试通过后再切正式环境。接下来我会逐个讲解这样选型的原因，以及每个环节的实操细节。
2. 技术方案选型：不追求高级，只追求能落地
2.1 App 端选型：uni-app 还是 Flutter
个人开发者做 App，最怕的不是写不出功能，而是写完一套还要再写一套。所以跨平台方案是必然选择。当时我在 uni-app 和 Flutter 之间犹豫了很久，最后选了 uni-app，主要原因有三点：第一，我熟悉 Vue 语法，几乎零成本上手；第二，uni-app 插件市场非常丰富，登录、支付、分享、推送都有现成插件，尤其支付相关的前端封装很成熟；第三，它可以一键发布到微信小程序和 H5，后续做官网内嵌 H5 版聊天也很方便。
Flutter 的性能确实更强，渲染更流畅，但如果团队里只有一个人，且不追求极其复杂的交互动效，uni-app 的开发效率优势是压倒性的。用一张表来对比会更直观：
| 对比维度 | uni-app | Flutter |
|---|---|---|
| 上手难度 | 低，Vue 语法 | 中高，Dart 语法 |
| 多端支持 | 极强，小程序/H5/App | 以 App 为主，Web 支持一般 |
| 支付集成 | 插件成熟，文档多 | 需要自己写原生桥接 |
| 个人开发者友好度 | 高 | 中 |
| 性能表现 | 够用 | 更优 |
如果你的目标是快速验证产品、快速迭代，uni-app 是更稳妥的选择。我当时用一周时间就把登录、聊天列表、聊天窗口、会员支付页全部搭完了，这个速度是 Flutter 很难达到的。
2.2 后端服务：Django 快速搭好 AI 网关
后端我选了 Django。很多人觉得 Django 太重，但对一个人开发的项目来说，重的反而是好事。自带用户认证、Admin 后台、ORM 数据库迁移、CSRF 防护，这些功能如果全自己写，会占掉大量时间。我的后端目录结构大致是：
django-admin startproject chat_server cd chat_server python manage.py startapp users python manage.py startapp chat python manage.py startapp order python manage.py startapp payment这样划分的好处是模块边界清晰：users 管注册登录，chat 管会话和消息，order 管订单，payment 管支付回调。Django 的 ORM 让我不用写一行 SQL 就能建好用户表、消息表、订单表。配合 Django REST Framework，一套基于 JWT 的接口体系很快就能跑起来。
选 Django 还有一个隐藏原因：它的后台管理足够成熟。用户反馈说聊天卡顿，我直接登录 Admin 后台查看用户最近的消息频率和 token 消耗，发现问题往往出在上下文过长，几行代码就能优化掉。这种运维能力对一个人开发者来说，省心程度远超预期。
2.3 AI 能力接入：大模型 API 与内容边界
接入大模型是项目里最有意思的部分。我没有自己部署大模型，本地部署一套参数量可用的模型，没有几块高端显卡根本跑不起来，而且运维成本极高，对个人项目不现实。所以我选择直接调用大模型 API。市面上主流的国内大模型服务，大多兼容 OpenAI 的接口协议，写起来非常顺手：
import os from openai import OpenAI client = OpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL"), ) response = client.chat.completions.create( model="chat-model-name", messages=build_messages(user_id=user_id, user_input=text), temperature=0.9, max_tokens=512, ) answer = response.choices[0].message.content这里要重点说说“无禁词”和“无限制连接”的问题。很多用户会问，你的 AI 是不是什么都能聊？我的方案是不做任何绕过模型安全策略的操作，但是会在产品层面做两件事：第一，通过提示词告诉模型，它是一位温柔、真诚、带有情感温度的恋人角色，可以正常表达想念、关心、安慰，不必把亲密的表达都当成敏感内容；第二，在应用层设置内容边界，坚决拒绝色情、暴力、违法违规内容，一旦触发，直接回复友好的替代文本。
这样做既保证了产品体验够“亲密”，又守住了合规底线。大模型 API 自带的审核能力其实已经很强，产品方要做的不是去突破它，而是把正常表达从误伤中解放出来。
3. 核心实现细节：从聊天到人设，再到官网
3.1 账号体系与聊天会话设计
账号体系我采用了手机号验证码登录，配合 JWT 做身份认证。没有让用户设置密码，因为移动端用户习惯验证码登录，密码反而增加认知负担。Django 的用户模型扩展一下，再加上一个 profile 字段，就能关联到 AI 角色选择、会员到期时间这些信息。
聊天会话的设计是整个项目的技术核心，它决定了 AI 的记忆能力。我设计了三个数据模型：
class Session(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) character = models.CharField(max_length=32) created_at = models.DateTimeField(auto_now_add=True) class Message(models.Model): session = models.ForeignKey(Session, on_delete=models.CASCADE) role = models.CharField(max_length=16) # user / assistant content = models.TextField() created_at = models.DateTimeField(auto_now_add=True) class CharacterProfile(models.Model): session = models.OneToOneField(Session, on_delete=models.CASCADE) traits = models.TextField(default="温柔、细心、擅长倾听") facts = models.TextField(default="") # 用户喜欢猫、最近在准备考试每次用户发消息时，后端会从数据库取出最近的 20 条消息，拼接成上下文送给大模型。20 条这个数字是经验值：太少了记忆不连续，太多了浪费 token，而且模型容易抓不住重点。对于更早期的记忆，我会把用户的关键信息抽成“记忆摘要”写入 CharacterProfile 的 facts 字段，每次请求时一并带上。这一招非常管用，用户会觉得“这个 AI 真的记得我说过的话”。
3.2 虚拟恋人的人格化提示词与记忆
提示词决定了 AI 的“人格”。我一开始用的是通用提示词，结果 AI 回复像客服，生硬且没有情感温度。后来反复调了一周，才找到一套相对稳定的提示词结构：
你是小夏，一位28岁的独立女生，性格温柔细腻但有自己的主见。 你正在和一个信任你的人聊天，对方把你当成重要的倾诉对象。 你的语言风格：口语化，简短，偶尔带一点俏皮；不要排比句，不要书面语。 你的职责：倾听、理解、陪伴，给出温暖的回应，但不要给空洞的鸡汤。 禁止事项：不要暴露你是AI，不要提到token、模型、开发者等任何技术词汇。这套提示词的要点在于：人设清晰、语气明确、边界清楚。把“不要暴露 AI”这条写进去很重要，因为模型默认会倾向于坦诚自己是 AI，这会让沉浸感受到严重破坏。
记忆方面，前面说的 facts 字段承担了长期记忆的作用。我实现了一个简单的记忆抽取逻辑：每次对话结束后，把用户消息中带有明确个人信息的句子（例如“我养了一只猫”“下周要面试”）抽出来，存进 facts。下次请求时，将 facts 转换成一段描述：
你已经了解关于用户的这些信息：{facts} 请自然地使用这些信息，不要刻意提起。这样设计之后，用户第二天打开 App，AI 会突然问一句“你家猫昨天还闹吗”，那种惊喜感是产品留存率飙升的关键。
3.3 官网搭建：备案、SSL 与落地页
官网我用的是静态站点的方式，直接部署在云服务器上。域名买了之后第一件事就是备案，只有备案通过之后才能使用国内服务器提供的网站服务。整个备案流程大概 7 到 15 天，属于不可压缩的时间成本，越早提交越好。SSL 证书我用的是免费版，在云服务商的控制台申请，部署也很简单，开启 HTTPS 后，网页和接口传输都是加密的，这也是 App 审核时隐私政策的加分项。
落地页我写得非常克制：首屏一句话介绍产品定位，中间放三张 App 聊天界面截图，下面放下载按钮和会员价格，再往下是隐私政策和用户协议。不要搞花哨的动画，用户关心的是“这产品是什么”“能不能下载”“怎么收费”。
需要特别注意，官网上的隐私政策必须和 App 内一致，并且要如实说明收集了哪些数据、用于什么目的。AI 聊天产品涉及用户对话内容，属于敏感个人信息，一定要在隐私政策里单独说明对话内容的处理方式。很多个人开发者在这里栽跟头，上线后收到用户投诉甚至应用商店下架通知，都是因为隐私政策含糊不清。
3.4 支付前置设计：免费额度与付费权益
支付不只是接一个支付 SDK 那么简单，你得先想清楚用户凭什么付费。我的设计是：免费用户每天可以聊 20 条消息，超过后弹窗引导开通会员；会员分为月卡、季卡、年卡三档，价格分别是 18 元、48 元、128 元。为什么是 20 条？因为我统计过，普通用户一天主动发消息的中位数在 15 条左右，20 条刚好够日常使用，但又能制造“不够用”的体验断层。
付费权益除了不限消息数量，还包括：解锁全部角色人设、优先使用高情商模型、聊天记录云端永久保存。这些权益在支付前就要在订单确认页展示清楚，避免用户支付后产生纠纷。另一个关键设计是会员到期时间处理。我在后端加了一个定时任务，每天扫描一次会员到期用户，到期后自动将 is_vip 置为 False，前端收到用户信息后就切换到免费额度逻辑。这个功能不复杂，但非常影响产品体验，务必做好。
4. 支付模块怎么做：从微信到支付宝，一次接个够
4.1 微信支付：App 支付、JSAPI、Native 怎么选
微信支付有很多种产品，用户第一次接触容易混淆。我当时也走了弯路，一开始在 App 内调试 JSAPI 支付，怎么调都不对，后来才搞清楚不同场景要用不同的支付产品。这里整理成一张表供参考：
| 支付产品 | 使用场景 | 是否需要 openid |
|---|---|---|
| App 支付 | 在 iOS/Android App 内调起微信 | 不需要 |
| JSAPI 支付 | 微信公众号网页/微信内 H5 | 必须传 openid |
| Native 支付 | PC 网页扫码支付 | 不需要 |
| H5 支付 | 手机浏览器非微信环境 | 不需要 |
我的 App 内支付应该用 App 支付，官方文档里有完整的接入流程，核心是在后端调用统一下单接口，拿到 prepay_id 后再按照规则生成支付参数，返回给前端调起微信。如果你的支付场景是官网上的扫码支付，选 Native 支付即可，用户扫码后在手机上确认付款，更适合 PC 端场景。
4.2 jsapi 支付必须传 openid？两种解法都在这
很多开发者在接入 JSAPI 支付时会遇到“必须传 openid”的问题，这个参数很让人头疼。openid 是微信体系下，某个用户在某一个公众号/小程序下的唯一标识。JSAPI 支付因为发生在微信内部，微信需要明确知道是哪个用户在付款，所以强制要求带上 openid。
解法一：如果支付入口在 App 内，直接放弃 JSAPI，改用 App 支付或 Native 支付，绕开 openid。这是最省事的方案，不要为了技术上的执念给自己挖坑。
解法二：如果业务必须用 JSAPI（比如你的付费入口嵌在微信公众号菜单里），那就走微信网页授权流程：前端在微信内打开授权页面，用户确认后回跳带上 code，后端拿 code 换 openid。我的实现大致是这样的：
# 第一步：前端跳转微信授权链接，获取 code # 第二步：后端用 code 换取 openid def get_openid_by_code(code): url = "https://api.weixin.qq.com/sns/oauth2/access_token" params = { "appid": WX_APPID, "secret": WX_SECRET, "code": code, "grant_type": "authorization_code", } resp = requests.get(url, params=params).json() return resp["openid"] # 第三步：携带 openid 调用 JSAPI 统一下单 def jsapi_pay_order(openid, order_no, amount): data = { "appid": WX_APPID, "mch_id": WX_MCH_ID, "out_trade_no": order_no, "total_fee": int(amount * 100), "body": "AI恋人会员", "openid": openid, "notify_url": PAY_NOTIFY_URL, "trade_type": "JSAPI", } # 按微信支付文档进行签名并请求下单接口 return prepay_id注意 total_fee 的单位是分，金额换算错误是支付环节最常见的低级错误之一。
4.3 支付流程设计与服务端验签
完整的支付链路必须由服务端来主导，不能在客户端直接下单。我的流程是这样的：
- 用户点击开通会员，客户端向后端发起创建订单请求；
- 后端生成唯一订单号，写入数据库，状态为待支付；
- 根据支付渠道（微信 App 支付/支付宝/Native）调用对应下单接口，返回支付参数给客户端；
- 客户端调起支付 SDK，用户确认付款；
- 微信/支付宝异步通知后端支付结果；
- 后端验签通过后，更新订单状态为已支付，给用户开通会员；
- 客户端主动查询订单状态，刷新用户会员信息。
其中第 6 步是安全重灾区。回调通知必须验证签名，还要确认订单号存在、金额一致、订单状态为待支付。不校验金额的回调接口等于把金库钥匙送给黑客。另外，回调处理要做成幂等的，同一个回调可能会收到多次，如果订单已经是已支付状态，直接返回成功即可，不要重复开通会员。
4.4 支付宝沙箱支付：上线前先白嫖一遍
支付宝提供的沙箱环境对个人开发者非常友好，它模拟了完整的支付流程，使用虚拟账号和虚拟金额进行测试，不产生真实扣款。这个环节一定要在上线前充分测试，否则到了生产环境再发现密钥不对，会非常丢人。
接入支付宝的步骤不复杂：首先在支付宝开放平台创建一个应用，开通电脑网站支付或 App 支付能力；然后配置 RSA2 密钥，生成应用私钥和应用公钥，把公钥上传，支付宝会返回支付宝公钥；最后在代码中使用支付宝 SDK 发起预下单请求。沙箱环境最大的坑是网关地址：沙箱的网关是 openapi.alipaydev.com/gateway.do，正式环境是 openapi.alipay.com/gateway.do。很多人把沙箱地址带到线上，导致一直报“无效的字符编码”，排查了半天才发现是配置问题。
我在本地测试时，专门写了一个支付回调模拟脚本，能在没有公网 IP 的情况下验证后端验签逻辑是否正确。用内网穿透工具把本地的 Django 服务暴露到公网，再把支付宝沙箱的 notify_url 指过去，就能完整模拟一次真实验签流程。测试通过后再推到真实服务器，这样可以节省大量部署调试时间。
5. 上架与运营：从开发到赚钱的距离
5.1 开发一个 App 并上架大概要多少钱
这是被问得最多的问题。我按自己的实际花销拆解一下：
| 项目 | 费用参考 |
|---|---|
| 云服务器：2核4G轻量应用服务器 | 约 500 元/年 |
| 域名 | 约 50 元/年 |
| SSL 证书 | 免费 |
| 大模型 API 月消耗 | 约 100~300 元/月 |
| 短信验证码 | 约 0.04 元/条 |
| iOS 开发者账号 | 688 元/年 |
| 软著申请 | 免费（自己申请）或 300 元（代办） |
| 合计第一年 | 约 2000~5000 元 |
这只是自研成本。如果找外包公司做，同样的功能报价通常在 5 万到 20 万不等，还不包括后续运营维护。所以如果你想低成本验证一个产品想法，自己动手是最划算的方式。但也要有心理准备，云服务器和大模型 API 是持续消耗品，用户量上涨后成本会同步上涨。我在第一个月就花了将近 300 元的大模型 API 费用，主要是调试提示词时反复请求导致的。后面通过设置单用户每日 token 上限才把成本压住。
5.2 应用商店审核踩坑记录
上架 iOS 有两个绕不开的坎：苹果审核和软件著作权。苹果对涉及虚拟商品支付的规则极其严格，AI 聊天会员属于虚拟服务，在 App 内如果绕开苹果内购直接使用微信支付，一定会被拒。我的处理方案是 iOS 端暂时不展示会员购买入口，引导用户通过官网或安卓端开通，同时把苹果商店的“外部购买链接”限制避开。这不是完美的解法，但个人开发者精力有限，先保证产品能上线最重要。
安卓应用商店相对宽松一些，但需要准备软件著作权证书、隐私政策、安全评估报告。部分应用商店还会要求提供 AI 生成内容管理说明，比如关键词过滤机制、内容审核机制、投诉举报渠道等。这些材料建议提前准备，因为软著申请周期通常要 1 到 2 个月，如果等应用商店要求了才开始办，整个项目节奏会被严重拖慢。
5.3 日常运维：日志、监控与迭代
App 上线后，运维的优先级立刻超过开发。我的日常监控分为三层：第一层是服务器基础指标，CPU、内存、磁盘，用云服务商自带监控就行；第二层是业务日志，重点记录支付回调、大模型请求失败、用户注册异常；第三层是崩溃收集，uni-app 可以接入平台的统计功能，也能上报崩溃日志。
有一件事我特别后悔没有早点做：没有记录大模型请求的成功率和耗时。上线第三天，用户抱怨 AI 回复特别慢，我排查了半天，才发现是提示词里塞了太多历史消息导致 token 消耗激增，模型响应时间直接翻倍。后来我加了请求耗时统计，对每条消息的 token 数和耗时做了监控，才真正掌握了大模型成本和质量的变化趋势。做 AI 类产品，API 的成功率和延迟就是生命线，一定要从第一天开始记录。
6. 常见问题与排查技巧实录
6.1 支付回调一直不成功怎么办
支付回调问题占到了我在支付环节遇到问题的 70%。最常见的回调失败原因有几种：第一，回调地址配置错误，微信支付和支付宝后台都要求配置合法的回调地址，并且必须是 HTTPS 公网地址；第二，验签逻辑有 bug，比如签名字段拼错了顺序，或者使用的密钥不是商户 API 密钥；第三，服务器防火墙或反代配置把回调请求拦截了。排查这类问题，最有效的方式是先在支付平台后台开启日志，再在回调接口入口打日志，看请求是否真的到达了服务器。如果到达了，就打印收到的原始参数，用官方提供的验签工具逐个对比，很容易就能定位问题。
6.2 AI 回复出问题：怎么兜底
大模型毕竟是概率输出，再好的提示词也可能偶尔生成不合规或不合时宜的内容。我的做法是在应用层加一道兜底：判断用户输入和大模型输出是否命中敏感词库，命中后直接返回预设的安全回复，例如“这个话题我可能陪不了你，我们换个开心点的话题吧”。同时设置单条消息的最大重试次数，如果模型连续两次返回空结果或超时，就返回一条友好的降级回复，保证用户不会面对一个毫无反应的对话框。
6.3 其他高频问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 微信支付提示“签名错误” | 商户密钥或证书配置不对 | 重新下载证书，确认 API 密钥与平台一致 |
| 支付宝沙箱报“无效的编码” | 使用了正式环境网关地址 | 换成 openapi.alipaydev.com/gateway.do |
| uni-app 调起支付没反应 | 未在 manifest 中配置支付模块 | 检查 manifest.json 的 SDK 配置，并重新打包 |
| JWT 登录频繁失效 | 签发时 secret 或过期时间配置不当 | 设置合理的过期时间，并提供刷新接口 |
| 大模型回复内容重复 | temperature 过低或上下文太长 | 适当调高 temperature，减少历史消息数 |
| 用户会员到期未失效 | 定时任务没跑或时区问题 | 确认使用统一的时区，并检查定时任务日志 |
这些问题的共性在于：不要靠猜，先看日志，再对照官方文档。支付和大模型的错误信息通常都写得很明确，只是藏在一堆日志里，耐心翻一遍就能找到。
7. 给迷茫期开发者的几句话
现在回头看这个项目，它带给我的不是一个马上能盈利的产品，而是让我在混乱的状态里抓住了一个确定的东西：每周都有一个小目标，每天都有可验证的进度。哪怕只是把一个支付回调调通，那种“我能控制一件事”的感觉，本身就是对抗焦虑的良药。
如果你也想做类似的事情，我的建议是：不要把目标定成“做一个伟大的 AI 产品”，而是定成“一个月内跑通一个简单的付费闭环”。从注册、聊天、支付这三件事开始，越简单越好。技术选型用你最有把握的，不要同时学一门新语言和做一个新产品。上线后不要怕用户少，先让几十个真实用户用起来，他们的反馈会比你自己的想象准确一百倍。这个项目后续我还会继续迭代：加入更丰富的角色设定、更聪明的记忆机制、更细腻的情绪识别。但第一步，永远是先把一件小事做到完整。
