AI 时代下 JS 的 Lint 工具能多快?

前言

前段时间 Cloudflare 写了一篇文章叫做《How we rebuilt Next.js with AI in one week》(原文参考: https://blog.cloudflare.com/vinext/)。

大意是 CF 的工程师用了价值 1100 亿美刀的 token 重写了 next.js，替换成了 vite 底层构建引擎，能有很快的性能提升、开发体验等等。

于是正巧赶上最近 OpenAI Codex Token 大放水，笔者前几个月前通过 OpenAI 的开源计划申请到了半年的 Codex Pro 20x 的套餐，最近加上疯狂额度重置，于是决定尝试结合 AI 来干一件类似的事情。

结论

于是在过去三天，我用家里空闲的 Mac Mini 以及 GPT 5.5 Fast / High 从零开始重构一个新的 Lint 工具，最终构造出了目前还处于初步阶段的 utoo-lint: https://github.com/fireairforce/utoo-lint。

在早期的基准测试中，utoo lint 目前对比社区主流的一些 rust 构造 lint 工具具备一些性能优势，同时在大部分场景下对比 eslint 能有 100x 以上的性能提升:

目前 utoo-lint 也完成了大部分 eslint rule 的 port 适配工作，目前整体约支持了大概 280+ 的规则集。

这整个过程消耗了大约 20 亿左右的 token，重置了约两次 codex pro 周用量:

技术路线

utoo-lint 基于 Zig 语言研发，之所以选择 Zig 是因为看到了 Yuku 这个 Parser(https://github.com/yuku-toolchain/yuku):

它的 node api parser 本身要比 swc / oxc 这些工具链要快:

同时 AST 结构也符合 ESTree 规范，于是在这个 parser 的基础上，笔者决定结合最近 AI 大战疯狂送 token 的 GPT 5.5 pro 开始一路开车之路。

在很早之前完成了一个初步的依赖架构搭建之后(通过 git submodule yuku)，于是这几天的 vibecoding 主要成了相关 lint rule 的实现和相关 Node API 的适配工作:

三天的时间，完成了大约 300 个左右的 lint rule 的适配(当然一些 lint 的规范、报错、诊断并没有完善的很好)。

现状 & 未来

这里先明确指出: 目前 utoo-lint 还处于实验阶段。目前笔者还在慢慢孵化中，目前我甚至还没给他发一个正式的 npm 包，所有测试都在仓库的 benmark 文件中本地完成(https://github.com/fireairforce/utoo-lint/tree/main/benchmarks)。

同时关于目前已经支持的 lint rule 在 utoo-lint 的 README 中可以找到: https://github.com/fireairforce/utoo-lint/blob/main/docs/rule-status.md

未来会结合 yuku parser 去做更多的 lint rule 的支持以及适配，例如 vue dsl、axml 小程序 dsl 的 lint rule 的适配，同样 utoo lint 本身也会去完成更多的 lint rule 的 port 支持。

type-aware lint 呢？

目前对于一些简单的不需要类型推导的 lint rule，utoo lint 已经完成了初步的支持，这里主要对齐 typescript-eslint里面的一些规则集，这里同样可以在 README 里面找到。

对于 type-aware lint 的支持后续考虑按照 Biome 的路线演进，目前 yuku 也提供了 semantic 分析的支持，不过目前来看，这一目标可能还需要一定的时间去演进。

总结

这篇文章其实并不算一篇对于 utoo-lint 的完整介绍，等后续笔者有空之后 node api 发布以及相关使用文档、迁移文档完成之后会写一篇更完整的文章来介绍一下。

utoo