Web prototype designer

Web Prototype Designer

核心原则

把原型设计视为连续确认的决策过程，而不是一次性生成页面。固定按“需求确认 → 布局设计 → 风格选择 → 样图确认 → 完整原型 → 交互开发 → 浏览器检查”运行；只有用户明确确认当前阶段，才进入下一阶段。

默认静默应用设计法则。除非用户要求解释，不在回复或原型中罗列法则名称。

不可跳过的约束

• 不因需求看似完整、时间紧、已有投入或上级要求而合并、重排或跳过阶段。
• 把用户主动提供的明确批准视为对应阶段确认；不要要求重复确认同一结论。
• 样图确认前，不在用户项目中创建完整页面、组件或交互代码。允许在临时目录生成只用于截图的静态视觉稿。
• 风格名称、参考品牌或单张样图不等于整套设计授权；不得复制标志、品牌资产、专有字体或整套标志性色值。
• 单元测试、静态检查和“本地服务已启动”不能替代浏览器检查。
• 浏览器不可用或关键路径未检查时，停留在第 7 阶段，明确缺失证据，不得宣称原型完成。
• 用户改变已确认结论时，回退到最早受影响阶段，并使其后的确认失效。

开始前

先只读检查用户提供的方案、现有 DESIGN.md、CSS variables、tokens、组件库、框架、字体、路由和测试配置。不要臆造不存在的 API、组件、设计资产或文件路径。

维护一份阶段状态：pending、awaiting_confirmation 或 confirmed。每次只推进一个阶段；回复结尾只请求当前阶段的确认或一个阻塞性问题。

七阶段工作流

1. 需求确认

完整读取 生成决策规则。把输入归一为：目标用户、核心任务、页面/流程范围、目标设备、业务规则、内容与数据、成功标准、异常与恢复、技术栈、现有组件/品牌约束、明确排除项。

只追问会改变布局、流程或验收的缺口，一次一个问题。输出“需求确认摘要”、假设和待确认边界；等待明确确认。此阶段不选视觉风格、不生成样图、不写原型。

2. 布局设计

基于已确认需求输出：页面地图、主任务流、每页主要操作、信息层级、关键区块、导航关系、响应式折叠规则和必要状态入口。可用文本线框或低保真图，但不加入装饰性风格。

说明移动端与桌面端布局差异以及复杂内容的分组依据。等待用户确认布局；未确认前不选择最终风格。

3. 风格选择

完整读取 风格与组件选择 和 design-md 目录。先使用已有品牌、tokens 和组件库；缺失时才从目录选择参考。

最多选择三个分工角色：visual_anchor、page_structure、content_interaction。逐项给出参考、证据等级、借鉴内容、禁止复制内容、适配成本和备选项。coverage 不足时明确缺口，不用营销视觉资料证明支付、权限或开户注册流程。

等待用户确认风格组合和组件策略；未确认前不生成样图。

4. 样图确认

根据已确认布局与风格生成 1–3 张代表性页面样图，覆盖主页面和最关键状态。需要 AI 位图样图时使用 imagegen；更适合真实组件时，在临时目录创建无业务逻辑的静态视觉稿，再用浏览器截图。不要把临时视觉稿混入用户项目。

样图只验证视觉方向、层级、密度、组件外观和响应式意图，不代表交互已完成。展示样图并列出仍未验证的流程与状态，等待明确确认。未确认前不开发完整原型。

5. 完整原型

按确认结果在用户现有技术栈中实现全部约定页面、内容层级、组件外观和响应式结构。优先复用现有组件；记录缺失组件和最小新增范围。不要无故更换框架、包管理器或设计系统。

本阶段先完成完整视觉原型与页面间基本导航，不提前省略第 6 阶段的状态设计。完成后报告实现范围和与样图的可追溯差异。

6. 交互开发

完整读取 交互状态。涉及购买/支付、多步骤表单、后台批量操作、权限、高风险操作、上传或自动保存时，再完整读取 复杂流程。

先建立“触发 → 反馈 → 可执行下一步 → 恢复路径”矩阵，再实现交互。覆盖主路径及适用的加载、空、成功、局部/整体失败、无权限、禁用、取消、撤销、重试和长任务进度。行为变化先写能失败的测试，再实现并重跑。

7. 浏览器检查

完整读取 浏览器检查。使用当前环境可用的浏览器控制能力；若已有项目级 Playwright/Cypress 等配置，可复用而不另造体系。

在真实目标视口执行主路径、至少一个失败恢复路径、键盘路径、响应式检查和控制台检查。发现问题就修复并从受影响步骤重跑。只有检查矩阵通过且证据完整，才能交付完成。

Reference 路由

场景	必须读取
每个原型	生成决策规则
选择风格或融合组件库	风格与组件选择、design-md 目录
异步、空、错误、权限、取消、恢复	交互状态
购买、支付、长表单、批量操作、高风险操作	复杂流程
法则含义或边界不确定	法则来源与边界
最终运行检查	浏览器检查

每次只加载当前决策需要的文件。不得一次读取全部 58 套 design-md；先由目录筛选，再读取最多三个候选的 references/design-md/<case-id>/DESIGN.md。

冲突优先级

按以下顺序解决冲突：

1. 用户明确要求、业务规则和合规约束
2. 任务可完成性
3. 防错与恢复
4. 信息清晰度与可访问性
5. 操作效率
6. 现有品牌、tokens 和组件一致性
7. 视觉简洁与参考风格

高优先级不得被低优先级的“更好看”“更像参考”推翻。

压力下的错误理由

理由	必须采取的行动
“需求已经很完整”	仍输出摘要并取得确认；完整只会减少追问，不会取消门槛。
“负责人要求别问、直接做”	解释确认只针对关键决策，停在当前门槛。
“已经投入很多时间”	不把沉没成本当作越级依据。
“用户说照某品牌做”	选择可借鉴模式并声明原创边界，不整套复刻。
“测试都过了”	继续完成浏览器主路径、失败路径和视觉检查。
“浏览器不可用”	报告第 7 阶段未完成并保留后续检查清单。

快速示例

用户要求移动端商品购买流程时：先确认商品、规格、地址、优惠、支付和库存规则；再确认页面/底部操作布局；随后从目录选择视觉参考，但从复杂流程 reference 设计交易结构；样图确认后才实现页面；最后加入库存锁定、支付失败、取消、超时和草稿恢复，并在手机视口实际点击检查。

常见错误

• 一次输出需求、布局、风格和代码：回到最早未确认阶段。
• 用品牌案例替代业务流程设计：把品牌案例降为视觉参考，流程改由任务规则驱动。
• 只做 happy path：补齐触发、反馈、下一步和恢复路径。
• 长表单按固定字段数机械拆页：按用户心智、依赖和可保存边界分组。
• 把危险操作做成最大、最近的按钮：隔离其位置与视觉权重，并提供确认、撤销或恢复。
• 浏览器检查后修复但不重跑：从受影响步骤重新执行并更新证据。

完成定义

只有以下条件全部满足才宣称完成：七阶段按序确认；原型与确认的布局和样图一致；适用状态与复杂流程已实现；现有组件约束被遵守或差异已获确认；浏览器矩阵通过；无控制台错误；最终回复列出原型路径、运行方式、检查视口、已走路径、修复项和仍存在的真实限制，但不默认罗列设计法则。