Files
cmbuyer/docs/design

设计原型输入约定

本目录存放页面原型,作为确认信息架构并校验用户故事清单和 交互清单的一次性输入物。 原型回答"页面上有什么";"该怎样表现"的权威始终是交互清单,不是原型。

一、定位与边界

  • 原型的唯一用途:让 agent 据图枚举页面、控件和用户可见动作,产出 IX 总表草稿,避免凭空发明界面或漏项。
  • 行为权威是交互清单:加载、空态、错误、权限、确认等行为以 IX 条目为准;原型与清单冲突时,以清单和需求为准,或先对齐再动手。
  • 原型不定义需求范围:原型里出现、但需求未收录的功能,不能因为"图上有"就实现。
  • 禁止把原型代码直接复制进生产实现:原型没有组件抽象、状态管理和可访问性实现,实现时按架构设计的组件边界重写。

二、默认形态:单文件 HTML 原型

  • 一个页面一个 .html 文件,按路由或页面名命名,例如 【items-list】.html、【login】.html。
  • CSS / JS 全部内联,零构建依赖,双击即可在浏览器打开。
  • 低保真优先:结构和控件齐全即可,不追求视觉完成度。
  • 使用语义化标签(button、form、table、dialog、nav),标签本身就是控件清单。
  • 列表内详情可以使用路由驱动的抽屉 / 模态层,但必须保留可复制的详情 URL、浏览器返回和 完整页直达兜底;关闭后恢复触发行焦点与列表现场。
  • 数据一律用假数据,页面顶部放固定横幅标注:PROTOTYPE - 仅供枚举交互,非实现依据。
  • 不加载外部字体、CDN、图片或生产地址;浏览器网络面板除当前本地文件外应为零请求。
  • 需要演示空态、加载、错误等状态时,可用少量内联 JS 做状态切换按钮,对应交互清单状态表的行。
  • 网页端使用 web-*.html,桌面端使用 desk-*.html。并行任务不得共同修改一个索引文件。
  • 原型至少验证 375、768、1024、1440 px;桌面端另验证 compact / medium / wide 布局。
  • 键盘顺序、可见焦点、错误文本、aria-live 与 prefers-reduced-motion 必须可检查。

三、替代形态:SVG / 手绘草图

布局说不清、画得快时,可用 SVG(Excalidraw、Penpot、Figma 导出)代替:

  • 文字必须保留为真文本(<text> 元素),不要导出为轮廓路径,否则 agent 读不到按钮文案。
  • 分组 / 图层使用语义命名。
  • 静态图只能表达一帧,状态与异常仍须在交互清单里逐项约定。

四、工作流

  1. 用一两句话描述页面:有哪些区块、控件和主要动作。
  2. AI 生成低保真原型(HTML 或 SVG),存入本目录。
  3. 人工在浏览器查看并调整,直到布局、控件集合和关键状态被明确认可;需要人工确认的 任务在此之前保持 DOING。
  4. AI 据原型产出交互清单的 IX 总表草稿,状态全部标【待确认】。
  5. 人工逐条确认行为决策(优先级、状态与异常、无障碍),P0 交互按详情模板展开。
  6. 对应 IX 条目在「关联原型」字段引用本目录文件;原型更新后检查受影响的 IX 条目。

五、生命周期与维护规则

原型是一次性输入物,生命周期是"开工前生成 → 显著改版时重新生成 → 实现后过期"。不建立"每模块常备原型库",也不承担与实现持续同步的义务。

  • 开工门槛(一次性):P0 的 UI 模块首次实现前应有原型;没有就先生成原型、人工确认后再拆任务。
  • 两阶段确认:Phase 0 先确认流程、状态、主动作和布局;T-103 真机取证后再核对实际可读 字段与文案。第二阶段若有变化,先修订 IX 与原型,再写生产页面。
  • 管理员“开始采购”授权的单趟流程属于显著改版,T-111 重新生成任务创建、工作台、详情和桌面执行 四个原型;旧的试选后确认/第二趟状态不得继续作为实现输入。
  • 触发式重新生成:新需求显著改变某页面的布局或控件集合时,把"重新生成该页原型 → 更新 IX 草稿"作为该任务的第一步。判断标准只有一条:这次变更是否让 agent 需要重新"看图"才能枚举交互。换文案、加字段等小改动只改 IX 条目,不碰原型。
  • 实现后即过期:页面实现后,原型自动视为过期,不回头修补;实现后的视觉事实由任务文件 ## 执行记录 中的真实截图或可运行验证承担。
  • 需要新原型时整页重新生成,不逐次修补旧文件。
  • 已无对应页面或已完成使命的原型可以删除;删除前确认没有 IX 条目仍在引用。
  • 本目录不放业务敏感数据、真实用户数据或生产接口地址。