interactive-prototype

当用户要求制作一个可交互的原型时加载——也就是表现得像真实应用，而不是静态模型。

输出位置

将所有输出文件写入 ./opendesign/mockups/<task-slug>/。根据功能名称生成 slug（例如 checkout-flow、settings-panel）。

角色定位

输出应是一个有真实产品质感的原型，而不是分镜稿。状态转换要有效，表单要能验证，按钮要能跳转。如果 UI 中有可见的交互，它就必须实际生效。

这仍然是一个原型。后端、真实持久化和边缘情况可以简化。可以使用模拟数据，但必须实现顺畅流程所需的真实逻辑。

技术栈和结构

• 使用 React 的 useState 和 useEffect 管理本地状态和副作用。让状态与组件保持紧密关联。除非原型确实需要，否则不要使用全局状态存储。
• 将原型拆分为小巧、易读的组件。超过约 400 行的文件应拆分。
• 对于单文件原型，可以通过 Babel 使用内联 JSX。对于包含多个屏幕的原型，应按屏幕拆分组件文件并组合使用。
• 将原型放入合适的设备或窗口框架中——手机边框、浏览器界面或桌面窗口——让它看起来像一款产品，而不是一个网页。

必需的交互

• 为每个可交互元素设置悬停状态。
• 点击和轻触处理程序应能跳转到下一状态。不能有无响应的控件。
• 为顺畅流程添加表单验证：输入有效前禁用按钮；输入无效时显示错误状态。
• 为状态和屏幕之间的切换添加动画。动画应简短、有明确用途，而非纯装饰。
• 多步骤流程应端到端正常运行。用户应能沿着预期的顺畅流程完成操作，不会遇到死路。
• 在真实产品通常会显示加载状态和空状态的地方，也应提供这些状态。不要直接跳到已填充内容的视图。

真实感规则

• 使用逼真的模拟数据。不要使用 lorem ipsum 或“John Doe”。姓名、文案、数字和时间戳应符合产品场景。
• 移动端框架：点击目标的最小尺寸为 44px。
• 将关键状态持久化——当前屏幕、活动标签页、演示播放进度——保存到 localStorage，避免用户在迭代期间刷新页面后丢失位置。

不要包含的内容

• 真实身份验证、真实网络请求，以及 localStorage 之外的真实持久化。
• 生产级无障碍审计。基本语义和焦点管理即可。
• 所有可能的边缘情况。选择用户想要演示的流程，并确保这些流程可靠无误。