夜雨聆风第一步是AI模型能力选型。
做一个什么样的产品，会推动着去找什么样的模型。
如何去找一个产品的大概方向，可以考虑从应用商店中竞品的付费排名，应用榜单排名观察，总体上有一个大概的脉络。结合在应用商店中的付费订阅数，商店评价，对于判断这个方向的产品值不值得做，会有一个基本的结论。
把这些值得做的产品列出来，然后做一个排名，综合产品和技术实现复杂度、优先级、市场前景等维度，有一个价值的初步评估。
总体评价可以借助于AI模型ChatGpt，分析给出一个合理的推荐参考。TOP5 或者TOP3的产品，圈出来作为后续优先考虑去实现的产品方向。
在产品的方向以及细分领域确定之后，那么就可以从几个方面去进行下一步。
分析现有对标竞品的技术实现、产品呈现、定价策略、商店评价，做一个初步的摸底和尽调。
确定具体的技术方案实现，包括但不限于合理范围的逆向分析和研究、AI实现的架子等。
是否市面上有相同能力的 AI 模型、或者就是同竞品的商用AI模型方案，查看相关技术文档，确定对接或者实现复杂度。
经历过一些淘汰或者筛选，我们能大致确定最终对标产品所需要的AI模型。
对于出海业务来说，需要额外考虑AI模型是否支持海外独立部署，这里面涉及到商店里的出海合规等问题。
第二步是产品定价。
结合业务调用AI模型需要消耗的 token 量级和 AI模型的输入/输出价格，核算出一个单用户实际的消耗成本，设计合理的订阅价格，最后计算出一个大致的单用户价值。
单用户的ROI，对应着订阅所能带来的收益占比，初步考虑较高毛利作为高优先级，比如说 50% 以上。筛选下来，最好确定1~2个可用的AI 模型作为备选。以便产品业务上能在复杂的网络场景或者全球业务覆盖上，能够有效的去切换或者兜底。
第三步是考虑后台系统设计。
主要是管理系统设计，AI的产品的后台管理设计，可以短平快，技术储备够当然也可以考虑设计上尽可能满足后续的AI应用矩阵，能够快速有效的去切换方向，快速试错，以拥抱AI模型的整个大的迭代周期。
那么笔者选择的是后一种，设计一个能适配AI 矩阵的后台管理系统。
对于一个可落地的AI类应用，作用是包装AI模型去实现业务和一些具体的能力，然后UI上呈现，比如说用户需要借助AI模型去编辑和美化图片，那么这个时候AI修图APP可能仅仅就只是包装调用了一个商用 AI 修图的模型而已。
AI模型接入了APP之后，能够去有效去处理用户的输入，比如拍照或者选择相册照片，最后通过AI模型调用，然后产出结果呈现给用户。
这个简单的场景就基本囊括了一个通用的AI 应用的开发范式。
抽象出来就是，一个UI的呈现，用户操作UI上的某些元素，然后发起一个后台的接口调用，后台接口根据用户具体的行为，去挑选对应能力的AI模型。
这里调用AI模型，需要在AI模型的后台去新增对应的模型Key，而这个模型key，我们可以在后台管理页面维护一个可用的模型Key 池子，以便满足众多普通用户各种量大和复杂的 AI 请求，并始终保持一个稳定可用的状态。
后台系统通过key去调用对应的AI大模型，商用AI大模型会返回对应的输出，后台系统通过结构化输出返回客户端想要的数据结构，最终呈现结果给用户，完成一个AI业务调用的闭环。
所以描述下来这个流程所涉及的后台管理功能主要有以下几点。
AI模型Key维护，在产品用户数不断增长的过程中，尽量的去维护和满足需求的模型key池，后台能查询和管理，以及定期做一定的key 的健康检查，比如是否过期失效，是否账户欠费状态。
产品的订阅，这是最核心的一点。用户发起AI模型的调用，需要为这次的行为付出相应的价格，这个价格对应着后台管理系统的整套订阅。
用户在发起AI请求的时候，我们会看他是否有订阅、是否在试用状态，如果没有订阅并且也不能试用，会进行一定拦截，让用户去订阅。
当用户发起一个订阅之后，整个后台系统会产生很多功能的细节。
发起订阅前会出现一个付费墙，这个付费墙包括系统返回的套餐，常规来说是包括月付、季付、年付套餐，每个套餐对应着一个订阅，用户勾选套餐后会发起订阅。
管理系统返回展示到APP上的付费墙设计一般分为两种情况。
应用商店的订阅。
这里面分为Google平台和Apple平台。每个平台的订阅流程虽然大体相同，但整个的技术细节，每个平台有个性化的差异，后台系统需要做一定的平台适配，统一抽象成一个标准的订阅模型。
一般一个标准的商店订阅模型，以 Google 平台为例，主要包含订阅的ID、订阅计划、订阅价格。其中Apple Store和Google Play的订阅价格自动考虑了全球的汇率问题，不同国家对应不同的价格。我们只需要在应用商店的管理后台创建一个订阅和多个订阅计划，一旦创建之后一般不太会轻易改变。
日常操作更多的是订阅的维护，自身系统后台去抹平不同平台的差异，实现一个订阅数据的维护，负责从不同的应用商店后台拿取实时的订阅数据。
在展示套餐的时候，我们可以给自己不同的APP分配不同的订阅套餐数据。后台系统除了处理应用商店的订阅计划套餐外，如果业务上有必要，还需要去处理除了应用商店之外的，业内主要是自己官方H5上的订阅套餐。
官方H5 的订阅。
区别于应用商店的订阅套餐，官方自己的套餐价格更复杂，不同的国家需要考虑不同的汇率，这个价格存在一定的变化，而应用商店的整个订阅价格是不需要开发者过多关心的，它能在不同分发渠道、不同国家动态实时显示当前的订阅价格。
为了尽快实现上架和产品的MVP流程，官方H5渠道笔者暂不考虑。业内一般业务涵盖官方H5 的初衷是在有用户基础的情况下，提高订阅收入，应用商店提供流量入口和便捷的订阅会拿走30% 的订阅收入，而官方渠道订阅收入能 100% 进兜。
介绍完订阅的分类，我们开始深入订阅后的流程，下面以Google 应用商店订阅为例展开。
用户发起订阅后，首先会下单，系统收到下单请求后，创建用户的初步订单数据，然后返回下单结果。客户端 App收到下单成功后，会继续向应用商店发起订阅支付请求，用户通过已绑定的应用商店支付方式发起支付，支付成功后，应用商店订阅成功后返回结果给客户端 App，App调用平台支付确认接口后续通知系统侧已订阅，这个时候系统能直接更新刚才创建的订单，改用户订单状态为已订阅吗？
不推荐，因为不保险。做过支付的朋友应该知道，支付平台一般在核实支付到账后会通知平台上配置的回调地址通知进入方做二次检验，因为客户端永不可信，有串改可能。
应用商店也有这一套流程，核实到订阅成功并且已支付后会通知接入方。收到回调后，我们的系统再更新用户订单状态为已订阅。
背后这一套流程对于用户来说是无感的，前面用户发起订阅并支付成功后，会前置收到支付成功提示或者支付失败提示。用户只会关心我为啥支付失败，或者支付成功后平台是否为已订阅态或者会员状态，进而开始 AI App 上后续顺利操作，比如修图。
转回到系统设计，有了用户的订阅下单数据，我们的系统需要关心前面提到涉及的三个方面
未支付成功，需要排查用户是在应用商店订阅支付失败的原因，这个可以通过端侧的埋点上报，或者调用系统接口。省事一点，埋点就够了。
下单失败，需要排查系统内部原因，比如系统宕机、数据表操作异常等。
订阅成功了，用户的订阅态和对应订单要有记录，好方便排查和后续的用户权益配额或发放。
讲到这儿，我们已经基本覆盖了AI应用前期的主要几个方面，剩下来就是权益设计、抵扣规则设计和成本核算、订阅到期/续订/取消、用户登录。
我们下次再讲。
