用AI辅助写代码已经是现在开发者的日常操作，但一个普遍的困扰是：模型吐出来的代码风格千奇百怪。同样是JavaScript，有的地方用单引号，有的地方用双引号；Python代码里缩进一会儿是2个空格一会儿是4个空格；长行该换行的不换行，注释对齐方式也各不相同。如果团队本身有代码规范，这些代码直接提交上去，Code Review时会被格式问题淹没，真正的逻辑问题反而没人注意。解决这个问题的核心思路很简单：不要靠人去改格式，让工具去改。前端的答案是Prettier，Python的答案是Black，这两款工具的共同特点是"没有多少可配置项、说一不二"，特别适合用来收编AI生成的不规范代码。
为什么AI生成的代码需要专门的格式化流程
传统项目里，格式化工具解决的是"团队成员风格不统一"的问题，而在AI辅助开发时代，问题变成了"同一个开发者每次生成的代码风格都不统一"。大模型是基于概率生成的，它在训练数据里见过无数种风格，输出时会把这些风格混杂在一起。比如同一次对话里，它可能先给你一段用分号结尾的JS代码，紧接着又给一段不带分号的；Python代码里字典的花括号内换行规则前后两段完全不同。
更麻烦的是，如果把没格式化的代码直接提交，Git diff里会出现大量纯格式改动，后续做代码合并或者追溯某次改动的真实意图时，这些噪音会严重干扰判断。所以正确的做法是：AI生成代码进入项目前，先过一遍格式化工具，保证进入仓库的代码永远是统一风格，diff里出现的就只剩下真正的逻辑变化。
Prettier和Black能胜任这个任务，还因为它们都是"观点鲜明"的工具。Prettier官方文档明确说自己的目标就是终结关于风格的争论，可选配置极少；Black更是号称"The Uncompromising Code Formatter"，几乎不给用户配置余地。这种设计哲学用在AI生成代码上特别合适——没有讨价还价的空间，格式一次到位。
Prettier的安装配置与AI代码收编
Prettier主要覆盖JavaScript、TypeScript、CSS、HTML、JSON、Markdown等前端生态的文件格式化。安装非常简单，作为开发依赖装进项目即可：
npm install --save-dev --save-exact prettier
然后在项目根目录创建一个配置文件，常见的格式有.prettierrc、prettier.config.js等。针对AI生成代码的特点，建议显式声明几个关键配置，避免模型默认行为带来的混乱：
{
"semi": true,
"singleQuote": true,
"tabWidth": 2,
"printWidth": 100,
"trailingComma": "es5",
"arrowParens": "always"
}这里几个配置项的作用值得说明。semi控制是否在语句末尾加分号，AI生成JS代码时经常在这一点上摇摆不定，显式声明后一次统一。printWidth设为100是因为AI倾向于生成很长的链式调用，不设上限的话一行代码可能拖到两百个字符，可读性极差。arrowParens设为always则是强制箭头函数参数始终带括号，避免出现x => x * 2和(x) => x * 2混用的情况。
配置完成后，可以用命令行对整个项目或单个文件做格式化：
# 格式化整个src目录
npx prettier --write "src/**/*.{js,ts,jsx,tsx,css,json}"
# 只检查哪些文件不符合规范，不实际修改
npx prettier --check "src/**/*"--write会直接改写文件，--check常用于CI流水线里做卡点：格式不合格就不让合并。日常使用中，更推荐配合编辑器插件实现"保存即格式化"，VS Code里装上Prettier插件后，在设置中勾选Format On Save并指定Prettier为默认格式化器，AI生成的代码一粘贴进来，Ctrl+S一下就干净了。
Black接管Python代码的格式统一
Python对格式的要求比其他语言更苛刻，因为缩进直接影响语法。AI生成的Python代码偶尔会出现tab和空格混用的情况，直接运行会报TabError。Black能彻底解决这个问题，它会把所有缩进统一为4个空格，并处理字符串引号、行长度、运算符空格等一整套规范。
安装Black推荐用pip：
pip install black
Black的配置可以放在pyproject.toml里，这是目前Python社区推荐的方式：
[tool.black] line-length = 88 target-version = ["py38", "py39", "py310", "py311"] skip-string-normalization = false
关于line-length，Black默认是88，这个数字来自相关研究认为的较佳可读性范围。如果你团队习惯更长或更短的行宽，可以调整，但要注意Black不会强行折断长字符串和注释，AI生成的超长字符串可能仍会超出限制，这种情况需要手动处理或借助其他工具。skip-string-normalization如果设为true，Black就不会把双引号统一改掉，适合那些不希望引号被动的项目，默认的false更适合收编AI代码，因为模型在引号使用上实在太随意了。
命令行使用方式如下：
# 格式化整个项目 black . # 只检查不修改 black --check . # 显示将要做的修改 black --diff your_file.py
建议先用--diff看一眼Black打算怎么改，确认没有误伤后再用格式化命令实际写入。这一点在处理AI生成的大段代码时尤其有用，因为你对这段代码还不熟悉，先看diff能顺便帮你理解代码结构。编辑器集成方面，VS Code装上Black扩展后，在settings.json里配置Python格式化器即可实现保存自动格式化。
与Git工作流集成，从源头杜绝格式冲突
单机格式化解决的是个人效率问题，团队协作还需要流程保障。核心做法是把格式化挂到Git的pre-commit钩子上，任何人在提交前代码都会被自动格式化，不合格的提交直接被拦截。
推荐使用pre-commit这个框架统一管理钩子，新建.pre-commit-config.yaml：
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.5.0
hooks:
- id: trailing-whitespace
- id: end-of-file-fixer
- repo: https://github.com/psf/black
rev: 24.1.1
hooks:
- id: black
- repo: https://github.com/pre-commit/mirrors-prettier
rev: v3.1.0
hooks:
- id: prettier然后执行pre-commit install安装钩子。之后每次git commit时，Black和Prettier会先跑一遍，发现不符合规范的地方会自动修改并把提交打回，你重新add之后再提交即可。这样即使是从AI工具里复制粘贴进来的代码，也没机会以混乱的格式进入仓库。
另一个常见冲突点是Prettier和ESLint的配合。ESLint的部分规则（比如缩进、引号）会和Prettier打架，导致一边格式化一边报lint错误。标准解法是用eslint-config-prettier关掉所有与Prettier冲突的ESLint规则：
npm install --save-dev eslint-config-prettier
在ESLint配置中把它放在extends的最后一位，确保它的规则优先级最高。这样ESLint只负责检查逻辑类问题（未使用变量、可能的空指针等），格式问题全部交给Prettier，两者各司其职，不会再出现规则冲突。
总结一下实践路径：编辑器层面保存即格式化，保证你日常看到的代码永远是干净的；提交层面用pre-commit强制卡点，保证仓库里不混入漏网之鱼；CI层面用--check命令兜底，防止有人绕过钩子提交。三层防线建好之后，AI生成代码的格式问题就彻底和你无关了，你可以把精力完全放在审查代码逻辑本身，这才是AI辅助开发的正确打开方式。