从零开发AI聊天App：支付、官网与上架全记录

三月底那阵子，我整个人处于一种很奇怪的状态。白天上班开会还能正常应对，一到晚上就瘫在沙发上刷手机，刷到脑子发麻也不想睡。焦虑这种情绪最麻烦的地方不是“难受”，而是“不知道自己在难受什么”。为了把自己从这种状态里拽出来，我开始动手做一个完全属于自己的小产品——一个AI聊天虚拟恋人App，而且不是做完就扔的demo，我认认真真地给它接上了微信支付和支付宝，注册了域名、搭了官网、做了合规页面，一步一步把它推到了应用商店。

这篇文章本质上是一次项目复盘。我不打算讲太多大道理，而是把从零到可以独立运营这段路程里，我踩过的坑、验证过的方案、花掉的钱和换来的数据，一次说清楚。如果你也想做一个带支付、带官网、能自己收钱的AI聊天类App，这篇内容应该能帮你省掉至少一个月的试错时间。

1. 为什么迷茫焦虑的人，会想到去做“AI聊天虚拟恋人”

1.1 焦虑的另一种名字，叫“需要一件可控的事”

先说那段日子。项目延期、版本被砍、年终绩效一般，所有的反馈都在告诉我：很多事情不是你努力就能控制的。这种失控感积累到一定程度，人会本能地寻找一个完全由自己说了算的事情。对我这种写代码出身的人来说，最自然的出口就是——做一个自己的产品。

当时手机里装了好几个AI聊天软件，晚上睡不着的时候，我发现自己和Kimi、DeepSeek聊的时间比和真人还多。有时候只是瞎聊，有时候确实是心情不好想找人说说话。AI不会评判你，不会不耐烦，也不会因为你凌晨三点发消息就生气。这个体验本身给我提了个醒：大家需要的可能不是一个更聪明的AI，而是一个愿意听你说话、说话方式像人的陪伴者。

后来我顺手搜了下“虚拟ai聊天”“无禁词虚拟ai聊天”这类词，发现搜索量和需求远比我想象的大。很多用户抱怨的点在于：免费平台动不动就冷冰冰地拒绝、话题尺度限制太死、聊两句就开始说车轱辘话。这些抱怨正好对应了三个可以做事的方向：更自然的对话、更少被打断的体验、以及一个不那么廉价的陪伴感。

1.2 产品定位：不是成人内容，是情绪陪伴

这里必须先说清楚一件事：我做虚拟恋人App，定位从来就不是擦边或者成人内容，而是情绪陪伴。用户想要的是聊天时有来有回、能记住你昨天说过的烦心事、会在深夜问你“今天感觉好点吗”的那种被接住的感觉。

这个定位决定了后面所有的产品决策。话题边界要清晰，审核要有底线，宁可对话显得“克制”，也不能为了讨好用户去踩线。因为一旦产品涉及违规内容，支付渠道会停、应用商店会下架、域名会被锁，前期所有基建都白搭。这也是我把“带支付带官网”当成项目核心工程的原因——有支付意味着有真实商业闭环，有官网意味着有规则、有背书、有可以追责的地方，这会让产品的寿命完全不一样。

1.3 先给后来者算一笔账：时间、成本与能力准备

如果看到这里你也想动手，先冷静评估三件事。

是时间。我正常工作日在职，只能靠晚上和周末写代码，从立项到内测用了大概六周，接着花了三周接支付和准备上架材料。如果你能全职投入，时间可以压缩不少，但至少也要给自己留一个月以上的预算。

是成本。前期投入主要包括域名、服务器、大模型API调用费用、软著申请等，我在第五章会给出详细清单。总的感受是：个人做商业化App的花费没有想象中高，头两个月几千块以内完全能跑起来，真正贵的是时间和试错。

是技能。你不需要是技术大佬，但至少要会一点后端、一点前端，要是了解过怎么对接第三方API就更好了。AI聊天App的核心逻辑并不复杂：App负责聊天界面，后端转发大模型请求，支付系统负责收钱。这三条链路都不算特别深，但每条都有各自的坑。

2. 技术方案：先跑通“聊天闭环”，再谈App和官网

2.1 别一上来就自己搞模型，API 是个人开发者最好的起点

很多朋友问我，做AI聊天App是不是得自己训练个模型。这里我建议所有个人开发者冷静：训练一个靠谱的对话模型，时间和成本都不是独立开发者能承受的。我自己用的方案是接国内成熟的大模型API，比如DeepSeek、Kimi这类开放平台的接口，按token付费，随用随走。

选API时有三个关键指标：响应速度、上下文长度、成本。响应速度决定用户聊天的爽感，上下文长度决定AI能否记得住之前的对话线索，成本则决定了你卖会员的定价空间。实测下来，大部分情况下一个中等规模的模型就能满足虚拟恋人场景，没必要追求超大参数版本，因为用户感知最明显的永远是“回话快不快、像不像人”。

2.2 跨端App方案：我选了uni-app，性价比优先

App层面，我盘过三个主流方案：Flutter、React Native、uni-app。说实话每个都能做，但个人开发者的核心诉求是不浪费任何一次重复劳动，所以我最终选了uni-app。一套代码同时出iOS和Android，还能兼顾以后做H5的需求，这对只有一个人的项目来说价值极大。

我实际开发中感受到的另一个好处是：uni-app的插件市场非常实用，聊天界面常见的消息气泡、输入框、图片表情面板都有现成方案可以改造，省掉大量重复劳动。

2.3 聊天链路：WebSocket、心跳保活与流式返回

聊天是虚拟恋人App的心脏。最基础的问题是：消息怎么在App和服务器之间实时传递？我参考了“android如何用webscoket实现聊天”这类问题后，确定了自己的方案：App通过WebSocket和我的后端保持长连接，用户每条消息都经过后端统一转发。

这样设计有三个原因。第一，WebSocket天然支持双向实时通信，用户发消息和AI回消息走同一条通道，比HTTP轮询更顺畅。第二，后端可以在中间层做上下文管理和敏感词过滤，不必让每个用户直连大模型API，这样密钥更安全、策略更统一。第三，未来如果要加“正在输入中”状态，或者多端同步聊天记录，WebSocket架构也能顺滑扩展，不必推翻重来。

这里必须提醒几个实操细节：WebSocket连接要加心跳保活机制，我用了30秒一次的ping/pong，避免移动网络下连接被静默断开；断线后要自动重连，并且原始消息不能丢，我这边是前端先存本地发送队列，收到服务端ack之后才移除；另外聊天记录建议走独立的HTTP接口做持久化，不要把历史全部塞在WebSocket连接里。

2.4 官网：它不是摆设，是产品的门脸

现在很多独立开发者的App没有官网，下载全靠应用商店。但如果你要接支付、要做品牌、要在各个渠道投放引流，官网是绕不开的。

我的官网承担了几个核心功能：产品介绍、下载引导、隐私政策和用户协议公示、用户反馈入口。技术方案上我选了最省事的路线：一个静态页面为主、带一个极轻量后台的网站。静态部分用于展示，后台用于收集用户反馈和公告管理。部署在云服务器上，配合HTTPS证书，地址就是产品名对应的.com域名。官网做好的那一天，我第一次觉得这个项目“像个正经产品”了。

3. 支付接入全记录：微信、支付宝，以及三个让人失眠的坑

3.1 先决定支付路径：App内支付还是网页拉起？

支付模块第一件事是决策：用户在哪里完成付款？App内直接拉起支付，理想情况是接入苹果App Store和安卓应用商店的IAP内购，但这对个人开发者极不友好——资质要求高、审核严、分成也高。我走的是另一条路：网页+H5支付。

具体逻辑是：用户点击“开通会员”后，App内打开一个网页，页面展示会员套餐，用户可以选择微信或支付宝扫码支付；支付成功后，后台自动给对应账号开通会员。这种方式绕开了应用商店的支付约束，也让微信和支付宝两边的接入都能走网页支付的标准流程。

3.2 JSAPI支付必须传openid：那次让人抓狂的循环跳转

微信支付里，最折磨人的就是JSAPI支付必须传openid。第一次联调时，我照着文档写了个网页授权，结果用户点了支付之后，页面在微信授权和回调地址之间来回跳，像死循环一样，抓包也只看到一串redirect。

先说结论：JSAPI支付本质上是“在微信内打开的网页”使用的支付方式，微信必须在后台知道“这个支付请求到底是谁发起的”，所以要求调用统一下单接口时传用户的openid。而这个openid必须通过微信网页授权机制获取。完整链路是这样的：

1. 用户点击“开通会员”，后端生成一个带有状态的授权跳转URL，让前端跳转到微信的网页授权地址；
2. 微信询问用户是否授权，同意后带着一个code回调到你的服务器；
3. 后端拿这个code去微信接口换access_token和openid，这个code只能用一次，有效期只有几分钟；
4. 后端拿到openid后，再调用微信支付统一下单接口，生成prepay_id，把支付参数返回给前端；
5. 前端拿到参数后，调用微信内置的JSAPI拉起支付面板，用户输密码确认；
6. 微信支付成功后，异步通知后端支付结果，后端给用户账号开通会员。

这个链路本身不复杂，但我踩了几个坑：授权回调域名和JSAPI支付目录没有配全，微信会拒绝跳转；前端拿到code之后没有及时使用，等了几秒就直接失效了；用户拒绝授权时没有做降级方案，导致一直卡在授权页。

我的解决方案是：授权回调统一由后端处理，前端只负责跳转，这样code不会在前端被浪费；同时增加一条备选支付路径——如果用户当前不在微信内置浏览器里，就直接切到Native扫码支付或支付宝支付，避免因为微信授权问题把所有用户都拦住。

以下是后端用Node.js处理网页授权换取openid的核心示意代码，逻辑不复杂，关键是流程要完整：

// 微信网页授权：用code换取openid const axios = require('axios'); async function getOpenIdByCode(code) { const url = 'https://api.weixin.qq.com/sns/oauth2/access_token'; const params = { appid: WX_APPID, secret: WX_SECRET, code, grant_type: 'authorization_code' }; const res = await axios.get(url, { params }); if (res.data.errcode) { throw new Error(`微信授权失败: ${res.data.errmsg}`); } return res.data.openid; }

拿到openid之后，再调用统一下单接口，把openid放到JSAPI支付参数里。很多第一次接触的人都会漏掉这一步，结果接口报错还不知道原因。

3.3 沙箱环境不是摆设：支付宝沙箱帮我省下真金白银

支付宝那边就顺手很多，它提供了完整的沙箱环境，不需要真实资金就能走完整个支付流程。我在开发期就是靠沙箱把签名、回调、断网重试这些链路全部跑顺的。

沙箱环境的几个要点：要用支付宝提供的沙箱App去扫码，不能用真实的支付宝App；本地配置时要正确填写应用网关、RSA2公钥和支付宝公钥；回调通知地址必须是外网可访问的地址，所以我开发时用内网穿透工具把本机服务暴露到公网，方便支付宝往本地推回调。

3.4 回调验签与订单状态机：钱到账了，订单却还挂着

支付模块里最不能偷懒的就是回调处理。微信和支付宝在支付成功后都会异步通知你的服务器，但这个通知可能重复发送多次，所以回调必须做到幂等——也就是同一笔订单的通知来了十次，最终效果也只能是一次。

我设计了一套简单的订单状态机：待支付、已支付、已发货、已关闭。用户下单后订单进入待支付；支付回调成功且验签通过后变成已支付；随后后端执行“开通会员”动作，成功后变成已发货；如果用户超时未支付，订单被主动关闭。每次回调都要先判断当前状态，不能把“已发货”的订单再发货一次。

还有一个细节：不能完全依赖回调。微信支付偶尔会延迟通知，甚至可能出现回调丢失的情况。我在后端加了一个定时任务，每五分钟扫描一遍处于“待支付”但创建超过十分钟的订单，主动向微信查询支付状态。如果查到已支付但回调没到，就直接补单。这套对账逻辑上线以后，基本消灭了“用户付了钱但会员没到账”的客诉。

4. 内容安全与“无禁词”需求：陪聊产品存活的关键

4.1 “无禁词”的本质是什么

很多用户搜索“无禁词虚拟ai聊天”“无限制聊天ai”，说明大家被平台各种莫名其妙的内容拦截搞烦了。但深入想想，用户真正想要的不是“无法无天”，而是：聊天别动不动就冷冰冰拒绝、别因为一个词就中断、别让AI像个复读机一样打官腔。

所以我在产品里对“无禁词”的理解是：在合法合规前提下，尽可能提升对话的自然度。降低AI“说教式拒绝”的频率，减少将普通词汇误判为敏感词的拦截，让用户说任何情绪、聊任何日常烦恼，AI都能提供一个平稳、温暖、有内容量的回应。

4.2 自建敏感词与模型提示词的双保险

技术层面，我做了两层过滤。第一层是自建敏感词库，覆盖常见风险类型，对用户输入和AI输出都做实时检查。命中高危词时直接拦截，命中中危词时对AI的回复风格做加权调整，不轻易打断对话。第二层是给大模型的system prompt里写清楚边界规则，告诉模型“你是陪伴型恋人，但对涉及违法、人身伤害、自残等话题要表达关心，并引导用户寻求专业帮助”。这样大多数情况下模型自己能处理边界，自建词库只负责兜底。

这两层设计合在一起的效果，是在安全性和对话自然度之间找到了一个相对舒服的平衡点。我的实测数据显示，上线头一个月，被拦截的对话比例不到千分之五，但用户并没有抱怨“太自由”或“尺度太大”，说明这个边界是合理的。

4.3 用户举报、拉黑与隐私合规不能省

虚拟恋人产品天然涉及情感话题，用户和AI之间的聊天记录非常私密。这部分我有三条底线：聊天记录加密存储、后台员工不可直接查看明文、用户可一键清空全部聊天记录。同时产品里必须有举报入口和屏蔽功能，万一AI输出引发用户不适，用户能把记录上报给我，我再针对性地调整提示词或过滤规则。

这里特别提醒独立开发者：不要在早期跳过隐私政策和用户协议。这不仅是应用商店审核的硬性要求，也是支付渠道风控会看的材料。用户一旦觉得你的产品“不正规”，差评和退款会直接砸过来。

5. 官网、上架与成本：把业余项目做成正规产品的门道

5.1 官网为什么值得认真做

很多开发者觉得官网是件可有可无的事，但我在实践里发现，官网至少有四个不可替代的作用：第一，应用商店审核时，审核员会通过官网确认你的产品主体信息和联系方式，没有官网很容易被判定为信息不完整；第二，支付渠道申请时，官网是证明你“是个正经项目”的关键凭据；第三，官网上的隐私政策和用户协议必须独立页面展示，这在合规链路里是硬性要求；第四，用户搜索产品名时，如果搜不到官网，信任感会大打折扣，而有一个信息完整的官网，付费率都会有明显改善。

5.2 域名、备案与部署

域名我注册了一个和App名一致的.com，价格不高，一年几十块。因为服务器和官网都要部署在国内节点，所以按照云服务商的要求完成了网站备案。流程比想象中简单，主要是提交资料加等待，前后大约两周。

部署方案我合并到了同一台云服务器上：官网静态页面用Nginx托管，后端API服务用Node.js进程常驻。顺手配了HTTPS证书，现在浏览器打开会有小锁标，用户付款时不会看到“不安全”的警告。这个细节对支付转化率影响很大。

5.3 软件著作权、隐私政策、用户协议

上架安卓商店和小程序类渠道时，软件著作权几乎是必备材料。我现在回头看，最后悔的就是没有早点申请软著，因为软著申请需要时间。这里可以用AI辅助整理源代码文档和操作说明书草稿，但一定要自己核对核心材料，不要为了省事交付一堆有问题的文档。

隐私政策和用户协议我参照了主流产品的写法，再结合自己产品的功能做了定制。重点说明收集哪些数据（账号信息、聊天记录）、如何处理数据（加密存储、不向第三方出售）、用户有哪些权利（删除账号、清空记录）。这些页面发布到官网并关联到App的关于页面之后，整个项目的可信度直接上了一个台阶。

5.4 开发一个带支付、带官网的App到底要花多少钱

这是经常有人问我的问题：“开发一个app并上架大概要多少钱？”市面上报价从几千到几十万都有，主要差别在功能复杂度、开发者的时间成本和资质办理。我自己这个项目的实际支出，给一个参考表：

所以如果你只算现金成本，头两个月几千块钱绝对够了。那些动辄报价几十万的，贵在人天和服务，不贵在基础设施。个人开发者最大的成本永远是你自己的时间，尤其接支付那两周，几乎每天都是下班后写到凌晨。

5.5 客服渠道：越早留越省心

上线之后必然会有人找你，可能是问会员怎么买，可能是说聊天卡顿，也可能是要退款。我提前在官网做了一个简单的反馈表单，同时留了一个专门的客服邮箱。这些事情看似琐碎，但处理不好就是差评和应用商店投诉。我把退款政策写得比较宽松，早期少量退款换口碑，整体下来比死磕拒绝退款要划算。

6. 上线运营与心态复盘：付费转化和焦虑是怎么和解的

6.1 会员定价与优先队列：让付费理由更体面

产品上线前，我反复纠结一个问题：免费用户和付费用户的区别到底是什么？如果只是“次数限制”，用户会觉得自己被卡脖子；如果全免费，我撑不住API费用。最后我参考了一个很常见的模式，就是热门AI产品高峰期排队的方式——免费用户也能正常使用所有功能，但在高峰期需要排队；订阅会员可以进入优先队列，同时拥有更长的上下文记忆和专属人设定制。

这套机制的效果出乎意料地好。用户的反馈不是“这App真抠门”，而是“免费的时候聊得挺开心，遇到一次排队之后，忍不住就想开会员了”。付费点从“不付费不能聊”变成了“付费获得更好的体验”，心理阻力小了很多。

6.2 上线前两周：数据比我想象的诚实

说实话，我一开始对盈利没抱什么期望，毕竟Virtual Lover这个赛道竞争对手不少。但上线两周的数据给了我两个意外：一是留存比预期好，次日留存稳定在30%以上，周留存也有两位数；二是花时间的不是功能开发，而是“调人设”。同一个大模型，系统提示词里人设细节写得多一点，用户对AI的评价就完全不一样。

我花了很多个晚上看用户聊天日志（脱敏之后），发现用户最关心的不是模型多大、参数多强，而是三件事：回话快不快、有没有记得住之前聊过的话题、以及说话像不像一个“真实的人”。这些反馈直接影响了我后续的迭代方向，也让我意识到，一个技术上不算炫酷、但体验上足够温暖的产品，也能有真实的付费意愿。

6.3 迷茫期做产品教会我的事

回看这几个月，这个项目的意义已经不只是一个App。迷茫焦虑的根源是失控感，而做产品恰恰是一个把失控感一点点收拢回来的过程。当我发现网站的访问量在涨，支付回调里出现第一笔真实收入，用户在反馈里说“谢谢你做了这个产品”的时候，那种“自己在做一件具体的事”的踏实感，比任何鸡汤都管用。

我也理解了一个道理：大多数业余项目死掉，不是死在技术上，而是死在“永远在准备、永远不上线”。把支付接上、把官网上线、把App推到应用商店，这些动作本身就是一种治疗。你不用准备到完美才能出发，做一个带支付带官网的小产品，哪怕只有一百个用户，也意味着你真正完成了一个从想法到交易的闭环——这个闭环会推着你往下走，而不是让焦虑把你留在原地。