使用 Codex 修改项目以后，有时候功能已经能正常运行，但执行代码检查时却突然出现一堆报错：

npm run lint

结果可能看到：

• no-unused-vars

• no-explicit-any

• import顺序错误

• Promise没有正确处理

• React Hooks规则报错

• 格式和项目规范不一致

这时候很容易产生一个疑问：

代码明明能跑，为什么Lint还是不让过？

原因通常不是代码完全写错了，而是：

“能够运行”和“符合项目代码规范”本来就是两套检查标准。

---

一、Lint到底检查什么？

Lint和测试关注的重点不一样。

测试更多是在确认：

功能有没有按照预期运行

而Lint主要关注：

代码写法
潜在问题
项目规范
可维护性

例如：

const result = await getUser()

如果后面根本没有使用 result，程序可能照样运行。

但ESLint可能直接提示：

no-unused-vars

因为这个变量没有实际作用。

所以：

Lint报错不一定代表功能已经坏了，但通常说明代码还有需要整理的地方。

---

二、先确认项目到底用了哪些规则

不要看到Lint报错以后，就让 Codex 按自己的习惯重新格式化整个项目。

先检查项目里的配置文件。

常见包括：

eslint.config.js
.eslintrc
.eslintrc.json
.prettierrc
package.json

不同项目的规则差异可能很大。

例如有的项目允许：

any

有的项目则直接禁止。

有的项目要求双引号，有的项目统一使用单引号。

所以 Codex 修改代码之前，最好先理解：

当前仓库已经采用什么规范。

---

三、no-unused-vars为什么经常出现？

AI修改代码时，经常会先增加一个变量，后面调整方案以后却没有把它清理掉。

例如：

const user = await getUser(id)
const status = user.status

return user.name

这里：

status

没有真正被使用。

功能可能仍然正常。

但Lint会提示未使用变量。

遇到这种问题，通常应该：

删除真正没有作用的变量。

而不是为了通过检查，随便给变量增加一次无意义调用。

---

四、不要为了通过Lint直接关闭规则

例如看到：

@typescript-eslint/no-explicit-any

一个很简单的处理方式似乎是：

// eslint-disable-next-line

或者直接修改ESLint配置。

虽然这样可能马上让错误消失，但并不一定是正确解决方案。

因为项目设置这条规则，本身可能就是为了减少：

any

导致的类型问题。

更合理的顺序应该是：

先看代码能不能按照现有规则修改。

只有确定规则确实不适合当前场景，再考虑调整配置。

---

五、格式问题和逻辑问题要分开处理

有些Lint问题只是：

• 缩进；

• 引号；

• 分号；

• 换行；

• import排序。

这类通常可以使用自动修复：

npm run lint -- --fix

或者项目自己的格式化命令。

但另外一些问题，例如：

Promise未处理
Hook调用顺序错误
变量可能为空

就不能只靠格式化解决。

所以看到一大堆Lint错误时，可以先分成：

格式类
↓
代码规则类
↓
潜在逻辑风险类

再逐类处理。

---

六、React项目要特别注意Hooks规则

例如 Codex 修改组件后写成：

if (user) {
  useEffect(() => {
    loadData()
  }, [])
}

代码看起来很直观。

但 React Hooks 通常要求调用顺序保持稳定。

因此Lint可能直接提示Hooks规则问题。

这种情况下不能简单：

把Lint规则关闭。

应该重新调整代码结构。

这也是Lint真正有价值的地方：

它能提前发现一些运行时未必立即暴露的问题。

---

七、异步代码也是高频报错来源

例如：

saveUser()

如果 saveUser() 返回Promise，但既没有：

await saveUser()

也没有明确处理结果，就可能触发项目中的异步规则。

AI写代码时容易优先保证：

功能调用到了。

但项目规范可能还要求：

异步结果必须明确处理。

所以碰到 Promise 相关Lint错误时，要检查：

• 是否需要 await；

• 是否需要错误处理；

• 是否故意忽略结果；

• 当前函数是否应该改成 async。

---

八、Import规则为什么也容易被Codex触发？

大型项目经常规定：

外部依赖
↓
内部模块
↓
相对路径
↓
类型导入

按照固定顺序排列。

Codex新增 import 后，如果只是把它直接插在文件顶部，就可能违反现有规则。

这类问题本身不严重，但如果一个任务修改几十个文件，就可能一次产生大量Lint提示。

所以最好让Codex：

参考当前文件已有的import组织方式。

而不是重新发明一套格式。

---

九、先缩小范围，不要一次修整个仓库

如果Codex只修改了3个文件，但运行Lint以后发现整个项目有100个历史错误，不建议让它顺手全部处理。

因为这样很容易出现：

原任务修改3个文件
↓
为了修Lint又改30个文件
↓
Diff迅速扩大

更稳的方式是：

先确认：

哪些错误是本次修改新产生的。

优先只处理这些问题。

历史Lint问题可以另外安排任务解决。

---

十、可以按这个顺序排查

Codex修改代码后Lint突然报错，可以按照：

第一步：确认本次修改文件。

git diff --name-only

第二步：运行Lint。

查看具体规则名称。

第三步：区分格式错误和代码规则错误。

先处理可以自动修复的部分。

第四步：检查项目Lint配置。

不要直接关闭现有规则。

第五步：重新运行Lint。

确认本次新增错误已经清理。

最后再运行：

Type Check
↓
Test
↓
Build

检查其他环节。

---

十一、可以提前给Codex一条项目规范要求

以后让 Codex 修改真实项目时，可以在任务里加入：

修改代码前先读取项目已有的ESLint、
Prettier和TypeScript配置。

完成后：

1. 只处理本次修改产生的Lint问题；
2. 不随意关闭已有规则；
3. 不为了修Lint扩大无关修改范围；
4. 保持原项目的import和格式风格；
5. 重新运行Lint确认结果。

这样比代码全部改完以后，再一次性处理几十条规范错误稳定很多。

---

最后

Codex改完代码后Lint突然报一堆错误，并不意味着这次修改完全不能用。

真正需要判断的是：

这些错误属于格式问题、项目规范问题，还是潜在代码风险。

比较合理的处理顺序是：

先看规则 → 找本次新增问题 → 能自动修的先修 → 逻辑类问题单独处理 → 最后重新检查。

最不建议的做法是：

为了让Lint变绿，直接把规则关掉。

一个成熟的AI编程流程，不只是让代码：

“能运行”。

还应该让新代码能够自然融入项目原有规范，而不是每次都给代码库留下新的维护成本。

---

持续更新 Codex、大模型开发与 AI 编程实战内容，更多技术内容和稳定订阅渠道欢迎搜索关注「仙逆GPT」。