C
ChaoBro

react-doctor 火了:AI 写的代码越来越多,我们真的需要给 AI 代码做质检吗?

react-doctor 火了:AI 写的代码越来越多,我们真的需要给 AI 代码做质检吗?

react-doctor 的 README 只有一句话,但这句话值得反复读:

"Your agent writes bad React. This catches it."

你的 Agent 写了烂 React 代码。这个工具负责抓到它。

没有修饰,没有废话。million.js 的作者 Aiden Bai 一如既往地直接。

一周 2,430 颗星,总量突破 10,000。在 GitHub Trending 上不算最炸裂的数字,但考虑到它的定位非常垂直——只检查 React 代码质量——这个增长速度说明了一个真实的需求正在浮现。

AI 写的代码到底哪里"烂"?

你可能觉得这是一个夸张的说法。现在的 coding agent——Claude Code、Cursor、Windsurf——写代码的能力已经很强了。SWE-bench 分数越来越高,能完成的任务越来越复杂。

但"能完成任务"和"写出好代码"是两回事。

react-doctor 抓的问题包括:

  • 不必要的 re-render(性能杀手)
  • 违反 React Hooks 规则的用法
  • 过度复杂的组件嵌套
  • 缺少必要的错误边界
  • 状态管理反模式

这些问题人类开发者也会犯。但 AI agent 犯的频率更高,原因很简单:Agent 没有"代码品味"

Agent 是根据训练数据中的模式来生成代码的。它知道"这种写法能实现功能",但不知道"这种写法在三个月后会让你痛不欲生"。

代码品味是什么?是对可维护性、可读性、可扩展性的直觉判断。这种东西来自踩坑、来自 code review 中被前辈批斗、来自深夜 debugging 时的顿悟。

Agent 没有这些经历。它只有概率分布。

但 react-doctor 解决的只是症状

让我说一个可能不受欢迎的观点:

react-doctor 的出现,说明我们对 AI coding agent 的期望出了问题。

我们在期望 Agent 写出人类级别的好代码。但 Agent 的训练方式决定了它最多只能达到"训练数据中好代码的平均水平"——而训练数据里充满了烂代码。

GitHub 上有多少项目是有良好的 code review 流程的?有多少项目的 PR 描述写得很清楚?有多少项目的测试覆盖率高到可以放心重构?

不多。

所以 Agent 学到的"正常代码",本身就包含大量反模式。它不是在"变烂",它只是在"还原训练数据的真实面貌"。

react-doctor 的做法是正确的——在 Agent 输出和人眼 review 之间加一层自动化检查。但这也是治标不治本。

真正的解决方案是什么?

我认为有三个层次:

第一层(现在就能做):lint + react-doctor 这类工具。 在 Agent 提交代码之前自动跑一遍质量检查,拦截低级错误。这已经是 best practice 了。

第二层(正在发生):skill 化工程实践。 就像 mattpocock/skills 做的事情——把项目的代码规范、review 标准、最佳实践写成 Agent 可读的 skill。Agent 在写代码之前就"知道"这个项目的好代码长什么样。

第三层(还没人做好):让 Agent 学会"代码品味"。 这不是加几条规则就能解决的。它需要 Agent 理解代码的上下文、理解团队的风格偏好、理解业务场景对代码质量的真实要求。

第三层最难,但也最有价值。因为一旦做好,就不只是"抓错误"了,而是"写好代码"。

我的看法

react-doctor 的出现是 AI coding 生态成熟的标志。

当工具链中开始出现"专门给 AI 写的代码做质检"的工具时,说明 AI coding 已经从"新奇特"进入了"日常化"阶段。

我不觉得这是一个令人沮丧的信号。相反,它说明开发者社区已经开始认真对待 AI 生成代码的质量问题了——不是在恐慌"AI 会取代程序员",而是在务实地解决"AI 写的代码不够好,怎么让它更好"。

这才是健康的生态演进。

如果你是 React 开发者,我建议你现在就把 react-doctor 加到你的 CI 流程里。不是因为你的 Agent 很烂,而是因为任何自动化的代码生成工具,都应该配一个自动化的质量检查工具

这和人写代码要跑 linter 是一个道理。唯一的区别是,以前 linter 是可选的——因为人写的代码至少有人 review。Agent 写的代码,如果没有人 review,linter 就是唯一的防线了。

主要来源: