. 更好的原则：保留防 bug，减少风格洁癖

• 第一类：必须保留

no-dupe-keys
no-undef
no-unused-vars
no-unreachable
no-empty
no-unused-expressions
no-mixed-operators
no-unsafe-optional-chaining
consistent-return
vue/valid-v-model
import/no-cycle


Their errors almost always indicate real risk.

E.g. Mixed‑operator warning:

css
disabled={a && b || c && d}
Although JavaScript knows precedence。humans often misread it. Adding parenses is safer:
scss
disabled={ || }
perl
no-mixed-operators


第二类：视项目情况保留 

perl
no-restricted-syntax
prefer-destructuring
max-len
no-nested-ternary
no-param-reassign
no-plusplus
例如禁用 `for…in` 合理，因为它遍历原型链；但禁所有 `for，of` 则不一定合理。对于需要 `break`、`continue`、`await` 的循环，`for…of` 更清晰，


第三类：交给 Prettier 

缩进、空格、换行、引号、分号、对象换行、行宽…这些交给 Prettier。让代码格式自动化，不占用人和 AI 的判断力。

. ESLint 和 Prettier 的分工 


Prettier 
负责代码外观 

ESLint 
负责显式风险 

TypeScript 
负责类型正确性 

测试 
负责行为是否变化 

AI Review 
负责业务链路合理性 

这些工具应协作，而不是抢工作。

. Parser 必须升级 

ESLint 能否正确解析代码取决于 parser。再看老项目常见，
vbnet
说到parser。
'babel-eslint'
已被废弃。至于现代项目推荐，vbnet
至于parser，'@babel/eslint-parser' // Babel 项目
从parser来看，'@typescript-eslint/parser' // TypeScript 项目
再看parser。'vue-eslint-parser' // Vue 项目
parser 的好处：


更懂现代语法 → 减少误报 / 崩溃 

可以结合类型信息做更强检查 

至于案例，可选链 `parseFloat?.toFixed` 放在模板字符串里触发了 ESLint 内部错误。仅靠改业务代码无法根治，根本办法是升级工具链。

. AI 时代的理想 ESLint 配置 

目标不是“一刀切最严格”，而是 “最高信号”。示例配置如下的观点是，
javascript
module.exports = {
extends:,rules: {
'no-dupe-keys': 'error','no-undef': 'error','no-unreachable': 'error','no-empty': 'error','no-unused-expressions': 'error','no-mixed-operators': 'error','no-unsafe-optional-chaining': 'error'。'consistent-return': 'warn','vue/valid-v-model': 'error',
// 可根据项目自行开启/关闭
'prefer-destructuring': 'off','no-plusplus': 'off',// 示例：只限制 ForIn 与 With
'no-restricted-syntax':,

},};

至于关键点，不要禁用所有 ForOfStatement——在需要 break/await 时它比 .some 更直观。

. 报错信息也要解释型 

传统报错往往只有 rule 名称，例如：

perl
no-restricted-syntax


这对新人和 AI 都不友好。建议提供完整说明：

css
Avoid for...in because it iterates inherited enumerable properties. Use Object.keys/Object.entries if you only need own properties.
 

即：“不要只说‘不准’。要说明‘为什么不准’还有‘如何安全替代’”，帮助 AI 做出正确修复。说起来，

. AI Code Review 补足 ESLint 的盲区 

ESLint 看不到业务语义。例如：

text
审批页和查看页是否需要一致接口字段？按理说，是否符合后端契约？

这些需依赖 AI Review。AI 在复杂程序中应关注：


接口调用链状态机推进

权限条件路由入口一致性

旧数据兼容

后端 payload 是否误改






ESLint 的职责仅是挡住确定性错误，让人和 AI 将精力聚焦业务风险。

. 老项目落地方法 

针对老 Vue2 项目，建议分阶段实施：


恢复 lint 基线 – 确保全量 lint 能跑通。

评估规则价值 – 区分防 bug、风格、易诱导机械
三类。

降噪 – 暂时关闭高噪音规则。如 `prefer-destructuring`,`no-plusplus`,`max-len` 等。

引入 Prettier – 格式交给机器，不进入 review。

升级 parser – 从 `babel-eslint` → `@babel/eslint-parser` → `vue-eslint-parser` → `@typescript-eslint/parser` 按需迁移。

固化 AI Review 流程 – 每次业务改动必须说明影响入口、接口字段、提交 payload 验证方式等。不过，


这样比单纯堆砌更多 lint rule 更有效。

. 判断标准 — 噪音 vs 信号 

在 AI era。一个好的 eslint 报错应满足：


人和 AI 看见报错，都能立刻判断出大概率是真实风险。不过，

若 rule 常导致「代码无风险但必须换写法」。则应降级、关闭或交给 Prettier。


否则大量低信号报错会淹没关键风险，使审查注意力被稀释。例如一次 PR 中出现 10 个缩进/分号/单引号等格式问题。却还有 4 条可能影响行为的改动，AI 往往只看到「lint 批量修复」而忽略业务语义变更。



AI 时代的 ESLint 不是越严格越好。而是要 降低风格争论，提高 bug 信号强度。

让 ESLint 成为 AI 写代码的安全护栏而非 风格洁癖的绊脚石。

工具链常用方法：


Prettier → 格式化；

ESLint → 确定性风险；按理说，​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ ​​​​​​​​
 
​
​ TypeScript → 类型校验；​ 测试 → 行为验证，​ AI Review → 業務語義審核。​ ​ ​ ​ ⁣⁣⁣⁣⁢⁣⁣‌‍‌‍‌‌‏‏‏‏‏‏‏‏‏ ‏‌‎‎‎‎‎‎ ‎‌‏ ‎‍ ‏ ‌‍ ‍ ‌ ‎‌ ‌ ‎ ‌⁠⁠⁠⁠⁠⁠⁠⁠⁠\t\ t\





​

.