mobbin-search

Mobbin 搜索

从 Mobbin 获取真实应用截图，并在回答用户的设计问题前进行视觉分析。

为什么需要这项技能

设计问题最好用具体参考案例来回答，而不是泛泛而谈。这项技能会将这些问题引导至 Mobbin 精选应用界面库，让回答以真实应用的实际做法为依据，而非既有假设。

工作流

1. 规划搜索

调用任何工具前，先确定以下内容：

• 查询词 — 使用用户自己的措辞，也可以扩大范围。切勿添加用户未提及的具体要求，否则会让结果偏向某种设计模式，错过这项技能的价值所在——多样性。例如，“登录界面”→ 搜索 login screen，而不是 login screen with username and password。deep 搜索模式本身就能处理复杂查询；不要过早拆分成多个搜索，也不要加入用户未要求的限制条件。
• 平台 — ios 或 web。根据上下文推断：
  • Next.js/React/Web 应用 → web
  • SwiftUI/React Native/移动应用 → ios
  • 不明确 → 搜索前询问用户。
• 数量上限 — 默认为 5。只有在用户要求更多样的结果或指定数量时，才提高上限（最多约 15）。

先不要决定是否创建看板——等看过搜索结果再说。

2. 先说明计划，再继续

用一行说明计划，然后在同一轮中调用 search_screens。说明计划是为了让双方对预期达成一致，不是征求许可——如果用户不同意，可以重新指定，但不要停下来等待批准。

示例：“正在搜索 20 个 iOS 登录界面。”

保持简洁。无需解释工具。

3. 调用 search_screens

这是用于查找设计参考的工具。它会在服务端执行搜索，获取每张匹配的图片，并以内嵌图片内容块的形式返回——无需下载、无需使用 Read，也无需输出 URL。你可以直接在工具结果中查看这些界面。

响应包含：

• 一个元数据文本块：{ screens: [{index, id, app_name, mobbin_url, image_url, platform}], failed: [...] }
• N 个图片块，与 metadata.screens 中的条目一一对应，顺序相同

index 字段用于将每张图片与其所属应用对应起来。image_url 是用于调试或健全性检查的参考信息，分析时无需使用。

4. 决定如何回应

看完这些屏幕后，根据用户的实际需求选择以下两种模式之一。所有观察都要以你实际看到的内容为依据——具体指出文案、元素数量、颜色和按钮标签。避免泛泛而谈的 UX 套话。

模式 A — 直接回答。 用户的问题很具体，答案只需简短说明和 1-3 个屏幕即可。直接回复。用户寻求灵感时，先展示屏幕；用户需要构建帮助时，提供具体的实现细节（间距、文案、布局）。每个屏幕用一行说明，并附上 Mobbin URL。

链接格式：

1. **N26** — Single-field login with biometric option. [View on Mobbin](https://mobbin.com/screens/...)

如果自然地可以接着问一句（如“想看更多结果吗？”“想深入了解其中哪一个吗？”），就将这句话放在消息的最后一行——参见下文的“问题置于最后”规则。

模式 B — 提议制作看板。 用户的需求适合深入探讨：从一批内容中提取模式、并排比较多个应用、逐步讲解某个流程，或浏览足够多的灵感屏幕。在开始制作之前，先询问用户想要什么。

提问应尽量简洁——让用户看到明确的建议和几个容易浏览的备选项，而不是令人难以抉择的平级选项菜单。结构如下：

1. 引言——一句简短的话。 用一个观察说明为何提出建议（例如：“这 15 个屏幕分为 3 种明显的方案。”）。不要列出发现、总结模式，也不要用项目符号描述你看到了什么。等用户选定后，再把这些内容放进看板。过早透露发现会掩盖问题，还会提前给出看板本应呈现的答案。

2. 选项使用简短的编号列表——恰好 3 项。 有选项时，编号列表比散文更容易浏览。

   1. 明确标记你的建议（**推荐** — ...），用通俗易懂的语言描述，并简要说明为何适合。
   2. “描述你自己的布局（以及要应用的任何样式指南或其他技能）。”
   3. “只要文字总结。”

   只能有 3 项——不要附加其他命名结构。如果用户有其他想法，可以在选项 2 下描述。

3. 问题置于最后。 最后一行必须是用户可以回答的实际问题（如“你想选哪一种？”或“这样可以吗？”）。后面不要再加任何内容。用户读到结尾时应该知道你正在等他回复。

语气应像顾问：提出一个明确的建议，并提供容易选择的备选项，而不是给出中立的菜单。

示例：

这 15 个登录屏幕分为 3 种明显的方案。

1. 推荐 — 按模式整理成看板，方便你并排浏览不同方案
2. 描述你自己的布局（以及要应用的任何样式指南或其他技能）
3. 只要文字总结

你想选哪一种？

等用户选择后再开始制作。

5. 构建看板

仅在用户选定结构后执行。

看板是主要成果；终端文本只是指引用户前往看板的路标。不要在终端中重复看板内容——这是需要避免的陷阱。

制作独立的静态 HTML 文件。无需框架、外部 CSS 或构建步骤。使用搜索响应中的 image_url，通过 <img src> 嵌入屏幕截图——Mobbin CDN URL 可直接使用，约一小时后过期，但用于即时查看没有问题。

根据用户选择的结构来组织看板。按模式分组 → 建立分区，每个分区下方排列缩略图。进行对比 → 为每个应用设置固定列，各列使用相同的行（文案、CTA、字段数量等）。展示流程 → 按流程顺序水平排列。展示平铺图 → 使用松散网格，包含应用名称和缩略图，尽量减少装饰。优先保证易读性，而非生搬硬套模板——根据查询调整布局。

如果用户指定了样式指南或提及其他技能（例如 design-principles），请遵循。

无论使用哪种结构：

• 默认使用浅色主题——页面采用干净的白色或米白色，搭配深色文字、低调的边框和分隔线。Agent 往往会过度使用深色主题，并选择难以辨认的配色（对比度低的灰色、浑浊的强调色）；浅色主题更容易驾驭，也能让截图成为视觉焦点。如果用户指定了主题或引用了设计系统，则按其要求调整。
• 让视觉元素传达含义，而不是依赖文字。 屏幕截图就是说明——界面装饰应尽量退居其次。优先使用视觉提示——分组、留白、统一的缩略图尺寸、低调的标签、颜色编码、直接标注在图像上的简易说明——而非段落或冗长的项目符号列表。分区标题和一句话说明没有问题；如果满屏都是项目符号，就说明你用文字取代了本该采用的布局。发现自己正在编写解释屏幕截图内容的列表时，试着将其改为视觉布局。
• 将每个屏幕截图链接回对应的 Mobbin URL，方便用户点击查看
• 在每个屏幕截图旁标注应用名称
• 可考虑支持点击放大（使用普通的 <a href> 链接，在新标签页中打开 image_url）

保存并打开。 写入 ./.mobbin/<slug>-<YYYYMMDD-HHMM>.html——路径相对于当前工作目录，而非 /tmp。Slug 应是对查询内容的简短易读描述（例如 ios-login-patterns、fintech-dashboards）。如果父目录不存在，请创建该目录。写入后在浏览器中打开（在 macOS 上使用 open <path>）。

然后只需在终端中简短说明：

• 用一句话概述主要发现
• 用 2–3 个项目符号列出关键要点
• 提供看板路径，并说明看板已在浏览器中打开

深入内容应体现在看板中；终端只是路标。

6. 处理“再多展示一些”的后续请求

如果用户想查看更多结果，请再次调用 search_screens——提高上限，或细化查询。该工具再次调用的成本很低；无需自行实现去重逻辑。