AI 寫的 code 一堆 bug？讓 Claude 跟 Codex 自動互審
by Gary Chen
逐字稿
00:00 寫軟體的成本在過去兩年因為 AI 被不斷壓低
00:03 你不用是工程師，不用懂程式
00:05 一句話就能讓 AI 幫你生出一個網頁，甚至一個 app
00:08 這就是這一兩年大家都在講的 vibe coding
00:11 但只要真的動手做過
00:12 你應該都遇過同一件事
00:14 就是不管你用哪一個 model
00:15 它做出來的東西總有些地方沒想清楚
00:18 可能會漏掉某些 corner cases
00:20 可能某個邊界沒處理，跑起來就是一堆 bug
00:23 然後你就得回頭跟它講這裡不對，那裡要改
00:25 改完後可能又冒出新的問題
00:27 一來一回，其實 vibe coding 的時間
00:29 全部都卡在這上面
00:31 為了解決這個痛點
00:32 這支影片想分享的是我自己一直在用的一套工作流
00:35 cross model review
00:36 講白話就是讓 Claude 跟 Codex 可以彼此自動 review
00:39 找出各自的盲點
00:41 我本來是 Claude 的死忠用戶
00:43 後來有一陣子我覺得它明顯降智了
00:45 於是我就轉去用 Codex
00:47 但用久了我又發現 codex 也有它的缺點
00:50 於是我想通一件事，我幹嘛非得二選一
00:52 這兩個 model 各有各的脾氣，各有各的強項
00:56 那我兩個都要，各取所長，不是更好嗎？
00:59 那我們直接開始
01:00 先講一下兩個模型的分工
01:02 多數時候我的主力是 Claude
01:03 大部分的討論和實作計劃
01:05 都是我跟 Claude 一起弄出來的
01:07 而 Codex 的角色是 reviewer，專門幫我挑錯
01:10 你當然可以反過來
01:11 畢竟 codex 比 Claude 便宜不少
01:13 但我自己使用下來的感覺是
01:15 Claude 很像班上那個第二名的學生
01:17 跟它合作很愉快，討論起來它也很細心
01:19 你丟一個想法給它，它能夠理解你
01:22 有時候還會給你一點驚喜
01:23 但就是偶爾會粗心，有些細節沒顧到
01:26 有些狀況想得不夠周全，所以總是考第二名
01:29 Codex 則是很無聊，跟它對話沒什麼火花
01:32 但它就是穩
01:33 尤其在處理後端比較複雜的邏輯時特別可靠
01:36 該想到的它都幫你想到了
01:38 所以 codex 考試總是可以第一名
01:40 再說一次，兩者的職責沒有對錯，單純靠個人偏好
01:44 你完全可以讓 codex 主導對話
01:46 然後讓 Claude 來 review
01:48 對我來說，reviewer 這個位子
01:50 就是要找那個無聊，但永遠不出錯的人
01:53 來幫你守最後一道關
01:54 至於那個有趣，但偶爾粗心的
01:57 讓它在前面負責互動和創意就好
01:59 把關這種事，要的就是穩，不是有趣
02:02 既然要審
02:03 那我為什麼不乾脆叫 Claude 自己再檢查一遍
02:05 還要多拉一個 Codex 進來？
02:07 因為模型在訓練時，側重點會有點不一樣
02:10 比方說 codex 在做前端的時候
02:12 常常給我一些看了會讓人吐血的設計
02:14 反觀 Gemini 或者是 Claude 在這方面就做得比較好
02:17 你自己寫的東西，自己讀了三遍，還是有錯字
02:21 結果拿給別人，人家一眼就看到了
02:24 AI 也是一樣的道理
02:25 一個 model 寫出來的東西
02:27 它自己讀起來一定都很合理
02:28 因為它就是用同一套腦袋
02:30 還有同一套假設在檢查自己
02:31 而這樣子做總是會有盲點的
02:34 我最早在做這件事的時候，完全是純手工的
02:37 當 Claude 寫完一份 plan
02:39 我把它整份複製起來，貼到 Codex 那邊
02:42 叫它幫我 review
02:43 Codex 給我一串 feedback
02:45 我再把這串 feedback 複製回 Claude 請它修改
02:48 改完我會再貼回去 Codex 給它複查
02:50 就這樣來來回回跑個好幾輪
02:52 直到兩邊達成共識
02:54 雖然我並沒有去做一個很嚴謹的 ab test
02:56 但這樣做下來，我的體感是
02:58 程式碼架構確實變得比較乾淨
03:00 技術債變少了
03:01 後修 bug 的頻率也變得非常低
03:03 不過問題也接踵而來
03:05 就是我成為了生產力的瓶頸
03:06 因為我必須擔任中間那個負責複製貼上的人肉橋樑
03:10 一開始還好，反正一次就處理一條線
03:13 慢就慢一點
03:14 但如果你需要多功能並行開發
03:16 勢必會用到 worktree
03:17 也就是說我手上同時有三條，四條開發線在跑
03:21 那每一條線的 plan
03:23 我都得這樣手動跑好幾輪的 review
03:25 所有東西都卡在我複製貼上的速度上
03:28 光是切換上下文我就快瘋了
03:30 而且有時候我會偷懶
03:31 有些 plan 比較小，看起來比較簡單
03:33 我瞄一眼就會想這個應該沒事吧
03:35 然後就直接跳過 review 了
03:37 結果最後出包的偏偏就是那些我覺得應該沒事的東西
03:40 而且常常跳過 review 省下的那五分鐘
03:42 後面要花我一兩個小時去擦屁股
03:45 這件事就是整套系統的起點
03:47 人的紀律是靠不住的
03:48 所以與其逼自己每次都記得
03:50 不如把這件事直接做成系統
03:52 讓它每一次都自動發生
03:54 不管我當下想不想做，完全不依賴我的紀律
03:57 那要怎麼做成系統？
03:58 我先用一個比喻幫助各位理解
04:00 想像一間出版社在出書之前的流程
04:03 第一個角色是作者，負責寫稿
04:06 第二個角色是門口的守衛
04:07 這個守衛只認一件事
04:09 就是你的稿子上有沒有蓋一個審核通過的章
04:11 如果沒有蓋章，對不起
04:13 你這份稿子就不准送出這道門
04:15 那要怎麼拿到章？
04:17 稿子得先送到第三個角色，也就是審稿人那邊
04:20 作者跟審稿人會來回討論
04:22 審稿人提出問題，作者要嘛把它改掉
04:25 要嘛拿出理由
04:26 反過來說服審稿人這樣沒問題
04:28 然後審稿人再看一輪
04:30 就這樣一直到兩個人都同意了
04:31 審稿人才會蓋上那個審核通過的章
04:34 守衛看到章會放行
04:35 而你身為老闆從頭到尾只會看到最後那份定稿
04:38 中間那些吵架，修改的過程
04:40 你完全不用管，也不用知道
04:42 好，那我們把這個比喻，直接套回我的系統
04:46 那個作者就是 Claude，審稿人就是 Codex
04:48 門口的守衛是一個叫 stop hook 的東西
04:51 而那個審核通過的章
04:52 就是一段寫在檔案結尾的文字，我叫它 marker
04:55 整套系統要跑起來其實非常簡單，分成兩塊
04:58 第一塊是 stop hook，扮演守衛
05:00 它是 Claude Code 裡的一個機制
05:02 每次 Claude 想收工
05:03 要把控制權交還給你之前，它就會被觸發
05:06 被觸發的時候它有兩個選擇
05:08 第一是放行，那這一輪就正常結束
05:10 第二是擋下來，然後塞一段訊息回去
05:13 讓 Claude 不結束
05:14 把那段訊息當成新的指令繼續做事
05:17 這個能擋下結束
05:18 還能塞一段提示詞回去的能力
05:20 就是整套系統能成立的關鍵
05:22 它在我的系統裡做三件事
05:24 第一，掃這一輪有沒有寫出一份 implementation plan
05:28 第二，有的話，翻到那份檔案的結尾
05:30 看有沒有那個審核通過的 marker
05:34 第三，如果沒有 marker，就擋下這次結束
05:36 塞一段話回去
05:37 叫 Claude 去跑 codex review skill
05:40 所以 stop hook 只負責攔，不負責審
05:43 第二塊就是剛剛提到的 skill
05:44 提供 Claude 一套審稿的方法論
05:47 Claude 被 stop hook 攔下來後，會閱讀這份 skill
05:49 而這份 skill 會指示 Claude 調用 Codex CLI tool
05:52 然後請 Codex 幫忙 Review
05:54 直到最後 Codex 放行這個實作計劃後
05:57 再回頭在檔案結尾蓋上那個審核通過的 marker
06:00 這兩塊平常互不相干
06:02 中間就靠 marker 這個暗號接起來
06:05 守衛只認 marker，看到就放行，沒看到就攔
06:08 而這個 marker 只有 skill 審過了才蓋得上去
06:11 你可能會問，幹嘛拆成兩塊？
06:13 其實就是單純的解耦
06:15 把攔截的工作交給 stop hook
06:17 把審核的方法論交給 skill
06:19 如果發現攔截失敗
06:20 或者攔截後 Claude Code 的行為異常，就修 stop hook
06:23 反之，如果發現 review 品質不佳
06:26 就改 skill 裡面的 review 方法論，兩者各司其職
06:30 好，兩塊都講完了
06:32 接著我把整套流程完整跑一遍給你看
06:34 一個完整的循環有五步
06:37 第一步，Claude 寫完一份 plan，想結束對話
06:40 這時會觸發第二步，也就是 stop hook
06:43 stop hook 一掃，發現檔案尾巴沒有 marker 就會擋下
06:47 然後進入第三步
06:48 Claude 收到 stop hook 預先設置好的指令
06:50 去啟動 codex review skill
06:51 呼叫 Codex 並請它 review
06:54 第四步就是兩邊一輪一輪過招
06:56 該修的修，該反駁的反駁
06:58 直到雙方有了共識且 Codex 回覆通過
07:01 最後一步是收到審核通過後
07:03 Claude 會在檔案尾端蓋上審核通過的 marker
07:06 而我的任務就是掛在那邊
07:07 等它們兩個自己討論完畢，然後進入實作
07:10 但在這套流程裡面
07:11 還有一個我自己實驗下來比較重要的事情
07:14 要特別強調
07:15 也就是審核的方式還有通過標準
07:17 這套流程的通過標準
07:19 不是你們來回討論滿三輪就算過
07:22 它的標準是兩個 model 真的達成了共識
07:25 審稿人 Codex 不能為了想趕快結束
07:27 就隨便點個頭放水
07:28 作者 Claude 也不能為了想趕快過關
07:30 就假裝問題不存在
07:32 每一個爭議，Codex 都要明確表態
07:34 要嘛它被說服了，承認你說得對
07:37 要嘛它堅持，那就要講清楚它到底在堅持什麼
07:40 有爭議，就繼續吵
07:41 要嘛你把對方說服，要嘛你被對方說服
07:44 沒有達成共識，就不准收工
07:46 講到這邊
07:47 有試過類似操作的朋友應該也想到一個可能的狀況
07:50 也就是當你丟一份其實已經很好的實作計劃給 AI
07:52 它總是能挑出那一兩個漏洞
07:54 要嘛是它沒有足夠的 context
07:55 認為某些設計決策是 bug
07:57 要嘛就是它過度追求完美導致 over engineering
08:00 底層的原因是大型語言模型有 sycophancy 的傾向
08:03 你給它什麼任務它都會使命必達
08:05 所以你請它 review
08:07 它就會想辦法給你找出幾個問題來
08:10 而這套流程能打到一個甜蜜點
08:11 能收斂而且不會一直無限拖下去
08:13 關鍵就在我從頭到尾只開同一個 Codex 對話
08:16 不是每一輪都重開一個新的 session
08:18 具體怎麼做有點枯燥乏味，你可以直接問你的 AI
08:21 我也會直接把我的 codex review skill 放在 Patreon 文章裡
08:25 這邊就不多贅述
08:26 如果每一輪都重開一個新的 Codex
08:28 它每次都是冷啟動，什麼都不記得
08:31 那它每一輪
08:32 都可能挑出一堆新的，而且不重要的小毛病
08:34 永遠挑不完，你也永遠改不完
08:37 這就變成過度設計了，沒完沒了
08:39 但如果是同一個對話，它記得自己上一輪講過什麼
08:43 所以第一輪
08:44 它就會把主要的問題一次抓出來
08:46 我把這些修掉就好
08:47 下一輪，它是來驗收的，看我改對了沒
08:50 然後往共識收斂
08:52 而不是沒事找事，重新發明一堆新問題
08:55 當然這樣的缺點就在於第一次如果漏看
08:58 可能就會漏掉一些關鍵的 bug
08:59 但其實這樣做已經可以解決 80% 的問題
09:02 省掉我大量的時間
09:04 我要的是 Codex 一次抓出真正重要的問題
09:07 不是陪我玩到天荒地老
09:09 其實我一開始的版本，有設一個最多三輪的上限
09:13 後來我發現這個上限會逼出一個很糟的結果
09:16 就是到了第三輪
09:17 不管問題到底解決了沒
09:19 它都會為了結束，而假裝沒問題
09:21 這完全違背我做這件事的初衷
09:23 所以我把上限拿掉了，只認一個標準，共識
09:27 光這樣講可能有點抽象
09:28 我舉一個比較具體的例子
09:30 假設你叫 Claude 規劃一個電商網站的下單功能
09:33 它給你一份 plan，寫得漂漂亮亮
09:36 其中有一條寫著
09:37 這個功能必須保證不會超賣
09:39 同一件商品不會賣給兩個人
09:41 聽起來很完整對吧
09:42 但你仔細看，整份 plan 從頭到尾
09:45 它都沒寫具體的處理方法
09:46 像是只剩最後一件的時候
09:48 兩個人同時按下下單
09:50 那一瞬間到底要怎麼處理
09:51 誰先搶到，另一個又是怎麼被擋下來的
09:55 Claude session 可能是因為 context 過長導致遺漏細節
09:57 或者是模型在處理這種 corner cases 的時候
10:00 本來就容易粗心大意
10:02 不管是什麼原因
10:03 這時你換 Codex 或者另外一個模型
10:05 它用第三方的角度客觀的去審核這個計劃
10:08 就有更高的機率可以發現這個實作計劃的盲點
10:11 而這就是整套系統真正的價值
10:13 講到這裡，我想把這件事往上拉一層
10:16 我做的其實不只是找第二個 AI 來審稿這麼一件小事
10:19 我是在根據自己的使用習慣替自己建一套 harness
10:22 新來的朋友可能不熟悉
10:24 harness 這個詞你可以把它理解成
10:26 包在 AI 外面的那一整套工作環境
10:28 包含你給它的限制，流程，跟工具
10:31 老闆幫員工搞個舒服的辦公室
10:33 準備零食區，休息區
10:34 目標是提高員工的工作效率
10:36 Harness 就是你幫 AI Agent 準備的辦公室
10:39 回頭看我這套流程
10:40 stop hook 扮演的是強制約束
10:42 它逼著流程一定要走完，不給你偷懶的空間
10:45 skill，扮演的是工作方法
10:47 它定義了審核的流程跟方法，到底要怎麼審
10:51 而 marker 是它們之間的握手暗號
10:54 cross model review 只是我這套 harness 裡的其中一塊而已
10:57 同樣的思路你可以拿去包任何一件
10:58 你本來就會做，但常常會偷懶跳過的事
11:02 Harness 其實不用複雜
11:03 就像一個好的產品不用太花俏
11:05 它可能非常低調，非常簡單
11:07 但只要能解決那個你生活中不起眼的小摩擦
11:09 你都會很爽很爽
11:11 像我自己建置的這個 stop hook
11:13 就是幫我解決了來回複製貼上這麼小的問題
11:15 就足以大幅提高我的工作效率
11:18 講到這裡
11:18 如果你想直接把這整套立刻搬到自己電腦裡
11:21 或者你不知道怎麼設置 stop hook
11:23 我在 Patreon 文章裡有提供完整的教學
11:26 包括我的 stop hook 設定方式
11:28 以及 codex review skill
11:29 不是什麼很複雜的 rocket science
11:31 但這是我用了兩個多月的工作流程
11:33 有需要的朋友可以在影片下方資訊欄找到連結
11:36 那我們繼續
11:37 所以當 AI 一直產出不夠好的東西
11:39 與其每次都自己跳下去手動救
11:41 我更想回頭問一個問題
11:42 我的系統，為什麼會讓這種東西過關？
11:45 然後從系統的層面
11:46 直接把這個漏洞封殺掉，讓它下次不再發生
11:49 如果你是一個 solo developer
11:51 一個人在做開發，這件事對你又特別重要
11:54 因為沒有同事可以幫你 code review
11:56 沒有人幫你把關，所有的洞都得自己扛
11:59 但你可以反過來想，你可以建一套系統
12:01 讓它扮演那個永遠不會累
12:03 永遠不會偷懶的同事
12:05 二十四小時在後面幫你守著，幫你審
12:07 這就是一個 solo developer 自己的 harness
12:10 一個人，也可以有一整個團隊的把關
12:13 與其祈禱 AI 不要出錯，不如動手
12:15 建一個讓它可以出錯
12:17 但這個錯誤會被 Harness 浪漫接住的環境
12:20 那以上就是今天的內容，我是 Gary
12:22 各位喜歡的話記得幫我按讚追蹤加分享
12:25 這是我持續創作下去的動力，我們下次見