R-1592​

京东零售价格治理部

用户、商家

利益/补偿与承诺规则

电商“价格保护”自动赔付模型

用户购买商品后，在承诺的价格保护期（如7天、30天）内，若同一商品（同SKU）在京东平台发生降价，系统自动计算差价并返还至用户支付账户。

京东价保自动赔付模型

提升用户购物信心和满意度，减少因价格波动引发的客诉，践行“低价”承诺。

1. 价保期限以订单完成时间为起点计算。
2. 仅适用于自营及部分参与活动的第三方商品。
3. 降价需为直接降价，不含优惠券、满减等间接降价。
4. 用户需未使用该商品发起退货。

输入：用户订单Order、商品当前售价P_current、价保期限T_guarantee、商品SKU。
输出：价保触发状态Trigger、返还金额Refund。
流程：1. 系统每日/实时扫描在价保期内的订单。
2. 获取订单中商品的原购买价格P_original和当前售价P_current。
3. 比较价格：若P_current < P_original，则触发价保。
4. 计算差价：Refund = P_original - P_current。
5. 自动发起退款流程，将Refund返还至用户原支付账户。

中

设用户订单中商品的原购买价格为P_orig，当前售价为P_curr。
价保触发条件：Trigger = (P_curr < P_orig) ∧ (Current_Time - Order_Time ≤ T_guarantee)。
返还金额：Refund = max(0， P_orig - P_curr)。
实际中，Refund = P_orig - P_curr，因为触发条件已保证P_orig > P_curr。

常量：价保期限T_guarantee。
变量：原价P_orig，现价P_curr，订单时间Order_Time，当前时间Current_Time，触发状态Trigger，返还金额Refund。

比较，减法，最大值函数，逻辑与。

1. 用户订单表（订单号、SKU、购买价、下单时间）。
2. 商品价格历史表（SKU、价格、生效时间）。
3. 价保规则配置表（商品类目、价保天数）。
4. 价保赔付记录表。

价格保护，自动退款，价保期限，电商。

1. 数据获取：系统扫描到订单O123（SKU: ABC， P_orig=100元， Order_Time=2025-01-01 10:00）。当前时间Current_Time=2025-01-05 15:00，价保期限T=7天。
2. 时效检查：时间差Δt = 4.2天 < 7天，在价保期内。
3. 价格查询：查询SKU ABC的当前售价P_curr=90元。
4. 价格比较：90 < 100，触发价保。
5. 计算差价：Refund = 100 - 90 = 10元。
6. 执行退款：向用户支付账户返还10元，并发送价保成功通知。

R-1593​

阿里巴巴搜索推荐事业部

商家、用户

资源/排序与质量规则

淘宝/天猫“商品搜索排序”综合质量分模型

商品在淘宝搜索结果的排名由“商品质量分”、“商家服务分”、“人气分”等多个维度的得分加权求和决定。质量分包括标题、图片、详情页质量；服务分包括DSR、退款率；人气分包括销量、收藏、转化率。

淘宝商品搜索综合质量分模型

将流量优先分配给商品质量高、服务好、受用户欢迎的商品和商家，提升平台整体交易效率和用户体验。

1. 各维度权重动态调整，不对外公开。
2. 数据统计有周期（如近30天）。
3. 存在反作弊机制，剔除刷单等虚假数据。
4. 个性化搜索下，用户画像也会影响排序。

输入：商品质量特征X_quality、商家服务特征X_service、商品人气特征X_popularity、各维度权重W_quality， W_service， W_popularity。
输出：商品综合质量分Score_total、搜索排序位置Rank。
流程：1. 分别计算商品质量分S_q = f_quality(X_quality)、商家服务分S_s = f_service(X_service)、商品人气分S_p = f_popularity(X_popularity)。
2. 加权求和：Score_total = W_q * S_q + W_s * S_s + W_p * S_p。
3. 对所有符合搜索关键词的商品按Score_total降序排序，得到Rank。
4. 结合个性化因子，对排序进行微调。

高

设商品i的质量分、服务分、人气分分别为S_q_i， S_s_i， S_p_i，对应权重为w_q， w_s， w_p，满足w_q + w_s + w_p = 1。
综合质量分：TS_i = w_q * S_q_i + w_s * S_s_i + w_p * S_p_i。
搜索排序：按TS_i降序排列，Rank_i越小表示排名越靠前。
个性化场景下，用户u对商品i的最终得分可能为：Final_Score_{u，i} = TS_i * Sim(u， i)，其中Sim为用户u与商品i的匹配度。

常量：各维度权重w_q， w_s， w_p。
变量：商品质量分S_q_i，商家服务分S_s_i，商品人气分S_p_i，综合质量分TS_i，排序Rank_i。
函数：各维度得分计算函数f_quality， f_service， f_popularity。

加权求和，降序排序。

1. 商品信息表（标题、图片、详情页）。
2. 商家服务数据（DSR评分、退款率、纠纷率）。
3. 商品行为数据（销量、收藏量、点击率、转化率）。
4. 搜索排序日志与权重配置表。

搜索排序，商品质量分，商家服务分，人气分，淘宝搜索。

1. 特征计算：对于商品A，系统计算：
- 商品质量分S_q：基于AI对标题、主图、详情页的评估，得分85。
- 商家服务分S_s：基于近30天DSR（4.8）、退款率（2%），得分90。
- 商品人气分S_p：基于近7天销量（1000件）、收藏增长率（5%），得分80。
2. 加权求和：当前权重配置w_q=0.4， w_s=0.3， w_p=0.3。TS_A = 0.4 * 85 + 0.3 * 90 + 0.3 * 80 = 34 + 27 + 24 = 85。
3. 排序：对于搜索词“连衣裙”，计算所有相关商品的TS。假设商品B的TS_B=82，商品C的TS_C=88。则排序为：C(1)， A(2)， B(3)。
4. 个性化调整：若用户是年轻女性，可能对款式新的商品A有偏好，Sim(A)=1.1，则Final_Score_A = 85 * 1.1 = 93.5，可能超过C的88，使A排名第一。

R-1594​

字节跳动抖音推荐算法部

用户、内容创作者

资源/分配与兴趣规则

抖音“短视频推荐”多目标融合排序模型

抖音信息流中视频的排序由多个目标共同决定：点击率（CTR）、完播率、互动率（点赞、评论、分享）、用户兴趣匹配度、作者生态健康度（如新作者扶持）。通过多任务学习模型预测各目标，再加权融合得到最终排序分。

抖音短视频多目标融合推荐模型

最大化用户满意度和停留时长，同时平衡内容多样性、作者成长和平台生态健康。

1. 模型实时更新，响应最新用户反馈。
2. 存在去重机制，避免同一内容反复出现。
3. 冷启动问题：对新视频和新用户有特殊处理。
4. 内容安全审核是前置条件。

输入：用户特征U、视频特征V、上下文特征C、多目标预测模型M、融合权重W。
输出：视频对各目标的预测值[y_CTR， y_play， y_like， ...]、融合总分Score_fused、推荐列表RankList。
流程：1. 召回：从海量视频中快速筛选出千级别候选集。
2. 粗排：用轻量模型对候选集初步打分，筛选出百级别。
3. 精排：将用户、视频、上下文特征输入多任务深度学习模型M，预测CTR、完播率、互动率等多个目标y_i。
4. 融合排序：Score_fused = Σ(w_i * y_i)，按此分排序。
5. 重排：考虑多样性、打散、运营策略等，生成最终推荐列表。

极高

设精排阶段有k个排序目标，对于用户u和视频v，模型预测的目标值为向量y_{u，v} = [y_1， y_2， ...， y_k]。
融合权重向量为w = [w_1， w_2， ...， w_k]。
融合得分：S_{u，v} = w · y_{u，v} = Σ_{i=1}^{k} w_i * y_i。
模型M通常是一个共享底层网络，上层有多个塔（Tower）分别预测不同目标的神经网络，损失函数为各任务损失的加权和。

常量：融合权重w_i，模型参数θ。
变量：用户特征U，视频特征V，上下文C，目标预测值y_i，融合得分S。
向量/矩阵：特征向量，预测向量，权重向量。

向量点积，加权求和，深度学习。

1. 用户画像数据（兴趣标签、历史行为）。
2. 视频内容数据（视觉、音频、文本特征）。
3. 实时交互日志（曝光、点击、播放进度、互动）。
4. 多任务模型参数与权重配置。
5. 推荐结果与用户反馈日志。

推荐系统，多任务学习，CTR预估，完播率，抖音算法。

1. 召回与粗排：用户U浏览抖音，系统从亿级视频池中通过协同过滤、兴趣标签匹配等方式召回1000个候选视频，再经粗排模型筛选出200个。
2. 精排预测：对于候选视频V1，提取用户特征（男，25岁，喜欢科技）、视频特征（科技类，时长15s）、上下文（晚上8点）。输入多任务模型M，输出预测值：y_CTR=0.08， y_play_completion=0.6， y_like=0.05， y_share=0.02。
3. 融合打分：当前融合权重w=[0.4， 0.3， 0.2， 0.1]。S = 0.4 * 0.08 + 0.3 * 0.6 + 0.2 * 0.05 + 0.1 * 0.02 = 0.032 + 0.18 + 0.01 + 0.002 = 0.224。
4. 排序与重排：计算所有200个候选视频的S，降序排列。前10名中，如果科技类视频过多，重排模块会插入一些其他类别（如搞笑）以保持多样性，最终生成10条视频的推荐列表。

R-1595​

小红书社区生态部

用户、博主、品牌方

资源/分配与内容规则

小红书“笔记流量分配”的“赛马机制”与“社区价值观”加权模型

新发布的笔记会先进入一个小流量池进行“赛马”，根据其在小流量池中的互动率（点赞、收藏、评论）、完读率等数据，决定是否进入更大的流量池。同时，笔记内容是否符合社区价值观（正能量、真实分享）也会通过模型评估，影响流量分配。

小红书笔记流量赛马与价值观加权模型

高效筛选出优质、受欢迎且符合社区调性的内容，激励创作者生产有价值笔记，维护社区氛围。

1. 赛马机制有多个流量阶梯。
2. 互动率指标需去水军、刷量。
3. 价值观评估模型基于文本、图像和多模态内容理解。
4. 不同垂类（美妆、旅行）的基准互动率可能不同。

输入：笔记内容Content、发布后初始曝光量N_imp0、初始互动数据Engage0（点赞L0、收藏C0、评论R0）、价值观评分V_score。
输出：笔记质量分Q_score、是否晋级下一流量池Promote、下一阶段分配流量N_imp_next。
流程：1. 笔记发布后，系统分配初始曝光（如500次）。
2. 监测初始曝光下的互动率：CTR0 = (L0+C0+R0)/N_imp0。
3. 计算笔记质量分：Q_score = α * CTR0 + β * V_score。
4. 若Q_score超过当前流量池的晋级阈值T，则笔记晋级，获得更大曝光（如5000次）。
5. 重复此过程，可能晋级多轮。

高

设笔记在某个流量池k中获得的曝光量为I_k，产生的有效互动数（点赞、收藏、评论之和）为E_k。
互动率：r_k = E_k / I_k。
设社区价值观模型给出的评分为V ∈ [0， 1]。
笔记综合质量分：Q_k = γ * r_k + (1-γ) * V，其中γ是权衡系数。
晋级条件：若Q_k ≥ T_k，则笔记晋级到流量池k+1，获得曝光量I_{k+1} = m * I_k（m为放大系数）。
若Q_k < T_k，则停止推荐，流量分配结束。

常量：初始曝光I_0，晋级阈值T_k，放大系数m，权重系数γ。
变量：当前曝光I_k，互动数E_k，互动率r_k，价值观分V，质量分Q_k，晋级状态Promote。

比率计算，加权求和，阈值比较。

1. 笔记内容表（ID、文本、图片、发布者、类目）。
2. 笔记曝光与互动日志（笔记ID、用户ID、曝光时间、是否点赞/收藏/评论）。
3. 社区价值观模型评分记录。
4. 流量池晋级规则配置表（阈值、放大系数）。

流量分配，赛马机制，社区价值观，内容推荐，小红书。

1. 初始曝光：一篇美妆教程笔记发布，系统分配I_0=500次曝光。
2. 数据监测：在500次曝光下，获得点赞L=30，收藏C=50，评论R=10，总互动E=90。互动率r_0 = 90/500 = 0.18。
3. 价值观评分：内容审核模型判断笔记为真实分享，无违规，V=0.9。
4. 质量分计算：γ=0.7，Q_0 = 0.7 * 0.18 + 0.3 * 0.9 = 0.126 + 0.27 = 0.396。
5. 晋级判断：第一级流量池的晋级阈值T_0=0.35。Q_0=0.396 ≥ 0.35，晋级。
6. 二次曝光：进入第二流量池，获得I_1 = m * I_0 = 10 * 500 = 5000次曝光。重复上述过程，决定是否进入万级、百万级流量池。

R-1596​

B站社区运营部

用户、UP主

激励/等级与权限规则

B站“会员等级”经验值增长与“硬币”激励模型

B站用户通过登录、观看视频、投币、分享等行为获得经验值，经验值累积提升会员等级（Lv0-Lv6）。高等级拥有更多权限（如发彩色弹幕、参与抽奖）。“硬币”是另一种激励代币，用户可通过每日登录获得，并投给喜欢的UP主，UP主可将硬币兑换为收益。

B站会员经验值与硬币激励模型

增加用户粘性和活跃度，构建社区荣誉体系，同时通过硬币机制激励UP主创作优质内容。

1. 每日经验值有获取上限。
2. 不同行为获得经验值不同（如投币经验值高）。
3. 硬币每日登录获得1枚，上限为2枚。
4. 硬币投出后无法收回，UP主硬币提现有比例和条件。

输入：用户每日行为列表ActionList（登录、观看、投币、分享等）、当前等级Lv、当前经验Exp_current、当前硬币数Coin_current。
输出：今日获得经验值ΔExp、今日获得硬币ΔCoin、更新后等级Lv_new、更新后经验Exp_new。
流程：1. 每日零点重置，用户登录获得基础经验（如5点）和1枚硬币（若未满2枚）。
2. 记录用户行为，根据行为经验值表累加ΔExp，但不超过每日上限（如50点）。
3. 更新经验：Exp_new = Exp_current + ΔExp。
4. 检查等级升级：若Exp_new ≥ Exp_required(Lv+1)，则Lv_new = Lv+1。
5. 硬币数更新：Coin_new = min(Coin_current + ΔCoin， 2)（持有上限）。

中

设用户u在日期d的行为集合为A_d。每种行为a对应经验值奖励e_a。
日经验获取：ΔExp_d = min( Σ_{a∈A_d} e_a， E_max )，其中E_max为每日经验上限。
累计经验：Exp_total = Σ_{d} ΔExp_d。
等级函数：Lv = f(Exp_total)，其中f是分段函数，当Exp_total ∈ [E_{Lv}， E_{Lv+1})时，等级为Lv，E_{Lv}为等级Lv所需的最低经验。
硬币模型：每日登录奖励1枚，持有上限C_max=2。Coin_{d} = min(Coin_{d-1} + 1_{login}， C_max)。

常量：行为经验值映射e_a，每日经验上限E_max，等级经验阈值E_{Lv}，硬币持有上限C_max。
变量：日行为集合A_d，日经验ΔExp_d，总经验Exp_total，等级Lv，硬币数Coin。
函数：等级函数f。

求和，最小值函数，分段函数。

1. 用户行为日志（用户ID、行为类型、时间）。
2. 行为经验值配置表。
3. 用户等级与经验账户表。
4. 用户硬币账户与流水记录。

会员等级，经验值，硬币，社区激励，B站。

1. 行为记录：用户U在2025-01-01完成：登录（e1=5）、观看视频超过5分钟（e2=5）、投币1枚（e3=10）、分享视频（e4=5）。
2. 计算日经验：Σe_a = 5+5+10+5 = 25。当日经验上限E_max=50，25<50，所以ΔExp=25。
3. 更新经验：原经验Exp=120，Exp_new=120+25=145。
4. 检查升级：查表知，Lv2需要经验100，Lv3需要200。145 ∈ [100，200)，因此等级仍为Lv2，Lv_new=2。
5. 硬币更新：昨日硬币Coin=1，今日登录奖励1枚，Coin_new = min(1+1， 2) = 2枚。

R-1597​

携程酒店业务部

酒店商家、用户

资源/排序与竞价规则

携程酒店“列表排序”的“综合排序分”与“竞价排名”混合模型

酒店在携程搜索结果的排序由“综合排序分”决定，该分数基于酒店销量、用户评分、地理位置、价格竞争力等。同时，酒店可购买“竞价排名”服务，通过设置关键词出价，获得额外的排序加权，提升排名。

携程酒店综合排序与竞价排名混合模型

平衡酒店自然质量与商业推广需求，为用户提供优质且符合其偏好的酒店选择，同时提升平台广告收入。

1. 综合排序算法因子不公开。
2. 竞价排名广告有明确标识（如“广告”）。
3. 出价按点击付费（CPC）。
4. 广告位数量有限。

输入：酒店综合排序分S_organic、酒店广告出价Bid、广告质量度Q（预估CTR）、广告权重系数α。
输出：酒店最终排序分S_total、广告实际扣费CPC。
流程：1. 计算酒店i的综合排序分S_i_organic，基于近30天销量、评分、距离市中心距离、价格等。
2. 若酒店i参与竞价排名，则计算广告贡献分S_i_ads = Bid_i * Q_i。
3. 最终排序分S_i_total = S_i_organic + α * S_i_ads。
4. 按S_i_total降序排序，得到列表。
5. 当用户点击广告位酒店时，按GSP规则计算实际扣费CPC_i。

高

设酒店i的综合排序分为O_i。
其广告出价为B_i，广告质量度（预估点击率）为Q_i。
广告贡献分：A_i = B_i * Q_i。
最终排序分：S_i = O_i + λ * A_i，其中λ为广告权重系数。
实际点击扣费（CPC）：采用广义第二价格拍卖，酒店i的实际扣费为：
CPC_i = (B_{i+1} * Q_{i+1}) / Q_i + ε，B_{i+1}和Q_{i+1}是排名下一位酒店的出价和质量度。

常量：广告权重系数λ，最小扣费单位ε。
变量：酒店综合分O_i，广告出价B_i，质量度Q_i，广告贡献A_i，最终排序分S_i，实际扣费CPC_i。

加权求和，乘法，广义第二价格拍卖。

1. 酒店经营数据（销量、评分、价格、位置）。
2. 用户搜索与点击行为日志。
3. 酒店竞价排名出价记录（关键词、出价）。
4. 广告质量度预估模型。
5. 酒店列表排序与扣费记录。

酒店排序，综合排序分，竞价排名，CPC，携程。

1. 计算综合排序分：对于搜索“上海外滩酒店”，酒店A的销量1000间夜，评分4.8，距离外滩0.5km，价格800元。通过模型计算得O_A=92分。
2. 计算广告贡献：酒店A对关键词“外滩酒店”出价B_A=2.5元，其广告历史CTRQ_A=3%。A_A = 2.5 * 0.03 = 0.075。设λ=100，则广告加权分=7.5。
3. 最终得分：S_A = 92 + 7.5 = 99.5分。
4. 竞争对手：酒店B综合分O_B=95，未投广告，S_B=95分。因此A排名第一，B第二。
5. 扣费计算：用户点击A的广告，A的实际扣费基于B（下一位）的数据。假设B未投广告，则B_{i+1}为系统默认底价（如0.5元），Q_{i+1}为平均CTR（如2%）。则CPC_A = (0.5 * 0.02)/0.03 + 0.01 ≈ 0.333 + 0.01 = 0.34元。

R-1598​

拼多多用户增长部

用户、用户

激励/裂变与分享规则

拼多多“砍价免费拿”助力模型与成功率控制

用户发起“砍价免费拿”活动，需邀请好友助力砍价。每次助力砍掉的金额是随机的，但总需助力次数和成功率由后台模型控制。模型根据用户价值、商品成本、活动目标动态调整砍价难度，确保平台总体成本可控。

拼多多砍价助力随机模型与成本控制

以低成本实现用户裂变和拉新，提升APP活跃度和用户粘性，同时将营销费用控制在预算内。

1. 砍价金额随机，但概率分布受控。
2. 新用户助力效果通常大于老用户。
3. 活动有时间限制（如24小时）。
4. 同一好友对同一活动仅能助力一次。

输入：商品价格P、用户价值U_value、活动预算Budget、已邀请好友列表FriendList、助力次数N_help。
输出：单次助力砍掉金额ΔCut、剩余金额P_remaining、预计还需助力次数N_need。
流程：1. 用户发起砍价，系统设定目标砍掉总金额P_target = P（即免费）。初始剩余金额P_rem = P。
2. 好友点击助力链接，系统根据模型计算本次砍掉金额ΔCut。模型会参考：助力者是否新用户、发起者用户价值、当前剩余金额等。
3. 更新：P_rem = P_rem - ΔCut。
4. 显示剩余金额和进度。
5. 当P_rem ≤ 0时，砍价成功，用户获得商品。

中高

设商品价格为P，当前剩余金额为R。
对于第k次助力，砍掉金额Δ_k是一个随机变量，但其期望E[Δ_k]由模型控制。
模型：E[Δ_k] = f(R， U_value， IsNewUser)，其中f是一个函数，通常设计为：
- 初始几次助力Δ较大，吸引用户。
- 中间阶段Δ很小，需要大量助力。
- 最后阶段Δ可能变大，帮助用户完成。
总助力次数N也是一个随机变量，其期望E[N]被控制，使得总期望成本E[ΣΔ_k] = P，但实际分布被设计为只有部分用户能成功。

常量：商品价格P，预算系数β。
变量：剩余金额R，助力次数k，单次砍价额Δ_k，用户价值U_value，助力者是否新用户IsNew。
函数：期望砍价函数f。

随机变量，期望控制，动态调整。

1. 砍价活动配置表（商品ID、价格、活动时间）。
2. 用户助力行为日志（发起者、助力者、砍掉金额、时间）。
3. 用户画像数据（新老用户、历史消费）。
4. 砍价成功与失败记录。

社交裂变，砍价，助力，随机模型，成本控制，拼多多。

1. 活动发起：用户A发起1000元手机的砍价。R=1000。
2. 首次助力：好友B（老用户）助力，系统根据模型计算Δ1=50元（较大，吸引）。R=950。
3. 后续助力：C、D、E（均为老用户）助力，Δ2=0.5，Δ3=0.3，Δ4=0.2元（金额骤降）。R≈949。
4. 新用户助力：好友F为新用户，助力Δ5=20元（鼓励拉新）。R=929。
5. 进度控制：系统后台模型根据A的用户价值（高价值用户可能更容易成功）和当前活动总体成功率，动态调整后续Δ。最终，A在邀请50人后，R降至0，砍价成功。而很多用户可能因助力不足或时间截止而失败。

R-1599​

腾讯微信支付分产品部

用户、商户

评估/信用与先享规则

微信支付分“免押金”与“先享后付”信用评估模型

微信支付分基于用户的身份特质、支付行为、信用历史等评估，分数范围300-850。高分用户可在接入的商户享受免押金租借、先享后付（先用后付钱）等服务。商户可设置接入门槛（如550分以上）。

微信支付分信用评估与免押/先享服务模型

建立用户信用体系，降低商户交易风险，提升用户体验，促进信用消费场景的拓展。

1. 支付分每月更新一次。
2. 用户需授权才能评估和使用服务。
3. 商户接入需审核，并承担信用风险。
4. 用户违约会影响支付分。

输入：用户特征向量X（身份、支付、履约等）、支付分模型M_score、商户服务门槛T_merchant。
输出：用户支付分Score、是否满足商户门槛Qualified、可享服务列表ServiceList。
流程：1. 用户授权后，系统收集相关特征数据X。
2. 将X输入支付分评估模型M_score（如梯度提升树），输出支付分Score。
3. 当用户在某商户尝试使用免押或先享服务时，系统检查Score ≥ T_merchant。
4. 若满足，则授权服务；用户履约（归还物品或按期付款）后无后续；若违约，支付分下降，并可能被追偿。

高

设用户特征向量为X ∈ R^d。
支付分模型为M: R^d → [300， 850]，即Score = M(X)。
对于商户j设定的门槛T_j，用户i的服务资格为：
Qualified_{i，j} = 1 if Score_i ≥ T_j else 0。
模型M的训练目标是最小化预测分数与用户真实信用表现（如是否违约）之间的损失。

常量：模型参数θ，商户门槛T_j。
变量：用户特征X_i，支付分Score_i，资格标志Qualified_{i，j}。
函数/模型：信用评分模型M。

机器学习模型，阈值比较。

1. 用户画像与支付数据（实名信息、消费频率、金额）。
2. 历史信用履约记录（免押订单是否按时归还、先享后付是否按时支付）。
3. 支付分模型参数与评估记录。
4. 商户接入与服务门槛配置表。

信用评分，支付分，免押金，先享后付，微信支付。

1. 特征提取：用户C，实名认证，月均消费5000元，历史有10次免押租借均按时归还，无违约记录。构建特征向量X_C。
2. 支付分评估：将X_C输入模型M，输出Score_C=720分。
3. 服务使用：C在共享充电宝商户扫码借充电宝，该商户免押门槛T=550分。系统检查720 ≥ 550，通过，直接借出，无需押金。
4. 履约与违约：C按时归还，记录良好，支付分可能微升。若C未归还，商户可发起扣款，若扣款失败，则记录违约，支付分大幅下降，并可能影响其他服务使用。

R-1600​

百度搜索广告部

广告主、用户

资源/排序与竞价规则

百度搜索“关键词竞价排名”的“质量度”与“出价”综合模型

广告在百度搜索结果页的排名由“综合排名指数（CRI）”决定，CRI = 出价 × 质量度。质量度基于广告的点击率、相关性、落地页体验等因素。实际点击扣费按下一名的CRI除以本广告质量度再加价计算。

百度搜索广告综合排名指数（CRI）模型

在保证广告收入的同时，提升广告质量和用户体验，鼓励广告主优化广告内容而非单纯提高出价。

1. 质量度分数不公开具体数值。
2. 广告有明确标识（如“广告”）。
3. 存在最低展现价格（门槛）。
4. 点击扣费不超过广告主出价。

输入：广告主出价Bid、广告质量度Q、下一名广告的CRICRI_next。
输出：广告综合排名指数CRI、广告排名Rank、实际点击扣费CPC。
流程：1. 广告主对关键词设置出价Bid。
2. 系统计算该广告的质量度Q（基于历史CTR等）。
3. 计算CRI：CRI = Bid * Q。
4. 对所有竞争同一关键词的广告按CRI降序排序，得到排名。
5. 当广告被点击时，扣费CPC = (CRI_next / Q) + δ，其中δ为极小常数。

高

设广告i的出价为B_i，质量度为Q_i。
综合排名指数：CRI_i = B_i * Q_i。
排名：按CRI_i降序排列，Rank_i越小越靠前。
实际点击扣费（CPC）：采用广义第二价格拍卖的变体，广告i的实际扣费为：
CPC_i = (CRI_{i+1} / Q_i) + ε，其中CRI_{i+1}是排名下一位广告的CRI，ε为最小单位。
约束：CPC_i ≤ B_i。

常量：最小扣费单位ε。
变量：广告出价B_i，质量度Q_i，CRICRI_i，排名Rank_i，实际扣费CPC_i。

乘法，排序，广义第二价格拍卖。

1. 广告主出价记录（关键词、出价）。
2. 广告历史表现数据（点击率、转化率、落地页停留时间）。
3. 质量度计算模型与分数记录。
4. 广告排名与扣费日志。

搜索广告，竞价排名，质量度，综合排名指数，百度凤巢。

1. 出价与质量度：广告主A对关键词“英语培训”出价B_A=5元，其广告历史点击率较高，系统评估质量度Q_A=1.2。广告主B出价B_B=6元，但广告相关性较差，Q_B=0.8。
2. 计算CRI：CRI_A = 5 * 1.2 = 6；CRI_B = 6 * 0.8 = 4.8。
3. 排名：CRI_A > CRI_B，因此A排名第一，B第二。
4. 扣费计算：当用户点击A的广告时，A的实际扣费基于B的CRI：CPC_A = CRI_B / Q_A + 0.01 = 4.8 / 1.2 + 0.01 = 4 + 0.01 = 4.01元。A的出价5元，扣费4.01元，节省了0.99元。

R-1601​

网易云音乐推荐算法部

用户、音乐人

资源/分配与兴趣规则

网易云音乐“每日推荐”与“私人FM”的协同过滤与音频内容分析模型

“每日推荐”基于用户历史听歌记录、收藏、红心等行为，通过协同过滤和深度学习模型，生成30首个性化推荐歌曲。“私人FM”则更注重实时反馈，根据用户对当前歌曲的喜欢/跳过行为，动态调整后续播放流。

网易云音乐个性化推荐与实时流调整模型

深度理解用户音乐品味，提供高度个性化的音乐发现体验，增加用户使用时长和粘性。

1. 每日推荐每日更新一次。
2. 私人FM无明确歌单，无限流。
3. 实时反馈（喜欢/跳过）影响后续歌曲权重。
4. 考虑歌曲冷启动和多样性。

输入：用户历史行为History（播放、收藏、红心）、实时反馈Feedback（喜欢、跳过）、歌曲特征SongFeatures（音频、标签）。
输出：每日推荐歌单RecList_daily、私人FM下一首歌曲NextSong_FM。
流程：
每日推荐：1. 离线训练协同过滤模型（如矩阵分解）和深度学习模型，学习用户和歌曲的隐向量。
2. 每日凌晨，为每个用户计算其与所有候选歌曲的匹配度分数。
3. 结合多样性、新颖性等策略，选取Top30生成歌单。
私人FM：1. 基于当前用户上下文（刚听过的歌曲、实时反馈）实时召回候选歌曲。
2. 使用在线模型预测用户对候选歌曲的喜好概率。
3. 按概率排序，选择下一首播放。

极高

每日推荐：设用户隐向量为u，歌曲隐向量为v_i。匹配度分数s_i = u · v_i。最终推荐列表L = TopK({s_i})，K=30。
私人FM：设t时刻，用户历史反馈序列为F_{1:t}。模型预测用户对候选歌曲j的喜欢概率`p_j = P(like

F{1:t}， v_j)。选择NextSong = argmax_j p_j或按概率抽样。<br>模型可以是循环神经网络（RNN）或Transformer，以F{1:t}`和歌曲特征为输入。

常量：隐向量维度d，每日推荐数量K=30，模型参数θ。
变量：用户隐向量u，歌曲隐向量v_i，历史反馈序列F_{1:t}，预测概率p_j。
向量/序列：隐向量，反馈序列。

向量点积，TopK选择，概率预测，序列模型。

1. 用户听歌行为日志（用户ID、歌曲ID、播放时长、是否红心/收藏）。
2. 歌曲元数据与音频特征向量。
3. 协同过滤模型与深度学习模型参数。
4. 每日推荐歌单生成记录。
5. 私人FM实时播放与反馈日志。

音乐推荐，协同过滤，矩阵分解，深度学习，网易云音乐。

R-1602​

滴滴出行供需策略部

乘客、司机

价格/动态与供需规则

滴滴“动态调价（高峰溢价）”供需平衡模型

当某个区域、时段的打车需求大于司机供给时，系统触发动态调价，通过价格杠杆吸引更多司机接单，并抑制部分非紧急需求，使供需恢复平衡。溢价倍数基于实时供需比计算。

滴滴动态调价（高峰溢价）模型

在运力紧张时，通过价格信号调节供需，缩短乘客平均等待时间，提升司机收入，优化整体出行效率。

1. 溢价倍数有上限（如1.5倍）。
2. 溢价区域和时段动态划定。
3. 向乘客明确展示溢价倍数和原因。
4. 溢价部分全部或大部分归司机。

输入：区域实时需求D、区域实时供给S、基础价格P_base、历史供需比基线R_base。
输出：动态溢价倍数k、乘客实际支付价P_final。
流程：1. 系统实时计算各区域的供需比R = D / S。
2. 将当前R与历史基线R_base比较，计算供需紧张程度T = R / R_base。
3. 根据T值，通过查表或函数映射得到溢价倍数k，k ∈ [1.0， k_max]。
4. 计算最终价格：P_final = P_base * k。
5. 向乘客展示溢价后的预估费用，司机端显示溢价激励。

中高

设基础价格为P0。
实时供需比r = D / S。
历史基线供需比r0。
供需紧张系数α = r / r0。
溢价倍数函数：k = f(α)，通常为分段线性或S型函数，满足：f(1)=1，且f(α)随α增大而增大，上限为k_max。
最终价格：P = P0 * k。
司机获得的溢价部分为P0 * (k - 1)。

常量：基础价格P0，历史基线r0，溢价上限k_max，函数f的参数。
变量：实时需求D，实时供给S，供需比r，紧张系数α，溢价倍数k，最终价格P。

比率，分段函数，乘法。

1. 实时订单需求热力图。
2. 实时司机分布与状态热力图。
3. 历史各时段/区域供需比数据。
4. 动态调价倍数映射表。
5. 订单成交价格与溢价记录。

动态定价，高峰溢价，供需平衡，网约车。

1. 计算供需比：晚高峰18:30，中关村区域实时需求D=150人，实时供给S=50辆车，r = 150/50 = 3。
2. 计算紧张系数：该时段历史基线供需比r0=1.5，α = 3 / 1.5 = 2。
3. 确定溢价倍数：根据函数f，α=2时对应k=1.8（假设上限k_max=2.0）。
4. 计算最终价格：行程基础价格P0=30元，P_final = 30 * 1.8 = 54元。
5. 司机激励：司机收入增加30 * (1.8-1) = 24元，激励其前往该区域接单。

R-1603​

拼多多拼购业务部

用户、用户

价格/团购与裂变规则

拼多多“多人拼团”阶梯价格与成团模型

商品设置拼团价，需在限定时间内邀请指定人数（如2人、5人）参团。参团人数达到要求则成团，所有人以拼团价购买；若失败则退款。拼团价通常低于单独购买价，且可能有人数越多价格越低的阶梯设置。

拼多多多人拼团阶梯价格与成团模型

通过社交裂变快速聚集订单，降低获客成本，利用规模效应向供应商争取更低价格，实现低价销售。

1. 拼团有有效期（如24小时）。
2. 参团人数需达到设定门槛。
3. 成团前可退款，成团后发货。
4. 一人可开多团，但同一商品限购。

输入：商品单独购买价P_single、拼团人数要求N_required、拼团价P_group、当前参团人数N_current、剩余时间T_left。
输出：拼团状态Status（进行中/成功/失败）、用户支付价格P_pay。
流程：1. 用户发起或参与拼团，支付拼团价P_group。
2. 系统开始倒计时T_left（如24小时）。
3. 其他用户加入该团，N_current增加。
4. 若在T_left内N_current ≥ N_required，则拼团成功，系统确认订单并安排发货。
5. 若T_left耗尽且N_current < N_required，则拼团失败，系统自动退款。

中

设拼团人数要求为N_req，当前人数为N_cur，剩余时间为T，总时限为T_total。
拼团成功条件：(N_cur ≥ N_req) ∧ (T > 0)。
拼团失败条件：(N_cur < N_req) ∧ (T = 0)。
阶梯价格扩展：若有多个拼团人数档位N1， N2， ...（N1<N2<...）对应价格P1， P2， ...（P1>P2>...），则当参团人数达到Ni时，适用价格Pi。

常量：单独购买价P_single，拼团人数要求N_req，拼团价P_group，拼团时限T_total。
变量：当前参团人数N_cur，剩余时间T，拼团状态Status。
集合：阶梯档位集合{(N_i， P_i)}。

逻辑与，比较，条件判断。

1. 商品拼团活动配置表（商品ID、拼团价、成团人数、有效期）。
2. 拼团实例表（团ID、发起人、参团人、当前人数、状态、截止时间）。
3. 订单与支付记录。
4. 拼团成功/失败处理日志。

社交电商，拼团，阶梯价格，成团模型。

1. 开团：用户A对某商品发起2人拼团，拼团价P_group=50元（单独购买价P_single=60元），要求N_req=2人，有效期T_total=24小时。
2. 参团：用户B加入该团，N_cur=2。
3. 成团判断：N_cur=2 ≥ N_req=2，且T_left>0，拼团成功。
4. 订单处理：系统从A和B账户各扣款50元，合并生成一个订单发给商家发货。
5. 失败场景：若24小时内只有A一人参团，N_cur=1 < 2，且T_left=0，则拼团失败，向A退款50元。

R-1604​

小米商城运营部

用户、供应链

销售/分配与稀缺规则

小米“F码”（优先购买码）发放与使用模型

针对热门稀缺新品（如手机），小米向核心粉丝、社区活跃用户等发放F码，持有者可在公开发售前或售罄后优先购买。F码的发放数量、渠道、有效期受控，以管理稀缺资源分配和维持社区热度。

小米F码发放资格与稀缺资源分配模型

回馈核心用户，激励社区参与，在供应不足时有序分配稀缺商品，并制造营销话题和热度。

1. F码与特定商品SKU绑定。
2. 一码限购一件商品。
3. F码有使用有效期。
4. 禁止转售F码。

输入：用户价值U_value（社区等级、活跃度、购买历史）、商品稀缺度S_level、F码库存N_Fcode。
输出：用户是否获得F码Grant、F码有效期T_valid。
流程：1. 根据新品稀缺性和营销计划，确定F码总发放量N_total。
2. 设定发放渠道：社区活动抽奖、老用户回馈、积分兑换等。
3. 针对不同渠道，设定发放规则。如社区抽奖：随机抽取；老用户回馈：根据U_value排序，前N名获得。
4. 发放F码，绑定用户账户和商品SKU，设置有效期（如7天）。
5. 用户使用F码下单，系统校验有效性后，提供优先购买通道。

中

设F码总发放量为M。
发放渠道集合为C = {社区抽奖， 老用户回馈， 积分兑换， ...}，每个渠道c分配数量m_c，满足Σ m_c = M。
对于“老用户回馈”渠道，用户i的价值分数为V_i（基于社区等级、购买金额等）。
发放资格：选取V_i最高的前m_c名用户发放。
F码有效期T_valid从发放时开始计算，过期作废。

常量：F码总发放量M，各渠道分配量m_c，有效期T_valid。
变量：用户价值分数V_i，发放标志Grant_i。
集合：发放渠道集合C，候选用户集合U。

求和，排序，阈值比较。

1. 用户价值评估数据（社区贡献、购买历史）。
2. F码发放计划表（商品、总量、渠道分配）。
3. F码发放记录（码值、绑定用户、商品、有效期）。
4. F码使用与核销记录。

饥饿营销，优先购买，用户忠诚度，F码，小米。

1. 计划制定：小米14 Ultra首发，备货紧张，计划发放M=5000个F码。渠道分配：社区活动m1=2000，老用户回馈m2=2000，媒体合作m3=1000。
2. 老用户回馈规则：筛选近一年购买金额大于5000元的用户，按社区等级和活跃度计算V_i，取前m2=2000名。
3. 发放：用户Z，V_z排名第1500名，获得F码一个，有效期7天。
4. 使用：在公开发售前，Z登录商城，选择小米14 Ultra，输入F码，系统校验通过，允许其下单购买，而普通用户需等待公开抢购。

R-1605​

快手直播营收部

主播、公会、平台

销售/分成与激励规则

快手直播“打赏礼物”平台-公会-主播分成模型

用户购买虚拟礼物打赏主播，平台、主播所在公会、主播三方按约定比例分成。平台抽成比例固定，公会和主播的分成比例由双方签约约定，通常主播分成比例随流水阶梯提升。

快手直播打赏收入三方分成模型

明确直播打赏收入的分配规则，激励主播和公会持续生产内容，同时保障平台收入。

1. 用户充值购买虚拟货币（快币）。
2. 礼物有固定快币价格。
3. 分成结算有周期（如月结）。
4. 平台抽成比例相对固定，公会-主播比例可谈判。

输入：礼物快币价值V_coin、平台抽成比例r_platform、公会抽成比例r_union（或主播分成比例r_host）、主播当月流水阶梯Tier。
输出：平台收入I_platform、公会收入I_union、主播收入I_host。
流程：1. 用户花费人民币购买快币，充值到账户。
2. 用户用快币购买虚拟礼物打赏主播，礼物价值V_coin快币。
3. 平台首先按比例r_platform抽成：I_platform = V_coin * r_platform。
4. 剩余部分V_remaining = V_coin - I_platform进入公会-主播分成池。
5. 根据主播当月累计流水所属阶梯，确定主播分成比例r_host，公会获得r_union = 1 - r_host。
6. 主播收入I_host = V_remaining * r_host，公会收入I_union = V_remaining * r_union。

中高

设礼物快币价值为V（已折算为人民币价值）。
平台抽成比例为p。
平台收入：I_p = V * p。
剩余价值R = V * (1 - p)。
设主播分成比例为h，该比例可能是当月累计流水G的函数：h = f(G)，通常f是阶梯递增函数。
主播收入：I_h = R * h。
公会收入：I_u = R * (1 - h)。
总计：I_p + I_h + I_u = V。

常量：平台抽成比例p，分成阶梯函数f的参数。
变量：礼物价值V，剩余价值R，主播当月累计流水G，主播分成比例h，三方收入I_p， I_h， I_u。

乘法，减法，分段函数。

1. 用户充值记录（人民币->快币）。
2. 直播打赏流水（用户、主播、礼物、快币数、时间）。
3. 平台-公会-主播分成比例合同。
4. 主播月度流水累计与阶梯认定记录。
5. 三方分成结算单。

直播打赏，收入分成，公会，主播，平台抽成，快手。

1. 充值与打赏：用户购买价值100元人民币的快币，打赏一个“火箭”礼物（价值V=100元）。
2. 平台抽成：平台抽成比例p=50%，I_p = 100 * 50% = 50元。
3. 剩余分配：R = 100 - 50 = 50元。
4. 主播分成比例：该主播当月累计流水G=5万元，根据合约，流水在[3万，10万)区间时，主播分成h=40%，公会60%。
5. 计算收入：主播收入I_h = 50 * 40% = 20元。公会收入I_u = 50 * 60% = 30元。
6. 总计：平台50元，公会30元，主播20元，合计100元。

R-1606​

OPPO/vivo销售管理部

经销商、渠道

销售/返点与激励规则

OPPO/vivo线下渠道“销售返点”阶梯激励模型

经销商从厂商提货，根据其月度/季度销售额（或提货额）达到不同阶梯，获得不同比例的销售返点。返点可能以货款抵扣、现金或货品形式返还，激励经销商提升销量。

OPPO/vivo经销商销售返点阶梯模型

激励经销商积极销售本公司产品，完成销售目标，巩固线下渠道市场份额。

1. 销售额以经销商实际出货（sell-out）或提货（sell-in）为准。
2. 返点阶梯和比例提前公布。
3. 返点结算有周期（如次月）。
4. 可能存在捆绑销售要求（如搭配配件）。

输入：经销商月度销售额S、返点阶梯表{(T1， r1)， (T2， r2)， ...}（T1<T2<...， r1<r2<...）。
输出：经销商本月返点金额Rebate。
流程：1. 统计经销商本月销售额S。
2. 根据返点阶梯表，确定S所属的阶梯区间。例如，若T_k ≤ S < T_{k+1}，则适用返点比例r_k。
3. 计算返点金额：Rebate = S * r_k。
4. 次月结算，返点可抵扣货款或直接返还。

中

设销售额为S。
返点阶梯为(T_i， r_i)， i=1，2，...，n，其中T_i为销售额阈值，r_i为返点比例，且T_1 < T_2 < ... < T_n，通常r_1 < r_2 < ... < r_n。
确定阶梯：找到最大的k，使得S ≥ T_k。则适用比例r_k。
返点金额：R = S * r_k。
若S < T_1，则无返点（r=0）。

常量：返点阶梯表{(T_i， r_i)}。
变量：销售额S，适用返点比例r_k，返点金额R。

分段函数，乘法，查找。

1. 经销商提货/销售数据（按SKU、时间）。
2. 返点政策文件（阶梯、比例、结算周期）。
3. 经销商返点计算与结算记录。
4. 返点使用记录（抵扣货款、提现）。

渠道管理，销售返点，阶梯激励，经销商，OPPO， vivo。

1. 统计销售额：经销商D在1月份销售额S=120万元。
2. 查询阶梯表：公司政策：销售额<50万，返点0%；50万≤S<100万，返点2%；100万≤S<200万，返点3%；S≥200万，返点5%。
3. 确定阶梯：S=120万，属于100万≤S<200万区间，适用比例r=3%。
4. 计算返点：R = 120万 * 3% = 3.6万元。
5. 结算：2月初，3.6万元返点打入经销商账户，可用于抵扣下次进货货款。

R-1607​

知乎社区治理部

用户、内容创作者

运营/信用与权限规则

知乎“盐值”系统与社区权限关联模型

用户通过发布高质量内容、友善互动、遵守社区规范等行为提升“盐值”。盐值高低影响用户在社区的权限，如投票权重、评论折叠阈值、举报优先处理等。盐值每日更新，基于多个维度计算。

知乎盐值计算与社区权限映射模型

量化用户在社区的贡献和信誉，激励良性互动，赋予高信誉用户更多治理权限，辅助社区自治。

1. 盐值计算维度固定（基础信用、内容创作、社区互动等）。
2. 每日更新，反映近期行为。
3. 权限与盐值分段绑定。
4. 违规行为会导致盐值扣减。

输入：用户近期行为数据B（创作、互动、举报、违规）、各维度权重W、基础信用分Base。
输出：用户当日盐值Score_salt、对应的权限等级Level。
流程：1. 收集用户过去一段时间（如90天）的行为数据，归类到不同维度：创作质量、社区建设、遵守规范等。
2. 对各维度打分S_i，加权求和得到总分：Score_total = Σ(W_i * S_i)。
3. 结合基础信用分，计算最终盐值：Score_salt = Base + Score_total，范围通常0-1000。
4. 根据盐值所在区间，映射到具体权限等级Level，解锁相应功能。

高

设盐值计算有n个维度，用户在第i个维度的得分为s_i，权重为w_i，Σw_i = 1。
总分：S_total = Σ_{i=1}^{n} w_i * s_i。
最终盐值：Salt = B + S_total，其中B为基础信用分（与注册时长、认证等相关）。
盐值映射到权限等级L：L = g(Salt)，g是分段函数，例如：Salt ∈ [0， 400) => L1， [400， 600) => L2， [600， 850) => L3， [850， 1000] => L4。

常量：维度权重w_i，基础信用分B，权限等级映射函数g。
变量：各维度得分s_i，总分S_total，盐值Salt，权限等级L。
向量：维度得分向量，权重向量。

加权求和，分段函数。

1. 用户行为日志（提问、回答、赞同、反对、举报、违规）。
2. 内容质量评估数据（回答获赞数、专业认可）。
3. 盐值计算维度得分表。
4. 盐值历史与权限变更记录。

社区信用，盐值，用户权限，社区治理，知乎。

1. 数据收集：用户U过去90天行为：发布10个回答（平均获赞100），获得5次专业认可，举报3个违规内容并被处理，无违规记录。
2. 维度打分：系统计算：
- 内容创作维度s1=85（基于回答质量和影响力）。
- 社区建设维度s2=90（基于举报有效性和互动）。
- 遵守规范维度s3=95（无违规）。
3. 加权求和：权重w=[0.5，0.3，0.2]。S_total = 0.5 * 85 + 0.3 * 90 + 0.2 * 95 = 42.5 + 27 + 19 = 88.5。
4. 计算盐值：用户U注册2年，基础信用分B=500。Salt = 500 + 88.5 = 588.5。
5. 权限映射：Salt=588.5属于[400， 600)区间，对应L2等级。该等级拥有“反对票权重更高”、“评论被折叠阈值提高”等权限。

R-1608​

微博热搜算法组

用户、媒体、广告主

运营/热度与排序规则

微博“热搜榜”热度值计算与排名模型

热搜榜排名基于话题的“热度值”，热度值由搜索量、讨论量（发博、转发、评论）、传播速度、社会影响力等多维度数据，经过时间衰减和归一化处理后加权计算得出。同时存在人工干预（置顶、广告位）。

微博热搜热度值计算与实时排名模型

反映实时社会热点和公众兴趣，提升平台活跃度和用户参与度，同时兼顾商业价值和舆论导向。

1. 热度值计算因子和权重不公开。
2. 数据统计有时间窗口（如1小时）。
3. 存在反刷量机制。
4. 广告热搜有明确标识。

输入：话题T在时间窗口Δt内的搜索量Search、讨论量Discuss（发博Post、转发Repost、评论Comment）、传播速度Spread、参与用户价值UserValue。
输出：话题T的热度值H、热搜排名Rank。
流程：1. 实时采集各话题的原始数据指标。
2. 对各指标进行去噪、反作弊、归一化处理，得到标准化值S_i'。
3. 计算热度值：H = Σ(w_i * S_i') * f(t)，其中w_i为权重，f(t)为时间衰减函数（新话题有加成）。
4. 对所有话题按H降序排序，取前50名生成热搜榜。
5. 运营人员可对榜单进行人工调整（如置顶正能量话题）。

高

设话题j在时间窗口[t-Δt， t]内的原始指标为向量X_j = (x1， x2， ...， xm)，如搜索量、发博量等。
归一化后得到X_j'。
热度值：H_j(t) = ( Σ_{i=1}^{m} w_i * x_{ji}' ) * exp(λ * (t - t_j0))。
其中w_i为指标权重，t_j0为话题首次出现时间，λ为时间衰减/增长因子（可能为正或负，新话题λ>0有增长加成，老话题λ<0衰减）。
排名：按H_j(t)降序排列。

常量：指标权重w_i，时间窗口Δt，时间因子λ。
变量：话题原始指标x_{ji}，归一化指标x_{ji}'，话题出现时间t_j0，当前时间t，热度值H_j(t)。
向量：指标向量，权重向量。

加权求和，指数函数，排序。

1. 话题实时数据流（搜索、发博、转发、评论）。
2. 用户画像与影响力数据。
3. 热度值计算中间结果与排名日志。
4. 人工运营操作记录（置顶、压热度）。

热搜榜，热度值，舆论监控，微博。

1. 数据采集：话题“#某明星发布会#”在过去1小时内，搜索量10万，发博量5万，转发量20万，评论量8万。
2. 归一化：对各指标除以全话题最大值进行归一化，得到[0.5， 0.3， 0.8， 0.4]。
3. 加权计算：权重w=[0.3，0.2，0.3，0.2]。加权和=0.3 * 0.5+0.2 * 0.3+0.3 * 0.8+0.2 * 0.4=0.15+0.06+0.24+0.08=0.53。
4. 时间加成：该话题是30分钟前新出现的，t - t0=0.5小时，设λ=0.5，时间因子exp(0.5 * 0.5)=exp(0.25)≈1.28。
5. 最终热度：H = 0.53 * 1.28 ≈ 0.68。
6. 排名：计算所有话题的H，假设0.68排名第5，则进入热搜榜第5位。

R-1609​

淘宝平台治理部

买家、卖家

运营/售后与纠纷规则

淘宝“七天无理由退货”条件判定与运费承担模型

消费者在签收商品之日起七天内，可发起无理由退货申请。退货需满足商品完好、不影响二次销售等条件。运费承担方根据退货原因判定：非商品质量问题通常买家承担，质量问题或卖家责任则卖家承担。

淘宝七天无理由退货条件与运费责任判定模型

保障消费者购物后悔权，降低决策风险，同时平衡卖家权益，明确退货条件和费用责任，减少纠纷。

1. 七日从签收次日零时起算。
2. 部分商品不适用（如定制、鲜活易腐）。
3. 商品完好标准有具体定义（如标签未拆、包装完整）。
4. 运费险可能覆盖买家运费。

输入：退货申请时间T_apply、签收时间T_receive、退货原因Reason、商品状态Condition、是否购买运费险HasInsurance。
输出：是否支持无理由退货Support、运费承担方Payer（买家/卖家/保险公司）。
流程：1. 检查是否在七日内：T_apply - T_receive ≤ 7 days。
2. 检查商品是否属于不支持无理由退货的类目。
3. 检查商品状态是否完好（如未使用、标签未拆）。
4. 判定运费承担方：若Reason为“不喜欢/不想要”等非卖家责任，则Payer为买家；若为“质量问题”、“描述不符”等卖家责任，则Payer为卖家。
5. 若买家购买了运费险，则保险公司赔付买家垫付的运费。

中

设签收时间为T0，申请退货时间为T1。
时效条件：Δt = T1 - T0 ≤ 7 days。
设商品状态完好为布尔值C_good，商品类目支持无理由退货为布尔值C_support。
支持退货条件：Support = (Δt ≤ 7) ∧ C_good ∧ C_support。
设退货原因为R，卖家责任原因集合为R_seller（如质量问题）。
运费承担方：
Payer = { “卖家”， if R ∈ R_seller； “买家”， otherwise }。
若买家购买了运费险，则实际运费由保险公司承担，但逻辑上仍先判定责任方。

常量：七天时限7 days，不支持无理由退货的类目集合Cat_exclude，卖家责任原因集合R_seller。
变量：签收时间T0，申请时间T1，时间差Δt，商品状态C_good，商品类目Cat，退货原因R，是否支持Support，运费承担方Payer。

时间差比较，逻辑与，集合包含判断。

1. 订单物流信息（签收时间）。
2. 退货退款申请记录（申请时间、原因、凭证）。
3. 商品类目与退货规则配置表。
4. 运费险购买与理赔记录。
5. 纠纷判决记录。

七天无理由退货，运费承担，平台仲裁，淘宝。

1. 时效检查：用户3月1日签收，3月5日申请退货，Δt=4天 ≤ 7天，满足时效。
2. 类目检查：商品为普通服装，属于支持无理由退货类目，C_support=True。
3. 商品状态：用户未拆吊牌，未穿着，C_good=True。
4. 退货支持：Support = True ∧ True ∧ True = True，支持退货。
5. 运费判定：退货原因R=”不喜欢“，不属于卖家责任集合R_seller，因此Payer=”买家“。
6. 运费险：用户购买了运费险，退货后上传运费凭证，保险公司赔付10元运费给用户。

R-1610​

腾讯游戏健康系统中心

用户（未成年人）、家长

运营/防沉迷与消费规则

腾讯游戏“未成年人防沉迷”时长与消费限制模型

对实名认证为未成年人的用户，实施游戏时长限制（平日1.5小时/天，节假日3小时/天）和消费限额（不同年龄档每月上限）。超过时长强制下线，消费达到限额后无法支付。

腾讯游戏未成年人时长与消费双限模型

保护未成年人身心健康，防止过度游戏和不当消费，履行社会责任，符合监管要求。

1. 强制接入公安实名认证系统。
2. 时长计算为累计在线时长。
3. 消费限额按自然月重置。
4. 家长可通过守护平台设置更严格的限制。

输入：用户实名信息Age、本次登录时间T_login、本次在线时长ΔT_session、本月已消费金额C_month、本次消费金额ΔC。
输出：是否允许继续游戏Allow_play、是否允许本次消费Allow_pay、强制下线时间T_force_logout。
流程：
时长限制：1. 查询用户今日已在线时长T_today。
2. 根据是否节假日，确定每日限时L_day（平日1.5h，节假日3h）。
3. 若T_today + ΔT_session ≥ L_day，则计算剩余可玩时间T_left = L_day - T_today，并在T_left后强制下线；否则允许本次会话。
消费限制：1. 根据用户年龄确定月度消费限额M_month（如8-16岁单次≤100元，每月≤400元）。
2. 若C_month + ΔC > M_month，则拒绝本次支付；否则允许。

中

设用户年龄为A。
时长限制：
每日限时L_day = { 1.5h， if 是平日； 3h， if 是节假日 }。
设今日已在线时长为T_used，本次会话时长为t。
允许继续游戏条件：T_used + t ≤ L_day。
强制下线剩余时间：T_left = max(0， L_day - T_used)。
消费限制：
月度消费限额M(A)是年龄A的函数。
设本月已消费C_used，本次尝试消费c。
允许消费条件：C_used + c ≤ M(A)。

常量：平日限时L_weekday=1.5h，节假日限时L_holiday=3h，年龄消费限额函数M(A)。
变量：用户年龄A，今日已在线T_used，本次会话时长t，本月已消费C_used，本次消费c，是否节假日IsHoliday，允许游戏标志Allow_play，允许消费标志Allow_pay。

条件判断，最大值函数，加法比较。

1. 用户实名认证信息（姓名、身份证号、年龄）。
2. 用户游戏登录与在线时长日志。
3. 用户游戏消费记录。
4. 节假日日历表。
5. 防沉迷规则配置表（年龄分段、时长、限额）。

防沉迷，未成年人保护，游戏时长，消费限额，腾讯健康系统。

1. 时长检查：未成年人用户（12岁），周六（节假日）登录游戏。今日已玩T_used=2小时。本次会话t=1小时。节假日限时L_day=3小时。T_used + t = 3 ≤ 3，允许本次游戏。但若t=1.5小时，则2+1.5=3.5>3，系统会在用户玩满1小时（T_left=3-2=1）后强制下线。
2. 消费检查：该用户年龄12岁，月度消费限额M=400元。本月已消费C_used=350元。本次试图充值c=100元。350+100=450 > 400，拒绝本次支付，提示“本月消费额度已满”。

R-1611​

字节跳动巨量引擎广告平台

广告主、平台

销售/竞价与优化规则

巨量引擎“广告投放”的“双出价（转化出价+深度转化出价）”与预算分配模型

广告主可设置两个出价：浅层转化目标出价（如点击）和深层转化目标出价（如表单提交）。系统在保证浅层转化成本的前提下，尽可能优化深层转化，并按照广告主设定的预算进行平滑投放。

巨量引擎广告双出价与预算平滑投放模型

帮助广告主在控制成本的前提下，优化更深层次的转化目标，提升广告投放ROI，同时平滑消耗预算，避免过早花完或花不出去。

1. 双出价需同时设置，且深层出价通常高于浅层出价。
2. 预算有每日预算和总预算。
3. 系统通过预估转化率来分配流量。
4. 实际成本可能围绕出价波动。

输入：广告主设置的浅层目标出价Bid_shallow、深层目标出价Bid_deep、每日预算Budget_daily、广告创意与定向Ad。
输出：实时竞价策略、预算消耗速度Spend_rate、预估转化成本Cost_per_action。
流程：1. 广告主创建广告计划，设置Bid_shallow（如点击出价2元）、Bid_deep（如表单提交出价50元）、Budget_daily（如1000元）。
2. 当有广告请求时，系统预估该流量对广告的浅层转化率p1和深层转化率p2。
3. 计算期望价值：`E_value = p1 * Bid

R-1612​

美团配送策略部

用户、骑手

价格/动态与供需规则

外卖“配送费”实时动态定价模型

配送费 = 基础费 + 时段系数基础费 + 天气系数基础费 + 距离费 + 供需加价。加价基于实时区域运力供需比计算，激励骑手接单。

美团外卖配送费动态定价模型

在高峰、恶劣天气等运力紧张时段，通过价格杠杆调节供需，保障订单履约率，平衡用户体验与骑手收入。

1. 加价有上限（如基础费的2倍）。
2. 向用户明确展示加价原因（如“高峰时段”）。
3. 恶劣天气加价部分全额或高比例补贴骑手。
4. 基础费与距离正相关。

输入：订单距离d、当前时段t、天气状况w、区域实时供需比r、基础配送费f_base。
输出：最终配送费f_final。
流程：1. 计算基础距离费：f_dist = g(d)。
2. 获取时段系数α_t、天气系数α_w、供需系数α_r。
3. 计算：f_final = f_base + f_dist + (α_t+α_w)*f_base + α_r*f_base。
4. 若f_final超过上限，则取上限值。
5. 向用户展示费用明细。

高

F = F_base + G(d) + (β_t + β_w + β_r) * F_base。
其中：
G(d)为距离函数，通常分段线性。
β_t ∈ [0， B_t]为时段加成系数。
β_w ∈ [0， B_w]为天气加成系数。
β_r = γ * max(0， (R_current / R_base - 1))，为供需紧张系数，γ为敏感度，R为供需比。

常量：基础费F_base，时段/天气系数上限B_t， B_w，敏感度γ，基线供需比R_base。
变量：距离d，当前时段t，天气w，实时供需比R_current，各系数β_t， β_w， β_r，最终费用F。
函数：距离费用函数G(d)。

分段函数，加权求和，最大值函数。

1. 订单与骑手实时位置热力图。
2. 天气数据接口。
3. 历史各时段/区域供需比数据。
4. 配送费定价参数配置表。
5. 订单成交与取消记录。

动态定价，共享经济，外卖配送，供需平衡。

1. 获取参数：订单距离d=3km，F_base=5元，G(3)=2元。当前晚高峰β_t=0.5，小雨β_w=0.3，区域供需比R_curr=2，基线R_base=1，γ=0.5。
2. 计算供需系数：β_r = 0.5 * max(0， 2/1 -1) = 0.5 * 1=0.5。
3. 计算总费用：F = 5 + 2 + (0.5+0.3+0.5)*5 = 7 + 1.3 * 5 = 7+6.5=13.5元。
4. 上限检查：上限为2 * 5+2=12元，因此F_final=12元。
5. 费用拆分：用户支付12元，其中骑手获得基础收入+加价补贴，平台收取信息服务费。

R-1613​

网易云音乐会员中心

用户、版权方

销售/订阅与续费规则

音乐App“连续包月”首月折扣与自动续费模型

用户选择“连续包月”时，首月享受大幅折扣（如0.1元），次月起按原价自动扣费。用户可随时取消自动续费，但取消后次月不再享受折扣价。

网易云音乐黑胶VIP连续包月折扣模型

降低用户首次订阅门槛，培养付费习惯，通过自动续费锁定长期收入，提升用户留存和LTV。

1. 首月折扣仅限新订阅用户或长时间未续费用户。
2. 自动续费需绑定支付方式并授权。
3. 续费前通过消息提醒用户。
4. 取消后续费后，再次订阅可能无法享受首月折扣。

输入：用户订阅状态S、是否为新订阅/回归用户IsNew、连续包月原价P_full、首月折扣价P_discount。
输出：用户首月支付价格P_first、续费周期T_cycle、自动续费状态AutoRenew。
流程：1. 用户选择“连续包月”套餐，系统检查资格：若IsNew=True，则适用首月折扣价P_discount。
2. 用户支付P_first = P_discount，开通服务，同时开启自动续费AutoRenew=True。
3. 服务有效期为1个月。
4. 到期前3天，系统检查AutoRenew，若为True且支付方式正常，则自动扣款P_full，续期1个月。
5. 用户可随时在设置中关闭AutoRenew，关闭后本期服务结束后不再续费。

中

设连续包月原价为P，首月折扣价为P0（P0 << P）。
用户u在时间t的支付价格：
Pay(t_u) = { P0， if t_u 是首个订阅周期； P， if t_u 是后续自动续费周期 }。
自动续费状态A(t)是一个布尔值，用户可手动切换。当A(t)=True且到期时，触发扣款P。

常量：原价P，首月折扣价P0，续费周期T=30天。
变量：用户订阅时间t_u，是否为新订阅IsNew，自动续费状态A，支付价格Pay。

条件判断。

1. 用户订阅与支付记录。
2. 自动续费授权状态表。
3. 折扣活动配置表（目标用户、折扣价）。
4. 续费扣款成功/失败日志。

订阅经济，自动续费，用户留存，首单折扣。

1. 资格检查：用户U从未订阅过黑胶VIP，点击“连续包月”，IsNew=True，首月折扣价P0=0.1元，原价P=18元。
2. 首次支付：U支付0.1元，立即获得VIP权限，同时系统设置AutoRenew=True。
3. 到期续费：30天后服务到期，系统在到期前3天检查，AutoRenew=True，从U绑定的支付账户扣款18元，续期30天。
4. 用户取消：U在第二个月中途关闭自动续费，AutoRenew=False。第二个月服务结束后，不再扣款，VIP权限终止。

R-1614​

滴滴青桔单车运营部

用户、平台

销售/套餐与自动续费规则

共享单车“骑行月卡”自动续费与优惠续订模型

用户购买骑行月卡（如30天不限次），可选择开启自动续费。自动续费时，若检测到用户有未使用的优惠券或平台有促销活动，系统会优先使用优惠，以低于原价的价格续费。

青桔单车骑行月卡智能续费与优惠应用模型

提升月卡自动续费率，增加用户粘性，通过智能使用优惠刺激用户保持订阅，同时消化平台优惠券库存。

1. 自动续费需用户主动开启并授权。
2. 续费时优先使用快到期的优惠券。
3. 优惠叠加规则需明确（如仅限一张）。
4. 续费前通知用户本次扣款金额和使用的优惠。

输入：用户月卡状态S、自动续费开关Auto、可用优惠券列表Coupons、月卡原价P_full。
输出：本次续费实际支付金额P_pay、使用的优惠券C_used、续费后有效期T_new。
流程：1. 用户月卡到期前N天，系统检查Auto是否为True。
2. 若为True，则扫描用户账户内可用且适用于月卡续费的优惠券Coupons。
3. 选择最优优惠券（如面值最大或折扣最大），计算P_pay = max(0， P_full - Value(C_used))。
4. 向用户发送续费提醒，包含金额和优惠信息。
5. 到期时自动扣款P_pay，延长月卡有效期30天。

中

设月卡原价为P。
用户可用优惠券集合为C = {c1， c2， ...}，每张券c_i有面值v_i或折扣率d_i。
最优券选择：c* = argmax_{c_i ∈ C} (Discount(P， c_i))，即能最大程度减少支付额的券。
实际支付：P_pay = P - v*（满减券）或 P_pay = P * (1 - d*)（折扣券）。
约束：P_pay ≥ 0。

常量：月卡原价P，续费周期T。
变量：自动续费状态Auto，优惠券集合C，最优券c*，实际支付P_pay。
集合：优惠券集合C。

最大值函数，减法，乘法。

1. 用户月卡购买与有效期记录。
2. 用户优惠券账户（券ID、面值、适用场景、有效期）。
3. 自动续费授权表。
4. 续费扣款与优惠核销记录。

共享经济，订阅服务，优惠券，自动续费。

1. 到期检查：用户U的月卡3天后到期，Auto=True。
2. 扫描优惠券：U账户内有：一张“满15减3”券，一张“8折”券，均适用于月卡续费。月卡原价P=20元。
3. 计算最优：
- 使用满减券：P_pay1 = 20-3=17元。
- 使用8折券：P_pay2 = 20 * 0.8=16元。
8折券更优，c*=8折券，P_pay=16元。
4. 通知与扣款：提前1天通知U：“将使用8折券，续费扣款16元”。到期时自动扣款16元，月卡延长30天。

R-1615​

淘宝天猫营销平台

买家、卖家

价格/促销与叠加规则

电商大促“跨店满减”优惠计算与分摊模型

活动期间，消费者在参与活动的商家购物，单笔订单总金额（剔除不支持商品）达到指定门槛，即可享受满减优惠（如满300减50）。优惠金额按商品金额比例分摊到每个子订单，用于退款计算。

天猫双十一跨店满减计算与分摊模型

刺激消费者凑单，提升客单价和平台整体GMV，简化优惠规则，提升用户体验。

1. 仅限活动标记的商品和商家。
2. 优惠可与店铺券、品类券等叠加，但有优先级。
3. 退款时按分摊后的实付金额退还。
4. 虚拟商品、特殊品类可能不参与。

输入：订单商品列表Items（每个商品金额p_i、是否参与join_i）、满减规则(X， Y)（满X减Y）。
输出：订单是否满足满减Eligible、优惠金额Discount、各商品分摊优惠d_i、各商品最终支付价p_i_final。
流程：1. 计算参与满减的商品总金额P_total = Σ(p_i * join_i)。
2. 判断是否满足：若P_total ≥ X，则Eligible=True，Discount = floor(P_total / X) * Y。
3. 分摊优惠：d_i = (p_i / P_total) * Discount。
4. 计算各商品最终支付价：p_i_final = p_i - d_i。
5. 下单支付总额为Σ p_i_final。

中高

设订单中参与满减的商品集合为I，商品i的金额为p_i。
满减规则：满M减N。
参与总金额：P = Σ_{i∈I} p_i。
优惠金额：D = floor(P / M) * N。
商品i分摊的优惠：d_i = (p_i / P) * D。
商品i最终支付价：p_i' = p_i - d_i。
订单实付：Pay = Σ p_i' = P - D。

常量：满减门槛M，减额N。
变量：商品金额p_i，参与标志join_i，参与总金额P，优惠D，分摊优惠d_i，最终支付p_i'。
集合：参与商品集合I。

求和，向下取整，乘法，比例分配。

1. 商品与活动关联表（商品ID、活动ID、是否参与）。
2. 跨店满减活动规则表（活动ID、门槛、减额、时间）。
3. 订单优惠计算中间结果与分摊记录。
4. 退款计算与分摊回溯日志。

电商大促，跨店满减，优惠分摊，GMV提升。

1. 计算参与总额：用户订单有A商品120元（参与），B商品200元（参与），C商品50元（不参与）。P_total = 120+200=320元。满减规则：满300减50。
2. 判断与计算优惠：320 ≥ 300，满足。Discount = floor(320/300)*50 = 1 * 50=50元。
3. 分摊优惠：
- A分摊：d_A = (120/320)*50 = 18.75元。
- B分摊：d_B = (200/320)*50 = 31.25元。
4. 最终支付价：p_A_final=120-18.75=101.25元，p_B_final=200-31.25=168.75元，C仍为50元。订单实付101.25+168.75+50=320元（原总价370元，优惠50元）。

R-1616​

京东PLUS会员中心

用户、平台、商家

销售/会员与权益规则

京东“PLUS会员”免运费券发放与使用模型

PLUS会员每月可获得固定数量的免运费券（如5张），用于抵扣自营订单运费。运费券有有效期（如当月有效），不可叠加，每张券可抵扣一笔订单的全部运费。

京东PLUS会员月度免运费券模型

提升PLUS会员的感知价值，刺激会员增加购买频次，尤其是小额订单，同时将运费成本内部化，提升用户忠诚度。

1. 运费券仅适用于京东自营商品。
2. 每张券仅限一单使用，订单取消或退货后券返还。
3. 券自动发放至账户，过期作废。
4. 可与优惠券、京豆等叠加。

输入：用户PLUS会员状态IsPlus、当前月份Month、本月已使用运费券数量N_used、本月总发放数量N_total（如5）、订单运费Freight。
输出：本月剩余可用运费券数量N_left、本次是否可使用运费券CanUse、使用后订单实付运费Freight_final。
流程：1. 每月1日，系统为所有有效PLUS会员发放N_total张运费券，有效期至当月最后一天。
2. 用户下单时，若IsPlus=True且N_left > 0，系统提示可选择使用一张运费券。
3. 用户选择使用后，Freight_final = 0，N_used += 1。
4. 若订单取消，返还运费券，N_used -= 1。

低

设每月发放券数为S（如5）。
用户u在月份m的已使用券数为U_m。
剩余券数：R_m = S - U_m。
使用条件：对于一笔订单，CanUse = (IsPlus_u = True) ∧ (R_m > 0)。
若使用，则Freight' = 0，且U_m += 1。

常量：月度发放数量S。
变量：用户PLUS状态IsPlus，月份m，已使用数U_m，剩余数R_m，订单运费Freight，是否可用CanUse。

减法，逻辑与。

1. PLUS会员订阅状态表。
2. 月度运费券发放记录（用户、月份、数量）。
3. 运费券使用与核销流水。
4. 订单运费与优惠明细。

会员经济，忠诚度计划，运费补贴，京东PLUS。

1. 月初发放：用户U是PLUS会员，3月1日系统自动发放5张运费券到其账户，有效期至3月31日。
2. 下单检查：3月10日，U下一笔自营订单，运费8元。系统检查：IsPlus=True，R_3 = 5 - 0 = 5 > 0，提示可使用运费券。
3. 使用与扣减：U选择使用一张，订单运费变为0。系统更新U_3 = 1，R_3 = 4。
4. 月末过期：3月31日24点，剩余4张未使用的运费券自动作废。4月1日，系统重新发放新的5张券。

R-1617​

拼多多百亿补贴审核部

用户、商家、平台

价格/补贴与风控规则

拼多多“百亿补贴”商品价格与正品资质双审核模型

商家申请商品加入“百亿补贴”频道，需承诺提供全网低价并提交品牌授权等正品证明。平台审核通过后，对商品进行价格监控和补贴，确保其价格低于其他主流平台，并对疑似假货或调价行为进行处罚。

拼多多百亿补贴价格与正品双重风控模型

通过官方补贴打造“全网最低价”心智，吸引价格敏感用户，同时严格管控商品质量和商家行为，提升平台信誉。

1. 申请商家需具备一定信誉等级。
2. 商品价格需低于其他平台（如天猫、京东）的同款。
3. 平台会进行神秘购买抽检。
4. 商家不得在活动期间私自提价，否则取消资格并处罚。

输入：商家申请资料App（商品ID、承诺价P_commit、资质文件）、竞品价格监控数据P_comp、商家历史信誉Credit。
输出：审核结果Approve、平台补贴金额Subsidy、监控状态Monitor。
流程：1. 商家提交申请，填写承诺销售价P_commit。
2. 平台审核资质（品牌授权、质检报告等）。
3. 比价系统抓取其他平台同款商品当前最低价P_min_comp。
4. 若P_commit < P_min_comp且资质合格，则审核通过，商品进入百亿补贴频道。
5. 平台补贴Subsidy = P_min_comp - P_commit的一部分给商家或直接让利用户。
6. 持续监控价格和商品质量。

高

设商家承诺价为P_s，竞品最低价为P_c。
审核通过条件：(P_s < P_c) ∧ (Qualify = True)，其中Qualify为资质审核结果。
补贴计算：平台补贴额B = θ * (P_c - P_s)，θ ∈ (0， 1]为补贴系数。
用户实际支付价仍为P_s，商家收到P_s + B。

常量：补贴系数θ，资质审核标准。
变量：承诺价P_s，竞品价P_c，资质结果Qualify，审核结果Approve，补贴额B。

比较，逻辑与，乘法。

1. 商家资质文件库。
2. 全网比价系统数据（商品、平台、价格、时间）。
3. 百亿补贴申请与审核记录。
4. 补贴发放与价格监控日志。
5. 神秘抽检报告。

价格战，补贴，风控，正品保障，拼多多。

1. 商家申请：商家S申请iPhone 15加入百亿补贴，承诺价P_s=5000元，提交苹果授权书。
2. 资质审核：审核通过，Qualify=True。
3. 比价：比价系统显示，天猫官方店同款售价P_c=5200元，京东5250元，P_min_comp=5200元。
4. 价格审核：5000 < 5200，满足低价条件，审核通过。
5. 补贴计算：设θ=0.8，B = 0.8*(5200-5000)=160元。平台补贴160元给S，用户支付5000元即可购买。

R-1618​

字节跳动番茄小说商业化部

用户、广告主

运营/免费与变现规则

免费阅读App“看广告得阅读时长”激励模型

用户可通过观看一段完整的视频广告，获取一定时长的免费阅读权限（如30分钟）。每日有获取上限。平台通过广告展示获得收入，平衡用户体验和商业化变现。

番茄小说看广告得阅读时长激励模型

为不愿付费的用户提供免费阅读路径，提升用户粘性和停留时长，同时通过广告实现流量变现。

1. 广告需完整播放（如30秒）才奖励。
2. 奖励的阅读时长有有效期（如当天）。
3. 每日通过广告获得的阅读时长有上限（如2小时）。
4. 不同用户可能看到不同的广告奖励时长（用于AB测试）。

输入：用户观看广告行为AdView（是否完整、广告ID）、用户当日已获时长T_today、每日上限L_max、基础奖励时长B。
输出：本次奖励时长ΔT、用户累计免费时长T_total、是否达到上限ReachLimit。
流程：1. 用户点击“看广告得时长”按钮，播放一段广告。
2. 广告播放完毕，系统验证AdView完整。
3. 计算本次奖励：ΔT = B（或根据广告价值浮动）。
4. 检查上限：若T_today + ΔT > L_max，则ΔT = L_max - T_today。
5. 更新用户免费时长账户：T_total += ΔT。
6. 时长可用于阅读正版章节，扣除规则与付费时长相同。

中

设每次完整观看广告的基础奖励时长为T0。
用户u在日期d已通过广告获得的时长为A_d。
每日上限为L。
本次实际奖励：Δ = min(T0， L - A_d)。
更新累计：A_d' = A_d + Δ。
用户总免费时长F_u增加Δ。

常量：基础奖励T0，每日上限L。
变量：当日已获时长A_d，本次奖励Δ，总免费时长F_u。

最小值函数，加法。

1. 用户广告观看日志（用户、广告ID、是否完成、时间）。
2. 用户免费阅读时长账户（总时长、来源、有效期）。
3. 广告奖励规则配置表（基础时长、上限）。
4. 广告填充与收益数据。

免费模式，激励视频广告，用户留存，商业化。

1. 用户行为：用户U点击看广告，完整观看了一则30秒游戏广告。
2. 奖励计算：基础奖励T0=30分钟，U今日已通过广告获得A_d=90分钟，每日上限L=120分钟。
3. 上限检查：L - A_d = 120-90=30分钟，min(30， 30)=30分钟。因此Δ=30分钟。
4. 更新账户：A_d'=90+30=120分钟（达到上限），总免费时长F_u增加30分钟。
5. 使用：U在阅读时，系统优先扣除免费时长，用尽后再提示购买或看广告。

R-1619​

腾讯视频内容付费部

用户、内容版权方

销售/点播与付费规则

视频平台“超前点播”单集解锁与打包折扣模型

对于热播剧，会员可额外付费提前观看未播剧集。提供两种选择：单集点播（如3元/集）和打包多集（如提前看3集共8元，折扣价）。解锁后永久有效。

腾讯视频超前点播单集与打包定价模型

在会员收入基础上，挖掘核心粉丝的付费潜力，获取增量收入，同时通过打包折扣刺激消费更多集数。

1. 仅限VIP会员购买。
2. 解锁后可在会员有效期内观看。
3. 打包折扣价低于单集价之和。
4. 活动有明确时间窗口（如更新后一周内）。

输入：用户VIP状态IsVIP、剧集列表Eps、单集价格P_single、打包方案(N， P_pack)（N集打包价P_pack）。
输出：用户可选择购买选项Options、打包节省金额Save。
流程：1. 热播剧更新，对VIP用户开放超前点播。
2. 展示购买选项：单集购买（每集P_single）或打包购买（N集P_pack，Save = N*P_single - P_pack）。
3. 用户选择并支付。
4. 系统解锁对应剧集，用户可立即观看。

低

设单集价格为p。
打包方案：n集打包总价为P_n，通常P_n < n * p。
打包节省额：S = n * p - P_n。
用户购买k集（k≤n）时，若选择打包，则支付P_n；若选择单集，则支付k*p。系统会推荐更优方案。

常量：单集价p，打包方案(n， P_n)。
变量：用户选择集数k，支付金额Pay，节省额S。

乘法，减法，比较。

1. 用户VIP状态与有效期表。
2. 剧集点播产品配置表（剧集ID、单集价、打包方案）。
3. 超前点播购买记录（用户、剧集、支付金额、时间）。
4. 收入分成结算数据。

视频付费，增值服务，打包折扣，腾讯视频。

1. 产品展示：剧《梦华录》更新至第20集，VIP可超前点播21-24集。单集价p=3元，打包4集价P_4=10元。
2. 节省计算：单买4集需4 * 3=12元，打包省12-10=2元。
3. 用户选择：用户U是VIP，想提前看21-23集（3集）。单买需9元。但打包4集10元，解锁21-24集，更划算。U选择打包支付10元。
4. 解锁观看：U立即获得21-24集的观看权限。

R-1620​

支付宝余额宝产品部

用户、基金公司

运营/收益与分配规则

货币基金“万份收益”每日计算与分配模型

余额宝对接的货币基金，每日计算“每万份基金份额收益”（即万份收益），根据用户持有的份额，将当日收益累加到其账户，收益每日结转，复利计算。

余额宝万份收益每日计算与分配模型

向用户清晰展示每日收益，提供稳定的现金管理工具，增强用户对平台的资金沉淀和粘性。

1. 收益计算基于基金的实际投资回报。
2. 收益每日计算，次日下午15点前显示。
3. 用户持有份额以当日收盘后登记为准。
4. 收益免征个人所得税（目前）。

输入：基金当日万份收益I_per10k、用户持有份额S_units（以基金单位计）。
输出：用户当日收益Income、累计收益Income_total。
流程：1. 基金公司每日公布万份收益I_per10k（元）。
2. 系统获取用户在当日交易截止时间（通常15:00）前确认的持有份额S。
3. 计算当日收益：Income = S / 10000 * I_per10k。
4. 将Income加入用户余额宝账户总额，同时更新累计收益。
5. 收益可用于消费或再投资。

中

设用户在t日收盘后持有的基金份额为S_t（单位：份）。
t日基金的万份收益为R_t（单位：元/万份）。
用户t日收益：I_t = (S_t / 10000) * R_t。
份额更新：S_{t+1} = S_t + I_t（收益自动再投资，份额增加）。
累计收益为Σ I_t。

常量：单位换算10000份。
变量：用户份额S_t，万份收益R_t，当日收益I_t，累计收益ΣI_t。

除法，乘法，求和。

1. 基金每日万份收益公告。
2. 用户余额宝份额持有明细（每日快照）。
3. 收益计算与分配流水记录。
4. 用户总资产与累计收益表。

货币基金，万份收益，复利，现金管理，支付宝。

1. 获取数据：2025年3月10日，天弘余额宝货币基金万份收益R=0.6元。
2. 用户份额：用户U在3月9日15:00后至3月10日15:00前未申购赎回，持有份额S=50000份。
3. 计算收益：I = (50000 / 10000) * 0.6 = 5 * 0.6 = 3.0元。
4. 更新账户：3月11日，U的余额宝总额增加3元，份额变为50000 + 3/1 = 50003份（假设基金单位净值始终为1元）。累计收益增加3元。

R-1621​

微信公众平台

作者、读者

销售/内容与付费规则

微信公众号“付费阅读”单篇文章定价与试读模型

公众号作者可对单篇文章设置付费阅读，读者需支付一定费用（如1-208元间）才能阅读全文。系统支持设置免费试读比例（如前20%），并提供付费后72小时内的退款通道。

微信公众号付费文章定价与试读模型

为优质内容创作者提供直接变现渠道，鼓励深度内容生产，同时保障读者付费后的权益。

1. 付费功能需申请开通并符合条件。
2. 定价有范围限制。
3. 试读比例可设置。
4. 付费后一定时间内可申请退款（如无严重争议）。

输入：文章总字数L_total、作者设置试读比例r_free、文章定价P、用户支付状态Paid。
输出：用户可见内容Content_visible、是否需要付费NeedPay、退款资格Refundable。
流程：1. 作者发布文章，设置P元和r_free（如20%）。
2. 读者打开文章，系统展示前r_free*L_total字作为免费试读，后续内容遮盖，提示付费。
3. 读者支付P元后，可阅读全文。
4. 支付后72小时内，读者可在文章页面申请退款，若作者无异议，系统原路退款。

中

设文章总长度为L，试读比例为α（0≤α<1）。
免费部分长度：L_free = α * L。
对于未付费用户，显示前L_free个字符；对于已付费用户，显示全部L个字符。
定价P在区间[P_min， P_max]内。
退款窗口期为支付后的T_refund时间内（如72小时）。

常量：定价区间[P_min， P_max]，退款窗口T_refund。
变量：文章长度L，试读比例α，定价P，支付时间t_pay，当前时间t_now，是否可退款Refundable = (t_now - t_pay ≤ T_refund)。

乘法，比较，时间差。

1. 付费文章配置表（文章ID、定价、试读比例、发布时间）。
2. 用户付费记录（用户、文章、支付金额、时间）。
3. 退款申请与处理记录。
4. 内容分发与访问日志。

知识付费，内容变现，试读，退款，微信公众号。

1. 文章发布：作者A发布一篇深度分析，总字数L=5000字，设置试读α=20%，定价P=5元。
2. 读者体验：读者B打开文章，看到前1000字（5000 * 20%），后续内容被遮盖，提示“支付5元阅读全文”。
3. 付费阅读：B支付5元，立即解锁全文。
4. 退款机制：B阅读后觉得内容不符预期，在支付后24小时内申请退款。系统在作者无异议（如未遭恶意举报）的情况下，将5元退还给B。

R-1622​

贝壳找房交易平台

买家、卖家、经纪人

销售/佣金与分成规则

房产交易“中介佣金”分段累进计算模型

房产交易中介佣金按成交总价分段设置不同费率，累进计算。例如：100万以内部分费率2%，100-200万部分费率1.5%，200万以上部分费率1%。同时，佣金在买方和卖方之间按约定比例分摊。

贝壳找房房产交易佣金分段累进计算模型

使佣金费用与房屋总价更成比例，在高端房产交易中降低费率以促进成交，同时明确买卖双方责任。

1. 佣金费率及分段标准提前公示。
2. 买卖双方可协商佣金分摊比例（如买方承担）。
3. 佣金在交易完成后支付。
4. 可能存在政府指导价上限。

输入：房屋成交总价P_total、分段佣金费率表{(B1， r1)， (B2， r2)， ...}、买卖双方分摊比例(β_buyer， β_seller)。
输出：总佣金C_total、买方承担C_buyer、卖方承担C_seller。
流程：1. 根据成交价P_total，确定其落入的分段区间。
2. 按分段累进计算：C_total = Σ_{i} (min(P_total， B_i) - B_{i-1}) * r_i，其中B_0=0。
3. 根据分摊比例计算各方承担额：C_buyer = C_total * β_buyer， C_seller = C_total * β_seller。
4. 在交易流程完成后，分别向买卖双方收取。

中

设分段阈值为0 = T0 < T1 < T2 < ... < T_n，对应费率r1， r2， ...， r_n。
对于成交价P，总佣金：
C = Σ_{k=1}^{n} r_k * max(0， min(P， T_k) - T_{k-1})。
买方承担：C_b = α * C，卖方承担C_s = (1-α) * C，α为买方分摊比例。

常量：分段阈值T_k，费率r_k，买方分摊比例α。
变量：成交价P，总佣金C，买方佣金C_b，卖方佣金C_s。

分段函数，累加，最小值/最大值函数，乘法。

1. 房产成交信息表（房屋ID、成交价、时间）。
2. 佣金费率分段配置表。
3. 佣金分摊协议记录（合同）。
4. 佣金支付与结算流水。

房产中介，佣金，分段累进，交易服务费。

1. 确定参数：成交价P=280万元。费率表：0-100万部分r1=2%，100-200万部分r2=1.5%，200万以上部分r3=1%。买方承担全部佣金（α=1）。
2. 分段计算：
- 第一段：(100-0)*2% = 2万元。
- 第二段：(200-100)*1.5% = 1.5万元。
- 第三段：(280-200)*1% = 0.8万元。
3. 总佣金：C_total = 2+1.5+0.8=4.3万元。
4. 分摊：买方承担4.3万元，卖方承担0元。

R-1623​

携程机票搜索事业部

用户、航空公司、代理商

价格/波动与预测规则

机票“价格趋势预测”与“降价提醒”模型

系统基于历史价格数据、当前搜索量、航班上座率、提前预订天数等特征，预测未来一段时间内机票价格的波动趋势。当预测未来可能降价时，可向用户发送“降价提醒”通知。

携程机票价格趋势预测与智能提醒模型

帮助用户做出更明智的购票决策，提升用户满意度和平台粘性，增加机票业务的转化率。

1. 预测仅为参考，不保证准确。
2. 提醒功能需用户主动订阅（关注航班）。
3. 降价判断基于当前价格与预测价格的比较。
4. 考虑燃油附加费、税费等变动。

输入：航班信息Flight、历史价格序列{P_hist}、当前搜索量Q、提前天数D、用户订阅状态Subscribe。
输出：未来N天价格预测曲线{P_pred}、是否触发降价提醒Alert、建议购买时机Advice。
流程：1. 用户搜索航班并点击“关注”或“降价提醒”。
2. 系统收集该航班相关特征，输入时间序列预测模型（如LSTM、Prophet）。
3. 模型输出未来7天或起飞前的每日预测价格。
4. 监控实时价格，若当前价格P_now比昨日预测的最低价P_pred_min下降超过阈值δ，则向订阅用户推送提醒。

高

设航班f在时间t的价格为P_f(t)。
预测模型M以历史价格窗口`[t-H

R-1641​

京东价保中心

买家、卖家

价格/保价与补偿规则

电商“价格保护”自动退差价模型

用户在购买商品后，若在价保期内（如7天）该商品发生降价，系统自动或经用户申请，计算差价并退还。价保通常仅限同一商品同一促销属性（如颜色、规格）。

京东价格保护自动退差价模型

提升用户购物安全感，减少因降价导致的订单取消和售后纠纷，增强平台信任度。

1. 价保期从下单或收货开始计算。
2. 仅适用于自营商品和部分第三方商品。
3. 降价需发生在同一商品ID、同一销售属性下。
4. 需排除赠品、秒杀等特殊场景。

输入：用户订单Order、商品当前价格P_current、用户购买时价格P_original、价保期T_protect、当前时间T_now。
输出：是否在价保期内InPeriod、是否降价PriceDrop、差价金额Diff、退款操作Refund。
流程：1. 检查T_now是否在订单完成时间T_order后的T_protect内。
2. 抓取同一商品当前售价P_current。
3. 比较：若P_current < P_original，则计算差价Diff = P_original - P_current。
4. 触发退款流程，将Diff退至用户原支付账户。

中

设用户购买时间为t0，购买价为P0。
价保期为ΔT。
当前时间为t，当前价为P(t)。
价保条件：(t - t0 ≤ ΔT) ∧ (P(t) < P0)。
退差价金额：D = P0 - P(t)。

常量：价保期ΔT。
变量：购买时间t0，购买价P0，当前时间t，当前价P(t)，差价D。

时间差比较，减法。

1. 订单详情（商品ID、属性、价格、下单时间）。
2. 商品价格历史快照。
3. 价保申请与处理记录。
4. 退款流水。

价格保护，退差价，消费者权益，京东。

1. 检查时效：用户3月1日下单购买手机，价保期7天。3月5日检查，t - t0 = 4天 ≤ 7天，满足。
2. 比价：购买时价格P0=3000元，当前价格P(t)=2800元。
3. 判断降价：2800 < 3000，降价成立。
4. 计算差价：D = 3000 - 2800 = 200元。
5. 退款：系统自动将200元退至用户支付账户。

R-1642​

微信支付风控部

用户、商户

运营/风控与限额规则

微信支付“单笔/单日交易限额”动态调整模型

根据用户账户历史行为、信用评估、交易场景等因素，动态设置和调整单笔支付和单日累计支付的最高限额，以平衡便利性与风险控制。

微信支付交易限额动态风控模型

在保障支付安全、防范盗刷和洗钱等风险的前提下，尽可能满足用户大额支付需求，提升支付成功率。

1. 不同支付方式（零钱、银行卡）限额不同。
2. 不同商户类别码（MCC）限额不同。
3. 用户可通过验证身份信息提升限额。
4. 异常交易会触发临时限额降低。

输入：用户身份信息ID、支付方式Method、交易场景Scene（MCC）、历史行为History、风险评估分数RiskScore。
输出：当前单笔限额Limit_single、单日限额Limit_daily、是否触发验证NeedVerify。
流程：1. 获取用户基础限额L_base（根据身份认证等级）。
2. 根据支付方式Method和场景Scene，获取调整系数α。
3. 根据RiskScore获取风险系数β（高风险则β<1）。
4. 计算动态限额：Limit = L_base * α * β。
5. 若交易金额接近或超过Limit，触发额外验证（如短信、人脸）。

高

设用户基础限额为L0（向量，包含单笔、单日等）。
支付方式调整系数为α_m，场景调整系数为α_s，风险调整系数为β（0<β≤1）。
动态限额：L = L0 ⊙ α_m ⊙ α_s ⊙ β，其中⊙表示逐元素乘法。
对于单笔交易金额A，若A > L_single，则要求验证。

常量：基础限额向量L0，各类调整系数表。
变量：支付方式m，场景s，风险分数r，调整系数α_m， α_s， β，动态限额L。
向量：限额向量，系数向量。

向量乘法，逐元素操作。

1. 用户身份认证等级表。
2. 支付方式与场景限额系数表。
3. 用户交易行为与风险评分。
4. 限额调整与验证触发日志。

支付风控，交易限额，动态调整，身份验证。

1. 获取基础限额：用户U已完成实名认证，基础单笔限额L0_single=5000元，单日L0_daily=50000元。
2. 系数调整：U使用信用卡支付(α_m=1.2)，在珠宝店消费(MCC α_s=0.8)，近期风险评分正常(β=1)。
3. 计算动态限额：L_single = 5000 * 1.2 * 0.8 * 1 = 4800元，L_daily=50000 * 1.2 * 0.8 * 1=48000元。
4. 交易验证：U支付6000元，超过L_single，触发短信验证码验证。

R-1643​

滴滴出行算法部

乘客、司机

运营/匹配与调度规则

网约车“实时订单匹配”全局最优分配模型

将新产生的乘客订单与周围空闲司机进行实时匹配，目标是最大化全局匹配效率（如最小化平均等待时间、最小化总接驾距离），同时考虑司机接单意愿和乘客取消风险。

滴滴实时订单-司机全局最优匹配模型

缩短乘客等待时间，提高司机接单效率和收入，优化平台整体运力利用率和用户体验。

1. 匹配需在毫秒级完成。
2. 考虑司机方向、口碑值、是否顺路。
3. 考虑乘客历史取消率。
4. 为保留运力，可能故意不将最近司机匹配给订单。

输入：新订单O（起点Lo、终点Ld）、周围空闲司机集合D={D1， D2， ...}（位置L_i、状态S_i）、路况Traffic。
输出：最佳匹配司机D*、预计接驾时间ETA、预计接驾距离Dist。
流程：1. 筛选符合条件的司机（如状态为空闲、距离小于阈值）。
2. 为每个候选司机Di计算匹配成本C_i，可能包括：接驾距离d_i、接驾时间t_i、司机方向与订单方向夹角θ_i等。
3. 选择成本最小的司机：D* = argmin_{Di} C_i。
4. 向司机D*派发订单。

高

设订单o，司机i。
匹配成本函数：C(o， i) = w1 * d(o， i) + w2 * t(o， i) + w3 * θ(o， i) + ...，其中d为接驾距离，t为接驾时间，θ为方向偏差角，w为权重。
最优匹配：i* = argmin_i C(o， i)。
全局优化可能是多订单多司机的二分图匹配问题，使用匈牙利算法等求解。

常量：成本权重w1， w2， ...，筛选阈值。
变量：订单o，司机集合D，司机位置L_i，成本C_i，最优司机i*。
函数：距离函数d()，时间函数t()，方向函数θ()。

加权求和，最小值函数，优化算法。

1. 实时订单流（起点、终点、时间）。
2. 实时司机位置与状态流。
3. 实时路况与ETA数据。
4. 订单-司机匹配记录与结果。

实时匹配，运筹优化，网约车调度，匈牙利算法。

1. 订单产生：乘客P在A点下单去B点。
2. 司机筛选：系统筛选周围3公里内空闲司机5名：D1(距离1km，方向顺路)， D2(距离0.8km，方向相反)， D3(距离2km，方向顺路)。
3. 成本计算：设成本C=距离*1 + 方向系数*5，方向顺路为0，反方向为1。则：
C1=1 * 1+0 * 5=1， C2=0.8 * 1+1 * 5=5.8， C3=2 * 1+0 * 5=2。
4. 最优匹配：C1最小，选择D1派单。

R-1644​

抖音推荐算法部

用户、内容创作者

运营/分发与排序规则

短视频“冷启动流量池”分级推荐模型

新发布的视频首先进入一个小流量池进行测试，根据其在该池中的核心互动指标（完播率、点赞率、评论率、分享率）决定是否推送给更大流量池，形成分级放大或淘汰机制。

抖音短视频冷启动流量池分级推荐模型

高效筛选出有潜力的优质内容，给予更多曝光，同时控制低质内容的传播，优化平台内容生态和用户粘性。

1. 初始流量池大小固定（如500播放）。
2. 考核指标有明确阈值或排名。
3. 不同类别内容可能有不同考核标准。
4. 存在人工审核干预机制。

输入：新视频V、初始曝光量N0、在初始池中的互动数据E（完播率r_complete、点赞率r_like等）。
输出：是否晋级Promote、下一级流量池大小N_next。
流程：1. 视频发布后，随机推送给N0个用户（冷启动池）。
2. 收集N0次曝光后的互动数据E。
3. 计算视频质量分数S = f(r_complete， r_like， r_comment， r_share)。
4. 若S超过阈值θ1，则晋级到下一级流量池（如N1=5000曝光）。
5. 重复步骤2-4，可多级放大，直至进入热门池。

高

设视频v在流量池k中获得曝光N_k，互动数据向量为E_k = (r_c， r_l， r_m， r_s)（完播、点赞、评论、分享率）。
质量分数：S_k = w·E_k = w1*r_c + w2*r_l + w3*r_m + w4*r_s。
晋级条件：S_k > θ_k，其中θ_k为第k级池的晋级阈值。
若晋级，则N_{k+1} = γ * N_k（γ>1）。

常量：初始曝光N0，权重向量w，各级阈值θ_k，放大系数γ。
变量：视频v，当前池级别k，互动数据E_k，质量分数S_k，下一级曝光N_{k+1}。

向量点积，比较，乘法。

1. 视频发布元数据（作者、类别、时长）。
2. 冷启动曝光日志（用户、视频、是否曝光）。
3. 用户互动行为日志（完播、点赞、评论、分享）。
4. 流量池晋级决策记录。

推荐系统，冷启动，流量池，内容分级，抖音。

1. 冷启动：新视频V发布，进入500人流量池。
2. 数据收集：500次曝光后，完播率r_c=40%，点赞率r_l=10%，评论率r_m=2%，分享率r_s=1%。
3. 质量评分：设权重w=(0.5，0.3，0.1，0.1)，S=0.5 * 0.4+0.3 * 0.1+0.1 * 0.02+0.1 * 0.01=0.2+0.03+0.002+0.001=0.233。
4. 晋级判断：一级池阈值θ1=0.2，S=0.233>0.2，晋级。
5. 放大：进入二级池，曝光量N1=5000。

R-1645​

美团外卖运营部

用户、商家

销售/补贴与拉新规则

外卖“满减优惠”与“配送费减免”叠加计算模型

商家设置满减活动（如满30减5），平台同时提供配送费减免券。下单时，先计算商品总价是否满足满减门槛，再计算配送费，最后叠加可用优惠券，得出最终实付金额。

美团外卖满减与配送费优惠叠加计算模型

通过商家满减和平台补贴的组合，降低用户实际支付成本，刺激下单转化，同时平衡商家利润和平台营销支出。

1. 满减仅限商品价格，不含打包费、配送费。
2. 配送费减免券有使用门槛（如满20元可用）。
3. 优惠叠加顺序：满减 -> 折扣券 -> 配送费券。
4. 部分特殊商品（如特价菜）不参与满减。

输入：商品总价P_food、打包费P_pack、配送费P_delivery、满减规则(X， Y)、可用优惠券列表Coupons（如配送费减C_del）。
输出：满足满减后的商品价P_food'、配送费减免后P_delivery'、最终实付P_final。
流程：1. 判断P_food是否满足满减门槛X，若满足，则P_food' = P_food - Y。
2. 计算总餐品费：P_meal = P_food' + P_pack。
3. 检查配送费券使用条件（如P_meal ≥ threshold），若满足，则P_delivery' = max(0， P_delivery - C_del)。
4. 计算总价：P_total = P_meal + P_delivery'。
5. 应用其他平台或商家折扣券（如有），得出P_final。

中

设商品总价F，满减规则：满M减N。
满减后商品价：F' = F - N * I(F ≥ M)，其中I()为指示函数。
设打包费P，配送费D，配送费券面值C，使用门槛T。
配送费减免后：D' = D - C * I(F' + P ≥ T)，且D' ≥ 0。
最终实付：Pay = F' + P + D'，再减去其他折扣券。

常量：满减门槛M，减额N，配送费券门槛T，面值C。
变量：商品价F，打包费P，配送费D，满减后F'，减免后配送费D'，实付Pay。
指示函数：I(condition)。

指示函数，减法，最大值函数。

1. 订单商品明细与价格。
2. 商家满减活动配置。
3. 用户可用优惠券列表（类型、面值、门槛）。
4. 优惠叠加计算中间结果与最终订单金额。

优惠叠加，满减，配送费减免，外卖下单。

1. 满减计算：商品总价F=35元，满30减5，满足，F'=35-5=30元。打包费P=2元。
2. 配送费券检查：餐品费F'+P=32元，配送费券门槛T=20元，满足。配送费D=5元，券面值C=3元，D'=5-3=2元。
3. 计算总价：Pay = 30 + 2 + 2 = 34元（原价35+2+5=42元，共优惠8元）。

R-1646​

腾讯游戏健康系统

用户（未成年人）、家长

运营/防沉迷与时长规则

未成年人游戏“时长与消费”双限模型

对实名认证为未成年人的用户，限制其游戏时长（如平日1.5小时/天，节假日3小时/天）和单次消费金额（如单次≤100元，每月≤400元）。超时后强制下线，超限后禁止消费。

腾讯游戏未成年人防沉迷时长与消费限制模型

落实监管部门要求，保护未成年人身心健康，防止过度游戏和非理性消费，履行企业社会责任。

1. 基于公安实名认证系统验证身份和年龄。
2. 时长计算为累计在线游戏时间。
3. 消费限额按自然日/月累计。
4. 家长可通过守护平台设置更严格的限制。

输入：用户身份ID、年龄Age、本次登录时长Δt、本次消费金额Δc、当日已玩时长T_today、当月已消费C_month。
输出：是否允许继续游戏AllowPlay、是否允许本次消费AllowPay、剩余时长T_left、剩余消费额度C_left。
流程：1. 用户登录时，检查年龄Age<18则启用防沉迷。
2. 游戏过程中，累计T_today。若T_today达到当日上限L_day，则强制下线。
3. 消费时，检查单次金额Δc是否超过单次上限L_once，以及C_month+Δc是否超过月上限L_month。任一超限则禁止支付。

中

设未成年人当日时长上限为L_d（平日1.5h，节假日3h），当月消费上限为L_m。
单次消费上限为L_o。
游戏时长控制：允许游戏条件为T_today + Δt ≤ L_d。
消费控制：允许消费条件为(Δc ≤ L_o) ∧ (C_month + Δc ≤ L_m)。

常量：时长上限L_d，单次消费上限L_o，月度消费上限L_m。
变量：当日已玩时长T_today，本次时长Δt，当月已消费C_month，本次消费Δc。

加法，比较，逻辑与。

1. 用户实名认证信息（姓名、身份证、年龄）。
2. 用户游戏登录与时长日志。
3. 用户游戏消费记录。
4. 防沉迷规则配置表（时长、消费上限）。

防沉迷，未成年人保护，游戏时长，消费限额。

1. 登录检查：用户U，年龄12岁，周六登录游戏。节假日时长上限L_d=3小时。今日已玩T_today=2小时。
2. 时长监控：U本次玩了Δt=1小时，累计2+1=3小时，达到上限。系统在满3小时时强制弹出提示并下线。
3. 消费检查：U想购买68元皮肤。单次上限L_o=100元，本月已消费C_month=350元，月上限L_m=400元。检查：68 ≤ 100且350+68=418 > 400，超过月上限，支付被禁止。

R-1647​

闲鱼平台治理部

卖家、买家

销售/信用与交易规则

二手交易“闲鱼信用速卖”估价与预付款模型

用户出售高信用商品（如手机）时，可选择“信用速卖”。系统基于商品型号、成色、市场行情给出预估回收价，并提供部分预付款。买家确认收货后，尾款结清。若商品与描述不符，平台介入扣款。

闲鱼信用速卖估价与担保交易模型

简化二手交易流程，加快卖家回款速度，降低买家风险，提升高价值二手商品的交易效率和信任度。

1. 仅限部分高信用卖家和特定品类。
2. 估价基于公开市场数据和算法模型。
3. 预付款比例固定（如50%-80%）。
4. 买家有验货期，确认后尾款到账。

输入：商品信息Item（品牌、型号、成色、配置）、市场行情数据Market、卖家信用Credit_seller。
输出：预估回收价P_estimate、预付款金额P_advance、尾款金额P_final。
流程：1. 卖家提交商品信息，选择“信用速卖”。
2. 系统调用估价模型，结合市场数据给出P_estimate。
3. 根据P_estimate和卖家信用，计算预付款P_advance = r * P_estimate（r为预付款比例）。
4. 卖家发货，平台垫付P_advance给卖家。
5. 买家收货验货，确认无误后，平台支付尾款P_final = P_estimate - P_advance给卖家。若不符，则协商或扣除部分款项。

中高

设商品估价为V，预付款比例为α（0<α<1）。
预付款：A = α * V。
尾款：F = V - A = (1-α) * V。
估价模型V = f(brand， model， condition， config， market_price)，为回归模型。

常量：预付款比例α，估价模型参数。
变量：商品属性（品牌、型号、成色等），市场价market_price，估价V，预付款A，尾款F。

乘法，减法，回归模型。

1. 商品信息提交表（品类、型号、成色、照片）。
2. 二手市场行情价格数据库。
3. 卖家信用评分历史。
4. 信用速卖订单与支付流水（预付款、尾款）。

二手交易，信用体系，估价模型，预付款，闲鱼。

1. 提交信息：卖家S（信用极好）出售一部iPhone 13， 9成新， 128GB。提交信息。
2. 系统估价：估价模型参考市场均价、成色、型号，给出V=3000元。
3. 计算预付款：预付款比例α=70%，A=3000 * 0.7=2100元。
4. 发货与垫付：S发货，平台垫付2100元给S。
5. 验货与尾款：买家B收货验货无误，确认。平台支付尾款F=3000-2100=900元给S。交易完成。

R-1648​

哔哩哔哩大会员运营部

用户、内容版权方

销售/会员与权益规则

视频平台“大会员”免费观影券每月发放模型

大会员用户每月可获得若干张“免费观影券”，用于观看付费电影/剧集（原需单独购买）。观影券有有效期（如当月），不可累计，每月固定时间发放。

B站大会员月度免费观影券发放与使用模型

增加大会员权益价值，激励用户续费，同时促进平台内付费内容的消费，提升用户活跃度和停留时长。

1. 仅限有效期内的大会员领取。
2. 观影券仅用于抵扣指定付费内容。
3. 每月发放数量固定（如2-4张）。
4. 过期未用自动作废。

输入：用户大会员状态IsVIP、当前月份Month、本月已发放数量N_sent、每月配额Q、用户已使用数量N_used。
输出：本月是否可领取CanGet、可领取张数N_get、剩余可用张数N_left。
流程：1. 每月固定日期（如1日），系统检查用户IsVIP状态。
2. 若为有效大会员且N_sent < Q，则发放N_get = Q - N_sent张观影券至用户账户。
3. 用户观看付费内容时，若N_left > 0，可选择使用一张观影券抵扣。
4. 月底未使用的观影券清零。

低

设每月发放配额为Q。
用户u在月份m的已发放数为S_m，已使用数为U_m。
月初发放：若IsVIP_u = True，则S_m = Q，U_m = 0。
可用张数：A_m = S_m - U_m。
使用条件：对于一部付费内容，若A_m > 0，则可使用一张，U_m += 1。

常量：月度配额Q。
变量：用户VIP状态IsVIP，月份m，已发放S_m，已使用U_m，可用A_m。

赋值，减法。

1. 大会员订阅状态表。
2. 月度观影券发放记录（用户、月份、数量）。
3. 观影券使用与核销流水（内容、用户、时间）。
4. 付费内容库与价格。

会员权益，免费观影券，内容消费，B站。

1. 月初发放：用户U是大会员，4月1日，系统发放Q=4张观影券到其账户，有效期至4月30日。
2. 使用：4月10日，U想观看一部付费电影（原价5元），账户有4张券，选择使用1张，免费观看。U_4=1，A_4=3。
3. 过期：4月30日24点，剩余3张未用券自动作废。5月1日，系统发放新的4张券。

R-1649​

高德地图打车事业部

乘客、多家网约车平台

运营/比价与派单规则

聚合打车“多平台比价与一键呼叫”模型

用户输入行程后，系统同时向多个合作网约车平台（如滴滴、曹操、T3）询价，并展示各平台预估价格、车型、等待时间。用户可选择或由系统智能推荐最优选项，一键呼叫。

高德地图聚合打车多平台比价与智能派单模型

为用户提供更全面的价格和运力选择，提升叫车成功率和体验，同时为合作平台导流，收取技术服务费。

1. 需与各平台建立API对接。
2. 比价结果有有效期（如30秒）。
3. 智能推荐可能基于价格、速度、成功率综合加权。
4. 用户可设置偏好（如首选低价、首选快车）。

输入：行程请求R（起点、终点）、合作平台列表Platforms、用户偏好Pref。
输出：各平台报价列表Quotes（价格P_i、车型T_i、等待时间W_i）、智能推荐结果Recommend。
流程：1. 用户发起行程请求。
2. 系统并发向各合作平台API发送询价请求。
3. 接收各平台返回的报价信息。
4. 根据用户偏好Pref（如最低价、最快接驾）对Quotes排序，或计算综合得分Score_i = w1*P_i + w2*W_i，推荐Score最优者。
5. 用户确认后，向对应平台发起叫车请求。

中

设合作平台集合为{P1， P2， ...， Pn}。
平台i的报价为三元组(price_i， wait_i， type_i)。
综合评分：S_i = α * normalize(price_i) + β * normalize(wait_i)，其中normalize为归一化函数，α+β=1。
智能推荐：i* = argmin_i S_i（若偏好最低综合成本）。
用户也可手动选择。

常量：权重α， β，归一化函数。
变量：平台报价price_i， wait_i， type_i，综合评分S_i，推荐平台i*。
集合：平台集合，报价集合。

加权求和，归一化，最小值函数。

1. 用户行程请求记录（起点、终点、时间）。
2. 各合作平台API接口与响应数据。
3. 比价结果展示与用户选择日志。
4. 叫车成功率与用户反馈数据。

聚合打车，比价，智能推荐，高德地图。

1. 询价：用户从A到B，高德向滴滴、曹操、T3发送请求。
2. 获取报价：滴滴：价格25元，等待5分钟；曹操：22元，等待8分钟；T3：28元，等待3分钟。
3. 智能推荐：设用户偏好平衡，权重α=0.6（价格），β=0.4（等待）。归一化后计算综合得分：滴滴S1=0.6 * 0.5+0.4 * 0.4=0.46，曹操S2=0.6 * 0.2+0.4 * 0.8=0.44，T3S3=0.6 * 0.8+0.4 * 0.2=0.56。曹操得分最低（成本最低），被推荐。
4. 一键呼叫：用户点击推荐或手动选择曹操，高德向曹操平台发起叫车。

R-1650​

拼多多果园游戏部

用户、平台、商家

运营/任务与奖励规则

电商小游戏“多多果园”水滴收集与果树成长模型

用户通过完成指定任务（浏览商品、下单、签到等）获得“水滴”，浇灌虚拟果树。果树经历多个成长阶段，最终成熟可兑换真实水果。水滴有每日获取上限，果树成长有进度条。

拼多多多多果园任务-水滴-成长兑换模型

通过游戏化任务提升用户活跃度、停留时长和购买转化，实现用户激励和电商导流。

1. 水滴任务每日刷新，有完成次数限制。
2. 果树成长各阶段所需水滴量不同。
3. 兑换实物水果需达到100%成熟度。
4. 水滴可能过期（如7天未使用）。

输入：用户任务完成情况Tasks、当前果树阶段Stage、当前进度Progress、水滴余额Water。
输出：本次完成任务获得水滴ΔW、浇灌后新进度Progress'、是否可兑换CanRedeem。
流程：1. 用户完成一个任务（如浏览商品60秒），系统校验后发放对应水滴ΔW。
2. 用户使用水滴浇灌果树，消耗W_use滴水滴。
3. 根据当前阶段Stage，计算W_use可转化的进度ΔP = W_use / Need(Stage)，其中Need(Stage)是该阶段总需水滴。
4. 更新进度：Progress' = Progress + ΔP。若Progress' ≥ 1，则进入下一阶段或成熟。
5. 当果树进度达到100%（所有阶段完成），可兑换实物水果。

中

设果树有n个阶段，阶段k所需总水滴为N_k。
用户在当前阶段k的已浇灌水滴为W_k，进度为P_k = W_k / N_k。
浇灌更新：若本次使用w滴水滴，则W_k' = W_k + w，P_k' = W_k' / N_k。
若P_k' ≥ 1，则阶段k完成，进入阶段k+1，重置W_{k+1}=0。
总进度：P_total = (Σ_{i=1}^{k-1} N_i + W_k) / (Σ_{i=1}^{n} N_i)。

常量：各阶段需水滴N_k，任务奖励水滴ΔW_task。
变量：当前阶段k，当前阶段已浇灌W_k，进度P_k，总进度P_total，水滴余额Water。

除法，加法，求和。

1. 用户任务完成日志（任务类型、完成时间、奖励水滴）。
2. 用户水滴账户流水（获得、消耗、余额）。
3. 果树成长阶段与进度记录。
4. 实物兑换订单记录。

游戏化，用户激励，任务系统，电商导流，拼多多。

1. 任务完成：用户U完成“浏览商品60秒”任务，获得ΔW=10滴水滴，余额Water=50。
2. 浇灌：U对果树使用20滴水滴。当前为第2阶段，该阶段总需N2=100滴，已浇W2=30滴。
3. 进度计算：W2'=30+20=50，P2'=50/100=50%。
4. 阶段判断：P2'=50% < 100%，未进入下一阶段。
5. 总进度：假设第1阶段需N1=50滴已完成，总需50+100=150滴，总进度P_total=(50+50)/150=66.7%。

R-1651​

中国铁路12306

乘客、铁路局

销售/售票与分配规则

火车票“候补购票”排队与兑现模型

当车次车票售罄时，乘客可提交候补订单，预付票款。系统根据退票、改签等产生的余票，按候补订单的提交时间、车次、席别顺序，自动为候补乘客分配车票。

12306候补购票排队与余票分配模型

在票源紧张时，为乘客提供官方、公平的排队购票渠道，减少第三方抢票软件干扰，提高票务分配效率。

1. 候补订单需预付全款，兑现失败全额退款。
2. 同一车次同一席别可候补多个日期。
3. 候补成功率不保证，与排队位置和退票量相关。
4. 截止兑现时间前（如开车前2小时）未成功则退款。

输入：候补订单Order（车次Train、席别Seat、提交时间T_submit）、余票释放事件TicketAvailable（票数N、时间T_available）。
输出：候补订单兑现状态Status（成功/失败）、兑现时间T_fulfill。
流程：1. 乘客提交候补订单，进入对应车次、席别的候补队列，按T_submit排序。
2. 当有退票或改签释放余票N张时，系统从队列头部开始，为前N个候补订单兑现车票。
3. 兑现成功者扣款出票，并从队列中移除。
4. 若在截止兑现时间前未成功，则订单自动取消，退款。

中高

设某一车次-席别的候补队列为Q，按提交时间t升序排列。
当在时间τ有m张余票释放时，系统从Q中取出前`min(

Q

， m)个订单进行兑现。<br>兑现成功的订单从Q中移除。<br>设订单i的提交时间为t_i，兑现截止时间为T_deadline。若在[t_i， T_deadline]`内未兑现，则失败退款。

常量：兑现截止时间T_deadline。
变量：候补队列Q，订单提交时间t_i，余票释放时间τ，释放票数m，兑现状态Status_i。

队列，排序，最小值函数。

1. 候补订单提交记录（用户、车次、席别、提交时间）。
2. 余票释放监控日志（车次、席别、票数、时间）。
3. 候补兑现成功/失败记录。
4. 退款处理流水。

R-1652​

拼多多拼团运营部

买家、卖家

销售/拼团与成团规则

电商“两人拼团”成功与失败模型

用户发起或参与一个拼团订单，需在有效期内（如24小时）凑齐指定人数（通常2人）并完成支付，则拼团成功，否则失败自动退款。

拼多多两人拼团成团与自动退款模型

利用社交裂变快速成单，降低获客成本，提升商品销量和曝光。

1. 拼团价低于单独购买价。
2. 成团有效期固定，不可延长。
3. 参团者需支付相同拼团价。
4. 失败后自动退款至原支付渠道。

输入：拼团订单GroupOrder、成团所需人数N、当前参团人数M、开团时间T_start、有效期T_valid。
输出：拼团状态Status（进行中/成功/失败）、成功时间T_success或失败退款时间T_refund。
流程：1. 用户开团，创建拼团订单，状态为“进行中”，开始计时。
2. 其他用户参团，M增加。
3. 实时检查：若M ≥ N，则标记为成功，通知所有参团者，安排发货。
4. 若到达T_start + T_valid时M < N，则标记为失败，系统自动发起退款。

低

设成团所需人数为K（通常为2）。
开团时间为t0，有效期为ΔT。
在时间t，已参团人数为n(t)。
成功条件：∃ t ∈ [t0， t0+ΔT]， s.t. n(t) ≥ K。
失败条件：∀ t ∈ [t0， t0+ΔT]， n(t) < K。

常量：成团人数K，有效期ΔT。
变量：开团时间t0，当前时间t，已参团人数n(t)，状态Status。

存在量词，全称量词，比较。

1. 拼团订单主表（团ID、商品、拼团价、开团时间、状态）。
2. 参团记录表（团ID、用户、参团时间）。
3. 定时任务扫描未成团即将过期订单。
4. 退款流水表。

社交电商，拼团，成团逻辑，自动退款。

1. 开团：用户A开团购买商品G，拼团价50元，需2人成团，有效期24小时。t0=当前时间，K=2，n(t0)=1。
2. 参团：3小时后，用户B参团支付。n(t0+3)=2。
3. 成功判断：n(t) = 2 ≥ K，拼团成功。系统更新状态为成功，通知A和B，发货。
4. 失败场景：若24小时内无他人参团，n(t0+24)=1 < K，则拼团失败，系统自动退款给A。

R-1653​

淘宝营销平台

买家、卖家

价格/积分与抵扣规则

电商“淘金币”抵扣现金比例模型

用户在支付时，可使用淘金币按一定比例抵扣现金（如100淘金币抵扣1元），抵扣上限为订单金额的一定比例（如10%）。淘金币可通过任务、购物等方式获得。

淘宝淘金币抵扣现金计算模型

提升用户粘性和活跃度，增加复购，构建平台内积分生态。

1. 淘金币有有效期（通常1年）。
2. 抵扣比例和上限可能随活动调整。
3. 部分商品或场景不支持抵扣。
4. 可与优惠券、红包等叠加使用。

输入：订单金额P、用户淘金币余额C、当前抵扣比例r（如1%）、抵扣上限比例u（如10%）。
输出：最大可抵扣金额D_max、实际使用淘金币数量C_use、最终抵扣金额D、订单实付P_final。
流程：1. 计算最大可抵扣金额：D_max = P * u。
2. 根据比例r计算所需淘金币：C_need = D_max / r。
3. 用户选择使用淘金币数量C_use，不超过min(C， C_need)。
4. 实际抵扣金额D = C_use * r。
5. 订单实付P_final = P - D。

低

设订单金额为A，淘金币余额为B，抵扣比例为α（即α元/金币），抵扣上限比例为β。
最大可抵扣金额：D_max = A * β。
所需金币：C_need = D_max / α。
实际使用金币：C_use = min(B， C_need)。
实际抵扣：D = C_use * α。
实付：Pay = A - D。

常量：抵扣比例α，上限比例β。
变量：订单金额A，金币余额B，最大可抵扣D_max，所需金币C_need，实际使用C_use，实际抵扣D，实付Pay。

乘法，除法，最小值函数。

1. 用户淘金币账户（余额、有效期）。
2. 订单金额明细。
3. 淘金币抵扣比例与上限配置表。
4. 抵扣使用与核销记录。

积分体系，现金抵扣，用户忠诚度，淘宝。

1. 计算上限：订单金额A=200元，上限比例β=10%，D_max=200 * 0.1=20元。
2. 计算所需金币：抵扣比例α=0.01元/金币（100金币抵1元），C_need=20/0.01=2000金币。
3. 用户余额：用户有B=1500金币。
4. 实际使用：C_use=min(1500，2000)=1500金币。
5. 实际抵扣：D=1500 * 0.01=15元。
6. 实付：Pay=200-15=185元。

R-1654​

腾讯游戏增值服务部

玩家、平台

销售/首充与奖励规则

游戏“首次充值”双倍钻石奖励模型

玩家在游戏中首次充值任意金额，即可获得相当于充值金额双倍的游戏货币（如钻石）奖励。仅限首次，且通常有最低充值门槛。

腾讯游戏首充双倍钻石奖励模型

降低玩家首次付费门槛，提升付费转化率，培养付费习惯，增加游戏收入。

1. 仅限账号首次充值，以区服为单位。
2. 充值金额需达到最低要求（如1元）。
3. 双倍奖励部分为赠送，不计入VIP成长值等。
4. 活动长期有效，但可能调整。

输入：玩家账号ID、区服Server、本次充值金额R、是否首次充值IsFirst、最低充值门槛R_min。
输出：是否触发双倍奖励Eligible、获得游戏货币总额V_total、其中赠送额V_bonus。
流程：1. 玩家发起充值，选择金额R。
2. 系统检查该账号在该区服是否已有充值记录。若无，则IsFirst=True。
3. 检查R ≥ R_min。
4. 若IsFirst=True且R ≥ R_min，则Eligible=True，计算V_total = R * 2 * k（k为钻石兑换比例，如1元=10钻石），V_bonus = R * k。
5. 发放V_total钻石至玩家账户。

低

设充值金额为M（元），钻石兑换比例为γ（钻石/元），即1元兑换γ钻石。
首次充值双倍奖励：若IsFirst=True且M ≥ M_min，则获得钻石总数D_total = 2 * γ * M。
其中基础钻石D_base = γ * M，奖励钻石D_bonus = γ * M。
否则，D_total = γ * M。

常量：兑换比例γ，最低充值门槛M_min。
变量：充值金额M，是否首次IsFirst，获得钻石总数D_total，奖励钻石D_bonus。

乘法，条件判断。

1. 玩家账号区服充值记录表。
2. 游戏货币兑换比例配置。
3. 首充活动配置（最低门槛、奖励倍数）。
4. 钻石发放流水记录。

游戏变现，首充奖励，付费转化，腾讯游戏。

1. 充值请求：玩家在1区充值M=6元，兑换比例γ=10钻石/元，最低门槛M_min=1元。
2. 检查首充：查询记录，该账号在1区无充值记录，IsFirst=True。
3. 检查门槛：6 ≥ 1，满足。
4. 计算奖励：D_total = 2 * 10 * 6 = 120钻石。其中基础D_base=60，奖励D_bonus=60。
5. 发放：向玩家账户发放120钻石。

R-1655​

腾讯云计费中心

用户、平台

财务/计费与停用规则

云服务“按量计费”余额不足自动停服模型

对于后付费的按量计费云资源（如CVM、COS），系统监控用户账户余额。当余额低于阈值（如0元）时，发送预警；当余额为负且持续一定时间（如2小时）后，自动停止服务以避免欠费扩大。

腾讯云按量计费资源欠费停服模型

控制平台坏账风险，提醒用户及时充值，保障云服务资源的合理使用和回收。

1. 余额检查有固定频率（如每小时）。
2. 停服前有多次提醒（短信、邮件、站内信）。
3. 停服后数据会保留一段时间（如7天）。
4. 充值后需手动重启服务。

输入：用户账户余额B、按量计费资源列表Resources、各资源消费速率Rate_i、预警阈值T_warn（如0）、停服阈值T_stop（如-2小时欠费）。
输出：预警状态Alert、停服操作StopAction、停服资源列表StoppedList。
流程：1. 定期（如每小时）检查账户余额B。
2. 若B ≤ T_warn，发送余额不足预警。
3. 若B < 0，开始计时欠费时长D。
4. 当D ≥ T_stop（如2小时），对Resources中所有按量计费资源执行停服操作，并通知用户。
5. 用户充值后，余额恢复为正，需手动在控制台重启资源。

中

设账户余额为B(t)，是时间t的函数，随消费减少。
欠费开始时间为t0，满足B(t0) < 0。
停服阈值为ΔT（时间长度）。
停服条件：(B(t) < 0) ∧ (t - t0 ≥ ΔT)。
当条件满足时，对资源集合R执行停服操作Stop(R)。

常量：预警阈值T_warn，停服时长阈值ΔT。
变量：账户余额B(t)，欠费开始时间t0，当前时间t，欠费时长D=t-t0，资源集合R。

函数，不等式，逻辑与。

1. 用户账户余额与消费流水。
2. 按量计费资源列表及其计费项。
3. 余额预警与欠费通知记录。
4. 资源停服操作日志。

云计算，后付费，欠费管理，资源停服，腾讯云。

1. 余额检查：用户账户余额B=1.5元，每小时消费约1元。1小时后检查，B=0.5元，未触发预警。
2. 欠费开始：又1小时后，B=-0.5元，B<0，记录t0为当前时间，发送欠费预警。
3. 计时停服：2小时（ΔT）后，t - t0 = 2小时，B(t)仍<0。满足停服条件。
4. 执行停服：系统自动停止该用户所有按量计费云服务器、数据库等资源。

R-1656​

网易云音乐会员中心

用户、版权方

销售/会员与权限规则

音乐App“会员免费听”歌曲范围与下载模型

付费会员可免费收听平台内绝大多数歌曲（除少数数字专辑需单独购买），并可下载标准音质歌曲至本地（有数量限制）。非会员仅可试听部分片段或收听带广告的完整版。

网易云音乐会员免费听歌与下载权限模型

推动用户订阅会员，实现内容付费变现，同时保障版权方利益，区分会员与非会员体验。

1. 免费听歌范围覆盖曲库绝大部分，但可能随版权变动。
2. 下载的歌曲有DRM保护，仅限本账号在本App内播放。
3. 下载数量可能有上限（如300首）。
4. 会员过期后，下载歌曲无法播放。

输入：用户会员状态IsVIP、歌曲版权信息Copyright（是否需单独购买）、用户操作Action（播放/下载）、已下载数量N_downloaded、下载上限L_download。
输出：是否允许播放AllowPlay、是否允许下载AllowDownload、播放音质Quality。
流程：1. 用户请求播放歌曲S。
2. 检查S的版权：若需单独购买，则无论是否会员都需购买；否则进入下一步。
3. 检查IsVIP：若为True，则AllowPlay=True，Quality=最高音质；若为False，则可能仅试听片段或带广告播放。
4. 用户请求下载歌曲S：检查IsVIP和N_downloaded < L_download，若均满足，则AllowDownload=True，下载标准音质；否则拒绝。

中

设歌曲s的播放权限为P(s)，下载权限为D(s)。
用户会员状态为V（布尔值）。
播放权限：AllowPlay(s) = (P(s) = "free") ∨ (V = True ∧ P(s) = "VIP")。
下载权限：AllowDownload(s) = (V = True) ∧ (N < L) ∧ (D(s) = "VIP")，其中N为已下载数，L为上限。
歌曲版权状态P(s)和D(s)由版权协议决定。

常量：下载上限L，版权状态映射。
变量：会员状态V，歌曲版权状态P(s)， D(s)，已下载数N，是否允许播放AllowPlay，是否允许下载AllowDownload。

逻辑或，逻辑与，比较。

1. 歌曲版权信息表（歌曲ID、播放权限、下载权限）。
2. 用户会员状态与有效期。
3. 用户已下载歌曲记录与计数。
4. 音质配置表。

数字音乐，会员权益，版权管理，下载限制，网易云音乐。

1. 播放请求：用户U（会员）请求播放歌曲A。查询版权，P(A)="VIP"。检查V=True，因此AllowPlay=True，以SQ音质播放。
2. 下载请求：U请求下载歌曲A。检查V=True，D(A)="VIP"，已下载数N=250，上限L=300，250<300，因此AllowDownload=True，下载标准音质文件。
3. 非会员场景：用户N（非会员）请求播放歌曲B，P(B)="VIP"，检查V=False，则AllowPlay=False，可能仅提供30秒试听。

R-1657​

京东金融白条产品部

用户、平台

财务/分期与手续费规则

消费金融“白条分期”手续费率与期数模型

用户使用京东白条支付时，可选择分期还款。分期期数（如3、6、12期）对应不同的手续费率（月费率或总费率）。手续费在分期后首期一次性收取或按月收取，分期本金按月偿还。

京东白条分期手续费计算模型

为用户提供消费信贷服务，赚取分期手续费收入，同时管理信用风险。

1. 分期功能需用户开通并有一定额度。
2. 不同期数费率不同，可能促销免息。
3. 手续费可能一次性收取或分期收取。
4. 提前结清可能减免部分手续费。

输入：分期本金P、分期期数N、月手续费率r（或总费率R）、手续费收取方式Method（首期一次性/按月）。
输出：每期应还本金P_per、每期手续费F_per、总手续费F_total、每期还款总额M_per。
流程：1. 用户选择分期期数N，系统显示对应月费率r或总费率R。
2. 计算每期本金：P_per = P / N。
3. 计算手续费：若为月费率，总手续费F_total = P * r * N；若为总费率，F_total = P * R。
4. 根据Method计算每期还款：若手续费一次性收取，则首期M_1 = P_per + F_total，后续M_i = P_per；若按月收取，则每期M_i = P_per + F_total / N。

中

设分期本金为A，期数为n，月手续费率为r（小数形式）。
总手续费：F = A * r * n。
每期本金：P_i = A / n。
每期手续费（按月收取）：f_i = A * r。
每期还款额（按月收手续费）：M_i = A / n + A * r。
若手续费首期一次性收取，则M_1 = A/n + F，M_i = A/n（i=2，...，n）。

常量：月手续费率r，期数n。
变量：本金A，总手续费F，每期本金P_i，每期手续费f_i，每期还款M_i。

乘法，除法，加法。

1. 白条分期费率表（期数、月费率、活动信息）。
2. 用户分期订单记录（本金、期数、费率、还款计划）。
3. 分期手续费收取流水（一次性或分期）。
4. 提前结清计算规则。

消费金融，分期付款，手续费，京东白条。

1. 用户选择：用户消费1200元，选择分3期，月费率r=0.5%，手续费按月收取。
2. 计算每期：每期本金P_per=1200/3=400元。每期手续费f_per=1200 * 0.5%=6元。每期还款M_per=400+6=406元。
3. 总手续费：F_total=6 * 3=18元。
4. 还款计划：第1期还406元，第2期406元，第3期406元。若手续费首期一次性收取，则首期还400+18=418元，后两期各还400元。

R-1658​

美团酒店平台运营部

用户、酒店商家

销售/预订与取消规则

酒店“不可取消”特价房预订规则

酒店商家可设置部分房型为“不可取消”特价房，价格低于可取消房型。用户预订此类房型后，若取消订单，将不退还任何费用。

美团酒店不可取消特价房预订与扣款模型

帮助酒店商家提高入住确定性，减少空房损失，同时为用户提供更低价格的选择。

1. 预订时需明确提示“不可取消”规则。
2. 支付需全额预付。
3. 不可取消订单一般不支持修改入住日期。
4. 因极端天气等不可抗力，平台可能介入协商。

输入：订单Order、房型取消政策Policy（不可取消）、订单状态Status（待入住/已取消）、取消时间T_cancel。
输出：是否允许取消AllowCancel、退款金额RefundAmount。
流程：1. 用户预订时，系统清晰展示“不可取消”政策，并需用户确认。
2. 用户支付全款。
3. 若用户在入住前任何时间申请取消，系统根据Policy判断：若为“不可取消”，则AllowCancel=False，RefundAmount=0。
4. 订单状态标记为“已取消（不可退款）”。

低

设订单支付金额为A，取消政策为P（P ∈ {"free"， "nonrefundable"}）。
退款金额函数：Refund(P) = { A， if P = "free"； 0， if P = "nonrefundable" }。
对于不可取消订单，Refund("nonrefundable") = 0。

常量：取消政策P。
变量：订单金额A，退款金额Refund。

条件函数（分段函数）。

1. 酒店房型取消政策配置表。
2. 订单详情（金额、政策、状态）。
3. 取消申请与处理记录。
4. 退款流水（无可退款则为0）。

酒店预订，取消政策，特价房，美团。

1. 预订展示：用户选择某酒店“特价大床房”，价格300元，政策明确显示“不可取消”。用户确认并支付300元。
2. 申请取消：入住前1天，用户因故申请取消。
3. 规则判断：系统读取订单政策P="nonrefundable"。
4. 结果：AllowCancel=False，RefundAmount=0。系统通知用户订单取消成功，但房费不退。

R-1659​

携程机票业务部

乘客、航空公司

销售/改签与费用规则

机票“改签手续费”阶梯式计算模型

乘客更改航班日期或时间需支付改签手续费。手续费通常根据机票票价、舱位、离起飞时间等因素阶梯式计算，且可能补收票价差额。

携程机票改签手续费计算模型

为乘客提供行程变更的灵活性，同时补偿航空公司的座位管理和运营成本，规范改签收费。

1. 改签需在原航班起飞前申请。
2. 手续费率或固定费用根据舱位规定不同。
3. 若新航班票价高于原票价，需补差价。
4. 特价机票可能不允许改签。

输入：原机票信息Ticket（票价F_old、舱位C、起飞时间T_depart）、新航班票价F_new、申请改签时间T_change、航空公司改签规则Rule。
输出：是否允许改签AllowChange、改签手续费Fee_change、票价差额Diff_fare、总需支付Total_pay。
流程：1. 检查机票C是否允许改签，若不允许则结束。
2. 根据Rule，基于T_depart - T_change（提前时间）和舱位C，确定手续费率r或固定费F_fixed。计算Fee_change = max(F_old * r， F_fixed)。
3. 计算票价差额：Diff_fare = max(0， F_new - F_old)。
4. 总需支付：Total_pay = Fee_change + Diff_fare。

中高

设原票价为P0，新票价为P1，改签手续费函数为g(P0， Δt， C)，其中Δt为提前改签时间，C为舱位。
票价差额：ΔP = max(0， P1 - P0)。
总费用：Total = g(P0， Δt， C) + ΔP。
函数g可能是比例费率g = α * P0（α随Δt和C变化），也可能是固定费用。

常量：改签规则表（舱位、时间区间、费率/固定费）。
变量：原票价P0，新票价P1，提前时间Δt，舱位C，手续费g，差价ΔP，总费用Total。

最大值函数，分段函数，查表。

1. 机票订单详情（票价、舱位、航班时间）。
2. 航空公司改签规则库（舱位、时间阶梯、费率）。
3. 实时航班票价查询接口。
4. 改签申请与费用计算记录。

机票改签，手续费，票价差额，携程。

1. 查询规则：用户欲改签机票，原票价P0=1000元，舱位Y，原起飞时间24小时后。航空公司规则：起飞前2小时外改签，Y舱手续费为票价的10%。
2. 计算手续费：Δt=24h > 2h，费率α=10%，g=1000 * 10%=100元。
3. 查询新票价：新航班票价P1=1200元。
4. 计算差价：ΔP=max(0，1200-1000)=200元。
5. 总费用：Total=100+200=300元。用户需支付300元完成改签。

R-1660​

滴滴出行定价策略部

乘客、司机

价格/动态与供需规则

网约车“高峰期/恶劣天气”动态调价模型

在出行高峰（如早晚高峰）或恶劣天气（雨雪）导致供需失衡时，平台在基础价格上乘以一个动态调价系数（如1.5倍、2.0倍），以激励更多司机上线，平衡供需。

滴滴出行动态调价（倍率）模型

通过价格杠杆调节高峰期和恶劣天气下的供需关系，缩短乘客等待时间，激励司机接单，提升平台整体运力效率。

1. 调价倍数有上限（如3倍）。
2. 调价区域和时段动态划定。
3. 向乘客明确展示调价倍数和原因。
4. 调价部分收入大部分归司机。

输入：基础价格P_base、实时供需比R（需求/供给）、天气状况W、时段T、区域Z。
输出：调价倍数Multiplier、最终预估价格P_final。
流程：1. 系统实时监控各区域Z的供需比R、天气W、时段T。
2. 根据预置规则或模型计算调价倍数M：M = f(R， W， T)，通常M ≥ 1，且M随R增大而增大。
3. 限制M不超过上限M_max。
4. 计算P_final = P_base * M，并展示给乘客。

中高

设基础价格为P0。
动态调价倍数为m，是供需比r、天气w、时段t的函数：m = f(r， w， t)。
最终价格：P = P0 * m。
函数f通常满足：∂f/∂r > 0（供需越紧张，倍数越高），m ∈ [1， M_max]。
一个简化模型：m = 1 + α * (r - r0)，其中r0为平衡供需比，α为敏感系数。

常量：基础价P0，上限M_max，平衡供需比r0，敏感系数α。
变量：实时供需比r，天气w，时段t，调价倍数m，最终价P。
函数：调价函数f(r， w， t)。

乘法，函数映射，约束。

1. 实时订单与司机位置热力图（供需数据）。
2. 天气数据接口。
3. 历史调价规则与效果数据。
4. 动态调价系数配置表。

动态定价，供需平衡，网约车，滴滴。

1. 监控数据：晚高峰18:00，中关村区域，供需比r=3（需求是供给的3倍），天气晴朗。
2. 计算倍数：根据模型f，r0=1，α=0.5，则m = 1 + 0.5*(3-1) = 1+1=2.0。检查上限M_max=3.0，未超过。
3. 计算价格：行程基础价P0=30元，P_final=30 * 2.0=60元。
4. 展示：App显示“当前需求旺盛，价格已上调至2.0倍，预计60元”。

R-1661​

字节跳动巨量引擎广告部

广告主、平台

财务/广告与计费规则

信息流广告“CPM（千次展示）”计费模型

广告主按广告被展示1000次（CPM）为单位进行付费，而非点击或转化。实际扣费按实际展示次数除以1000再乘以出价计算，但可能参与竞价，最终扣费可能低于出价。

巨量引擎CPM计费与竞价模型

为品牌广告主提供曝光量保障的计费方式，平台根据广告竞争力（出价、质量度）分配流量，按实际展示扣费。

1. 广告需通过审核才能上线。
2. 计费以实际展示为准，过滤无效曝光。
3. 参与广告竞价，最终扣费通常为下一位出价加微小金额。
4. 有每日预算和总预算限制。

输入：广告出价Bid（元/CPM）、广告质量度Quality、实际展示次数Impressions、竞价环境（其他广告出价Bid_others）。
输出：广告是否赢得展示Win、实际扣费单价Cost_per_mille、总扣费Total_cost。
流程：1. 当有一次广告展示机会时，系统对候选广告根据Score = Bid * Quality进行排序。
2. 得分最高者赢得展示。
3. 计算实际扣费：通常按第二高价（下一位得分对应的出价）加上一个极小值δ，再除以自身质量度：Cost_per_mille = (Score_second / Quality_win) + δ。
4. 累计展示每满1000次，扣费一次：Total_cost = (Impressions / 1000) * Cost_per_mille。

高

设广告i的出价为b_i（元/CPM），质量度为q_i。
竞争力得分：s_i = b_i * q_i。
竞价获胜：i* = argmax_i s_i。
实际千次展示扣费：c_i* = (s_{second} / q_i*) + ε，其中s_{second}是第二高的得分，ε为极小常数。
总扣费：对于N次展示，C_total = (N / 1000) * c_i*。

常量：极小值ε。
变量：广告出价b_i，质量度q_i，得分s_i，第二高得分s_second，实际扣费c_i*，展示次数N，总扣费C_total。

乘法，最大值函数，除法。

1. 广告计划出价与质量度数据。
2. 广告竞价日志（每次展示的候选广告及得分）。
3. 广告展示与扣费记录。
4. 广告预算消耗记录。

广告计费，CPM，竞价拍卖，第二高价，巨量引擎。

1. 竞价：一次展示机会，广告A出价b_A=10，质量度q_A=0.9，得分s_A=9；广告B出价b_B=12，质量度q_B=0.7，得分s_B=8.4。A得分更高，赢得展示。
2. 计算扣费：第二高得分s_second=8.4，ε=0.01。A的实际扣费c_A = (8.4 / 0.9) + 0.01 ≈ 9.34元/CPM。
3. 累计扣费：A当天获得5000次展示，N/1000=5，总扣费C_total = 5 * 9.34 = 46.7元。

R-1662​

百度网盘会员中心

用户、平台

运营/限速与体验规则

网盘“非会员下载速度限制”动态调整模型

非会员用户下载文件时，其下载速度会被限制在一个较低的值（如100KB/s），而会员用户可享受高速下载（如全速）。限速策略可能根据服务器负载动态微调。

百度网盘非会员下载限速模型

引导非会员用户升级为付费会员，实现变现，同时合理分配带宽资源，保障会员体验和服务器稳定。

1. 限速值有基础下限和上限。
2. 可能根据时间段、文件热度动态调整。
3. 多个非会员用户共享带宽池。
4. 会员速度承诺优先保障。

输入：用户会员状态IsVIP、当前服务器负载Load、基础非会员限速值S_base、动态调整系数α。
输出：用户当前下载速度限制S_limit、实际分配带宽B。
流程：1. 用户发起下载请求，系统检查IsVIP。
2. 若IsVIP=True，则S_limit为高速（如不限速或极高

R-1663​

拼多多百亿补贴运营部

商家、消费者、平台

价格/补贴与竞争力规则

电商“百亿补贴”价格竞争力审核与平台补贴模型

商家申报商品进入“百亿补贴”频道，平台审核其价格是否具备较强竞争力（而非绝对最低）。审核通过后，平台对商品进行直接补贴，使消费者到手价显著低于市场均价，补贴差额由平台承担。同时严格管控临期、过期、超期商品。

拼多多百亿补贴价格审核与平台直补模型

通过平台直接补贴打造极致性价比心智，吸引并留住价格敏感用户，同时通过严格品控保障正品体验，提升平台整体信誉和用户粘性。

1. 商品需具备较强价格竞争力，而非硬性要求“全网最低”。
2. 严禁上架临期、过期、超期商品（如非医药类商品生产日期超过3年即属超期）。
3. 宣传禁用“华强北”、“莆田”等误导性词汇。
4. 商品由中国人保财险承保，假一赔十。

输入：商家申报价P_seller、商品品类Category、生产日期Date_prod、全网比价数据MarketPrices。
输出：是否具备价格竞争力IsCompetitive、平台补贴额Subsidy、消费者到手价P_final。
流程：1. 商家提交商品及价格P_seller申请进入百亿补贴池。
2. 系统审核：a. 品控审核（临期、过期、超期）。b. 价格竞争力审核（基于MarketPrices和规则模型判断P_seller是否具备竞争力）。
3. 若审核通过，平台基于P_seller和市场目标价P_target计算补贴额Subsidy = P_seller - P_target（P_target < P_seller）。
4. 前端展示：消费者看到的价格为P_final = P_target，并标注“百亿补贴”和“平台补贴XX元”。

中高

设商家申报价为P_s，平台通过算法评估的市场有竞争力目标价为P_t。
价格竞争力判断：IsCompetitive = f(P_s, MarketPrices, Category)，函数f评估P_s是否在合理有竞争力的区间。
平台补贴额：若IsCompetitive = True，则Subsidy = P_s - P_t，其中P_t由平台设定，通常P_t < P_s。
消费者到手价：P_c = P_t = P_s - Subsidy。

常量：品类竞争力评估参数，临期/超期时间阈值。
变量：商家价P_s，目标价P_t，补贴额Subsidy，竞争力标志IsCompetitive。
函数：竞争力评估函数f()，目标价设定函数。

比较，减法，函数评估。

1. 商家商品申报信息（价格、品类、生产日期）。
2. 全网实时比价数据。
3. 百亿补贴商品审核状态记录。
4. 平台补贴支出流水。

平台补贴，价格竞争力，品控，全网比价，拼多多。

1. 商家申报：商家A申报iPhone 16，价格P_s=5999元。
2. 品控审核：生产日期2025年10月，未超3年，通过。
3. 价格审核：系统比价发现市场均价约6200元，P_s=5999元具备较强竞争力，IsCompetitive=True。
4. 设定目标价：平台设定有吸引力的目标价P_t=5799元。
5. 计算补贴：Subsidy = 5999 - 5799 = 200元，由平台承担。
6. 前端展示：用户看到价格5799元，标注“百亿补贴”、“平台补贴200元”。

R-1664​

淘宝/天猫会员运营部

用户、阿里生态内各业务方（饿了么、飞猪等）

销售/会员与权益规则

电商“88VIP”会员资格与全生态权益整合模型

用户淘气值决定其开通88VIP的资格和价格（淘气值≥1000可88元开通，否则888元）。开通后，会员可享受淘宝天猫购物折扣、优酷/饿了么/飞猪等生态内多项联名会员权益，以及退货包运费等专属服务。

淘宝88VIP会员资格定价与全生态权益整合模型

锁定高价值用户（高淘气值），通过整合阿里生态内多场景权益提升用户粘性和跨业务消费，构建消费闭环，提升用户生命周期价值。

1. 开通资格和价格由淘气值决定（≥1000分享受88元年费）。
2. 权益覆盖电商、本地生活、文娱、出行等多场景。
3. 部分权益（如盒马X会员）为限时体验或需领取。
4. 会员权益可能随时间升级调整。

输入：用户淘气值Score、当前88VIP开通价格表PriceTable、权益列表Benefits。
输出：是否有资格以优惠价开通Eligible、开通年费Price、可享受的权益集合BenefitSet。
流程：1. 用户进入88VIP开通页面，系统读取其淘气值Score。
2. 判断资格：若Score ≥ 1000，则Eligible=True，Price=88元；否则Eligible=False，Price=888元。
3. 用户支付Price开通后，系统为其账户激活对应的权益BenefitSet（如购物95折、优酷VIP、饿了么会员等）。
4. 部分权益需用户手动领取（如盒马X会员体验卡）。

中

设用户淘气值为S，优惠门槛为S0=1000，优惠价为P_low=88，原价为P_high=888。
开通价格函数：P(S) = { P_low, if S ≥ S0; P_high, otherwise }。
权益激活：开通后，权益集合B被激活，B ⊆ Benefits。

常量：淘气值门槛S0，优惠价P_low，原价P_high，权益集合Benefits。
变量：用户淘气值S，开通价格P，激活权益B。
指示函数：用于价格判断。

分段函数，集合论。

1. 用户淘气值历史与当前分数。
2. 88VIP开通价格配置表。
3. 88VIP权益配置表（电商、生活、文娱等）。
4. 用户权益开通与使用记录。

会员体系，淘气值，生态整合，跨业务权益，阿里巴巴。

1. 查询淘气值：用户U淘气值S=1200。
2. 判断资格：S=1200 ≥ 1000，因此Eligible=True，Price=88元。
3. 开通付费：U支付88元开通88VIP年卡。
4. 激活权益：系统为U激活权益集B，包括天猫超市95折、优酷VIP年卡、饿了么会员年卡、退货包运费等。U可手动领取盒马90天体验卡。

R-1665​

腾讯视频会员产品部

用户（VIP/SVIP）、内容版权方

运营/内容分发与付费规则

视频平台“VIP抢先看”与“付费超前点播”分级访问模型

VIP会员可免费抢先观看部分剧集（如比非会员多看N集）。针对部分热门剧集，在VIP抢先看的基础上，提供“超前点播”服务，VIP会员可额外付费（如3元/集）解锁更多剧集，实现内容的分级变现。

腾讯视频VIP内容分级访问与付费点播模型

在保障VIP基础权益的同时，通过付费超前点播满足部分用户提前观看需求，挖掘内容增量价值，增加单用户收入（ARPU）。

1. VIP抢先看是基础权益，不额外收费。
2. 超前点播需在VIP身份基础上额外付费。
3. 超前点播通常按集收费，可能有打包优惠。
4. 内容播出进度和点播方案可能调整。

输入：用户会员等级Level（非会员/VIP/SVIP）、剧集播出进度Ep_released、剧集点播规则Rule（VIP抢先集数N_vip，超前点播集数M_ppv，单价Price）。
输出：用户可观看最新集数Ep_accessible、是否需要为超前点播付费NeedPay、付费金额Amount。
流程：1. 非会员可观看Ep_released - N_vip - M_ppv集。
2. VIP会员可观看Ep_released - M_ppv集（即比非会员多看N_vip集）。
3. 若VIP会员想观看最新Ep_released集，需购买超前点播，可观看集数为Ep_released，需支付Amount = (想观看的超前集数) * Price。
4. SVIP可能享有更多抢先权益。

中

设非会员可看集数为E_free，VIP会员可看集数为E_vip，总已释放集数为E_total。
VIP抢先集数为N，超前点播集数为M。
观看权限：
E_free = E_total - N - M。
E_vip = E_total - M。
对于超前点播，设用户已购买点播集数为K（0 ≤ K ≤ M），则VIP用户实际可看集数为E_vip + K。
点播费用：Cost = K * p，其中p为单价。

常量：VIP抢先集数N，超前点播集数M，点播单价p。
变量：总已释放集数E_total，用户会员等级L，已购买点播集数K，可看集数E_access，费用Cost。

减法，乘法。

1. 用户会员身份与等级信息。
2. 剧集播出与点播规则配置表。
3. 用户超前点播购买记录。
4. 内容访问权限控制日志。

内容付费，会员权益，超前点播，分级访问，腾讯视频。

1. 剧集状态：某剧已播出20集(E_total=20)，规则：VIP抢先看N=2集，超前点播M=6集，单价p=3元。
2. 权限判断：非会员可看20-2-6=12集。VIP会员可看20-6=14集（即比非会员多看2集）。
3. 超前点播：VIP用户U想看到最新第20集，需购买超前点播的6集(K=6)。
4. 费用计算：Cost = 6 * 3 = 18元。支付后，U可观看全部20集。

R-1666​

京东PLUS会员运营部

用户、物流部门、商家

运营/会员与运费规则

电商“PLUS会员无限免邮”与运费券发放模型

正式PLUS会员在购买符合范围的京东自营商品时，享受不限次数、不限订单金额的免运费服务（无限免邮）。部分特殊业务（如七鲜）可能调整为每月限量运费券。会员试用期或不同等级会员享有不同免邮额度。

京东PLUS会员自营商品免运费规则模型

提升PLUS会员的购买频次和客单价，增强会员粘性和价值感知，同时通过设定适用范围（如自营）控制物流成本。

1. 无限免邮主要适用于京东自营商品。
2. 特殊配送服务（京尊达等）及部分独立APP业务不适用。
3. 试用会员、企业会员等可能有不同的免邮规则或额度。
4. 部分生鲜即时零售业务（如七鲜）可能调整为每月限量免邮券。

输入：用户PLUS会员状态Status（正式/试用/企业）、订单商品列表Items（是否自营IsSelf、商品重量/体积）、配送服务Service。
输出：是否免邮FreeShipping、需支付运费ShippingFee、消耗的免邮券数量CouponUsed。
流程：1. 判断用户Status：正式PLUS会员进入无限免邮逻辑；试用会员检查免邮券余额；企业会员适用企业规则。
2. 检查Items：所有商品均需为适用范围内的自营商品。
3. 检查Service：是否为不支持的特殊服务。
4. 若全部满足，则FreeShipping=True，ShippingFee=0。否则按标准运费规则计算。对于七鲜等业务，每月初发放固定数量免邮券，使用时扣除。

中

设用户会员状态为S，订单商品集合为I = {i1, i2, ...}，每个商品i有属性isSelf_i（是否自营）。
配送服务为serv。
免邮条件：对于正式PLUS会员，FreeShipping = (∀i ∈ I, isSelf_i = True) ∧ (serv ∉ ExcludedServices)。
对于试用会员，设有C张免邮券，则FreeShipping = (C > 0) ∧ (∀i ∈ I, isSelf_i = True) ∧ (serv ∉ ExcludedServices)，若免邮则C = C - 1。

常量：排除的配送服务集合ExcludedServices。
变量：会员状态S，商品自营属性isSelf_i，配送服务serv，免邮券数量C，是否免邮FreeShipping。

逻辑与，全称量词，集合论。

1. 用户PLUS会员类型与状态。
2. 商品信息（是否自营、类目）。
3. 配送服务类型配置表。
4. 免邮券账户余额与使用记录。

会员权益，免运费，物流成本，京东PLUS。

1. 用户状态：用户U是正式PLUS会员。
2. 订单检查：U购买了一本书和一瓶水，均为京东自营商品(isSelf=True)，选择普通配送(serv不在排除列表)。
3. 规则应用：满足(所有商品为自营)且(服务非排除项)，因此FreeShipping=True。
4. 结果：订单运费为0元。若U是试用会员且有2张免邮券，则同样免邮，但券数量减为1。

R-1667​

阿里云计费部

用户、平台

财务/计费与阶梯定价规则

云计算“按量计费”资源使用量阶梯定价模型

用户按实际使用的云资源（如OSS存储容量、CDN流量）付费，但单价并非固定，而是随着使用量的增加，进入不同的阶梯，单价逐级降低，鼓励大规模使用。

阿里云按量计费资源阶梯定价模型

通过阶梯降价激励用户增加用量，提升客户粘性和资源利用率，同时使定价更具竞争力和灵活性。

1. 阶梯区间和单价预先定义并公示。
2. 计费周期通常为自然月，按月累计用量划分阶梯。
3. 不同资源（存储、流量、计算）有独立的阶梯表。
4. 费用按每个阶梯内的用量分别计算后累加。

输入：用户本月累计使用量Usage、阶梯定价表Tiers（区间[L_k, U_k]，单价Price_k）。
输出：本月总费用TotalCost、各阶梯费用明细Cost_k。
流程：1. 统计用户在一个计费周期（如一个月）内的资源总使用量Usage。
2. 根据Tiers，确定Usage落在哪个或哪几个阶梯区间内。
3. 对每个阶梯k，计算该阶梯内的用量Usage_k = min(Usage, U_k) - L_k（注意首尾阶梯处理）。
4. 计算该阶梯费用Cost_k = Usage_k * Price_k。
5. 总费用TotalCost = Σ Cost_k。

中

设阶梯有n级，第k级用量区间为[l_k, u_k]，单价为p_k，且u_k = l_{k+1}，l_1=0。
总用量为U。
第k级用量：u'_k = min(U, u_k)。
第k级计费用量：U_k = max(0, u'_k - l_k)。
第k级费用：C_k = U_k * p_k。
总费用：C_total = Σ_{k=1}^{n} C_k。

常量：阶梯区间l_k, u_k，单价p_k。
变量：总用量U，第k级计费用量U_k，第k级费用C_k，总费用C_total。

分段函数，最小值，最大值，求和。

1. 用户资源使用量明细（按小时/天）。
2. 阶梯定价配置表（资源类型、阶梯、单价）。
3. 月度累计用量与费用计算中间结果。
4. 账单明细。

云计算，按量计费，阶梯定价，用量折扣，阿里云。

1. 用量统计：用户本月使用OSS存储U=55TB。阶梯：0-10TB，单价0.12元/GB/月；10-50TB，单价0.09元/GB/月；50TB以上，单价0.07元/GB/月。
2. 阶梯计算：第一阶梯：U1 = min(55,10)-0 = 10TB，费用C1=10 * 1024 * 0.12=1228.8元。
第二阶梯：U2 = min(55,50)-10 = 40TB，费用C2=40 * 1024 * 0.09=3686.4元。
第三阶梯：U3 = 55-50 = 5TB，费用C3=5 * 1024 * 0.07=358.4元。
3. 总费用：C_total=1228.8+3686.4+358.4=5273.6元。

R-1668​

腾讯游戏（如王者荣耀）运营部

玩家、平台

销售/通行证与任务规则

游戏“赛季通行证”经验值升级与奖励解锁模型

玩家通过完成每日/每周任务或对局获得通行证经验值（EXP），提升通行证等级。每升一级可解锁对应等级的免费或付费奖励。付费购买精英通行证可额外解锁精英奖励轨道。

腾讯游戏赛季通行证经验积累与等级奖励模型

通过持续的任务和奖励设计，提升玩家日活和在线时长，并通过售卖精英通行证实现增值服务变现。

1. 通行证有固定赛季时长（如2-3个月）。
2. 每日/每周任务有经验值上限。
3. 免费奖励轨道和精英奖励轨道并行。
4. 赛季结束后通行证等级和未领取奖励可能清零。

输入：玩家当前通行证等级L、当前经验值EXP_current、完成任务获得的经验EXP_task、升级所需经验函数NeedEXP(L)。
输出：新等级L'、新经验值EXP_new、解锁的奖励列表Rewards。
流程：1. 玩家完成任务，获得EXP_task。
2. 更新经验：EXP_new = EXP_current + EXP_task。
3. 检查升级：当EXP_new ≥ NeedEXP(L)时，等级提升：L' = L + 1，EXP_new = EXP_new - NeedEXP(L)。重复此步骤直至EXP_new < NeedEXP(L')。
4. 每升一级，根据L'和玩家是否拥有精英通行证，发放对应等级的免费和/或精英奖励。

中

设当前等级为l，当前经验为e。
完成任务获得经验Δe。
等级l升到l+1所需经验为f(l)（通常随等级增加）。
经验更新：e' = e + Δe。
升级循环：
while e' ≥ f(l):
e' = e' - f(l)
l = l + 1
end while
最终等级为l，剩余经验为e'。

常量：升级所需经验函数f(l)，任务经验值Δe。
变量：等级l，经验e，新等级l'，新经验e'。

循环，减法，比较。

1. 玩家通行证状态（等级、经验、是否精英）。
2. 任务列表与经验值配置。
3. 通行证等级奖励配置表（免费、精英）。
4. 经验获取与等级提升日志。

游戏化，赛季通行证，任务系统，经验值，腾讯游戏。

1. 初始状态：玩家通行证等级l=5，经验e=200/400（升到6级需400）。
2. 完成任务：完成一个每日任务，获得Δe=100经验。
3. 经验更新：e'=200+100=300。
4. 检查升级：300 < 400，不升级。新状态：等级l'=5，经验e'=300/400。
5. 再完成一个任务：又获得Δe=150，e'=300+150=450。
6. 升级：450 ≥ 400，升级到l=6，剩余经验e'=450-400=50。升到7级需500经验，50 < 500，停止。发放等级6的奖励。

R-1669​

网易严选会员中心

用户、供应商

价格/会员价与返现规则

自营电商“会员价”与“返现”组合优惠模型

付费会员（如严选Pro会员）购买商品可享受会员专享价（通常低于原价）。此外，会员消费后可获得一定比例的返现（如1%），返现金额可用于后续消费抵扣。

网易严选会员专享价与消费返现模型

通过差异化的会员价和消费返现激励用户开通会员并持续消费，提升复购率和客单价，锁定高价值用户。

1. 会员价仅限有效期内会员可见和购买。
2. 返现比例可能根据商品类别或活动调整。
3. 返现金额有有效期（如一年）。
4. 返现可能仅限部分商品或场景使用。

输入：用户会员状态IsMember、商品原价P_original、会员专享价P_member、订单实付金额Pay、返现比例r。
输出：用户实际支付价P_paid、本次消费获得返现金额Cashback。
流程：1. 用户浏览商品，若IsMember=True，则展示P_member，否则展示P_original。
2. 下单时，若IsMember=True，则按P_member计算商品总价，再叠加其他优惠。
3. 支付完成后，根据实付金额Pay和返现比例r计算返现：Cashback = Pay * r。
4. 返现金额存入用户账户，有效期N天，可用于下次消费抵扣。

低

设商品原价为P0，会员价为P_m（P_m ≤ P0）。
用户会员状态为M（布尔值）。
用户看到的价格：P_display = { P_m, if M=True; P0, otherwise }。
设订单其他优惠后实付为A，返现比例为α。
返现金额：若M=True，则C = A * α；否则C=0。

常量：会员价P_m，返现比例α。
变量：会员状态M，原价P0，实付金额A，返现金额C。

条件判断，乘法。

1. 商品价格表（原价、会员价）。
2. 用户会员状态与有效期。
3. 订单支付记录（实付金额）。
4. 返现金额账户流水（获得、消耗、过期）。

会员专享价，消费返现，用户忠诚度，网易严选。

1. 价格展示：用户U是严选Pro会员(M=True)。商品原价P0=100元，会员价P_m=88元。U看到的价格是88元。
2. 下单支付：U购买该商品，无其他优惠，实付A=88元。
3. 计算返现：返现比例α=1%，C=88 * 0.01=0.88元。
4. 发放返现：0.88元返现存入U的账户，有效期365天。

R-1670​

美团外卖会员产品部

用户、商家、平台

销售/会员与红包规则

外卖“会员红包”周期发放与膨胀使用模型

用户购买外卖会员后，每月可获得固定数量的红包（如6张5元券）。红包可用于抵扣配送费或商品金额，部分红包在特定商家或时段使用时可“膨胀”为更大面额（如5元膨胀至7元）。

美团外卖会员红包月度发放与膨胀使用模型

通过定期发放红包培养用户消费习惯，提升会员购买率和外卖订单频次；通过红包膨胀刺激用户在特定商家或高客单价时段消费。

1. 红包按月发放，当月有效。
2. 红包有使用门槛（如满20元可用）。
3. 膨胀红包仅在指定商家或时段生效。
4. 红包不可叠加使用，每单限用一张。

输入：用户会员状态IsMember、当前月份Month、红包库存Coupons、订单金额OrderAmount、商家/时段是否支持膨胀CanExpand。
输出：本月可领取红包NewCoupons、可用红包列表AvailableCoupons、红包膨胀后面额ExpandedValue、最优抵扣选择BestCoupon。
流程：1. 每月初，若IsMember=True，系统发放固定数量红包至账户。
2. 用户下单时，系统根据OrderAmount和商家/时段信息，筛选出满足使用门槛的红包列表AvailableCoupons。
3. 对每个可用红包，判断是否满足膨胀条件CanExpand，若满足，则面额Value' = Value + Bonus。
4. 用户选择一张红包使用，抵扣相应金额。

中

设会员每月获得N张面额为V0的红包。
红包使用门槛为T。
膨胀条件为布尔值E，膨胀奖励为B。
膨胀后面额：V = { V0 + B, if E=True; V0, otherwise }。
红包可用条件：订单金额A ≥ T。
用户从可用红包集合C_available中选择一张使用，抵扣min(V, A)。

常量：每月红包数量N，基础面额V0，使用门槛T，膨胀奖励B。
变量：会员状态M，膨胀条件E，订单金额A，膨胀后面额V，可用红包集合C_available。

条件判断，最小值函数。

1. 用户会员开通与续费记录。
2. 月度红包发放记录。
3. 红包库存与使用状态。
4. 商家/时段膨胀规则配置表。

会员红包，膨胀优惠，用户留存，美团外卖。

1. 月初发放：用户U是会员，4月1日收到6张5元红包，门槛满20元可用。
2. 下单：U在商家M（支持膨胀）下单，订单金额A=30元。
3. 红包筛选：满足门槛30≥20，所有红包可用。
4. 膨胀判断：商家M支持膨胀，5元红包可膨胀至7元。
5. 使用抵扣：U选择使用一张膨胀红包，抵扣min(7,30)=7元，实付23元。

R-1671​

携程酒店会员运营部

用户、酒店集团

运营/会员等级与权益匹配模型

在线旅行“酒店会员等级”与“合作酒店集团会籍”匹配模型

携程根据用户的消费金额、间夜数等计算成长值，划分会员等级（如黄金、白金、钻石）。不同等级匹配不同合作酒店集团（如华住会、洲际）的相应会籍，享受免房升级、延迟退房等权益。

携程酒店会员成长值计算与酒店集团会籍匹配模型

通过会员等级体系激励用户持续在平台消费，并通过与酒店集团会籍互通提升会员权益价值，增强用户忠诚度和平台竞争力。

1. 成长值基于酒店消费金额、间夜数等计算，定期更新等级。
2. 与特定酒店集团的会籍匹配关系预先定义。
3. 匹配的会籍权益由酒店集团提供，可能变化。
4. 会员等级有效期通常为一年。

输入：用户历史消费数据History（消费额Amount、间夜数Nights）、成长值计算规则Rule、等级权益匹配表MatchTable。
输出：用户当前成长值Points、会员等级Level、匹配的酒店集团会籍列表StatusList。
流程：1. 根据Rule计算用户累计成长值：Points = f(Amount, Nights, ...)。
2. 根据Points查询等级阈值表，确定当前Level（如0-1999黄金，2000-4999白金，5000+钻石）。
3. 根据Level查询MatchTable，得到匹配的酒店集团及对应会籍等级（如钻石匹配华住会金卡、洲际白金卡）。
4. 用户入住合作酒店时，可享受对应会籍权益。

中

设成长值计算函数为P = α * A + β * N + ...，其中A为消费金额，N为间夜数，α, β为系数。
等级阈值向量为L = [l1, l2, ..., ln]，对应等级名称["黄金"， "白金"， "钻石"]。
等级判定：若P ∈ [l_k, l_{k+1})，则等级为第k级。
会籍匹配函数M(level)返回该等级对应的酒店集团会籍列表。

常量：成长值系数α, β，等级阈值L，匹配表M。
变量：消费额A，间夜数N，成长值P，等级level，会籍列表status_list。

线性组合，区间判断，查表。

1. 用户酒店消费记录（金额、间夜、时间）。
2. 成长值计算规则配置。
3. 会员等级阈值表。
4. 等级-酒店集团会籍匹配关系表。

会员等级，成长值，会籍匹配，酒店集团，携程。

1. 计算成长值：用户U过去一年酒店消费A=8000元，间夜N=15。规则：P = A*1 + N*100 = 8000 * 1 + 15 * 100 = 8000+1500=9500。
2. 确定等级：阈值：黄金(0-1999)，白金(2000-4999)，钻石(5000+)。P=9500 ≥ 5000，为钻石会员。
3. 匹配会籍：根据匹配表，钻石会员匹配：华住会金卡、洲际白金卡、万豪银卡。
4. 享受权益：U通过携程预订华住酒店，可享受金卡会员的免费早餐、延迟退房权益。

R-1672​

抖音电商直播运营部

主播、商家、平台

财务/佣金与结算规则

直播带货“阶梯佣金”与“平台服务费”结算模型

主播为商家带货，根据实际成交额（GMV）按约定佣金比例获取报酬。佣金比例可能采用阶梯制，即GMV达到不同区间，佣金率不同。平台从中收取一定比例的技术服务费。

抖音直播带货阶梯佣金与平台抽成结算模型

激励主播提升带货销售额（GMV越高佣金率越高），同时平台通过技术服务费分享收益，规范直播电商交易结算。

1. 佣金比例在直播前由主播与商家通过协议约定。
2. 阶梯佣金以直播期间或指定时间段内该商品的GMV累计计算。
3. 平台服务费比例固定或根据类目调整。
4. 结算通常在用户确认收货后。

输入：商品成交额GMV、阶梯佣金协议CommissionRates（区间[G_k, G_{k+1}]，比例r_k）、平台服务费率p。
输出：主播佣金Commission、平台服务费PlatformFee、商家结算金额Settlement。
流程：1. 直播结束后，统计该商品总GMV。
2. 根据GMV和CommissionRates确定适用的佣金比例r。若为阶梯制，则按各区间分段计算佣金后加总。
3. 计算主播佣金：Commission = GMV * r。
4. 计算平台服务费：PlatformFee = GMV * p。
5. 商家结算：Settlement = GMV - Commission - PlatformFee。

中高

设成交额为G，阶梯佣金区间为[g0, g1, ..., gn]，对应佣金率为[c1, c2, ..., cn]，其中g0=0。
分段佣金计算：
对于k从1到n：
G_k = min(G, g_k) - g_{k-1}，若G_k > 0，则该段佣金C_k = G_k * c_k。
总佣金：C_total = Σ_{k=1}^{n} C_k。
设平台费率为f。
平台服务费：F = G * f。
商家结算：S = G - C_total - F。

常量：佣金阶梯g_k，佣金率c_k，平台费率f。
变量：总成交额G，分段成交额G_k，分段佣金C_k，总佣金C_total，平台费F，商家结算S。

分段函数，最小值，求和。

1. 直播带货商品销售记录（GMV）。
2. 主播与商家的佣金协议（阶梯比例）。
3. 平台服务费率配置表。
4. 佣金与服务费结算流水。

直播电商，佣金结算，阶梯佣金，平台抽成，抖音。

1. 成交统计：主播为商家带货商品A，总成交额G=150，000元。
2. 阶梯佣金：协议：0-5万部分佣金率10%，5-10万部分15%，10万以上部分20%。即g=[0，50000，100000，∞]，c=[10%，15%，20%]。
3. 分段计算：
第一段：G1=min(150000，50000)-0=50000，C1=50000 * 10%=5000。
第二段：G2=min(150000，100000)-50000=50000，C2=50000 * 15%=7500。
第三段：G3=150000-100000=50000，C3=50000 * 20%=10000。
总佣金C_total=5000+7500+10000=22500元。
4. 平台抽成：平台费率f=5%，F=150000 * 5%=7500元。
5. 商家结算：S=150000-22500-7500=120000元。

R-1673​

天猫/淘宝营销平台部

用户、商家、平台

价格/促销与优惠规则

电商“平行满减”优惠计算模型

在购物车结算时，系统并行计算所有符合条件的优惠（如店铺券、商品券、平台券、跨店满减），并按照最优组合（如最大折扣）进行叠加。与递进式优惠（券后价再满减）不同，平行满减中，各种优惠的计算基准是原始价格，互不冲突，可以叠加享受。

电商平行满减优惠叠加计算模型

简化优惠规则，让用户更容易理解并享受到最大优惠，提升下单转化率；同时为商家和平台提供灵活的促销工具。

1. 各优惠券/活动有各自的使用条件（门槛、适用范围、互斥关系）。
2. 优惠叠加需遵循平台规则（如优先级、上限）。
3. 最终优惠后价格不能低于0。
4. 需清晰展示各优惠的抵扣金额。

输入：商品列表（含单价、数量）、可用优惠券列表（类型、门槛、面额）、可参与的活动列表（如每满300减40）。
输出：最优优惠组合BestCombo、各优惠抵扣明细DiscountDetails、最终应付金额FinalPrice。
流程：1. 枚举所有可能的优惠组合（券+活动）。
2. 对每种组合，并行计算各优惠的抵扣额：店铺/商品券按其规则计算，跨店满减按总价满足门槛的档位计算。
3. 计算该组合下的总抵扣额TotalDiscount。
4. 选择TotalDiscount最大的组合作为BestCombo（需满足各优惠互不冲突）。
5. 计算FinalPrice = 原总价 - TotalDiscount。

中高

设商品原总价为P，有n种优惠方式，第i种优惠的抵扣函数为D_i(P, conditions_i)，表示在条件conditions_i下可抵扣的金额。
平行叠加：总抵扣额D_total = Σ_{i=1}^{n} D_i(P, conditions_i)，其中每种优惠独立计算，计算基准均为原价P（或各自适用商品的子集原价）。
最终价：P_final = max(0, P - D_total)。

常量：各优惠规则定义（门槛、折扣率、面额）。
变量：商品原总价P，各优惠抵扣额D_i，总抵扣D_total，最终价P_final。

求和，最大值，条件函数。

1. 商品价格与数量信息。
2. 用户可用优惠券列表及使用规则。
3. 平台/店铺促销活动规则。
4. 优惠计算中间结果与最终订单金额。

电商促销，优惠叠加，平行满减，组合优化，淘宝/天猫。

1. 输入：用户购物车有商品A（200元）、B（150元），总原价P=350元。可用优惠：店铺券满300减20，平台券满200减15，跨店满减每满300减40。
2. 枚举组合：三种优惠均可用于此订单，且不互斥。
3. 并行计算：店铺券：满足300减20，可抵扣D1=20。平台券：满足200减15，可抵扣D2=15。跨店满减：350满足300，按300一档计算，抵扣D3=40。
4. 总抵扣：D_total = 20+15+40=75元。
5. 最终价：P_final = 350-75=275元。

R-1674​

腾讯视频会员产品部

用户、内容版权方、平台

内容/访问与会员规则

视频平台“会员抢先看”观看模型

对于部分独家或热门剧集，平台采用“会员抢先看”模式：免费用户可观看部分集数（如前2集），或延迟一段时间（如更新后一周）观看；付费会员则可以提前观看更多集数（如已更新的全部集数），甚至提前观看下周的更新。

腾讯视频会员抢先看（追剧日历）模型

以独家优质内容吸引用户付费订阅会员，增加会员收入；同时通过免费集数吸引新用户，并通过延迟观看制造焦虑感促进转化。

1. 剧集的观看规则（免费集数、会员更新节奏、免费延迟时间）需提前公示。
2. 会员权益清晰，避免纠纷。
3. 免费用户有明确的追剧进度限制。
4. 需防止技术手段绕过限制。

输入：用户会员状态IsVip、当前剧集总集数TotalEps、已更新集数ReleasedEps、免费观看集数FreeEps、会员抢先看集数VipAdvanceEps、免费延迟天数FreeDelayDays。
输出：用户当前可观看的集数列表AccessibleEps、各集解锁状态（免费/会员/锁定）。
流程：1. 根据剧集排播计划，确定每日ReleasedEps。
2. 对会员用户：AccessibleEps = 已更新的前 min(ReleasedEps, VipAdvanceEps) 集（通常会员可看全部已更新）。
3. 对免费用户：AccessibleEps = 已更新的前 min(ReleasedEps, FreeEps) 集，但对于超过FreeEps的集数，需等待FreeDelayDays天后才能观看。即，如果某集更新日期为T_release，则免费用户在T_release + FreeDelayDays后才可观看。
4. 前端根据AccessibleEps和用户状态显示可播放或锁定的剧集。

中

设当前日期为t，剧集e的更新日期为t_e。
会员可观看集：`E_vip = {e

t_e ≤ t}（即所有已更新集）。<br>免费用户可观看集：E_free = {e

(t_e ≤ t) ∧ ( (e ≤ E0) ∨ (t ≥ t_e + Δt) ) }，其中E0为固定免费集数（如前2集），Δt`为延迟天数。

常量：免费集数E0，延迟天数Δt。
变量：当前日期t，剧集更新日期t_e，会员状态V（布尔），可看集集合E_acc。

集合运算，比较，逻辑或。

1. 剧集元数据（总集数、更新计划）。
2. 用户会员状态与有效期。
3. 用户剧集观看进度记录。
4. 剧集解锁规则配置表。

R-1675​

网易云音乐推荐算法部

用户、平台

算法/内容分发与推荐规则

音乐App“个性化每日推荐”歌曲生成模型

系统基于用户的历史听歌行为（播放、收藏、分享、跳过）、歌曲本身的特征（流派、歌手、语种）、以及其他相似用户的行为，通过协同过滤、深度学习等推荐算法，为每个用户生成一个高度个性化的、每日更新的歌曲推荐列表（如“每日推荐30首”）。

网易云音乐“每日推荐”个性化歌单生成模型

提升用户音乐发现效率和听歌时长，增强用户粘性；通过精准推荐促进长尾歌曲的分发，优化平台内容生态。

1. 推荐需兼顾新颖性和熟悉度，避免信息茧房。
2. 列表每日更新，保持新鲜感。
3. 需过滤用户已明确不喜欢的歌曲或歌手。
4. 推荐结果需满足一定的多样性（如流派、语种）。

输入：用户历史行为序列History、用户画像Profile、全量歌曲特征矩阵SongFeatures、用户-歌曲交互矩阵UserItemMatrix。
输出：每日推荐歌曲ID列表RecList（如30首）。
流程：1. 候选生成：从全量歌曲库中，基于History和Profile，通过多种策略（如协同过滤、基于内容、热门补充）召回数千首候选歌曲。
2. 排序：使用精排模型（如深度神经网络）对候选歌曲进行打分，模型融合用户特征、歌曲特征、上下文特征（时间、天气）等，预测用户对每首歌的喜好程度Score。
3. 重排：对精排结果进行多样性打散、新鲜度控制、版权过滤等，生成最终的RecList。
4. 每日定时（如早上6点）为每个用户生成新列表并缓存。

高

设用户u，候选歌曲集合C。
精排模型为f(u, i; θ)，输入用户特征x_u、歌曲特征x_i、上下文特征x_c，输出预测得分s = f(x_u, x_i, x_c; θ)。
排序：对所有i ∈ C，按s_i降序排列，得到初始列表L。
重排：应用多样性约束，如最大边际相关性（MMR），从L中依次选择歌曲，使得推荐列表R在相关性和多样性间平衡：i* = argmax_{i ∈ L \ R} [λ * s_i - (1-λ) * max_{j ∈ R} sim(i, j)]，其中sim(i,j)为歌曲i,j的相似度，λ为权重。

常量：模型参数θ，多样性权重λ。
变量：用户特征x_u，歌曲特征x_i，上下文x_c，预测得分s_i，推荐列表R。

向量内积，函数映射，排序，迭代优化。

1. 用户历史听歌行为（播放、收藏、跳过）。
2. 歌曲元数据与音频特征向量。
3. 用户画像标签（兴趣、 demographics）。
4. 每日推荐生成结果与用户反馈数据。

推荐系统，协同过滤，深度学习，多样性，网易云音乐。

1. 候选生成：用户U最近常听民谣和独立音乐，系统基于协同过滤召回1000首候选歌曲，包括其他民谣、独立音乐，以及部分流行摇滚（因为相似用户也喜欢）。
2. 精排打分：对1000首歌，用深度模型f预测U对每首歌的播放概率。模型考虑U的听歌历史、歌曲特征、当前时间是早晨等因素。得到每首歌的得分s_i。
3. 排序与重排：按s_i降序，前100首可能都是民谣。为增加多样性，使用MMR算法，在相关性损失不大的情况下，插入几首流行摇滚和轻音乐，形成最终30首列表。
4. 推送：每日早上6点更新“每日推荐”歌单，U打开App即可看到新的30首推荐。

R-1676​

腾讯游戏（如王者荣耀）匹配系统

玩家、平台

算法/匹配与平衡规则

多人在线游戏“ELO匹配”模型

系统根据玩家的隐藏分（ELO rating，或类似MMR）进行匹配，力求双方队伍的平均隐藏分相近，同时尽可能缩短匹配时间。玩家的隐藏分根据对战结果（胜负）和对手强弱动态调整：战胜强敌加分多，输给弱敌扣分多。

王者荣耀ELO竞技匹配与评分模型

为玩家提供公平、竞技性强的对战体验，减少实力悬殊的对局；通过隐藏分系统反映玩家真实水平，用于排位赛段位升降。

1. 匹配需综合考虑隐藏分、玩家当前段位、位置偏好、在线人数等因素。
2. 隐藏分调整公式需平滑，避免剧烈波动。
3. 新玩家有初始隐藏分，并通过定级赛快速校准。
4. 匹配时间不能过长，有时需在公平和速度间权衡。

输入：玩家i的当前隐藏分R_i、玩家选择的游戏模式Mode、匹配队列时间WaitTime。
输出：匹配完成的10名玩家（分为两队，每队5人）列表MatchResult。
流程：1. 玩家进入匹配队列，系统根据Mode和R_i将其放入相应的匹配池。
2. 每隔一段时间（如几秒），从匹配池中尝试组队。目标是最小化两队平均隐藏分之差`

Avg(R_teamA) - Avg(R_teamB)

，同时控制匹配时间。<br>3. 匹配成功后，开始游戏。<br>4. 游戏结束后，根据结果（胜/负）和双方赛前隐藏分，按照ELO公式更新每位玩家的隐藏分R_i`。

高

匹配目标：从候选玩家集合P中选出10人分成两队A和B，最小化目标函数`Z =

mean(R_A) - mean(R_B)

+ α * WaitTime，其中α为权衡系数。<br>**ELO更新公式**：玩家i的赛后期望胜率E_i = 1 / (1 + 10^{(R_j - R_i)/400})，其中R_j为对手队伍的平均隐藏分（团队游戏通常取对手队伍平均分）。实际结果S_i：胜为1，负为0。<br>**隐藏分更新**：R_i' = R_i + K * (S_i - E_i)，其中K`为调整系数（新手较大，高手较小）。

常量：ELO公式参数400，K因子K，权衡系数α。
变量：玩家隐藏分R_i，匹配时间WaitTime，两队平均分mean(R_A), mean(R_B)，期望胜率E_i，实际结果S_i。

R-1677​

美团/饿了么配送调度部

骑手、用户、商家、平台

运营/调度与路径规划规则

外卖“订单分配与骑手路径规划”模型

系统接收到多个用户订单后，需将订单分配给在线骑手，并为骑手规划取餐和送餐的路径顺序，目标是整体配送时间最短、用户体验最优（准时）、骑手负荷平衡。考虑因素：订单地理位置、预计出餐时间、骑手实时位置、骑手已有订单顺路程度、交通路况等。

外卖实时订单分配与骑手路径规划模型

最大化配送效率，降低平均配送时长，提升订单准时率，优化骑手体验和收入，提升平台整体运力效能。

1. 订单有期望送达时间，超时可能扣罚。
2. 骑手同时配送的订单数有上限（如5单）。
3. 路径规划需考虑实际道路网络和交通状况。
4. 分配需近乎实时（秒级）完成。

输入：新订单O_new（商家位置M，用户位置C，期望送达时间T_due）、在线骑手列表Riders（每个骑手当前位置、已有订单任务列表Tasks）、实时路况Traffic。
输出：订单分配决策（将O_new分配给骑手R_x）、骑手更新后的路径顺序Route。
流程：1. 预测O_new的商家出餐时间T_prep。
2. 对每个骑手R_i，模拟插入O_new到其现有任务列表Tasks_i中，生成新的路径Route_i'。
3. 计算Route_i'的总耗时（或总距离），以及O_new的预计送达时间T_estimated。
4. 评估T_estimated是否满足T_due，以及是否超出骑手负荷。
5. 选择最优的骑手R*，使得目标函数（如总延迟最小、总路径最短）最优，且满足约束。
6. 将O_new分配给R*，并更新其路径为Route*'。

极高

设骑手r当前任务序列为S_r = (t1, t2, ..., tn)，每个任务包括取餐点p和送餐点d。
新订单o有取餐点m和送餐点c。
插入评估：将(m,c)插入S_r的某个位置，生成新序列S_r'。计算S_r'的总行程时间T_total(S_r')，以及o的预计送达时间T_c。
目标函数：最小化所有骑手的总行程时间之和，或最小化总延迟Σ max(0, T_c - T_due)。
分配决策：r* = argmin_{r} [ Cost(S_r') ]，且满足T_c ≤ T_due + δ（δ为宽松量）和骑手任务数上限。

常量：骑手速度v，任务数上限L，时间宽松量δ。
变量：骑手任务序列S_r，新订单o，插入位置k，总时间T_total，预计送达时间T_c。

组合优化，路径规划，插入评估，目标函数最小化。

1. 实时订单流（商家、用户位置，期望时间）。
2. 骑手实时位置与状态（空闲/繁忙，任务列表）。
3. 商家历史出餐时间数据。
4. 实时路况与道路网络数据。
5. 订单分配与路径规划结果记录。

运筹优化，车辆路径问题，实时调度，外卖配送，美团/饿了么。

1. 新订单：新订单O1，商家M1，用户C1，期望45分钟后送达。
2. 候选骑手：附近有3位骑手R1, R2, R3。R1当前有2个任务，R2空闲，R3有1个任务。
3. 模拟插入：对R1，现有路径为A->B。将M1->C1插入，可能路径变为A->B->M1->C1，计算总时间增加和O1预计送达时间T_est1。
4. 评估：T_est1=40分钟，满足。同样计算R2、R3。
5. 选择最优：R2空闲，插入后T_est2=35分钟，且增加行程最短，选择R2。
6. 分配：将O1分配给R2，R2路径更新为：当前位置->M1->C1。

R-1678​

猿辅导/学而思网校教学产品部

学生、教师、平台

运营/排课与资源分配规则

在线教育“直播课排课与选课”模型

平台发布一系列直播课程（课程表），包括课程主题、教师、时间、价格、最大容量等。学生根据自己的时间安排和兴趣选择课程并支付。系统需确保选课人数不超过课程容量，并处理选课、退课、调课等操作，同时为教师生成教学日程。

在线教育直播课程排课与选课系统模型

高效匹配学生需求与教师供给，最大化课程报名率和座位利用率；为学生提供灵活的学习计划，为教师合理安排教学任务。

1. 课程容量有限，先到先得或抽签。
2. 课程可能有时间冲突，学生不能选择时间重叠的课程。
3. 选课后在一定时间内可退课或调课。
4. 课程开始前可提醒学生。

输入：课程信息Course（ID, 教师, 时间, 容量Cap）、学生选课请求Request（学生ID, 课程ID, 操作：选/退）。
输出：选课结果Result（成功/失败，原因）、课程当前报名人数Enrolled、学生已选课程列表Schedule。
流程：1. 学生浏览课程表，选择课程并提交选课请求。
2. 系统检查：该课程是否已满（Enrolled < Cap）？该学生是否已选此课？该学生已选课程中是否有时间冲突？
3. 若所有检查通过，则增加课程Enrolled计数，并将课程加入学生Schedule。
4. 若课程已满，则加入等待队列或提示失败。
5. 退课流程类似，减少Enrolled计数，从Schedule中移除。

中

设课程c的容量为C_c，已报名人数为E_c。
学生s已选课程集合为S_s，其中每门课i的时间段为[t_start_i, t_end_i]。
选课条件：对于学生s选课c（时间段[t_start_c, t_end_c]），需同时满足：
1. E_c < C_c。
2. c ∉ S_s（未选过）。
3. ∀ i ∈ S_s, [t_start_c, t_end_c] ∩ [t_start_i, t_end_i] = ∅（无时间冲突）。
选课成功：E_c ← E_c + 1, S_s ← S_s ∪ {c}。
退课：E_c ← E_c - 1, S_s ← S_s \ {c}。

常量：课程容量C_c。
变量：课程已报名人数E_c，学生已选课集合S_s，课程时间区间。

集合运算，区间重叠判断，计数增减。

1. 课程信息表（时间、教师、容量、价格）。
2. 学生选课记录表（学生ID，课程ID，状态）。
3. 课程报名人数统计。
4. 选课/退课操作日志。

在线教育，选课系统，资源预约，时间冲突检测，猿辅导。

1. 学生请求：学生S想选择课程C1（时间：周一20:00-21:00，容量30人，已报名25人）。
2. 系统检查：检查1：E_c=25 < 30，通过。检查2：S的已选课程列表S_s中无C1，通过。检查3：S已选课程有C2（周一19:00-20:00），与C1时间不重叠（C2结束时间20:00，C1开始时间20:00，假设边界不冲突），通过。
3. 选课成功：更新E_c=26，将C1加入S_s。返回成功。
4. 若冲突：如果S已选C3（周一20:30-21:30），则与C1时间重叠（20:00-21:00与20:30-21:30重叠30分钟），选课失败，提示“时间冲突”。

R-1679​

阿里云/腾讯云计费部

用户、平台

价格/用量与计费规则

云服务“按量计费”模型

对于云服务器（CVM）、对象存储（COS）、数据库等资源，按实际使用量（如CPU时间、存储容量、网络流量）和持续时间进行计费，通常以小时或秒为单位，按使用量阶梯定价。用户需先充值或设置支付方式，系统定期（如每小时）统计用量并扣费，余额不足可能触发停服。

云服务按量计费（后付费）模型

为用户提供弹性、按需付费的灵活性，降低使用门槛；同时确保平台资源使用得到合理补偿，收入与成本匹配。

1. 计费项和单价公开透明。
2. 用量统计需精确，通常有最小计费单位（如1小时）。
3. 余额不足时需提前预警。
4. 提供详细的用量账单和计费明细。

输入：用户U在计费周期T内的资源使用量Usage（如CPU小时数、存储GB-月、流出流量GB）、各资源单价PricePerUnit（可能阶梯）、用户账户余额Balance。
输出：周期T内的费用Charge、扣费后新余额NewBalance、欠费状态Arrears。
流程：1. 计量系统收集U在周期T内各资源的使用量。
2. 根据单价表，计算每个资源的费用：Charge_i = Usage_i * PricePerUnit_i（若阶梯计价，则分段计算）。
3. 总费用Charge = Σ Charge_i。
4. 从账户余额中扣除Charge：NewBalance = Balance - Charge。
5. 若NewBalance < 0，标记为欠费，并可能暂停服务直至充值。

中

设资源类型i的用量为U_i，单价为p_i（可能是用量的分段函数）。
阶梯计价示例：p_i = { p1 if 0 ≤ U_i ≤ Q1; p2 if Q1 < U_i ≤ Q2; ... }。
费用计算：C_i = ∫ p_i(U) dU（离散求和），总费用C = Σ C_i。
余额更新：B' = B - C。
欠费判断：B' < 0。

常量：单价表p_i(U)，阶梯阈值Q_j。
变量：用量U_i，费用C_i，总费用C，余额B，新余额B'。

分段函数，积分（求和），减法。

1. 资源使用量详细日志（实例运行时间、存储容量、流量）。
2. 资源单价配置表（包括阶梯价格）。
3. 用户账户余额与充值记录。
4. 计费周期账单明细。

云计算，按量计费，阶梯定价，用量统计，阿里云。

1. 用量统计：用户U在1小时内使用了1台2核4G的云服务器（单价0.1元/小时），使用了10GB存储（单价0.1元/GB/月，按小时折算），流出了5GB流量（单价0.8元/GB）。
2. 费用计算：服务器费用：0.1 * 1 = 0.1元。存储费用：0.1元/GB/月，每月按30天720小时计，每小时单价0.1/720 ≈ 0.000139元/GB/小时，10GB费用0.00139元。流量费用：0.8 * 5 = 4元。总费用C=0.1+0.00139+4≈4.10139元。
3. 扣费：从U账户余额扣除4.10元（四舍五入）。
4. 余额检查：若余额充足，扣费成功；若不足，发送欠费通知，并可能暂停服务。

R-1680​

字节跳动巨量引擎广告部

广告主、用户、平台

算法/竞价与展示规则

信息流广告“实时竞价”与“千次展示成本”模型

当用户刷新信息流时，系统从众多广告主中通过实时竞价（RTB）决定展示哪条广告。广告主为广告设定出价（如每次点击出价CPC）和目标人群。平台根据广告主的出价、广告质量度（CTR预估等）、用户匹配度等因素计算每条广告的“综合得分”，按得分高低决定胜出者，并按“第二高价”计费。广告主按实际效果（点击、转化）付费。

信息流广告实时竞价与千次展示成本（CPM）计费模型

最大化平台广告收入，同时平衡用户体验（广告质量）和广告主投资回报率（ROI），实现广告资源的优化配置。

1. 竞价在毫秒级内完成。
2. 计费方式多样（CPC, CPM, CPA），需统一换算以便比较。
3. 广告质量度（如预估CTR）影响排名和实际扣费。
4. 需防止虚假点击和作弊。

输入：用户U的特征、候选广告集合Ads（每个广告i有出价bid_i、目标人群条件、广告素材）、广告质量度预估q_i（如预估CTR）。
输出：胜出广告ad_win、广告排名Rank、实际扣费cost_per_click/impression。
流程：1. 候选检索：根据U的特征，从广告库中召回符合目标人群的广告集合Ads。
2. 预估质量分：对每个广告i，预估其对于U的点击率pCTR_i、转化率pCVR_i等。
3. 计算综合得分：score_i = bid_i * pCTR_i * α（或其他函数，如bid * pCTR^β）。
4. 排序：按score_i降序排列，最高者胜出，获得展示机会。
5. 计费：按“广义第二价格”（GSP）计费，即胜出者按下一位广告的得分折算其实际扣费，使其刚好排在第二位的位置。

高

设广告i的出价为b_i（按CPC计），预估点击率为pCTR_i。
综合得分：s_i = b_i * pCTR_i（或更一般地s_i = f(b_i, pCTR_i, pCVR_i, ...)）。
排序：按s_i降序，假设排序后s_1 ≥ s_2 ≥ ...。
GSP计费：胜出者（第一位）的实际每次点击扣费cpc_1为：cpc_1 = (s_2 / pCTR_1) + ε，其中ε为最小货币单位（如0.01元），确保s_1的得分仍然最高。对于CPM出价，需换算。

常量：计费公式，最小单位ε。
变量：出价b_i，预估点击率pCTR_i，得分s_i，实际扣费cpc_i。

乘法，排序，除法。

1. 用户特征与行为数据。
2. 广告库（出价、素材、目标人群）。
3. 广告质量度预估模型输出。
4. 竞价日志与计费记录。
5. 广告展示与点击日志。

在线广告，实时竞价，CTR预估，广义第二价格，巨量引擎。

1. 候选：用户U刷新信息流，系统召回3条广告A1, A2, A3，出价分别为1.5元, 2元, 1元（CPC）。
2. 预估CTR：模型预估A1对U的pCTR=2%，A2为1%，A3为3%。
3. 计算得分：s1=1.5 * 0.02=0.03, s2=2 * 0.01=0.02, s3=1 * 0.03=0.03。A1和A3得分相同，可按其他因素决断，假设A1胜出（排序s1, s3, s2）。
4. 计费：按GSP，A1的实际扣费cpc1 = s3 / pCTR1 = 0.03 / 0.02 = 1.5元（或加ε=1.51元）。即A1每次点击付费1.5元。

R-1681​

哈啰/美团单车运营部

用户、平台

运营/调度与定价规则

共享单车“动态调度费”模型

在车辆稀缺区域（如早高峰地铁口）或淤积区域（如晚高峰商圈），为激励用户将车辆骑到需求区域或从淤积点骑出，平台会设置动态调度费。用户在还车时，若停在“调度区域”内，可能需要支付额外的调度费；若从调度区域骑出，可能会获得优惠券奖励。

共享单车动态调度费与调度激励模型

通过价格杠杆引导用户行为，优化车辆空间分布，提高车辆利用率和用户用车满意度，同时降低平台人工调度成本。

1. 调度区域和费用/奖励需在地图上明确标识。
2. 调度费或奖励实时变化，反映供需情况。
3. 用户结束订单时即时结算调度费。
4. 可能有封顶费用。

输入：用户还车位置P_end、还车时间T、当前调度区域地图Map（每个区域Zone有调度费Fee，正数表示收费，负数表示奖励）、用户骑行轨迹Route。
输出：本次订单的调度费Surcharge（正数为需支付，负数为奖励）、订单总费用TotalFee。
流程：1. 用户结束行程，系统获取还车点P_end的经纬度。
2. 查询P_end所属的调度区域Z（如果有）。
3. 获取该区域当前的调度费Fee（可能为正或负）。
4. 若Fee > 0，则用户需额外支付Fee元；若Fee < 0，则用户获得优惠券（或直接减免骑行费）`

Fee

元。<br>5. 计算总费用：TotalFee = 骑行费 + Surcharge`。

中

设还车点坐标为(x,y)，调度区域集合为{Z_i}，每个区域Z_i有边界多边形Poly_i和当前调度费f_i。
判断所属区域：若(x,y) ∈ Poly_i，则Z = Z_i, Fee = f_i。
调度费：S = Fee。
总费用：T = R + S，其中R为基于时长和距离的常规骑行费。

常量：调度区域多边形Poly_i，调度费f_i（动态变化）。
变量：还车点(x,y)，所属区域Z，调度费S，常规骑行费R，总费T。

几何包含判断，加法。

1. 用户骑行订单数据（起终点、时间、轨迹）。
2. 调度区域动态定义与费用配置（时空范围）。
3. 车辆实时分布与供需热力图。
4. 调度费收取与奖励发放记录。

R-1682​

平安好医生/微医产品部

用户、医生、平台

运营/预约与分配规则

在线问诊“医生接单与分配”模型

用户提交在线问诊订单（选择科室、描述症状）后，系统将订单推送给在线的、符合科室的医生。医生可主动抢单，或由系统根据医生等级、擅长领域、接诊饱和度、用户评价等因素自动分配。目标是缩短用户等待时间，提高问诊匹配质量。

在线问诊医生匹配与订单分配模型

高效匹配患者与医生，提升问诊效率和用户满意度；合理分配医生工作量，保障医生收入和服务质量。

1. 医生有在线状态和可接诊时间。
2. 用户可选择指定医生或由系统分配。
3. 自动分配时需考虑医生当前接诊数量（不超过上限）。
4. 紧急情况（如重症）可能需要优先处理。

输入：用户问诊订单Order（科室Dept，症状描述Desc，紧急程度Urgency）、在线医生列表Doctors（每个医生D有科室Dept_D、擅长标签Tags_D、当前接诊数Load_D、评分Rating_D等）。
输出：分配结果（接诊医生D_assigned）、预计等待时间WaitTime。
流程：1. 若用户指定了医生，则直接分配给该医生（若该医生在线且未满负荷）。
2. 否则，系统筛选在线且科室匹配的医生候选池Cand。
3. 对Cand中的医生，根据Load_D（越低越好）、Rating_D（越高越好）、Tags_D与Desc的匹配度、Urgency等因素计算综合得分Score_D。
4. 按Score_D降序，选择最高分且Load_D < MaxLoad的医生，将订单分配给他/她。
5. 若没有医生可用，则订单进入排队队列，估计WaitTime。