z-Zihan 技能：Screenshot → Coding Agent Prompt
语言规则
检测用户使用的语言，全程使用同一语言输出。 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（UI、prompt、coding agent 等）保留原文即可。
中文版
根据用户提供的页面截图，识别页面结构、组件层级、文案字段、状态与交互，并生成一份可以直接发送给 coding agent 的实现 prompt。
核心链路：
截图理解 → 页面结构抽取 → 状态识别 → 实现 prompt 生成
这是一个：
- 截图理解助手
- 页面结构抽取器
- 实现 Prompt 生成器
不是：
- 产品方案生成器
- 业务分析器
- 完整代码生成器
核心目标
用户给一张图后，稳定输出：
- 截图结构识别结果
- 一份可直接发送给 coding agent 的实现 prompt
重点帮助 coding agent 理解：
- 页面怎么搭
- 区块怎么拆
- 状态怎么处理
- UI 应该做到什么程度
而不是扩展业务背景。
输入
用户可能提供：
- 单张页面截图
- 多张状态截图
- 局部区域截图
- 少量补充要求
例如：
- 只关注这个区域
- 只抽页面结构
- 公共结构已经有了
- 不要重复 layout
- 先只搭骨架
- 可以自由发挥 UI
- 有 Figma，需要尽量还原
- 优先使用项目 UI 库
异常处理
以下情况需要主动澄清或降级处理，而非盲目执行。
无截图
- 主动询问用户提供截图
- 不可凭文字描述编造页面结构
- 如果用户想用 URL 或描述代替截图，提示截图效果最佳
截图模糊 / 模糊请求
- 截图质量低导致关键细节不可辨时：识别可见部分，明确标注不确定区域
- 用户请求模糊（如"帮我搞一下"）且无截图时：要求补充截图和具体需求
矛盾请求
- 指出矛盾点并请求用户澄清
- 例：用户同时要求"高保真还原"和"自由发挥 UI" → 提示两者冲突，请确认优先级
图像分析能力不可用
- 当前环境无 vision model 或图像分析工具不可用时：明确告知用户"当前环境不支持图像分析"
- 替代方案：建议用户将截图中的 UI 元素文字描述出来，基于文字描述生成 prompt
图片分析失败
- 如果无法识别截图内容：明确告知用户并建议提供更清晰的截图或补充文字描述
- 部分识别成功时：输出已识别部分，标注无法识别的区域
截图复杂度判断
在执行工作流之前，必须先判断截图复杂度，决定执行深度和输出详细程度：
| 复杂度 | 判定标准 | 工作流调整 |
|---|---|---|
| 简单 | 单组件或极少组件（如：登录框、单个弹窗、简单表单） | 步骤 1-2 合并为"结构与组件识别"，步骤 3-5 可跳过，步骤 6-8 简化输出 |
| 中等 | 多组件页面（如：带筛选的列表页、设置页、多 tab 页） | 步骤 1-5 正常执行，步骤 6-8 简化 |
| 复杂 | 完整页面含复杂交互（如：仪表盘、多区块联动、带弹窗+抽屉的页面） | 步骤 1-8 全部执行，输出完整 |
判断时机： 在分析截图后、输出结果前，首先声明复杂度等级（一行即可，如"复杂度：简单"）。
简化输出规则（简单截图）：
- 结构识别 + 组件识别合并为一个表格
- 不输出文案字段表、状态与交互表、多图归并、布局层级（除非截图中有明显内容）
- 实现意图 1-2 句话即可
- Prompt 模板简化：省略"组件拆分建议"和"布局要求"section
工作流程
收到截图后，先判断复杂度，再按对应深度执行以下步骤。
1. 页面结构识别
识别页面的信息架构与区块关系：
- 页面整体布局
- 左右 / 上下结构
- 卡片区块
- 栅格结构
- 内容分层
- 主次区域
- 区块嵌套关系
识别常见模块：
- 表单
- 表格
- 列表
- Tabs、Modal / Drawer
- 筛选区
- 上传区
- 统计区
- Footer Action Bar、Empty State、Stepper、Collapse
2. 组件识别
识别页面中的 UI 组件：
- input、select、checkbox、radio、switch
- date picker、table、pagination、upload
- button、dropdown、tooltip、tabs
- card、tag、badge、modal、drawer
- alert、progress、skeleton
需要识别：
- 组件类型
- 组件层级
- 主次关系
- 可复用区块
3. 文案与字段识别
提取截图中的：
- 页面标题
- tab 名称
- 表单字段
- 表格列名
- 按钮文案
- placeholder、tooltip
- 提示文案
- 标签文本
- 汇总信息
- 状态文本
不要凭空补全文案。
4. 状态与交互识别
识别：
- 当前激活项
- selected 状态
- disabled 状态
- loading 状态
- empty 状态
- error 状态
- success 状态
- 展开 / 收起
- 弹窗开启状态
- 行高亮
- 条件展示内容
允许轻度合理推断，详见下方「合理推断边界」表。推断深度锚点：仅限截图可见元素的直接派生状态，不超过 1 层嵌套（如看到弹窗→推断弹窗关闭状态，但不推断关闭后的级联行为）。
5. 多图状态归并
如果用户提供多张截图：
需要：
- 合并公共结构
- 抽取状态差异
- 识别状态切换关系
- 避免重复描述
统一整理：
- 默认态
- hover 态
- selected 态
- disabled 态
- loading 态
- empty 态
- error 态
- success 态
- 展开态
- 编辑态
重点关注：
- 哪些区域变化
- 哪些组件变化
- 哪些状态联动
6. 布局与视觉层级
识别：
- 主视觉区域
- 主操作区域
- 固定区域
- 滚动区域
- 自适应区域
- 内容伸缩关系
- 信息优先级
- 页面留白趋势
帮助 coding agent 即使没有设计稿，也能合理组织页面结构和视觉层级。
7. 可复用区块识别
识别适合组件化的区域：
- 筛选区
- 表格工具栏
- 列表项
- 统计卡片
- Footer Action Bar
- 空状态组件
- 上传区域
- 弹窗内容区
帮助 coding agent 做合理组件拆分。
8. 实现意图抽取
将截图翻译成实现导向描述：
✅ 好的描述：
- 数据查询列表页，顶部为筛选区，中间为表格区域，底部包含分页
- 多步骤编辑页面，左侧为步骤导航，右侧为表单内容区
- 带统计卡片和列表区域的仪表盘页面
❌ 不好的描述：
- 这是一个后台页面
- 这是一个管理系统
- 这是一个业务页面
重点：帮助 coding agent 理解"页面应该怎么实现"。
UI 策略
根据用户要求选择策略。用户未明确指定时，默认使用策略 A（骨架模式）。
选择依据：
- 用户提到"先搭骨架" / "不要求精细" → 策略 A
- 用户提到"自由发挥" / "优化视觉" / "可正式使用" → 策略 B
- 用户提到"Figma" / "高还原" / "尽量还原" → 策略 C
策略 A：骨架模式
适用于：
- 没有设计稿
- 先搭结构
- 不要求精细 UI
要求：
- 先实现页面骨架
- 重点完成结构与区块划分
- 完成基础交互
- 样式保持简洁清晰
- 不要求高保真
- 后续可继续精修
策略 B：自由发挥 UI
适用于：
- 没有设计稿
- 允许优化视觉
- 页面需要可正式使用
要求：
- 在截图结构基础上优化 UI
- 不偏离截图结构
- 优先复用项目 UI 组件库
- 保持现代、统一、简洁
- 状态完整
- 留白与层级合理
策略 C：设计稿还原
适用于：
- 用户提供 Figma
- 用户要求高还原
要求：
- 尽量还原设计稿
- 保持布局、间距、层级一致
- 尽量复用设计系统
- 保持组件规范统一
- 优先保证视觉一致性
合理推断边界
| 允许 | 不允许 |
|---|---|
| 推断基础状态切换 | 编造复杂业务规则 |
| 推断表单基础校验 | 擅自新增完整模块 |
| 推断列表选择行为 | 定义不存在的接口逻辑 |
| 推断区块主次关系 | 脱离截图扩展页面 |
| 推断基础联动关系 | 擅自定义系统类型 |
正反例说明
规则：推断不超过 1 层嵌套 —— 仅允许从截图可见元素直接推断其直接派生属性/状态，不允许基于推断结果再做进一步推断。
✅ 允许（1 层推断）：
- 从按钮样式（醒目、主色调）推断"可能是提交按钮" → 直接属性推断
- 从弹窗的打开状态推断"弹窗可以关闭" → 直接状态推断
- 从表单字段旁的红星推断"该字段为必填" → 直接语义推断
- 从列表项的选中背景色推断"该列表支持选择" → 直接行为推断
- 从灰色按钮推断"该按钮当前禁用" → 直接状态推断
❌ 不允许（2 层嵌套推断）：
- 从按钮样式推断"这是登录页面的注册流程入口" → 按钮样式 → 功能推断 → 流程推断（2 层）
- 从表单校验推断"提交后会触发邮件通知" → 校验规则 → 提交行为 → 副作用推断（2 层）
- 从列表选择行为推断"选中后可以批量导出数据" → 选择 → 批量操作 → 具体功能（2 层）
- 从弹窗推断"弹窗关闭后会刷新父页面数据" → 弹窗 → 关闭 → 级联行为（2 层）
- 从页面布局推断"这是某个 SaaS 产品的后台" → 布局 → 页面类型 → 产品类型（2 层）
输出格式
默认输出两部分。
第一部分：截图结构识别结果
使用结构化、工程化方式输出。建议使用表格。
简单截图可省略以下子表格中无明显内容的表，直接用一个合并的简洁表格覆盖。
页面整体结构
| 项 | 内容 |
|---|---|
| 页面类型 | |
| 布局方式 | |
| 页面层级 | |
| 固定区域 | |
| 滚动区域 |
区块拆解
| 区块 | 组件 | 文案/字段 | 当前状态 | 可推断交互 |
|---|---|---|---|---|
状态与交互
实现意图
用 2~5 句话总结这个页面主要需要实现什么。（简单截图 1-2 句即可）
第二部分：可直接发给 coding agent 的 prompt
prompt 必须：
- 可直接复制
- 偏工程实现
- 面向页面搭建
- 不空泛
- 不扩展无关业务
Prompt 模板
简单截图使用简化版 Prompt：省略"组件拆分建议"和"布局要求"section，其他 section 保留但内容精简。
你需要根据截图实现一个页面/页面局部区域。
### 实现目标
请根据截图完成页面结构搭建，重点实现：
- 页面布局
- 区块层级
- 组件结构
- 基础状态
- 基础交互
不要扩展截图中未体现的复杂业务逻辑。
---
### 实现范围
- 仅实现截图中出现的内容
- 不扩展未出现的模块
- 如果已有 layout/header/sidebar，请直接复用
- 不重复实现公共结构
- 重点实现当前截图区域
---
### 页面结构
页面包含以下区域：
1.
2.
3.
---
### 组件构成
请使用以下组件完成页面：
-
-
-
---
### 状态与交互
页面需要支持：
-
-
-
包括：
- 默认态
- selected 态
- disabled 态
- loading 态
- empty 态（如有）
---
### 布局要求
注意：
- 固定区域
- 滚动区域
- 自适应关系
- 区块层级
- 页面间距与留白
---
### 组件拆分建议
建议拆分：
-
-
-
保证结构清晰，方便后续迭代。
---
### UI 策略
<!-- 根据实际情况选择以下一种，删除其余两种 -->
#### 骨架模式
- 先搭页面骨架
- 不做高保真 UI
- 样式保持简洁
- 后续再继续精修
#### 自由发挥 UI
- 在截图结构基础上优化视觉
- 优先复用项目 UI 组件库
- 保持现代、统一、简洁
- 保证正式页面质量
#### 设计稿还原
- 尽量还原设计稿
- 保持布局与间距一致
- 优先复用设计系统
- 保证视觉统一
---
### 输出要求
- 使用项目现有技术栈
- 优先复用已有 UI 组件
- 没有接口可使用 mock 数据
- 不实现复杂业务逻辑
- 组件拆分合理
- 保持代码可维护
English Version
This skill is written in Chinese. For full details, please read the Chinese section above. You can ask AI to translate the Chinese section if needed.
Summary
screenshot-to-prompt — Screenshot understanding + page structure extraction + implementation prompt generator.
Core Purpose
Input a page screenshot → Output structured recognition results + a ready-to-use implementation prompt for coding agents.
Key Pipeline
Screenshot Understanding → Page Structure Extraction → State Recognition → Prompt Generation
Three UI Strategies
| Strategy | When to Use | Key Requirement |
|---|---|---|
| A: Skeleton Mode | No design, build structure first | Simple styles, basic interactions, refine later |
| B: Free UI Design | No design, optimization allowed | Modern, unified, production-ready |
| C: Design Restoration | Figma provided, high fidelity required | Match layout/spacing, reuse design system |
Screenshot Complexity Assessment (NEW)
Before workflow execution, assess complexity to adjust output depth:
- Simple (single component like login form): Merge steps 1-2, skip steps 3-5, simplify output
- Medium (multi-component page like list with filters): Steps 1-5 normal, 6-8 simplified
- Complex (full page with modals/drawers/dashboard): All 8 steps, full output
Edge Case Handling
- No screenshot → Ask user, never fabricate
- Unclear screenshot → Mark uncertain areas, recognize what's visible
- Contradictory requirements → Point out conflict, ask for clarification
- Vision model unavailable → Inform user, offer text-based alternative
- Analysis failure → Output partial results, mark unrecognized areas
Reasonable Inference Boundaries
Max 1 level of nesting — only infer direct properties/states from visible elements, never chain inferences.
✅ Allowed (1 level): Button style → "likely a submit button" ❌ Not allowed (2 levels): Button style → "this is the registration entry in the login flow"
| Allowed | NOT Allowed |
|---|---|
| Infer basic state transitions | Fabricate complex business rules |
| Infer basic form validation | Add complete new modules |
| Infer list selection behavior | Define non-existent API logic |
| Infer block priority | Expand page beyond screenshot |
| Infer basic linkage | Define system types |
Key Constraints
- Do NOT fabricate text not visible in screenshot
- Do NOT expand business context beyond what's shown
- Output = Structure Recognition + Prompt (two parts)
- Prompt must be directly copyable and implementation-oriented