代码化标准：Vercel 的 57 条 React 规则对质量管控的启示

Vercel 发布了 57 条 React 性能规则。它们不是空泛的“编写高效组件”，而是具体到：“避免从 lucide-react 进行批量导入（barrel imports）”、“利用 Promise.all 并行化独立的 await 调用”、“对超过 50KB 的组件使用动态导入”。这些规则被分为 CRITICAL（关键）、HIGH（高）和 MEDIUM（中）三个等级。其编写标准达到了机器可以直接校验的程度。

大多数遇到这类规则的团队通常会做两件事之一：要么把它们扔进维基（Wiki），要么粘贴到编程代理（Coding Agent）的系统提示词中。但这两种做法都依赖于人类的记忆力来执行。

维基注定会悄无声息地失效。它就在那里，但没人会读。一位新开发者入职，提交了三个包含批量导入的 PR，没人发现，因为在审查时没人会特意去查这个。

代理提示词则有一种更隐蔽的失效模式。团队中并非每个人都使用相同的编码工具，也并非每个人都使用相同的配置。了解该规则的工程师会在使用代理时应用它，而不了解的人则不会。由于 PR 在粗看之下没问题，因此在代码审查阶段没有任何警示信号。

这两种方法都将标准仅仅视为文档。而文档只是建议。

适当的颗粒度

Vercel 的规则之所以有趣，不在于它们有多全面，而在于它们是按照“机器可校验”的级别编写的。

“编写高性能代码”是无法校验的，那只是个愿景。“避免从 lucide-react 进行批量导入”则是可校验的。导入要么存在，要么不存在。校验过程无需理解开发意图，只需读取文件即可。

大多数团队在这里走进了误区。当他们真正需要规则时，却写成了原则。“API 应当设计良好”无法变成检查项，但“每个新的 API 端点都需要速率限制”可以。

Vercel 已经完成了最艰难的工作，至少在 React 性能方面是这样。他们列举了违规项，使规则具体化，并按严重程度进行了分级。请将它们视为检查项，而不是指南。

代码化标准

这与“基础设施即代码”（IaC）的模式如出一辙：将存在于某人脑中或 Google 文档里的东西，搬进版本控制的代码仓库中，实现自动化运行。

每一个检查项都是仓库中的一个 Markdown 文件，它以机器可评估的精确度描述了一项标准。在 Continue 中，检查项以完整 AI 代理的形式运行：它们读取文件、运行命令并生成建议的补丁（diff）。输出结果会作为原生的 GitHub 状态检查显示在每个 PR 上。它要么静默通过，要么在失败时直接附带修复建议。

其核心特质在于：它不会遗忘，不会在周五下午感到疲倦。它会在每个 PR 上运行，无论是由谁发起或由谁审查。无论是新来的开发者，还是撰写这些规则的资深工程师，都受到同一标准的约束。

将其与代码审查评论对比一下。审查评论只存在于单个 PR 中，它必须在随后的每个 PR 中被重新注意、重新沟通和重新强调。那不是强制执行，那只是记忆力很差的建议。

信任弧

你不必第一天就将全部 57 条规则编码完成。

从 CRITICAL（关键）级别开始。Vercel 的关键规则涵盖了会导致真正、可衡量损失的违规行为：例如导致包体积激增、阻塞渲染或以直接影响用户的方式破坏服务器组件的行为。这大约有 5 到 6 条规则。

将这些编写为检查项。运行几个迭代（Sprint）并观察它们的捕获情况。你会发现，那些原本因为审查人员专注于架构而未扫描导入从而漏掉的 PR，现在被检查项捕获了。这就是检查项的价值所在。

一旦团队确信这些检查项能够在没有误报的情况下捕获预期的错误，再扩展到 HIGH（高），然后是 MEDIUM（中）。每一层级都在为下一层级的信任积累基础。

另一种做法是在第一天就全部启用 57 条规则。这样，工程师们会在检查项证明自身价值之前，就淹没在调试误报中。这就是“代码化标准”在实施前夭折的原因。

这实际上改变了什么

Vercel 的 57 条规则已经发布。那些只读过并手动应用它们的团队，执行起来必然是不一致的。这并非因为某人粗心，而是因为人类无法像机器那样保持状态。

这些规则中凝聚的宝贵知识是血淋淋的教训换来的：让团队措手不及的包体积、进入生产环境的性能回归、审查人员反复指出同一类错误直到有人将其写下来。

写下来只是第一步。让它在每个 PR 上运行才是第二步。

从一条规则开始，看看它的运行效果。您可以 Fork Vercel 的性能实验室项目，创建一个 PR，并观察这些检查项如何评估您代码中的 React 服务器组件模式。