让 Claude 修一行 lint，它顺手把一直挂着的 CI 和一个 CVE 一起带出来——副产品比任务本身值钱。
how2claude 项目里我准备做一组小修，前置步骤要先把仓库的 rubocop lint 通过。我截了一张 GitHub Actions 红色 CI 的截图发给 Claude。
它的第一句话：
CI 挂了。我去查一下哪些原因。
我以为它会去跑 rubocop、看错误、然后修。它没有。
几分钟后它回了这一段：
CI 早就在挂了（之前的 run 在 4 月 12 号也是 failed）。问题分两类：
我引入的新问题：迁移文件 2 处 RuboCop violation
早就存在的问题：
- CI 没配 postgres service，所有 test/system-test 一直起不来（基础设施问题，2 周前就这样）
- 61 处 pre-existing 的 RuboCop 违规（不在我改的文件里）
先把我引入的 2 处 fix 掉
这一段值得停一秒看。
我让它做的事是"修 rubocop"。它去查 CI 历史时顺手做了一件我没让它做的事——把"挂掉的原因"拆成两类：是我这次引入的、还是仓库里早就坏的。
我没要求它做这个分类。它做了。
那两类问题里，第二类才是核心：
db:test:prepare 每次跑都 connection refused也就是它说的：
之前的 run 在 4 月 12 号也是 failed
CI 已经红了三周。我自己天天在 push，每次 push 都看到 CI 红，但因为我大多数时候在 master 上直接 commit、本地跑 spec，已经习惯把那个红当背景噪声了。
直到这一刻让 Claude 修一处 lint，它一查 history，立刻把"这事不是从你这次开始的"摆到我面前。
接下来它把一切顺手处理掉：
✓ 63 RuboCop 违规 → 0（17 个文件 whitespace 自动修）
✓ MCP gem CVE-2026-33946 → bundle update mcp，0.9.0 → 0.14.0
✓ test/system-test postgres service 缺失 → 添加 postgres:17 service container
✓ 全部 241 测试本地仍通过
✓ bundler-audit: No vulnerabilities found
注意第二行——它顺手 bundle update 了 mcp gem，因为发现新版本修了一个 CVE。我也没让它做这个。它只是在跑 bundler-audit 时看到了警告，把它一起带出来了。
第三行是真正解决 CI 的：CI 工作流里加了 postgres:17 service container，配置了 health check 和 DATABASE_URL。
接着它问我提交粒度：
要不要分两个 commit：
chore(lint): rubocop autocorrect (whitespace only)fix(ci): add postgres service + bump mcp gem for CVE-2026-33946或者一个 commit：
fix(ci): make CI green again？
我回了一个字 commit，意思是按它提的两段分开提。它推了。
CI 重新跑。我让它盯着结果。
4 个绿了，system-test 还红。查具体原因
它查了几下，回了这一句：
test/system/目录都不存在——这个 job 跑test:system但根本没有 system tests。直接删掉这个 job。
我盯着这一行看了好几秒。
test/system/ 是 Rails 默认的 system test 目录。我从 init 这个项目起就没写过 system test。但 GitHub Actions workflow 的 ci.yml 里一直有一个 system-test job，每次 push 都跑，每次都 fail，因为它在 bundle exec rails test:system 时找不到目录。
这个 job 不是 Claude 修 postgres service 之后才坏的。它从这个项目存在的第一天就在坏。我以为加上 postgres 之后它会跟着绿，结果它根本不需要 postgres——它需要的是被删掉。
它的第三个 commit：
e1d91d1 chore(ci): drop system-test job
CI 全绿。
回头看这次的产出：
如果是我自己来，我大概率只会做那 1 件——因为我看 CI 红已经看了三周了，神经早就钝了，我会以为这次的 lint 修一下就好。我已经把那个红框当成"背景"。
Claude 不带这种习惯。它对仓库没有"以前一直这样"的记忆。它每次看 CI 都是第一次看 CI。这反而是优势——我看不见的"长期默认坏"，它看见。
让 Claude 接手一个小任务，最值钱的副产品经常不是任务本身完成，而是它顺手做的体检。如果它在跑你那个小任务的过程中主动报出"顺便发现你这边还有 X、Y、Z 一直在坏"，不要把这些当杂讯。这就是体检报告。
几个对我自己有用的小习惯：
让 Claude 在跑小任务前先扫一眼周边状态。 让它跑 lint 前先看 CI 历史。让它写 migration 前先看最近一次 schema 是什么时候改的。让它改一个 controller 前先 grep 一下这个文件的测试覆盖。这种"开始之前扫一眼"几乎不耗时间，但经常会甩出一两条"等等，这边有事"。
它说"分两类问题"或"分两类原因"时，那一定是它在做你没让它做的整理。 这种总结句你应该停下来读完，不要划过去。
修一个东西时碰到长期红的别绕过。 我之前每次 push 都看到 CI 红，每次都跟自己说"这是 known issue 等以后再看"。但"以后再看"可能等三年。让 Claude 顺手清掉，比单独排一个时间修 CI 现实得多。
最后再说一遍那三个 commit：
74a3ebf chore(lint): rubocop autocorrect — Layout cops only
76264ee fix(ci): add postgres service + bump mcp gem for CVE-2026-33946
e1d91d1 chore(ci): drop system-test job
第一个是我让 Claude 做的。第二、第三个是它顺手做的。后两个的价值远超第一个。