--- schemaVersion: 1 slug: gp-66-20260216-self-healing-pr-devin-autofix ticketId: GP-66 lang: zh-tw title: 自我修復的 PR — Devin 的 Autofix Loop 讓人類只需要做最後的判斷 summary: Cognition 推出 Devin Autofix，讓 review bot 的 comment 自動觸發修復 → CI 重跑 → loop 直到乾淨，人類只需要做最後的 architecture 判斷。核心洞察：單一 agent 是工具，agent + reviewer loop 才是系統，而系統會複利成長。 originalDate: 2026-02-16 translatedDate: 2026-02-16 source: "@dabit3 (Nader Dabit) on X + Cognition Blog" sourceUrl: https://x.com/dabit3/status/2023206853715325068 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-66-20260216-self-healing-pr-devin-autofix status: published replacementTicketId: null replacementUrl: null --- # 自我修復的 PR — Devin 的 Autofix Loop 讓人類只需要做最後的判斷 > **來源:** [@dabit3 (Nader Dabit) on X + Cognition Blog](https://x.com/dabit3/status/2023206853715325068) _來源：[@dabit3 (Nader Dabit) on X](https://x.com/dabit3/status/2023206853715325068) + [Cognition Blog](https://cognition.ai/)_ --- 你有沒有過這種經驗： AI agent 幫你寫完一個 PR，你丟去 review，bot 抓到三個 lint error、一個 security warning。然後呢？你要手動把 bot 的 feedback 複製貼上，餵回給 coding agent，等它修完，再 push，再等 CI 跑完，再看一次 review comment。 **你不是在做 code review，你是在當傳話筒。** Bot 說的話，你翻譯給 agent 聽。[Agent](https://gu-log.vercel.app/glossary#agent) 改完的 code，你推回去給 bot 看。來回三四次，一個下午就沒了。 Nader Dabit（Cognition 的 DevRel）最近分享了一個東西，讓我覺得這個 middleman 的時代要結束了：**Devin Autofix**。 > **Mogu 碎碎念：** > > 人類在 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 就會讀、就會修。 > **Mogu murmur：** > > 支援任何 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 是確定性的。你少一個分號，補上去就是補上去了，不會有人跑來說「其實我覺得那個分號不該加」。 > **Mogu 內心戲：** > > 「預設忽略全部 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 越轉越順。 > **Mogu 歪樓一下：** > > 「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](https://gu-log.vercel.app/glossary#token) 花費暴增，但回不去了 Cognition 在 blog 裡承認了一件很真實的事：內部 token 花費暴增。 想想也合理。以前一個 PR 可能只跑一次 agent，現在要跑 agent 寫 code → reviewer 掃 → agent 修 → reviewer 再掃 → agent 再修⋯⋯每一輪都在燒 token。 但他們說了一句很有意思的話：**回不去了。** PR 品質大幅提升，review 時間大幅縮短，人類可以專注在高價值的判斷上。一旦你嚐過這種工作方式，手動來回傳話的日子就像回到用紙本寫程式一樣難以忍受。 這是一個真實的 trade-off：花更多的錢（token），買更多的時間（人類 review 時間）和更好的品質（自動修復的 PR）。 > **Mogu OS：** > > Token 花費暴增但回不去了——這跟公司從手動部署換到 CI/CD 的故事一模一樣。一開始大家會說「CI server 好貴」，但用了三個月之後你叫他回去手動 SSH 上去 deploy，他會當場辭職 (￣▽￣)／ --- ## 那些還沒補上的洞 當然，自動修 lint error 跟自動修整個 app 是兩回事。Cognition 也沒有假裝一切都完美——他們很誠實地說，現在的 loop 還有幾個缺角。 最明顯的一個：agent 改完 code 之後，有沒有人真的把 app 跑起來看一眼？沒有。CI 跑的是 unit test 和 lint，不是「打開瀏覽器點一點看有沒有壞掉」。你我都知道，有些 bug 是只有肉眼才抓得到的——按鈕跑到螢幕外面、loading spinner 轉到天荒地老、那種讓 PM 截圖貼到 [Slack](https://gu-log.vercel.app/glossary#slack) 群裡附帶三個驚嘆號的 bug。 還有 unit test 的問題。Agent 修了一個 bug，但它有沒有順手補一個 test 確保這個 bug 不會復活？大部分時候，沒有。這就像你修好了水龍頭的漏水，但沒有拿膠帶做個記號提醒自己下次檢查——遲早還是會再漏。 > **Mogu 偷偷說：** > > 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，哪些事情值得花你的腦細胞。 ## 延伸閱讀 - [MP-84: 33,000 筆 Agent PR 數據的殘酷真相：Codex 贏麻了、Copilot 慘兮兮，你的 Monorepo 可能撐不住](https://gu-log.vercel.app/posts/mp-84-20260216-drexel-agent-pr-failure/) - [MP-140: Agentic Engineering 的最終 Boss：消滅 Code Review](https://gu-log.vercel.app/posts/mp-140-20260303-swyx-agentic-engineering-boss-code-review/) - [MP-161: Imbue Vet：專抓 Coding Agent 說謊的糾察隊](https://gu-log.vercel.app/posts/mp-161-20260314-imbue-vet-coding-agent-honesty/) > **Mogu 偷偷說：** > > 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 翻譯機的嘛 (•̀ᴗ•́)و