mcpField
S
seenry-apps

seenry-apps

github.com/ayangabryl设计与 UI219 次安装今天更新
代码仓库

关于 seenry-apps

面向 iOS、Android 和网页应用的移动端设计技能,涵盖研究、规格制定、原型制作和模拟器检查。它强调研究完整应用流程、塑造有辨识度的核心屏幕,并依据平台惯例检查连贯状态。

主要功能

  1. 01研究完整应用流程
  2. 02记录设计决策与模式
  3. 03探索核心屏幕设计方向
  4. 04遵循 iOS 与 Android 布局指引
  5. 05构建连贯的界面状态
  6. 06在模拟器中检查流程

适用场景

  1. 01设计移动应用引导流程
  2. 02跨移动平台制作应用原型
  3. 03检查导航与返回路径
  4. 04依据研究过的参考检查屏幕

MCP 相关

连接 Seenry MCP 后,可搜索应用流程、逐页检查并借鉴参考案例。未连接时,工作流会改为运行本地研究脚本。

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/ayangabryl/seenry-skills --skill seenry-apps

安装后在 Claude Code 中输入/seenry-apps确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
openai.yaml
references/
flows.md
research.md
scripts/
app_preflight.mjs
independent_flow_gate.py
review_schema.json

详细介绍

Seenry 应用

移动端质量主要取决于对平台特性的忠实还原,以及与 Web 系统一致的严谨规范:严格的网格、分层构建的组件、少量字号、一种强调色,以及对每种状态的设计。使用项目现有的技术栈和组件进行开发。

工作流

  1. 明确设计任务。 编写 research/brief.md:产品基于什么(流程)、应该呈现什么样子(视觉风格),以及招牌屏幕承担什么任务(差异化)。「基于 X,采用 Y 的设计」表示 X 提供流程,Y 提供视觉风格;指定一个应用则表示两者都取自该应用;没有指定则表示有意选择视觉风格。遵循 research。
  2. 研究真实应用,走完整旅程。 使用 Seenry MCP,按名称查找应用(search_app_flows {q: "<app>"}),并按顺序走完完整流程(get_app_flow,翻页直至结束)。对于你构建的任何流程,至少研究 3 个完整流程(基于的应用,加上同类最佳的领先应用;对于 Headspace、Duolingo、Calm 或 Noom 的新手引导);视觉风格应用至少研究 2–3 个流程中的 8 个屏幕;其他每种屏幕类型至少研究 10 个屏幕;并对差异化做一次 borrow_references。当研究趋于饱和、新屏幕不再改变规范时停止。应用屏幕带有小水印,请忽略。
  3. 先写规范,再写代码。 research/flows.md 记录每个流程的主线(每一步:询问什么、提供什么、如何呈现);.seenry/look.md 记录视觉风格应用的配色、字体、数字样式和具名招牌组件;research/patterns.md 区分基本要求、差异化和开场设计;research/decisions.md 列出每项决策及其来源屏幕 ID,以及导航图。每个新手引导屏幕都要采用视觉风格中的一个招牌组件,并填入本产品的内容。 借鉴招牌特色,不要照搬默认样式。 视觉风格应用的平台默认样式(系统蓝、白色分组表单、SF Pro、灰色行)不是它的视觉风格;每个应用都有这些默认样式。它的视觉风格体现在招牌组件及其背后的态度。产品应在此基础上建立自己的身份:从自身理念中提炼强调色(除非品牌本身拥有该颜色,否则绝不使用 iOS 蓝或靛蓝)、采用令人难忘的展示字体或数字样式,以及符合主题的色彩世界(睡眠产品应置身夜色)。如果只换个 Logo,屏幕看起来就像任何应用的新手引导,那就是敷衍,不管研究得多忠实。
  4. 使用 flows 绘制流程及其入口: 标明每个屏幕的呈现形式(推入、模态、表单页、替换)、从该屏幕返回时的行为,以及单向门(完成新手引导、登录、购买等)——这些地方按返回不能重新进入。新手引导每个屏幕只问一件事,并根据回答进行引导;在任何权限请求或付费墙出现之前,先以根据用户回答生成的成果作为回报。
  5. 探索招牌屏幕,然后盲选。 为流程所围绕的屏幕(通常是回报屏,欢迎屏也采用同一方向)设计三个方向,并分别保存为单独文件:一个采用常规控件,两个各自打破一种陈词滥调,一个基于借鉴的差异化。它们在视觉焦点上必须有所区别,而不只是布局不同。运行 node ../seenry/scripts/pick.mjs a.html b.html c.html --brief <brief> --refs <look app screens>,然后按胜出方向构建整个流程。
  6. 使用 四层构建方法 为每个组件制定规范: 网格 → 安全空间 → 结构 → 字体与状态。
  7. 使用真实数据构建完整的状态: 加载、空状态、错误、权限拒绝、离线、成功,以及键盘弹出时的布局。Web 原型以 <!doctype html>、<meta charset="utf-8"> 和 viewport meta 开头。
  8. 预检各项数量: node scripts/app_preflight.mjs <source> 会统计强调色的色相类别、灰色类别、圆角规格、UI 中的表情符号、渐变、字体系列、每种意图的标签数量、编码和文档头部。数量检查失败就要修复,不能靠主观判断决定是否接受;如果有意偏离视觉风格(例如 Flighty 的状态颜色),请在 decisions.md 中记录。
  9. 在模拟器上走完整流程并录制。 在 iOS Simulator(或 Android 模拟器)上端到端运行流程,包括 Web 原型:启动文件夹服务,启动已安装的 iPhone(xcrun simctl list devices available,然后 xcrun simctl boot <udid>;每个模拟器运行一次),xcrun simctl openurl booted http://127.0.0.1:<port>/,并用 xcrun simctl io booted screenshot NN-step.png 截取每一步的屏幕。390px 宽的桌面浏览器无法呈现 Safari 工具栏、安全区域、键盘或真实字体渲染效果。测试每一步、每条返回路径(箭头、边缘滑动、Android 返回键)、每个单向门之后的返回操作、表单页的拖动及拖动中途取消、键盘弹出和收起,以及一次性跳过所有步骤。录制流程(xcrun simctl io booted recordVideo rec.mov;Android 使用 adb shell screenrecord /sdcard/rec.mp4),并观看两遍:一遍正常播放,一遍逐帧检查是否出现主题闪烁、布局跳动或丢帧。
  10. 逐屏超越参考。 将每个自制屏幕与研究过的最佳对应屏幕并排比较。任何效果更差的屏幕都要回到迭代流程中。然后运行验收检查:node ../seenry/scripts/check.mjs --screens <screens in flow order> --video rec.mov --brief <brief>,并持续修复,直到通过或停止。在展示模式下,如果停止时的分数低于目标,就用步骤 5 中的另一个方向重新构建招牌屏幕和流程,并运行一次 check.mjs --new-direction 后再提交。默认使用 --mode quick(一轮评审,只应用一次修复);收到生产就绪要求时使用 --mode polish;只有用于展示作品时才使用 --mode showcase。在交付内容中报告分数和等级:通过(9)、领先水平(8),或低于领先水平并列出差距。如果没有 Seenry MCP,先运行 node ../seenry/scripts/research.mjs --type app,为评审提供基准。按照 seenry 的要求编写 .seenry/idea.md、.seenry/motion.md 和 DESIGN.md;验收检查会检查这些文件。
  11. 按照 seenry 的要求交付 Seenry 说明页(说明页):提供各状态的屏幕截图、研究过的应用和流程及其 ID、决策及其来源、招牌屏幕结构解析和设计指南。使用 sheet.py;对于 anatomy.mjs(仅适用于 Web)无法处理的模拟器屏幕截图,请手动添加注释。

平台系统

iOSAndroid(Material 3)
网格以 4pt 为基准,布局尺寸为 8 的倍数以 4dp 为基准,布局尺寸为 8 的倍数
屏幕边距16(大屏手机和内嵌分组列表中为 20)16(较大屏幕中为 24)
最小触控目标44×44 pt48×48 dp
导航栏44 + 大标题 52顶部应用栏 64
标签栏49 + 主屏幕指示条;3–5 个项目;图标 24–28 + 标签 10/500导航栏 80;3–5 个项目
列表行最小 44;带副标题或 40pt 图片时为 60–76单行 56,双行 72
分组列表内嵌 16,圆角 10–12,分隔线缩进至文本处卡片或全宽布局并带分隔线
按钮全宽主按钮,高 50,圆角 12–14 或胶囊形填充/色调按钮,高 40,圆角为全圆
表单中/大两档高度,带拖动指示条,系统圆角约 10底部表单,拖动手柄 32×4
字体SF Pro:Large Title 34、Title 1 28、Title 2 22、Title 3 20、Headline 17/600、Body 17、Callout 16、Subhead 15、Footnote 13、Caption 12/11Roboto/Flex:Display 57/45/36、Headline 32/28/24、Title 22/16/14、Body 16/14/12、Label 14/12/11

使用 Dynamic Type 文本样式(iOS)和带字体缩放的 sp(Android),不要使用固定字号。使用项目的设计令牌,或将 .seenry/look.md 中研究的视觉风格映射到系统语义角色(label、secondaryLabel、systemBackground),以支持深色模式和增强对比度;仅在两者都不存在时使用纯系统颜色。这些指标是平台的最低标准,而非风格要求:Web 原型应采用原生尺寸、触控目标和安全区域,而不是 iOS 默认样式。

屏幕规则

  • 每个屏幕只有一个主要操作,放在拇指容易触及的位置:固定在底部、位于主屏幕指示条上方的全宽按钮,或导航栏末端的“保存/完成”按钮。
  • 每个组件最多使用 3 种文本样式。 播放器卡片使用 Headline、Subhead 和 Caption;除此之外不使用其他样式。
  • 嵌套形状使用同心圆角(inner = outer − inset),iOS 使用连续圆角曲线(.continuous / squircle)。
  • 内容优先。 列表、媒体和记录应占据屏幕主体;摘要和标题保持紧凑。大标题在滚动时收起。
  • 优先使用原生控件,而非自定义控件:选择器、切换开关、分段控件、菜单、分享表单、日期选择器。自定义控件必须提供与原生控件相匹配的反馈(触觉反馈、按下状态)和无障碍支持。
  • 安全区域和键盘。 刘海、灵动岛、主屏幕指示条或键盘下方不得放置内容。主要按钮应随键盘上移。
  • 引导流程:每个屏幕展示一个想法,显示进度并提供跳过选项;首屏展示产品标志性视图;选择项采用大行布局;权限请求应在用户即将获得相应价值时,通过预先提示再提出。流程长度应遵循研究过的流程:个性化产品如果每个回答都能明显改变最终价值,可设置 8–15 个屏幕;没有可个性化内容的工具则设置 1–3 个。任何付费墙出现之前,先根据回答展示相应价值(flows)。
  • 付费墙:展示产品的实际功能(真实屏幕或功能);提供计划选项并预选推荐方案;在 CTA 正下方以纯文本标明每个周期的价格和试用条款;提供恢复购买和条款链接。
  • 设置:使用内嵌分组列表,每个分区包含 2–6 行;图标方块尺寸为 28–29、圆角为 6–7,且样式统一;数值靠右显示,使用 secondaryLabel;破坏性操作放在最后并单独分组。
  • 空状态和错误状态应显示在对应区域内,并提供一个可解决问题的操作。

对齐

相同的基准线、墨色层级和视觉对齐规则也适用于原生界面(alignment、optical):按照字形对齐 SF Symbols(使用 .imageScale,并与文本基线对齐;使用 alignmentGuide 对齐大写字母高度);图标 + 标签行使用 firstTextBaseline 对齐;通过 3x 截图检查播放/尖括号字形在圆形按钮中的居中情况。

动效

根据遇到的频率决定每种动效是否需要设计(参见 流程):标签页、滚动、返回和键盘使用平台自带的动效;按压反馈低于 150ms;精心设计的动效只用于少见时刻,例如新手引导中的惊喜时刻。导航动效遵循平台规范(推入、工作表、缩放)。自定义动效使用弹簧(response 0.35–0.5, dampingFraction 0.8–0.9),可中断,体感时长为 150–300ms,并在操作确认时提供触觉反馈(选择、成功、警告)。尊重“减少动态效果”设置。对于基于 Web 的应用,请使用 seenry-motion 和 Seenry Transitions 工具包。

Web 工具包提供的相同转场也适用于原生应用(根据具体情况主动应用):

情况SwiftUIJetpack ComposeReact Native
触发元素变成界面主体(菜单、卡片转详情)使用 matchedGeometryEffect 或 .navigationTransition(.zoom(sourceID:in:));关闭时回到触发元素所在位置SharedTransitionLayout + sharedBoundsReanimated 共享元素转场
工作表、对话框.sheet 配合 .presentationDetents;自定义:.spring(response: 0.4, dampingFraction: 0.86)ModalBottomSheet;spring(dampingRatio = 0.86f, stiffness = 400f)@gorhom/bottom-sheet,弹簧阻尼 20-24
数字变化在 withAnimation 中使用 .contentTransition(.numericText(value:))使用 AnimatedContent 逐位动画,并按方向滑动使用 Reanimated 按方向逐位执行 FadeIn/SlideIn
标签页、分段控件使用 matchedGeometryEffect 实现共享指示器使用 animateDpAsState 动画显示指示器偏移使用 Reanimated withSpring 动画指示器的 translateX
列表插入、移除、重排在稳定 ID 上使用 .transition(.move(edge:).combined(with: .opacity))Modifier.animateItem()LinearTransition / FadeIn 布局动画
按钮加载、成功、错误使用 .symbolEffect 和 .contentTransition(.symbolEffect(.replace));.sensoryFeedback使用 AnimatedContent 处理标签;HapticFeedback图标切换时缩放 0.9→1 并改变不透明度;expo-haptics
Toast、横幅从顶部安全区域边缘进入,使用弹簧效果;退出使用 120ms 缓出AnimatedVisibility(slideInVertically + fadeIn)Reanimated SlideInUp / FadeOut

退出动画要比进入动画快;列表中只对变换和不透明度做动画;每个自定义动画都必须提供“减少动态效果”方案(@Environment(\.accessibilityReduceMotion)、Settings.Global.ANIMATOR_DURATION_SCALE、AccessibilityInfo.isReduceMotionEnabled)。

避免应用设计俗套

表现改进
在应用中使用 Web 风格的居中主视觉屏幕采用内容优先的原生布局
带光晕、渐变或悬浮色块的自定义标签栏使用系统标签栏,或符合原生尺寸规范的简洁自定义标签栏
每一行都是独立的彩色渐变卡片使用分组内嵌列表
正文使用 12px 字号、固定字号使用动态字体样式,正文为 17pt
付费墙隐藏价格或试用条款在 CTA 下方注明每个周期的价格和相关条款
使用紫色渐变新手引导和现成的 3D 插图展示产品如何发挥作用
采用某个具名风格(“像 Flighty 一样”),却只用系统蓝色搭配分组列表呈现使用 .seenry/look.md 中的标志性组件,以及产品自身的强调色和色彩体系
每个问题都用相同的白色卡片、单选项和蓝色全宽按钮呈现将答案设计成产品自身的对象(例如板上的一个时间、逐渐填满的通行证),并根据答案类型采用不同的输入方式
照搬参考产品的平台默认样式,并称其为产品风格使用参考产品的标志性组件和设计态度;默认样式不等于产品身份
Web 原型缺少 <meta charset="utf-8"> 和 viewport meta两者都放在 <head> 中;检查标点是否正常显示,布局是否适配 390pt
屏幕底边的按钮高度为 36pt高度设为 50pt,内缩 16,并放在主屏幕指示器上方

按流程完成

  • 已研究三个或更多完整流程和 8 个以上的 look-app 屏幕;对应 ID 位于 research/ 中;已为每个屏幕命名采用的模式
  • .seenry/look.md 已存在,其中的标志性组件已出现在包含此产品内容的构建中,且强调色和色彩风格属于产品自身,而非平台默认设置
  • 已构建标志性屏幕的三个方向,并使用 pick.mjs 盲选其一
  • 已编写导航图;已在每个屏幕上验证返回功能;单向入口无法重新进入
  • 引导流程以根据回答构建的成果结束;每项权限都有预先提示和温和的退出方式;行动号召按钮下方以纯文本展示付费墙条款
  • 已设计加载、空内容、错误、权限被拒和长内容状态,而非使用默认状态
  • app_preflight.mjs 已通过,或已在 decisions.md 中记录每项例外
  • 已在屏幕上验证浅色和深色模式、最大动态字体、安全区域和键盘
  • 已观看流程录制两遍,确认没有闪烁、跳帧或丢帧
  • 屏幕和录制内容是在 iOS Simulator(或模拟器)上截取的,而非桌面浏览器
  • 每个屏幕与研究过的最佳参考屏幕并排比较时都经得起检验;已按要求的模式运行 check.mjs,并报告分数和等级

审查

按顺序在设备或模拟器上截取整个流程的屏幕截图(浅色和深色模式、最大字号),并使用 seenry-review 或新的 Agent 进行审查。如果已安装 Codex CLI,可选的流程门禁会将按顺序排列的截图发送给新的视觉和流程审查员。静态截图无法证明手势、VoiceOver 或计算功能正常;请在设备上测试这些内容。

评论

支持 Markdown