biome-formatting（Biome代码格式化）Skill 是什么？如何下载？

Biome代码格式化Skill：用 Rust 级速度统一 JS/TS/JSON 代码风格

一句话定位：这是把 Biome 格式化器的命令、配置项、风格预设与迁移路径系统化沉淀下来的 AI 技能，让 AI 助手能直接给出可落地的格式化方案，而不是泛泛而谈。
覆盖范围：JavaScript / TypeScript / JSON / CSS 的格式化，包含全局配置、语言级配置、忽略规则、行宽与缩进策略、Prettier 迁移、CI 与编辑器集成。
使用方式：该技能在清单中标注为不可由用户直接调用（user-invocable: false），由 AI 在识别到"格式化 / 代码风格 / 迁移 Prettier"等任务时自动加载并据此作答。
技术底座：Biome 用 Rust 编写，定位是"类似 Prettier 的意见化、快速的代码格式化，但性能更好"，同时覆盖格式化与代码检查。
最适合：正在统一团队代码风格、打算从 Prettier 迁出、或需要把格式化纳入 CI 和预提交钩子的前端与全栈团队。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

这个技能的中文名是 Biome代码格式化Skill，英文名（同时也是技能标识名）是 biome-formatting，技能 ID 为 13886。它的文件名标记为 biome-formatting，技能描述是"使用 Biome 快速格式化 JavaScript/TypeScript 代码时使用，包括模式、选项和代码样式管理"。

它解决什么问题？ 现实中的格式化问题往往不是"不知道有格式化工具"，而是：

团队里每个人对 quoteStyle、trailingCommas、semicolons 的偏好不同，配置散落、互相冲突；
从 Prettier 迁移到 Biome 时，配置项名称对不上，不知道该写 singleQuote: true 还是 quoteStyle: "single"；
生成的代码、构建产物被误格式化，浪费 CI 时间；
想要 Standard / Google / Airbnb 这类风格，却不知道对应的 JSON 该怎么写。

该技能把这些场景下需要的信息——命令、配置项、可选值、示例代码、迁移步骤、故障排查——整理成了结构化的知识，AI 调用后能直接给出"可以直接粘贴进项目"的答案。

关于"一键安装 AI 技能"的思路：AI 技能本身的安装入口与具体命令，请以你所使用平台的官方说明为准（本技能详情中未提供平台侧的安装命令）。安装完成后的逻辑是：技能进入技能清单 → AI 在遇到格式化相关任务时自动加载 → 你只需要用自然语言描述需求。

项目侧的 Biome 安装则是有明确命令的，按详情内容照做即可：

安装前提：本地具备 Node.js 与 npm 环境，且在目标项目根目录下操作。
安装 Biome 本体：
```
npm install -D @biomejs/biome
```
初始化配置文件：
```
npx biome init
```
验证是否生效：先用只检查、不修改的模式跑一遍，确认工具能识别到文件：
```
npx biome format .
```
如果输出中列出了待格式化的文件与差异，说明已生效；随后再执行 npx biome format --write . 真正写入改动。
（可选）编辑器集成：在 VS Code 的 settings.json 中把默认格式化器设为 biomejs.biome，并开启 editor.formatOnSave。

该技能的主要功能和特点

命令层全覆盖：既有 biome format --write . 这种"格式化并写入"，也有 biome format . 这种"只检查不修复"，还有 biome check --write . 这种"检查 + 格式化一起做"，以及专供 CI 使用的 biome ci .。此外支持通过标准输入格式化：
```
echo "const x={a:1}" | biome format --stdin-file-path="example.js"
```
全局格式化配置：enabled、formatWithErrors、indentStyle、indentWidth、lineEnding、lineWidth、attributePosition 七个选项，每个都给了可选值与默认值，避免"猜默认行为"。
语言级细粒度控制：JavaScript/TypeScript 可单独设置 quoteStyle、jsxQuoteStyle、quoteProperties、trailingCommas、semicolons、arrowParentheses、bracketSpacing、bracketSameLine、attributePosition，每一项都配有前后对比的代码示例。
现成的风格预设：直接提供 Prettier-like、Standard/XO、Google、Airbnb 四套配置，复制即可用，省去逐项调试。
Prettier 迁移路径：给出 .prettierrc.json 与 Biome 配置的逐项对应关系，以及"安装 → init → 对齐设置 → 全量格式化 → 改脚本 → 卸载 Prettier"的六步迁移流程。
忽略策略分层：既支持用 // biome-ignore format: 在代码块级别保留原样（如矩阵、ASCII 艺术横幅），也支持在配置中用 formatter.ignore 只忽略格式化、或用 files.ignore 同时忽略检查与格式化。
大型仓库优化：支持 --changed 只处理变更文件、--since=main 处理指定提交范围，以及 overrides 按文件类型覆盖配置（例如 JSON 用 120 列、Markdown 用 80 列）。
故障排查清单：针对"文件没被格式化"“格式化结果反复横跳”"性能不佳"三类高频问题给出排查顺序。

和普通"随手一搜"的差别在哪？ 普通搜索往往只能拿到零散片段，或者拿到的是 Rome 时代（Biome 前身）的旧配置。这个技能的优势在于配置项名称、可选值、示例、迁移映射是同源的，AI 调用后给出的答案内部自洽，不会出现"选项名对不上"的低级错误。

如何使用该技能？

该技能由 AI 在相关任务中自动加载，你不需要手动"触发"，只需要把需求说清楚。下面是一套推荐的使用流程：

第 1 步：先让 AI 帮你确定风格基线。 可以这样提问："我们团队想从 Prettier 迁到 Biome，原来是单引号、2 空格缩进、行宽 80、尾随逗号 all，请给我等效的 biome.json。"AI 会依据技能中的映射关系，输出类似：

{
  "formatter": { "indentWidth": 2, "lineWidth": 80 },
  "javascript": {
    "formatter": {
      "semicolons": "always",
      "quoteStyle": "single",
      "trailingCommas": "all"
    }
  }
}

第 2 步：把配置落到项目里。 拿到 JSON 后写入项目根目录的 biome.json，然后执行 npx biome init（若已手动建好配置文件可跳过）与 npx biome format --write . 完成首次全量格式化。建议首次格式化单独提交一个 commit，避免和业务改动混在一起。

第 3 步：用"只检查"模式接入 CI。 在 CI 中运行 biome ci .，它会同时校验代码检查与格式化结果，一旦不符合规范就失败，从而把风格约束从"靠自觉"变成"靠流水线"。本地对应的检查命令是 biome format .。

第 4 步：处理"不想被格式化"的部分。 如果是某个代码块需要保留原样，让 AI 帮你加注解：

// biome-ignore format: 保留矩阵排版
const matrix = [
  [1, 0, 0],
  [0, 1, 0],
  [0, 0, 1]
];

如果是整个目录（如 dist、node_modules、*.min.js），则写进 files.ignore。

第 5 步：接入编辑器与预提交钩子。 让 AI 生成 VS Code 的 settings.json 片段（editor.defaultFormatter: "biomejs.biome"、editor.formatOnSave: true），以及 package.json 里的脚本：

{
  "scripts": {
    "format": "biome format --write .",
    "format:check": "biome format ."
  }
}

输出说明：AI 的产出通常是三类——可直接粘贴的 biome.json 配置、可直接执行的命令行、以及带前后对比的代码示例（例如 arrowParentheses: "always" 与 "asNeeded" 的差异）。你拿到后先小范围验证，再全量推行。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
Biome（本技能所覆盖）	Rust 编写的、意见化的格式化 + 代码检查一体化工具链	格式化 JS/TS/JSON/CSS，附 `check`、`ci` 等组合命令，配置项齐全，支持 Prettier 配置映射	需 Node/npm 环境，`npm install -D @biomejs/biome` 后 `biome init` 即可，配置文件单一	希望"一个工具搞定检查与格式化"、追求执行速度、准备从 Prettier 迁移的项目	优势：官方定位为"类似 Prettier 但性能更好"，配置与检查同源，CI 命令开箱可用；不足：生态与插件数量不及 Prettier 成熟，部分冷门语法或框架的支持需要留意
Prettier	老牌意见化格式化器，生态最广	多语言格式化，插件体系庞大，编辑器支持完善	安装简单，`.prettierrc` 生态成熟	多语言混合项目、依赖大量社区插件、团队已经沉淀了稳定配置	优势：兼容面最广、资料最多；不足：与代码检查是两套工具，需额外配 ESLint，执行速度在超大型仓库中可能成为 CI 瓶颈
ESLint（含格式化规则）+ Prettier 组合	检查为主、格式化为辅的经典双工具链	代码质量规则 + 风格规则 + Prettier 负责排版	需要两份配置文件、处理规则冲突（如 `eslint-config-prettier`），维护成本较高	需要强代码质量约束、规则高度定制化的项目	优势：规则可深度定制，历史项目存量大；不足：配置复杂、两套工具职责重叠易冲突、整体执行相对更慢
dprint	同为 Rust 编写的快速格式化器	插件化架构，支持多种语言格式化	需安装 CLI 或编辑器插件，配置为 JSON	追求极致速度、语言种类多且愿意接受插件模式	优势：速度快、插件可按需加载；不足：JS/TS 生态的一体化检查能力不如 Biome 完整，社区资料相对少

选型建议：如果你要的是"格式化 + 检查一体、配置集中、能进 CI"，Biome 是当前性价比最高的选择；如果你依赖大量 Prettier 插件或需要格式化非 JS 系的冷门语言，Prettier 仍更稳妥；如果是历史项目且 ESLint 规则已经深度定制，可以先保留 ESLint 做质量检查、把排版交给 Biome，逐步演进。

该技能的典型应用场景与实际体验情况

场景一：前端团队统一代码风格。 角色是前端 Tech Lead，痛点是 6 个人的仓库里单引号双引号混用、尾随逗号时有时无，Code Review 里一半评论都在吵格式。使用方式是让 AI 输出一份"Airbnb 风格"的 Biome 配置（quoteStyle: "single"、jsxQuoteStyle: "double"、trailingCommas: "all"、lineWidth: 100），写入根配置后用 overrides 给不同子包做行宽覆盖。 实际体验：上手难度低，配置粘上去就能跑；效果上最明显的是 Review 噪音大幅下降。注意事项：首次全量格式化会产生一个巨大的 diff，务必单独提交，并提前通知所有分支负责人尽快 rebase，否则后续合并会非常痛苦。

场景二：从 Prettier 迁移到 Biome。 角色是负责工程效率的后端兼工具链同学，痛点是 Prettier 在大型仓库里跑全量检查耗时偏长，且和 ESLint 的配置互相打架。使用方式是让 AI 给出"迁移六步"：装 Biome → biome init → 按 .prettierrc.json 逐项映射 → biome format --write . → 改 package.json 脚本 → 验证后卸载 Prettier 并删除 .prettierrc.json、.prettierignore。 实际体验：映射关系清楚，semi/singleQuote/tabWidth/trailingComma/printWidth 到 Biome 选项的对应一目了然。注意事项：不要在迁移当天就删 Prettier，先在分支上验证一轮，确认编辑器保存格式化、CI 检查、预提交钩子三条链路都正常后再移除依赖。

场景三：把格式化纳入 CI 与预提交钩子。 角色是 DevOps / 平台工程师，痛点是"本地格式化靠自觉，合并后又出现风格漂移"。使用方式是用 biome ci . 作为流水线检查项，本地配置 editor.formatOnSave 与提交前钩子自动格式化。 实际体验：ci 模式把"检查 + 格式化"合并成一条命令，流水线配置显著简化。注意事项：CI 中应使用只检查模式而非 --write，否则流水线会"自动改代码"而不报错，问题被掩盖。

场景四：大型单体仓库的性能优化。 角色是全栈开发者，痛点是仓库文件数上万，全量格式化太慢。使用方式是改用 biome format --write --changed 只处理变更文件，或在需要时用 --since=main 处理某个提交范围，同时在 files.ignore 中排除 node_modules、dist、*.min.js。 实际体验：增量格式化让日常开发几乎无感。注意事项：--changed 依赖版本控制信息，若在 CI 的浅克隆环境下使用，需要确认能正确取到对比基线，否则可能"什么都没格式化"。

该技能能为用户带来的价值

第一，把"配置决策"的一次性成本降到最低。 缩进用空格还是制表符、行宽 80 还是 100、尾随逗号 all 还是 es5——这些看似小事，往往要开会讨论半小时。技能里不仅有四套成熟风格预设，还给出了行宽的三档策略（80 保守 / 100-120 平衡 / 120+ 宽松）和缩进两种方案的适用理由，让团队可以"选一个然后往前跑"，而不是反复纠结。

第二，把"迁移风险"变成可执行的步骤。 从 Prettier 迁出最大的成本不是改配置，而是不知道改哪一项、改完对不对。技能提供的是逐项对应关系加上六步迁移流程，把一次高风险迁移拆成了可以逐步验证的动作，大幅降低了回滚概率。

第三，把"风格约束"从人工评审转移到自动化。 通过 biome ci .、编辑器保存即格式化、预提交钩子三层防线，格式问题在进入 Code Review 之前就被消化掉。虽然本技能未给出具体耗时数据，但可以确定的是：每一次因为格式问题产生的 Review 往返，都是可以被省下的。

第四，长期看是一份可传承的团队规范文档。 最佳实践里的十条（一致配置、平衡行宽、使用空格、CI 启用、预提交钩子、记录选择、忽略生成文件、增量格式化、编辑器集成、审查差异）和常见陷阱里的十条（配置冲突、格式化生成代码、行宽过严、混用制表符与空格、无 CI 检查等），本质上是一份"团队格式化操作手册"，新人入职可以直接照做。

第五，降低工具链维护门槛。 格式化与代码检查合并到一个工具、一份配置文件，意味着更少的依赖、更少的版本冲突、更少的"两个工具打架"的排查时间。

常见问题 FAQ

Q1：这个技能怎么安装？需要我手动调用吗？ A：该技能在技能定义中标注为 user-invocable: false，即不由用户直接触发，而是由 AI 在识别到格式化、代码风格、Prettier 迁移等相关任务时自动加载并据此作答。技能本身的平台安装入口与命令请以你所使用平台的官方说明为准。项目侧的 Biome 安装是独立的，执行 npm install -D @biomejs/biome 加 npx biome init 即可。

Q2：这个技能收费吗？ A：技能详情中未包含任何定价或授权信息，是否收费取决于你所使用的 AI 平台的计费规则，请以官方说明为准。技能所依赖的 Biome 本身是独立的开源项目，其许可证与使用条款同样以 Biome 官方说明为准。

Q3：适合谁用？纯后端或者写 Python 的同学有用吗？ A：主要面向使用 JavaScript / TypeScript 项目的前端与全栈开发者、负责工程效率与 CI 的同学、以及正在做团队代码规范落地的 Tech Lead。由于该技能覆盖的语言是 JS / TS / JSON / CSS（详情中分别给出了这三种语言的配置段落），纯 Python 或 Go 项目并不适用。

Q4：和 Prettier 相比，我该怎么选？ A：用三个问题判断：① 你的项目是否严重依赖 Prettier 的社区插件来格式化冷门语言？是则继续用 Prettier。② 你是否希望"格式化 + 代码检查"只维护一份配置？是则 Biome 更划算。③ 你的 CI 是否因为格式化而变慢？是则值得迁移评估。若决定迁移，直接让 AI 走技能中的六步迁移流程，并在验证通过后再删除 Prettier 依赖。

Q5：为什么我执行了格式化命令，文件却没有变化？ A：按技能中的排查顺序检查四点：① 配置里 formatter.enabled 是否为 true；② 文件扩展名是否受支持；③ 文件是否被 formatter.ignore 或 files.ignore 的模式命中（常见误伤如 **/dist/**）；④ 是否被版本控制集成排除。另外如果格式化结果反复横跳，请确认全仓库只有一个 biome.json 作为真实来源，并统一团队成员的 Biome 版本。