# 模块设计：先证明必要性，再组织信息

---
rule_id: R-MODULE-DESIGN-01
category: Design
status: active
owner: 主设计会话 / 项目架构负责人
scope: 小程序与后台的模块规划、功能增删、信息架构、导航、页面布局及设计审查
updated: 2026-09-29
---

## 1. 核心原则与触发

**先明确用户需要作出的判断或完成的任务，再决定功能、信息和页面。不得先堆组件、指标和入口，再找内容填进去。**

开始模块设计或重构前必须读取本规则。设计规划、交互原型阶段同样适用，不以已存在REQ为前提。微调文案或样式只检查受影响的原则，不要求每次重做整个模块。

本规则由用户在2026-09-29确认并要求持久化，源于后台概览与导航迭代。它是设计约束，不新增Runtime阶段、审批门禁或需求锁定；不发布Foundation，也不改变架构中的业务事实、权限或资金政策。

## 2. 先判断功能是否必要

设计者应先回答，而不是把问题原样抛给用户：

1. **谁在什么情况下打开它？** 区分日常检查、任务执行、异常处置和偶尔维护，不能只写“运营人员使用”。
2. **他最想知道或完成什么？** 用一句话确定主任务；包含多个无关目标时，重新划分模块或页面职责。
3. **看完信息可以作出什么决定？** 每项数据回答“所以呢”：是否影响选择、调度、办理、核验或恢复？
4. **没有这项功能，实际工作在哪里受阻？** 指出无法判断、遗漏、重复录入、跨页拼查或无法续办等后果；说不清则标为待验证，不按后台惯例默认加入。
5. **完成任务需要的信息与动作是否齐全？** 包括来源、正常结果以及缺资料、无权限、失败、未知和处理中时的下一步；不能只画成功路径。

产出应是有理由的功能范围，不是菜单清单。必要但缺来源或契约的能力应明确待补，不以删掉它获得“简洁”；未经验证的候选也不应伪装成已批准业务。

## 3. 再决定意群与导航

| 判断问题 | 设计选择 |
| --- | --- |
| 哪些信息必须同时看，才能完成一个判断？ | 合成一个意群，避免跨页记忆与比较；组合展示不改变事实Owner |
| 是否必须先掌握全局，才能决定下一步？ | 才设置概览；否则侧栏直接进入记录、内容或任务操作 |
| 是同一问题、同一任务的不同观察面吗？ | 使用顶部Tab，名称说明视角；不能仅因同一技术模块就塞进一排Tab |
| 是不同目标、不同办理过程吗？ | 拆为独立任务，放侧栏；折叠导航组不必另造一个目录页 |
| 点击具体页面后，是否只是看到另一堆入口？ | 取消没有增加事实或判断价值的中间层；真正的对象目录不等于功能入口墙 |
| 进入具体记录后，是否还需要跳其他列表？ | 优先保持当前对象上下文；关联对象明确身份与去向，返回保留筛选和定位 |
| 哪些内容是说明、依据或历史？ | 次一级呈现或按需展开；阻断、风险与未知结果不能因此隐藏 |

不能为了减少菜单，把所有内容塞成长页面；也不能为了减少点击，混合身份、权限或不同业务的执行结果。导航深度应由任务需要解释，不以固定层数或页面数作为成绩。

## 4. 页面重点必须有信息价值

**被强调的内容必须值得用户看一眼，且看完能获得结论或下一步依据。**

- 位置、面积、明暗和字号共同分配注意力，不是每个模块都配置同样的大数字、深色摘要和图表。
- 概览支持组合判断；处理页支持定位与办理；维护页支持准确编辑。允许三者有不同密度和结构。
- 数字需有对象、单位、日期、范围、状态及必要构成；明确人数与单数、计划与实际、确认与交付。不是每项都常驻展开，但不能靠猜。
- 区分无记录、来源缺失、结果未知与零值。合成场景明确标识，统计来自可核对记录，不维护独立装饰计数。
- 标题负责定位，优先简短业务名称，如“猪肉到货”“配送时段”。事实负责回答，不用问句、口号或旁白重复解释明显内容。
- 信息密度是可理解、可用于决策的信息量，不是文字、边框、卡片或按钮数量。删描述不能删必要口径、异常解释和恢复路径。
- 图表必须让重要关系比列表或短句更容易理解；否则用更直接的表达，不为“像Dashboard”而画图。

反例：“8项异常”占据视觉中心却不解释类型、对象和影响，吸引了注意却没有提供判断依据。改进应展示异常构成与业务影响，或将该数字降为辅助信息，而不只是换颜色和字号。

## 5. 模块设计卡

在模块现有设计文档中记录，避免新建重复事实源。完整模块梳理先写八项，再展开页面；局部调整引用已有卡并补受影响项。

| 项目 | 必须说清 |
| --- | --- |
| 使用者与触发场景 | 谁、何时、为什么进入 |
| 唯一主任务 | 这一页主要负责什么，不负责什么 |
| 需要作出的判断 | 看完后可以决定或完成什么 |
| 必要信息及来源 | 每项如何支持判断，来源与缺失如何表达 |
| 必要动作与异常出口 | 正常、拒绝、失败、未知及未完成如何继续 |
| 应同时呈现的意群 | 哪些内容一起看才完整，主次如何分配 |
| 侧栏、Tab与详情边界 | 为什么合并或拆分，为什么需要或不需要概览 |
| 删去与保留的理由 | 删除了什么冗余，保留了什么必要能力及待验证项 |

卡片是推导依据，不是凑齐字段的表格。无法回答的地方保留缺口；业务价值或权限存在不可推导的分歧时，提出有取舍的建议请用户判断。

## 6. 自审与体验验证

完成设计后反问：

1. 用户不读设计说明，能否知道本页的主任务？
2. 目光首先落下的位置，是否给了足够信息，而不只是一个醒目的数字？
3. 用户能否看清“现在什么情况、需要做什么、做完会怎样”？
4. 合并或精简是否反而增加跨页拼查、隐藏风险、删除必要功能？
5. 同一对象在概览、列表、详情和客户下钻中的数据是否一致？日期、范围、去重与未知口径是否一致？
6. 在实际视口、真实渲染和有代表性的空态、异常、长内容下，层次是否仍成立？不能仅凭代码或小样本截图宣布全模块完成。

评审时先说明希望验证的体验，再让用户给第一眼感受。反馈用来检验任务与注意力假设，不机械转为局部样式指令；设计者负责整体取舍。

最终标准：**留下的每一项，都能解释为什么在这里；被强调的每一处，都能兑现用户投入的注意力。**

## 7. 关联与维护

- [规则索引](README.md)：设计相关工作触发必读。
- [设计执行卡](../design/DESIGN.md)：本规则的常读入口；品牌与Surface约束仍各归其主讲。
- [后台信息架构](../design/prototypes/admin-console/INFORMATION-ARCHITECTURE.md)、[经营概览推导](../design/prototypes/admin-console/DAILY-OVERVIEW.md)：实践案例，不将某一版布局升为所有模块的固定模板。

规则正文只在本文件维护；AGENTS与设计入口只链接，不复制另一份会逐渐分歧的检查表。