expo-dev-client

expo-dev-client 技能概览

expo-dev-client 能做什么

expo-dev-client 技能的核心价值，是先帮你判断是否真的需要 Expo development client，再指导你如何通过 EAS Build 在本地或提交到 TestFlight 的方式完成配置与构建。它真正解决的问题，不只是“把包打出来”，而是“在不用反复翻 Expo 文档、靠猜配置的前提下，把支持自定义原生能力的测试 App 装到真实设备上”。

谁适合使用这个技能

这个技能最适合：

• 正在为 Expo 项目接入原生模块的团队
• 需要测试本地 Expo modules 或自定义原生代码的开发者
• 使用 Apple 特定目标能力的应用，例如 widgets、app clips 或 extensions
• 需要一套可重复执行的内部 iOS 测试路径，并通过 TestFlight 分发的团队

如果你的应用完全可以在 Expo Go 中运行，通常就不需要这个技能。

最关键的安装决策

是否要采用这个技能，最重要的问题其实很简单：你到底需不需要 development client？expo-dev-client 技能的价值，就在于它会很早把这个判断摆到前面。它会明确建议你先用 npx expo start 试跑 Expo Go，避免无谓的构建时间浪费，也避免过早引入 EAS 的复杂度。

为什么 expo-dev-client 不同于通用的 Expo 提示词

普通提示词可能只会让代理“帮我把 Expo dev client 配好”，但这个技能更偏向决策与流程判断。它重点覆盖的是：

• 什么时候才算真的需要 dev client
• eas.json 需要具备的关键结构
• 本地构建与云构建 / TestFlight 构建的区别
• 在真实设备上进行接近部署场景测试时，实际应该走的命令路径

因此，相比泛泛的 Expo 助手提示词，它更适合用于初始化配置，以及靠近发布前测试的工作流。

如何使用 expo-dev-client 技能

安装 expo-dev-client 技能

在支持 skills 的环境中，用下面的命令安装：

npx skills add https://github.com/expo/skills --skill expo-dev-client

由于这个技能本身体量不大，核心内容主要集中在 SKILL.md，安装的重点其实是让它在后续 Expo 原生测试任务里可被重复调用。

先明确要完成的任务，而不是先想命令

在调用 expo-dev-client 技能之前，先把真实目标说清楚：

• “我接入了一个原生 SDK，需要在 iPhone 上测试”
• “我们需要一个按分支区分的 dev client 供 QA 使用”
• “应用现在加了 widget，Expo Go 已经不够了”
• “我们想通过 TestFlight 分发一个 iOS development build”

这一步很重要，因为这个技能最擅长的场景，就是你已经能明确说明为什么必须引入自定义原生能力。

先确认 Expo Go 是否已经足够

很多人常见的错误，是太早上来就用 expo-dev-client。推荐先做的测试是：

npx expo start

如果应用在 Expo Go 里可以正常运行，那就到此为止。development client 会额外带来构建耗时、签名要求和分发成本。只有当原生能力确实逼着你往前走时，才应该用这个技能。

了解最适合使用 expo-dev-client 的触发条件

当你的项目包含以下情况时，就应该考虑使用 expo-dev-client：

• 本地 Expo modules
• 自定义原生代码
• Expo Go 不支持的第三方原生模块
• Apple 目标能力，例如 widgets、app clips 或 extensions

在这些场景里，dev client 就不是“可选项”，而是“必需项”。

先准备好代理真正需要的最小输入信息

如果你希望代理把 expo-dev-client 技能用好，至少要提供这些信息：

• 目标平台：ios、android 或两者都要
• 预期分发方式：本地安装、内部测试，还是 TestFlight
• 项目是否已经配置过 EAS
• 当前的 eas.json
• 应用是否使用了 Expo Go 不支持的原生模块
• 是否存在版本号或签名方面的限制

如果没有这些上下文，代理当然也能给命令建议，但很可能选错 build profile，或者给出过度配置的方案。

不要只说“set up expo-dev-client”，提示词要更具体

一个弱提示词：

Set up expo-dev-client.

一个更强的提示词：

Use the expo-dev-client skill to determine whether this Expo app needs a dev client. We added a third-party native iOS SDK and need a TestFlight-distributed development build for internal QA. Review this eas.json, identify missing settings, and give the exact commands for building and submitting.

这样写更有效，原因是：

• 它先要求判断是否真的适配
• 它明确点出了原生能力触发因素
• 它说清了目标工作流
• 它提供了配置文件，便于做具体修正

正确配置 eas.json

这个技能强调的关键配置，是在 eas.json 中加入 development build profile，并设置 developmentClient: true，通常还会配合版本自动递增：

{
  "cli": {
    "version": ">= 16.0.1",
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    },
    "development": {
      "autoIncrement": true,
      "developmentClient": true
    }
  },
  "submit": {
    "production": {},
    "development": {}
  }
}

其中最重要的字段是：

• developmentClient: true：告诉 EAS 需要打包 development client
• autoIncrement: true：减少 build number 相关的摩擦
• appVersionSource: "remote"：让版本管理通过 EAS 保持一致

需要远程真机测试时，用 TestFlight 构建 expo-dev-client

对于 iOS 团队来说，expo-dev-client usage 最有价值的一条路径，通常就是走 TestFlight：

eas build -p ios --profile development --submit

当你需要把支持开发能力的 App 分发给测试人员，而不是只拿到一个本地构建产物时，这就是最实用的“expo-dev-client for Deployment”流程。它把云端构建和提交流程串在一起，通常比自己拆成多个步骤更快。

当速度或隐私更重要时，优先考虑本地构建

如果你不需要 TestFlight，本地构建往往是更好的工作流：

• 在某些环境下迭代更快
• 对本地工具链有更强控制力
• 适合在更大范围内部测试前，先在自己设备上验证

如果你是在排查配置问题，或者只想先验证某个原生集成是否能在自己设备上跑通，就选本地构建。若你要和 QA 或非技术测试人员协作，就更适合走 TestFlight。

先读对仓库文件：从 SKILL.md 开始

这个技能结构很简单：优先看 SKILL.md。在这条技能路径下，没有 resources/、rules/ 之类的额外支持目录，也没有辅助脚本，所以大多数可执行的指导其实已经集中在这里。

这也意味着你不该期待它内置很深的自动化逻辑；它本质上更像一份偏实战的决策与工作流指南。

面向真实项目的推荐 workflow

一套可靠的 expo-dev-client guide 使用流程可以是：

1. 先确认 Expo Go 是否因为原生能力限制而无法满足需求。
2. 检查现有 eas.json，没有的话就创建。
3. 增加一个带有 developmentClient: true 的 development profile。
4. 在本地构建和 TestFlight 分发之间做选择。
5. 针对目标平台执行准确的 EAS build 命令。
6. 在真实设备上测试。
7. 如果版本号或提交流程表现异常，再回头调整 profile 设置。

按这个顺序走，可以减少无效构建次数，也能尽早发现“其实根本不需要 dev client”的情况。

expo-dev-client 技能 FAQ

expo-dev-client 只适合高级 Expo 应用吗？

大体上是的。新手当然也可以用，但这个技能真正有价值，通常是在应用因为原生需求而超出 Expo Go 能力边界之后。如果你还处在纯 managed workflow 阶段，它暂时未必能带来明显收益。

expo-dev-client 是否等同于在项目里安装 expo-dev-client 包？

不是。expo-dev-client 技能关注的是 development-client 构建相关的整体工作流：什么时候该用、EAS 应该怎么配、构建路径如何选。它不是单纯提醒你安装一个 package。

什么情况下不应该使用 expo-dev-client 技能？

以下情况不建议使用：

• 应用已经能在 Expo Go 中正常运行
• 你只需要 JavaScript 层面的迭代
• 你要找的是完整 release build 指南，而不是 development-client 配置
• 你遇到的问题和原生能力或构建分发无关

它和普通的 Expo 排障提示词有什么区别？

普通提示词通常只能给出比较泛的构建建议。expo-dev-client skill 更聚焦，因此更适合做安装决策判断：它会把“到底需不需要 dev client”这个检查点放在前面，也会明确指出 EAS profile 里那些最常卡住落地的配置细节。

expo-dev-client 对 Android 也有用吗？

有用。但从技能内容来看，它最明确、最有操作性的指导主要还是围绕 iOS 和 TestFlight 展开。底层逻辑对 Android development build 同样适用：只要自定义原生代码让 Expo Go 不再够用，就需要 dev client。

它适合用于 deployment 工作流吗？

适合，但要理解边界。expo-dev-client for Deployment 更准确地说，是用于 development build 的内部发放，尤其适合通过 TestFlight 做 QA 或分支测试。它不能替代完整的生产发布规划。

如何改进 expo-dev-client 技能的使用效果

一开始就提供当前项目状态

如果你想让 expo-dev-client 技能给出更高质量的结果，建议一开始就附上：

• 你的 eas.json
• 目标设备和平台
• 这是本地使用还是走 TestFlight
• 是哪个原生模块或目标能力触发了这次变更
• 是否已经试过 Expo Go

这样代理才能从泛泛建议，进入到具体修改和精确命令层面。

先让它做判断，再让它给步骤

高质量提示词可以这样开头：

First determine whether this app truly needs expo-dev-client.

这句指令会明显提升输出质量，因为这个技能最大的价值，本来就是避免不必要的 dev-client 配置。

提供配置片段让它直接审查

如果你把现有 eas.json 贴出来，代理就能：

• 发现是否缺少 developmentClient: true
• 提出版本管理方面的修正建议
• 对齐 submit 和 build profiles
• 避免凭空补出你其实不需要的配置

这比从零开始提问要有效得多。

明确说明你的分发目标

正确命令取决于你到底想要：

• 一个本地 development build
• 一个可安装到设备上的云构建
• 一个提交到 TestFlight 的 iOS build

如果你不说明这一点，第一次返回的结果可能技术上没错，但在团队实际执行上是错的。

注意 expo-dev-client 最常见的失败模式

最常见的失败，是把 expo-dev-client 用在本来应该继续留在 Expo Go 的应用上。第二常见的问题，是 EAS 配置给得太少，却反过来嫌技能输出不够具体。只要你把原生需求和当前配置说清楚，这两种问题都可以避免。

拿到第一次回答后继续迭代

得到第一轮回复后，可以继续追问：

• “Validate this eas.json against a dev-client TestFlight workflow.”
• “Rewrite the build commands for Android only.”
• “Assume our app uses a widget extension; what changes the decision?”
• “Minimize the setup to the smallest working development profile.”

这样才能把 expo-dev-client skill 从泛化说明，推进到真正贴合项目的执行方案。

用统一提示模板提升团队采用效率

如果团队里会有多位开发者使用这个技能，建议做一个可复用的内部提示模板，例如：

Use expo-dev-client to assess whether this Expo app requires a development client. Here is our eas.json, target platform, distribution goal, and native dependency list. Return: 1) decision, 2) config changes, 3) exact commands, 4) likely blockers.

这样可以让输出更稳定，也能降低新人上手成本。

把这个技能当作决策闸门，而不只是操作清单

提升 expo-dev-client usage 效果的最佳方式，是把它当作构建前的决策闸门来用，而不是等团队已经决定要做 dev client 之后，才把它当作配方来执行。否则你会失去它最大的优势：提前拦住那些本来不需要进入原生构建工作流的情况。