基于 skills 仓库的 UI Prototype 实战指南单路由多变体切换与浮动切换栏实现【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills导读本文围绕开源仓库 GitHub_Trending/skills13/skills 中prototypeskill 的 UI 分支UI.md展开系统讲解如何在单个路由上生成若干结构截然不同的 UI 变体、用?variant搜索参数与浮动底部切换栏floating bottom bar让用户在浏览器里来回对比、挑选甚至偷取不同变体的局部设计然后只把胜出者合入真实代码。读完本文你将掌握两种子形态Sub-shape A / Sub-shape B的选型标准、六步落地流程、键盘/路由交互约定、生产环境隐藏策略以及该 skill 在整套工程技能中的定位与边界。一、UI Prototype 是什么在哪个分支干活在 prototype/SKILL.md 中prototype是一条**由模型自动调用model-invoked**的工程 skill定位是为回答一个设计问题而写的、用完即弃的代码throwaway code that answers a question。SKILL.md 的 frontmatter 明确说明它的适用时机Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.skill 内部按问题类型分成两个分支详见 skills/engineering/README.md 对 prototype 的描述这套逻辑 / 状态模型手感对吗→ 走 LOGIC.md产出一个单一自包含 HTML 文件含自由点击按钮与分标签的引导式演练让非开发人员也能亲手推动状态机。这个东西看起来应该是什么样→ 走本文主角 UI.md在单条路由上生成若干结构上完全不同的 UI 变体用 URL 搜索参数加浮动底部栏在浏览器中切换。分支选错会浪费整个原型因为两者产出的工件差异极大。一个实用的默认判断问题是关于逻辑/状态而不是外观就走 LOGIC.md问题是某个页面该长什么样就走 UI.md。SKILL.md 还给了补充规则如果问题确实模糊且用户不在场就依据周边代码猜——后端模块偏向逻辑分支页面/组件偏向 UI 分支并在原型顶部写明该假设。二、什么时候该用这个形态When this is the right shapeUI.md 给出的典型触发场景非常直白这个页面应该长什么样我想在拍板之前先看几个 dashboard 的候选方案。给设置页试一种不同的布局。任何用户原本要花一整天在脑子里比较三张模糊线框图的时刻。它对应的是 docs/engineering/prototype.md 里那句判断你遇到一个靠谈话无法拍板的问题——比如一个无法在脑中完整推演的屏幕设计需要同时看到三个版本并排对比。当 grilling 类会话如 grill-me、grill-with-docs在这些问题上不断膨胀时agent 换个说法、你继续猜、范围越滚越大正确动作是停止 grilling去构建一个一次性版本看一眼然后用一句话回答。反之如果问题已经讨论清楚、只是要按规格落地实现则应按 to-spec / implement 的流程走而不是原型。三、两种子形态优先选择 Sub-shape AUI 原型最容易评判的时刻是它贴住应用其余部分的时候真实的 header、真实的 sidebar、真实的数据、真实的密度density。一条孤立的临时路由是真空——每个变体单独看都好看。因此 UI.md 给出默认策略只要存在一个合理的宿主页面就默认用 Sub-shape A。子形态 A对既有页面的调整首选路由已经存在变体渲染在同一条路由上由?variantURL 搜索参数门控。已有的数据获取、参数、鉴权全部保留只有渲染子树rendered subtree随变体切换。即便原型针对的页面还不存在但它天然属于某个页面内部dashboard 的新区块、设置页的新卡片、既有流程中的新步骤依然归为子形态 A——把变体挂载进宿主页面即可。从源码结构看这种做法的收益是零上下文丢失评审者看到的是变体在真实数据密度下的表现而不是一条与世隔绝的临时页面上孤零零的布局。子形态 B新页面最后的退路仅当被原型化的东西确实没有任何可嵌入的既有页面时才使用例如一个全新的顶级 surface或一段无法嵌进任何合理位置的流程创建一条临时路由throwaway route遵循项目既有的路由约定不要发明新的顶级结构。命名要让人一眼看出是原型路径或文件名中包含prototype字样。使用同样的?variant模式。提交到子形态 B 之前要自检真的没有任何既有页面可以承载它吗一条空路由会掩盖空路由才能暴露的设计问题——有内容的页面才会把问题逼出来。两个子形态下浮动底部栏的实现完全一致。四、六步落地流程Process第 1 步陈述问题并确定变体数量 N默认生成3 个变体超过 5 个就不再是截然不同而是噪音因此上限为5。随后用一行话写下计划放在原型所在位置或文件顶部注释里Three variants of the settings page, switchable via?variant, on the existing/settingsroute.这句话无论用户当下在不在场、要不要反驳都是有效的检查锚点。第 2 步生成结构上截然不同的变体为每个变体起草并逐条守住三条约束页面的目的与它能拿到的数据项目既有的组件库/样式体系TailwindCSS、shadcn、MUI、纯 CSSwhatever一个清晰的导出组件名例如VariantA、VariantB、VariantC。关键判据原文档反复强调变体必须在结构上不同——不同的布局、不同的信息层级information hierarchy、不同的主操作入口primary affordance而不是仅仅颜色不同。三个微调过的卡片网格不是 UI 原型是壁纸。如果两个草稿太相似就按明确禁止使用卡片网格的要求重做其中一个。第 3 步把它们接线到一起在路由上创建一个单一的切换器组件UI.md 给出的伪代码如下按项目框架适配// pseudo-code, adapt to the projects framework const variant searchParams.get(variant) ?? A; return ( {variant A VariantA {...data} /} {variant B VariantB {...data} /} {variant C VariantC {...data} /} PrototypeSwitcher variants{[A,B,C]} current{variant} / / );子形态 A既有页面所有数据获取保持在切换器之上只有渲染子树随变体变化子形态 B新页面临时路由挂在/prototype/name下挂载同一个切换器。这样?variant参数既是门控开关也是可分享、可刷新还原的状态来源——这正是后续评审与交接的基础。第 4 步构建浮动切换栏floating switcher一个位于屏幕底部居中的fixed定位小条包含三块左箭头循环切到上一个变体可回绕 wrap around变体标签显示当前变体 key若变体导出了名字一并显示例如B (Sidebar layout)右箭头循环切到下一个变体可回绕。行为约定可复用的检查清单关注点约定URL 同步点击箭头更新 URL 搜索参数用框架自带 routerNext 用router.replaceReact Router 用navigate等保证变体可分享、刷新后稳定键盘操作←/→方向键也能循环切换焦点豁免当input、textarea、[contenteditable]获得焦点时不得拦截方向键视觉区分与页面明显区分如高对比度胶囊、细微阴影让人一看就知道这不是被评审的设计本身生产隐藏以process.env.NODE_ENV ! production或等价检查门控防止原型误合并后把切换栏带给真实用户切换器应做成单一共享组件让两个子形态都能复用位置放在项目共享 UI 所在处。注意最后一行的用意一次意外的原型合并不该把切换栏发到用户端这是原型纪律的最后一道保险。第 5 步交接Hand it over把 URL连同各?variantkey交出去用户有空就翻一翻。原文档点出最有价值的反馈形态通常是——我想要 B 的 header 配 C 的 sidebar那才是用户真正想要的设计。也就是说变体不是用来单选的也可以被拆借。第 6 步捕获答案并清理胜出变体确定后捕获答案哪个变体、为什么按 prototype/SKILL.md 描述的方式捕获原型本身把胜出者合入真实代码其余内容放上一次性分支throwaway branch而非 main子形态 A把胜出者折入既有页面失败的变体和切换器从 main 移除子形态 B把胜出变体升级为真实路由临时路由和切换器从 main 移除。一个关键细节全套变体是一手来源primary source所以它落在一次性分支上而不是垃圾桶里——因为留在 main 分支上的变体组件和切换器会快速腐烂rot fast还会误导下一位读者。这与 docs/engineering/prototype.md 中原型不再是删掉而是作为 evidence 停在 main 之外的分支上的原则完全一致。五、反模式清单Anti-patternsUI.md 收尾处明确列出四条红线逐条展开变体只在颜色或文案上不同——那是微调tweak不是原型真正的变体必须在外观结构上互相矛盾。变体之间共享过多代码——共享一个Header没问题共享一个Layout就违背了初衷。每个变体都应能自由地抛弃布局。把变体接到真实的写操作mutations上——只读原型是没问题的如果某个变体需要写数据就指向一个 stub。要回答的问题是这应该长什么样而不是后端能不能跑。直接把原型提升到生产环境——变体代码是在原型约束下写的无测试、最小错误处理。折入正式代码时应当按正式标准重写。这四条与 SKILL.md 的通用规则互相呼应prototype 是从第一天起就可抛弃的无测试、无超出可运行所需之外的错误处理、无抽象、默认无持久化状态只存内存持久化恰恰是原型要检验的东西而不是它依赖的东西。六、在整套 skills 中的位置与上下文从仓库层面看prototype位于 skills/engineering/ 的Model-invoked模型自动调用分组即模型或用户都能触发Agent 在任务匹配时会自动拾取。其 frontmatter 与agents/openai.yamlinterface.display_name: Prototype共同构成 Agent 可检索的元数据。上下游关系依据 docs/engineering/prototype.md 整理上游/并行的邻居可 grill 的问题交给grill-me/grill-with-docsgrill 不动的不可谈问题比如屏幕长什么样才落到原型产出的一句话答案再回填到对话中。最大消费者wayfinder的地图由决策 ticket 组成prototype是四类 ticket 之一——当阻塞性问题是这看起来/动起来应该是什么样且讨论无法解决时使用。原型 ticket 由答案解决原型本身作为 asset 挂在地图上。下游验证过的状态模型或 UI 方向成为to-spec的已定稿输入可以内联原型产出的决策片段而不是用散文描述。运行方式原型应尽量在独立会话/独立目录中运行避免污染提出问题的线程上下文只把答案带回handoff 是双向桥梁。七、判定工作正常的验收信号Its working if结合 docs/engineering/prototype.md 的验收清单UI 分支做对了的标志是你能用一句话说清这个原型要回答什么问题UI 变体在布局与信息层级上分歧而不只是颜色与文案你收到的反馈是B 的 header 配 C 的 sidebar这种结构级意见问题一次性得到回答——如果一天后还在搭原型说明问题太大需要拆分收尾时main 里只有决策、没有任何原型代码实现 issue 上留了指向保留原型分支的上下文指针context pointer。参考路径UI 原型主文档本文主体prototype skill 总入口双分支路由与通用规则逻辑分支单文件可分享 demo原型 skill 的完整说明文档工程 skills 索引Model-invoked 分组仓库 README 中的安装与使用说明【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 基于 skills 仓库的 UI Prototype 实战指南：单路由多变体切换与浮动切换栏实现
基于 skills 仓库的 UI Prototype 实战指南单路由多变体切换与浮动切换栏实现【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills导读本文围绕开源仓库 GitHub_Trending/skills13/skills 中prototypeskill 的 UI 分支UI.md展开系统讲解如何在单个路由上生成若干结构截然不同的 UI 变体、用?variant搜索参数与浮动底部切换栏floating bottom bar让用户在浏览器里来回对比、挑选甚至偷取不同变体的局部设计然后只把胜出者合入真实代码。读完本文你将掌握两种子形态Sub-shape A / Sub-shape B的选型标准、六步落地流程、键盘/路由交互约定、生产环境隐藏策略以及该 skill 在整套工程技能中的定位与边界。一、UI Prototype 是什么在哪个分支干活在 prototype/SKILL.md 中prototype是一条**由模型自动调用model-invoked**的工程 skill定位是为回答一个设计问题而写的、用完即弃的代码throwaway code that answers a question。SKILL.md 的 frontmatter 明确说明它的适用时机Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.skill 内部按问题类型分成两个分支详见 skills/engineering/README.md 对 prototype 的描述这套逻辑 / 状态模型手感对吗→ 走 LOGIC.md产出一个单一自包含 HTML 文件含自由点击按钮与分标签的引导式演练让非开发人员也能亲手推动状态机。这个东西看起来应该是什么样→ 走本文主角 UI.md在单条路由上生成若干结构上完全不同的 UI 变体用 URL 搜索参数加浮动底部栏在浏览器中切换。分支选错会浪费整个原型因为两者产出的工件差异极大。一个实用的默认判断问题是关于逻辑/状态而不是外观就走 LOGIC.md问题是某个页面该长什么样就走 UI.md。SKILL.md 还给了补充规则如果问题确实模糊且用户不在场就依据周边代码猜——后端模块偏向逻辑分支页面/组件偏向 UI 分支并在原型顶部写明该假设。二、什么时候该用这个形态When this is the right shapeUI.md 给出的典型触发场景非常直白这个页面应该长什么样我想在拍板之前先看几个 dashboard 的候选方案。给设置页试一种不同的布局。任何用户原本要花一整天在脑子里比较三张模糊线框图的时刻。它对应的是 docs/engineering/prototype.md 里那句判断你遇到一个靠谈话无法拍板的问题——比如一个无法在脑中完整推演的屏幕设计需要同时看到三个版本并排对比。当 grilling 类会话如 grill-me、grill-with-docs在这些问题上不断膨胀时agent 换个说法、你继续猜、范围越滚越大正确动作是停止 grilling去构建一个一次性版本看一眼然后用一句话回答。反之如果问题已经讨论清楚、只是要按规格落地实现则应按 to-spec / implement 的流程走而不是原型。三、两种子形态优先选择 Sub-shape AUI 原型最容易评判的时刻是它贴住应用其余部分的时候真实的 header、真实的 sidebar、真实的数据、真实的密度density。一条孤立的临时路由是真空——每个变体单独看都好看。因此 UI.md 给出默认策略只要存在一个合理的宿主页面就默认用 Sub-shape A。子形态 A对既有页面的调整首选路由已经存在变体渲染在同一条路由上由?variantURL 搜索参数门控。已有的数据获取、参数、鉴权全部保留只有渲染子树rendered subtree随变体切换。即便原型针对的页面还不存在但它天然属于某个页面内部dashboard 的新区块、设置页的新卡片、既有流程中的新步骤依然归为子形态 A——把变体挂载进宿主页面即可。从源码结构看这种做法的收益是零上下文丢失评审者看到的是变体在真实数据密度下的表现而不是一条与世隔绝的临时页面上孤零零的布局。子形态 B新页面最后的退路仅当被原型化的东西确实没有任何可嵌入的既有页面时才使用例如一个全新的顶级 surface或一段无法嵌进任何合理位置的流程创建一条临时路由throwaway route遵循项目既有的路由约定不要发明新的顶级结构。命名要让人一眼看出是原型路径或文件名中包含prototype字样。使用同样的?variant模式。提交到子形态 B 之前要自检真的没有任何既有页面可以承载它吗一条空路由会掩盖空路由才能暴露的设计问题——有内容的页面才会把问题逼出来。两个子形态下浮动底部栏的实现完全一致。四、六步落地流程Process第 1 步陈述问题并确定变体数量 N默认生成3 个变体超过 5 个就不再是截然不同而是噪音因此上限为5。随后用一行话写下计划放在原型所在位置或文件顶部注释里Three variants of the settings page, switchable via?variant, on the existing/settingsroute.这句话无论用户当下在不在场、要不要反驳都是有效的检查锚点。第 2 步生成结构上截然不同的变体为每个变体起草并逐条守住三条约束页面的目的与它能拿到的数据项目既有的组件库/样式体系TailwindCSS、shadcn、MUI、纯 CSSwhatever一个清晰的导出组件名例如VariantA、VariantB、VariantC。关键判据原文档反复强调变体必须在结构上不同——不同的布局、不同的信息层级information hierarchy、不同的主操作入口primary affordance而不是仅仅颜色不同。三个微调过的卡片网格不是 UI 原型是壁纸。如果两个草稿太相似就按明确禁止使用卡片网格的要求重做其中一个。第 3 步把它们接线到一起在路由上创建一个单一的切换器组件UI.md 给出的伪代码如下按项目框架适配// pseudo-code, adapt to the projects framework const variant searchParams.get(variant) ?? A; return ( {variant A VariantA {...data} /} {variant B VariantB {...data} /} {variant C VariantC {...data} /} PrototypeSwitcher variants{[A,B,C]} current{variant} / / );子形态 A既有页面所有数据获取保持在切换器之上只有渲染子树随变体变化子形态 B新页面临时路由挂在/prototype/name下挂载同一个切换器。这样?variant参数既是门控开关也是可分享、可刷新还原的状态来源——这正是后续评审与交接的基础。第 4 步构建浮动切换栏floating switcher一个位于屏幕底部居中的fixed定位小条包含三块左箭头循环切到上一个变体可回绕 wrap around变体标签显示当前变体 key若变体导出了名字一并显示例如B (Sidebar layout)右箭头循环切到下一个变体可回绕。行为约定可复用的检查清单关注点约定URL 同步点击箭头更新 URL 搜索参数用框架自带 routerNext 用router.replaceReact Router 用navigate等保证变体可分享、刷新后稳定键盘操作←/→方向键也能循环切换焦点豁免当input、textarea、[contenteditable]获得焦点时不得拦截方向键视觉区分与页面明显区分如高对比度胶囊、细微阴影让人一看就知道这不是被评审的设计本身生产隐藏以process.env.NODE_ENV ! production或等价检查门控防止原型误合并后把切换栏带给真实用户切换器应做成单一共享组件让两个子形态都能复用位置放在项目共享 UI 所在处。注意最后一行的用意一次意外的原型合并不该把切换栏发到用户端这是原型纪律的最后一道保险。第 5 步交接Hand it over把 URL连同各?variantkey交出去用户有空就翻一翻。原文档点出最有价值的反馈形态通常是——我想要 B 的 header 配 C 的 sidebar那才是用户真正想要的设计。也就是说变体不是用来单选的也可以被拆借。第 6 步捕获答案并清理胜出变体确定后捕获答案哪个变体、为什么按 prototype/SKILL.md 描述的方式捕获原型本身把胜出者合入真实代码其余内容放上一次性分支throwaway branch而非 main子形态 A把胜出者折入既有页面失败的变体和切换器从 main 移除子形态 B把胜出变体升级为真实路由临时路由和切换器从 main 移除。一个关键细节全套变体是一手来源primary source所以它落在一次性分支上而不是垃圾桶里——因为留在 main 分支上的变体组件和切换器会快速腐烂rot fast还会误导下一位读者。这与 docs/engineering/prototype.md 中原型不再是删掉而是作为 evidence 停在 main 之外的分支上的原则完全一致。五、反模式清单Anti-patternsUI.md 收尾处明确列出四条红线逐条展开变体只在颜色或文案上不同——那是微调tweak不是原型真正的变体必须在外观结构上互相矛盾。变体之间共享过多代码——共享一个Header没问题共享一个Layout就违背了初衷。每个变体都应能自由地抛弃布局。把变体接到真实的写操作mutations上——只读原型是没问题的如果某个变体需要写数据就指向一个 stub。要回答的问题是这应该长什么样而不是后端能不能跑。直接把原型提升到生产环境——变体代码是在原型约束下写的无测试、最小错误处理。折入正式代码时应当按正式标准重写。这四条与 SKILL.md 的通用规则互相呼应prototype 是从第一天起就可抛弃的无测试、无超出可运行所需之外的错误处理、无抽象、默认无持久化状态只存内存持久化恰恰是原型要检验的东西而不是它依赖的东西。六、在整套 skills 中的位置与上下文从仓库层面看prototype位于 skills/engineering/ 的Model-invoked模型自动调用分组即模型或用户都能触发Agent 在任务匹配时会自动拾取。其 frontmatter 与agents/openai.yamlinterface.display_name: Prototype共同构成 Agent 可检索的元数据。上下游关系依据 docs/engineering/prototype.md 整理上游/并行的邻居可 grill 的问题交给grill-me/grill-with-docsgrill 不动的不可谈问题比如屏幕长什么样才落到原型产出的一句话答案再回填到对话中。最大消费者wayfinder的地图由决策 ticket 组成prototype是四类 ticket 之一——当阻塞性问题是这看起来/动起来应该是什么样且讨论无法解决时使用。原型 ticket 由答案解决原型本身作为 asset 挂在地图上。下游验证过的状态模型或 UI 方向成为to-spec的已定稿输入可以内联原型产出的决策片段而不是用散文描述。运行方式原型应尽量在独立会话/独立目录中运行避免污染提出问题的线程上下文只把答案带回handoff 是双向桥梁。七、判定工作正常的验收信号Its working if结合 docs/engineering/prototype.md 的验收清单UI 分支做对了的标志是你能用一句话说清这个原型要回答什么问题UI 变体在布局与信息层级上分歧而不只是颜色与文案你收到的反馈是B 的 header 配 C 的 sidebar这种结构级意见问题一次性得到回答——如果一天后还在搭原型说明问题太大需要拆分收尾时main 里只有决策、没有任何原型代码实现 issue 上留了指向保留原型分支的上下文指针context pointer。参考路径UI 原型主文档本文主体prototype skill 总入口双分支路由与通用规则逻辑分支单文件可分享 demo原型 skill 的完整说明文档工程 skills 索引Model-invoked 分组仓库 README 中的安装与使用说明【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考