building-native-ui

building-native-ui 技能概览

building-native-ui 技能适合解决什么问题

building-native-ui skill 是一份非常实用的指南，专门帮助你打造精致、原生感强的 Expo Router 界面，而不是只做出“能跨平台运行”的 UI。它尤其适合你希望 AI agent 在 React Native 和 Expo 应用中替你做出具体 UI 决策的时候：比如路由结构、iOS 风格控件、headers、tabs、动画、媒体流程、视觉效果，以及符合平台习惯的交互模式。

谁适合安装它

这个 building-native-ui skill 最适合在 Expo 或 React Native 场景下工作的前端开发者，尤其是那些不满足于“通用组件代码”的团队。如果你们在做移动优先产品，并且导航、原生控件、动效和平台规范都很重要，这个技能会特别合适。若你已经在用 Expo Router，或者准备采用 Expo Router，它比一句宽泛的“帮我做个移动端 UI”提示要靠谱得多。

它真正帮你完成的工作

用户通常会在希望 agent 把一个粗略的产品想法，直接转成可落地的 UI 实现方案时安装 building-native-ui，而不是让模型自己猜 Expo 生态下该怎么做。它的核心价值不只是给几段示例代码，更在于减少你在 tabs、sheets、search、storage、media、icons、animations 和路由组织上的错误起步。

它和通用 UI 提示词最大的区别

building-native-ui 最强的差异点在于：它内置了 Expo 特定的偏好和约束，会主动把 agent 引导到这些方向上：

• Expo Router 的文件与 layout 约定
• 更有原生感的 iOS 控件和 SF Symbols
• 优先使用基于 Reanimated 的动效，而不是更老的动画方案
• 明确平台边界，例如什么时候 Expo Go 可用、什么时候必须 custom build
• 针对 tabs、search、media、gradients、zoom transitions 和视觉效果的聚焦参考资料

在采用前最需要知道的事

在你使用 building-native-ui for Frontend Development 之前，要先知道它是有明确倾向的。它更推崇原生交互模式，而不是通用跨平台 UI kit；更偏好 Expo 友好的 API；也会涉及一些带版本或平台限制的能力，比如仅限 iOS 的特性、New Architecture 要求，以及 SDK 版本要求。如果你的目标是做出高质量的原生体验，这些倾向是优势；但如果你在做大量 Web 端复用的设计系统，或是需要框架无关的 app scaffolding，它就未必是最佳选择。

如何使用 building-native-ui 技能

安装 building-native-ui 技能

如果你的 agent 支持 Skills，可以从 Expo skills 仓库中添加：

npx skills add https://github.com/expo/skills --skill building-native-ui

如果你的环境里已经能访问 Expo skills repo，那么直接从 plugins/expo/skills/building-native-ui 加载 building-native-ui skill 即可。

先读这些文件

想尽快上手，不要一开始就把所有内容都粗略扫一遍。建议按这个顺序读：

1. SKILL.md
2. references/route-structure.md
3. references/tabs.md
4. references/toolbar-and-headers.md
5. references/animations.md

然后只有在你的功能确实需要时，再补充阅读这些更窄的参考文件：

• references/form-sheet.md
• references/search.md
• references/media.md
• references/storage.md
• references/icons.md
• references/visual-effects.md
• references/zoom-transitions.md
• references/gradients.md
• references/webgpu-three.md

这条阅读路径和真实 UI 决策的顺序基本一致：先定应用结构，再定导航，再处理具体页面行为和视觉打磨。

提示前先确认安装上下文

是否值得做 building-native-ui install，很大程度取决于你的运行时约束。这个 skill 明确建议：在做 custom builds 之前，先尝试 Expo Go。原因很实际，因为它引用的一些能力并不是所有环境都支持：

• CSS gradients 需要 React Native New Architecture，且在 Expo Go 中不可用
• Apple Zoom transitions 需要 iOS 18+
• 一些 toolbar 和 search 模式仅适用于 iOS
• Form sheet 示例依赖 Expo Router stack 设置，其中某些细节还要求较新的 Expo SDK 版本

如果你的应用必须完全运行在 Expo Go 里，一定要在提示词里明确写出来。否则 agent 可能会选择一些会迫使你改用 development build 的功能。

给这个技能提供正确的输入信息

building-native-ui usage 的输出质量非常依赖上下文。你最好明确提供：

• 你的 Expo SDK 版本
• 是否必须支持 Expo Go
• 目标平台：iOS、Android、web
• 是否已经使用 Expo Router
• 你想实现的 screen 或 flow
• 设计目标，比如“原生 iOS 设置页风格”或“类似 Instagram 的相机体验”
• 对 storage、media、animations、search 或 tabs 的硬性要求

较弱的输入：
“Build a settings screen.”

更强的输入：
“Using Expo Router on Expo SDK 55, build a settings area for iOS and Android. Must work in Expo Go. Use native-feeling controls for notification toggles, theme mode selection, and a storage section. Keep route files in app/ only and place reusable UI in components/.”

后者之所以更好，是因为它给了 skill 足够的信息，让它能选对控件、避开不受支持的 API，并遵守路由约定。

把模糊想法整理成完整提示词

一个可靠的 building-native-ui guide 提示模板通常包含：

• 产品背景
• 目标平台
• 运行时约束
• 页面列表或 route tree
• 交互细节
• 视觉风格目标
• 期望输出格式

示例：

“Use the building-native-ui skill to design and implement a photo detail flow in Expo Router. Target iOS first, Android acceptable. Try to stay compatible with Expo Go unless a feature clearly requires a custom build. I need:

• route structure for list, detail, and search
• native tabs if appropriate
• a large collapsing image header
• search in the header
• saved items persisted locally
• smooth Reanimated transitions
  Return:

1. recommended file tree
2. route files to create
3. key component code
4. note any features that require iOS-only APIs or custom builds.”

这个提示词好用，是因为它让 skill 去“做决策”，而不只是机械地生成 JSX。

按照这个技能偏好的工作流来用

在实际使用中，最有效的 building-native-ui usage 工作流通常是：

1. 先让它给出 route 和 navigation 结构。
2. 再让它为每个 screen 选择合适的原生控件。
3. 确认结构无误后，再加 motion 和 headers。
4. 等媒体、search、持久化这些流程明确后，再逐步加上。
5. 最后再让 agent 标出哪些地方需要 custom build 或仅支持特定平台。

这样可以显著减少返工，尤其是在炫酷 UI 概念和 Expo Go、路由约定或平台支持冲突时。

严格使用路由约定

这个 skill 最有价值的一点之一，就是它对 Expo Router 约定非常严格。写提示词时，最好明确要求 agent 遵循 references/route-structure.md 中的规则：

• route 文件只放在 app/
• 非路由代码放到 app/ 外
• 使用 _layout.tsx 管理 stacks
• 正确使用 [id].tsx 和 [...slug].tsx
• 确保 / 一定能解析到一个路由

这比看起来更重要。通用提示词很容易把 route 文件和组件文件混放在 app/ 里，后期维护会越来越乱。

想要原生感，就让它优先选原生控件

如果你的目标是做出原生感 UI，就要明确让 skill 尽量优先选择内置控件或平台原生控件。参考资料里给出的建议包括：

• 二值设置使用 Switch
• 短模式切换使用 segmented control
• 较长的选项列表使用 picker
• 图标优先通过 expo-symbols 使用 SF Symbols，而不是 FontAwesome 风格的 icon pack

这类建议很有价值，因为很多通用提示词默认会生成过度定制的控件，不仅看起来不够原生，还会带来额外的设计和维护负担。

动效重要时优先使用 Reanimated

这个 skill 在这点上立场很明确：如果是认真做 UI 动效，优先用 Reanimated v4，而不是 React Native 内置的 Animated API。只要你的 screen 涉及进入、退出、布局变换，或者跟随滚动的动画，就应该在提示词里直接说清楚。这样 agent 更容易采用参考资料中已有的成熟模式，而不是生成更基础、可扩展性较差的动画代码。

把功能需求对应到正确的参考文件

如果第一次输出太泛，可以按下面这张“仓库阅读地图”快速定位：

• animated transitions 或手势细节优化 → references/animations.md
• sliders、switches、segmented controls → references/controls.md
• modal card 体验 → references/form-sheet.md
• gradients 和分层背景 → references/gradients.md
• icon 系统 → references/icons.md
• camera、video、audio、文件保存 → references/media.md
• app 文件夹设计和 params → references/route-structure.md
• header search 和过滤 → references/search.md
• 本地持久化 → references/storage.md
• native tabs 和迁移选择 → references/tabs.md
• stack headers、menus、toolbar actions → references/toolbar-and-headers.md
• blur 和 glass 效果 → references/visual-effects.md

这些实用提示词能明显提升输出质量

不如这样写：
“Make a tabbed app UI.”

更建议这样写：
“Apply building-native-ui to recommend whether this app should use Expo Router NativeTabs or JS tabs. The app has Home, Search, Inbox, and Profile. Prioritize native behavior on iOS, keep labels short, and explain any migration tradeoffs.”

不如这样写：
“Add icons and animations.”

更建议这样写：
“Using building-native-ui, replace generic icon usage with SF Symbols where supported and add Reanimated-based entering and scroll-linked animations for the header. Keep the implementation maintainable and call out any platform fallbacks needed.”

这些提示词之所以更有效，是因为它们迫使 agent 使用这个 skill 真正内置的决策规则，而不是吐出一份通用代码。

building-native-ui 技能常见问题

building-native-ui 只适合 iOS 风格应用吗？

不完全是，但它确实明显偏向 native-first 的移动端 UI，也包含不少偏 iOS 的建议，比如 SF Symbols、Apple Zoom transitions、toolbar 模式和某些 sheet 行为。不过它对 Android 依然有帮助，因为路由、动画、媒体、存储以及 Expo Router 相关的指导同样适用。

building-native-ui skill 对新手友好吗？

友好，前提是你已经掌握 React Native 或 Expo 的基础。这个 skill 更偏实现导向，而不是概念教学，所以新手最适合一次只处理一个 screen 或一个 flow，并且一开始就把版本和平台信息交代清楚。

building-native-ui 比普通提示词强在哪里？

它最大的优势是“带约束感知的输出”。普通提示词可能会编出错误的导航结构，选错不够原生的图标系统，忽略 Expo Router 约定，或者推荐一些其实需要 custom build 的功能，却不提醒你。building-native-ui 会把这些选择范围收窄到 Expo 参考资料支持的模式里。

什么情况下不该用 building-native-ui？

如果你的主要目标是以下几类，就可以考虑跳过：

• 与设计系统无关的通用 React 应用
• web-first UI
• 高度自定义的品牌化组件库，且并不在意原生交互规范
• 框架中立的移动端架构指导

在这些场景下，这个 skill 对 Expo 和原生模式的偏向可能会显得过窄。

building-native-ui 必须搭配 Expo Router 吗？

从实际效果看，基本可以认为“是的”。这个 skill 的大量内容都围绕 Expo Router 的概念组织，比如 _layout.tsx、route folders、native tabs、form sheets 和 headers。即使你在 Expo Router 之外，也能借用其中的控件或动画建议，但它最强的价值还是建立在你的应用遵循这套栈之上。

想把 building-native-ui 用好，一定需要 custom dev build 吗？

不一定。这个 skill 明确建议优先尝试 Expo Go。但它引用的某些能力确实要求更多条件：

• CSS gradients 需要 New Architecture
• Apple 特定 transitions 需要较新的 iOS 版本
• 某些 packages 或 APIs 在 Expo Go 中不可用

如果你最看重构建简单，记得在提示词里直接写上 “Expo Go only”。

如何提升 building-native-ui 技能的使用效果

先给约束，再谈视觉效果

想让 building-native-ui 的结果更靠谱，最快的方法就是在要求 UI polish 之前，先把硬约束说清楚：

• 只能用 Expo Go，还是允许 custom build
• SDK 版本
• 仅 iOS，还是跨平台
• router 是否已经安装
• 是否开启 New Architecture

否则 agent 很可能会选出看起来漂亮、但实际接入成本很高的方案。

让它做决策，不只是出代码

这个 skill 最有用的时候，是你让它在多个原生方案之间做判断。比如：

• “Should this be segmented control or tabs?”
• “Should search live in the header or in-content?”
• “Should I use NativeTabs here?”
• “Can this visual effect stay in Expo Go?”

和“generate a screen”相比，这种以决策为导向的提示词通常效果更好，因为这个仓库本质上更擅长做模式选择和实现路径建议。

提供一个明确的目标 route tree

很多输出质量问题，其实都来自导航结构不清。哪怕只是一个粗略的 route tree，也会很有帮助：

• /
• /search
• /items/[id]
• /settings/profile

这样 skill 就有足够的结构信息来套用 Expo Router 约定，避免文件位置越做越乱。

把你想要的交互模式说具体

不要只说“做得高级一点”或“有 premium 感”。要把交互说具体：

• scroll-reactive header
• modal form sheet with footer
• native search in header
• camera with flip and flash controls
• local saved state
• zoom-like image transition

这些表达能直接对应到 skill 的参考文件，也更容易导向扎实、可实现的方案。

注意这些常见失败模式

最常见的低质量输出通常有这些问题：

• route 文件和组件文件混放在 app/ 里
• 推荐了自定义 icon pack，而不是 SF Symbols
• 该用 Reanimated 的地方却用了老旧动画 API
• 提出了不受支持的功能，却没有标注平台或构建要求
• 控件过度设计，而原生控件其实更简单也更好

如果你看到这些问题，就直接要求 agent 对照对应的参考文件重做。

让 agent 标注平台限制

一个很有价值的 refinement 步骤是直接要求：

“Revise this using building-native-ui and annotate each feature as Expo Go compatible, custom-build required, iOS-only, or New Architecture only.”

这一步能把“看起来不错的回答”变成“可以直接评估是否采用的实施方案”。

按层迭代，不要一上来全盘重写

想得到更好的结果，建议按层次逐步细化：

1. route structure
2. screen skeletons
3. control selection
4. navigation and headers
5. animation and visual polish
6. storage or media integration

这种分层工作流和这个 skill 本身的组织方式非常契合，也更容易在早期发现错误假设。

要求落到具体文件实现

如果第一次回答太泛，就直接要求它改到实际文件里：

• app/_layout.tsx
• app/index.tsx
• app/search.tsx
• app/items/[id].tsx
• components/ItemCard.tsx

这样能迫使 agent 把 building-native-ui 当作实现指南来用，而不是停留在设计脑暴层面。

用 references 反向约束低质量输出

如果 agent 给出的还是泛泛而谈，就把它拉回仓库内容：

• “Rework this using references/route-structure.md conventions.”
• “Switch this animation approach to the patterns in references/animations.md.”
• “Replace the icons with the references/icons.md guidance.”
• “Check whether this should be a form sheet based on references/form-sheet.md.”

这是最实际的方式，能逼出这个 skill 真正有信息增量的部分，而不只是得到一段浅层总结。

用更强的最终提示词提升 building-native-ui 效果

一个高质量的 building-native-ui for Frontend Development 最终提示词可以写成这样：

“Use the building-native-ui skill to implement an Expo Router feature for a saved-recipes app. Target iOS and Android, but keep Expo Go compatibility if possible. I need a route structure, native-feeling tabs, a search experience, recipe detail pages, local persistence for favorites, and smooth header animations. Put only routes in app/, use Reanimated for motion, prefer SF Symbols where appropriate, and clearly mark any part that requires iOS-only APIs, New Architecture, or a custom build.”

这个提示词之所以有效，是因为它把产品目标、技术限制、路由规范、UX 预期和审查标准都放进了一次请求里。