上萬道菜被同一雙筷子檢查過，而那雙筷子現在開放借你了

9月7日，一篇聊阿裏開源專案 open-code-review 的文章在技術圈流傳開來。這個用 Go 寫的專案，源自阿裏巴巴集團內部的 AI 程式碼審查助手，介紹裡寫得很直白：服務過數萬名開發者，識別過數百萬個程式碼缺陷，現在開源出來。不到一個月，GitHub 上的星號衝破一萬八千，Apache-2.0 授權，任何人都能下載來用。

工程師看到的是工具。但我看到這則新聞的時候，腦子裡浮現的是一間後廚，以及那個總在菜上桌前，用筷子把每一盤都夾過一遍的人。

每間像樣的後廚，都有一個「審菜」的人

你大概遇過這種場景：宴客那天，桌上十幾道菜，炒的燉的炸的輪番出鍋，油煙機轟轟地響，每個人手上都有活。這時候最怕什麼？最怕沒人試味道。

鹽放重了沒人發現，湯底燒過頭帶著一股焦苦，那盤看起來油亮亮的青菜其實底下還是生的。做菜的人自己嚐，往往越嚐越順口，因為你的舌頭早就習慣了自己的手路。這跟工程師自己審自己的程式碼，越看越順眼，是同一件事。

老一輩的辦桌師傅有個角色，有些地方叫「管菜的」，有些就叫品管。他不掌勺，手上的那雙長筷只做一件事：每道菜出鍋，先夾一筷子，看色、聞香、試鹹淡。涼了該回鍋的回鍋，鹹了該補湯的補湯。一場兩百人的辦桌下來，他用那雙筷子檢查過的菜，比任何人喫的都多。

open-code-review 做的事，說穿了就是把這雙筷子交給了機器，而且是一雙服務過數萬人、檢查過數百萬個缺陷的筷子。現在阿裏把這雙筷子放到開放的路邊，任何人都能撿起來用。

為什麼通用幫手做不好，專職的才行

文章裡提到一個很有意思的對比。很多人用通用型的 AI 助手做審查，踩過幾個坑：改了三十個檔案，報告只覆蓋五個；說第四十二行有問題，跳過去一看是個空行；提示詞改幾個字，審查品質就大幅波動。

把它翻譯成廚房的語言，你馬上就懂。你請一個什麼都會一點的幫手來試菜，他今天嚐出湯鹹了，明天同一鍋湯卻說剛好。他不是舌頭笨，是他手上同時太多事了，一邊顧火一邊顧刀，注意力散掉了。

open-code-review 的解法是把事情拆開：能靠規則保證的步驟，絕不讓模型用猜的。哪些檔案該審、哪些該過濾，交給確定性工程，就像品管師傅的檢查清單，哪道菜必試、哪道只需目視，白紙黑字寫死，不靠心情。相關的檔案打包成同一個審查單元，好比同一組菜色一起試，才知道味道搭不搭。而真正需要判斷的部分，讀完整檔案、比對多處改動、給出有脈絡的缺陷描述，才交給 LLM Agent。

定位甚至能準到行級。這在廚房裡叫什麼？叫「這盤是鹽放多了，不是醬油放多了」。很多試味的人只會說「有點鹹」，厲害的能告訴你問題出在哪一步、哪一勺。方向錯了，回鍋救菜就會救錯地方。

這種「清單管流程、師傅管判斷」的分工，其實在很多老手藝裡都看得到。我們先前寫過廚房裡的筆記、火候與一場家宴的分工，聊的也是同一件事：記憶交給本子，判斷留給人。現在阿裏把這套廚房哲學寫成了程式，還開了源。

一條指令就能借到的筷子

實際用起來的門檻低得出奇。一條 npm 指令裝完，ocr 命令全域可用。模型設定支援 OpenAI、Anthropic 等介面，也能自己加。要審工作區裡所有變更，一行 ocr review；要對比兩個分支，加上 --from 和 --to 就行。

文章裡給了一個數字：中等規模的改動，大概一到三分鐘審完。

一到三分鐘。你在爐子前等一鍋油熱，大概就是這個時間。以前這段時間是空轉的，現在它可以是一雙筷子替你把整桌菜快速掃過一遍的時間。這速度來自工程端的並發拆分，大改動自動切成多個子任務同時跑，就像大辦桌時不只一位品管，一排人各自守住自己的那一爐。

開源這件事，像食譜被公開了

最後想聊「開源」本身。

一家公司把內部用了很久的工具放出來，Apache-2.0，隨你改隨你用。這在飲食世界裡有個很貼切的對照：老店把祖傳食譜公開了。為什麼要公開？因為一道菜的配方從來藏不住味道本身，藏住的只是比例和火候的細節。公開了，別人能照著做，能改出自己的版本，而原店的名聲反而更響。

數萬名開發者用過、數百萬個缺陷被它抓出來，這些數字是這雙筷子的資歷。現在輪到你，不用拜師，不用人情，一條指令就能借來用。

回到你自己的餐桌

寫到這裡，工具的部分講完了，但我想把話拉回你家廚房。

科技新聞每天很多，真正值得留在餐桌上的，往往是那個被反覆驗證過的道理：自己做的菜，自己嚐不準。無論是程式碼還是一鍋湯，都需要一雙外來的、有經驗的、不怕得罪人的筷子。下回家宴，菜上桌前，試著請家裡那個味覺最刁的人先夾一口，認真聽他說鹹淡。那口判斷，比你自己的十口都值錢。

至於那雙已經檢查過數百萬個缺陷的筷子，它就放在 GitHub 上，等你哪天需要。就像我們之前聊廚房裡被追問火候與一鍋湯斷火重燉時說的，被問、被審、被試味，從來都是為了上桌那一刻，沒有人皺眉。