给前端质量闸口换成 Biome 前，我会先拆清 format、lint 和 assist 边界

一个前端仓库用久之后，代码风格、lint 规则、导入排序和 PR 校验很容易长成几套工具各管一段的状态。Prettier 负责格式，ESLint 负责规则，IDE 插件再做一部分自动整理，最后 CI 只负责报红。Biome 的吸引力在于它把 formatter、linter、assist 和 CI 命令放进同一个工具链里，适合把这些零散入口收敛起来。不过我不会一上来就替换全部规则，而是先把每一层的责任拆清楚，避免一次迁移把开发体验和合并闸口一起打乱。

原创示意图：从本地保存、自动修复、Pull Request 闸口到 CI 只读校验的分层链路。来源：Codex image generation

第一层先只管可预测格式

我会先从 biome format --write 开始。官方 formatter 文档强调它面向 JavaScript、TypeScript、JSON、CSS 等前端常见文件，并且提供独立命令入口。这个阶段的目标很简单：让团队确认保存后的缩进、换行和引号策略是否可接受。格式化结果应该尽量没有业务语义，适合放进保存动作和一次性迁移提交里。这样做的好处是审查者可以把格式化 diff 和真实逻辑 diff 分开看，也能减少后续 lint 迁移时的噪声。

第二层再接 lint 自动修复

格式稳定后，我会再引入 biome lint --write 或 biome check --write。Biome 的 linter 文档把规则分组、严重级别和配置入口都放在 biome.json 里，适合先挑低风险规则落地。这里要特别留意自动修复边界。比如无用导入、简单风格问题可以交给工具；牵涉代码意图、异步控制、可访问性和类型假设的规则，我会先只报警，不急着批量修。开发者需要相信工具不会悄悄改掉行为，质量闸口才有机会长期保留。

assist 更适合放在人工动作里

Biome 的 Assist 文档把这类能力定位成代码动作，可以通过 IDE 或 CLI 触发。我的理解是，assist 很适合做导入整理、局部重构和编辑器里的快捷动作，但它不应当和保存格式化混在一起。保存动作要轻，PR 前的修复可以更完整，CI 则应该以只读校验为主。这样分层之后，开发者日常写代码不会被过重的自动动作打断，评审人也能从失败日志里判断到底是格式问题、规则问题，还是需要人工解释的重构建议。

CI 里只做可复跑的判断

接入 Pull Request 时，我会使用官方 continuous integration recipe 里的思路，把 biome ci 放进合并前检查。它适合在 CI 环境里做只读验证，发现格式、lint 或导入整理问题时直接失败。我的默认顺序是本地保存跑 format，提交前可选跑 check write，PR 里跑 ci。这样 CI 不会替开发者改文件，只给出可复现结果。规则需要收紧时，也先在本地和预提交阶段试一周，再升级成必须通过的合并条件。

迁移时保留旧工具的退出路线

Biome 提供从 ESLint 和 Prettier 迁移的官方指南，但真实项目里常会遇到插件规则、框架专用配置和历史忽略文件。我的做法是先选一个活跃 package 试点：补 biome.json，限定 include 范围，跑一次格式化专用提交，再开 lint 报警模式，最后才替换 CI。旧工具不急着删除，先保留到两个版本周期，等常见失败都能解释清楚，再把重复检查合并。这样的迁移节奏看起来慢一些，但它能把工具切换变成可回滚的工程动作。

第一周我会看什么指标

第一周只看三件事：保存动作是否稳定，PR 失败是否能在本地一条命令复现，规则误报是否集中在少数目录。如果这三件事都顺，Biome 就可以从试点 package 扩到主仓库；如果失败集中在框架插件或历史代码风格上，就先继续缩小范围。工具链治理的关键不在于少装几个包，而在于让开发者知道每一个自动动作发生在哪一层、失败后该运行哪条命令、什么时候需要人工判断。