Moddingflow/better-design

更好的设计

使请求的任务清晰且可操作：用户能够看清当前所处位置，在执行操作前理解其作用，获得结果，并能从错误中恢复。分别评估连贯性、表现力和无障碍性。不要承诺完美的用户体验。

1. 确定范围与视觉基础

• 选择一种模式：创建、针对性改进、审计或规划。审计保持只读状态；不要在规划中实施更改。不要添加用户未要求的功能。
• 从请求和项目中确定平台。仅在缺少上下文时，将响应式网页、语义化HTML和WCAG 2.2 AA作为初始目标。
• 在构建或更改响应式界面之前，定义实际的设备和视口矩阵。对于网站，应包含产品支持的移动端、平板、桌面和超宽屏布局；对于移动游戏，应包含小型和典型手机以及平板。设计约束和布局行为必须适应这些界面，而不仅仅是缩小桌面布局。对于浏览器端工作，在矩阵中应包含浏览器缩放，因为75%、100%和150%这些缩放比例可能会暴露出不同的裁剪、密度、回流和交互问题。
• 在进行任何UI工作之前，查找项目的DESIGN.md（根目录、docs/、design/或代理指令中指定的路径）并完整阅读。它是界面值的单一来源：字体、字阶、颜色角色、间距、圆角、组件尺寸、图标和动效。新代码或修改代码中的每个值都应通过角色或标记名称从此文件中获取；切勿肉眼估计、四舍五入或引入近似重复值。规则请参见 design-md.md。
• 检查当前运行时或已确认的当前捕获中的现有屏幕，然后检查附近的组件、标记、样式和项目规则。缺少DESIGN.md并不意味着没有设计系统：代码标记本身就是系统。保留正在进行中的无关工作。
• 区分实现缺陷和重新设计请求。首先解决根本原因：排序不清、操作不可预测、反馈差、数据丢失或内容丢失。
• 按此顺序做出决策：明确的任务和约束 → DESIGN.md和现有系统 → 平台约定 → 领域任务 → 本技能的可配置基线。功能性和适用的无障碍要求在每个层级都适用。
• 默认视觉方向。 当用户未指定视觉风格且项目没有DESIGN.md、品牌、代码标记或可继承的实时UI时，采用内部风格：苹果精神下的高级极简主义（黑色画布，接近白色的Geologica字体，权重500和340，两种灰色，一种蓝色用于链接和焦点，药丸形操作，通过色调区分表面，真实内容是唯一的色彩）。规则和现成的DESIGN.md预设位于 house-style.md；在编写任何样式前完整阅读。有两种误读会导致代理偏离，因此需明确检查它们（house-style.md第1节）：产品的领域、行业、受众或名称不是视觉线索（例如“咖啡烘焙坊”、“面向开发者”），以及未经修改的脚手架默认值不是可继承的系统（例如shadcn/ui默认主题、Tailwind默认调色板、create-next-app、Vite、Expo启动器、Bootstrap、MUI或Chakra默认值）；应在其上映射内部样式。当适用时，从参考文件 house-style.html 开始，而不是空白页面：获取其标记、类型类、导航、按钮、磁贴和章节节奏（或将其移植到技术栈的组件中），然后替换其内容（house-style.md第1节）。任何来自用户的视觉线索（颜色、情绪、主题、参考、品牌、受众风格）都将覆盖它：遵循请求，仅应用请求未明确且不矛盾的内部样式部分。除非被要求，否则不要将现有产品重新样式化为它。游戏保留其自身的艺术方向。
• 保留既定的品牌、密度、游戏化、编辑性或表现力组成。不要用通用的灰色CRM取代它们。对于真正的冲突，选择最小的可访问调整并解释具体的偏差。
• 仅澄清那些实际改变决策的未知因素；简要陈述合理的假设。此技能不引入新的批准或HTML关卡。项目现有的关于原型、批准和构建的要求仍然适用。

2. 定义任务与适度的合同

• 用通俗语言描述主要场景及其可观察的结果。 遍历：进入 → 操作 → 结果 → 错误/重试 → 返回/取消。
• 区分主要任务、次要操作和帮助。选择用户熟悉的名称和模式；保持导航和操作位置在屏幕间一致。
• 单个修复只需简短记录更改的决策和检查。对于新的流程，在实施之前编写一个紧凑的合同；它是一个工作工具，不是向用户强制提交的文档。
• 使用 design-contract.md 了解结构、 数值默认值和例外。JSON 示例 演示了格式；不要为了小的更改将其整份添加到项目中。
• 合同内容限于平台、目标、现有系统、方向、受影响的组件、 其操作/状态、响应性行为和验收证据。 计划的检查不等于已完成的检查。

3. 在确定样式之前设定艺术方向

否定规则只会将输出导向下一个最常见的模板；特色来自一个过程。当创建或重新设计一个其身份是任务一部分的界面时（品牌、落地页、作品集、消费级应用、游戏、编辑页面、启动器），在选择标记之前，请遵循 art-direction.md。当应用内部样式时（第1节），调色板、字体、形状和动效标记来自其预设；仍需编写概念，并让其选择图像、每个章节的主导元素以及一个标志性细节（house-style.md第10节）。否则：

• 从产品领域、受众和内容中提炼出一个单句概念——来自该世界的一个物体、地点或工艺——而非来自诸如“现代、干净、简约”之类的形容词。 添加三个目标品质和三个具体的反品质。
• 收集3-5个真实参考（用户提供优先；绝不使用AI生成的图像），并记录每个参考中精确采纳的内容：节奏、密度、数字呈现方式、材质、光线。
• 勾画2-3个方向，它们的核心驱动因素不同（排版主导、图像主导、结构主导），然后根据任务和受众的理由选择一个。
• 从概念中推导调色板和字体：具有明确来源和色调中和的调色板；三个字体候选及合理选择。计划一个或两个标志性细节；effects-library.md 中的可选池包含经过测试的细节。
• 从同一概念中推导动效特征：该世界中的事物如何运动（节奏、重量、物理特性、是否有弹性跳动）以及一个标志性动效细节。调色板、字体和动效必须读起来像同一个声音；参见 motion.md。
• 在DESIGN.md内，或继承的艺术方向有现有品牌或设计系统时：从DESIGN.md获取它，或用一句话从实时界面中描述它，并在其内部工作。密集的工作工具通过精确性和数据排版来体现特色；在没有系统且无用户提示的情况下，它们采用内部样式的应用比例和调色板，并配合中性回退版本的密度。
• 将方向记录在合同中（direction，包括 direction.motion），并计划 distinctiveness 和 motion 检查。将所选方向及其标记写入DESIGN.md，以便后续的屏幕和会话基于相同的值构建。

4. 构建连贯的决策系统

• 重用DESIGN.md和代码标记中的标记和组件。对于新系统，定义颜色、排版、间距、圆角、层级和动效的语义角色；然后选择组件变体。
• 保持集合封闭，以便每个屏幕都由相同的部分构建：一个或两个字体族、由少数角色组成的阶梯式字阶、固定的间距规模、少数圆角以及固定的组件大小（例如按钮sm/md/lg）。相同的角色，在每个屏幕上相同的值。缺失的值是系统决策：在同一个更改中将该角色添加到DESIGN.md和代码标记中。
• 当从头开始创建界面时（从house-style预设 当应用内部样式时），或重新设计或多组件更改找不到DESIGN.md时，从模板创建DESIGN.md；从实时代码标记中推导出来，而不是发明值；记录矛盾之处，而不是静默地修复它们。不要为单元素修复创建它，除非被要求；可以在一行中提供。在每次更改中保持DESIGN.md和代码标记同步，只要其中一个被触及。
• API表达意图、大小、密度和状态。保留原生属性、表单参与、链接和可访问名称；不要在提交按钮或带href的链接上要求onClick。
• 不要用每个元素自己的十六进制颜色、间距、阴影和圆角来微调每个元素。当根本原因共享时，更改共享的标记或变体。布局数学、1px边框、0、fr、%、calc、aspect-ratio和允许的项目值本身不是违规。
• 根据角色和容器选择文本大小。
• 构建几何；切勿凭眼睛放置。遵循 layout-geometry.md 处理每个屏幕、面板和游戏菜单，并测量结果（第8节）。在其根本原因处修复对齐错误（枢轴、锚点、缺失的布局组、精灵内边距、字体度量），切勿通过微调单个元素：
  • 等间距。 同类兄弟元素位于一个布局容器内（flex/grid gap，Unity布局组，Godot盒子容器，UMG盒子），使用一个间距标记，因此它们之间的每个间隙都是相同的。不同的间隙必须意味着一个新的组和一个清晰的规模梯级。邻近梯级：控件内部 < 项目之间 < 组之间 ≤ 内边距。
  • 共享线条。 一行中的项目共享其顶部/中心/底部（不同高度共享中心）；一列中的项目以及设置列表中的每个标签从一条垂直对齐线开始，控件位于第二条对齐线上。使用网格或固定的标签列，永远不要使用每行的偏移。按钮集合共享一个尺寸。
  • 小型控件内的内容 根据其可见墨迹（大写字母高度，修剪后的图标像素）居中，而不是根据字体线框或带内边距的精灵矩形；不对称图标需在组件中声明一个光学偏移。图标+标签对使用一个间距标记。
  • 呼吸空间。 没有任何内容溢出或紧贴其容器边缘：内边距至少等于其包含的间隙，并为最长的本地化文本、悬停缩放和焦点环预留空间；交互式UI保持在每个支持宽高比的安全区域内。当内容无法容纳时，更改布局，而非边距。
• 通过一个过程选择排版，而不是黑名单：从概念中筛选出三个字体族（时代、材质、声音、数据密度），然后选择并给出理由。该字体必须在其实际大小和语言下可读，并提供所需的字重、样式、数字、字形覆盖（包括西里尔字母，如果支持）和回退行为。没有字体被禁止，但出于习惯选择的字体是一个缺陷：将一个潮流默认字体（Inter， Uni Sans）替换为下一个（Space Grotesk， DM Sans， Instrument Serif）而没有理由是相同的模板。时尚的字体绝不能使界面更难阅读。
• 通过主导性和对比度构建层级结构：每个屏幕或章节有一个主导元素，一个清晰的阶梯式字阶（在表现力界面上显示是正文的3-5倍，在密集工具中步长较小），在有意识服务于概念的情况下采用不对称布局，以及相邻章节在结构上有所不同，而不是重复一个区块模式。
• 黄金比例可以在改进构图时用于比例、层级结构、裁剪或空白，但它是一个视觉工具，而非强制性公式。在出现冲突时，宁可采用实际任务、内容、响应式约束、可读性和现有系统。
• 不要将一个主屏幕变成一堵不间断的散文墙，如果其内容可以通过操作、分组或视觉锚点来理解。将密集的解释分解为可扫描的章节，并在有用时将它们与有意义的控件、图标、插图、预览、图表或其他与任务相关的图像配对。例如，仪表盘或账户区域应暴露其主要部分和后续操作，而不仅仅是描述用户可以配置哪些内容。不要添加与理解力相竞争或造成虚假可操作感的装饰性视觉元素。
• 使用颜色传达意义和强调；不要仅用颜色传达状态。 将错误/成功/必填/已选信息与文本、图标、形状、图案或其他在灰度模式下和对于色觉缺陷者仍可见的非颜色线索配对。
• 在应用了透明度、叠加层、渐变、图像以及每个必需的主题后，在实际相邻的前景/背景对上验证对比度；不要四舍五入接近阈值的结果。正常文本和有意义的文本图像至少达到4.5:1，只有大文本（至少24 CSS px常规或18.5 CSS px粗体）才可以使用3:1。对于细微、小字或非寻常字体，目标设定更高。
• 确保用于识别活动控件、其焦点或状态以及有意义的图形对象与其相邻颜色之间的视觉信息具有至少3:1的最小对比度比率。只有当边框是使控件可识别的要素时才需要边框；当边框用于此目的时，它必须满足相同的3:1对比度标准。

…

[文本已截断用于翻译]