來源：@dabit3 (Nader Dabit) on X + Cognition Blog

你有沒有過這種經驗：

AI agent 幫你寫完一個 PR，你丟去 review，bot 抓到三個 lint error、一個 security warning。然後呢？你要手動把 bot 的 feedback 複製貼上，餵回給 coding agent，等它修完，再 push，再等 CI 跑完，再看一次 review comment。

你不是在做 code review，你是在當傳話筒。

Bot 說的話，你翻譯給 agent 聽。Agent 改完的 code，你推回去給 bot 看。來回三四次，一個下午就沒了。

Nader Dabit（Cognition 的 DevRel）最近分享了一個東西，讓我覺得這個 middleman 的時代要結束了：Devin Autofix。

Clawd Clawd 歪樓一下：
人類在 bot 和 agent 之間當傳話筒。這不就是「肉身 webhook」嗎？你的工作內容等於 JSON.parse() 加 JSON.stringify()，只是中間多了一層肉做的 middleware。終於有人把這條線接起來了 (╯°□°)⁠╯

自動修復的 Loop 長什麼樣

概念其實很直覺，畫出來就是一個 loop：

  1. Agent 寫 code → 開 PR
  2. Review bot 掃描 → 留 comment（lint error、security issue、style violation⋯⋯）
  3. Devin 讀 comment → 理解問題，push fix
  4. CI 重跑 → 如果還有問題，回到第 2 步
  5. Loop 直到 CI 乾淨 → 人類進場做最終 review

就這樣。沒有人類在中間傳話。Bot 跟 agent 直接對話，人類只在最後出現。

重點是，這不只支援 Devin 自己的 review bot——任何 GitHub PR bot 都能接。SonarQube、Codacy、CodeClimate、Devin Review，隨你插。只要 bot 會留 comment，Devin 就會讀、就會修。

Clawd Clawd 忍不住說：
支援任何 GitHub PR bot 這點，說白了就是 Cognition 看透了一件事：你的 review 工具鏈一定比你的 coding agent 換得慢。今天用 SonarQube，明天換 Semgrep，後天可能又回去用 ESLint 就好。如果 autofix 只能配自家 bot，那就跟買了一台只能加中油的車一樣尷尬 ┐(￣ヘ￣)┌ 聰明的做法就是「你們吵你們的，我全部都聽」。

Bot 無窮迴圈？他們想到了

你一定在想：等等，兩個 bot 如果互噴 comment 停不下來怎麼辦？

想像一下。Bot A 說「這行要改」，agent 一改，踩到 Bot B 的規則，Bot B 又留新 comment，agent 再改，又觸發 Bot A⋯⋯恭喜你，你發明了永動機 ╰(°▽°)⁠╯

Cognition 的解法非常聰明——他們用了一個跟 firewall 一模一樣的邏輯：預設全擋，白名單放行。Devin 一開始不聽任何 bot 的話，你得手動告訴它「這幾個 bot 可以信」。有點像新員工報到第一天，主管跟他說：「這間辦公室很多人會來煩你，但你只需要聽我和 PM 的話就好。」

唯一的例外是 lint failure——不管白名單怎麼設，lint 爆了就一定修。為什麼？因為 lint error 是確定性的。你少一個分號，補上去就是補上去了，不會有人跑來說「其實我覺得那個分號不該加」。

Clawd Clawd 內心戲：
「預設忽略全部 bot，白名單 opt-in」這個設計跟你家 Wi-Fi 路由器的 MAC address filtering 根本同一個哲學——先全部拒絕，信任的才放進來。不過我們 gu-log 的 pre-commit hook 目前還停留在「大喊你壞掉了然後拒絕 commit」的階段，離自動修還很遠 ╮(╯_╰)╭ 算是⋯⋯Phase 0.5 吧。

系統 vs 工具：這才是真正的洞察

Cognition blog 裡面有一句話我覺得值得裱框：

Systems compound, tools don’t.

這什麼意思？用個比喻好了。

你去夜市買鹹酥雞，老闆一個人炸、一個人裝袋、一個人收錢。這是三個「工具」——每個人做自己的事，產出是線性的。

但如果你把這三個人串起來——炸完直接滑到裝袋區、裝完直接推到收銀台、收銀台的銷售數據回傳給炸鍋決定下一批炸什麼——這就變成「系統」了。系統會複利成長：每一輪都在優化，環節之間會互相強化。

回到 code review。單一的 coding agent 是工具——你給它指令，它產出 code，完畢。但 coding agent + review bot + CI + autofix loop，這是系統。Agent 寫的 code 越多，reviewer 累積的 pattern 越多，autofix 處理過的 case 越廣，整個 loop 越轉越順。

Clawd Clawd murmur：
「Systems compound, tools don’t.」——我覺得這句話應該刺在每個 Tech Lead 的手臂上。大部分團隊的問題不是缺工具，是工具之間沒有接起來。你有 Copilot、有 SonarQube、有 CI，但它們各自活在自己的世界裡，中間靠人類用複製貼上黏合。這不叫系統，這叫拼裝車 (๑•̀ㅂ•́)و

人類的工作變成什麼

如果 bot 能抓 lint error，agent 能自動修，CI 能自動驗證⋯⋯那人類還要做什麼？

Cognition 的答案很明確，人類的 review 收窄到三件事：

  1. Architecture — 這個 abstraction 合理嗎？要不要拆 service？
  2. Product direction — 這個 change 該不該存在？跟產品方向一致嗎？
  3. Domain knowledge edge cases — 有沒有只有人類才知道的業務邏輯特例？

注意這三件事的共通點：它們都需要 context，而且是 codebase 之外的 context。

Lint error 的 context 在 code 裡面，agent 看得到。但「我們上次因為這個 pattern 被客戶投訴」這種 context，在任何程式碼裡都找不到。這是人類的護城河。

換個角度想：review 的瓶頸，從「找 bug」移動到了「判斷 architecture」。

以前 Tech Lead 花 70% 的 review 時間在抓格式問題、命名不一致、忘記 error handling。現在這些都被 bot + agent 處理掉了。剩下的 30% 才是真正需要人類腦袋的部分——而且那 30% 才是最有價值的。

Token 花費暴增，但回不去了

Cognition 在 blog 裡承認了一件很真實的事：內部 token 花費暴增。

想想也合理。以前一個 PR 可能只跑一次 agent，現在要跑 agent 寫 code → reviewer 掃 → agent 修 → reviewer 再掃 → agent 再修⋯⋯每一輪都在燒 token。

但他們說了一句很有意思的話：回不去了。

PR 品質大幅提升，review 時間大幅縮短，人類可以專注在高價值的判斷上。一旦你嚐過這種工作方式，手動來回傳話的日子就像回到用紙本寫程式一樣難以忍受。

這是一個真實的 trade-off：花更多的錢（token），買更多的時間（人類 review 時間）和更好的品質（自動修復的 PR）。

Clawd Clawd 內心戲：
Token 花費暴增但回不去了——這跟公司從手動部署換到 CI/CD 的故事一模一樣。一開始大家會說「CI server 好貴」，但用了三個月之後你叫他回去手動 SSH 上去 deploy，他會當場辭職 (￣▽￣)⁠／

那些還沒補上的洞

當然，自動修 lint error 跟自動修整個 app 是兩回事。Cognition 也沒有假裝一切都完美——他們很誠實地說，現在的 loop 還有幾個缺角。

最明顯的一個：agent 改完 code 之後，有沒有人真的把 app 跑起來看一眼？沒有。CI 跑的是 unit test 和 lint，不是「打開瀏覽器點一點看有沒有壞掉」。你我都知道，有些 bug 是只有肉眼才抓得到的——按鈕跑到螢幕外面、loading spinner 轉到天荒地老、那種讓 PM 截圖貼到 Slack 群裡附帶三個驚嘆號的 bug。

還有 unit test 的問題。Agent 修了一個 bug，但它有沒有順手補一個 test 確保這個 bug 不會復活？大部分時候，沒有。這就像你修好了水龍頭的漏水，但沒有拿膠帶做個記號提醒自己下次檢查——遲早還是會再漏。

Clawd Clawd 真心話：
Cognition 承認這些 gap 我反而更信任他們。每次看到「我們的 AI 解決了一切問題」的公告，我的第一反應是「你的 QA 呢？」。敢說自己哪裡還做不到的公司，通常是真的在做事，不是在做簡報 (◕‿◕)

如果你想像一個終極版本：agent 寫 code → bot review → agent 修 → CI 跑 → E2E test 跑 → agent 看 test 結果再修 → 全部綠燈 → 人類 approve。整個流程裡面，人類只需要按一個按鈕：Approve 或 Reject。

好，那我明天上班可以幹嘛

假設你是 Tech Lead，看完覺得「嗯，有道理」。但回到辦公室，桌上還是那二十幾個等 review 的 PR。怎麼辦？

先別急著導入什麼工具。先低頭看看你已經有的東西。

你八成已經有 coding agent 了——GitHub Copilot、Cursor、Devin，隨便一個。你八成也有 review bot——SonarQube、CodeClimate 之類的。這兩邊都有了。但問題是，它們中間隔了一個你。Bot 在左邊喊「這裡有問題」，agent 在右邊等指令，而你就是那個來回跑的工讀生。

差的就是那條線。那條讓 bot 的 comment 自動餵進 agent 的線。

把那條線接起來，你就從「每一輪都要到場的傳話筒」變成「終場才出現的裁判」。至於哪些 feedback 該自動修、哪些該留給人類——就用 allowlist 的邏輯。Prettier 少個分號？自動修，不用煩你。Security scanner 噴警告？那得你來看。這個分界線畫清楚了，你就知道哪些事情值得花 token，哪些事情值得花你的腦細胞。

延伸閱讀

Clawd Clawd 內心戲：
Cognition 還偷偷塞了一個超離譜的 onboarding 方式：把 PR 的 github.com 換成 devinreview.com 就能用 Devin Review。以前接一個 review bot 要設 webhook、裝 GitHub App、搞 OAuth token，搞到懷疑人生。現在改一下 URL 就好？這 DX 根本是作弊 (⌐■_■)

而且 token 成本真的不用怕。一個 PR 多花 $0.50 的 token，但省了 Tech Lead 30 分鐘的 review 時間？你去算算 Tech Lead 的時薪，這筆帳根本不用算就知道答案。

把傳話筒放下吧

回想一下開頭那個場景——你坐在電腦前，把 bot 的 comment 複製貼上、餵給 agent、等它改完、推上去、等 CI 跑、再看一輪 comment。這個流程其實跟二十年前 Tech Lead 手動 SSH 進 production server 跑 deploy script 沒什麼不一樣。都是人類在做機器本該自己處理的事。

差別只在於，二十年前的解法叫 CI/CD pipeline，現在的解法叫 autofix loop。本質都一樣：把人類從 loop 裡面抽出來，放到 loop 外面去做判斷。

當然，目前 agent 還沒辦法判斷 architecture，E2E testing 和自動補 unit test 都還是進行式。但方向已經很清楚了：人類的角色會一直往上移——從找分號錯誤，到判斷設計 pattern，最後到拍板產品方向。

所以，如果你現在還在當那個傳話筒，是時候把 bot 和 agent 之間的線接起來了。

畢竟，你當初學寫程式不是為了當 JSON 翻譯機的嘛 (•̀ᴗ•́)و