Codex代码风格统一的项目实践

作者：袖梨 2026-08-07

ChatGPT充值后，不少开发者会开始使用 Codex 修改项目代码。刚开始处理单个函数时，生成结果通常比较直观，但随着修改文件越来越多，新的问题也会逐渐出现：

新代码的命名方式与原项目不一致；
有的文件使用单引号，有的使用双引号；
函数结构可以运行，但不符合团队规范；
Codex 重复实现了项目中已有的工具函数；
每轮修改后都需要人工重新格式化；
代码可以通过测试，却很难直接进入审查流程。

这些问题通常不是 Codex 不会写代码，而是项目缺少一套可以自动执行的代码规范。

如果只在对话中告诉 Codex“代码写得规范一点”，不同任务得到的结果仍然可能存在差异。更稳定的方法，是把规范放进项目配置中，让每次修改都经过自动检查。

一、为什么Codex生成的代码风格会变化？

Codex 会根据当前任务、已有文件和项目上下文生成代码。

如果项目本身存在多种写法，或者没有统一的格式检查规则，Codex 很难判断哪一种才是团队真正采用的标准。

例如同一个 JavaScript 项目中同时存在：

const getUser = async () => {  return await request('/user')}

以及：

async function fetchUser() {    return request("/user");}

两段代码都可以运行，但在命名、缩进、引号和函数写法上并不统一。

当 Codex 读取到不同风格的文件时，后续生成结果也可能跟随当前文件变化，最终让项目差异越来越明显。

二、不要把格式要求全部写进提示词

很多开发者会在每次任务中重复说明：

使用两个空格缩进，采用单引号，不要写分号，函数使用箭头形式。

这种方式短期有效，但存在两个问题。

第一，每次都要重复输入。

第二，Codex 即使按照要求生成代码，后续人工修改仍然可能破坏格式。

更合理的做法，是将格式规则交给专门工具，例如：

JavaScript、TypeScript 使用 ESLint；
统一代码格式使用 Prettier；
Python 项目使用 Ruff；
Go 项目使用 gofmt；
Java 项目使用 Checkstyle；
多语言项目通过 CI 统一执行检查。

Codex 负责完成逻辑，检查工具负责统一风格，两者分工会更加稳定。

三、JavaScript项目如何建立基础检查？

前端或 Node.js 项目通常可以同时配置 ESLint 和 Prettier。

在 package.json 中增加脚本：

{  "scripts": {    "lint": "eslint .",    "lint:fix": "eslint . --fix",    "format": "prettier . --write",    "format:check": "prettier . --check"  }}

然后在项目规则中明确要求：

每次修改完成后执行：npm run lintnpm run format:check如果检查失败，先修复当前任务相关问题，不要修改无关文件。

这样，Codex 完成代码后不仅要说明改了什么，还要通过统一的格式与质量检查。

相比人工逐行检查缩进和引号，这种方式更适合长期项目。

四、Python项目可以使用Ruff减少重复配置

Python 项目中常见的问题包括：

导入顺序不统一；
存在未使用变量；
行长度不一致；
同类函数命名混乱；
可以简化的代码没有处理。

可以在项目配置中加入 Ruff，并提供固定命令：

ruff check .ruff format --check .

需要自动修复时，可以使用：

ruff check . --fixruff format .

同时建议限制自动修复范围，不要每次都格式化整个旧项目。

例如本轮只修改 app/service 目录，就只检查相关目录，避免一次任务产生大量无关差异。

五、把代码规范写入AGENTS.md

检查工具解决的是可执行规则，AGENTS.md 可以补充项目特有的开发约定。

例如：

# 代码规范- TypeScript 不使用 any，特殊情况必须说明原因- 优先复用 src/utils 中的已有工具- API 请求统一放在 src/api- 公共类型放在 src/types- 不在页面组件中直接拼接请求地址- 新增函数必须使用清晰的业务命名- 不进行与当前任务无关的全局格式化# 完成前检查- npm run lint- npm run type-check- npm run test

这样，Codex 不仅知道代码“怎么格式化”，还知道应该放在哪里、能不能新增依赖、是否允许修改公共模块。

六、不要让自动格式化扩大修改范围

代码格式化工具虽然方便，但在旧项目中直接执行全局格式化，可能一次修改几百个文件。

结果是当前任务只改了一个接口，Git 差异却包含大量缩进和换行变化，人工审查反而更困难。

建议遵循三个原则：

只检查当前改动范围

优先检查本轮涉及的文件和目录。

逻辑修改与全局格式化分开

如果确实需要统一整个项目格式，应单独建立任务和提交，不要与功能开发混在一起。

修改后检查Git差异

执行：

git diff --statgit diff

如果出现任务范围之外的大量文件，应先确认原因，不要直接提交。

七、让Codex输出规范检查结果

每轮任务结束时，可以要求 Codex 按固定格式总结：

本轮修改文件：1. src/api/user.ts2. src/types/user.ts已执行检查：- npm run lint：通过- npm run type-check：通过- npm run test：通过规范说明：- 未新增第三方依赖- 未修改任务范围之外的文件- 已复用现有 request 工具

这种结果比单纯回答“已经修改完成”更有参考价值，也方便后续代码审查。