讓 Claude 修一行 lint，它順手把一直掛著的 CI 跟一個 CVE 一起帶出來——副產品比任務本身值錢。
how2claude 專案我準備做一組小修，前置步驟要先把 repo 的 rubocop lint 通過。我截了一張 GitHub Actions 紅色 CI 的截圖丟給 Claude。
它的第一句話：
CI 掛了。我去查一下哪些原因。
我以為它會去跑 rubocop、看錯誤、然後修。它沒有。
幾分鐘後它回了這一段：
CI 早就在掛了（之前的 run 在 4 月 12 號也是 failed）。問題分兩類：
我引入的新問題：migration 檔案 2 處 RuboCop violation
早就存在的問題：
- CI 沒配 postgres service，所有 test/system-test 一直起不來（基礎設施問題，2 週前就這樣）
- 61 處 pre-existing 的 RuboCop 違規（不在我改的檔案裡）
先把我引入的 2 處 fix 掉
這一段值得停一秒看。
我讓它做的事是「修 rubocop」。它去查 CI 歷史時順手做了一件我沒讓它做的事——把「掛掉的原因」拆成兩類：是我這次引入的、還是 repo 裡早就壞的。
我沒要求它做這個分類。它做了。
那兩類問題裡，第二類才是核心：
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 workflow 加了 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 不帶這種習慣。它對 repo 沒有「以前一直這樣」的記憶。它每次看 CI 都是第一次看 CI。這反而是優勢——我看不見的「長期預設壞」，它看見。
讓 Claude 接手一個小任務，最值錢的副產品經常不是任務本身完成，而是它順手做的體檢。如果它在跑你那個小任務的過程中主動報出「順便發現你這邊還有 X、Y、Z 一直在壞」，不要把這些當雜訊。這就是體檢報告。
幾個對我自己有用的小習慣：
讓 Claude 在跑小任務前先掃一眼周邊狀態。 讓它跑 lint 前先看 CI history。讓它寫 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 做的。第二、第三個是它順手做的。後兩個的價值遠超第一個。