tapcanvas-design-to-web

TapCanvas Design To Web

目标

• 把用户提供的设计稿图片还原成仓库内真实可运行的网页，而不是只产出静态描述。
• 优先追求接近设计稿的视觉完成度，同时保持实现符合当前仓库技术栈与模块边界。
• 单一路径执行：设计稿取证 -> 结构拆解 -> 代码实现 -> 对稿修正。

强约束

• 本 skill 强依赖本地已启动的 TapCanvas vision 工作流。
• 默认视觉模型是 gemini-3.1-flash-image-preview；除非用户显式指定其他 active model，否则不要私自改。
• 假定当前环境具备白名单调用权限；若无权限，必须直接报错。
• 必须先做视觉取证，再动代码；禁止凭主观印象直接开写。
• 本地 vision 工作流不可用、超时、返回空结果、资源不可达或证据不足时，必须显式报错并说明卡在哪一步。
• 禁止静默降级到其他模型、默认视觉方案、硬编码模板或“差不多”的通用 landing page。
• 只能使用用户本轮明确提供的设计稿路径、当前真实代码、当前项目状态和工具返回结果作为依据。

何时使用

• 用户说“根据这张设计稿还原页面”“把截图做成网页”“参考这张 UI 图实现页面”。
• 用户明确把设计稿图片放进仓库，例如 assets/，并要求还原为 React/Mantine 页面。
• 用户要求“接近 AI Studio 做出的网页质感”，本质上是在追求高保真视觉落地。

必要输入

• 至少一张设计稿图片路径。
• 明确目标页面或落地区域：新页面、现有路由、现有组件改造，或其他清晰的前端 surface。
• 明确还原标准：
  • 高保真还原
  • 保留风格但允许工程化调整
• 确认本次任务应通过本地 TapCanvas vision 工作流做视觉分析。
• 可选外部 vision prompt；若调用方提供，必须优先使用该 prompt，而不是静默改写。

缺少上述信息时，先指出缺失项，不要假设页面归属或交互细节。

视觉取证步骤

1. 收集输入事实

• 读取用户给出的设计稿路径。
• 确认要修改的页面入口、路由、组件或容器。
• 如果是现有页面改造，先读现有实现，确认哪些结构可以保留，哪些必须重写。

2. 调用图像理解

优先使用本地 TapCanvas vision 工作流，对设计稿做结构化取证。目标不是“看图讲故事”，而是提取可编码的界面事实。

建议分析维度：

• 页面结构：section 划分、主次层级、左右布局、卡片/列表/表单/导航的组合关系
• 视觉 token：主色、辅助色、背景层次、圆角、边框、阴影、模糊、间距节奏
• Typography：字号层级、字重、大标题风格、正文密度、按钮文字风格
• 组件清单：hero、navbar、feature cards、metric tiles、gallery、CTA、form、footer
• 装饰系统：渐变、光斑、噪点、网格、插画、mock device、浮层、标签
• 交互暗示：hover、选中态、滚动分段、粘性头部、入场动画线索

调用时默认要求：

• 默认 modelAlias="gemini-3.1-flash-image-preview"
• 温度保持低值，例如 0.2
• 若调用方提供外部 vision prompt，则直接透传该 prompt
• 若未提供外部 vision prompt，才使用本 skill 内置的结构化分析提示
• 若外部 prompt 与要求的输出结构冲突，必须显式报冲突，不能自己猜着改
• 输出必须是结构化结果，至少包含：
  • layout
  • designTokens
  • components
  • visualHierarchy
  • motionHints
  • uncertainties

如果设计稿有多个画板或多张图片：

• 先分别取证，再合并出统一 token 与组件契约。
• 对互相冲突的部分显式标注，不要自行拍板“平均化”。

实现步骤

3. 把取证结果转成代码计划

先形成一个简短实施计划，再开始改代码：

• 页面拆成哪些组件
• 哪些 token 放在页面级样式，哪些放在复用样式
• 哪些视觉效果要用纯 CSS，哪些需要少量交互动效
• 哪些地方必须做响应式重排

坚持单一职责：

• 页面容器负责整体结构
• 各 section 组件只负责自己的视图
• 视觉 token 与纯转换逻辑尽量抽成独立模块

4. 在仓库中落地

• 优先改真实页面，不要只生成示例文件。
• 遵守当前仓库技术栈：React + TypeScript + Mantine。
• 每个 JSX/TSX 标签都要带可读 className。
• 不新增 any，不写 as any。
• 如果现有文件已经过大，先拆分再实现。
• 如需补充图片资源，只能使用用户明确提供的设计稿或仓库已有合法资源；不能伪造未提供素材。