📌 本文重點
- AI 寫程式一定要搭配 AI 審查流程
adamsreview提供多代理、分階段 PR 審查React Doctor專治 AI 產出的 React 小雷- 組合成「AI 寫 + AI 審 + 人類決策」完整 workflow
當你開始大量用 AI 寫程式時，真正的風險不在「寫不出來」，而在「錯誤、壞味道、性能坑」靜靜被合進主幹，所以現在比起寫程式，更需要好的 AI 審查與補救工具。
下面用兩個最近爆紅的開源工具 adamsreview 和 React Doctor，帶你組一條「AI 寫程式 + AI 審 PR/修 bug」的實戰流程。
核心功能：兩個工具，一條龍
工具總覽
| 名稱 | 核心功能 | 免費方案 | 適合誰 |
|---|---|---|---|
| adamsreview | 多代理分工的 PR 審查，深度檢查邏輯與安全 | 完全開源 | 用 GitHub / GitLab、有 PR 流程的後端或全端團隊 |
| React Doctor | 自動檢測、修正 AI 產出的 React 程式碼 | 完全開源 | 用 Claude/ChatGPT 產生 React/TSX 的前端團隊 |
接下來分別講清楚：
- adamsreview 怎麼把 PR 審查拆給多個 AI 代理，使錯誤更難漏掉。
- React Doctor 怎麼專門處理「AI 產生 React code 一堆小雷」這件事。
- 最後用這兩個工具，組裝一條可直接抄走的開發 workflow。
一、adamsreview：多代理分工的嚴謹 PR 審查
核心功能
adamsreview 是一個專為 Claude Code 設計的插件（slash commands），重點是：
- 多階段、多代理 PR 審查
- 不是一次跑完，而是分成好幾個階段：整體變更 → 文件/測試 → 安全/性能 → 修正建議。
- 每個階段可啟動平行子代理（sub-agents），例如一個看 API 變更，一個看錯誤處理。
-
審查狀態存在本地 JSON 裡，可以在不同命令之間保持上下文。
-
更少漏網 bug、更少誤報
作者在 HN 上提到，它在實戰中比：
- Claude 內建
/review、/ultrareview - CodeRabbit、Greptile
更常抓到真實 bug，同時少講廢話。
實際上常被抓到的包括：
- 新增邏輯沒有對錯誤狀況做邊界檢查
- 漏更新單元測試或 fixture
- API 變更與文件不一致
- 可預期的性能問題（例如重複查詢、無 cache）
💡 關鍵： 多階段、多代理的拆解方式，讓 adamsreview 比一般單次
/review更容易抓到真正 bug，且減少冗長誤報。
- 直接嵌入現有 PR 工作流
- 提供像
/review、/codex-review、/fix等命令，照著你原本用 Claude Code 的習慣延伸。 - 可搭配 Codex CLI 與 PR bot，在 PR 上直接留下 AI 審查留言。
- 狀態存在檔案裡，方便在 CI 或本地反覆跑不同階段的檢查。
適合誰用
幾個具體場景：
- 有正式 PR 流程的後端/平台團隊
例如：用本地 LLM 或 Claude 幫你生成 service / handler，透過 adamsreview 做一輪「AI 審 PR」，再交給人類最後確認。
- 資深工程師很忙的小團隊
初階工程師用 AI 寫功能，先交給 adamsreview 初審，減少 reviewer 花時間抓基礎錯誤。
- 正在導入 AI coding，但怕品質失控的團隊
讓「AI 生成程式碼」必須經過「AI 多代理審查」，有規則可循，而不是全憑 reviewer 心情。
怎麼開始：最小安裝步驟
以下是一個「最短路徑」，讓你在現有 GitHub PR 流程中接上 adamsreview：
-
準備環境
-
需要：
- 有權使用 Claude Code 並可安裝插件（通常是付費方案）。
- 本機有
git+Node.js（或作者指定的執行環境）。
-
安裝與設定
在你的開發機或開發容器中：
bash
git clone https://github.com/adamjgmiller/adamsreview
cd adamsreview
# 若有提供安裝腳本
npm install # 或 pnpm/yarn
-
依照 repo README 設定環境變數（通常包含
Claude/CodexAPI key）。 -
在 Claude Code 中載入插件
-
打開 Claude Code（或支援的 IDE 插件）。
- 依 README 說明匯入 slash commands。
-
你會看到新增的命令，例如：
/review、/fix。 -
在 CI / PR 流程中接上（GitHub Actions 範例）
在 .github/workflows/pr-review.yml 增加一個簡化版 workflow：
“`yaml
name: AI PR Review
on:
pull_request:
types: [opened, synchronize]
jobs:
ai-review:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install adamsreview
run: |
git clone https://github.com/adamjgmiller/adamsreview
cd adamsreview && npm install
- name: Run adamsreview
env:
CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
run: |
cd adamsreview
# 依專案提供的 CLI 指令
npm run review -- ../
“`
這樣每次有人開 PR，就會自動觸發 AI 審查並在 PR 留言（實際指令依 repo 說明調整）。
二、React Doctor：專治 AI 產出的 React 小雷
它在 README 的第一句就是：「Your agent writes bad React. This catches it」。重點就是：AI 幫你產生的 React/TSX 常常「能跑，但不安心」。
核心功能
-
針對 React/TSX 的靜態檢測與修復
-
專門用來掃描 React 專案（
JSX/TSX），找到常見的壞味道與 bug。 - 例如：
- 在
useEffect中漏依賴 - 不必要的 re-render
- 不穩定的
key props型別不一致
- 在
-
部分問題可以自動產生修正
patch，直接套用。 -
和 AI 代理配合運作
它假設你已經在用 AI（Claude、ChatGPT、Cursor 等）生成元件或 hook：
- 先讓 AI 產出
code commit前跑React Doctor：快速找出「AI style 錯誤」-
必要時讓
React Doctor幫你修補。 -
TypeScript 友善
-
專案本身用 TypeScript 寫，也善用現有型別資訊。
- 如果你本來就用
TS + React，導入成本很低，直接把現有tsconfig、型別檔當基礎。
💡 關鍵： React Doctor 把「AI 寫得能跑」提升到「依 React/TS 最佳實務可維護」，特別適合大量由 AI 生成的 UI 程式碼。
適合誰用
幾個典型情境：
- 用 Claude/ChatGPT 幫你生 UI 元件
例如設計稿轉 React Component：
- AI 負責「寫得出來」。
-
React Doctor 負責「寫得對、好維護」。
-
React 新手 + AI 輔助開發
新手可能看不出 AI 產生的 code 有哪些壞習慣，React Doctor 可以當成「自動 code review 老師」。
- 已有大型 TypeScript + React 專案
部分模組開始用 AI 重構或新增功能，用 React Doctor 當 Safety Net，避免 AI 把舊 code 改壞。
怎麼開始：在 TS 專案快速啟用
假設你有一個現成的 React + TypeScript 專案：
- 安裝 React Doctor
專案目錄下：
bash
npm install react-doctor --save-dev
# 或
pnpm add -D react-doctor
- 新增設定檔（若有需要）
參考 repo 中的樣板（實際檔名跟範例以官方 README 為準）：
bash
npx react-doctor init
這通常會產生一個設定檔，例如 react-doctor.config.ts，你可以指定：
- 要掃描的資料夾（例如
src） -
要啟用的規則
-
在
package.json加上腳本
json
{
"scripts": {
"doctor": "react-doctor check src",
"doctor:fix": "react-doctor fix src"
}
}
-
在 Git hooks / CI 中啟用
-
透過
Husky或lint-staged，在pre-commit或pre-push跑：bash
npx react-doctor check src -
或在 GitHub Actions 加一個 job：
yaml
- name: React Doctor
run: npm run doctor
這樣每次有人把 AI 產的 React code 推上來，就會被 React Doctor 先掃過一次。
三、組裝一條「AI coding + AI code review/repair」工作流
最後用文字幫你拼成一個可以直接採用的流程，從「AI 寫 code」到「AI 審查 + 修正」：
-
開發階段：AI 寫程式
-
使用本地 LLM、Claude Code 或 ChatGPT：
- 讓 AI 產出後端
handler、service、React 元件。 - 人類工程師只負責寫 prompt + 調整架構。
- 讓 AI 產出後端
-
前端部分：React Doctor 抓小雷
-
每次 AI 生成或修改 React/TSX 檔案：
- 本地跑
npm run doctor檢查。 - 對於可自動修正的問題，跑
npm run doctor:fix。
- 本地跑
-
把這個步驟固定在：
pre-commithook- 或 VS Code Task /
npm script
-
提交 PR：adamsreview 做多階段 PR 審查
-
開 PR 後，GitHub Actions 觸發
adamsreview：- 階段 1：總覽差異，找出風險區域。
- 階段 2：針對測試、錯誤處理、安全性做專門檢查。
- 階段 3：產生具體修正建議或
patch。
-
PR 上自動留下 AI comment，方便 reviewer 快速聚焦真正問題。
-
人類最後把關
-
Reviewer 看：
- React Doctor 的報告（前端）
- adamsreview 的 PR 評論（後端/全端）
- 決定哪些建議要採用，哪些視情況忽略。
- 合併前至少確保：
- 所有必跑的 React Doctor / adamsreview 任務都綠燈。
💡 關鍵： 重點不是「全自動合併」，而是用 AI 把最耗時、最容易忽略的細節掃一遍，再由人類做最後決策。
這條工作流的重點不是「全自動」，而是：
- 把 AI 寫程式變成可控的流程，而不是隨意貼 paste code。
- 把最耗時、最容易忽略的細節（React 小雷、邊界條件、安全性）交給專門的 AI 工具來抓。
實作上，你可以先選一個小模組試行：
- 前端導入 React Doctor。
- 後端/全端導入 adamsreview。
- 兩週後檢查：PR 審查時間、有 bug 的 PR 比例是否下降，再決定要不要擴大到整個 repo。
用 AI 寫程式已經變成常態，下一步是在你的團隊裡，建立一套 「AI 寫 + AI 審 + 人類決策」的固定流程，讓速度與品質可以同時兼顧。
🚀 你現在可以做的事
- 打開 GitHub，分別把
adamsreview與React Doctorrepo 加到你的星標與閱讀清單- 在一個側專案或小模組上，先實驗接上
React Doctor的npm run doctor/doctor:fix腳本- 在現有 repo 新增一個簡單 GitHub Actions workflow，試跑一次
adamsreview的 AI PR 審查流程
發佈留言