用途
RYUX Analyze 用来回答“这个界面里究竟有什么”。它分析一个已有的设计，让后续的构建、扩展、重设计或评审决策从事实出发。它不是截图转代码，也不评判设计好坏；质量判断由 ryux-critique 负责。连接 ryux MCP 时，可用 search_screens、get_local_pattern 引用可比的印尼界面来佐证所命名的模式。
适用时机
- 在修改或扩展一个并非自己设计的产品之前。
- 被要求分析、逆向工程、记录或学习某个设计或竞品时。
- 把现有设计转成 Build 可以遵循的 DESIGN.md 时。
使用方式
1. 采集设计
按来源选择采集方式：
- Figma 链接（figma.com/design/<fileKey>/...?node-id=1-2）：用 Figma MCP 的 get_screenshot（把 1-2 转为 1:2）取图像；get_metadata 取框架树；get_design_context 和 get_variable_defs 取文本、组件和变量（测量值）。如果不可用，则请求帧的 PNG 导出，或请求连接 Figma MCP。
- pen.dev 设计：用 pencil MCP 的 get_app_state 列出帧；使用 TakeScreenshot([frameId]) 取图像；用 Get visitor 打印文本节点、节点属性（字体、尺寸、填充、间距）以及 ctx.problems（被裁剪内容）。如果不可用，则请求导出的 PNG。
- 网站 URL：运行 npx playwright screenshot --full-page --viewport-size=1440,900 <url> desktop.png，以及 --viewport-size=390,844 的移动端截图；有浏览器工具时用它获取交互状态（悬停、聚焦、错误）；获取页面 HTML 和 CSS，用于标题、标签、alt 文本、地标和声明值。如果不可用，则请求桌面和移动宽度的截图。
- 截图或图片：直接读取图像。
- 仅代码：先渲染（参见 ryux-visual-qa）；若无法渲染，则基于代码工作并说明未渲染。
分析过程保持只读：不要编辑 Figma 文件、pen.dev 文档或站点。记录采集内容：帧或 URL、视口和所用工具。
2. 标注每条观察
- 测量：从源读取，如 Figma 变量、CSS、pen.dev 节点属性（例：来自 CSS 的 body 16px / 24px）。
- 观察：在截图中清晰可见但未测量（例：1440 下为两栏布局）。
- 推断：合理猜测（例：可能是 8px 间距尺度）。
绝不把推断值当作测量值呈现。只有截图时，大多数值属于观察或推断，需明确说明。
3. 盘点
覆盖截图所示内容，跳过未显示的内容并说明其不可见。
- 结构：页面与区块、容器与最大宽度、网格（列、槽宽）、导航模型与深度、内容层级（视线顺序、主操作）。
- 视觉：字体（字族、字号与字重尺度、行高）、间距尺度及断裂处、颜色角色（表面、文本、强调、状态，有测量值时给出）、圆角、边框、阴影、密度、对齐。
- 组件：所见每个组件（按钮、输入、选择、表格、卡片、模态、标签页、导航等）、其变体、所见状态（默认、悬停、聚焦、禁用、错误、加载）。
- 行为：交互与反馈、加载/错误/空状态、确认与撤销、响应式行为（仅在采集了多个宽度时）。
- 设计语言：用 3 到 5 个特征概括视觉语言，每个都绑定证据；组件模式；间距与字体系统；交互模式。
同时记录内容与语气（自然印尼语或翻译、金额与日期的写法）和本地模式（QRIS、虚拟账户、OTP、地址、先买后付、e-KYC）。
4. 模式与证据
命名反复出现的模式及其出现位置。连接 ryux MCP 时，按 screen_id 引用可比的印尼界面；未连接时，说明模式仅来自本设计。
5. 报告
输出结构化而非散文式报告，作为 ryux-critique 和 DESIGN.md 的输入。报告模板包含：
- 上下文（来源、视口、采集工具、不可见内容、假设）
- 布局（容器、网格、间距、密度、对齐）
- 字体（字体、尺度、层级）
- 视觉（颜色角色、圆角/边框/阴影）
- 组件（主次组件、所见状态）
- 交互（导航、操作、状态、反馈）
- 设计语言
- 检测到的模式
- 证据（每条带标签与来源，使用的 RYUX Knowledge screen_id）
- 待解问题
6. 可选：DESIGN.md 草稿
当下一步是 Build 时，把盘点转成简短的 DESIGN.md：令牌（颜色角色、字体尺度、间距、圆角）、原则（设计语言特征）和模式，每项带来源与置信度。推断值保持标注，供构建者确认。
限制与注意事项
- 分析时不要编辑源文件。
- 不要把从截图生成代码当作分析。
- 不要评判好或坏；列出待解问题并交给 ryux-critique。
- 不要用典型值填补空白并当作已发现的事实呈现。
适用场景
适用于设计交接前的现状梳理、竞品界面拆解、已有产品改造前的基线记录，以及为构建阶段准备设计说明文档。该工具侧重描述与记录，不负责质量评审或代码生成。