| name | frontend-logic-design |
| description | Use when 1flowbase frontend/UI structure feels illogical, unintuitive, inconsistent, hard to navigate, or has unclear information hierarchy, entry points, drill-down paths, or same-object behavior. |
前端逻辑化设计（Frontend Logic Design）
Overview
当前端界面让用户感到"不对劲"时，问题往往不在视觉层，而在信息架构层——信息的分类、层级、下钻路径和交互行为不符合用户的心智模型。
本 Skill 提供一套系统性的诊断和修正流程，基于三大核心理论：
- MECE 原则（互斥且穷尽）— 保证信息分类不重不漏
- 渐进式披露（Progressive Disclosure）— 保证信息按深度递进展示
- 施耐德曼法则（Shneiderman's Mantra）— 概览优先，缩放筛选，按需详情
触发场景
当用户提出以下类型的问题时，必须使用本 Skill：
- "这个页面感觉没有逻辑"
- "为什么有的能点有的不能点"
- "交互不一致"
- "不知道该去哪里找信息"
- "这个功能放在这里合理吗"
- "信息层级混乱"
- "导航结构不清晰"
- "用户会困惑"
- 任何涉及信息架构、导航设计、页面层级的设计讨论
The Iron Law
不要在 UI 容器维度做 MECE，要在信息深度维度做 MECE。
容器（侧栏/页面/弹窗/对话）是实现手段，不是分类维度。
诊断流程
Phase 1：识别问题类型
首先判断问题属于哪一类（可多选）：
| 问题类型 | 症状 | 根因 |
|---|
| 分类不互斥 | 同一信息出现在多个地方，用户不知道去哪找 | 分类维度选错，存在交叉 |
| 分类不穷尽 | 有些信息/操作无处安放，被遗漏 | 分类不完整，存在盲区 |
| 深度不一致 | 有的能点有的不能点，交互行为不统一 | 缺少统一的下钻规则 |
| 层级错位 | 复杂操作放在概览层，简单信息放在深层 | 信息深度分配不合理 |
| 入口缺失 | 用户知道信息存在但找不到入口 | 渐进式披露的"暗示"不足 |
Phase 2：信息深度审计
用四层信息深度模型审计当前页面的每一个元素：
L0 概览（Overview）
用户问题："什么情况？"
容器：卡片 / 列表摘要 / 统计数字
规则：直接可见，无需交互
允许的操作：一键确定性操作（审批、标记已读等）
L1 聚焦（Focus）
用户问题："这条具体是什么？"
容器：侧栏抽屉（Drawer）/ 展开面板
规则：点击任意条目触发
关键：同一页面内，所有可点击条目的行为必须一致
L2 管理（Manage）
用户问题："让我找/改某个东西"
容器：独立页面（Full Page）
规则：通过"查看全部"入口进入
特征：全量数据 + 搜索 + 筛选 + 批量操作 + CRUD
L3 执行（Execute）
用户问题："帮我做这件事"
容器：对话页面 / 向导流程 / 专用操作页
规则：通过明确的行动按钮触发
特征：需要多步骤或AI介入的复杂操作
审计方法：列出页面上的每一个交互元素，标注它属于哪个深度层。如果发现：
- 同层元素行为不一致 → 深度不一致问题
- 某层完全缺失 → 入口缺失问题
- 元素放错层 → 层级错位问题
Phase 3：MECE 检查
对页面的信息分类进行 MECE 检验：
互斥性检查（ME）
对于页面上的每一个数据项：
它只属于一个分类/一个卡片/一个Tab吗？
如果同一数据出现在多处：
- 是否因为呈现角度不同？（允许：D01待办 和 D10今日 可以有重叠）
- 还是因为分类维度混乱？（不允许：同一操作在两个地方都能做）
穷尽性检查（CE）
列出用户对该模块的所有可能意图：
- 能否在当前设计中找到每个意图的入口？
- 是否存在"用户想做某事但不知道去哪"的情况？
- 是否存在只能通过URL直接访问的"孤岛页面"？
Phase 4：一致性矩阵
构建交互一致性矩阵，确保同类元素行为统一：
| 组件/卡片 | 条目可点击?(L1) | 查看全部?(L2) | AI执行?(L3) | L0内操作 |
|----------|---------------|-------------|------------|---------|
| 卡片A | ? | ? | ? | ? |
| 卡片B | ? | ? | ? | ? |
| ... | | | | |
规则：
- 所有列表型组件的"条目可点击"列必须全部为 ✅（或全部为 ❌）
- 同列的交互触发方式必须一致（比如都是弹出侧栏，不能有的弹侧栏有的跳页面）
Phase 5：生成修正方案
基于诊断结果，生成修正方案。方案必须遵循：
- 统一下钻规则：定义清晰的 L0→L1→L2→L3 路径，所有同类组件遵循
- 入口暗示原则：每个被隐藏的深层功能，在上层必须有可见的入口暗示其存在
- 容器选择决策树：
需要保持当前上下文？
├─ 是 → 用户需要对比/参考背景数据？
│ ├─ 是 → Drawer（侧栏抽屉）
│ └─ 否 → Modal（弹窗）— 仅用于简单确认
└─ 否 → 操作复杂度？
├─ 高（多步骤/全量数据/批量操作）→ Page（独立页面）
└─ 低（单步操作）→ 就地完成（inline）
输出格式
诊断完成后，输出以下结构化报告：
## 信息架构诊断报告
### 问题清单
| # | 问题类型 | 位置 | 描述 | 严重度 |
|---|---------|------|------|--------|
### 一致性矩阵（当前状态）
| 组件 | L0 | L1 | L2 | L3 |
### 修正方案
| # | 改动 | 深度层 | 涉及文件 | 说明 |
### 一致性矩阵（修正后）
| 组件 | L0 | L1 | L2 | L3 |
理论参考
详见 references/ 目录下的理论文档：
mece-in-frontend.md — MECE 原则在前端设计中的应用progressive-disclosure.md — 渐进式披露的设计模式和反模式container-decision-tree.md — Modal vs Drawer vs Page 决策树
示例提示词
用户可能这样描述问题，你应该立即启动诊断流程：
"我们看板上有的卡片能点进去看详情，有的不能，感觉逻辑不一致"
→ 诊断方向：深度不一致（Phase 1 → Phase 4 一致性矩阵）
"这个功能放在看板上有意义吗？用户根本不会在这里添加任务"
→ 诊断方向：层级错位（Phase 2 信息深度审计）
"用户说找不到某个功能，但那个页面明明存在"
→ 诊断方向：入口缺失（Phase 3 穷尽性检查）
"我们有侧栏、有独立页面、有弹窗，感觉分类很乱"
→ 诊断方向：在容器维度做了 MECE（Iron Law 违反）
"帮我审查这个新模块的信息架构是否合理"
→ 完整走一遍 Phase 1-5
Anti-Patterns
1. 在容器维度做 MECE
❌ 错误：侧栏放详情、页面放管理、对话放执行 → "三者互斥"
✅ 正确：L0概览 → L1聚焦 → L2管理 → L3执行 → 信息深度互斥，容器只是实现手段
2. 每个组件自己决定交互行为
❌ 错误：卡片A点击弹侧栏，卡片B点击跳页面，卡片C不可点击
✅ 正确：所有列表型卡片的条目点击行为一致（统一弹侧栏或统一跳页面）
3. 概览层塞入重操作
❌ 错误：在看板卡片里放"快速添加任务"输入框
✅ 正确：概览层只展示信息 + 一键确定性操作，创建操作放到 L2 或 L3
4. 隐藏功能无入口暗示
❌ 错误：存在 /tasks 页面但看板上没有任何链接指向它
✅ 正确：每个列表型卡片底部有"查看全部 →"链接
5. 深层信息越级展示
❌ 错误：在概览卡片里展示任务的完整描述、所有评论、历史记录
✅ 正确：概览只展示标题+状态+一句话摘要，详情在 L1 侧栏中展示
