46 lines
3.1 KiB
Markdown
46 lines
3.1 KiB
Markdown
# 项目愿景
|
|
|
|
## 一、核心目标
|
|
|
|
`cmhub` 要解决：`cmbot` 的 AI 生成能力（标题、图片）目前锁在单机桌面工具里，无法被其他项目复用，也没有计费和用量管控。
|
|
|
|
> 让**其他业务项目**能够**通过 HTTP API 调用 AI 生成标题和图片**，并获得**按点数计费、用量可控、调用可追溯**的能力。
|
|
|
|
它面向两类使用者：**终端用户**在自助用户端注册、扫码充值、管理自己的 API Key；**其他业务项目/程序**用这些 API Key 调用生成接口。本服务是**自助用户端 + 计费型 AI 能力网关 + 运营后台**三合一。用户端不做面向消费者的「内容生成产品页」，只做账户自助（注册/充值/Key 管理/记录），生成结果仍只经 API 输出。
|
|
|
|
## 二、目标用户
|
|
|
|
- **注册用户（终端用户）**：在用户端自助注册登录、扫码充值、查看自己的充值记录/充值总额/剩余点数/消费记录、自助生成与删除 API Key。点数余额挂在用户账户上。
|
|
- **接入方（用户的程序 / 其他项目）**：拿用户名下的 API Key 调用生成接口，关心稳定、点数够不够、报错清晰；扣的是所属用户的点数。
|
|
- **运营人员**：在 django-admin 管理注册用户、点数余额、计费规则，查看充值和调用记录，处理点数不足/异常。
|
|
|
|
## 三、产品原则
|
|
|
|
遇到取舍时，以这些原则为准：
|
|
|
|
- **核心流程优先**：先把「鉴权 → 计费 → 生成 → 扣点 → 记录」这条主链路做顺。
|
|
- **真实数据优先**：点数、金额、扣费、充值不造假；不用演示逻辑冒充计费逻辑。
|
|
- **账目必须对得上**：每一笔点数变动都有流水、可追溯到充值订单或调用记录。
|
|
- **小步交付**：每一步都能运行、能验证、能回退。
|
|
- **少即是稳**：MVP 不追求完整，只追求最小闭环可靠；先同步、先单机、先后台手工开通。
|
|
- **可维护**：复用 `cmbot` 现有 AI 调用代码，不另起一套。
|
|
|
|
## 四、核心价值主张
|
|
|
|
| 价值点 | 说明 |
|
|
| --- | --- |
|
|
| 能力复用 | 把 `cmbot` 的标题/图片生成开放给任意项目，无需各自重复对接上游 |
|
|
| 按量计费 | 不同操作/模型消耗不同点数，用量与成本可控 |
|
|
| 充值即点数 | 外部支付系统付款后自动转点数，扣费与上游解耦、低延迟 |
|
|
| 可观测可运营 | django-admin 一处管理账号、点数、计费规则、充值与调用记录 |
|
|
|
|
## 五、不做什么（非目标）
|
|
|
|
- 不做自建支付/收银台，付款在外部支付系统完成，本服务发起扫码下单并接收回调，不碰资金清算。
|
|
- 不做异步任务队列（第一版图片生成走同步等待）。
|
|
- 不做面向终端消费者的「内容生成产品页」；用户端只做账户自助（注册/充值/API Key 管理/记录查询）。
|
|
- **注册不赠送免费点数**：必须充值才有点数，降低薅羊毛/滥用风险。
|
|
- 不做多币种、分账、自动退款对账等容易膨胀、不属于 MVP 的能力。
|
|
|
|
> MVP 的具体功能范围与验收标准，见 [需求](02-requirements.md)。
|