把软件做得好用：UI/UX 的设计与实现
导读：一次没有解释清楚的文件复制
假设你把一批照片复制到移动硬盘。一部分已经复制成功，另一部分因为文件占用或存储空间不足而失败。进度窗口消失后，软件只留下“操作失败”四个字。你不知道哪些照片已经复制，也不知道重新执行会覆盖文件、生成副本，还是只处理剩余项目。
底层程序可能准确地报告了每一次读写的结果，但界面没有把这些结果组织成你能理解的信息。于是，确认文件、比较目录和判断是否重试的工作，需要由你继续完成。这个例子是一个假设场景，却能把“功能已经实现”和“用户能够完成任务”之间的差别说明白。
讨论软件质量时，UI/UX 容易被缩减为圆角、配色、图标和动画。谈到自由软件，又会出现另一层顾虑：维护者已经投入了无偿劳动，继续要求视觉打磨和交互改进，是否忽视了项目的资源限制？我认为这两件事需要同时考虑。设计有成本，项目可以限定自己承担的工作；用户能否理解和使用软件，也确实是质量问题。
本文从用户任务出发，讨论界面设计中的具体问题：哪些问题可以从任务表现中观察，哪些属于偏好，哪些工作能交给平台复用，又有哪些决定必须由应用自己作出？最后再看 AI 生成界面之后，开发者还需要学习和验证什么。
1 从用户任务理解软件质量
1.1 UI、UX 与可用性
用户界面（User Interface，UI）是人与系统交互的界面，包括控件、文字、布局、输入方式和操作反馈。用户体验（User Experience，UX）的范围更广。Norman 与 Nielsen 对它的说明包括用户与公司、服务和产品交互的各个方面，并明确区分整体体验与界面本身。[1] 对桌面软件而言，安装、首次配置、日常操作、更新和获取帮助，都可能影响用户怎样理解和评价这个产品。
可用性（usability）则让评价有了更具体的条件。ISO 9241-11 的定义关注特定用户在特定使用情境中，能否有效、有效率并满意地完成特定目标。[2] 因而，“这个软件好不好用”还需要补充：谁在使用，要做什么，用什么设备，具有什么经验？
一个熟悉命令行的管理员，可能很愿意用脚本批量整理文件；一个偶尔备份照片的人，可能需要看见来源与目标，逐项确认结果。两种界面都可以设计得好，也都可能令人困惑。图形界面不会自动获得良好体验，命令行也有命名、反馈、默认行为和错误恢复的问题。
本文主要讨论桌面图形应用，并从文件管理器展开。它包含几类彼此相关、但不能互相替代的判断：
| 评价对象 | 具体问题 | 适合查看的依据 |
|---|---|---|
| 功能支持 | 能否访问目标设备并完成文件操作 | 支持范围与执行结果 |
| 信息架构 | 文件位置、操作和设置按什么关系组织 | 导航结构与查找过程 |
| 交互行为 | 选择、复制、取消和恢复怎样发生 | 操作过程与状态变化 |
| 视觉表达 | 信息能否辨认，层级是否清楚，外观是否令人喜欢 | 排版、对比度、视觉观察与偏好反馈 |
| 任务表现 | 用户是否完成目标，需要多少帮助 | 任务观察、时间与错误记录 |
这些维度可以出现不同结果。一个界面可能很好看，但复制失败后无法恢复；另一个支持熟练用户所需的全部命令，却让新用户很难找到入口。只保留“好”或“差”一个总评，就会失去真正需要改进的对象。
1.2 交互要求会改变实现
“支持复制文件”看似是一条明确需求，但它省略了不少完成条件。用户提交了哪些对象？目标位置是否正确？遇到同名文件时怎么办？哪些项目成功，哪些失败？关闭窗口以后，操作是否继续？这些决定会影响任务调度、结果记录、错误处理和界面结构。
ISO/IEC 25010:2023 的产品质量模型将交互能力（interaction capability）列为质量特性，下面包含易学性、易操作性和用户差错防护等方面。它同时区分产品支持交互的属性与具体情境中的使用结果。[3] 这一区分很实用：软件可以提供清楚的命令、反馈和恢复机制，实际用户是否因此更容易完成任务，仍要放到使用过程中判断。
因此，设计工作应当进入需求和实现过程。若到功能完成后才发现用户需要取消任务，开发者可能必须修改原来的同步调用、增加取消状态，并明确已经写入的数据如何处理。给窗口补一个“取消”按钮，只完成了其中很小一部分。ISO 9241-210 也把以人为中心的设计原则与活动放在交互系统的整个生命周期中。[4]
这不意味着每个程序员都要独自掌握所有设计工作。用户研究、信息架构、视觉设计和软件实现需要不同经验，团队可以分别承担。它们需要共同确定交付条件，否则设计稿中的行为与代码提供的能力就可能对不上。
1.3 资源有限时，怎样讨论不足
“维护者没有时间修改”和“这个问题不影响用户”是不同判断。前者说明资源约束，后者需要检查使用后果。用户提供一份可复现的交互问题，也不自动意味着维护者有义务立即修复。
我更愿意按后果和任务安排优先级。一个删除操作可能误伤数据，一个对话框使键盘用户无法继续，一个低频页面的间距不一致，它们需要的处理通常不同。不过，问题的外观不一定能说明严重程度：一处看起来很小的低对比度文字，也可能让某些用户读不到必要信息。排序时要具体说明受影响的人、任务和条件，再结合修复与维护成本。
小项目可以缩小功能范围，复用平台控件，公开尚未支持的使用条件，或者暂缓某项改进。这些都是可以讨论的工程选择。用户同样可以因为当前体验不满足自己的需求而选择其他软件。对劳动的尊重，与对产品表现的准确描述，可以同时成立。
设计工作还需要明确的职责与决策权限。谁来长期承担设计、测试和用户沟通，设计人员是否有与职责相应的授权，涉及项目的组织方式，参见《Snap、Flatpak 与 Nix》第 5.1 节对持续投入与设计分工的讨论。
把约束说清楚以后，设计讨论才有具体对象。接下来要回答的是：同样一组功能，怎样安排才能让用户理解自己能做什么、已经做了什么，以及下一步该怎么做？
2 用户怎样理解界面
2.1 操作能力与操作线索
一个文件条目可以接受拖拽，并不表示用户知道它能拖动；一个图标有点击事件，也不表示用户能猜出点击后发生什么。Norman 用 affordance 描述行动者与环境之间可能发生的动作关系，用 signifier 描述人能够感知、解释的线索。[5] 在界面设计中，需要同时考虑软件支持哪些动作，以及怎样让用户发现和理解这些动作。
文字标签、形状、位置和状态变化都能提供线索。例如，选中文件后显示相关命令，可以说明命令作用于哪些对象；按钮旁边的文字可以说明操作含义；提交任务后的反馈则告诉用户输入已经被接收。这些信息共同帮助用户形成对系统行为的预期。
Nielsen 的启发式原则包含系统状态可见、识别而非回忆、用户控制和错误恢复。[6] 它们适合转成具体检查：用户是否知道当前选择？能否看见可用命令？必须记住哪些信息？操作结果有没有解释？出错后还能不能继续？
菜单和快捷键在这里承担不同工作。菜单帮助用户发现命令，快捷键让熟悉命令的人直接执行。只提供快捷键，会要求用户事先知道它；只提供多层菜单，又可能使高频操作变得繁琐。设计通常需要把可发现的入口与熟练操作的途径结合起来。
2.2 用户需要理解操作范围
除了知道命令在哪里，用户还要知道它会处理什么。同样是输入一个文件名，软件可能只过滤当前目录已经显示的条目，也可能在更大范围内执行搜索。结果为空时，用户会据此判断文件不存在、位置不对，或者搜索还没有完成。界面如果没有交代范围，就很容易让正确结果被理解错。
Files 在 2025 年 9 月发布的 v4.0 中，明确将过滤与搜索分开：过滤针对当前目录显示的项目，搜索使用 Windows Search 索引，并为两者提供不同入口。发布说明将减少混淆列为这项调整的目的。[7] 这项调整把两种处理范围分别呈现出来，使入口与用户需要理解的操作含义对应。
同样的问题也出现在复制冲突中。“跳过”是跳过当前文件还是所有冲突？“替换”会覆盖哪个位置的对象？“应用到全部”包括后续遇到的不同类型问题吗？用户不应该先理解内部异常分类，才能推断这些按钮的作用。
清楚的文案需要底层提供足够的信息。应用若只收到一个笼统的失败标记，就难以说明哪些对象受影响。交互设计由此反过来要求操作接口保留对象、原因与处理结果。
2.3 简单与强大如何共存
渐进式披露（progressive disclosure）把主要信息放在当前界面，将次要或专业细节放到可以继续展开的入口。[8] 它适合处理功能较多的应用，但前提是主要与次要的区分符合实际任务，用户也知道到哪里寻找更多内容。
例如，文件列表默认可以突出名称、修改时间和大小，权限细节放入属性页面。对经常管理访问权限的人，这种安排可能仍然不够方便，应用可以提供更直接的入口或允许调整列。决定显示什么，需要考虑目标用户的工作频率和上下文，而不能只看页面是否显得清爽。
KDE HIG 对此给出了很具体的约束。它要求主要工作流默认可见，把快捷键和上下文菜单视为加速途径；同时反对用可配置性逃避设计决定，也不推荐把各类设置藏进含义不明的“Advanced”页面。额外细节应与具体对象保持联系。[9]
因此，功能数量不能单独说明复杂程度。一个功能丰富的界面，如果分组清楚、入口稳定，熟练用户可能很容易使用；一个按钮很少的界面，如果把必要操作藏得过深，用户反而需要记忆更多路径。设计要减少的是完成任务时不必要的理解和操作负担。
2.4 视觉设计表达关系，也影响感受
视觉层级决定用户先看到什么，以及怎样理解元素之间的关系。文件名与修改时间使用不同字重，可以提示主要内容与辅助信息；同组操作保持接近，不同组之间增加间距，可以表达分组；警告文字、图标与颜色共同出现，可以使操作后果更容易辨认。Fluent 2 的布局指导就把间距用于表达关系和层级，并将这些选择组织成可复用的变量。[10]
这些做法有适用条件。元数据使用次要样式，不等于把它淡化到难以阅读；增加留白可以帮助分组，也会减少同屏内容；动画可以解释位置和状态变化，但若每次操作都必须等待动画结束，就会增加时间成本。要判断取舍，需要回到信息内容、输入方式和任务频率。
视觉设计的价值也包括人对产品的感受。有人喜欢克制的布局，有人更愿意使用颜色鲜明、表达丰富的界面。只要偏好被如实表述，就不必先证明它能减少几次点击才值得讨论。与此同时，某个人不喜欢一种视觉语言，也不足以说明使用这种语言的应用整体难用。
审美与可用性效应进一步说明了两者怎样关联。NN/g 的资料描述了用户可能将有吸引力的界面评价得更易用，并对轻微问题更宽容；它的测试观察也显示，视觉好评可能掩盖实际操作中的困难。[11] 因而，视觉喜好、主观易用评价和任务表现需要分别记录。
视觉改变也可能影响实际行为。Google 介绍 Material 3 Expressive 的研究时，报告参与者在部分实验中发现关键控件的速度最多达到原设计的四倍。邮件示例同时改变了发送按钮的大小、位置与颜色；同一篇材料也报告，打乱熟悉的播放列表结构或移除操作文字会损害可用性。[12] 这些结果支持在具体任务中研究视觉强调，不能据此把整个设计体系的效率概括为“四倍”。
原则解释了设计决定的理由。要让这些决定在多个页面、主题和状态中保持一致，还需要把它们组织成可以复用和维护的规则。
3 设计系统与平台控件
3.1 从主题到设计系统
主题通常调整已有界面的颜色、字体、图标或其他外观资源。设计系统还会说明组件适合什么场景、操作如何组织、状态怎样表达，以及哪些规则可以由应用调整。人机界面指南（HIG）、设计系统和 UI 工具包的范围有重叠，但各自提供的信息不同。
以一个危险操作按钮为例，设计指导需要解释它应放在哪里、如何命名、何时确认；设计变量规定相关的颜色、间距与字重；控件实现处理输入和呈现；应用代码则负责执行操作、解释失败并提供恢复。它们需要配合，换一套主题只能改变其中部分内容。
设计变量也不只是一些数字。把颜色命名为“错误文本”“次要文字”或“选中背景”，可以表达使用意图，并让它们在不同主题下取得合适的值。若各个页面直接写死颜色，应用以后适配深色或对比主题时，就需要重新检查大量局部选择。
例如，WinUI 3 的文件列表可以通过 {ThemeResource ...} 引用文字、背景和选中状态所需的画刷，让引用随主题切换重新求值。自定义画刷需要为 Light、Dark 和 HighContrast 提供合适的值；在对比主题中，选中背景与选中文字也要配套使用系统颜色。这样，调整配色仍然保留了“当前位置”“当前选择”等信息含义。[13]
3.2 不同平台怎样组织设计工作
GNOME HIG 鼓励聚焦应用的目标，减少用户需要记忆的信息、操作步骤和不必要的打断，也明确使用渐进式披露。[14] KDE HIG 强调默认体验与有需要时的专业能力，同时限制无目的的配置选项。两者在减少理解负担、保持主要工作流可见方面有共同点，不能简单分成“一个追求简单、一个追求功能”。
Fluent 2 提供布局、视觉变量等跨平台设计指导；开发 Windows 应用时，还需要查 Windows 的控件与 API 文档。设计体系中的概念与某个框架里的具体实现不一定一一对应。读懂间距规范，不等于已经掌握 NavigationView 的行为；知道控件属性，也不等于已经确定应用的导航结构。
对开发者而言，选择一个主要平台体系，可以减少需要重新决定的细节。借鉴其他体系时，则可以比较同一个问题：设置如何分组，窗口变窄后哪些内容改变位置，危险操作如何确认。这样能理解选择背后的条件，而不只是收集看起来喜欢的组件。
平台规范描述的是推荐做法，实际应用是否做到仍要检查。界面采用了某套颜色与材质，也不表示它已经遵循了这套体系的交互要求。
3.3 标准控件保存了哪些实现经验
Microsoft 的无障碍文档说明，XAML 标准控件提供键盘和辅助技术的基础支持，通过 UI Automation 暴露相关信息。[15] 使用标准按钮时，开发者可以复用已有的输入行为；如果从绘图和指针事件开始自行实现，就需要逐项补上这些能力。
| 行为 | 应用需要检查什么 |
|---|---|
| 输入 | 鼠标、键盘与所支持的触摸操作能否正确触发 |
| 焦点 | 用户能否找到当前位置，进入和离开控件 |
| 语义 | 辅助技术是否知道控件的名称、角色与状态 |
| 外观 | 主题、缩放、禁用与选中状态是否仍然清楚 |
| 任务 | 触发后执行什么，怎样反馈结果与处理失败 |
前几项可以从成熟控件中得到很多帮助，最后一项仍依赖应用的需求。一个标准按钮可以正确响应 Enter，却不知道“重试”应该处理哪些失败文件。开发者也可能通过错误的名称、模板或焦点安排，破坏原本可用的基础行为。
GNOME 的 UI Styling 指导建议减少不必要的自定义样式，以控制维护成本并保持与无障碍、本地化能力的兼容。[16] 这并不排除定制控件。专业绘图、音频和数据工具可能需要现成控件无法提供的表达方式；采用定制实现时，应把输入、语义和适配工作一起纳入成本。
3.4 一致性与产品差异
设计系统可以统一同类按钮、焦点和错误反馈，却不应替所有应用决定相同的信息结构。照片浏览器需要图像预览，批量文件处理工具需要比较名称、大小与结果，设置页面需要让用户理解选项之间的关系。它们可以遵循同一平台规范，仍然拥有不同的布局与信息密度。
窗口大小也是设计条件的一部分。GNOME 的适配指导讨论了窄窗口、分屏和大型窗口，并提醒在调整布局时保留功能。[17] 对一个双栏文件管理器，把窗口缩窄后，开发者需要处理两栏的摆放，同时决定当前操作对象是否保留、焦点在哪里，以及用户怎样继续查看另一个位置。
在 WinUI 中，布局判断依据窗口可用的有效像素。用户在高分辨率显示器上把窗口缩成半屏，或增大显示缩放后，可用布局空间都可能减少。文件列表与详情面板因此可以在空间不足时改为单页切换，保留所选文件、返回入口和主要命令；断点应设在内容开始拥挤的位置，不能只根据显示器分辨率决定是否显示双栏。[18]
Files v4.0 的修复记录就包含这类具体问题：自适应布局使活动面板失去焦点、非活动面板在文件变化时抢走焦点、切换布局后焦点错误地进入右侧面板。[7:1] 这些记录说明，多栏布局的完整实现需要维护操作上下文。两张并排的文件列表画出来以后，交互工作仍然没有结束。
由此可以看出设计系统的收益与应用自身的责任：共同规则和控件减少重复实现，应用还要把它们接到自己的任务、状态与数据上。
4 把交互要求落实到工程
4.1 界面状态与任务状态
继续看开篇的文件复制。按钮会经历悬停、按下、获得焦点等状态；复制任务则可能正在准备、执行、等待冲突处理，最后全部成功、部分成功或失败。这是两组不同的状态。任务正在运行时，取消按钮仍可以获得焦点；窗口暂时不在前台时，任务也可能继续执行。
如果把所有变化都放进一个 isLoading，界面就很难准确表达后续情况。“没有加载”究竟是尚未开始、已经成功、发生错误，还是取消完成？实现需要根据任务区分这些结果，再决定用户可以看到什么、执行什么操作。
下面是一项批量复制功能可以采用的状态设计。它描述需求，不对应某款文件管理器的内部实现：
| 情况 | 需要向用户说明什么 | 应用需要保留或处理什么 |
|---|---|---|
| 正在执行 | 来源、目标、进度与当前是否仍在工作 | 任务标识、进度信息、取消请求 |
| 同名冲突 | 哪个对象冲突，每个选项作用于哪些项目 | 待处理对象、用户选择及其适用范围 |
| 部分失败 | 已完成、失败和未处理的项目 | 逐项结果、失败原因、重试条件 |
| 请求取消 | 请求已收到，哪些工作已经发生 | 停止后续任务、处理进行中的操作、汇总实际结果 |
| 操作结束 | 最终结果，以及可继续采取的动作 | 结果记录、错误详情和适用的恢复信息 |
这里尤其需要区分取消与回滚。收到取消请求时，部分文件可能已经复制完成，另一些正在写入。应用需要决定如何处理未完成的目标文件，并根据实际结果更新界面；不能因为用户点击了取消，就立即宣称所有影响都已消失。如果任务在处理取消前已经完成，也应显示真实结果。
重试同样需要明确对象。只重试失败项目，与重新执行整批操作，可能得到不同后果。实现时要考虑目标文件是否已经存在、原文件是否发生变化，以及再次执行会不会重复生成内容。这些信息会影响用户能否放心使用“重试”。
底层文件操作本身也可能很复杂，涉及权限、存储故障和数据一致性。用户交互增加的这些要求，需要与底层实现一起设计。哪一部分花费更多时间，取决于具体功能和已有基础设施，不能给所有项目规定一个工时倍数。
4.2 错误信息需要连接到下一步
一个错误码有助于诊断，却未必能帮助用户继续完成任务。界面需要说明受影响的对象、已经发生的结果，以及当前可以采取的操作。对于批量任务，这还包括是否能跳过个别失败项、继续处理其他项目。
以 WinUI 为例，复制结束后的汇总或可以稍后处理的提示，适合放在页面文字、结果面板或 InfoBar 中；需要用户决定是否覆盖目标时，才使用 ContentDialog 中断当前流程。[19] 多窗口应用还要让对话框属于发起操作的窗口，为它设置正确的 XamlRoot，协调同一窗口内的显示顺序，并在关闭后恢复合理焦点。否则，用户可能在另一个窗口看到与当前操作无关的提问。
Files 在 2026 年 7 月发布的 v4.2 中，为文件占用对话框增加了“Skip”按钮。[20] 这项改动说明，错误处理会决定任务能够怎样继续。为了支持跳过，开发者需要让界面命令与队列、结果记录和最终提示保持一致。
恢复能力还会影响是否需要事前确认。GNOME 的对话框指导倾向于在可以恢复时提供撤销；无法提供撤销时，仍建议用确认说明风险和即将发生的操作。[21] 因而，移入回收站与永久删除可以采用不同处理，不能把“少打断用户”直接变成删除所有确认框的理由。
撤销也需要真实的实现条件。恢复覆盖前的文件，可能需要保留原内容；恢复被移动的对象，需要知道原位置，并处理该位置已被其他对象占用的情况。如果外部状态已经变化，应用可能无法完整恢复，这时仍需解释哪些部分成功、哪些没有成功。按钮上的“撤销”表达的是一项能力，工程实现必须说明它的范围。
4.3 无障碍是同一任务的另一组使用条件
只用鼠标完成一次复制，不能说明这项功能对其他输入方式同样可用。键盘用户需要合理的焦点路径和可见的当前位置；屏幕阅读器用户需要知道所选对象、控件含义和操作结果；低视力用户可能依赖文本放大或系统对比主题。这些用户要完成的仍是同一项任务。
应用可以先从完整流程检查：用键盘找到来源和目标，选择文件，启动复制，处理一个冲突，再查看失败结果。每个局部控件都可以获得焦点，仍不保证整个流程连续。例如，关闭冲突对话框后焦点丢失，或者任务失败后只在角落改变一个图标，用户仍可能不知道该怎样继续。
标准控件提供基础支持，应用还需要为图标按钮提供名称，让动态变化能够通过平台的无障碍机制被获知，并验证实际的朗读和导航结果。Microsoft 的文档也要求开发者检查控件语义与辅助技术行为。[15:1] 这种检查应随功能变化持续进行，因为一次布局调整也可能改变焦点或阅读顺序。
WCAG 2.2 提供了键盘、焦点、对比度和指针操作等可测试要求；讨论非网页桌面软件时，可以结合 WCAG2ICT 对非网页情境的解释，以及平台自身的实现指导。[22][23] 它们帮助提出明确要求，但几项简单检查不等于完成整个应用的无障碍评价。
拖拽替代路径能说明检查为什么必须具体。WCAG 2.2 的 2.5.7 关注不需要拖拽的单指针操作方式；仅增加键盘快捷键，并不一定满足这一要求。[24] 对文件移动而言，用户可以通过点击选择对象，再点击移动命令并指定位置。这条路径与键盘路径可能共享控件，但需要分别验证。
因此，无障碍不能只剩“我们支持键盘”或“用了原生控件”一句话。应当确认目标用户能否完成任务，并把阻断流程的问题具体记录下来。对比度、目标尺寸和缩放要求的几个区别见附录 A。
4.4 任务耗时与界面响应
复制大量文件需要时间，保持界面响应则是另一项要求。用户应该知道任务已经开始，能够查看状态，在支持取消时发出请求，并继续进行不受影响的工作。加一个进度动画可以表达等待，却无法替代底层进度信息，也无法解决界面线程被长时间占用的问题。
Microsoft 的性能指导将响应能力与 UI 线程处理工作的机会联系起来，建议适当使用异步 API，并提醒 await 本身不会把所有应用计算移到后台。[25] 开发者还要处理实际的线程与调度安排，避免耗时工作阻塞输入和更新。
实时搜索还需要处理输入与结果的时序。如果产品要求输入时更新查询，就要让 TextBox.Text 的双向绑定按属性变化提交；默认的失焦提交可能使用户打完文字后仍看不到变化。[26] 搜索开始后，新查询可能比旧查询更早完成，应用可以用请求标识检查结果是否仍属于当前查询。输入提交、异步执行与结果更新需要共同维护用户眼前的状态。
评价性能时，应分别记录首次反馈、任务完成与取消响应。一个软件可能很快显示“正在复制”，却迟迟不能完成；另一个可能底层吞吐较好，却在枚举目录时让窗口停止响应。把它们都概括成“快”或“慢”，很难确定改进方向。
大目录中的列表还需要考虑数据与 UI 元素的规模。Microsoft 对 ListView 和 GridView 的性能指导将 UI 元素创建时间、数据与界面元素的内存占用列为主要因素。[25:1] 界面是否创建了过多对象，缩略图是否占用了太多资源，刷新是否反复重建视图，都值得结合性能记录调查。
4.5 界面完成的条件需要一起维护
状态、恢复、无障碍和性能会彼此影响。调整布局可能改变焦点，改成异步执行可能暴露取消与完成之间的时序问题，增加逐项结果又可能带来大列表的渲染开销。因此，设计交付不能只是一张静态效果图，工程验收也不能只检查成功路径。
对一个小项目，可以先选定最重要的工作流，写下正常、失败和取消时的预期，复用已有控件，再补充与这些行为对应的验证。这样新增功能时，维护者知道需要保护哪些既有行为，也能更准确地估计改动成本。
这正是 UI/UX 与软件工程相交的地方：设计确定用户应该获得怎样的信息和控制，工程让它在实际运行条件下成立。代码由人手写还是由 AI 生成，都需要经过这一步。
5 AI 生成界面之后，开发者还需要什么
5.1 相似界面怎样产生
“做一个现代、简洁的 dashboard”描述了很宽泛的风格，却没有说明用户要比较什么信息、主要操作是什么，以及页面需要怎样的密度。这种提示给生成过程留下了大量空白，模型就需要从已有模式中补齐布局、字体、颜色和组件。侧边栏、卡片、圆角与浅灰背景因此可能被反复选中。
训练样本会影响模型熟悉哪些组合，以及哪些实现更容易被复用。v0 的旧设计系统指南明确说明，它针对 shadcn/ui 的默认实现做过专门训练，使用者大幅定制这些组件时，生成结果可能出现不符合预期的情况。[27] 这提供了一个具体例子：生成工具对某套实现的熟悉程度，本身就会影响输出选择。
提示词与项目环境会继续影响这个过程。不同产品如果都只提供“modern / clean / minimal”这类要求，又沿用相同的默认字体、间距、图标和组件，就缺少引导模型作出不同选择的信息。Tailwind 的样式工具类和 shadcn/ui 的默认组件，可以成为这类重复组合中的实现材料。[28][29] 在这种条件下，我认为训练中熟悉的模式、通用提示词与默认资源会相互强化，使不同任务更容易得到相似的界面。
要减少这种千篇一律，需要把产品自己的设计意图加入生成条件：文件比较需要哪些列，图片浏览需要多大的预览，哪些命令必须直接可见，哪种信息关系适合分组。v0 的提示词指导也要求补充具体功能、设计偏好与技术条件，Design Systems 2.0 则允许提供团队已有的组件、变量和约定。[27:1] 这些信息让生成过程能够围绕具体任务选择结构，也使开发者有依据判断结果是否合适。
5.2 把设计决定写进生成条件
让 AI 辅助设计时，可以先提供用户、任务与约束，再要求它提出候选结构，说明各自适用的条件。对尚未确定的部分，AI 可以帮助比较；对已经确定的组件和行为，应提供准确资料，让它据此实现。
例如，为一个批量文件操作工具写下这样的要求：
用户需要把一批文件复制到另一个位置，并确认哪些项目没有完成。
界面要清楚区分来源、目标和任务结果。
主要命令包括开始复制、请求取消、查看失败项和重试失败项。
同名冲突需要说明作用对象，以及选择是否应用到后续项目。
取消后按实际结果汇总，不假定已完成操作都会回滚。
采用项目现有控件、语义颜色与间距变量。
主要任务应支持键盘，并向辅助技术提供控件名称与状态信息。
窗口变窄后仍能完成任务，保留选择与操作上下文。这份说明还不是完整规格，但已经让讨论落到行为上。模型生成后，可以逐项检查，并继续补充不明确的地方。相比只写“现代、简洁、好看”，它更容易暴露哪些需求尚未落实。
设计输入也不应变成另一套未经解释的模板。导航在多宽时折叠，需要看内容是否放得下；设置是否立即生效，需要看操作代价和恢复方式；是否使用卡片，需要看信息之间的关系。填入固定断点或某种材质名称，并不自动提供这些理由。
AI 可以参与提出方案、实现原型和发现遗漏。它给出的解释仍是一项建议，开发者需要检查理由、观察运行结果，并决定是否接受。组件代码生成正确，只回答了实现的一部分；用户是否理解这组行为，还要通过使用来判断。
5.3 开发者可以从一项小任务开始学习
对已经会编程的人，我更建议围绕一个任务学习设计。先选文件复制、设置修改或批量重命名，写明用户希望完成什么，再学习与这项任务有关的概念和平台规范。Figma、Penpot、纸面草图或直接编码，都可以作为表达方案的工具。
Norman 的文章适合建立操作线索与概念模型的认识，Nielsen 的启发式原则适合检查已有界面。随后选择一种主要平台的 HIG，查看它怎样安排导航、命令和反馈。如果目标是 Windows 应用，可以将文档与 WinUI Gallery 中的交互示例、标记和代码放在一起阅读。[30]
Files 则适合用来观察这些行为如何组合成完整应用。它的构建资料列出了 WinUI 与 Windows App SDK 相关工具链，源码也可供查阅。[31] 学习时可以先执行一个任务，记录入口、状态与疑问，再去定位相关实现。直接复制页面外观，容易错过命令何时可用、焦点怎样移动、失败后怎样继续这些决定。
视觉练习可以更小：拿同一组文件信息，尝试调整字号层级、对齐和间距，再比较不同方案表达了什么。实现练习则可以选择一种错误状态，把它从接口返回一直接到用户能够继续操作。每次练习留下选择与理由，比一次定义几十个颜色和圆角变量更容易检查自己是否理解了问题。
等项目出现重复需求，再提取共同的组件与规则。一个小项目可以逐步积累自己的设计系统：稳定的语义颜色、文字层级、间距、控件状态，以及少量反复使用的交互模式。规则要能解释已有需求，也要允许在发现问题后修改。
5.4 让真实使用修正设计
原型可以操作以后，就需要让符合目标条件的人尝试。NN/g 对可用性测试的说明以任务、参与者和观察为核心：研究者给出实际目标，观察参与者怎样完成，并收集反馈。[32]
例如，任务可以是“把这些照片复制到指定目录，并确认哪些没有成功”，而不是“点击左上角的复制按钮，再打开状态中心”。前一种写法能观察用户如何理解界面，后一种已经提供了路线。参与者停顿、误操作或求助时，应记录当时的状态，再判断是入口难找、范围不清、反馈不足，还是对任务本身有不同理解。
访谈和行为记录各有价值。用户觉得界面拥挤、喜欢某种视觉风格，都值得听取；与此同时，还要观察他们是否完成了任务、如何确认结果。两类材料不一致时，应该继续追问原因，而不是任选其中一种作为全部结论。
早期从少量用户开始，可以帮助发现具体问题，但几个人的成功率和完成时间不能直接代表整个用户群。定性研究的样本与过程通常不足以支持这类量化推断。[33] 如果要比较总体效率，就需要围绕比较目的安排样本、任务与测量，并说明不确定性。
AI 生成的原型同样需要这个过程。若生成工具让尝试一个方案变得更便宜，就可以利用这个机会比较更多有理由的选择；完整开发是否更快，还要计入审阅、修复、测试与维护。最终值得保留的是在目标任务中表现更合适的方案，以及能够解释这项选择的记录。
结语：用户需要能够继续完成任务
回到开篇那次复制。用户需要知道哪些照片已经到达目标，哪些没有，以及重试会做什么。为了提供这些信息，应用需要记录逐项结果，安排清楚的反馈，给出适用的恢复操作，并让不同输入方式的用户都能获得这些能力。视觉层级、控件实现与底层任务处理在这里共同决定体验。
这也是我认为 UI/UX 应进入软件工程的原因。它会改变需求、接口、状态和验收条件，不能等核心功能完成后再统一作为外观调整处理。视觉本身也有价值：它帮助组织信息，并影响用户对产品的感受。承认偏好存在，不妨碍我们检查对比度、命令范围或任务结果这些具体问题。
成熟设计系统和标准控件能减少重复劳动，AI 也可以参与提出与实现方案。开发者仍需要说明软件为谁服务、支持哪些任务，以及哪些证据能表明它已经做到了。对于资源有限的项目，合理缩小范围、复用已有能力和公开限制，都是可持续的做法。质量问题可以被准确描述，投入多少工作则由项目在自己的条件下决定。
附录 A：无障碍要求中的几个区别
下面的条款用于查阅具体要求，不能代替完整评价。WCAG 的成功准则、用于解释准则的 Understanding 文档，以及针对非网页软件的 WCAG2ICT，具有不同用途；桌面实现还需要结合平台机制。
| 问题 | 对应资料 | 需要区分的条件 |
|---|---|---|
| 键盘操作 | WCAG 2.2，2.1.1，A | 覆盖功能操作，并有依赖输入轨迹的例外；不能只检查 Tab 能否移动 |
| 焦点顺序与可见性 | 2.4.3，A；2.4.7，AA | 顺序与可见性分别检查；焦点不能被其他内容完全遮挡还涉及 2.4.11，AA |
| 文本对比度 | 1.4.3，AA | 普通文本至少 4.5:1，大文本至少 3:1；大文本按规范定义，存在禁用控件、标志等例外[34] |
| 文本放大 | 1.4.4，AA | 不借助辅助技术将文本放大到 200%，且不丢失内容或功能，字幕和文字图像除外；不同于仅把操作系统显示缩放调到 200% |
| 拖拽替代 | 2.5.7，AA | 需要不拖拽的单指针替代方式，具有例外；键盘支持不自动满足它 |
| 目标尺寸 | 2.5.8，AA | 最小目标尺寸为 24×24 CSS 像素，有间距、行内目标等例外；不能直接理解为物理像素[35] |
| 交互触发的动画 | 2.3.3，AAA | 非必要的交互触发运动动画应可禁用；它不属于 AA，但项目仍可将减少动态效果列为设计要求 |
对比主题、辅助技术名称和本地化也需要在实际应用中检查。将某项检查列入项目要求，可以是开发者根据目标用户作出的决定，不必把所有实践都写成同一级别的标准条款。
附录 B：一次设计练习可以留下什么
下面以小型文件操作工具为例。记录的目的，是让设计理由和实际结果能够在下一次修改时继续使用。
| 阶段 | 建议保留的内容 |
|---|---|
| 明确任务 | 用户经验、使用环境、起始状态、完成条件 |
| 设计结构 | 信息分组、主要命令、备选方案及选择理由 |
| 设计行为 | 正常、失败、取消与恢复时的预期 |
| 实现 | 使用的控件、平台版本、定制部分及其原因 |
| 观察 | 操作路径、停顿、误解、求助、实际结果与用户反馈 |
| 修改 | 问题依据、修复内容、同一任务的复查结果 |
阅读资料时，可以按当前问题选择入口：Norman 的概念文章与《The Design of Everyday Things》用于理解人怎样认识操作；Nielsen 的启发式原则用于检查界面；平台 HIG 用于查阅具体模式；组件示例与真实应用源码用于理解实现。没有必要先读完所有体系，再开始做一个可操作的小原型。
参考资料
以下网页与公开文档访问于 2026-10-07。Files 的例子依据带版本的发布说明，说明项目记录过的设计与修复工作，不构成本文对当前版本的实测比较。
Don Norman、Jakob Nielsen，The Definition of User Experience (UX)，1998-08-08。区分整体体验、UI 与可用性。 ↩︎
ISO 9241-11:2018；NIST：Usability。本文采用特定用户、目标与使用情境中的有效性、效率和满意程度这一含义。 ↩︎
ISO/IEC 25010:2023，参见 标准预览第 3.4 节及其子条目。2023 年版使用 interaction capability；预览中的前言还说明了相对 2011 年版的术语调整。本文未将产品属性与使用结果等同。 ↩︎
ISO 9241-210:2019，官方公开摘要，说明交互系统生命周期中的以人为中心的设计原则与活动。 ↩︎
Don Norman，Signifiers, not affordances，2008-11-17，原刊于 Interactions 15(6)，此处为作者公开版本。 ↩︎
Jakob Nielsen，10 Usability Heuristics for User Interface Design，1994 年初刊。它们是通用启发式原则，不是具体产品的量化评分标准。 ↩︎
Files Community，Announcing Files v4.0，2025-09-03。正文引用 Filtering and search 与 Navigation and layout 部分；发布记录说明调整和修复内容，不提供其发生率或改进幅度。 ↩︎ ↩︎
Jakob Nielsen，Progressive Disclosure，2006-12-03。讨论主要与次要功能的安排，以及进入后续层次的可发现性。 ↩︎
KDE，Powerful when needed，包括配置、熟练操作与渐进式披露的指导。 ↩︎
Microsoft，Layout — Fluent 2。本文采用其关于空间关系、分组与层级的说明；具体间距变量属于该设计体系。 ↩︎
Kate Moran，The Aesthetic-Usability Effect，页面标注复核于 2026-09-01。包含主观评价与团队可用性测试观察；不能据此推导视觉美观必然改善实际任务表现。 ↩︎
Google Design，Better, Easier, Emotional UX。这是团队公开的多项研究总结；“up to four times faster”针对关键元素的发现速度，邮件示例同时调整大小、位置和颜色，不能分离归因于其中一项，也不是整体任务时间的四倍改善。 ↩︎
Microsoft Learn，XAML theme resources。说明 ThemeResource 在主题变化时重新求值、主题字典与系统颜色资源。正文的文件列表是应用这些规则的设计示例。 ↩︎
GNOME，Design Principles。关于任务聚焦、减少用户工作、渐进式披露与不必要打断的指导。 ↩︎
Microsoft Learn，Accessibility overview。涉及 XAML 控件、键盘、UI Automation、辅助技术名称与主题支持。 ↩︎ ↩︎
GNOME，UI Styling。涉及自定义样式、既有变量、主题和无障碍检查。 ↩︎
GNOME，Scaling & Adaptiveness。讨论不同窗口尺寸与设备条件下的布局，以及适配时的功能保留。 ↩︎
Microsoft Learn，Screen sizes and breakpoints for responsive design。布局面向应用窗口的可用空间，以有效像素表达尺寸；正文的列表与详情切换为本文提出的方案。 ↩︎
Microsoft Learn，InfoBar 与 Dialog controls。分别说明页面内状态反馈，以及 ContentDialog 的阻塞行为、XamlRoot 和同一窗口的显示限制。 ↩︎
Files Community，Announcing Files v4.2，2026-07-05，Other highlights 中记录 File In Use 对话框增加 Skip 按钮。正文对任务继续与结果记录的讨论是基于这一改动的工程分析。 ↩︎
W3C，Web Content Accessibility Guidelines 2.2，2024-12-12 Recommendation 版本。正文与附录所列级别依据各成功准则。 ↩︎
W3C，WCAG2ICT Overview；Guidance on Applying WCAG 2 to Non-Web ICT，2025-12-11 Group Note。该指导为信息性文件，本身不设新的规范性要求。 ↩︎
W3C，Understanding SC 2.5.7: Dragging Movements。单指针替代与键盘操作分别评价；存在拖拽本质必要、用户代理控制等例外。 ↩︎
Microsoft Learn，Keep the UI thread responsive 与 Optimize ListView and GridView performance for WinUI。分别讨论 UI 线程与异步工作，以及列表的 UI 创建、内存占用等问题。 ↩︎ ↩︎
Microsoft Learn，Windows data binding in depth。TextBox.Text 的默认双向源更新涉及 LostFocus，逐字更新可选择 PropertyChanged；异步结果的请求标识检查是本文提出的实现要求。 ↩︎
Vercel，Design systems — legacy、Text Prompting 与 Design Systems 2.0。旧指南说明针对 shadcn/ui 默认实现的训练，提示词指南要求补充具体条件，新指南说明导入团队设计资料的流程。关于训练偏好、通用提示与默认资源共同促成相似结果的解释是本文分析，不是对所有生成工具训练集的统计结论。 ↩︎ ↩︎
Tailwind CSS，Styling with utility classes。说明样式工具类的组合机制。 ↩︎
shadcn/ui，Introduction。说明组件代码可修改、组件分发与默认样式等设计。 ↩︎
Microsoft，WinUI Gallery。包含控件代码、适配布局及设计与无障碍示例。仓库可能包含实验性 API，使用时需确认对应 SDK 与接口状态。 ↩︎
Files，Compiling the source code；项目源码。用于查阅构建条件与实现，实际依赖版本以所研究的代码版本为准。 ↩︎
Kate Moran，Usability (User) Testing 101。介绍任务、参与者、观察过程，以及定性和量化研究的用途。 ↩︎
Raluca Budiu，Why You Cannot Trust Numbers from Qualitative Usability Studies，2021-05-23。讨论小样本与可变研究协议下的量化推断限制。 ↩︎
W3C，Understanding SC 1.4.3: Contrast (Minimum)。大文本的定义涉及字号、字重及 CJK 字体的等效尺寸；非文本信息另有条款。 ↩︎
W3C，Understanding SC 2.5.8: Target Size (Minimum)。24×24 CSS 像素及规定的例外，不应与 2.5.5 的增强级别或平台触摸建议混用。 ↩︎