配了三年 code review，今天才发现 70% 的意见本该是机器提的——三道门禁把这件事彻底变了

配了三年 code review，今天才发现 70% 的意见本该是机器提的——三道门禁把这件事彻底变了。

你有没有这种感觉：review 别人的 PR，打开一看，满屏都是”这里少了个分号”、”那个变量名拼错了”、”import 顺序不对”。这些问题你说出来显得很小气，不说出来代码库里又留着碍眼。

这就是质量门禁失守的代价——人花了大量时间做机器该做的事，机器反而没人管。

百度智能云有个数据：未建立质量保障的前端项目，平均每千行代码有 3.2 个潜在缺陷，线上故障修复周期 12 小时。建立系统化质量管控后，缺陷密度降到 0.8 个/千行，故障响应缩短到 2 小时。这个差距不是靠 hire 更好的 developer 填上的，是靠把质量检查自动化。

今天把这个过程拆成三道门禁，每道各管一件事。

第一道：本地 pre-commit Hook，让机器在你提交前先拦一次

第一道门禁在你自己机器上，就在 git commit 之前。

做法是装 Husky + lint-staged，配置好之后每次 commit 自动对你这次改的文件跑 ESLint 和 Prettier，整个过程 1-3 秒。你本地修一个小 bug，提交前 ESLint 告诉你这个文件里有个 console.log 没删、Prettier 发现格式不对——顺手就修了，根本不用等 review。

关键配置：.lintstagedrc.mjs 里 ‘*.{ts,tsx}’: [‘eslint –fix –max-warnings 0’, ‘prettier –write’]。关键是 –max-warnings 0 这个参数。不加这个，ESLint 报 warning 你的 commit 照样能过，门禁效果直接归零。

lint-staged 只检查你这次改的文件，不扫整个仓库，所以不会慢。真正让团队接受 pre-commit hook 的就一条：执行时间控制在 2 秒以内。超过这个时间的 hook，工程师会用 git commit –no-verify 绕过去，那门禁就等于没装。

第二道：CI 流水线强制执行，merge 前没有人能跳过关

本地 hook 是信任，CI 是强制。

不管谁的机器、什么时间提交的代码，只要创建 PR，CI 流水线就会跑完整的检查：Lint + TypeScript 类型检查 + 单元测试，全部通过才允许 merge。这道门禁没有人能绕过。

TypeScript 的类型检查是很多人跳过的步骤，觉得 IDE 里提示就够了。实际上 CI 里的 tsc –noEmit 能抓到 IDE 里没暴露的问题——尤其是在 monorepo 环境或者多人协作时，不同人的 IDE 配置不一样，IDE 没报错不等于代码没问题。

第三道：GitHub Code Quality，自动在 PR 里投质量报告

2026 年 7 月 GitHub Code Quality 正式 GA，在 Settings → Security → Code quality 开启后，每次 PR 自动跑 CodeQL 扫描，把质量报告直接呈现在 PR 页面。

CodeQL 扫描比 ESLint 更深一层：ESLint 告诉你语法和风格不对，CodeQL 告诉你这个写法在语义上有什么风险。

GitHub 自己的数据是：正确配置质量门禁的团队，PR review 时间减少 30-40%，因为 reviewer 打开 PR 看到的都是逻辑和架构问题，不再是”缩进不对”。

三步落地，今天就能跑

第一步（今天）：装 pre-commit hook。Husky 装好了跑 npx husky init，然后在 .husky/pre-commit 里写 npx lint-staged。从 ESLint + Prettier 开始，两个都配 –max-warnings 0。

第二步（本周）：把 CI 质量门禁加进 workflow。在你的 CI workflow 文件里加一个 quality job，先跑 npm run lint，再跑 tsc –noEmit，两个都 fail-fast。

第三步（下周）：开 GitHub Code Quality 看一次报告。去 Settings → Security → Code quality 开启，然后创建一个测试 PR，看 CodeQL 报告了什么。

质量门禁的核心逻辑就一句话：让机器检查格式，让人审查逻辑。格式问题是确定性问题，机器检查比人更快、更准、更不会疲劳。逻辑和架构判断是开放问题，需要 human context，只能人来干。把前者自动化了，后者才有精力做好。