fix: reduce signup bonus to ten points

docs/01-vision.md

@@ -21,7 +21,7 @@
 - **核心流程优先**：先把「鉴权 → 计费 → 生成 → 扣点 → 记录」这条主链路做顺。
 - **真实数据优先**：点数、金额、扣费、充值不造假；不用演示逻辑冒充计费逻辑。
 - **账目必须对得上**：每一笔点数变动都有流水、可追溯到充值订单或调用记录。
-- **试用额度可控**：新用户注册送 100 点试用点数降低首次接入门槛，但必须按账本发放、可追溯、可防重复。
+- **试用额度可控**：新用户注册送 10 点试用点数降低首次接入门槛，但必须按账本发放、可追溯、可防重复。
 - **小步交付**：每一步都能运行、能验证、能回退。
 - **少即是稳**：MVP 不追求完整，只追求最小闭环可靠；先同步、先单机、先后台手工开通。
 - **可维护**：复用 `cmbot` 现有 AI 调用代码，不另起一套。
@@ -40,7 +40,7 @@
 - 不做自建支付/收银台，付款在外部支付系统完成，本服务发起扫码下单并接收回调，不碰资金清算。
 - 不做异步任务队列（第一版图片生成走同步等待）。
 - 不做面向终端消费者的「内容生成产品页」；用户端只做账户自助（注册/充值/API Key 管理/记录查询）。
-- 不做复杂活动赠点、邀请奖励或历史用户自动补发；当前只做新用户注册一次性 100 点试用额度，且必须配套防刷、幂等和流水留痕。
+- 不做复杂活动赠点、邀请奖励或历史用户自动补发；当前只做新用户注册一次性 10 点试用额度，且必须配套防刷、幂等和流水留痕。
 - 不做多币种、分账、自动退款对账等容易膨胀、不属于 MVP 的能力。
 
 > MVP 的具体功能范围与验收标准，见 [需求](02-requirements.md)。