背景

“传统的五子棋只是把五个子连成一条线，而技能五子棋则是在传统的五子棋中加入了技能。”

几个月前，“技能五子棋”一度在社交平台出圈。

它之所以有趣，并不只是玩法变复杂了，而是规则本身发生了变化：

胜负不再只取决于落子，而是取决于你如何使用能力。

有意思的是，类似的变化，也正在软件工程和AI领域发生。

如果回看近几年的技术演进路径，会发现一个非常清晰的趋势：

-2024年：Prompt工程

我们学习如何“把话说清楚”，让模型更好地理解意图。

-2025年：上下文工程（Context Engineering）

我们开始关注如何构建长期、稳定、结构化的上下文，让模型“理解得更全面”。

-2026年：Skills工程

不再只是临时指令，而是把经验、规则、最佳实践沉淀为可复用、可组合的能力单元。

所谓Skills，本质上就是把“人脑里的经验”产品化、模块化。

也正是在这样的背景下，一个由Vercel官方发布的React Best Practices Skill开始进入我的视野。

这个Skill是什么

React Best Practices Skill是一个将 React/Next.js 常见最佳实践系统化的skill集合，核心目标是：

👉在开发过程中，主动识别潜在问题，并给出可执行的最佳实践建议

覆盖的方向主要包括：

  • 数据获取（async/并行/cache）

  • Bundle&构建优化

  • 重渲染与渲染性能

  • 第三方库加载时机

  • Next.js Server/Client组件使用方式

为什么这些问题总是反复出现

在实际工程中，React性能优化往往是被动的。

一个常见的节奏是：

  • 发版之后，页面变慢了

  • 指标下降，用户开始感知卡顿

  • 团队开始“追症状”，到处补优化

这种方式不仅成本高，而且很容易优化错地方。

而在多个真实生产代码库中，长期反复出现的根因其实高度一致：

-本该并行的async工作，被无意中写成了串行

-客户端bundle体积随着迭代不断膨胀

-组件比实际需要渲染得更频繁

-不必要的计算和第三方代码在首屏就被加载

这些都不是“微优化”，而是会直接表现为：

  • 等待时间变长

  • 页面jank

  • 每一次用户会话都在反复支付的性能成本

为什么会对它感兴趣

一个主要的原因是：它和当前官网项目的技术栈高度契合。

在landing过程中接触到的官网项目：

  • 使用Next.js Page Router

  • 有SSR/RSC/性能指标要求

  • 迭代周期短，需要在「规范性」和「开发效率」之间取得平衡

而React Best Practices Skill覆盖的内容，几乎正好命中了这些项目中最容易被忽略的部分：

  • 表面上“写得能跑”

  • 但长期来看，会逐渐累积性能和维护成本的地方

其实，React Best Practices Skill并不是我接触到的第一个Skill。

在此之前，我也了解过像UI UX Pro Max这类更偏设计与体验侧的Skill，它们在交互一致性和设计规范上同样很有价值。

但React Best Practices Skill吸引我的是：

  • 它关注的不是抽象原则，而是具体到代码层面的决策

  • 它解决的不是“好不好看”，而是“在当前技术栈下是不是一个更稳妥的实现”

在Cursor中如何使用这个

为了尽量贴近真实开发场景，我选择直接在Cursor中使用React Best Practices

整个过程并不复杂

Step 1：切换到Nightly更新渠道

Skills功能目前需要Cursor的Nightly版本才能完整使用。

操作步骤如下：

  1. 打开Cursor设置

    • macOS：Cmd + Shift + J

    • Windows/Linux：Ctrl + Shift + J

  2. 进入Beta选项卡

  1. 将Update Channel切换为Nightly

  2. 等待更新完成后重启Cursor

⚠️注意：一定要确认已经更新到最新的Nightly版本，否则后续Skills相关配置可能不会生效。

Step 2：开启Skills功能（通过cursor rules）

更新完成后，需要在Cursor的rules中引入Skill。

官方提供的React Best Practices已经被整理成通用的Agent Skills，可以安装到：

  • Cursor

  • Claude Code

  • Codex

  • Opencode

等多种coding agent中。

在cursor-rules（或对应规则配置文件）中，import React Best Practices Skill的GitHub项目地址，示意如下：

或者使用提供的CLI安装Skill：

该命令会自动：

  • 拉取vercel-labs/agent-skills仓库

  • 将React Best Practices等Skill安装到本地Agent配置中

  • 使其可被Cursor等编辑器识别和使用

Step3：在Prompt中显式启用Skill

完成rules配置后，还需要在实际使用时通过Prompt明确声明使用某个Skill。

例如在对话或编辑指令中加入类似：

使用React Best Practices Skill，帮我检查这段Next.js代码是否存在性能或最佳实践问题

或者在重构场景中：

基于React Best Practices Skill，优化当前组件的渲染和数据获取方式

通过这种方式，Skill会在理解上下文时：

  • 以「React/Next.js最佳实践」作为核心判断依据

  • 主动识别潜在问题并给出针对性的建议

实验设计：用Demo验证Skill的性能提升价值

实验目标

量化评估使用React Best Practices Skill前后，Next.js项目在以下方面的变化：

  • 构建性能

  • 包体积

  • 常见性能问题数量

  • 开发过程中的问题暴露速度

实验方案

环境

我创建了两个功能完全一致的Next.js Demo：

两者遵循：

  • 相同功能

  • 相同依赖版本

  • 相同测试环境

典型测试场景

实验中刻意覆盖了一些真实项目中非常常见的问题：

  • 串行数据请求导致的瀑布流

  • Barrel imports（如lodash）导致的bundle膨胀

  • 重型组件在首屏被加载

  • 缺少memo导致的重复渲染

  • 第三方库过早初始化，阻塞hydration

这些问题有一个共同点：

  • 在单次开发中很容易被忽略

  • 但一旦进入主干，就会在每一次用户访问中持续放大成本

对应的优化方向全部来自skill给出的建议。

实验代码

被测Demo

基于Next.js 14+React 18+TypeScript实现功能

  1. 服务端数据获取

    1. 在服务端组件里调用fetchUserData、fetchProducts、fetchAnalytics（模拟 API），拿到用户、产品、分析数据。

  2. 混合渲染

    1. 首页page.tsx：服务端组件，负责拉数据。

    2. UserProfile、ProductList、Analytics：’use client’客户端组件，负责交互和展示。

  3. 三个业务模块

    1. 用户资料：头像、姓名、邮箱、计数按钮、在线状态切换。

    2. 产品列表：过滤（价格>100）、排序、列表展示，并挂一个“重型组件”。

    3. 分析数据：展示浏览量、点击量、转化数，并模拟分析库打点（如page_view）。

  4. 模拟API

    1. lib/api.ts里用setTimeout模拟延迟（约400–600ms），返回固定结构的JSON，模拟真实接口。

测试脚本

measureBuildTime：测量构建耗时+成功状态

  • 在跑build前后记录时间戳

  • 用差值算buildTime（秒）

  • 同时携带build是否成功（来自runCommand）

calculateBundleSize：统计.next/static产物体积

计算：

  • .next/static/chunks的总大小（认为是JS）

  • .next/static/css的总大小（CSS）

  • 并输出MB/KB方便阅读

measurePerformance：单个项目的完整流程编排

  1. 检查项目目录存在

  2. 检查node_modules是否存在，不存在就npm install

  3. 清理.next（防止上一次构建残留影响结果）

  4. 跑measureBuildTime

  5. 如果build成功，跑calculateBundleSize

  6. 把结果写入results/<project>-metrics.json

generateComparisonReport：对比两个项目并计算提升

读取两个JSON结果文件，然后计算对比：

  • buildTime的提升百分比

  • bundleSize/jsSize的提升百分比（如果baseline或optimized没bundle数据就N/A）

提升公式：

并且把对比JSON写入：

  • results/comparison-report.json

同时也在控制台打印一个“报告摘要”，便于跑完立刻看到结果。

main：测两个项目+生成对比报告

  • 逐个项目测量

  • 两个项目都有结果才生成对比报告（避免其中一个失败导致报表数据不完整）

最后输出“测试完成”。

实验结果

构建时间对比

项目 构建时间
Baseline 11.71s
Optimized 8.31s
提升 ≈ 29% ⬇️

Skill在bundle拆分、动态导入等方面的建议，对构建时间的提升有明显帮助。

Bundle 体积变化（Optimized）

通过：

  • 移除lodash

  • 使用原生方法

  • 动态导入重型组件

有效控制了首屏负担。

性能问题数量对比

问题类型 Baseline Optimized
串行数据获取 ✅ ❌
Barrel Imports ✅ ❌
不必要重渲染 多处 0
过早加载第三方库 ✅ ❌

Skill在问题识别准确率上表现很好，基本都命中了我刻意埋下的“坑”。

结论与思考

Skill的价值体现在哪里？

  1. 将隐性经验显性化

  2. 很多问题并不是“不会写”，而是“不容易意识到这是问题”。

  3. 对Next.js项目尤其友好

  4. 不只是React通用建议，而是结合了RSC/Page/App Router的真实场景。

补充实验：用Demo验证Skill的工程价值

可能可以尝试，基于不同的模型，执行的同样的任务，看代码的输出是否一致

附录