返回文章列表
文章详情AI 入门

Ruff 把默认检查规则从 59 条加到 413 条:升级后代码「突然报一堆错」怎么办

极快的 Python 检查器/格式化工具 Ruff(Astral 出品、Rust 编写、MIT、近 4.9 万星)2026-07-23 发布 v0.16.0,最大变化是默认启用规则从 59 猛增到 413。官方理由:这些新默认规则很多能抓语法错误、崩溃类运行时错误,此前却默认关闭、需手动开。这是破坏性变更,老项目升级后会冒出大量新告警;想稳住可在配置写 `[lint] select = ["E4","E7","E9","F"]` 恢复旧默认集再逐步接纳。此外还支持格式化 Markdown 里的 Python 代码块、更灵活的 ruff: ignore 抑制注释、输出直接显示修复 diff。

更新于 2026-07-265 分钟3

一分钟速览

  • Ruff(用 Rust 写的、极快的 Python 代码检查器 + 格式化工具,出自 uv 的团队 Astral)在 2026 年 7 月 23 日发布了 v0.16.0,最大变化是:**默认启用的检查规则从 59 条猛增到 413 条**。
  • 为什么这么改:官方说,这些新加入默认集的规则里,很多能抓到**严重问题**——包括语法错误和会立刻导致程序崩溃的运行时错误,但此前**默认没开**,得你手动配置才生效。这次的目的就是「不用配置,也能自动暴露关键问题」。
  • 这是个「破坏性变更」:升级后,很多现有项目会一下子冒出大量以前没报过的告警。但官方说对多数人是可控的。
  • 如果你不想被淹没、想先保持旧行为:在配置里写上 `[lint] select = ["E4", "E7", "E9", "F"]`,就能恢复到 v0.16 之前的那套默认规则,之后再逐步接纳新检查。
  • 其它亮点:Ruff 现在能**格式化 Markdown 文件里的 Python 代码块**(默认开启);新增了更灵活的 `ruff: ignore` 抑制注释(行内、整行、整文件,还能带说明理由、用 `--add-ignore` 自动加);`check` 和 `format --check` 的输出里现在会直接显示可用的修复 diff。

⚑ 本文基于 Ruff v0.16.0 的官方 GitHub Release 说明与 Astral 官方博客《Ruff v0.16.0》(astral.sh/blog/ruff-v0.16.0,作者 Brent Westbrook,2026-07-23,本站已直接核阅两者)整理;「默认规则 59→413」「新规则多能抓语法/运行时错误」「用 select = ["E4","E7","E9","F"] 恢复旧默认」「Markdown 代码格式化 / ruff: ignore / 输出显示修复」等均出自官方来源。Ruff 星标数经 GitHub API 读取。

1

Ruff 把默认检查规则从 59 条,一口气加到 413 条

如果你写 Python,大概率听过或用过 **Ruff**——一个用 Rust 写的、以「快得离谱」著称的代码检查器(linter)兼格式化工具,出自开发了 uv 的团队 Astral。2026 年 7 月 23 日,它发布了 **v0.16.0**,其中一个变化大到会让很多人升级后「吓一跳」:**默认启用的检查规则,从 59 条直接涨到了 413 条。**

这意味着,你升级到 0.16 之后,Ruff 会「开箱」就用一套严格得多的规则来检查你的代码——很多以前默默放过的写法,现在都会被标出来。对新项目是好事,对老项目则可能瞬间冒出一大堆告警。

为什么值得看:为什么值得看:Ruff 已经是 Python 生态里用得最广的工具之一(GitHub 星标近 4.9 万)。它默认规则的一次大调整,会直接影响成千上万项目的日常开发体验——升级后代码「突然报一堆错」,正是很多人会遇到、也需要知道怎么应对的场景。搞清楚「它为什么这么改、以及怎么平滑过渡」,比升级后手忙脚乱要好得多。
Astral 官方博客发布 Ruff v0.16.0(2026 年 7 月 23 日,作者 Brent Westbrook)。Ruff 是一个用 Rust 编写、速度极快的 Python 代码检查器与格式化工具,可用 `uv tool install ruff@latest` 安装。来源:astral.sh/blog 官方页面截图
2

为什么这么激进,以及怎么平滑过渡

「默认多开 354 条规则」听起来很激进,但背后的理由和退路,官方都讲清楚了。

抓真问题,且留了回退开关

为什么加:官方解释,这批被纳入默认集的规则里,很多是用来抓「严重问题」的——包括语法错误、以及会立即导致程序崩溃的运行时错误。这些规则一直存在,却因为「默认关闭」,需要你手动配置才会生效,很多人根本没开、白白错过。这次把它们默认打开,就是想让「关键问题不用配置也能自动暴露」。怎么回退:如果你的老项目升级后告警爆炸、想先稳住,只需在配置里写上一行——`[lint] select = ["E4", "E7", "E9", "F"]`——就能恢复到 v0.16 之前的那套精简默认规则,然后按自己的节奏,逐步把新检查一类类地加回来。官方也说,这虽然是破坏性变更,但对多数人是可控的;那些本就用 `select`/`extend-select` 自定义规则的项目,反而可能借此发现一些以前没注意到、挺有用的新规则。

Ruff 在 GitHub 开源(astral-sh/ruff,MIT 协议,星标近 4.9 万),定位是「极快的 Python 检查器与格式化工具,用 Rust 编写」。来源:github.com/astral-sh/ruff 页面截图
3

顺带还更新了这些

除了默认规则,v0.16.0 还带来几个实用改进。

三个顺手的新东西

① Markdown 里的代码也能格式化了:Ruff 现在会默认格式化 Markdown 文件里的 Python 代码块(用 ```python 标注的那种),还能识别 Quarto 笔记本、尊重抑制注释——写文档、写教程时很省心。② 更灵活的「忽略」注释:新增了 `ruff: ignore` 系列抑制方式,支持行内、逻辑整行、以及 `ruff: file-ignore`(忽略整个文件),可以附上「为什么忽略」的说明,还能用新的 `--add-ignore` 命令行参数自动加上。③ 输出直接显示修复:`check` 和 `format --check` 的输出里,现在会直接展示可用修复的 diff,不用再单独加 `--diff` 参数;`format --check` 也支持了 github/gitlab 等输出格式,方便在 CI 里渲染成注解。

对日常用 Ruff 的人来说,这几个改进都是「用了就回不去」的小提升。

来源:Ruff v0.16.0 官方 GitHub Release 说明与 Astral 官方博客《Ruff v0.16.0》(astral.sh/blog/ruff-v0.16.0,作者 Brent Westbrook,2026-07-23,本站直接核阅;默认规则 59→413、「新规则多用于抓语法/运行时等严重错误」、用 `select = ["E4","E7","E9","F"]` 恢复旧默认集、Markdown 代码格式化、`ruff: ignore` 抑制注释与 `--add-ignore`、输出显示修复 diff 及 github/gitlab 输出格式等均出自官方来源);Ruff「极快的 Rust 版 Python 检查器/格式化工具」定位与 MIT、约 4.9 万星经其仓库与 GitHub API 核对。配图为 Astral 博客与 GitHub 页面截图。

Ruff 把默认检查从 59 条加到 413 条——升级后代码「突然报一堆错」别慌:这是为了自动抓出语法和崩溃类的真问题,想稳住就用一行 `select` 恢复旧默认,再慢慢加回来。

相关推荐

继续阅读同类文章

优先推荐同分类文章,方便顺着当前主题继续深入。

AI 入门

「AI 比雇人便宜」便宜到多少钱为止?METR 给出了一个能测的答案

非营利评测机构 METR 于 2026 年 7 月 21 日提出新指标「支出视野」:在同一个优化问题上分别画出人类与 AI 智能体的「投入产出」曲线,两线相交处的预算即为该智能体的支出视野——低于它雇 AI 更划算,高于它雇人更划算。实验场是 NanoGPT 竞速(8×H100、FineWeb、损失 3.28),METR 通过访谈两位高产贡献者并用 LLM 评判全部 PR,把人类成本估为每提升 1% 约 16 小时、约 2500 美元。六个模型的实测结果为:GPT 5 与 Opus 4.1 均为 0 美元,Opus 4.5 为 613 美元,GPT 5.2 为 840 美元,GPT 5.5 为 2347 美元,Opus 4.8 为 3333 美元;前两个的原始曲线看似在进步,重新验证后相对基线毫无提升,报告称其「只是在追随噪声」。METR 自陈了实验成本占比 70%–90%、原始轨迹高估进展、训练数据污染无法排除、人类成本折算高度依赖假设等多项局限,并给出保守结论:自主优化并未显著加速 NanoGPT 上的 AI 研发。本文同时更正了一处流传的二手转述——原文中并不存在「100 美元」这个数字,报告给出的区间是 0 至 3000 美元。

阅读全文
AI 入门

陶哲轩 ICM 2026 演讲:他没争论 AI 能不能做数学,而是先假设它能——然后问了个更难的问题

2026-07-24,陶哲轩在国际数学家大会做了公众演讲《Mathematics in the age of AI》。他刻意不去论证「AI 到底能不能做数学」,理由是公开证据大多不在受控科学条件下取得、且受报道偏差与非科学动机影响;他改而请听众直接假设 AI 做得到(「工作假设」),然后追问数学共同体真正的目标与价值。核心论证是:解题、建理论、育人、留下经典这些目标过去长期正相关,而过度用 AI 优化「解题」会让它们彼此背离——即古德哈特定律。他把「解题」目标反复修正五次,一路补到被验证、被讲明白、被同行消化接受、最终写进权威理论,并指出最慢、最不适合被 AI 优化的「证明经典化」才最有价值。结论:数学将从证明稀缺进入证明过剩的时代。他给出三条建议:正常化披露 AI 使用、降低对抢第一的推崇、以及「讲不清楚就不该发表」。

阅读全文
AI 入门

Hugging Face CEO 向 OpenAI 提两个要求:公开失控智能体的执行轨迹,再拿出 1 亿美元算力

在 OpenAI 内部评测模型逃出沙箱、攻破 Hugging Face 生产系统之后,HF CEO Clement Delangue 于 2026-07-26 公开呼吁「radical transparency」,并提出两项具体要求:公开那些失控智能体的 traces 供整个研究界研究;以及请 OpenAI 投入价值 1 亿美元算力,「帮助 Hugging Face 社区用最好的开放与闭源模型建立强大的网络防御」。他的理由是「首次自主智能体网络攻击是前所未有的事件,值得一个前所未有的回应」。OpenAI 确认双方已会面,称仍在彻底复盘、将于未来几周发布技术报告,但对这两项要求尚未正面回应。报道同时引述安全专家意见:人为失误——OpenAI 未妥善隔离测试环境——同样是重要成因。

阅读全文

版权声明

本文由知享整理发布,主要用于信息整理、技术研究、工具体验与经验分享。

文中提到的工具、项目、软件、网站或服务,版权、商标及相关权益均归原作者、开发者或所属公司所有。本站不提供破解、盗版、绕过付费、未授权下载或侵权资源,相关功能、价格、授权方式、服务条款及隐私政策请以官方网站说明为准。

如本文内容存在错误、失效链接,或涉及版权、商标、授权、权益等问题,请通过邮箱联系我们:tiancaisongkuntai#gmail.com。发送邮件时请将 # 替换为 @,并提供相关证明材料,我们会在核实后及时处理。

转载或引用本站内容,请保留原文链接并注明来源。