DEV Community

JH5
JH5

Posted on • Originally published at Medium

AI Agent協作的品質監控策略

AI Agent協作的品質監控策略

AI Agent協作帶來的技術都更

前一篇整理了一些近期的感想,AI Agent協作帶來的技術都更,整體感覺上對於個人的產出,目前是正向的十倍界王拳的感受,不過往上一層從系統層面跟團隊的角度來看,還是有一些待觀察的點。

1. Review Bottleneck

以前的工作經驗大多是region或是專案的 Architecture 在kick off初始期,最容易會遇到這樣的狀況,不過現在的狀況是每個工程師,過去一天「產出」500–1000 行程式碼已經是很頂的,而現在,一天可能需要「審查」由 Agent 輔助產出的 5000 行程式碼或是更多,甚至是Agent常常會像是熱心的年輕老師幫你生成很多除錯的MD檔案而你根本無法從頭讀起XD

這個新的「審查瓶頸 (Review Bottleneck)」也導致了一種「AI 生產力悖論 (AI Productivity Paradox)」:

  • 個人效率:大幅度提升

  • 團隊流通率 (Throughput):不升反降

大量的 Pull Request (PR) 湧入,但團隊中能夠進行審查的資深工程師的時間是有限的,PR 卡住了,整個開發流程也隨之停擺,再用一個Agent來幫忙Review ?

2. AI 成為「技術債加速器」?

面對這一坨一坨來的「程式碼」,最大的風險不是「審查不完」,而是「隨便審查」。

當被迫在10 分鐘內審查一個 2000 行的 PR 時,根本不可能逐行閱讀,只能「大致看」,然後基於對同事(其實是他的 Agent?)的信任而按下「Approve」。

Agent 產出的程式碼,往往具有以下特點:

  1. 缺乏上下文,重複造輪: 它不知道團隊在三個月前已經寫過一個類似的工具函式,於是它又寫了一個新的,導致程式碼冗餘。

  2. 過度工程化: 您只想要一個簡單的腳本,它卻給了您一個包含三個設計模式和五個抽象層的複雜架構。

我們一直以為AI是史上最高效的「技術加速器」,但他其實是史上最高效的「技術債加速器」,今天的「高效率」,會不會是未來三年的「維護地獄」?

三、怎麼用AI幫忙審查?

傳統的「逐行審查」顯然已經破功,而網路上,那些已經在第一線戰鬥的團隊,開始演化出新的應對策略,核心思想是:不要試圖「讀完」所有程式碼,要「驗證」其核心意圖。

1. 從「程式碼審查」轉向「意圖審查 (Intent Review)」

工程師的時間,不該花在檢查「命名風格」或「語法細節」上 — — 這些事情應該交給 AI 去做

  • 新工作: 專注於審查 AI 無法判斷的業務概念。

  • 架構合規性: 這個 PR 是否引入了新的、未經許可的外部3PP?是否正確使用了我們定義的內部 API?

  • 核心業務邏輯: 它是否正確理解了「會員 VIP 等級」的複雜計算規則?

  • API 介面設計: 它定義的這個新 API 介面是否易於理解、考慮到未來擴展性、並處理了錯誤狀態?

2. AI 互評(AI reviews AI)

面對 Agent 產出的程式碼,最高效的第一道防線是另一個 Agent

  • 實務做法: 在 CI/CD 流程中或 PR 流程中,自動觸發一個「AI Reviewer」。

  • AI Reviewer 的任務:

  • 檢查 90% 的低階問題:程式碼風格、潛在 Bug(如 null 檢查)、安全漏洞(如 SQL 注入)。

  • 總結 PR: 用自然語言總結這個 PR 的「核心變動」,幫助人類審查者快速抓住重點。

  • 質詢 Agent: 針對可疑的程式碼片段,自動向 PR 提交者(和他的 Agent)提出問題。

3. 強制「測試先行 (Test-First)」

在 AI 時代,測試程式碼的重要性,超過了實作程式碼

  • 新的審查鐵律: 我們無法信任 Agent 的實作,但可以驗證 Agent 產出的測試

  • 審查流程轉變: 打開一個 PR,第一時間不是看原始碼 (.js /.py),而是先看測試碼 (_test.js / test_*.py)

  • Agent 是否只寫了「快樂路徑 (Happy Path)」的測試?

  • 是否測試了邊緣案例 (Edge Cases)?(例如:輸入為空、輸入超長)

如果 Agent 能產出高質量、高覆蓋率的測試,那麼產出的實作程式碼是「正確」的機率將大幅提升。

4. 強制 Agent 「小步快跑」

作為AI Agent的控管者,我們有責任從一開始就阻止 5000 行的 PR 出現。

  • 指令: 在第一步(Prompt)就必須明確要求 Agent:「將這個複雜任務拆解為 5 個可以獨立交付的小步驟,並為每一步驟分別生成程式碼。

  • 好處: 將一個巨大、無法審查的 PR,分解為 5 個小型、易於理解的 PR。

上面這個也是過去帶新人時,常常提醒的拆分task或是團隊git branch上policy應該要訂定的。

過去我們在團隊進行規模化成長下習慣訂定的Dev Guideline,跟Agent協作後,更應該採用並且架構化 (Architect)」相關的審查流程。

後面還有其他除了跟Agent協作之外,你還要習慣跟同事的Agent一起協作的問題可以來好好討論一下。

#ai#ai-agents

Top comments (0)