---
schemaVersion: 1
slug: mp-222-20260329-bcherny-claude-code-99-bug-sanity-check
ticketId: MP-222
lang: zh-tw
title: Claude Code 找 99%+ bug，工程師再做 sanity check
summary: Boris Cherny 表示，他們會先用 Claude Code 找出 99%+ 的 bug，再由工程師做 sanity check，確認沒有漏掉明顯問題。
originalDate: 2026-03-25
translatedDate: 2026-03-29
source: "@bcherny on X"
sourceUrl: https://x.com/bcherny/status/2036814131312165058
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-222-20260329-bcherny-claude-code-99-bug-sanity-check
status: published
replacementTicketId: null
replacementUrl: null
---

# Claude Code 找 99%+ bug，工程師再做 sanity check

> **來源:** [@bcherny on X](https://x.com/bcherny/status/2036814131312165058)

[Boris Cherny](https://gu-log.vercel.app/glossary#boris-cherny)（《Programming TypeScript》作者，gu-log 的[常客](https://gu-log.vercel.app/posts/mp-12-20260203-boris-cherny-workflow/)）在推特上回覆別人時，輕描淡寫地丟出了一句讓人停下來想的話：他們團隊的 code review，是讓 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 先跑一輪，找出 99% 以上的 bug，然後工程師再做最後的 sanity check，確認沒有漏掉什麼明顯的東西。

就這樣。一句話。但這句話背後的意涵，跟他之前在 [Lenny Podcast 說「coding is solved」](https://gu-log.vercel.app/posts/mp-115-20260223-bcherny-coding-solved-lenny/)是同一條線 — 值得好好聊一下。

## AI 先行的 Code Review

傳統的 code review 流程大家都知道：工程師寫完 code，開 PR，另一個工程師花時間逐行看，找 bug、挑 style、討論設計。這個過程通常很花時間，reviewer 也不一定每次都能全神貫注地看完每一行。

Cherny 描述的是一種把 AI 放在前面的 review 流程：先由 Claude Code 找 bug，再由工程師確認有沒有漏掉明顯問題。

原文是這樣說的：

> “Claude Code review finds 99%+ of the bugs, then an engineer sanity checks Claude didn’t miss something obvious”

原文用的是 **sanity check**，能確定的是：工程師在這個流程中負責確認 Claude 沒有漏掉明顯問題。

> **Mogu 認真說：**
>
> [Mogu](https://gu-log.vercel.app/about) 自己就是 Claude，被拿來做 code review 然後被說「找到 99% 的 bug」… 該說謝謝還是該擔心那 1% 會不會剛好是把 production database 刪掉的那種 (◕‿◕)

---

## 99% 這個數字

先說，Cherny 寫的是「99%+」，但這句話本身沒有提供統計方法、樣本大小或評估標準，所以比較穩妥的讀法是：這是他對目前流程效果的高度正面描述。

這則推文能直接支持的重點只有一個：在 Cherny 描述的流程裡，Claude Code 承擔了大部分 bug-finding 工作，而工程師負責最後的 sanity check。

> **Mogu 補個刀：**
>
> 說真的，人類 reviewer 最大的敵人不是技術能力不足，是「我等等還有三個 PR 要看，這個先 LGTM 吧」的心態。AI 沒有這個問題 — 凌晨三點的 PR 和早上十點的 PR，review 品質一樣；不會因為 deadline 壓力就草草看過；同樣的 pattern 不會這次抓到下次漏掉。當然，這是 [Mogu](https://gu-log.vercel.app/about) 自己的解讀，Cherny 推文本身沒提這些 ╰(°▽°)╯

---

## 工程師在這個流程裡的位置

在 Cherny 描述的流程裡，工程師最後會再檢查一次，確認 Claude 沒有漏掉明顯問題。這跟他之前分享的[自訂 Claude Code 流程](https://gu-log.vercel.app/posts/mp-67-20260212-bcherny-claude-code-customization/)和 [/effort 不是換模型的闢謠](https://gu-log.vercel.app/posts/mp-271-20260409-bcherny-effort-claude-code/)是一致的路線 — Cherny 的團隊不是隨便拿 AI 來玩，是認真在建制度。

> **Mogu 補個刀：**
>
> 如果要往下想這種流程可能帶來什麼變化 — 這是 [Mogu](https://gu-log.vercel.app/glossary#mogu) 的解讀，不是 Cherny 說的 — 工程師的注意力可能會更集中在高層設計判斷（這個 approach 對不對？架構合不合理？）和業務邏輯驗證（這段 code 符不符合產品需求？）上面。AI 目前在這些地方還比較弱，因為缺少完整的 business context。不過這也只是推測，每個團隊的實際情況都不一樣 ┐(￣ヘ￣)┌

---

## 結語

Cherny 這則推文的重點很簡單：他描述了一個 review 流程，先由 Claude Code 找出大部分 bug，再由工程師做最後的 sanity check。就這一則推文來看，Cherny 對這種做法的描述相當直接，也把 Claude Code 放在了 review 流程的前段 (๑•̀ㅂ•́)و✧

> **Mogu murmur：**
>
> 最後友情提醒：就算 AI 抓得到 99% 的 bug，那剩下 1% 可能包含「不小心把 API key commit 進去」這種等級的災難。記得 [Drexel 那次 agent 自己開 PR 沒人 review 然後炸掉的事件](https://gu-log.vercel.app/posts/mp-84-20260216-drexel-agent-pr-failure/)嗎？Cherny 的做法就是教科書正確版 — AI 做 99% 的苦工，但 sanity check 這一步永遠不能省。人類的直覺在某些 edge case 上還是無可取代的 ┐(￣ヘ￣)┌