# Canvas Design To Web

> 基于用户提供的设计稿图片还原真实网页。该 skill 可用于任意前端项目，但强依赖本地已启动且已授权的 JarvisHub vision 工作流；视觉模型由服务端默认配置决定，支持外部传入 vision prompt，且不可静默降级。

- Skill: `lyl1015/canvas-design-to-web` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lyl1015/canvas-design-to-web`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lyl1015/canvas-design-to-web/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: lyl1015 (https://skillmd.com/u/lyl1015)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lyl1015/canvas-design-to-web

---


# JarvisHub Design To Web

## 目标

- 把用户提供的设计稿图片还原成仓库内真实可运行的网页，而不是只产出静态描述。
- 优先追求接近设计稿的视觉完成度，同时保持实现符合当前仓库技术栈与模块边界。
- 单一路径执行：设计稿取证 -> 结构拆解 -> 代码实现 -> 对稿修正。
- 在 JarvisHub `webHero` 画布流程中，只生成 HTML/CSS，并通过 readiness -> 两字段 stage -> commit 提交；`webHeroDocumentHtml` 必须由服务端派生，不能写进 text node 或 generic node patch。

## 强约束

- 本 skill 强依赖本地已启动的 JarvisHub vision 工作流。
- 视觉模型由服务端默认配置决定，调用方不要在工具参数里传任何未暴露的模型 / 厂商选择字段。
- 假定当前环境具备白名单调用权限；若无权限，必须直接报错。
- 必须先做视觉取证，再动代码；禁止凭主观印象直接开写。
- 若代码生成依赖画布里的已批准预览图，必须先用 `canvas_read_node_media_for_context` 读取这些预览图，让模型真实看到图片后再写最终代码。
- 每张已批准预览图都必须对应最终 DOM 中一个真实 `<section>`；CSS/JS 引用的 section id 必须存在于 DOM 中。
- 本地 vision 工作流不可用、超时、返回空结果、资源不可达或证据不足时，必须显式报错并说明卡在哪一步。
- 禁止静默降级到其他模型、默认视觉方案、硬编码模板或“差不多”的通用 landing page。
- 只能使用用户本轮明确提供的设计稿路径、当前真实代码、当前项目状态和工具返回结果作为依据。

## 何时使用

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

## 必要输入

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

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

## 视觉取证步骤

### 1. 收集输入事实

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

### 2. 调用图像理解

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

建议分析维度：

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

调用时默认要求：

- 视觉模型由服务端默认配置决定；**不要**在工具参数里传任何未暴露的模型 / 厂商选择字段，传入会被拒。
- 若当前 schema 支持温度参数，保持低值。
- 若调用方提供外部 vision prompt，则直接透传该 prompt
- 若未提供外部 vision prompt，才使用本 skill 内置的结构化分析提示
- 若外部 prompt 与要求的输出结构冲突，必须显式报冲突，不能自己猜着改
- 输出必须是结构化结果，至少包含：
  - `layout`
  - `designTokens`
  - `components`
  - `visualHierarchy`
  - `motionHints`
  - `uncertainties`

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

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

## 实现步骤

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

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

- 页面拆成哪些组件
- JarvisHub `webHero` 目标节点 id，以及最终要写入的 `webHero*` 字段
- 哪些 token 放在页面级样式，哪些放在复用样式
- 哪些视觉效果要用纯 CSS，哪些需要少量交互动效
- 哪些地方必须做响应式重排

坚持单一职责：

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

### 4. 在仓库中落地

- 优先改真实页面，不要只生成示例文件。
- 若目标是 JarvisHub `webHero`，用 `canvas_create_webhero_node` 确保存在目标节点；先通过 `canvas_webhero_check_readiness`，再用稳定 session ID 只 stage HTML/CSS，最后调用 `canvas_webhero_code_commit`。若宿主是严格 JSON 的前端 WebHero runner，只把 HTML/CSS JSON 返回给宿主，由 runner 执行同一事务；任何路径都不得用 `canvas_update_node_data` 写最终代码。
- 遵守当前仓库技术栈：React + TypeScript + Mantine。
- 每个 JSX/TSX 标签都要带可读 `className`。
- 不新增 `any`，不写 `as any`。
- 如果现有文件已经过大，先拆分再实现。
- 如需补充图片资源，只能使用用户明确提供的设计稿或仓库已有合法资源；不能伪造未提供素材。

### 5. 对稿修正

至少做一次“设计稿 vs 页面实现”的回看，重点检查：

- 第一屏比例关系是否接近
- 标题与正文层级是否准确
- 卡片尺寸、圆角、间距是否统一
- 背景层次、渐变、阴影是否到位
- 响应式下是否仍保留设计核心气质

如果差异明显，继续修，不要在“已经能跑”时提前停止。

## 输出要求

对用户汇报时必须包含：

- 已修改的真实页面/组件
- 设计稿中哪些视觉特征已经落地
- 仍存在的差异与原因
- 是否完成构建/类型检查/静态验证

## 失败策略

- 本地 vision 工作流不可用、未授权或模型不可达：直接报错，说明调用失败，不做替代分析。
- `imageUrl` 资源不可读，例如供应商侧无法访问 `127.0.0.1` / 本机局域地址：直接按阻塞失败处理，不得把空结构当成功分析。
- 设计稿信息不足：列出缺失事实，例如“只有局部截图，无法判断整页结构”。
- 现有页面归属不明：先说明需要落到哪个入口，不能私自挑一个无关页面。
- 缺少关键素材：明确指出缺什么，不要用默认图、默认文案、默认插画填空。

## 推荐交付节奏

1. 先读图并输出结构化取证摘要。
2. 再说明准备改哪些页面和组件。
3. 然后直接实施代码改动。
4. 最后做一次显式 review：对照用户目标、设计稿、已改代码、验证结果，确认没有遗漏再结束。