Baz 怎麼把規格變成合併檢查

我拆 Baz 的做法：把 Figma、Jira、瀏覽器預覽串成逐條檢查，讓 PR review 不再只看 diff，而是直接驗證產品意圖。

我用過一堆 code review 流程，老實講，很多都很會演。diff 看起來乾淨、測試也過了、CI 綠燈亮著，結果一進預覽環境就開始露餡。按鈕位置不對、空狀態文案不對、某個互動步驟根本沒出現。最煩的是，大家還會先誇一句「這個 PR 很整齊」，好像整齊就等於做對。不是啊，review 如果只看程式碼長相，不看產品意圖，那它其實只是在挑字體，不是在驗收。

我看到 Baz 這篇關於用 Amazon Bedrock AgentCore 提高 AI agent code review 準確度的文章時，心裡只有一個反應：對，這才像在做事。它不是把模型調得更會講漂亮話，而是把 review 的判斷基準改掉。它把 Figma 和 Jira 拉進來，拆成細粒度檢查，再到瀏覽器裡看實際跑起來的介面。這種做法很土，但土得很對。

別再把 diff 當成完整真相

「Baz 想把缺少的那一層驗證自動化，把意圖、行為與實作放進同一條 review 流程。」

翻譯一下就是：他們不再假裝 code review 可以單獨回答產品問題。diff 只能告訴你「改了什麼」，不能可靠地告訴你「是不是符合設計」、「是不是滿足驗收條件」、「是不是保住了 PM 和設計師在意的互動細節」。

我自己最常遇到的爛尾場景，就是某個元件改完了，測試也綠了，大家就以為差不多了。結果一打開預覽，才發現 spacing 不對、disabled 狀態沒出現、某個流程多了一步。不是程式碼不對，是 review 的問題定義就錯了。你如果只盯著 diff，永遠只會得到「程式有變」，不會得到「產品有沒有做對」。

Baz 的思路是把 review 從「程式驗證」升級成「產品驗證」。這句聽起來很大，但實作上其實很務實：先把需求來源抓進來，再看跑起來的系統是不是跟需求對得上。這才是 AI reviewer 真正該做的事，不然它只是會講話的 lint tool。

實操上，我會先把 reviewer 的輸入改掉：不要只餵 PR diff。至少要把設計稿、工單、驗收條件、預覽連結一起丟進去。沒有產品意圖，agent 只能猜；而猜得很像的東西，通常最害人。

Figma 和 Jira 才是規格，不是聊天串

「規格子代理會同時讀取來自 Figma 的視覺規格，以及來自 Jira 的功能規格。」

這句話我很買單，因為它直接點出真實世界的 truth source 在哪裡。不是 Slack 討論串，不是會議記憶，不是某個人腦中模糊的「我記得應該是這樣」。真正能拿來判斷的，還是設計系統、工單、驗收條件這些有結構的東西。

也就是說，Baz 不是讓 agent 自己幻想規格，而是讓它去讀兩種不同的來源。Figma 提供視覺意圖：排版、間距、層級、狀態、元件長相。Jira 提供功能意圖：使用者能不能完成任務、什麼算 done、哪些 edge case 要管。少了任何一邊，review 都會歪掉。只看 Figma，會變成挑像不像；只看 Jira，會變成只管功能過不過，不管畫面是不是整個壞掉。

我很少看到團隊真的把這兩個來源整合好。多數時候是設計師在 Figma 改了，工程師看 Jira 做，最後 reviewer 只能靠肉眼補洞。這種流程很累，而且很容易漏。Baz 的做法比較像把大家本來就分散在不同系統裡的真相，拉回同一個檢查面上。

如果是我自己要抄，我會先做一個需求匯入層，把 Figma frame、Jira acceptance criteria、相關截圖和註解都轉成可檢查的條目。每條條目都要能回指原始來源。因為只要不能回指，後面所有判斷都會變得很玄。玄的東西，最後通常都只能靠人肉拍板。

• 視覺規格：Figma frame、元件狀態、字級、間距、層級、色彩。
• 功能規格：Jira 驗收條件、流程步驟、例外情境、完成定義。

把一個功能拆成很多小判決

「系統接著會啟動彼此隔離的子代理工作者，每個工作者對應一條需求，專門驗證那條需求。」

這種拆法我很認同，因為一個大 agent 想一次看完整個功能，最後通常只會變成一坨模糊印象。它會記錯、漏看、腦補，然後講得像自己很有道理。Baz 把工作切成一條需求一個子代理，這很無聊，但也很有效。

白話講就是：不要問「這個功能整體有沒有做好」，要問「這一條驗收條件有沒有被滿足」。前者太大，後者才可操作。當 agent 只負責一件事，它才比較不會飄，也比較好 debug。哪一條失敗、哪一條需要人工複查，一眼就看得出來。

我以前碰過那種 review 系統，輸出一長串像論文摘要，看到最後還是不知道它到底在反對什麼。是規格不清楚？是 browser 操作失敗？還是模型自己腦補？完全拆不開。子代理的價值就在這裡：把大而空的判斷，切成可以追的單位。這樣你才能真的修，不是只會安慰自己「AI 有看過」。

而且 Baz 後面還有彙總報告，這點也很重要。人不想看 20 段 agent 對話，他想看結論、證據、下一步。子代理負責辛苦幹活，彙總器負責把結果整理成團隊能用的格式。這才是正常的工程流程，不然你只是把噪音自動化。

實作上，我會先定義需求 schema，再讓每個 worker 只處理一條需求。輸出也要限制成 pass / fail / needs_human_review，再附證據。千萬不要讓摘要 agent 自己編故事，因為一旦讓它自由發揮，最後就會產生一份看起來很完整、其實完全沒用的漂亮謊言。

• 好的工作單位：一條驗收條件、一個 UI 狀態、一條互動路徑。
• 不好的工作單位：「幫我 review 整個功能」或「看起來對就好」。

真正的答案在瀏覽器，不在原始碼

「實作子代理是這個架構的核心……它們會在實際的預覽環境中渲染真正的實作，並以視覺方式驗證 UI 是否符合 Figma 設計，以及功能是否符合 Jira 規格。」

這段是我最在意的。靜態分析有用，但它永遠看不到瀏覽器裡真正在發生什麼。Baz 用 Amazon Bedrock AgentCore 的瀏覽器工具打開預覽環境、看 DOM、模擬事件、對照規格。這才是該驗證產品行為的層級，因為使用者就是活在這一層。

也就是說，agent 不再只是讀 code，而是會點、會輸入、會觀察畫面變化。這很重要。很多 bug 在 code review 裡根本看不出來，因為程式碼長得很合理；真正出事，是 app 跑起來之後，state 變了、畫面沒跟上、互動流程卡住。這種問題，瀏覽器裡才會露出來。

我自己最常撞到的就是表單、modal、條件式渲染、disabled 狀態這些小東西。程式碼都在，元件也 render 了，但狀態切換錯了，或某個控制項被動畫蓋掉，或某個步驟根本不會出現。這些東西不是看 diff 就能抓到的。你要真的打開預覽，真的去操作，才知道有沒有鬼。

AgentCore 在這裡扮演的角色也很務實：隔離、沙箱、可重複執行。因為一旦讓 agent 進瀏覽器，你就得控制它不要亂跑、不要吃到別人的 session、不要依賴某台開發機的怪狀態。這些都不是模型問題，是執行環境問題。

實操上，我會把 review agent 接到真實的 preview deployment，再讓它像使用者一樣操作頁面。能用 browser automation 驗的，就不要只靠 code 讀心。像畫面狀態、互動流程、輸入回饋、錯誤提示，全部都應該在瀏覽器層驗證。只看原始碼的 reviewer，基本上就是瞎子。

如果你要找工具起點，可以先看 Amazon Bedrock 做模型推理、AgentCore 做瀏覽器執行，再接一個盡量接近正式環境的 preview。預覽如果是假的，review 也會跟著假。

把模型留給判斷，別叫它管機器

「Amazon Bedrock AgentCore 成了建立能驗證真實產品行為的 AI code reviewer 的基礎。」

Baz 這裡做對的一點，是把模型的工作範圍收得很乾淨。LLM 負責解讀規格、比對觀察結果、下判斷；AgentCore 負責瀏覽器執行和隔離。這個分工很重要，不然系統很快就會變成一個需要人類照顧的模型玩具。

翻成白話就是：模型應該做 reasoning，不該做 infrastructure babysitting。它不需要去煩瀏覽器怎麼啟動、session 怎麼維持、sandbox 怎麼設。那些是平台的事，不是模型的事。你把這些混在一起，最後每個錯誤都會變得很難查，因為根本不知道是推理錯、執行錯，還是環境錯。

我很喜歡這種切法，因為故障邊界比較清楚。模型判錯，就回頭查 prompt、查需求拆解；瀏覽器壞掉，就查執行層。兩邊分開，系統才有辦法維護。否則你會得到一個很會講道理、但出了事完全沒人知道該修哪裡的東西。

Baz 也提到 observability，這點我覺得很多團隊都會拖到最後才補。你讓 agent 對 UI 狀態下判斷，就一定要知道它看到了什麼、點了什麼、為什麼判 pass 或 fail。不然你只是把「自動化信心」包裝得比較漂亮而已，出事時一樣沒人知道發生什麼。

實作上，我會把 reasoning 和 execution 完全拆開。模型只處理規格與觀察，執行層只負責跑瀏覽器、抓截圖、記 DOM snapshot、留 trace。最後一定要有可重播的路徑，讓人能回頭看 agent 為什麼下這個結論。沒有 trace 的自動判斷，基本上都不值得信。

• 模型負責：規格解讀、證據比對、結論輸出。
• 平台負責：瀏覽器啟動、環境隔離、步驟記錄、快照保存。

把結果送回開發者真的會看的地方

「審查完成後，結果會分發到適當管道：直接留言到 GitHub PR、透過 Slack 通知團隊可見性、並把發現的問題自動連回 Jira 追蹤與修正。」

這一段看起來很平凡，但其實是整套流程能不能活下來的關鍵。你如果把 review 結果丟到另一個獨立儀表板，大概沒多久就沒人看了。Baz 把結果送回 GitHub PR、Slack、Jira，這才是對的。因為開發、協作、追蹤，本來就已經在這些地方發生。

白話講就是：工具不要逼人換腦袋。開發者想在 PR 看評論，QA 想知道問題有沒有追蹤，PM 想看 ticket 有沒有回連。你如果硬要大家再去一個新後台查 AI 意見，採用率很快就掉光，而且掉了還不一定有人承認是因為流程太麻煩。

我看過太多內部工具死掉，原因不是功能爛，是輸出放錯地方。邏輯很強，交付很弱。Baz 的好處就在這裡：它知道 review 的輸出不是報告本身，而是後續行動。找得到位置、接得上流程，團隊才會真的用。

我自己會再多加一個原則：每個發現都要有可追蹤的 issue 編號。沒有對應 ticket 的 comment，通常只會變成噪音。只要 agent 能把問題自動連回 Jira，後續修正就不用重講一次背景，這點很省時間。

實操上，你可以先決定三種輸出要放哪裡：阻擋性問題進 PR、跨團隊可見性進 Slack、後續修正進 Jira。不要讓 agent 找不到出口。找不到出口的發現，最後通常就等於沒發現。

可抄的模板

# 規格審查 Agent 模板：把 PR 變成可驗證的合併檢查

## 目標
在合併前，驗證 PR 是否同時符合產品意圖、設計意圖與功能需求。

## 輸入
- GitHub Pull Request 連結
- Figma 檔案或 frame 連結
- Jira 工單或驗收條件
- 預覽環境 URL
- 原始碼存取權

## 流程
1. PR webhook 觸發審查工作。
2. 從 Figma 抓取視覺規格。
3. 從 Jira 抓取功能規格。
4. 把規格整理成一條條可驗證需求。
5. 針對每一條需求啟動一個子代理。
6. 每個子代理只做一件事：
   - 讀相關原始碼
   - 打開預覽環境
   - 用瀏覽器操作 UI
   - 比對觀察結果與需求
   - 回傳 pass / fail / needs_human_review 與證據
7. 彙總所有子代理結果。
8. 把摘要貼回 GitHub PR。
9. 把通知送到 Slack。
10. 對失敗項目建立或更新 Jira issue。

## 需求 schema
- id：字串
- source：figma | jira | both
- type：visual | functional | interaction
- description：字串
- expected_result：字串
- evidence_required：screenshot | dom_state | console_log | network_log | step_trace
- severity：blocker | major | minor

## 子代理輸出 schema
- requirement_id：字串
- verdict：pass | fail | needs_human_review
- summary：字串
- evidence：
  - screenshots
  - DOM snapshots
  - interaction steps
  - relevant code references
- confidence：low | medium | high
- follow_up：字串

## 審查提示詞
你是一個 code review agent。你的工作是驗證實作是否符合需求。
請同時使用原始碼、預覽環境與需求來源。
不要猜。若證據不足，請標記 needs_human_review。
只輸出要求的 schema 欄位。

## PR 留言格式
### 審查摘要
- 通過：X
- 失敗：Y
- 需人工確認：Z

### 阻擋性問題
- [requirement_id] 問題簡述與證據連結

### 非阻擋性問題
- [requirement_id] 問題簡述與證據連結

### 備註
- 截圖連結
- 瀏覽器 trace 連結
- Jira 後續處理連結

## 操作原則
- 以具體證據優先，不靠模型直覺。
- 每個子代理只處理一條需求。
- 執行紀錄與最終判斷分開保存。
- 證據不足時要保守失敗。
- 永遠保留回溯到原始規格的能力。

我會偷走的不是模型，是這套判斷方式

我對 Baz 的讀法很簡單：它不是把 AI 塞進 code review 而已，而是把 review 能判斷的範圍整個改掉。它不再只問「diff 看起來有沒有問題」，而是問「產品證據有沒有對上」、「瀏覽器裡真的有沒有跑出來」、「每條需求能不能被追溯」。這才是有用的方向。

如果你也要做類似的東西，別先從模型開始。先問你到底要它回答什麼問題，再決定要抓哪些證據、怎麼拆成小檢查、結果要送去哪裡。這三件事沒想清楚，後面接再多 agent 都只是堆戲法。

而且我真的不建議跳過瀏覽器那層。很多團隊會覺得那一步很煩、很慢、很像多此一舉。但說白了，使用者看到的就是瀏覽器裡那個東西。你不去那裡驗，review 再漂亮也只是紙上談兵。

來源：https://aws.amazon.com/blogs/machine-learning/how-baz-improved-its-ai-agent-code-review-accuracy-using-amazon-bedrock-agentcore/。我這篇是拆解與模板整理，屬於衍生寫作；模板段落與實操建議則是我自己的整理版本。