forms-inputs-checkout

表单、输入与结账

目的

帮助 Agent 设计、评审并实现清晰、易访问且转化率高的表单、输入项、验证和结账流程。

将每个表单都视为阻碍用户实现目标的障碍。Agent 的工作是降低这道障碍，同时避免收集错误数据、隐藏重要选项，或削弱易访问性、隐私、法律或业务要求。

何时使用此技能

适用于以下场景：

• 结账、购物车、支付、配送、账单、优惠码、账户、注册、登录、引导、订阅、潜在客户收集、支持、调查、设置、个人资料、上传和数据录入表单。
• 评审涉及表单的屏幕截图、线框图、Figma 描述、HTML/CSS/React 组件、设计系统组件或产品流程。
• 选择标签、输入控件、分组、进度指示器、默认值、验证、错误消息、帮助文本、提交状态和成功状态。
• 为语义化 HTML 表单、易访问名称、焦点、键盘操作流程、验证和响应式行为提供前端指导。

何时不使用此技能

以下场景请勿使用此技能：

• 通用页面布局、落地页、导航、营销内容或视觉品牌设计，除非页面包含表单或结账决策。
• 后端数据建模、欺诈检测、税务、法律、PCI/安全实现，或超出 UX/前端影响范围的支付处理器集成细节。
• 表单场景之外的通用转化文案工作。
• 用户明确要求使用源材料未涵盖的平台指南时，不要使用此技能处理特定平台的原生表单控件。此时应询问用户，或使用相应的平台技能/来源。

核心原则

1. 从外向内着手。 从用户的目标和当前所处的流程阶段开始，而不是从组织想要的数据库字段开始。
2. 设计新字段前，先考虑移除、延后、推断或设置默认值。 每个问题都会增加用户的操作成本和出错可能。
3. 让完成路径一目了然。 表单应有清晰的视线浏览路径，从标题到第一个问题，再到最终操作。
4. 使用与问题相匹配的控件。 优先使用原生、语义化的表单控件；选项较少时，应让选项直接可见。
5. 让标签提供持久的上下文。 除了简单、常见、只有一个字段的交互外，不要只用占位符作为标签。
6. 验证是为了提供帮助，而不是斥责用户。 应在用户完成作答后进行验证，避免可预防的错误，并就地提供解决方法。
7. 为错误做好设计。 用户可能会漏掉步骤、选错操作、输错内容、误解标签，或在压力下错过信息。
8. 不要只依赖颜色。 错误、成功、必填/选填状态、禁用状态以及支付/安全提示，除了颜色外还需要文字和/或形状来表达。
9. 让结账保持聚焦。 移除干扰，避免强制创建账户，清楚展示费用和后果，并确保主要操作符合买家的目标。
10. 如实呈现进度。 仅当流程顺序和范围足够稳定、不会造成误导时，才使用进度指示器。

每项原则都可作为可复用的卡片，详见 references/principle-cards.md。

默认建议

除非用户提供了特定于产品的约束，或技能中的决策提示表明需要提问，否则请使用以下默认设置。

表单目的与范围

默认设置：以尽可能少且可信的数据，帮助用户顺利实现当前目标。

覆盖此默认设置的情况：法规、安全、欺诈、身份、资格、支持或履约要求需要额外数据时。请询问具体要求及其影响。

问题集

默认：删除非必要问题；将可选问题或营销问题推迟到核心提交之后；在置信度较高时，根据已知上下文推断答案。

例外情况：可选答案对个性化、资格判定、定价、合规性或运营分流至关重要时。

结构

默认：短表单且主题较为集中时使用单页；长表单、包含分支流程的表单、移动端优先的表单或需要高度专注的任务，使用多页或每页一个事项的设计。

例外情况：用户需要一起查看多个相关答案、比较选项或完成内容密集的专家工作流时。

标签

默认：在字段上方使用清晰、简洁、自然的可见标签。顶部标签通常能缩短填写时间、更好地适应本地化，也适用于移动端。

例外情况：桌面端的密集型表单受到严重的垂直空间限制，或复杂的设置表单更需要便于扫描标签，而非提高填写速度时。

必填和可选字段

默认：避免设置可选字段。大多数字段为必填项时，用“可选”等文字标记少数可选字段。大多数字段为可选项时，用“必填”等文字标记少数必填字段。不要将每个字段都标为必填。

例外情况：组织标准要求使用星号时；仍需提供说明，并将标记与标签关联起来。

输入控件

默认：使用原生控件和语义化 HTML。一组少量选项中单选时使用单选按钮；是/否问题或多选时使用复选框；自由回答时使用文本输入框；仅当选项较多时能减少操作量，才使用选择框或组合框模式。

例外情况：设计系统中经过测试的无障碍自定义控件能够保留键盘操作、屏幕阅读器、焦点和错误处理行为时。

选择框

默认：将选择框作为最后手段。短列表优先使用可见的单选选项；长列表优先使用自动补全/组合框；已知最可能的答案时，优先使用合理的默认值。

例外情况：平台惯例或空间限制使选择控件成为最简单的无障碍解决方案时。

输入宽度

默认：当答案长度有固定范围时，例如邮政编码或安全码，应让字段宽度体现预期答案长度。长度不代表特定含义时，使用一致且实用的宽度。

例外情况：响应式布局限制、本地化或自动格式化会导致固定宽度产生误导时。

帮助文本

默认：仅在涉及用户不熟悉的数据、隐私/安全问题、特殊格式、敏感问题、可选/必填项例外情况或建议的答案格式时，提供简短且紧邻字段的帮助文本。

例外情况：专家工作流、重复使用的工作流或复杂工作流需要持续显示上下文帮助面板时。

验证

默认：在用户完成字段后进行验证，通常是在字段失焦或选择完成后，而非用户仍在输入时。对于错误率较高、格式严格、需要唯一性检查、有长度限制或有效答案范围很大的字段，使用行内验证。

例外情况：实时计数器或指示器可直接帮助用户构建答案，例如字符数限制或密码强度；应在输入时提供非阻断式反馈。

错误消息

默认：长表单或存在多个错误时，提供页面顶部的错误摘要，并为每个有问题的字段提供行内修正方法。应通过文字和视觉强调标记错误字段，不能只依赖颜色。

例外情况：非常短的表单只有一个明显错误，且行内消息位于当前视野内时。

提交按钮和提交状态

默认：让主要操作始终可见且处于启用状态；点击后清晰显示处理中状态，并防止重复提交。提交前避免隐藏或禁用提交按钮，除非说明原因且下一步修正方式一目了然。

例外情况：具有破坏性、不可逆或涉及法律敏感事项的操作需要明确的前置条件时；应说明缺少什么，并将焦点移至第一个阻碍项。

结账

默认：支持访客结账，或购买后创建账户；保持订单摘要和总额可见，尽量减少中途退出的机会；按合理顺序询问配送和付款信息，并将账户／个人资料相关问题推迟到后面。

例外情况：如果没有账户、身份验证、资格审核或已保存的关系，产品就无法完成交易。

进度指示器

默认：对于简短、不确定或会动态分支的表单，不显示进度条。只有在稳定的多步骤流程中，才显示范围、当前位置以及保存／状态信息。

例外情况：长表单需要提供安心感，但步骤会动态变化；此时使用「即将完成」或章节完成情况等概括性进度提示，而不是精确的步骤数量。

无障碍级别

默认：按照 WCAG 风格的预期进行设计：使用语义化控件、清晰可见的标签、键盘访问支持、有意义的焦点状态、足够的对比度、文本替代内容、避免仅靠颜色传达信息、支持文本缩放，并确保辅助技术能读出错误消息。

例外：不要降低无障碍标准。对于高风险领域，应询问是否需要额外的无障碍支持、测试或法律合规。

前端实现

默认：优先使用语义化 HTML；尽可能为原生控件设置样式；优先使用能保留原生语义的设计系统组件；围绕字段值、已触碰／已修改状态、验证状态、提交状态和服务器错误状态管理表单状态。

例外情况：确有必要时才使用自定义交互；在推荐之前，必须确保其支持键盘、焦点、屏幕阅读器和移动设备输入行为。

必须向用户询问的问题

仅当答案会改变推荐的表单设计时，才提出有针对性的问题。不要询问常规的最佳实践问题。

如果以下任何事项未知，且会实质性影响工作，请进行询问：

• 表单的业务／用户目标不明确。
• 流程涉及结账、付款、身份、法律同意、医疗保健、金融、政府、未成年人、无障碍合规或不可逆的后果。
• 表单字段很多，且不清楚哪些是必填、选填、可推断或可延后填写的。
• 受众、地区、语言、设备组合或辅助技术需求可能会影响标签长度、输入格式、键盘行为或信任提示。
• 存在权衡取舍，例如单页与多页、速度与仔细审核、可见选项与紧凑控件，或访客结账与创建账户之间的取舍。
• 需要现有的分析／研究来诊断用户流失、错误率或转化问题。

请使用 references/decision-prompts.md 中可直接用于提问工具的提示词。

评审现有表单的工作流

按以下顺序检查：

1. 目标契合度： 用户想要完成什么？表单是否不必要地拖延或阻碍了这一目标？
2. 问题必要性： 哪些字段可以删除、推断、设为默认值、改为可选或延后询问？
3. 流程与顺序： 问题顺序是否符合人们处理任务时的思路？敏感或费力的问题是否延后到建立信任或提供足够背景之后？
4. 结构与分组： 相关问题是否以尽可能少的视觉干扰归为一组？分支是否处理得清晰、不让人迷失方向？
5. 浏览路径与布局： 用户能否从标签到输入框再到操作一路顺畅地完成填写，而不必来回跳转、跨列浏览或错过重要信息？
6. 标签与控件： 标签是否清晰可见、简洁、持久，并与正确的语义控件相关联？
7. 帮助说明与微文案： 帮助说明是否切合上下文且简明？是否只解释设计无法直观表达的内容？
8. 验证与错误： 是否尽可能预防错误，在恰当的时机显示错误，并以可执行的补救方式表述？
9. 提交与成功： 主要操作是否明确？是否妥善处理加载、防止重复提交、成功状态和后续步骤？
10. 无障碍与实现： 表单是否支持键盘、屏幕阅读器、触控、移动设备键盘、缩放，以及不依赖颜色传达信息的使用方式？
11. 衡量： 建议针对完成率、中途退出情况、错误位置、完成时间、支持请求和主观挫败感进行测试或数据分析。

呈现评审意见时，按严重程度分组：阻碍性问题、高摩擦问题、无障碍问题、转化机会、润色建议。

创建或改进表单的工作流

1. 明确任务。 确定用户目标、业务目标、所需输出、受众、设备构成和限制条件。
2. 定义成功提交所需的最少信息。 将字段列为必填、可选、可推断、可设默认值和可延后。
3. 选择流程形式。 单页、多步骤、每页一个问题、渐进式展示或逐步引导。
4. 安排问题顺序。 先问低摩擦、可帮助建立上下文的问题；账户、敏感、法律或费力的问题应延后，直到有充分理由再询问。
5. 按用户主题对字段分组。 使用标题、留白、字段集和图例；避免添加视觉干扰的装饰性分隔线。
6. 选择控件和标签。 选择与问题匹配的最简单原生控件；使用清晰可见的标签和符合预期的输入属性。
7. 添加默认值和帮助说明。 仅在默认值很可能正确时设置；帮助说明应紧邻相关内容，简短且具体。
8. 设计验证与错误处理。 预防错误，在合适的时机进行验证；必要时提供错误摘要，并为具体字段提供补救方法。
9. 设计提交状态。 明确主要和次要操作、加载状态、防止重复提交、成功状态及后续步骤。
10. 检查无障碍性与前端可行性。 验证语义化 HTML、焦点、键盘顺序、必要时使用的 ARIA、响应式行为以及与设计系统的契合度。
11. 说明权衡。 说明所选默认方案、其适用原因，以及在不同限制条件下会有哪些变化。

决策框架

增加复杂度之前，按以下优先顺序考虑：

1. 删除问题。
2. 推断答案，利用已知上下文或系统数据。
3. 设为默认值，前提是该默认值符合大多数用户的目标且易于更改。
4. 延后问题，直到核心任务完成或答案变得相关。
5. 询问问题时尽可能采用最简单的方式。
6. 解释提问原因，尤其是用户可能感到疑惑、担忧或缺乏背景时。
7. 验证答案时尽量减少干扰。
8. 妥善处理答案缺失、错误或被服务端拒绝的情况。

实用规则

结构和流程

• 使用符合用户预期任务的标题命名表单，而不是使用内部数据库对象名称。
• 对于结账流程，避免设置必须登录才能继续的门槛。尽可能让用户以访客身份继续，或在购买后创建账户。
• 将较长的表单拆分为有意义的主题；不要为了营造参与感，把简短表单拆成多个页面。
• 当专注、分支逻辑、移动端操作体验或理解度比一览全貌更重要时，每页只展示一项内容。
• 仅在进度指示器能够如实说明整体范围、当前位置和状态时使用。
• 为耗时较长、需要投入大量精力的表单提供保存和恢复功能。

标签和问题

• 使用用户熟悉的语言，将标签写成简短、具体的问题或名词短语。
• 保持大小写一致。除少数警告场景外，避免使用全大写。
• 用户输入后仍应显示标签。占位文本可以作为补充，但不能取代标签。
• 同一表单中不要混用不同的标签对齐方式。
• 对于用户熟悉的数据和以移动端为先的场景，优先使用顶部对齐的标签。
• 只有在浏览不熟悉或大量可选字段比填写速度更重要时，才优先使用左对齐的标签。

分组和视觉层次

• 优先通过元素间距和留白来分组，而不是使用分隔线、面板或交替背景。
• 使用 fieldset 和 legend 对单选按钮、复选框及相关控件进行分组。
• 让主要操作与其提交的字段之间具有清晰的视觉关联。
• 避免使用双列布局，除非制表顺序、响应式折叠和内容浏览方式都清晰易懂。

控件

• 当用户必须从少量选项中选择一项，且所有选项都应显示时，使用单选按钮。
• 对于相互独立的选项，或单个是／否同意项或选项，使用复选框。
• 对于少量选项，避免使用选择框；它会隐藏选项并增加操作成本。
• 对于较长的选项列表，可考虑使用自动补全／组合框，并确保键盘操作无障碍且有效建议清晰明了。
• 让选项标签可点击；确保输入控件及其标签共用同一触发区域。
• 使用适合移动设备的输入类型和属性：仅在确实适合数字输入时使用 email、tel、url、number，并按需使用 autocomplete、inputmode、autocapitalize、spellcheck 和 aria-describedby。

必填、可选和可延后填写的输入项

• 除非可选字段能明确服务于用户或业务需求，否则应将其移除。
• 标注少数情况：大多数字段为必填时标注可选项；大多数字段为可选时标注必填项。
• 为清晰起见，使用文字而不是符号。如果使用星号，应提供说明，并添加无障碍标签。
• 仅在符合当前情境时询问优惠码、创建账户、营销偏好和补充个人资料；否则应延后询问。

默认值和个性化

• 只有在默认值很可能正确、可撤销且符合用户利益时，才用默认值减少用户操作。
• 不要默认选择隐藏费用、同意接收营销信息、高级套餐或高风险权限。
• 对于回访用户，如果相关信息很可能保持不变且易于修改，可个性化默认值。
• 谨慎设置国家／地区、配送和付款默认值：错误的默认值可能造成高昂损失。

帮助文本

• 对于不熟悉的术语、敏感数据、隐私／安全保障、不常见的格式、答案限制，或解释字段用途时，提供帮助信息。
• 将帮助信息放在相关标签／输入项旁边，或在包含大量重复字段的复杂表单中，放置于统一的帮助区域。
• 避免在表单前放置冗长的说明；用户常常会直接跳到字段开始填写。
• 不要用帮助文本来弥补标签不佳、控件选择错误、格式要求随意或不必要的问题。

验证、错误与成功

• 尽可能接受灵活的用户输入，例如电话号码或信用卡号中空格位置不同，然后在输入后进行规范化。
• 在验证有用的时机检查唯一性、可用性、严格格式和限制。
• 用户仍在正常输入答案时，不要显示错误。
• 说明问题是什么、出现在哪里，以及如何解决。
• 对于较长的表单，提供错误摘要，并提供链接或焦点跳转到每个出错字段。
• 使用文本、图标／形状和样式来表示错误；将红色和警告图标保留给错误，以免其失去意义。
• 提交成功后，确认已完成的操作，并提供下一步合理的操作。避免让用户无事可做的成功页面。

结账专属规则

• 让结账界面比浏览界面更简洁平静。移除无关导航、优惠信息以及会使用户离开结账流程的链接。
• 保留购物车相关信息：商品数量、可编辑的订单摘要、配送／账单／付款总额、已知的税费，以及预计送达时间。
• 按用户预期的顺序提问：联系信息／电子邮箱、配送／位置、配送方式、付款、审核／确认。若产品情境需要其他顺序，则相应调整。
• 尽可能将创建账户、设置密码、偏好选项和营销内容推迟到购买完成后。
• 付款／安全保障信息应具体且可核实，而不是泛泛的装饰。
• 提供优惠码输入选项，但在折扣并非业务模式核心时，应降低其视觉优先级。
• 确保最终操作明确传达其后果：下单、付款、订阅、提交申请或保存更改。

无障碍与包容性要求

始终检查：

• 每个字段都有无障碍名称；最好使用可见的 <label>，并通过 for／id 关联字段，或使用包裹字段的标签。
• 相关控件使用语义化分组：单选／复选框组使用 <fieldset> 和 <legend>。
• 错误和帮助文本通过 aria-describedby 或等效方式与字段建立程序化关联。
• 错误摘要可获得焦点、会被读屏软件播报，并提供指向无效字段的链接。
• 焦点顺序应符合视觉顺序和任务顺序；不得造成键盘陷阱；所有控件和帮助触发器都应无需鼠标即可使用。
• 焦点状态清晰可见，且不会被 CSS 移除。
• 表单在缩放和增大文字时仍可正常使用；移动端布局不得隐藏标签或错误消息。
• 颜色绝不能是唯一的提示方式。还应提供文本、图标／形状和程序化状态。
• 尽量减少动画、闪烁和自动变化；动态验证应以礼貌、不造成干扰的方式进行。
• 对于超时，应尽可能提供警告、延长时间的选项，并避免工作内容丢失。
• 文案避免仅依赖物理位置、颜色或视觉形状的指引，例如“右侧的绿色按钮”。
• 对关键流程进行测试时，应邀请目标用户参与，包括残障用户。

前端实现指南

在增加 JavaScript 复杂度之前，优先使用语义化 HTML。

<form novalidate>
  <fieldset>
    <legend>Delivery method</legend>
    <label><input type="radio" name="delivery" value="ship"> Ship to address</label>
    <label><input type="radio" name="delivery" value="pickup"> Pick up in store</label>
  </fieldset>

  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email" autocapitalize="none" spellcheck="false" aria-describedby="email-help email-error">
  <p id="email-help">We will send your receipt and delivery updates here.</p>
  <p id="email-error" role="alert" hidden>Enter an email address, like [email protected].</p>

  <button type="submit">Continue to payment</button>
</form>

实现规则：

• 除非自定义控件能保留键盘和辅助技术的行为，否则不要用自定义控件替换原生控件。
• 保持 DOM 顺序与视觉顺序一致，尤其是在多列布局中。
• 避免使用正值 tabindex；应改为调整 DOM 顺序。仅在需要通过程序将焦点设置到摘要或标题时使用 tabindex="-1"。
• 明确建模表单状态：值、是否已修改／触碰、客户端有效性、服务端有效性、加载／提交中、成功以及可恢复的失败。
• 对于服务端验证，应保留用户输入的值，并使用稳定的字段名称返回字段级错误。
• 点击后应禁用或防止重复提交；传达处理状态，并确保标签／后果易于理解。
• 除非界面同时说明阻止提交的原因以及如何解决，否则不要在未满足验证条件时隐藏唯一的提交途径。
• 适当情况下，为常见结账字段使用 autocomplete 令牌：name、email、tel、street-address、address-line1、address-level2、postal-code、country、cc-name、cc-number、cc-exp、cc-csc。
• 对于应使用文本输入而非数字输入的类数字值（例如邮政编码、电话号码和卡号），使用 inputmode。
• 尽可能在输入后进行格式化，而不是拒绝常见的人类输入格式。
• 组件 API 应接受可见标签、帮助文本、错误文本、必填／选填文本、描述 ID，以及用于间距／状态的设计令牌。

质量检查清单

完成建议前，请确认：

• 表单有明确的用户目标和主要操作。
• 每个字段都有当前存在的理由。
• 可选字段已移除、延后，或标记为少数情况。
• 问题顺序符合用户对任务的认知模型。
• 布局提供单一、清晰易读的完成路径。
• 控件与数据类型和决策类型相匹配。
• 标签始终可见，并通过程序关联。
• 帮助信息贴合上下文、简洁明了，且不会弥补糟糕的设计。
• 验证时机符合用户体验，字段错误具有可操作性。
• 错误和成功状态均经过设计，而非依赖默认设置。
• 除非有必要，否则结账流程不应设置账户门槛或不必要的退出路径。
• 键盘、焦点、屏幕阅读器、颜色对比度、缩放和移动设备键盘均已考虑。
• 实现可在设计系统和前端技术栈中实现。

请参阅 references/checklists.md 中的完整检查清单。

应避免的常见错误

• 根据数据库字段而非用户任务进行设计。
• 在核心任务之前询问可选资料、个人资料、营销或账户相关问题。
• 将占位符用作标签。
• 对较短的选项列表使用下拉框。
• 将每个字段都标记为必填。
• 对普通标签或帮助信息使用红色文字，削弱错误提示的含义。
• 在用户仍在输入时进行验证。
• 隐藏或禁用提交操作，却不提供明显的解决方法。
• 对动态或未知步骤使用进度条。
• 让次要／破坏性操作在视觉上与主要操作同等突出。
• 添加会打断浏览的装饰性分组。
• 一次显示所有依赖字段，让用户应接不暇。
• 以没有确认信息或后续步骤的成功页面结束流程。

请参阅 references/anti-patterns.md 中的完整反模式列表。

如何向用户解释建议

从完成任务、置信度、防错和信任的角度进行解释。

使用以下模式：

1. 说明建议。“使用清晰可见、顶部对齐的标签，并将帮助文本放在字段下方。”
2. 关联用户目标。“这样可以让用户在移动设备上轻松浏览结账流程，并降低用户输入时失去上下文的可能性。”
3. 说明权衡。“这会占用更多垂直空间，但表单足够简短，清晰度比紧凑更重要。”
4. 说明例外情况。“对于信息密集的专家设置界面，左对齐的标签可能更合适，因为用户会先浏览标签再进行编辑。”
5. 仅在有用时提供实现细节。“使用真正的 <label>，并通过 aria-describedby 关联帮助文本或错误文本。”