html-prototype

HTML 原型

构建一个可信的产品决策模型。根据用户的上下文匹配产物，而不是套用固定的通用风格。目标不是制作所有可能的屏幕，而是让重要的视觉或行为问题可以接受测试。

选择保真度模式

使用以下两种模式之一：

• Mockup（视觉稿）： 当待解决的问题涉及视觉层级、布局、字体、颜色或产品契合度时，创建精致、响应式且基本静态的产物。
• Prototype（原型）： 当待解决的问题涉及导航、输入、状态变化、反馈、恢复或过渡时，创建可运行的流程。

不要创建单独的 html-mockup 技能。不要为了让视觉稿显得更完整而添加行为。如果用户同时要求两种模式，请保持内容和结构一致，以便轻松比较不同保真度下的变化。

根据上下文确定方向

在设计前检查对话、提供的参考资料和项目。查找设计系统文档、设计令牌、现有组件、产品截图及相关产物。

优先级顺序如下：

1. 用户明确提出的视觉和功能要求。
2. 项目既有的设计语言和交互惯例。
3. 产品、受众、内容和场景。
4. 你自己的设计判断。

编码前，先确定：

• 用户及其关键任务；
• 正在评审的限定场景；
• 视觉稿或原型模式；
• 视觉方向的来源；
• 相关状态模型；
• 真实产品接管的位置。

如果没有设计系统，请根据主题和用例确定具体方向。不要默认使用渐变、暗色仪表板、千篇一律的卡片或装饰性指标。面向现场作业工具、编辑工作流和财务审批的原型，不应给人以同一种产品的感觉。

当 design-artifact 可用且视觉方向尚未确定时，请阅读该技能，并将其与本技能结合使用。用它来选择风格、配色、字体和构图；保真度、状态和交互完整性仍以本技能为准。

限定可信体验的范围

选择能够回答评审问题的最小流程。使用真实且前后一致的名称、日期、状态、数量和文案。

• 确保模型范围内的导航可正常使用。
• 表单应包含标签、验证、提交反馈和合理的默认值。
• 仅当场景涉及打断或确认时才使用对话框。
• 使用过渡来说明连续性或状态变化，而非装饰。
• 移除无效按钮。如果某项操作属于真实系统，请说明边界，不要假装操作已完成。

建模相关状态

构建前列出状态。包括所选场景中实际可能出现的状态：

• 加载中；
• 空状态；
• 错误；
• 成功；
• 禁用；
• 移动端；
• 需求说明中特定领域的状态。

异步效果明显的原型操作通常应展示加载、成功以及失败或恢复状态。对于集合，通常应考虑空状态。对于受限制的操作，应说明禁用原因。不要为了满足检查清单而将无关状态强行纳入主流程。交接时应明确说明省略了哪些状态。

完善交互

• 使用语义恰当的原生元素。
• 支持通过键盘完成整个模拟流程。
• 保持焦点可见，并在重要状态转换后有意设置焦点位置。
• 为对话框设置无障碍名称、限制焦点范围、支持按 Escape 关闭，并将焦点还原到触发元素。
• 将表单错误与对应控件关联，并播报重要的状态变化。
• 不要将关键行为仅限于悬停时可用。
• 尊重 prefers-reduced-motion，同时保留状态反馈。
• 确保触控目标便于操作，并防止页面意外出现水平溢出。

在模型演示模式下，即使控件尚未接入功能，也要保留语义结构和可见的焦点样式。明确标示静态审查的范围。

构建要求

• 交付一个包含内联必要 CSS 和 JavaScript 的独立 .html 文件。
• 不依赖构建工具、身份验证、实时 API 或外部服务。
• 采用响应式布局，而不是缩小桌面画布。
• 设计令牌应精简，并贴合所选方向。
• 确保对比度符合无障碍要求，并使用颜色以外的方式传达状态。
• 与其在虚构产品中追求广度，不如深入打磨一个流程并确保其正确性。

验证并交付

在宽屏桌面和窄屏移动设备上测试产物。检查每种模拟状态和控件。测试 Tab、Shift+Tab、Enter、Space、适用时的方向键，以及对话框中的 Escape。检查控制台、页面溢出、长内容、禁用行为、焦点还原和减少动态效果模式。

检查每个不同表面上计算后的前景色和背景色，尤其注意暗色或带色区域内可能继承正文颜色的文本。如果无法使用浏览器工具，请说明哪些视觉和交互检查尚未验证，不要用源码检查代替实际测试。

返回绝对文件路径、保真模式、模拟的场景、已实现的状态，以及有意未实现的生产环境行为。

延伸阅读

阅读 Plannotator 的面向编码 Agent 的 HTML 线框图和原型，了解如何从已批准的结构转向模型演示或可运行的原型。