Callstack React Native Agent Skills 评测：12 个 Skills，真的能改善 RN 性能吗？

测试快照： 2026-08-09

项目： callstackincubator/agent-skills

仓库快照： 1,589 Stars、115 Forks，最近推送 2026-08-08

许可证： MIT ｜ 规模： 12 个 SKILL.md

证据边界： 本文 60% 的结论来自 L0 静态审计、L1 触发测试和 L2 代码输出对照；本轮没有安装依赖、编译、启动 Metro、连接设备或执行截图回归。

先说结论

Callstack 的 RN Skills 是四个移动开发 Skill 集合里最克制、最容易常驻上下文的一套：12 个条目的 SKILL.md 合计 17,284 tokens，中位数 1,224，没有一个正文超过 5,000 tokens。它的路由也最稳：13 条 React Native 范围内请求全部命中，7 条越界请求零误触发。

但如果问题是“它能不能让模型修好一份 RN 性能代码”，答案要谨慎得多。本轮 500 条列表的 A/B 对照中，裸模型和注入 Skill 的模型都拿到 12/12；三次裸模型都独立找到了最隐蔽的 Row 内嵌组件问题。因此综合分只有 3.7/5：它写得好、触发准，却没有在这道已经被社区充分讨论的题上带来可测量的 checklist 增益。

真正值得带走的价值有两项：

1. 过程纪律。 B 组会明确说出没有设备就不能完成 Measure → Optimize → Re-measure → Validate，而裸模型没有一次主动说明这一点。
2. 一个窄但可解释的技术增量。 B 组 3/3 将搜索框改为非受控输入，避免受控 TextInput 的 JS↔native 往返；A 组 0/3 做到这一点。

所以它适合当作 RN 项目的“第二双眼睛”，尤其适合性能剖析、迁移、导航和原生集成；不适合被当成自动验收器，也不应因为仓库来自 RN 核心贡献者就跳过真实设备验证。

评分卡

这个仓库到底包含什么

12 个 SKILL.md 分成三层：8 个自有 Skill、3 个 vendored Skill、1 个内部校验器。

自有 Skill

• react-native-best-practices：性能、JS 线程、Hermes、FlashList、内存泄漏、动画和原生模块。
• react-navigation：React Navigation 配置和常见路由问题。
• upgrading-react-native：RN 版本升级。
• create-react-native-library：创建 RN 原生库。
• react-native-brownfield-migration：把 RN 引入现有原生应用。
• assess-react-native-migration：评估迁移可行性和风险。
• react-native-tv-best-practices：电视端 RN 实践。
• github-actions：RN 项目的 GitHub Actions 自动化。

Vendored Skill

agent-device、dogfood、react-native-testing 来自外部同步。它们提供设备操作、内部试吃流程和 React Native Testing Library 方向的内容。

内部工具

validate-skills 是仓库维护者使用的校验命令，不是普通业务开发 Skill。把它算进 12 个条目可以反映仓库完整形态，但不能把它当成 RN 能力覆盖。

和 Expo 官方 Skills 的差异很明确：Expo 负责框架和 EAS 服务；Callstack 是 RN 生态里的第三方工程团队和核心贡献者。它的强项因此不是“官方产品配置”，而是性能、迁移和工程实践。

我们怎么测：不要把 Stars 当成效果证明

本评测使用三层证据：

L0：全量静态体检

检查 12 个 SKILL.md 的核心字段、相对链接、正文体积、附属 references 和 provenance 元数据。结果是 12/12 核心字段完整、0 断链、0 个 SKILL.md 超过 5,000 tokens。

L1：只看 description 的触发测试

模型只能看到 12 个 Skill 的 name + description，不能读取正文。我们使用 13 条 RN 范围内请求，以及 7 条越界请求（Flutter、PRD、后端 API、推送通知、审核被拒、深色模式和数据库选择），记录 top-1 路由和误触发。

L2：RN 性能 fixture 的 A/B

fixture 是一个包含 500 条商品的 React Native 列表页，预埋 10 类性能缺陷。用户只报告三件事：滚动掉帧、搜索每输入一个字就卡、离开页面后似乎仍有后台任务。A 组使用裸模型，B 组注入 react-native-best-practices，各运行三次，再用 12 项 checklist 对输出判分。

L3：本轮没有做什么

没有执行 npm install、真实构建、Metro 启动、模拟器或真机运行，也没有截图回归。因此“12/12”表示静态代码输出通过检查，不等于应用在你的设备上已经达到 60 FPS，更不等于可以直接合并上线。

L0：它是四家里最精简的仓库

其中 react-navigation 最能体现渐进披露：入口只有 631 tokens，但附属 references 达到 17,267 tokens，入口与深层资料比为 27.36。需要导航知识时读导航资料，需要列表性能时读列表资料，而不是把整个 RN 手册塞进每次请求。

写作纪律：原则很先进，执行机制还不够

Callstack 的 AGENTS.md 明确提出：只加入模型不知道的上下文、description 使用第三人称、写清 What + When、references 只允许一层深、避免重复，正文控制在 500 行以内。这是四个仓库里最清楚的一套作者规范。

静态统计显示：正文长度和第三人称要求都达标；但自有 skills/ 的 83 个文件里出现了 299 次一层深引用违规。例如 js-lists-flatlist-flashlist.md 末尾又链接到 js-profile-react.md 和 js-measure-fps.md。这种“See also”不一定损害阅读体验，甚至可能构成有用的知识图谱，但它和仓库自己的规则冲突。

原因是 /validate-skills 只是手动 slash 命令，不是 CI 检查。对比 Expo：相同的 500 行限制被写入 CI，Callstack 目前主要靠文档约束。容易靠自觉完成的规则达标了，需要自动发现的规则却漂移了。

元数据写在 POWER.md，规范解析器可能看不到

react-native-best-practices 目录里有一个非标准的 POWER.md，其中重复了 frontmatter，并额外包含 author 和 keywords。按 SKILL.md 规范读取时，这些字段不会被看见。因此 L0 统计出 author 只有 8% 覆盖、keywords 为 0%，不是信息完全不存在，而是信息被放到了工具未必读取的地方。

profiler 截图是一个真正有用的附加资产

react-native-best-practices/references/images/ 包含 12 张性能剖析截图，覆盖 flamegraph、memory heap snapshot、bundle treemap、Xcode Instruments、FlashList 对比、受控 TextInput 往返、FPS 曲线和 view hierarchy 等。这个仓库总大小约 22 MB，截图是主要来源。

这不是“放图更好看”这么简单：它给 agent 一个把 profiler 输出和诊断结论联系起来的视觉样本。四轮对比中，这是唯一在 references 里系统放置性能分析截图的集合。不过图片只能帮助解释证据，不能替代在真实设备上采样。

溯源元数据仍然是短板

React Native 的 New Architecture、FlashList v2、Hermes 和 SDK 组合都可能随版本变化，但 Skill 没有 last_verified 或 review_by。今天准确的建议，明天可能仍会被 agent 当成无条件规则。

L1：它的路由准确率是四家最好的一项

结果是：

• in-scope：13/13，100%；
• out-of-scope 误触发：0/7；
• 合计：没有把 RN Skill 错派给 Flutter、后端或普通产品需求。

react-native-best-practices 的 description 看上去范围很宽，提到 FPS、TTI、bundle、memory leak、re-render、animation、Hermes、JS thread、bridge、FlashList、native module 和 jank。但这些词都被“React Native performance optimization”以及 RN 专有名词框住，所以没有吞掉无关问题。

这给 Skill 作者一个可复用的经验：用平台和框架专有名词圈定边界，比单纯写“覆盖所有场景”更能降低误触发。

仍然存在的覆盖缺口：E2E 无人负责

“给 RN 项目补 unit tests 和 E2E”这一题只命中了 react-native-testing 的组件测试方向。目录里没有明确的 Detox 或 Maestro owner。也就是说，使用者可能得到 RNTL 组件测试建议，却还要自己补齐真机端到端测试、权限流和导航流回归。

L2：12/12 对 12/12，为什么还要装？

checklist 结果：没有增益

裸模型三次都找到了最容易漏掉的 bug：Row 写在父组件函数体内，每次父组件渲染都会产生新的组件类型，导致 500 行被卸载再挂载。两组还都主动加了 checklist 没要求的计时器叶子组件、getItemLayout、预计算小写搜索字段，并修复了模块级数组被 .sort() 原地修改的问题。

这不是 Skill 失败，而是测试题对现代模型来说已经饱和。RN 列表性能被社区讨论了多年，虚拟化、memo、稳定 callback、清理 timer 等模式已经进入模型的通用训练分布。

补充测量：唯一稳定差异是非受控输入

B 组三次都读了 js-uncontrolled-components.md，并把搜索输入从受控路径改成非受控路径。受控输入每次按键都会产生 JS 与原生之间的往返；在输入本身只用于触发搜索而不需要每一帧渲染时，非受控方案可以去掉这一层压力。

这是有价值的增量，但必须准确描述它的范围：它不是“受控输入永远错误”，也不是“加 Skill 后卡顿自动消失”。它只是为一个特定的高频输入场景提供了额外的优化方向，仍然需要用真实设备和 profiling 数据确认。

渐进披露有硬数字：省下 68%–72% 上下文

29 个可选 references 中，B1 读取 7 个，进入上下文 14,559 tokens；B2、B3 各读 6 个，进入 12,870 tokens。如果把 29 个全部灌入，则是 45,231 tokens，分别节省 68%、72%、72%。三次选中的文件高度一致：列表/FlashList、非受控组件、并发 React、内存泄漏、React profiling 和 FPS 测量。

这说明渐进披露不只是“把大文件拆小”。真正有效的是 Problem → Skill Mapping：先用问题分类表选出需要的页面，再读取少量 references。对多 Skill 项目，这可能比简单堆上下文更重要。

B 组改善了诚实度，而不是 checklist 分数

Skill 规定的流程是 Measure → Optimize → Re-measure → Validate。B 组三次都主动写明：当前环境没有设备和工具链，无法执行 flashlight measure、agent-device react-devtools profile 或 Perf Monitor，因此只能完成静态优化，不能声称性能已经被验证。A 组三次都没有主动说明验证缺口。

这是一种很现实的增益：Skill 让 agent 更清楚“给出代码”和“证明代码有效”不是一回事。对于性能任务，这种边界声明比再多一个 useMemo 更可靠。

和另外三套移动 Skills 怎么选

四轮 A 组中位数从 9 → 10 → 10 → 12。也就是说，裸模型对公开、经典的移动开发问题越来越强。选择 Skill 时不应只看 B 组满分，而应问：它是否提供模型无法凭常识知道的版本约定、内部流程、设备工具或组织规范？Callstack 在本轮的答案是“有一点，但不是 checklist 里的主要修复项”。

优点和缺点

优点

• 入口小。 826 tokens 的目录常驻上下文，安装成本低。
• 边界清晰。 13/13 命中且 0/7 误触发，RN 专有名词起到了路由护栏作用。
• 渐进披露做得实用。 Problem → Skill Mapping 能把 29 个 references 缩到 6–7 个。
• 性能证据资产独特。 12 张 profiler 截图不是装饰，而是诊断输出示例。
• 过程诚实。 明确要求测量、再测量和验证，而不是只给“看起来合理”的优化补丁。
• 适合复杂 RN 工程。 Brownfield、原生库、TV、导航和升级都比通用模型提示更有上下文。

缺点

• 对经典性能题的边际增益很低。 本轮 checklist 是 0 增益。
• 没有 E2E owner。 RNTL 组件测试不等于 Detox/Maestro 端到端回归。
• 规则执行不闭环。 299 次一层引用违规说明手工校验会漂移。
• 元数据不规范。 POWER.md 的 author/keywords 可能被标准解析器忽略。
• 缺少 freshness。 没有 updated、last_verified、review_by，版本敏感建议需要人工复核。
• 真实设备验证仍由使用者承担。 Skill 不能替代 profile、网络条件、低端 Android 和 iOS 真机测试。

实际使用建议

如果你正在维护 RN 应用

先安装并按任务触发，不要把全部 references 永久塞进系统提示。性能问题优先读取列表/FlashList、非受控组件、内存泄漏和 FPS 测量相关资料；导航问题再打开 react-navigation 的深层 references。每次生成补丁后，记录 RN、Hermes、Fabric/New Architecture、FlashList 和目标设备版本。

如果你在做 Brownfield 或原生库

Callstack 的迁移、原生库和 brownfield Skill 比通用“写一个模块”提示更有价值。但要把 iOS/Android 两边的构建日志、最低版本、CocoaPods/Gradle 配置和回滚方案交给真实 CI 验证。

如果你要做 E2E

不要因为 react-native-testing 被触发就认为端到端覆盖完成。明确补一套 Detox 或 Maestro 的 owner、设备矩阵、权限/登录/深链场景和截图回归策略。

如果你要评估是否值得安装

用自己的高频任务跑一次裸模型基线：如果裸模型已经稳定命中全部检查项，Skill 的价值可能在流程纪律、组织规范或少见版本约定，而不是更漂亮的代码。先做 A/B，再决定长期常驻。

最终判断

值得装，但要清楚它能给什么。

它是四家里最精简、触发最准确的 RN Skill 集合，尤其适合希望 agent 不要误接无关任务、又需要性能 profiler 和 React Native 工程经验的团队。它不是一个“让普通 RN 补丁自动变正确”的魔法开关：在本轮最经典的列表性能题里，裸模型已经三次满分。

Callstack 最值得复用的不是某一条 useMemo 建议，而是两种方法：用 Problem → Skill Mapping 做渐进披露；把 Measure → Optimize → Re-measure → Validate 写成不可跳过的流程。最该修的是把 /validate-skills 变成 CI，并给每个版本敏感 Skill 增加 last_verified 或 review_by。

最后，读者应把这篇文章理解为一个有边界的实验报告：它证明了路由准确率、上下文节省和特定输入优化的差异；它没有证明你的 RN 应用在真实设备上会更快，也没有替你完成安全审计、E2E、构建和发布。

参考资料

• Callstack agent-skills GitHub repository
• React Native documentation
• React Native Performance overview
• FlashList documentation