CardHelper 前期产品规划简报

0. 当前协作边界

后续规划只覆盖：

• 产品定位、目标用户与使用场景；
• 用户价值、功能范围与版本取舍；
• 核心流程、信息架构和五键交互体验；
• RLCD 与六色屏对应的 UI、视觉与内容表达；
• 产品外观、使用姿态、整体气质和设计稿；
• 原型验证、用户测试和产品阶段演进。

暂停展开：

• 电路、PCB、器件参数和引脚设计；
• 固件架构、代码、脚手架和测试实现；
• API、Schema、文件格式和命令行工具；
• 图像转换算法参数与批处理实现；
• 量产、认证和供应链执行细节。
• 定价、购买单位、商业模式、销售渠道和市场规模；
• 内容交易、商业合作、运营增长和盈利方式。

既有工程文档仅作为产品设计的可行性背景，不在当前阶段继续深化，也不因产品概念稿自动变更其中的技术决策。

1. 产品方向

CardHelper 是一张面向线下卡牌对局的全尺寸电子武将牌。它承载武将展示、选将以及体力和通用状态管理，同时保留实体手牌和线下面杀的仪式感。

当前不把它定义成通用掌机、线上游戏客户端或完整桌游平台。第一阶段先围绕三国杀武将牌这一件事做出明确、自然、愿意持续使用的体验。

2. 用户价值排序

建议按以下顺序理解产品价值：

1. 少带、好找：减少携带和整理大量武将牌的负担，快速找到要使用的武将。
2. 少错、好操作：体力、护盾和常见状态清楚，不容易被碰乱或忘记。
3. 像一张真正的牌：尺寸、摆放和视觉表达融入桌面，而不是像在对局中使用手机。
4. 有收藏和展示欲望：最终六色版本应具备长期静态展示和个性化卡面的吸引力。

无线、账号、社交、平台和多游戏扩展都不能先于这四项价值。

3. 核心使用体验

一次完整体验应保持简单：

拿起或唤醒设备
      ↓
快速找到并选择武将
      ↓
确认身份或模式
      ↓
进入卡面并开始对局
      ↓
用五键管理体力与少量状态
      ↓
休眠后可继续，结束后返回选将

前期所有功能判断都应回到一个问题：它是否让这条主流程更快、更清楚或更有卡牌感。如果不能，就不进入当前核心范围。

3.1 设备在一场对局中的角色

当前建议采用以下产品基线，尚未作为正式决策冻结：

• 一台设备对应一名玩家的一张武将牌，承担该玩家的武将展示、体力、护盾和少量公开状态。
• 设备必须能够单台独立使用，不要求同桌其他玩家也使用 CardHelper。
• 允许与实体武将牌混用，使用设备的玩家不应因此获得额外信息或改变其他玩家的操作方式。
• 多台同时使用时仍各自独立，前期不依赖组网、房间、同步或主从设备才能开始游戏。
• 实体手牌始终保留，设备不查看、不录入也不推断任何隐藏手牌信息。
• 屏幕只呈现公开信息，避免把对局辅助器演变成自动裁判或额外游戏客户端。

对应的牌桌关系为：

每位玩家
├─ 实体手牌：隐藏信息，保持原有玩法
└─ 武将区域
   ├─ CardHelper：武将展示与公开状态
   └─ 或实体武将牌：可与设备自然混用

这套基线让单台设备本身就能完成核心任务，也避免多设备连接成为开始对局的前置步骤。后续产品设计需要验证的不是联网方式，而是单台设备放在玩家面前时是否自然、清楚且不打断牌桌节奏。

3.2 核心体验主轴

当前建议采用 “卡面主导、状态常显、操作时展开” 的体验主轴，尚未作为正式决策冻结。

产品首先要让人感到它是一张武将牌，而不是一块计数器；但体力等公开状态也不能为了画面沉浸而被隐藏。界面因此分为三种体验层次：

1. 卡面层：人物、名称、势力和卡牌气质占据主要视觉面积，构成默认观看状态。
2. 常显状态层：体力与锁定状态始终可辨；护盾和 Token 在存在时明确出现，不要求用户按键查询。
3. 操作反馈层：发生增减或进入状态调整时，临时放大当前数值、变化方向和撤销提示，操作完成后回到克制的常显状态。

这不是在全卡面模式和固定状态区之间简单折中，而是规定两者的主次关系：

• 卡面负责身份、氛围和长期观看；
• 常显状态负责牌桌上的公开信息；
• 展开反馈负责短时间操作和防错；
• 设置、选将和确认页面可以更像工具，但进入对局后必须迅速回到“武将牌”状态。

后续视觉稿只需比较常显状态层如何融入卡面，不再同时发展“纯全屏隐藏状态”和“大面积固定控制面板”两套相反产品方向。需要验证的是：正常观看距离下状态是否清楚，以及操作展开是否会明显破坏卡面沉浸感。

4. RLCD 与六色版本的关系

RLCD 前期版本

• 用来验证全尺寸形态、五键交互、选将流程、对局状态和长时间使用体验。
• 重点是“能不能顺畅完成一场真实对局”，不是证明最终产品的彩色视觉品质。
• 黑白表达可以形成自己的清晰风格，不必伪装成六色屏效果。

六色最终方向

• 用来完成更接近实体收藏卡的视觉表现和产品化形态。
• 在保留同一核心流程的基础上，重新设计色彩、卡面层次和刷新反馈。
• 只有真实屏幕能力、成本和供货满足产品要求后，才能成为正式产品基线。

两者不是互相替代的两套产品逻辑，而是同一产品体验的两个验证阶段。共享核心体验，不强求共享所有画面。

5. 当前最重要的产品假设

这些假设的重要性高于当前功能数量和技术完整度。

6. 前期规划的四条主线

A. 产品需求

明确最典型的使用者、使用频率、现有替代方式和核心操作。先验证体验，再讨论扩展功能。

B. 核心体验

围绕选将、进入对局、状态操作、休眠恢复和结束游戏建立可理解的流程，并观察真实牌桌中的误触、等待和打断。

C. 产品形态

确认全尺寸设备的摆放、握持、按键触达和桌面观感。现阶段只确定方向，不冻结精确外壳细节。

D. 双屏路线

RLCD 支撑前期验证，六色屏同步做候选调查和视觉探索。两条线在产品体验层汇合，不要求研发节奏完全同步。

7. 当前范围边界

现在需要考虑

• 谁在什么场景操作设备，以及设备与实体手牌、武将牌和其他玩家的关系。
• 一场对局中的核心流程和高频操作。
• RLCD 原型要验证什么，六色最终版要提升什么。
• 全尺寸形态、五键和显示技术的主要风险。
• 原创视觉方向和产品整体气质。

现在暂不深入

• 完整软件脚手架、接口、Schema 和工具命令。
• 像素级 UI、最终色值和所有异常页面。
• PCB 引脚、器件型号和外壳精确尺寸。
• 批量武将生产、资源市场和内容平台。
• 账号、社交、多设备组局以及复杂无线功能。
• 定价、销售、商业模式、市场规模和完整商业发布方案。

8. 近期规划产出

前期只需要形成五类高层产出：

1. 一页产品定位与用户价值说明。
2. 一条核心使用流程和少量关键场景。
3. RLCD 前期版与六色最终版的阶段关系。
4. 产品外观、六色 UI 和武将卡面的视觉方向稿。
5. 需要用用户、样屏或原型验证的关键假设清单。

这些内容清楚后，就应进入小规模验证；不通过继续增加规划细节来替代证据。

9. 当前建议

• 保持“专用电子武将牌”的聚焦定位。
• 以真实线下面杀体验作为产品成败标准，而不是功能清单长度。
• 用 RLCD 尽早验证核心流程，同时持续研究六色屏，但不让六色屏阻塞前期体验验证。
• 视觉探索先服务于产品气质和用户判断，不直接当作工程稿。
• 下一轮规划优先讨论设备在一场对局中的角色、关键使用场景和核心体验，其次才是功能扩展。