2026-06-24 UI 需求收口

立项时间：2026-06-24 11:34:07 +08:00

这份文档只收 UI 需求，不做实现，也不改 src/*。目标是把竖版、横版和 App 双壳入口层整理成可分派、可验收的需求口径，供后续实现会话逐项接线。

1. 需求边界

• 竖版 UI 只定义手机端首屏、交互层级和抽屉式收纳方式。
• 横版 UI 只定义桌面端核心视口、控制台密度和信息层次。
• App 双壳只定义编排层与入口层的视觉/结构边界，不定义具体实现细节。
• 所有内容只写需求，不写代码，不写组件名，不写实现顺序。

2. 竖版 UI 需求

2.1 首屏结构

• 竖屏首页必须保留一个主场景核心区，其他内容下沉到 sheet 或 drawer。
• 顶部只保留时间、货币、声望、昼夜等高频状态。
• 底部只保留少量高频主动作，不允许堆成桌面式功能条。
• 首页不允许页面级长滚动，复杂内容必须进入二级层。

2.2 竖版信息层级

• 竖版 UI 的信息优先级应为：状态摘要 > 主动作 > 简短提醒 > 二级详情。
• 江湖简报、事件摘要和预告摘要只能作为轻量内容存在。
• 账号、多周目、Buff、客栈状态、终局、读档都应该通过明确入口进入，不要在首页直接堆全量管理面板。

2.3 竖版交互收纳

• 主动作区只能有一个。
• 复杂功能必须统一进入 sheet / drawer / 独立页。
• 竖屏首屏必须兼容 360x780 作为基线。
• 竖屏内容不能因为长文案或多标签把界面撑出横向滚动。

3. 横版 UI 需求

3.1 核心视口

• 横版桌面必须把大堂 / 核心场景作为第一视觉中心。
• 主视口需要允许聚焦、收起和复位。
• 右侧控制台必须可折叠，且折叠后不影响核心场景理解。
• 横版不允许把所有管理模块都堆成同一列。

3.2 横版信息结构

• 解释性信息默认收纳，必要时通过 tooltip 或折叠层打开。
• 日志、简报、目录、存档、终局等管理内容需要分层。
• 卡片和列表在横屏下应更紧凑，避免继续沿用竖屏堆叠思路。
• 文本、数值、标签要统一层级，不允许靠缩字救版面。

3.3 横版入口层

• 系统门厅、终局、简报、目录、存档等入口必须在横版里形成清晰的管理区。
• 入口层的任务是导流，不是替代功能页。
• 横版的入口层和核心视口之间要有明确视觉分工。

4. App 双壳需求

4.1 编排层边界

• App 只负责入口编排、壳层选择和最少量布局拼接。
• 事件表、规则、文案和详细 UI 不能继续堆在 App 里。
• 双壳切换必须能清楚区分竖版与横版，不允许继续混成一套桌面逻辑。

4.2 双壳视觉原则

• 竖版壳强调单屏经营、轻收纳、少入口。
• 横版壳强调高密度管理、核心视口优先和可折叠控制台。
• 同一功能在两个壳中的表达可以不同，但入口语义必须一致。

4.3 入口层需求

• 入口层必须让玩家能快速看见可去哪里，而不是先学习系统结构。
• 入口层只承载跳转和状态提示，不承载大段解释。
• 入口层如果涉及通知、提醒或风险，应与内容页分开。

5. 今日锁定

5.1 已锁文件

• docs/daily-plans/2026-06-24.md
• docs/app-structure-splitting-plan-v1.md
• docs/remaining-ui-requirements-2026-06-24.md

5.2 今日禁止写入

• src/App.tsx
• src/components/*
• docs/development-roadmap.md
• docs/version-history.md

6. 验收标准

• 竖版需求能单独看懂，不依赖实现代码。
• 横版需求能单独看懂，不依赖实现代码。
• 双壳边界清楚，不把入口层和实现层混写。
• 6.24 日计划里的 PM 派发记录能对应到这份需求文档。

7. 下一步

后续实现会话只要按这份需求补 UI，不要把实现任务写回 PM 文档。若主会话放行 src/App.tsx 或组件层，再按分派结果单独接线。