支持 应用广场 预设市场及开放模型接入市场

[bmwa0813]

1、应用功能（即目前的预设设置）
应用广场：支持用户上下架、后台审核
应用创建：包含标题、头像、标签、简介、说明（点击后在对话页面展示的说明文本）、预设(参照playground，前置语后置语)、是否公开
（另：预设内容建议隐藏，当前为公开）
2、stt
3、ai群聊
等等......
不知道是否会向此方向开发，毕竟目前市面其他商业版或开源已经有很多功能非常完善的项目

[zmh-program]

1. 前已经被列入 商业版 Todo 中。
   类似于 Poe 的模型市场，当前可支持两种方式：

• 预设市场，可选是否隐藏预设，可选是否计费及收费方式（一次性，按次计费，按 Token 计费等），后台可选百度等文本审核方式。
• 模型 API，可以定义好格式后 向外调用 API，可选收费方式。
  如果设置为计费，开发者可以通过预设/模型赚取一定收入。

2. stt 我认为当前系统输入法的语音转文字已经能胜任许多地方（拿华为输入法举例），不会去首先列入 Todo 实现。 TTS 倒是会首先计划先实现。
3. ai 群聊？im 群聊我认为是否过于臃肿 对于一个追求轻量化的项目来说，没有时间也没有考虑必要去实现，不会去过多考虑发展架设对于分布式 IM 即时消息架构设计，但是用户可以通过中转 / Nio API 进行调用对接现有的开源项目丰富的 QQ / Discord / TG 等 Bot 。

[bmwa0813]

1. 预设的开发者可从其他使用者手中赚取积分是非常好的构想，但如何与订阅体系更好的相结合需要设计完善的规则，应首先建立清晰的订阅体系。我有如下建议仅供参考：

• 订阅体系：包括模型包月、季、年与不限时的token资源包即可（个人认为推出按次付费的资源包似乎没有必要，站在运营者角度而言单次对话成本不好控制，用户也会认为1次使用就需要几毛钱，过于准确直观，不利于转化。例如昂贵的4.0模型和今后新的模型，按次付费则必然需限制其性能。当然此功能可以保留，由运营者自行决定如何设置）
• 应用收费方式：可包括“一次性收费”、“按使用付费”，其中“按使用付费”与下文用户的“订阅套餐日价值”和“流量包token价值”挂钩，持续产生收益（可增加使用权限，与订阅等级绑定，免费用户不可使用）
• 开发者收益来源：用户当日消耗于其付费应用的付费额度价值（应区分免费额度，并建议与订阅套餐的日价值或购买的流量包token价值挂钩），其价值的10%（某个比例）对应的积分返于预设开发者。
• 开发者主页，可见其全部作品
• 应用广场榜单、筛选功能（作者、作品名、标签）

2. 没错是TTS，最好可以支持使用自己训练的语音模型，模型使用权与订阅等级绑定

[zmh-program]

1. 按照你的思路来说有一定正确性，除此之外，但是按次 如 Midjourney, DALLE，Plus 逆向模型等模型也是存在的。我可以考虑设置资源包计费方式，如涵盖 Token 资源包, 次数配额资源包。不过 Token 资源包会有一定的架构冲突，上线有可能需要更长时间。

“按使用付费”与下文用户的“订阅套餐日价值”和“流量包token价值”挂钩是一个很不错的主意，我也曾思考过，但是如何避免刷使用量是一个值得长久思考的问题，目前分成两种思路我认为都不是理想方案：

• 即时结算，假设按价值的某个比例来说，如果使用一次就给开发者返回积分，比如 千分之0.1，每次一个用户用一次就给予 0.03 积分，如何避免刷使用量是个值得考究的问题（比如说我就用这个预设去免费模型请求了几十万次 这个开发者有可能就能获利远超于订阅的价格的问题，即所谓刷单。如果设置最大积分返现（比如一个用户的订阅统计已经返现超过10%比例后的返现将会为0，有可能对后面的开发者来讲 后续使用的预设或者模型 返现是没有的 这也是不理想的情况 而且这样数据库判定也比较难实现）。
• 按照一天的权重划分，每日结算，比如说这个A预设一个用户用了20次，B预设用了10次，我可以按照10%比例根据权重给予A预设开发者0.2积分，B预设开发者0.1积分，这样实现起来也是比较庞大而且容易出更多的“不可预料代码情况” 也容易出架构臃肿的设计，比如存储何处是个值得考虑的问题，如果存到数据库，占用存储大小需要考虑以及定期的数据清理和性能负载，包括每日结算的 worker 什么时候触发并如何计算等是一个非常需要构思的问题，如果存到缓存，需要考虑如果在分布式 / 高并发的情况下如何加锁防止多次同时请求或者多次同时触发带来的严重的更新异常问题）

我暂时没有更好的思路去解决这个问题，也欢迎提出更好的解决思路。

2. 可以。后台可以设置每次使用就根据字符扣费 / 按次计费（缓存不扣费） / 不计费。渠道设置里面已有成熟的相关的用户组分配可以实现用户组挂钩进行更多设置。

[bmwa0813]

只有用户购买了“TOKEN流量包”，才会存在“按次”调用预设消耗的token价值来实时结算，订阅套餐用户只存在日结算（需统计当日该用户各预设使用比例后，才能分配）。因此建议统一日结算。

1、根据我的设想来实现准确分佣的前提是，需要标注用户每次对话所使用的模型类型（免费/付费）、预设类型（系统/user分享）、调用该模型所使用的权限（订阅、流量包、免费token，同时token扣费顺序依次为订阅包月套餐（此时不扣token）-购买流量包Token（付费token扣除完毕后可取消用户拥有付费token的状态，方便结算判定）-赠送Token）。
2、结算规则如下：

• 统计当日各用户调用“user分享预设”并使用“付费模型”的总次数，取该订阅用户的“订阅套餐日价值”的10%（某个比例），再分别根据各预设调用次数占当日该用户调用预设总次数的比例，分别为各预设开发者分佣积分（例：该用户订阅套餐日价值为1元，则0.1元为其当日总分配额度，其当日调用A预设90次，B预设10次，则A获0.09元、B获0.01元）
• 统计当日各用户调用“user分享预设”并消耗流量包Token的总额度，取其Token价值的10%（Token的价值可自定义，可参照流量包价值，无需区分输入输出或模型名称），并同上进行分配。

至于如何实现，我咨询了下gpt仅供参考😂

[zmh-program]

统计当日各用户调用“user分享预设”并使用“付费模型”的总次数

这是一个好思路，不过需要统计的数据比较庞大，之后如果有时间可以往这方面发展。