標籤: Claude Code

  • 用 HyperResearch 把 Claude 變身研究員

    用 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,跑出第一份完整報告
  • 用 Claude Code routines 把修 Bug 和審 PR 自動化

    用 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