Ruff默认规则从59条增至413条，没锁版本的CI最先撞上新警告

Astral在7月23日发布了Ruff v0.16.0。这版Python代码检查工具把默认启用的规则从59条一次性提到413条，是v0.1.0以来最大的一次调整。只要项目里的ruff版本号没锁死，CI很可能在下一次构建时冒出大量此前从未出现的警告。

这次改动不是加新功能，而是把此前需要手动打开的严格检查设成了默认项。零配置检查变强，代价是一次没有预警的兼容性变更。项目跑得越省心，越容易在这次调整里被绊一下。

从59条到413条：六年来最大的一次默认规则调整

Ruff上一次修改默认规则集是在v0.1.0，那之后规则总量从708条涨到968条，但默认启用的数量一直卡在59条。很多新规则写好了，开关却没打开。v0.16.0把这批规则一次性收进默认集合，其中包括能捕捉语法错误和运行时错误的检查项——这类问题过去装了Ruff也未必能被发现。

这跟以往Ruff的迭代方式不一样。过去新增规则大多是可选项，用不用由使用者自己决定。这次Astral直接把更严格设成默认状态，相当于替所有没手动关闭规则的项目做了一次集体选择。没锁定ruff版本号，就等于把这次破坏性升级直接带进了下一次CI构建。

sqlite-utils实测：1618个问题里，80个躲不过自动修复

开发者Simon Willison用自己维护的三个项目做了测试：Datasette、sqlite-utils、LLM。sqlite-utils在Python 3.10到3.14上有完整的CI测试覆盖。他跑了ruff check . --fix --unsafe-fixes。

剩下的80个问题里，有裸露异常捕获（BLE001）、不带时区参数的datetime.now()调用（DTZ005）这类需要人工判断的写法。Ruff会解释清楚每一条为什么算问题，但不会替你决定怎么改。

--unsafe-fixes能自动改代码，但也可能改变代码的实际语义。Willison敢批量接受修复，前提是sqlite-utils本身有跨五个Python版本的完整测试。多数项目没有这样的CI覆盖，照搬这条命令风险不小。1618条检出里，多数是次要规则违规，不能直接当成1618个真实缺陷。

两类人该做什么，接下来盯住什么

维护Python项目和CI工具链的开发者，最直接的动作是把ruff版本号锁定在依赖文件里。升级前先在本地跑一遍uvx ruff@latest check .，看看新规则会炸出多少警告，再决定要不要合并到主分支。

负责依赖升级、代码质量和自动化改造的工程负责人，可以把这次升级当作评估编码代理的机会。Ruff所在的Astral今年3月并入OpenAI。这次整改，Willison用Codex（GPT-5.6 Sol high）处理了LLM和sqlite-utils的PR，用Claude Code（Opus 5）处理了Datasette的PR。Ruff给出的结构化报错信息，确实适合直接喂给代理去改代码，但一条unsafe fix要不要合并，最终看的是CI里的测试跑不跑得过，不是代理给出的diff好不好看。

目前还看不清Astral是否会给出更渐进的迁移路径，比如分批次启用新规则。接下来值得盯的是有多少项目报告类似的CI意外，以及有没有官方的降级或过渡建议出现。