13 KiB
13 KiB
业务逻辑与风控深度评审报告
评审日期：2026-03-18 评审方法：商业模式审查 + 风险建模 + 行业对标 评审范围：商业模式、计费逻辑、风控体系
1. 评审团队与方法
1.1 评审专家
- 商业模式专家 - 负责商业模式合理性评审
- 金融风控专家 - 负责计费与资金安全评审
- 合规顾问 - 负责合规风险评审
1.2 评审框架
| 维度 | 评估方法 |
|---|---|
| 商业模式 | 价值主张 + 成本结构 + 盈利性 |
| 计费逻辑 | 准确性 + 公平性 + 可审计性 |
| 风控体系 | 覆盖度 + 有效性 + 响应速度 |
| 合规性 | 法规对照 + 风险评估 |
2. 商业模式分析
2.1 当前商业模式概述
统购统销模式：
供应方 ──(60%折扣)──▶ 平台 ──(+15-50%毛利)──▶ 需求方
收入来源：
1. 套餐销售 (Growth/Enterprise)
2. API调用费
3. 增值服务
2.2 商业模式评分
| 维度 | 评分 | 说明 |
|---|---|---|
| 价值主张 | 8/10 | 差异化明确 |
| 成本结构 | 7/10 | 需细化 |
| 盈利性 | 7/10 | 15-50%毛利合理 |
| 可持续性 | 6/10 | 依赖供应商 |
商业模式评分：7/10
3. 深度问题分析
3.1 严重问题（Critical）
问题 B-01：资金池合规风险
发现： 平台涉及资金流转（采购→销售），可能涉及合规问题：
风险分析：
资金流：
1. 用户付款 → 平台账户
2. 平台 → 供应方结算
问题：
1. 是否需要支付牌照？
2. 资金沉淀如何处理？
3. 如何合规纳税？
行业对标：
合规要求：
1. 支付牌照
- 微信/支付宝支付需要牌照
- 资金托管需要牌照
2. 税务合规
- 平台收入需要纳税
- 代扣代缴供应方个人所得税
3. 资金托管
- 建议使用第三方支付
- 避免资金池
建议：
- 资金托管：使用 Stripe/Ping++ 等持牌机构
- 合规咨询：咨询律师确认资质要求
- 资金隔离：平台账户与运营账户分离
风险评级：🔴 P0
问题 B-02：计费精度风险
发现： 当前计费依赖 Usage 计算，存在精度问题：
风险场景：
Token 计费问题：
1. 浮点数精度
- 0.001 * 1000 = 1.0000000001
- 可能导致计费不准确
2. 并发计费
- 同一时刻多个请求
- 余额扣减可能出问题
3. 退款处理
- 如何处理异常扣费？
- 如何追溯？
建议：
from decimal import Decimal, ROUND_HALF_UP
class BillingEngine:
def calculate_cost(self, usage: Usage, price: Price) -> Money:
# 使用 Decimal 避免浮点问题
input_cost = Decimal(str(usage.prompt_tokens)) * Decimal(str(price.input))
output_cost = Decimal(str(usage.completion_tokens)) * Decimal(str(price.output))
total = (input_cost + output_cost).quantize(
Decimal('0.01'),
rounding=ROUND_HALF_UP
)
return Money(amount=total, currency='USD')
计费对账：
# 双重记账
class DoubleEntryBookkeeping:
def record_billing(self, transaction: Transaction):
# 借方：用户账户
self.debit(
account='user.balance',
amount=transaction.amount,
user_id=transaction.user_id
)
# 贷方：收入
self.credit(
account='revenue',
amount=transaction.amount
)
# 记录到审计日志
self.audit_log(
transaction_id=transaction.id,
type='billing',
details=transaction.to_dict()
)
风险评级：🔴 P0
问题 B-03：供应方结算风险
发现： 供应方结算涉及资金，需要严格控制：
风险场景：
结算风险：
1. 虚假挂载
- 用户挂载虚假账号
- 骗取结算
2. 额度作弊
- 篡改使用量
- 骗取更多结算
3. 恶意退款
- 用户退款
- 但供应方已结算
建议：
- 结算前对账：
class SettlementProcessor:
def process_settlement(self, provider_id, period):
# 1. 获取使用记录
usage = self.get_verified_usage(provider_id, period)
# 2. 与计费系统对账
billing = self.get_billing_records(period)
if not self.verify_match(usage, billing):
raise SettlementError("Usage and billing mismatch")
# 3. 计算结算金额
amount = self.calculate_settlement(usage, provider_id.rate)
# 4. 风控检查
if self.is_suspicious(provider_id, amount):
raise SettlementError("Flagged for manual review")
# 5. 执行结算
return self.execute_settlement(provider_id, amount)
-
阶梯结算：
- 新供应方：T+30结算
- 稳定供应方：T+14结算
- 优质供应方：T+7结算
-
保证金制度：
- 个人：¥500
- 企业：¥5,000
风险评级：🔴 P0
3.2 高风险问题（High）
问题 B-04：毛利率不稳定
发现： 15-50%毛利率范围过大，实际操作困难：
问题分析：
毛利率 = (售价 - 采购价) / 售价
问题：
1. 采购价波动如何处理？
2. 售价如何动态调整？
3. 不同客户毛利率差异大，如何定价？
建议：
class PricingEngine:
BASE_MARGIN = 0.30 # 基础毛利率 30%
def calculate_price(self, cost: Decimal, customer_tier: str) -> Money:
# 1. 基础定价
base_price = cost / (1 - self.BASE_MARGIN)
# 2. 客户层级调整
tier_multiplier = {
'free': 0.8, # 低价引流
'growth': 1.0, # 标准
'enterprise': 1.3 # 高毛利+服务
}
# 3. 供需系数
supply_factor = self.get_supply_factor(cost.model)
demand_factor = self.get_demand_factor(cost.model)
# 4. 最终定价
final_price = base_price * tier_multiplier[customer_tier]
final_price *= supply_factor * demand_factor
return Money(amount=final_price)
def validate_margin(self, price: Money, cost: Decimal) -> bool:
actual_margin = (price.amount - cost) / price.amount
return 0.15 <= actual_margin <= 0.50
风险评级：🟡 P1
问题 B-05：风控覆盖不完整
发现： 当前风控主要关注供应方，但需求方风控不足：
风险场景：
需求方风险：
1. 恶意使用
- 用户恶意消耗额度
- 逃费
2. 账户共享
- 多人共用一个账户
- 超额使用
3. 薅羊毛
- 利用优惠大量注册
- 骗取免费额度
建议：
class ConsumerRiskController:
RISK_SIGNALS = {
'high_token_velocity': {'threshold': 1000, 'window': 60}, # 1分钟1000token
'multiple_accounts': {'threshold': 5, 'window': 3600}, # 1小时5个账户
'unusual_pattern': {'model': 'anomaly_detection'}, # 异常模式
'rapid_api_calls': {'threshold': 100, 'window': 60}, # 1分钟100次
}
def evaluate_risk(self, user_id, request) -> RiskScore:
signals = []
# 1. 检查使用速度
velocity = self.get_token_velocity(user_id)
if velocity > self.RISK_SIGNALS['high_token_velocity']['threshold']:
signals.append('high_token_velocity')
# 2. 检查账户关联
related = self.get_related_accounts(user_id)
if len(related) > self.RISK_SIGNALS['multiple_accounts']['threshold']:
signals.append('multiple_accounts')
# 3. 异常检测
if self.is_anomalous(user_id, request):
signals.append('unusual_pattern')
# 4. 计算风险分数
score = self.calculate_score(signals)
# 5. 响应
if score > 80:
return RiskScore(block=True, reason='High risk')
elif score > 50:
return RiskScore(verify=True, reason='Manual review')
else:
return RiskScore(allow=True)
风控维度：
| 风险类型 | 检测方法 | 响应 |
|---|---|---|
| 恶意使用 | 速度异常 | 限流 |
| 账户共享 | 行为分析 | 封号 |
| 薅羊毛 | 设备指纹 | 审核 |
| 逃费 | 余额预警 | 暂停 |
风险评级：🟡 P1
问题 B-06：定价模型不清晰
发现： 当前定价只提到"毛利率15-50%"，但未明确具体定价模型：
缺失内容：
| 定价要素 | 当前状态 | 需设计 |
|---|---|---|
| 基础定价 | 毛利率公式 | 需明确 |
| 差异化定价 | 提及分层 | 需细化 |
| 动态定价 | ❌ 缺失 | 需补充 |
| 促销策略 | ❌ 缺失 | 需补充 |
建议：
class PricingModel:
# 定价公式
PRICE = COST * (1 + MARGIN) * SUPPLY_FACTOR * DEMAND_FACTOR
# 定价层级
TIERS = {
'free': {
'margin': 0.15,
'monthly_quota': 100000,
'features': ['basic']
},
'growth': {
'margin': 0.30,
'monthly_quota': 1000000,
'features': ['basic', 'analytics']
},
'enterprise': {
'margin': 0.45,
'monthly_quota': 'unlimited',
'features': ['basic', 'analytics', 'support', 'sla']
}
}
# 动态定价因素
DYNAMIC_FACTORS = {
'supply_availability': 0.8-1.2, # 供给系数
'demand_level': 0.9-1.3, # 需求系数
'competition': 0.85-1.15, # 竞争系数
'customer_relationship': 0.9-1.1 # 客户关系系数
}
风险评级：🟡 P1
3.3 中等风险问题（Medium）
| 问题编号 | 问题 | 建议 | 风险等级 |
|---|---|---|---|
| B-07 | 退款机制缺失 | 设计完整退款流程 | 🟢 P2 |
| B-08 | 发票机制缺失 | 对接发票系统 | 🟢 P2 |
| B-09 | 定价透明度不足 | 公开定价规则 | 🟢 P2 |
| B-10 | 优惠策略缺失 | 设计优惠券系统 | 🟢 P2 |
4. 计费逻辑深度分析
4.1 当前计费流程
用户请求 ──▶ 预扣额度 ──▶ 处理请求 ──▶ 实际扣费 ──▶ 账单生成
4.2 计费风险矩阵
| 风险点 | 影响 | 防护状态 | 建议 |
|---|---|---|---|
| 预扣失败 | 资金损失 | ⚠️ 需完善 | 增加重试 |
| 扣费不准 | 资金损失 | ❌ 需设计 | 双重对账 |
| 并发问题 | 计费错误 | ❌ 需设计 | 分布式事务 |
| 退款困难 | 用户投诉 | ❌ 需设计 | 自动化退款 |
| 账单争议 | 法律风险 | ⚠️ 需完善 | 完整记录 |
5. 风控体系分析
5.1 当前风控覆盖
| 风控对象 | 风控措施 | 覆盖度 |
|---|---|---|
| 供应方 | 保证金+实名+验证 | 70% |
| 需求方 | 余额预警+限流 | 50% |
| 账户 | 基础验证 | 60% |
| 交易 | 基础验证 | 40% |
5.2 风控建议
# 完整风控体系
class RiskControlSystem:
def __init__(self):
# 1. 身份风控
self.identity_risk = IdentityRiskController()
# 2. 交易风控
self.transaction_risk = TransactionRiskController()
# 3. 行为风控
self.behavior_risk = BehaviorRiskController()
# 4. 信用风控
self.credit_risk = CreditRiskController()
def evaluate(self, context: RiskContext) -> RiskDecision:
# 并行评估
results = asyncio.gather(
self.identity_risk.check(context),
self.transaction_risk.check(context),
self.behavior_risk.check(context),
self.credit_risk.check(context)
)
# 综合决策
return self.decision_engine.merge(results)
6. 总结
6.1 业务逻辑评分
| 维度 | 评分 | 说明 |
|---|---|---|
| 商业模式 | 7/10 | 统购统销合理，需细化 |
| 计费逻辑 | 5/10 | 需完善精度和对账 |
| 风控体系 | 6/10 | 覆盖不完整 |
| 合规性 | 5/10 | 需法务确认 |
业务逻辑综合评分：5.75/10
6.2 关键行动项
| 优先级 | 行动项 |
|---|---|
| 🔴 P0 | 资金流转合规咨询（支付牌照、税务） |
| 🔴 P0 | 设计高精度计费系统（Decimal + 双重记账） |
| 🔴 P0 | 设计完整结算风控流程 |
| 🟡 P1 | 完善需求方风控体系 |
| 🟡 P1 | 明确定价模型和毛利率管理机制 |
| 🟡 P1 | 设计退款和争议处理机制 |
| 🟢 P2 | 设计发票系统对接 |
| 🟢 P2 | 设计优惠券系统 |
7. 附录：行业对标
7.1 竞品商业模式
| 产品 | 定价策略 | 毛利率 | 特点 |
|---|---|---|---|
| OpenAI | 官方定价 | 0% | 官方直售 |
| Azure OpenAI | 官方定价 | 0% | 企业定价 |
| OpenRouter | 加价5-30% | 5-30% | 聚合平台 |
| 我们的方案 | 加价15-50% | 15-50% | 统购统销 |
7.2 计费系统最佳实践
Stripe Billing:
- 预付 + 后付
- 自动扣款
- 完整对账
- 退款API
AWS:
- 按量付费
- 预留实例
- 阶梯定价
- 成本分配标签
评审完成时间：2026-03-18 下次评审：商业模式确定后