# Token 交易平台设计文档 **日期:** 2026-04-21 **版本:** v1.0 **状态:** 待评审 --- ## 1. 项目概述 ### 1.1 愿景 打造一个去中心化的 API Token 额度流通平台，让个人/团队未用完的 AI API 额度可以在不同模型、不同用户之间自由交换，最大化资源利用率。 ### 1.2 核心价值主张 - **变废为宝**：把即将过期的、用不完的 API 额度换成需要的额度 - **跨模型流通**：Kimi 额度换 GPT-4 额度，打破厂商壁垒 - **公平透明**：平台提供模型真实性验证和价格参考，降低信息不对称 - **灵活交易**：支持 P2P 直接交换和平台托管代理两种模式 ### 1.3 核心约束 - 平台内部**只使用积分**作为交易货币，不涉及法币 - 交易手续费以积分形式收取（根据交易类型 5~8%，详见第 10 章） - 平台保底 key 由运营方用自有资金购买 - 所有 API key 的托管和交换必须保证安全 --- ## 2. 核心概念与术语 | 术语 | 定义 | |------|------| | **Token** | 各 AI 模型 API 的调用额度单位（如 1M GPT-4 tokens）| | **积分** | 平台内部统一计价单位，不与法币挂钩 | | **参考价** | 平台根据官方价格、模型质量、市场数据计算出的模型间兑换基准 | | **额度包** | 一组特定模型的可用 tokens，包含余额、有效期、真实性验证状态 | | **卖家** | 提供 API key / 额度的用户 | | **买家** | 消费 API 额度 / 使用平台服务的用户 | | **Key 池** | 平台托管的所有卖家 key + 平台保底 key 的集合 | | **Escrow** | 交易中临时冻结的积分/资产，交易完成后按规则释放 | | **保证金** | P2P 交易中双方质押的积分，用于违约赔付 | | **模型指纹** | 通过标准测试 prompt 识别模型身份的响应特征签名 | --- ## 3. 三阶段演进路线 ### P0: P2P 担保交换（MVP） **目标：** 最小可行产品，验证市场需求 **核心能力：** - 用户注册、信誉系统 - 余额验证、模型真实性检测（模型指纹 + 价格反推） - P2P 挂单/接单/撮合 - 双模式可选：平台中转担保 / 直接交换 - 安全通道（加密存储 + 一次性解密） - 参考价计算（基于官方价格 + 质量系数） - 保证金机制、争议仲裁基础流程 **不涉及：** 托管代理、市场竞价撮合、高级掺水监控 ### P1: 积分计量层 + 市场竞价 **目标：** 引入统一价值标尺和市场化定价 **新增能力：** - 积分账户体系（充值/消费/余额） - 市场竞价撮合引擎 - 价格偏离检查（偏离参考价 30% 以上需确认，50% 以上需审核） - 上下文长度测试、推理能力探针 - 历史成交数据驱动的参考价动态调整 ### P2: 平台托管代理（完整形态） **目标：** 提供统一 API 代理服务，完整的平台聚合器模式 **新增能力：** - Key 池化与智能路由 - 按量结算（卖家用多少结多少积分） - 实时掺水检测与风控 - 平台保底 key 池 - 高级用量分析与报表 --- ## 4. 系统架构 ``` ┌─────────────────────────────────────────────────────────────────┐ │ 前端层 │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Web 交易市场 │ │ 积分钱包 │ │ API 控制台 │ │ │ │ (挂单/搜索) │ │ (充值/提现) │ │ (key 托管) │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────────────────┐ │ API 网关层 │ │ - 认证鉴权 - 限流 - 请求路由 - 日志记录 │ └─────────────────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────────────────┐ │ 服务层 │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ 用户服务 │ │ 交易引擎 │ │ 定价引擎 │ │ │ │ (注册/认证) │ │ (挂单/撮合) │ │ (参考价/ │ │ │ │ (信誉/等级) │ │ (订单/结算) │ │ 市场数据) │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ 验证引擎 │ │ P2P 交换 │ │ 托管代理 │ │ │ │ (余额/ │ │ 服务 │ │ 服务 │ │ │ │ 真实性) │ │ (中转/ │ │ (路由/ │ │ │ │ │ │ 直接) │ │ 计量) │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ ┌────────────┐ ┌────────────┐ │ │ │ 争议仲裁 │ │ 积分服务 │ │ │ │ 服务 │ │ (账户/escrow)│ │ │ └────────────┘ └────────────┘ │ └─────────────────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────────────────┐ │ 数据层 │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌───────────┐ │ │ │ 用户数据 │ │ 订单/交易 │ │ 积分账户 │ │ API Key │ │ │ │ (PostgreSQL)│ │ (PostgreSQL)│ │ (PostgreSQL)│ │ 加密存储 │ │ │ └────────────┘ └────────────┘ └────────────┘ └───────────┘ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ 验证快照 │ │ 市场数据 │ │ 用量日志 │ │ │ │ (对象存储) │ │ (时序DB) │ │ (时序DB) │ │ │ └────────────┘ └────────────┘ └────────────┘ │ └─────────────────────────────────────────────────────────────────┘ ``` --- ## 5. 用户角色与核心流程 ### 5.1 角色定义 | 角色 | 描述 | 核心行为 | |------|------|---------| | **买家（C端）** | 需要 API 额度消费的用户 | 获取积分、购买额度、发起请求 | | **卖家（C端）** | 拥有未用完 API 额度的用户 | 存入 key、挂卖单、获得积分 | | **管理员（B端）** | 平台运营人员 | 管理用户、配置规则、处理争议、监控平台运行 | > **说明：** 一个用户可以同时是买家和卖家。管理员角色通过独立的权限系统控制，普通用户无法访问管理端。 ### 5.2 积分流向总图 ``` ┌─────────────┐ │ 买家账户 │ │ (积分余额) │ └──────┬──────┘ │ 消费积分 ▼ ┌─────────────────────────────────────────┐ │ 交易环节 │ │ ┌─────────┐ ┌─────────┐ │ │ │ P2P 交易 │ or │ 托管调用 │ │ │ │ 直接交换 │ │ │ │ │ │ 平台中转 │ │ │ │ │ └────┬────┘ └────┬────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────────────┐ │ │ │ 手续费抽成 (2%) │──────────┼──► 平台手续费账户 │ └─────────────────────────┘ │ └─────────────────────────────────────────┘ │ ▼ 剩余 98% ┌─────────────┐ │ 卖家账户 │ │ (积分余额) │ └─────────────┘ ``` --- ## 6. 验证引擎 验证引擎是平台公平性的核心保障，对每一个进入平台的 API key 执行标准化检测，输出不可篡改的验证报告。 ### 6.1 检测维度 | 检测项 | 方法 | 执行时机 | 可信度 | |--------|------|---------|--------| | **余额验证** | 调用提供商余额接口或发送测试请求前后对比余额 | 每次交易前、每日定时 | 高 | | **模型指纹** | 用标准测试 prompt 发送请求，对比响应特征（token 消耗模式、输出风格、延迟、特殊 token 行为）与官方样本 | 每次交易前 | 高 | | **价格反推** | 发送已知 token 数请求，对比实际扣费与官方定价 | 每次交易前 | 高 | | **上下文长度测试** | 发送超过标称短上下文模型的 prompt，验证是否报错或截断 | 每周抽检 | 高 | | **推理能力探针** | 发送标准能力测试题，对比官方基准得分 | 每周抽检 | 中 | ### 6.2 验证报告格式 ```json { "report_id": "vrp_abc123", "model_claimed": "kimi-moonshot-v1-128k", "provider": "moonshot", "submitter_id": "user_123", "verified_at": "2026-04-21T14:32:00Z", "results": { "balance": { "status": "passed", "remaining_tokens": 12450000, "expires_at": "2026-12-31" }, "fingerprint": { "status": "passed", "match_score": 98.7 }, "pricing": { "status": "passed", "observed_rate": "consistent" }, "context_window": { "status": "warning", "claimed": 128000, "tested_max": 96000, "notes": "实测到 96k 开始截断" }, "reasoning": { "status": "passed", "score": 92, "baseline": 94 } }, "overall": "verified_with_warnings", "warning_notes": ["上下文窗口略低于标称值"] } ``` ### 6.3 掺水检测（托管模式） | 检测方案 | 原理 | 响应速度 | |---------|------|---------| | **余额变化监控** | 定期查询余额，对比"平台已使用量"和"余额实际减少量" | 延迟高（小时级） | | **请求成功率监控** | 监控平台请求失败率（429/401），异常飙升即预警 | 实时 | | **动态速率预留** | 平台控制每个托管 key 的请求速率，预留余量 | 预防性 | | **保证金惩罚** | 检测到掺水后，从提供者押金中扣除赔付 | 事后惩罚 | **触发阈值与处理：** - 余额差额 > 5%：标记预警，增加监控频率 - 余额差额 > 15% 或失败率 > 10%：立即暂停该 key 的调度，通知卖家 - 已发生的合法用量正常结算，外部使用部分由卖家承担 --- ## 7. 定价引擎 ### 7.1 参考价公式 ``` 参考兑换率(模型A → 模型B) = (模型A 官方价格 $/1M tokens) / (模型B 官方价格 $/1M tokens) × 质量系数(A/B) × 市场供需调整因子 其中: - 质量系数: 基于 LMSYS 等第三方评测排名，线性映射到 0.5 ~ 2.0 - 市场供需调整: 基于平台最近 7 天成交数据 - 供不应求: 溢价系数 1.0 ~ 1.3 - 供过于求: 折价系数 0.7 ~ 1.0 - 供需平衡: 系数 1.0 ``` ### 7.2 参考价更新频率 | 数据源 | 更新频率 | 触发条件 | |--------|---------|---------| | 官方价格 | 实时（有变动时） | 提供商调价公告 | | 质量系数 | 每周 | LMSYS 新排名发布 | | 市场供需 | 每日 | 每日凌晨计算前 7 天成交数据 | ### 7.3 市场竞价与偏离检查（P1） - 买方挂买单：愿意用 X 积分购买 Y 个"模型 Z 的额度" - 卖方挂卖单：愿意以 Y 积分出售 X 个"模型 W 的额度" - 系统撮合时自动应用参考价作为价格合理性检查： - 偏离参考价 ±30% 以内：正常撮合 - 偏离参考价 30~50%：提示"价格偏离较大，请确认" - 偏离参考价 >50%：需要平台人工审核 --- ## 8. P2P 交易流程 ### 8.1 模式 A：平台中转担保（推荐） ``` 用户 A (卖家) 平台 用户 B (买家) │ │ │ │── 挂卖单 ─────────>│ │ │ "Kimi 5亿换 │ │ │ GPT-4 1亿" │ │ │ │ │ │ │◄── 浏览/搜索/接单 ──────│ │ │ │ │ │── 创建临时 session │ │ │ 生成临时 endpoint │ │ │ │ │── 提交 key_A ─────>│ │ │ 到平台加密存储 │ │ │ │ │ │ │── 验证 key_A │ │ │ (余额/真实性) │ │ │ │ │ │◄── B 确认交易 ──────────│ │ │ B 预扣积分到 escrow │ │ │ │ │ │── 交易激活 │ │ │ │ │ │◄── B 向临时 endpoint │ │ │ 发起请求 │ │ │ │ │ │── 用量校验 │ │ │ (是否超出购买额度) │ │ │ │ │ │── 转发给 key_A │ │ │── 返回结果给 B │ │ │ │ │ │── 记录实际用量 │ │ │── 实时结算积分给 A │ │ │ (从 escrow 释放) │ │ │ │ │◄── 获得积分 ────────│ │ │ │ │ │ │── 额度用完或超时 │ │ │── 释放 key_A │ │ │ (加密清除) │ │ │── 交易完成 │ ``` **平台保障：** - 用量限制：买家最多使用购买的额度，超出的请求被拦截 - 真实性验证：交易前验证卖家 key - 掺水监控：交易期间检测卖家是否在外部同时使用 - 完整日志：所有请求有详细记录，作为争议证据 ### 8.2 模式 B：直接交换 ``` 用户 A (卖家) 平台 用户 B (买家) │ │ │ │── 挂卖单 ─────────>│ │ │ │ │ │ │◄── B 接单 ─────────────│ │ │ │ │ │── 双方确认 │ │ │ 进入"准备交换" │ │ │ │ │── 提交 key_A ─────>│ │ │ 到安全通道 │ │ │ │◄── B 提交 key_B ────────│ │ │ 到安全通道 │ │ │ │ │ │── 验证双方 key │ │ │ (余额二次确认) │ │ │ │ │ │── 生成一次性解密链接 │ │ │ 分别发送给双方 │ │ │ │ │◄── 点击链接 ────────│ │ │ 获得 key_B │ │ │ (浏览器端解密) │ │ │ │──► B 点击链接 │ │ │ 获得 key_A │ │ │ │ │── 确认 & 测试 ────>│◄── 确认 & 测试 ─────────│ │ │ │ │ │── 交易完成 │ │ │ 释放保证金 │ │ │ 更新声誉 │ ``` **安全通道设计：** - key 使用平台公钥加密存储 - 交易完成后生成一次性解密链接（24h 有效） - 解密在浏览器端完成，平台服务器**不保留明文** - 交易快照（验证报告、余额、时间戳）永久保存用于仲裁 ### 8.3 两种模式对比 | 维度 | 平台中转担保 | 直接交换 | |------|------------|---------| | 速度 | 需平台介入，稍慢 | 验证完即交换，快 | | 用量保障 | 平台限制用量 | 无限制，拿到 key 后随意用 | | 掺水监控 | 交易期间监控 | 交易后无监控 | | 模型真实性 | 交易前验证 | 交易前验证 | | 争议处理 | 有完整日志 | 只有交易快照 | | 手续费 | 较高（平台承担代理成本） | 较低（只做验证） | | 推荐场景 | 大额交易、不信任对方 | 小额交易、信任对方 | --- ## 9. 托管代理模式（P2 阶段） ### 9.1 核心原则：先用后结，逐笔清算 ``` 用户存入 key ──► 平台验证 ──► 生成"托管资产记录" │ │ (不发放积分) ▼ 加入 Key 池，等待调度 │ ▼ 买家购买"调用配额" (预扣积分到 escrow) │ ▼ 请求通过平台代理 路由到对应托管 key │ ▼ 精确计量本次 token 消耗 │ ▼ 按参考价折算为"应结积分" │ ▼ 从 escrow 释放给卖家 多余部分返还买家 ``` ### 9.2 结算时序示例 | 时间点 | 事件 | 卖家积分 | 买家积分 | |-------|------|---------|---------| | T0 | 卖家存入 key，验证通过 | 0（未发放） | - | | T1 | 买家购买 100M tokens 配额，预扣 500 积分 | 0 | -500（冻结） | | T2 | 买家请求，实际消耗 1000 tokens | 0 | -500（冻结） | | T3 | 折算：1000 tokens = 0.5 积分 | +0.5（到账） | -0.5（实际），+499.5（释放） | | T4 | 累计消耗 1M tokens | +3.0（累计） | -3.0（累计），+497（释放） | | Tn | 配额用完或 key 失效 | 按实际总消耗结算 | 剩余 escrow 全额返还 | ### 9.3 路由策略 优先级从高到低： 1. **模型匹配** — 只从目标模型的 key 中选择 2. **余额充足** — 排除余额 < 安全阈值的 key 3. **成本优先** — 优先使用卖家 key（成本为 0），其次平台保底 key 4. **负载均衡** — 同成本下优先使用使用率低的 key 5. **质量优先** — 排除近期失败率高的 key 6. **保底兜底** — 所有卖家 key 不可用时，使用平台自有 key ### 9.4 Key 失效处理 - 平台监控 key 状态（401/403/余额归零） - 自动标记为"不可用"，从调度池中移除 - 未消耗的买家配额：escrow 全额返还 - 已发生的交易：正常结算 - 卖家声誉分扣减 --- ## 10. 积分经济模型 ### 10.1 积分获取途径 | 途径 | 说明 | 阶段 | |------|------|------| | 存入 API key | 托管模式下按实际用量获得积分 | P2 | | P2P 交易 | 出售额度获得积分 | P0 | | 平台奖励 | 新用户注册奖励、邀请返利、活动奖励 | P1 | | 积分互转 | 用户间直接转账（可选） | P1 | ### 10.2 积分消费途径 | 途径 | 说明 | 阶段 | |------|------|------| | P2P 购买额度 | 购买其他用户的 API 额度 | P0 | | 托管模式调用 | 通过平台代理消费额度 | P2 | | 支付手续费 | 交易时扣除的手续费 | P0 | | 支付保证金 | P2P 交易时质押 | P0 | ### 10.3 手续费机制 | 交易类型 | 手续费率 | 说明 | |---------|---------|------| | P2P 直接交换 | 5% | 平台承担验证成本 | | P2P 平台中转 | 8% | 平台承担代理成本 | | 托管模式调用 | 5% | 平台承担路由和监控成本 | 手续费以**实际消耗的 token 数量**为基数计算，从买家 escrow 中扣除，进入平台手续费账户。 ### 10.4 平台手续费账户用途 平台积累的积分用于： 1. **平台运营者自用**：使用平台上的 API 服务 2. **用户激励**：新用户注册奖励、邀请返利、交易返佣 3. **未来变现储备**：P3 阶段可能开放法币购买积分通道时，平台拥有的积分具有变现价值 4. **生态建设**：赞助社区活动、开发者奖励 --- ## 11. 信任与声誉系统 ### 11.1 信誉分计算 ``` 信誉分 = 基础分(100) + 成功交易次数 × 2 - 争议败诉次数 × 20 - 取消订单次数 × 1 - key 失效次数 × 10 + 好评率加成(0 ~ 30) ``` ### 11.2 信誉等级 | 等级 | 分数范围 | 权益 | |------|---------|------| | 新星 | 0 - 50 | 交易限额低，保证金比例 20% | | 可信 | 50 - 150 | 正常交易，保证金比例 10% | | 资深 | 150 - 300 | 限额提升，保证金比例 5%，优先撮合 | | 至尊 | 300+ | 大额交易权限，最低保证金，专属客服 | ### 11.3 评价系统 每笔交易完成后，双方可以互相评价： - 评分：1~5 星 - 标签：快速响应、额度准确、key 稳定、沟通顺畅 等 - 文字评价（可选） --- ## 12. 争议仲裁机制 ### 12.1 争议类型与处理 | 争议类型 | 触发条件 | 仲裁依据 | 处理结果 | |---------|---------|---------|---------| | Key 无效 | 买方无法使用收到的 key | 交易快照中的验证报告 | 卖方全责，保证金赔付 | | 余额不足 | 实际余额 < 交易快照 | 快照 vs 实时余额 | 按差额比例赔付 | | 模型不符 | 收到的不是标称模型 | 验证引擎检测报告 | 卖方全责，全额赔付 | | 一方不确认 | 超时不点击确认 | 聊天记录 + 系统日志 | 平台介入调查 | | 双方互指责 | 各自声称对方违约 | 全部证据 + 验证报告 | 平台仲裁，败方扣信誉分 | ### 12.2 保证金机制 - 每笔 P2P 交易双方各质押交易额的 5~20%（根据信誉等级） - 交易顺利完成，保证金返还 - 任何一方违约，保证金赔付给守约方 - 争议中平台暂扣保证金，仲裁后按结果分配 --- ## 13. 盈利模式 ### 13.1 收入来源 | 收入项 | 说明 | 阶段 | |--------|------|------| | 交易手续费 | 每笔交易抽成 5~8%（以积分形式） | P0 | | 会员费 | Pro/企业会员按月收取积分，享受更低手续费和更高限额 | P1 | | 数据服务 | 出售市场数据 API（价格趋势、交易量、模型热度） | P2 | | 广告位 | 热门模型推荐位、优质卖家推广位 | P2 | ### 13.2 渐进式盈利策略 | 阶段 | 策略 | 核心收入 | |------|------|---------| | P0 启动期 | 纯手续费 | 每笔交易抽 5~8%，快速验证市场 | | P1 增长期 | 手续费 + 基础会员 | 引入 Pro 会员（降手续费 + 优先权） | | P2 成熟期 | 会员 + 数据服务 + 广告 | 多元化收入来源 | --- ## 14. 技术选型建议 ### 14.1 后端 | 组件 | 推荐 | 理由 | |------|------|------| | 主框架 | Go (Gin/Echo) | 高并发代理场景性能好，与 new-api 经验一致 | | 数据库 | PostgreSQL | 关系型数据（用户、订单、积分） | | 缓存 | Redis | 会话、限流、热点数据 | | 消息队列 | NATS / Redis Stream | 异步结算、事件驱动 | | 时序数据 | InfluxDB / TimescaleDB | 用量日志、市场数据 | | Key 存储 | HashiCorp Vault | 安全的 secrets 管理 | ### 14.2 前端 | 组件 | 推荐 | |------|------| | 框架 | React + TypeScript | | UI 库 | Ant Design / Shadcn | | 状态管理 | Zustand | ### 14.3 基础设施 | 组件 | 推荐 | |------|------| | 部署 | Docker + Docker Compose (初期) | | 反向代理 | Nginx / Caddy | | 监控 | Prometheus + Grafana | | 日志 | Loki / ELK | --- ## 15. P0 MVP 范围 ### 15.1 必须实现（P0-1） - [ ] 用户注册、登录、基础信息 - [ ] 积分账户（初始化赠送，支持增减） - [ ] 余额验证引擎（支持主流 API：OpenAI、Kimi、GLM、Claude 等） - [ ] 模型指纹检测（至少覆盖 5 个主流模型） - [ ] P2P 挂单/搜索/接单 - [ ] P2P 直接交换（安全通道） - [ ] 参考价计算（基于官方价格 + 静态质量系数） - [ ] 保证金机制 - [ ] 交易快照与基础争议仲裁 ### 15.2 管理端（P0 必须） 管理端为平台运营人员提供独立后台，与用户端（C端）完全分离，通过权限系统控制访问。 | 模块 | 功能描述 | 优先级 | |------|---------|--------| | **仪表盘** | 平台核心指标概览：注册用户数、今日交易量、待处理争议数、活跃 key 数 | P0 | | **用户管理** | 查看用户列表、调整信誉分、禁用/启用账户、查看用户交易历史 | P0 | | **交易监控** | 查看所有挂单/订单列表、标记异常交易（大额、高频、价格偏离）、强制取消订单 | P0 | | **争议仲裁** | 查看申诉详情、查看交易快照与验证报告、执行赔付/驳回、扣除保证金 | P0 | | **验证引擎管理** | 配置各模型验证参数、查看验证报告历史、手动触发重验证、管理模型指纹库 | P0 | | **参考价管理** | 配置各模型官方价格、调整质量系数、查看参考价变更日志 | P0 | | **平台设置** | 手续费率配置（各交易类型）、保证金比例规则、积分初始值设置、系统公告发布 | P0 | | **操作日志** | 记录管理员所有操作（谁、何时、做了什么），支持审计追溯 | P0 | ### 15.3 建议实现（P0-2） - [ ] P2P 平台中转担保模式 - [ ] 信誉等级系统 - [ ] 评价系统 - [ ] 邀请返利机制 ### 15.4 明确不实现（P0 排除） - [ ] 托管代理模式（P2） - [ ] 市场竞价撮合（P1） - [ ] 动态参考价（P1） - [ ] 推理能力探针（P1） - [ ] 法币购买积分（P3） - [ ] 企业会员/数据服务（P2） --- ## 16. 风险与挑战 ### 16.1 技术风险 | 风险 | 影响 | 缓解措施 | |------|------|---------| | API 提供商反爬虫/反代理 | 验证引擎失效 | 模拟正常用户行为，控制请求频率，备用验证方案 | | Key 泄露 | 用户资产损失 | 加密存储、最小权限、安全审计 | | 高并发代理性能 | 服务不可用 | Go 高性能、缓存、限流、降级策略 | | 模型指纹被绕过 | 掺水/套壳检测失效 | 多维度检测组合、定期更新测试 prompt | ### 16.2 合规风险 | 风险 | 影响 | 缓解措施 | |------|------|---------| | API 提供商 ToS 禁止 key 共享 | 账号被封 | 明确告知用户风险、分散 key 使用、不长期托管 | | 积分被认定为虚拟货币 | 监管问题 | 积分不可提现、不与法币直接挂钩、用户协议明确 | | 数据隐私 | 法律风险 | 最小化数据收集、加密存储、透明隐私政策 | ### 16.3 运营风险 | 风险 | 影响 | 缓解措施 | |------|------|---------| | 早期流动性不足 | 交易撮合困难 | 平台运营方注入初始流动性（自有 key）、激励早期用户 | | 定价偏离真实价值 | 用户流失 | 透明定价公式、市场数据公开、用户反馈渠道 | | 恶意用户欺诈 | 平台信誉受损 | 多层验证、声誉系统、保证金、快速争议处理 | --- ## 17. 成功指标 | 指标 | P0 目标 | P1 目标 | P2 目标 | |------|--------|--------|--------| | 注册用户数 | 500 | 5,000 | 50,000 | | 月活跃交易用户 | 100 | 1,000 | 10,000 | | 月交易量（积分） | 100,000 | 1,000,000 | 10,000,000 | | 争议率 | < 5% | < 3% | < 1% | | 模型验证准确率 | > 90% | > 95% | > 98% | | NPS 评分 | > 30 | > 40 | > 50 | --- ## 附录 A：支持的 API 提供商（P0 初始） | 提供商 | 模型 | 验证支持 | 优先级 | |--------|------|---------|--------| | OpenAI | GPT-4, GPT-4o, GPT-3.5 | 余额 + 指纹 | P0 | | Moonshot (Kimi) | kimi-moonshot-v1 | 余额 + 指纹 | P0 | | Zhipu (GLM) | glm-4, glm-4-plus | 余额 + 指纹 | P0 | | Anthropic | Claude 3.5 Sonnet, Claude 3 Opus | 余额 + 指纹 | P0 | | DeepSeek | deepseek-chat, deepseek-coder | 余额 + 指纹 | P0 | | Google | Gemini Pro, Gemini Ultra | 余额 + 指纹 | P1 | | Alibaba (通义) | qwen-plus, qwen-max | 余额 + 指纹 | P1 | ## 附录 B：术语对照表 | 中文术语 | 英文术语 | |---------|---------| | 额度包 | Quota Package | | 参考价 | Reference Rate | | 保证金 | Security Deposit | | 托管资产 | Escrowed Asset | | 模型指纹 | Model Fingerprint | | 掺水 | Key Dilution | | Key 池 | Key Pool | | 智能路由 | Smart Routing |
