测试快照： 2026-08-09
项目： expo/skills
仓库快照： 2,380 Stars、125 Forks，最近推送 2026-08-07
许可证： MIT ｜ 规模： 23 个 Skills
证据边界： L0 静态检查、L1 触发测试和 L2 代码输出对照已完成；本轮没有完成
npm install、编译、模拟器运行或截图回归。
先说结论
Expo 的官方 Skills 是三套移动开发 Skill 中最容易控制规模的一套。它只有 23 个条目，却覆盖 Expo Router、数据请求、原生模块、EAS 构建与发布、OTA 更新、托管和观测。更重要的是，它把 description 长度限制在 1,024 个字符以内，把正文限制在 500 行以内，并通过 CI 强制执行。
本轮综合评分为 4.1/5。L0 静态检查达到 23/23 核心字段完整、0 断链，所有面向用户的 Skill 都通过体积限制；L1 经过 ground truth 修正后达到 19/20 top-1；L2 从裸模型 10/12 提升到 12/12，但多出来的两分分别是 Expo 特有的 EXPO_PUBLIC_ 环境变量约定，以及 React Query/SWR 方案处方，并不是三个用户报告的 bug 终于被修好。
所以它值得装，但不要把“官方”理解成“生成代码无需检查”。它最稳定的价值是把 Expo/EAS 的私有约定、版本边界和服务属性带进模型上下文；它最明显的缺口，是完全没有 last_verified 或 review_by 这样的时效元数据。
评分卡
| 维度 | 权重 | 得分 | 本轮依据 |
|---|---|---|---|
| 产出增益（L2） | 25% | 3.5/5 | A 组 10/12，B 组 12/12；增量是框架约定和方案处方 |
| 工程质量（L0） | 20% | 4.5/5 | 23 个 Skill 零断链，CI 强制体积上限，溯源元数据较弱 |
| 触发准确率（L1） | 15% | 4.0/5 | 初始 18/20，修正 ground truth 后 19/20 |
| 覆盖度 | 15% | 4.0/5 | Expo/EAS 专属，高频日常场景多于 Android 长尾集合 |
| 权威性 | 10% | 4.5/5 | Expo 框架方官方维护，但不是 Apple/Google 级平台方 |
| 可执行性 | 10% | 4.5/5 | expo-skill-eval 支持模拟器和截图方向 |
| 维护活跃度 | 5% | 4.5/5 | 推送活跃，接受外部贡献 |
| 加权总分 | 100% | 4.1/5 | 建议按项目选择性安装 |
它是什么
这个仓库把 Skills 分成三个实际使用层：
Expo 框架（开源免费）
expo-router、expo-ui、expo-native-ui、expo-data-fetching、expo-dom、expo-module、expo-brownfield、expo-app-clip、expo-dev-client、expo-project-structure、expo-tailwind-setup、expo-upgrade、expo-web-to-native、expo-examples 和 expo-migrate-module。
这些条目主要回答“如何在 Expo/React Native 项目中实现功能”，例如文件式路由、原生模块、数据请求、Tailwind、Brownfield 集成和 SDK 升级。
EAS 服务（付费）
eas-app-stores、eas-hosting、eas-observe、eas-simulator、eas-update-insights 和 eas-workflows。
这些条目涉及 EAS 构建、App Store/Google Play 提交、API Routes 托管、线上观测、云端模拟器和 OTA 采用率。使用时需要把 EAS 价格、账户权限和托管依赖当成独立工程决策。
内部元技能
expo-skill-eval 和 expo-skill-feedback 更像仓库维护工具，不是普通开发者每天都会触发的业务 Skill。
这种分类带来了一个实用优点：agent 和用户在读取正文之前，就能知道一个能力是开源框架知识，还是可能产生费用的 EAS 服务。
我们怎么测
为了避免只看 Stars，本文分三层：
L0：全量静态体检
用 harness/l0_static_audit.py 检查 23 个 SKILL.md 的核心字段、相对链接、正文体积、附属文档和 provenance 字段。
L1：触发准确率
只给模型 23 个 Skill 的 name + description，不读取正文。使用 20 条覆盖路由、升级、数据请求、EAS 发布、模拟器和官方示例的 prompt，测 top-1 选择。
L2：Expo Router 数据请求 A/B
fixture 是一个 Expo Router 任务列表，故意加入三个用户问题：快速切换 tab 时出现旧请求数据、断网后白屏、token 存在不安全位置。A 组不注入 Skill，B 组注入 expo-data-fetching，各运行三次，按 12 个静态检查项打分。
L3，也就是 npm install、真实编译、启动模拟器和截图回归，本轮没有执行。更重要的是，fixture 本身的版本组合并不自洽：expo ~54 配 expo-router ~5，而 SDK 54 通常需要核对对应的 Router 版本。因此 L2 只比较相对输出，不证明最终工程能直接构建。
L0：这是三个仓库里体积治理最成熟的一套
全量静态结果：
| 指标 | 结果 |
|---|---|
| 核心字段齐全 | 23/23 |
| 断链 | 0/23 |
SKILL.md 超过 5,000 tokens | 2/23 |
| 无附属文档 | 7/23 |
| 目录常驻上下文 | 2,173 tokens |
| 总 SKILL.md 体积 | 55,662 tokens |
CI 硬性限制比“请保持简洁”可靠
仓库的 scripts/check-skill-limits.ts 直接规定：
``ts const MAX_DESCRIPTION = 1024; const MAX_BODY_LINES = 500; ``
并且还强制识别：
Framework (OSS).或EAS service (paid).分类前缀；- EAS Skill 正文中的
EAS service - costs apply.； expo.dev/pricing价格链接。
实测结果是 100% 达标：description 最长 996 个字符，没有面向用户的正文超过 500 行，只有两个内部元技能获得分类前缀豁免。
这解释了体积差异：Expo 的 23 个 Skill 总共 55,662 tokens，Apple 社区仓库的 183 个 Skill 是 463,390 tokens；Expo 面向用户的最大单个 Skill 是 5,806 tokens，而 Apple 的最大单文件达到 15,667 tokens。Android 和 Apple 两边都没有阻止单文件膨胀的硬性上限。
商业属性披露是一个好机制
6 个 EAS Skill 全部带 EAS service (paid).，正文还必须包含费用提示和价格链接。这不是广告，而是权限和成本边界的显式标注：当 agent 建议 eas-hosting、eas-workflows 或 eas-simulator 时，用户知道这可能需要账户、云端服务和付费额度。
最大缺口：没有时效元数据
Expo 的 provenance 字段明显弱于另外两套：
| 字段 | Android | Apple | Expo |
|---|---|---|---|
author | 100% | 0% | 0% |
license | 100% | 0% | 86% |
updated | 95% | 100% | 0% |
review_by | 0% | 100% | 0% |
allowed-tools | 0% | 100% | 26% |
keywords | 100% | 0% | 0% |
内容大量提到 SDK 55+、SDK 56，却没有 last_verified、updated 或 review_by。对一个版本更新很快的框架，这意味着 agent 无法自动判断正文是否匹配当前项目。
L1：实际 top-1 是 19/20
初始结果是 18/20，但复核后发现其中一题是 ground truth 错误，因此更准确的结论是 19/20（95%）：
P18：安全 token 存储漏触发，是真实 description 缺口
expo-data-fetching 的正文有 Authentication 小节，明确使用 expo-secure-store：
``ts getToken: () => SecureStore.getItemAsync(TOKEN_KEY) ``
但 description 只写了 fetch API、React Query、SWR、错误处理、缓存、离线支持和 Router data loaders，没有 auth、token、SecureStore、credential 或 keychain 关键词。因此用户问“token 存哪里比较安全”时，模型选择 NONE 是合理的。
这不是正文能力不足，而是 description 没有暴露能力。补充 “auth tokens / secure storage / request interceptors” 就能修复。
P19：模拟器问题其实是 ground truth 错了
eas-simulator 的 description 明确写着：在 macOS 上，普通的“本地运行模拟器”不要自动触发；它只用于云端、远程、可分享的模拟器，或者当前主机没有本地模拟器的场景。
本次测试在 macOS 上，prompt 只是“想在模拟器上跑起来看看”，没有说云端或远程。模型选择 NONE 符合 Skill 自己写出的排除条件，因此不能把这题算成路由失败。
这条 description 反而是三轮评测中最完整的排歧样例：它同时写了正例场景、宿主环境条件和显式否定清单。
分类前缀的利弊
Framework (OSS). / EAS service (paid). 对粗粒度分流有帮助：用户问 App Store 提交、EAS 工作流、线上观测和 OTA 采用率时，可以先进入 EAS 簇。
但簇内几乎没有消歧作用。eas-observe 和 eas-update-insights 都以同一个付费前缀开头，真正有用的是 crash、TTI、channel、install counts 等后面的词。固定前缀还占用了 description 最重要的首词位置。
更好的方式是保留商业属性，但把它放在末尾，或者独立成 frontmatter 字段，让第一句直接描述功能。
“ANY network request” 造成过度承诺
expo-data-fetching 使用了：
debugging ANY network request, API call, or data fetching
这让它在“部署一个 API 后端”这类问题上接近 eas-hosting。本轮依靠 “+api.ts handlers”“eas deploy” 等更具体的词才没有误触发。更严重的是，ANY 声称覆盖所有网络问题，却没有在 description 中提到 token 安全存储。
应把全称量词改成有边界的描述，例如“涉及 fetch/HTTP 的读写路径，包括请求取消、认证 token 和缓存”，同时明确不负责后端部署。
L2：10/12 到 12/12，但增量要拆开看
| 检查项 | A1 | A2 | A3 | B1 | B2 | B3 |
|---|---|---|---|---|---|---|
检查 response.ok/status | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| token 改用 SecureStore | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 不再用 AsyncStorage 存 token | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 请求可取消、防竞态 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
API URL 使用 EXPO_PUBLIC_ | — | — | — | ✓ | ✓ | ✓ |
| 不再硬编码 URL | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 移除 axios | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 错误状态渲染到 UI | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 采用 React Query/SWR | — | — | — | ✓ | ✓ | ✓ |
| toggle 不再全量 refetch | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 无幻觉依赖 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 未破坏 TypeScript 入口 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 总分 | 10/12 | 10/12 | 10/12 | 12/12 | 12/12 | 12/12 |
三个用户问题，裸模型已经全部修对
A 组三次都处理了：
- 旧请求数据：不仅 abort，还增加单调递增 request ID，避免已经 resolve 的响应继续覆盖新状态；
- 断网白屏：加入 offline、error、empty 三态、Retry 和下拉刷新，并保留刷新失败前的旧数据；
- token 安全：迁移到
expo-secure-store，并把旧 AsyncStorage token 一次性搬到 Keychain 后删除明文副本。
这说明通用模型对常见网络工程问题的基线已经不低。
Skill 提供的真实增量：Expo 专有约定
C05 的 EXPO_PUBLIC_ 环境变量前缀，A 组 0/3、B 组 3/3。这是 Expo 特有的配置约定，不是通用 React Native 常识。它是本轮最干净的一项增益：裸模型很难凭空知道，Skill 明确写出后就稳定执行。
React Query 是方案选择，不是唯一正确答案
B 组三次都采用 React Query/SWR，A 组三次都写了一个更轻的 useTasks.ts，用 AbortController 和 request ID 处理竞态。两种方案都修好了用户问题：
| A 组手写方案 | B 组 Skill 方案 | |
|---|---|---|
| 竞态处理 | AbortController + request ID | queryKey 自动管理取消和缓存 |
| 新增依赖 | expo-secure-store | React Query + NetInfo + SecureStore |
| 优势 | 依赖少，改动小 | 缓存、重试、离线恢复更完整 |
| 代价 | 需要自己维护状态逻辑 | 包体、配置和升级成本增加 |
如果项目只是一个小列表，B 组并不一定更好；如果应用已经有多个查询、缓存和离线场景，React Query 的处方更有长期价值。评测 checklist 记 B 组赢，是因为它符合 Skill 的标准方案，不代表所有项目都该无条件引入新依赖。
分层 references 这次真的工作了
B 组三次都明确报告读取了 references/ 下的两个文件，并正确判断 expo-router-loaders.md 不适用：它针对 web-only / SDK 55+，而 fixture 是 SDK 54 的原生应用。这是三轮评测中第一次实测验证“薄的 SKILL.md + 厚的 references”不仅存在，而且能让 agent 根据版本和平台条件排除不适用内容。
它最值得借鉴的机制
- CI 体积上限。 1,024 字符 description 和 500 行正文，防止知识库随时间失控。
- OSS / paid 明示。 在路由前暴露服务属性，让成本和权限不是隐藏副作用。
- 明确排歧。
eas-simulator的“云端/远程才触发、本地模拟器不要触发”是优秀样例，但应给信息不足时留出兜底条件。 - 渐进披露。 SKILL.md 保持薄，版本相关或较长材料放入 references。
- 官方工作流覆盖。 Expo Router、EAS Workflow、App Store/Play 提交和 API Routes 都是实际开发会遇到的入口。
优点与不足
优点
- Expo 框架方维护，内容和工具链边界比通用 React Native 提示词更清楚；
- 23 个 Skill 规模适中，目录常驻成本约 2,173 tokens；
- CI 体积上限是三套仓库中最可靠的长期治理机制；
- EAS 付费属性显式披露，减少“被推荐后才发现要付费”的意外；
references/分层在实际 L2 中被正确读取和条件排除；- 接受外部贡献，便于修正文案和版本问题。
不足
- 完全没有
last_verified/review_by，无法自动判断 SDK 版本新旧； expo-data-fetching正文覆盖 token 安全存储，但 description 没有暴露，导致真实漏触发；- 固定分类前缀占用首词位置，簇内消歧收益有限；
ANY等全称承诺会扩大误触发压力；expo-skill-eval有评测工具，但运行产物没有提交，外部无法复核完整结果；- EAS 相关 Skill 会引入云端、账户、权限和费用，不能和开源框架 Skill 视为同一种依赖。
谁适合安装
适合
- 正在使用 Expo Router、EAS Build/Update 或 Expo Modules 的团队；
- 需要统一 SDK 升级、数据请求、原生模块和商店发布流程的项目；
- 希望让 agent 遵守 Expo 专有约定，而不是只生成通用 React Native 代码的开发者；
- 能够接受 EAS 账户、权限和费用边界的团队。
不适合全量无脑安装
- 只写一个小型 React Native demo；
- 项目锁定在旧 Expo SDK，但没有时间逐条核对版本；
- 不希望新增 React Query、NetInfo 或 EAS 云端依赖；
- 需要完全离线、本地模拟器工作流，却误用了
eas-simulator。
更安全的采用方式
- 先根据任务选择
expo-router、expo-data-fetching、expo-upgrade或目标 EAS Skill，不要默认装 23 个。 - 记录 Expo SDK、Router、React Native、Node 和 EAS CLI 版本；未来补上
review_by。 - 对涉及 EAS 的建议先确认账户权限、付费计划、API token 和 CI secret 位置。
- 把“修 bug”和“引入 React Query / 升级 SDK / 改托管方式”拆成独立变更。
- 先在可回滚 fixture 中记录 prompt、diff、依赖变化、构建日志和失败路径。
- 完成
npm install、npx expo doctor、真实构建、模拟器运行和核心交互回归后，再进入生产仓库。
与 Android、Apple Skills 的横向对比
| Google Android Skills | rshankras Apple Skills | Expo Skills | |
|---|---|---|---|
| 出品方 | Google 官方 | 社区维护 | Expo 官方 |
| 数量 | 22 | 183 | 23 |
| 目录常驻成本 | 约 1,595 tokens | 约 9,198 tokens | 约 2,173 tokens |
| 面向用户最大单文件 | 9,355 tokens | 15,667 tokens | 5,806 tokens |
| 体积硬限制 | 无 | 无 | 有（1024 字符 / 500 行） |
| 时效元数据 | last-updated 部分存在 | review_by 100% | 0% |
| 商业属性披露 | 无 | 无 | OSS / paid 前缀 |
| L1 top-1 | 10/10 召回、0 假阳性 | 19/20 | 19/20（修正后） |
| L2 A 组 | 8、9、10 | 10、10、10 | 10、10、10 |
| Skill 主要增益 | 降低方差 | 现代化规范 | Expo 专有约定 + 方案处方 |
三轮测试共同说明：裸模型基线比想象中高，Skill 的价值集中在模型不可能凭通用知识稳定知道的私有约定、版本门槛、服务边界和团队规范。数量不是价值，选题和治理才是。
编辑部结论
Expo Skills 值得装，而且是三套里最省心的一套，但仍应按任务选择。 它的最大优势不是 23 个条目本身，而是用 CI 把知识库体积控制在可管理范围内，并在路由前披露“开源框架还是付费 EAS 服务”。
它最该补的不是更多正文，而是 last_verified、SDK 版本基线和可公开复核的 eval 产物。它最该修的 description 是 expo-data-fetching：把 auth token、安全存储、请求取消和拦截器明确写进触发描述，同时收窄 “ANY network request” 的承诺。
对使用者来说，最稳妥的方式是：选一个与任务匹配的 Skill，锁定 Expo SDK，保留依赖和权限 diff，完成真实构建后再决定是否长期采用。对 Skill 作者来说，最值得复制的是“硬性体积上限 + 商业属性披露 + 正确的渐进披露”。
证据边界： 本文使用 2026-08-09 快照。L0、L1、L2 结果来自本地评测和仓库公开材料；L1 已对 ground truth 进行复核，L3 的安装、编译、模拟器和截图回归尚未完成。fixture 的 Expo/Router 版本组合也需要在真实项目中重新核对，不能把本轮相对比较写成生产构建保证。