標籤: Claude Code

本地 AI 代理寫程式，也要有 AI 幫你審 PR

📌 本文重點

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 心情。

怎麼開始：最小安裝步驟

原始專案：https://github.com/adamjgmiller/adamsreview

以下是一個「最短路徑」，讓你在現有 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/Codex API 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 小雷

官方 repo：https://github.com/millionco/react-doctor

它在 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 + 調整架構。
前端部分：React Doctor 抓小雷
每次 AI 生成或修改 React/TSX 檔案：
- 本地跑 npm run doctor 檢查。
- 對於可自動修正的問題，跑 npm run doctor:fix。
把這個步驟固定在：
- pre-commit hook
- 或 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 Doctor repo 加到你的星標與閱讀清單

在一個側專案或小模組上，先實驗接上 React Doctor 的 npm run doctor / doctor:fix 腳本

在現有 repo 新增一個簡單 GitHub Actions workflow，試跑一次 adamsreview 的 AI PR 審查流程

2026 年 5 月 12 日

Claude Code：把你的一人開發組變成小團隊
📌 本文重點
- Claude Code 扛「從 issue 到 PR」整條開發流程
- 百萬 token 上下文，能做跨檔案大規模重構
- 與 issue 管理工具整合，連動任務與代碼
- 把它當工作流 Agent，而不是單純寫程式助手
Claude Code 要解決的問題很單純：不要只幫你「寫幾行程式」，而是幫你「從 issue 到 PR 到 release note」整條開發流程一起扛掉。

Claude Code 官方頁面｜參考閱讀：Claude Code Isn’t a Coding Tool. It’s Your Team’s New Workflow Engine.

核心功能：不只是會寫程式的 Chatbot

1. 百萬上下文 + 跨檔案重構

Claude Code 的關鍵不是「會寫程式」，而是一次看得懂整個專案：

💡 關鍵： 百萬 token 上下文讓 Claude Code 能一次理解整個大型 repo，支援跨模組重構與設計級別調整。
- 支援百萬 token 上下文，實務上可以：
- 一次讀完整個 monorepo 的關鍵目錄
- 同時理解前後端、infra、文件
- 實際能做的事：
- 統一命名規則、API 介面：
  - 指令範例：
    
    「請在整個 apps/web 和 packages/api 裡，把 user profile 統一改成 UserProfile 類型，並更新相關型別定義與呼叫點。」
- 大規模重構：改 routing、auth、logging 邏輯，而不是只改單一檔案
行動建議：
– 第一次用時，直接把「專案關鍵資料夾」拖進 Claude Code，請它輸出：
– 架構圖
– 主要模組關聯
– 技術債/風險清單

2. 代碼審查 + 任務追蹤

Claude Code 把「code reviewer + 小 PM」包在一起用：
- 代碼審查：
- 貼 PR diff 或讓它自己產生 patch，請它從幾個角度審查：
  - 可讀性
  - 安全性
  - 可測試性
- 指令範例：
  > 「這個 PR 幫我做 code review，重點看：1) SQL 注入風險 2) log 裡有沒有可能洩漏個資。」
- 任務追蹤：
- 你丟一串 TODO、散落在註解、issue 裡，它可以：
  - 幫你整理成任務列表
  - 按複雜度排序
  - 標註依賴關係
行動建議：
– 把你專案裡的 // TODO 集中給 Claude Code，看它幫你：
– 分成「1 小時內可完成」「需要討論設計」兩類
– 生成對應 Issue 描述（等下一小節接管理工具）

3. 與 Linear / Jira 等管理工具整合

重點不是「Claude Code 會寫 issue」，而是它能 自己對應任務 ↔ 代碼：
- 典型流程：
- 從 Linear / Jira 拉某個 issue 描述
- Claude Code：
  - 解析需求
  - 找出相關檔案
  - 建議實作方案
  - 產生 patch / commit 訊息
- 回寫到對應 issue（附 PR link、測試說明）
- 這讓你可以用一句話驅動整個流程：
- 「幫我處理 Linear 上 FE-1234 這張 ticket，照 acceptance criteria 寫完測試再開 PR。」
行動建議：
– 把團隊目前的 issue 模板、PR 模板貼給 Claude Code，請它：
– 照樣學習格式
– 以後所有「產生 PR 描述 / 測試計畫」都統一風格

適合誰用？三種典型場景

1. 單人開發者：讓 Claude Code 當你的 PM + Reviewer

你一個人接案或做 side project，沒人幫你看架構、沒人幫你 review。Claude Code 可以扮演：
- 專案 PM：
- 幫你把「腦中需求」變成 roadmap：
  - 「這個月要完成：會員系統 v1、簡單報表」
- 轉成 task list：db schema、API、UI、測試
- code reviewer：
- 每次 commit 前，請它檢查：
  - 功能風險
  - 重複邏輯
  - 可抽共用函式的地方
具體做法：
– 建立一個持續使用的 Claude Code 專案，放：
– README、需求文件、todo list
– 一份「我寫程式的偏好」（語言、框架、lint 風格）
– 每天開工前一句：

「根據目前 repo 與 TODO，幫我排今天 3 個最值得做的 task，控制在 3 小時內。」

2. 小團隊：讓它維護 issue、測試、技術文件

對 3–10 人團隊，Claude Code 好用在「把大家都懶得做的事」接走：

💡 關鍵： 對 3–10 人的小團隊，把 issue 清理、測試補齊與文件生成交給 Claude Code，可顯著減少非核心開發時間。
- Issue 維護：
- 每週讓 Claude Code：
  - 清理過期 / 重複 issue
  - 把描述不清的 issue 重新改寫
- 測試補齊：
- 對於已存在的功能程式碼：
  - 要求它列出「目前缺哪些層級的測試」
  - 自動產生 test skeleton（unit / integration）
- 技術文件：
- 從 commit / PR 摘要產出：
  - 變更日誌
  - ADR（Architecture Decision Record）草稿
具體做法：
– 選一個模組先試點，例如「會員系統」：
1. 把現有 PR、issue 歷史餵給 Claude Code
2. 要它輸出一份「會員系統說明文件 v0」
3. 團隊一起 review，修改後當作標準模板

3. 大批量重構 / 遷移專案：讓它拆成可執行任務

當你在做：
– 從 JS → TS
– 從 REST → GraphQL / gRPC
– 從單體 → 模組化

這時 Claude Code 的長上下文 + 任務拆解很實用：
- 一次吃下：
- 主要模組目錄
- 現有測試
- 部署設定
- 輸出：
- 分階段遷移計畫
- 每階段具體改哪些檔、會壞掉什麼
具體做法：
– 問 Claude Code：

「假設我要在 4 週內把 services/auth 從 JS 遷移到 TS，請在不影響現在線上環境的前提下，拆成 4 週計畫，每週列出可以單獨合併的 PR 列表。」

怎麼開始：從註冊到跑完一條完整 workflow

步驟 1：註冊與開啟 Claude Code
1. 到 claude.ai 註冊帳號（可用 Google / Email）。
2. 登入後，點右上角 Code 進入 Claude Code 介面。
3. 建議準備：
4. GitHub repo 連結
5. 專案 README、需求文件
步驟 2：連接 GitHub / 專案庫

目前常見兩種用法：
- 直接拖拉檔案夾：
- 小專案、side project 最快
- 接 GitHub：
- 依照介面授權，把指定 repo 掛上去
- 在對話裡直接叫它打開某個檔案路徑，再請它操作
行動建議：
– 先選一個風險較低的 repo（side project 或工具庫）當實驗場，不要一開始就丟公司核心系統。

步驟 3：示範一條具體 workflow

以「從 TODO issue → 產生 PR → 自動寫 release note」為例：
1. 整理 TODO
  在 Claude Code 裡貼上：
2. 一個 Linear / Jira issue 內容，或
3. 散落在程式裡的 TODO 註解
請它：

「幫我把這些 TODO 整理成一個明確的 issue 描述，列出 acceptance criteria。」
1. 讓它實作並產生 PR
  接著說：
  
  「根據這個 issue，在目前 repo 裡完成實作，請：1）列出要改的檔案 2）給我完整 patch 3）附上測試建議。」
你可以：
– 先人工 review patch
– 把 patch 套進本地分支
– 提交 GitHub PR
1. 自動寫 release note
  PR 開好後，把：
2. PR diff / 連結
3. 關聯 issue 連結
貼給 Claude Code，指令：

「幫我寫一段 release note，給非工程同事看的，限制 150 字內，列出 2-3 個 bullet point。」

若你有一份既有 release note 模板，也一起貼上，請它照模板格式輸出。

做完一次，你就有一條可重複的最小 workflow，之後只要換 issue 就能重跑。

進階玩法：把 Claude Code 變成「小開發團隊」的一員

1. 和輕量模型分工，省錢跑批量任務

很多工作不需要 Claude 這種大模型，例如：
– 大量 JSON 重新排版
– 批次分類檔案
– 從文字裡抽欄位

參考這篇 Reddit 實作：Most of my Claude usage was on work that didn’t need Claude

做法：
– 另外架一個便宜的小模型 API（例如 DeepSeek V4 Flash）
– 在 Claude Code 這邊只放一個規則：
– 「遇到格式轉換、摘要這種機械工作，一律呼叫那個外部工具，不要自己算」

💡 關鍵： 把機械式任務交給便宜模型，可將大量批次任務成本壓到原本的約 1/10。

效果：
– 大量批次任務成本可壓到原本的 1/10 甚至更低

2. 搭配 Relay 這類插件，讓多個 Claude Code 會話互通

如果你常同時開：
– 一個 session 管 backend
– 一個 session 管 frontend
– 另一個管 infra / CI

可以照這篇的做法：built a plugin so my parallel Claude Code sessions can message each other

概念是：
– 用像 Relay 這種小工具，讓不同 Claude Code 視窗可以互相發訊息
– 例如：
– 前端 session 問：「User object 現在長怎樣？」
– 後端 session 直接回，結果推回前端視窗顯示

實際好處：
– 你不用在多個對話間複製貼上
– 等於有好幾個專職「子工程師」在各自 repo 幫你跑任務，互相同步狀態

小結：把 Claude Code 視為「工作流 Agent」，不是「更聰明的 Copilot」

使用 Claude Code 的關鍵心態是：
– 不要只問「幫我寫這個 function」
– 要改成「幫我把這個 issue 從需求 → 設計 → 實作 → 測試 → 文件，一次帶完」

先從一條最小 workflow 開始做起（例如本文的 TODO → PR → release note），再逐步接上 issue 管理、測試、自動文件，Claude Code 才會真正變成你開發流程的一部分，而不是多一個可以聊天的 IDE 工具。
🚀 你現在可以做的事
- 選一個風險低的 repo，丟進 Claude Code，請它產出架構圖與技術債清單
- 把現有的 issue / PR 模板貼給 Claude Code，讓它學會之後統一產生描述與測試計畫
- 實做一次「TODO → issue → PR → release note」完整 workflow，確認能在團隊內重複使用
2026 年 5 月 5 日
用 HyperResearch 把 Claude 變身研究員
📌 本文重點
- HyperResearch 把 Claude Code 變成可複製的研究流程
- 內建搜尋、查證、對抗審閱，降低 AI 瞎掰風險
- 每次研究都累積成可搜尋知識庫，方便長期追蹤
只要安裝一個開源專案 HyperResearch，就能把原本偏「寫程式」取向的 Claude Code，變成會自動幫你查資料、查證、寫報告的「可複製研究流程」。

專案連結：原作者 Reddit 介紹帖（含 GitHub 連結）：https://www.reddit.com/r/ClaudeAI/comments/1sz9ib0/converting_claude_code_into_the_most_intelligent/

HyperResearch 是什麼？一句話定位

HyperResearch 是一個基於 Claude Code 的開源研究 Agent 框架：
- 內建 16 步驟研究管線（搜尋 → 篩選 → 結構化 → 查證 → 對抗審閱 → 整理報告）
- 每一次對話都會 累積成可搜尋的知識庫，方便長期追蹤同一個主題
- 直接吃你現有的 Claude Code 訂閱 / API Key，不用再另外付費給其他研究 Agent
💡 關鍵： 透過 16 步驟固定流程與知識庫累積，HyperResearch 把一次性聊天升級成可重複、可追蹤的研究管線。

如果你曾經遇過：
- 叫 ChatGPT / Claude 查資料，結果：
- 一次性回答，看完就散了
- 沒有完整引用來源，很難信任
- 隔天再問，同一主題要從頭講起
HyperResearch 的核心價值，就是把「隨機聊天」變成一條 可重複、可追蹤、可查證的研究流水線。

核心功能：把研究拆成可以信任的步驟

1. 自動搜尋與整理：幫你做完「初篩 + 結構化」

HyperResearch 不是只給一段總結，而是走完一套預先設計好的研究流程（約 16 個步驟，細節實作在專案程式裡）：
- 自動搜尋：針對你的問題，拆成多個子題目，上網搜尋相關資料
- 初步過濾：排除明顯垃圾來源（內容農場、廣告頁）
- 結構化整理：把找到的內容轉成具體欄位，例如「來源、主張、數據、時間、可信度」
你可以怎麼用？
- 把原本「自己 Google 30 分鐘」的事情，改成：
- 對 HyperResearch 下指令：
  - 「請幫我整理 2024 之後出現的主要開源 LLM 架構，列出模型名稱、上下文長度、授權條款與 GitHub 連結。」
- 等它產出第一輪整理，再人工挑選你想深挖的部分
這讓你把時間從「掃網頁」轉到「判斷這些資訊要怎麼用」。

2. 內建事實查核與對抗審閱：降低瞎掰風險

HyperResearch 的流程裡，有兩個關鍵設計：
1. 事實查核（fact-checking）：
2. 重新比對模型產出的主張與原始來源內容
3. 對可能有爭議的數據，主動再搜尋次要來源交叉比對
4. 對抗性審閱（adversarial review）：
5. 讓另一個「挑錯模式」的 agent 嘗試反駁論點
6. 尋找忽略的反例、反向證據
實際操作上，你可以：
- 要求它：
- 「列出你這份報告中，最可能錯的三個地方，並附上你重新查證後的來源連結。」
- 把這段對抗性審閱，當成你自己 review 報告的 checklist
這對 投資決策、技術選型、競品分析 特別重要：你不只看到「一個漂亮的結論」，還能快速看到「這結論可能哪裡有問題」。

💡 關鍵： 透過事實查核與對抗審閱設計，HyperResearch 迫使模型主動暴露不確定性，讓你更容易信任或質疑結論。

3. 持久知識庫：一次研究，長期可用

HyperResearch 每一輪研究，都會把：
- 主題與子問題
- 整理後的來源資料
- 中間推理過程（為什麼舍棄某些證據）
- 最後的結論與報告
存進一個 可搜尋、可持久化的知識庫（具體實作依專案版本而定，通常以檔案 / 資料庫形式存在）。

實際用途：
- 之後你可以問：
- 「幫我回顧上次那份關於『開源 LLM 商業模式』的研究，更新 2025 Q1 之後的新變化。」
- 「從我過去所有 LLM 相關研究裡，整理一份『開源模型商業化常見風險』的清單。」
也就是說，HyperResearch 不是只做「一次性報告」，而是在幫你累積一個 主題型研究檔案庫，越用越值錢。

適合誰用？三種典型場景

1. 工程師：調研新 LLM 技術與工具

典型任務：

「幫我整理 2024 之後主流的推理引擎（如 vLLM、SGLang 等），比較它們在吞吐量、部署難度、社群活躍度上的差異，附 GitHub 連結與基準測試來源。」

實際好處：
- 幫你粗篩一輪技術選項
- 先列出「值得 Prototype 的 2–3 個方案」，再自己動手測
💡 關鍵： 把原本要自己比對多個技術方案的工作，收斂成 2–3 個最值得實測的選項，大幅節省試錯時間。

可以馬上做：
- 把你目前在考慮的幾個 LLM 技術（伺服架構、量化工具、Serving 框架）列成清單，丟給 HyperResearch 做第一輪比較，再根據結果決定 Week-end 要測什麼。
2. 個人投資者：公司 / 產業研究

典型任務：

「針對 NVIDIA、AMD、Intel，整理 2023 Q4 之後在 AI 加速卡市場的策略差異：產品線、定價、主要客戶、近期財報重點與風險因子，所有數據需附來源連結。」

好處：
- 幫你先把公開資訊「拉平、對齊格式」
- 你只需要專心在：這些資訊對你的投資策略代表什麼
可以馬上做：
- 選一檔你持有的股票，讓 HyperResearch 幫你產出一份「最近 6 個月的事件與風險總整理」，當成你之後加減碼時的參考底稿。
3. PM / 創業者：競品與市場分析

典型任務：

「請整理三家主打企業級 LLM Agent 平台的公司（例如 OpenAI workspace agents、Google Deep Research Max、其他新創），比較功能、價位、目標客戶與商業模式，並說明各自的優勢與可能風險。」

好處：
- 省掉反覆搜尋官網、看部落格、抄價格表的時間
- 快速得到可放進 Pitch Deck / 產品規劃的「競品對照表」
可以馬上做：
- 把你正在做的產品，交代給 HyperResearch：
- 「我在做 X（簡述產品與客群），請幫我找三個最接近的國外競品，整理功能矩陣與收費方式。」
怎麼開始：從安裝到跑出第一份研究

注意：以下為通用步驟說明，實際指令與設定請以 GitHub 專案 README 為準。

1. 取得原始碼（本地 or 雲端）
1. 前往作者貼文中的 GitHub 連結：https://www.reddit.com/r/ClaudeAI/comments/1sz9ib0/converting_claude_code_into_the_most_intelligent/
2. 在 GitHub 頁面：
3. 若要本地跑：
  - git clone <repo-url>
  - 進入目錄後，確認是否提供 Docker / Python 安裝腳本
4. 若要雲端：
  - 看 README 是否提供一鍵部署到 Render / Railway / Fly.io or 自架 VPS 的教學
行動建議：
- 若你是工程師，建議：本地 Docker 安裝，方便自訂與看程式碼
- 若你只想快速用：選擇作者提供的雲端部署方案（如果有），照步驟填環境變數即可
2. 接上自己的 Claude Code Key

HyperResearch 是「Claude Code skill harness」，也就是：
- 你需要準備：
- Claude Code 相關 API Key 或 Workspace Token（依專案說明）
- 在專案中通常會有一個 .env.example 或設定檔，流程大致如下：
- 複製一份：cp .env.example .env
- 填入：
  - ANTHROPIC_API_KEY=你的金鑰
  - 其他像 MODEL_NAME、BASE_URL 依你實際使用方案調整
行動建議：
- 進入 Claude 帳號後台，確認你有權限呼叫對應的 Claude Code 模型（例如具瀏覽 / tool use 能力的版本），再來啟動 HyperResearch。
3. 用實用提示詞啟動第一輪研究

啟動服務後（通常是 Web UI 或 CLI），你可以直接丟以下幾個模板：

模板 1：技術調研

「你是一位資深 LLM 工程師，使用 HyperResearch 的完整研究流程來回答。請針對『{主題}』進行調研，至少涵蓋：
1. 目前主要方案與代表專案
2. 各方案的優缺點與適用場景
3. 開源程度 / 授權條款
4. 實務部署時常見的坑與最佳實務
全程需自動搜尋最新資料，列出來源網址，並在最後列出你認為仍待驗證的部分。」

模板 2：產業 / 公司研究

「你是一位基本面導向的研究員。請用 HyperResearch 的 16 步驟研究管線，完整調查『{公司或產業}』：
– 商業模式與主要產品
– 收入結構與成長動能
– 核心競爭優勢與風險
– 最近 12 個月的重要事件
所有關鍵數據需附來源連結與時間，對重要但證據不足的結論請標記為『需進一步查證』。」

模板 3：競品分析

「你是一位 B2B SaaS 產品經理。請為『{產品類型}』找出 3–5 個國內外競品，並產出一份競品分析表，至少包含：
– 功能列表與差異
– 收費模式與價格區間
– 目標客戶與市場定位
– 優勢與明顯短板
請使用 HyperResearch 的對抗性審閱步驟，刻意找出你對每家競品認知可能有誤的地方，並附上重新查證的來源。」

4. 一晚就能完成的實戰任務（建議你現在就試）

任務：

「請幫我整理三家 LLM 公司的商業模式優劣，附來源連結。至少涵蓋：OpenAI、Anthropic、Google（Gemini）。說明它們的核心產品線、收費方式、目標客戶，以及各自的風險與機會。請使用完整的 HyperResearch 流程，並在最後給出一份表格總結與你的信心評估。」

操作方式：
1. 把上面整段貼進 HyperResearch
2. 等它跑完後：
3. 先看引用來源是不是你信任的媒體 / 官方文件
4. 再看對抗性審閱段落，確認它有沒有誠實暴露不確定處
5. 最後，把報告中你最在意的 2–3 個主張，自己再 Google 一次，感受一下：這條研究流水線幫你省下多少時間。
當你跑完這個任務，其實就等於：
- 搭起了自己的「AI 研究部門」
- 有了一套可複製的研究流程：之後換主題、丟新問題就能重複使用
你不需要再從「怎麼問 AI」開始煩惱，只要專心想：

下一個值得丟給 HyperResearch 深挖的問題，是什麼？
🚀 你現在可以做的事
- 前往 Reddit 貼文找到 GitHub 專案，閱讀 README 並決定要本地或雲端部署 HyperResearch
- 準備好自己的 ANTHROPIC_API_KEY，依照專案說明完成 .env 設定並啟動服務
- 選一個你近期最在意的技術或產業問題，把文中的研究提示詞貼進 HyperResearch，跑出第一份完整報告
2026 年 4 月 30 日
用 Claude Code routines 把修 Bug 和審 PR 自動化
📌 本文重點
- 用程式碼定義 routine，讓 Claude 自動跑開發流程
- 支援排程、API、GitHub webhook 等多種觸發方式
- 適合 CI、PR 初審、重構、錯誤偵測等自動化場景
- 建議先從「只讀建議」開始，逐步放權到自動修正
一句話先說清楚：Claude Code routines 就是「用程式碼把 Claude 變成你的自動化開發助理」，幫你在雲端自動跑修 Bug、審 PR、開 issue 等重複工作。

官方文件：https://code.claude.com/docs/en/routines

核心功能：用程式碼定義多步驟任務

routines 的概念很簡單：你先用程式碼把「要怎麼用 Claude 做事」寫成一個流程，之後就讓它自動在雲端重複跑。

典型一個 routine 可以長這樣：
1. 拉特定 repo（支援 GitHub 等連接器）
2. 用 Claude 分析程式碼變更或錯誤
3. 修改程式碼、產生 patch 或直接開 PR
4. 把結果回報到 GitHub、Slack 或你的 CI 系統
根據官方說明和社群分享（Reddit）：
- ✅ 多步驟流程可程式化：你不是丟一句 prompt 就結束，而是用程式碼描述整個 pipeline，例如：
ts // 偽程式碼示意：定義一個 routine const routine = defineRoutine({ name: 'lint-and-suggest', repo: 'github://my-org/my-repo', steps: [ cloneRepo(), runESLint(), askClaudeForFixes(), commentOnPullRequest(), ], })
- ✅ 三種觸發方式（都在雲端跑，電腦可關機）：
- 固定排程：例如每天凌晨跑一次重構建議
- API 呼叫：每個 routine 會有一個 endpoint，你可以從自家服務打 API 觸發
- GitHub webhook：例如「新 PR 建立時就讓 routine 自動跑審查」
💡 關鍵： routines 把「一次性的 prompt」變成「可重複觸發的程式化流程」，而且全部在雲端執行，不綁你的電腦在線。

你可以馬上做的事：
- 想一個你最常重複做的開發流程（例如「每次 PR 都要跑 lint + 給建議」），把它拆成 3–5 個步驟，列成清單，等等在「怎麼開始」直接照這份清單寫成 routine。
適合誰用：4 個典型場景

1. CI 流程自動跑靜態分析 + 修正建議

場景：你現在的 CI 只會跑 lint / type check，但錯誤一堆，只丟紅燈不給解法。

用 routines 可以：
- 在 CI 裡呼叫一個 API routine
- routine 拉 PR 的 diff，跑 ESLint / mypy 等工具
- 把錯誤丟給 Claude，讓它：
- 用自然語言解釋錯誤來源
- 產生建議修正（甚至 patch）
- 把結果直接貼回 PR comment
可執行動作：
- 選一個語言（例如 TypeScript），從你現有 CI 裡加一個步驟：呼叫 routines API，把 PR 編號、branch、diff 傳給它，讓 routines 回傳「修正建議文字」或「patch 檔」。
2. PR 自動初審：先讓 AI 篩一輪

場景：團隊 PR 多，但 Reviewer 不想浪費時間在命名、註解、重複邏輯這種「低階問題」。

routine 可以幫你：
- 透過 GitHub webhook，在 PR 開啟時觸發
- 讀取 diff + 相關檔案
- 按你定義的規則檢查：
- 是否有測試
- 是否破壞既有 API
- 命名 / 註解 / logging 是否符合約定
- 自動在 PR 下面留一串初步 review comment
可執行動作：
- 先在文件裡列出你希望「PR 初審」檢查的 checklist（3–7 項就好），之後在 routine 的 prompt 中直接貼入這份 checklist，讓 AI 依此審查。
3. 例行重構 / 格式化：排程交給 AI 擬方案

場景：技術債知道很多，但沒空系統性整理。

排程 routine 可以：
- 每週固定拉主分支
- 掃特定目錄（例如 /legacy/**）
- 讓 Claude：
- 找出重複程式碼、過長 function、潛在性能瓶頸
- 產出「重構提案」文件，列出建議與風險
- 適度產生小 patch（例如只做格式、抽小 function）
可執行動作：
- 挑一個最頭痛的模組，設定一個每週 routine，讓 AI 每週只做一件事：產出一份 markdown 報告 docs/refactor-suggestions.md，你每週開會時直接打開看。
4. Crash 時自動開 issue + 初步定位

場景：線上服務 crash，Log 一堆，沒人第一時間看。

你可以：
- 在監控系統（如 Datadog、Sentry、自家 APM）裡，當發生特定錯誤時，呼叫 routines API
- routine 取得：錯誤訊息、stack trace、關聯 log
- 讓 Claude：
- 用固定模版在 GitHub / Jira 開 issue
- 附上「可能原因、優先查看檔案、建議排查步驟」
可執行動作：
- 把你目前手動開 issue 的模版貼出來，照樣套到 routine：把欄位（背景、重現步驟、log、可能原因）寫進 prompt，讓 AI 自動填。
進階玩法：多代理 + DevOps 工具鏈串接

多代理平行工作：一個負責測試、一個負責安全

Anthropic 在桌面版 Claude Code 已經支援多代理平行工作（Reddit 範例），在 routines 概念上，你可以照抄這個思路：
- routine A：專門寫測試
- 拉 PR diff
- 找出新增 / 修改的 function
- 為這些 function 產測試檔 / 測試 case
- routine B：專門做安全檢查
- 用「安全檢查 prompt」掃過相同 diff
- 找 SQL injection、硬編 API key、不安全的反序列化等
你在 CI / webhook 流程裡：
- 對同一個 PR 同時觸發 routine A 和 B
- 兩邊結果都留言回 PR，Reviewer 一次看完
可執行動作：
- 先從「拆成兩個 routine」開始：複製一份 PR 初審 routine，一份改成只談測試、一份改成只談安全。兩個端點都掛在同一個 GitHub webhook 上平行觸發。
💡 關鍵： 把不同責任拆成多個 routine 平行跑，比讓一個超大 prompt 包山包海更穩定、也更好維護。

和 GitHub Actions / 自家 CI 組合

根據官方說明，每個 routine 都有自己的 API endpoint，你可以：
- 在 GitHub Actions 新增一個 step：
yaml - name: Call Claude routine run: | curl -X POST "$ROUTINE_ENDPOINT" \ -H "Authorization: Bearer $ROUTINE_TOKEN" \ -H "Content-Type: application/json" \ -d '{"pr_number": "${{ github.event.pull_request.number }}"}'
- 在自家 CI（GitLab CI、Jenkins 等）同樣用 curl / http client 呼叫
可執行動作：
- 挑一個已存在、每次都必跑的 workflow（例如 ci.yml 中的 lint job），在最後加上一個 step 呼叫 routines，把 log 或 diff 丟給它，先從「只產出建議、不寫檔」開始。
怎麼開始：從一個「最小可用」 routine 起步

1. 在哪裡開啟 Claude Code routines？

前提：需要 Claude 付費帳號（根據官方公告）。

步驟概念（介面可能會隨時間微調）：
1. 登入 https://code.claude.com
2. 在側邊欄找到 Routines 或類似入口
3. 點 Create routine 或 New routine
4. 選擇：
5. 要連接的 repo（GitHub / 本地鏡像等）
6. 要用的 connector（例如 Slack、GitHub）
7. routine 的觸發方式（排程 / API / GitHub webhook）
可執行動作：
- 現在就登入 Claude Code，看你的帳號是否已開 routines，確認你公司 repo 是否能被安全地接入（先選一個 side project 測試）。
2. 寫一個「最小可用」 lint & 建議 routine

目標：對指定 repo 做 lint，請 Claude 用自然語言給建議，不動任何程式碼。

流程示意（概念層級）：
1. 新建 routine：ts-lint-advisor
2. 設定：
3. Repo：github://your-org/your-repo
4. 觸發：API（先手動呼叫）
5. 在 routine 腳本中：
6. Step 1：git clone 對應 branch
7. Step 2：跑 pnpm lint 或 npm run lint，把輸出存成文字
8. Step 3：呼叫 Claude，把 lint log + 相關檔案片段丟給它，prompt 約略：
  
  你是一位 TypeScript 專案維護者。根據以下 ESLint 輸出，請：
  1. 依錯誤類型分組
  2. 解釋造成這些錯誤的程式風格 / 設計問題
  3. 提出 3–5 條優先修正建議（包含具體檔案與規則）
9. 回傳結果：只輸出 markdown 報告，不修改 repo
可執行動作：
- 先做一版「只讀不寫」的 lint 報告 routine，確定你喜歡它的輸出風格，再考慮讓 routine 產 patch 或自動發 PR。
💡 關鍵： 先用「只讀報告」驗證 routine 的品質與風格，比直接讓它改碼、開 PR 安全得多。

3. 設定 GitHub webhook：新 PR 自動觸發

當你有一個穩定的 PR 初審 routine 之後，可以這樣接 GitHub：
1. 在 routines 介面確認此 routine 的 API endpoint
2. 到 GitHub 專案 Settings → Webhooks：
3. Payload URL：貼上 routines endpoint
4. Content type：application/json
5. Which events：勾選「Pull requests」
6. 在 routine 的程式裡解析 GitHub webhook payload：
7. 取得 pull_request.number、head.ref、base.ref
8. 用這些資訊去抓 diff + 檔案內容
可執行動作：
- 先對「一個測試 repo」開 webhook，不要直接上 production monorepo；等確認 routine 不會亂刷 comment、沒權限問題，再複製設定到正式專案。
風險提示與 Best Practices

1. 權限控制：不要讓 Agent 直接推到 main

routines 能改程式碼，也能開 PR。建議：
- 對 routines 用的 GitHub Token：
- 禁止直接 push 到 main / master
- 只給「開 PR」和「留言」的權限
- 在 Org Policy 中明定：AI 開的 PR 一律需要人審核才能合併
可執行動作：
- 立刻確認你準備給 routines 用的 GitHub PAT / App 權限，把 push to protected branches 關掉。
2. 改動記錄與審計：每一個 AI 動作都要有跡可循

為了避免「不知道是哪個 routine 改了什麼」：
- 統一規範 AI 開 PR 的 branch 命名，例如：ai/routine-name/feature-x。
- PR 描述固定包含：
- 使用的 routine 名稱 & version
- 執行時間、輸入參數（例如針對哪個 issue / PR）
- 可以在 routine 程式裡主動把自己的輸出寫入一個 log 檔或 S3 / DB，供日後查詢。
可執行動作：
- 寫一個簡單規範：所有 routines 在 PR 描述最上方都要加一段固定訊息，例如：[Generated by routine: pr-initial-review v0.3]，方便日後搜尋、回溯。
3. 慢慢放權：先從「建議」再到「自動修改」

導入策略可以分三層：
1. 只讀模式：只產報告 / 建議，不動任何檔案
2. Patch 模式：產生 patch 檔、開 PR，但不自動合併
3. 半自動修正：對低風險項目（格式化、註解）允許自動合併，高風險項目仍需人工
可執行動作：
- 先列出「允許 AI 自動處理」與「必須人工審核」的改動類型（例如：格式化、註解 vs. 核心業務邏輯、資料庫 schema），在 routine 的 prompt 裡明寫清楚。
小結：從一個 routine 開始，把最煩的事交給 Claude

你可以把 Claude Code routines 當成「可編程的 AI Bot 平台」：
- 把你每天重複做的開發流程拆成步驟
- 用程式碼和 prompt 變成 routine
- 用排程、API 或 GitHub webhook 觸發
最實際的下一步：
1. 選一個最討厭但規則清楚的工作（例如 PR 初步檢查命名和註解）。
2. 在 Claude Code 裡建一個 routine，先只產出文字建議。
3. 跑一週，觀察輸出品質，再決定要不要進一步讓它產 patch、開 PR。
從一個小 routine 開始，你就能感受到「用程式碼把 Claude 變成你的自動化開發助理」的威力。
🚀 你現在可以做的事
- 打開一個 side project repo，列出 3–5 步驟的「最煩例行工作」，照文中流程設計第一個 routine
- 在 CI 或 GitHub Actions 中加上一個「只讀建議」的 routines 呼叫 step，觀察一週效果
- 為 routines 設計權限與審計規範（Token 權限、branch 命名、PR 描述格式），再逐步放權到 patch / 開 PR
2026 年 4 月 15 日

標籤: Claude Code

本地 AI 代理寫程式，也要有 AI 幫你審 PR

核心功能：兩個工具，一條龍

工具總覽

一、adamsreview：多代理分工的嚴謹 PR 審查

核心功能

適合誰用

怎麼開始：最小安裝步驟

二、React Doctor：專治 AI 產出的 React 小雷

核心功能

適合誰用

怎麼開始：在 TS 專案快速啟用

三、組裝一條「AI coding + AI code review/repair」工作流

Claude Code：把你的一人開發組變成小團隊

核心功能：不只是會寫程式的 Chatbot

1. 百萬上下文 + 跨檔案重構

2. 代碼審查 + 任務追蹤

3. 與 Linear / Jira 等管理工具整合

適合誰用？三種典型場景

1. 單人開發者：讓 Claude Code 當你的 PM + Reviewer

2. 小團隊：讓它維護 issue、測試、技術文件

3. 大批量重構 / 遷移專案：讓它拆成可執行任務

怎麼開始：從註冊到跑完一條完整 workflow

步驟 1：註冊與開啟 Claude Code

步驟 2：連接 GitHub / 專案庫

步驟 3：示範一條具體 workflow

進階玩法：把 Claude Code 變成「小開發團隊」的一員

1. 和輕量模型分工，省錢跑批量任務

2. 搭配 Relay 這類插件，讓多個 Claude Code 會話互通

小結：把 Claude Code 視為「工作流 Agent」，不是「更聰明的 Copilot」

用 HyperResearch 把 Claude 變身研究員

HyperResearch 是什麼？一句話定位

核心功能：把研究拆成可以信任的步驟

1. 自動搜尋與整理：幫你做完「初篩 + 結構化」

2. 內建事實查核與對抗審閱：降低瞎掰風險

3. 持久知識庫：一次研究，長期可用

適合誰用？三種典型場景

1. 工程師：調研新 LLM 技術與工具

2. 個人投資者：公司 / 產業研究

3. PM / 創業者：競品與市場分析

怎麼開始：從安裝到跑出第一份研究

1. 取得原始碼（本地 or 雲端）

2. 接上自己的 Claude Code Key

3. 用實用提示詞啟動第一輪研究

4. 一晚就能完成的實戰任務（建議你現在就試）

用 Claude Code routines 把修 Bug 和審 PR 自動化

核心功能：用程式碼定義多步驟任務

適合誰用：4 個典型場景

1. CI 流程自動跑靜態分析 + 修正建議

2. PR 自動初審：先讓 AI 篩一輪

3. 例行重構 / 格式化：排程交給 AI 擬方案

4. Crash 時自動開 issue + 初步定位

進階玩法：多代理 + DevOps 工具鏈串接

多代理平行工作：一個負責測試、一個負責安全

和 GitHub Actions / 自家 CI 組合

怎麼開始：從一個「最小可用」 routine 起步

1. 在哪裡開啟 Claude Code routines？

2. 寫一個「最小可用」 lint & 建議 routine

3. 設定 GitHub webhook：新 PR 自動觸發

風險提示與 Best Practices

1. 權限控制：不要讓 Agent 直接推到 main

2. 改動記錄與審計：每一個 AI 動作都要有跡可循

3. 慢慢放權：先從「建議」再到「自動修改」

小結：從一個 routine 開始，把最煩的事交給 Claude