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

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

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

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

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

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

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

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

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

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

以及：

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

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

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

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

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

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

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

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

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

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

1. JavaScript、TypeScript 使用 ESLint；
2. 统一代码格式使用 Prettier；
3. Python 项目使用 Ruff；
4. Go 项目使用 gofmt；
5. Java 项目使用 Checkstyle；
6. 多语言项目通过 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 项目中常见的问题包括：

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

可以在项目配置中加入 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 工具

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

八、Plus适合哪些代码规范任务？

如果日常使用主要包括：

1. 修改单个文件；
2. 生成小型函数；
3. 解释编译错误；
4. 编写测试示例；
5. 整理代码注释；
6. 偶尔执行格式和质量检查；

Plus 通常能够覆盖大部分需求。

通过 ESLint、Prettier、Ruff、Git 差异检查和 AGENTS.md，很多风格不一致的问题都可以在项目层面解决，不必完全依赖版本调整。

九、哪些情况可以考虑Pro？

如果开发者已经建立自动检查规则，但日常工作仍然包含以下场景，可以根据实际强度评估 Pro：

1. 每天修改多个模块；
2. 经常处理完整代码仓库；
3. 需要连续执行生成、检查、测试和修复；
4. 同时维护多个不同技术栈的项目；
5. 每轮任务都需要多次质量检查；
6. Codex 已进入正式开发和审查流程；
7. 当前使用空间经常影响任务连续性。

对于高频用户，Pro 的意义并不是让 Codex 生成更花哨的代码，而是让代码修改、规范检查、测试验证和问题修复更容易形成完整流程。

但无论使用 Plus 还是 Pro，都不能用版本替代项目规范。如果没有可执行的检查规则，使用空间增加后，依然可能产生更多不统一的代码。

十、ChatGPT充值后建议先完成这套配置

在让 Codex 深度参与项目之前，可以先完成以下准备：

1. 配置格式化工具；
2. 配置代码质量检查；
3. 增加类型检查命令；
4. 将验证命令写入 AGENTS.md；
5. 限定每轮修改范围；
6. 修改后检查 Git 差异；
7. 让 Codex 输出检查结果；
8. 再决定是否提交代码。

这套流程能够把“写代码”变成“生成、检查、验证、提交”的完整步骤。

总结

ChatGPT充值后，Codex 写出的代码风格不统一，通常不只是模型生成问题，更可能是项目缺少明确且可执行的规范。

通过 ESLint、Prettier、Ruff 等工具，可以统一格式并发现常见质量问题；通过 AGENTS.md，可以补充目录规则、命名要求和验证命令；再结合 Git 差异检查，能够避免自动格式化扩大修改范围。

对于单文件修改和轻量开发，Plus 通常已经可以满足需求。对于多项目、多模块、需要持续执行检查和测试的高频工程场景，Pro 更适合复杂而连续的工作流程。

真正稳定的 AI 编程，不是每次提醒 Codex“写规范一点”，而是让每一段新代码都必须通过项目中已经建立的规则。