標籤: 工作流自動化

  • 用 Claude Corps 組一支虛擬專案團隊

    用 Claude Corps 組一支虛擬專案團隊

    📌 本文重點

    • Claude Corps 把單一 Claude 變成多角色協作團隊
    • 透過 rubric 審稿 Agent,大幅提升輸出品質
    • 先從「主 Agent + 審稿 Agent」的小流程開始實驗

    一句話定位:Claude Corps 就是「多代理版 Claude 工作流引擎」——讓多個 AI 角色分工協作、互相審查,幫你跑完整個專案流程,而不只是回一個答案。

    👉 官方介紹文:https://www.anthropic.com/news/claude-corps
    👉 rubric grading 實驗文:https://pub.towardsai.net/i-added-one-agent-to-my-claude-setup-and-output-quality-jumped-10-overnight-6e5947a62141


    核心功能:把「一個 Claude」變成「一個團隊」

    1. 多角色分工:策略 / 執行 / 審查

    Claude Corps 的核心概念是:你先設計好幾個固定角色,然後讓他們一起跑流程,而不是一個大 prompt 想包山包海。

    常見三種角色:

    • 策略 Agent(Strategist):負責想方向、列計畫、拆步驟。
    • 執行 Agent(Executor):根據計畫產出具體內容(文案、規格、程式碼)。
    • 審查 Agent(Reviewer):按照事先定好的 rubric(評分標準)檢查、打分、要求重寫。

    你可以從自己現有流程開始,照這三個角色拆:

    行動建議:拿你最近一個要反覆修改的任務(例如長文案撰寫、PRD 撰寫),先在筆記裡寫下:
    – 「策略」要產出什麼?
    – 「執行」要交付什麼?
    – 「審查」要檢查什麼?

    後面我們會把這三塊直接翻成多代理設定。


    2. 長流程協作:從需求到結果的「接力棒」

    Claude Corps 的運作方式,可以理解為:

    1. 每個 Agent 有自己的「角色設定 + 任務說明」。
    2. 任務在 Agent 之間有順序地傳遞(像專案流程),每一步可以讀取前面 Agent 的輸出。
    3. 某些 Agent 還可以「退回修改」——例如 Reviewer 要求 Executor 重寫。

    這讓長流程任務可以被拆成清楚的階段:

    • 不再是「一個超長 prompt」,而是一組可重複、可維護的流程
    • 你可以只換掉「執行 Agent」,就測試不同寫作風格或程式風格。

    行動建議:選一個你每週都會做的流程(例如「寫週報」或「做競品整理」),用 3–5 個步驟寫成清單,想像每一步由一位 Agent 負責,準備在工具裡實作成 workflow。


    3. 內建 rubric grading 迴圈:讓 AI 自己打分再重寫

    在 Towards AI 那篇案例中,作者只做了一件事:

    在原本的 Claude 產生流程後面,多加一個「評分 Agent」,用 rubric grading 機制打分,如果分數太低就要求重寫。

    💡 關鍵: 只多加一個評分 Agent,就能在既有流程上建立「自評+重寫」迴圈,顯著提升輸出品質。

    關鍵是「分離」:

    • 產出內容的是 主 Agent
    • 負責打分與給修改建議的是 評分 Agent

    這樣可以:

    • 降低主 Agent 自己「自賣自誇」的偏差。
    • 讓評分標準可以獨立調整、版本管理。

    行動建議:想一個你最在意品質的輸出(例如「產品頁文案」或「技術文件」),列出 5 條評分標準(如結構、清晰度、錯字、符合品牌語氣等),後面我們會把它翻成 rubric grading Agent。


    實際案例:三種你可以馬上想像的流程

    案例 1:行銷活動全流程

    用 Claude Corps,你可以把一個行銷活動拆成:

    1. 策略 Agent
    2. 根據產品、目標客群、預算,產出「活動目標 + 訊息主軸 + 渠道組合」。
    3. 內容 Agent
    4. 依策略生成:EDM 內容、社群貼文、廣告標題、LP 架構。
    5. 審查 Agent
    6. 根據品牌語氣、禁用詞清單、法規注意事項打分。
    7. 如果某項低於 7/10,要求內容 Agent 重寫該段。

    💡 關鍵: 先用簡單門檻(如 7/10)判斷是否重寫,可以在不大改流程下快速導入品質控管。

    下一步你可以做:先把你現有的一個活動企劃書丟給 Claude,請它幫你拆成「策略 / 內容 / 審查」三階段,當作之後設定多代理流程的草稿。


    案例 2:自動化研究彙整

    研究型工作(PM、顧問、投資研究)非常適合用多代理拆分:

    1. 搜尋 Agent
    2. 根據關鍵字,抓資料來源(論文標題、新聞、公司年報等摘要)。
    3. 整理 Agent
    4. 把零散資料整理成結構化表格(時間、來源、關鍵發現)。
    5. 分析 Agent
    6. 做趨勢整理、異常點分析、風險與機會列表。
    7. 審查 Agent
    8. 檢查引用是否明確、有無過度延伸推論。

    下一步你可以做:拿近期一份你自己做的研究報告,請 Claude 列出「如果讓三個 AI 分工,你會分給誰做什麼」,你就有一個可以搬進 Corps 的流程骨架。


    案例 3:產品規格 → 需求分解 → 工單產生

    對產品 / 工程團隊來說,最實用的一個模式是:

    1. PRD Agent
    2. 輸入你草寫的產品想法,產出結構化 PRD(目標、用例、成功指標)。
    3. 需求分解 Agent
    4. 把 PRD 拆成功能需求、技術任務、依賴關係。
    5. 工單 Agent
    6. 依照 Jira / Linear 格式,產生工單標題、描述、驗收標準。
    7. 審查 Agent
    8. 檢查:需求是否有模糊詞、是否有驗收方式、是否與目標對齊。

    下一步你可以做:從你現有的一張 Jira 票開始,請 Claude 幫你「反推」:如果這張票是 AI 產的,上游的 PRD 會長怎樣?然後再用多代理方式讓 AI 自行從 PRD 走到工單。


    如何在現有 Claude 專案中,加一個「審稿/評分 Agent」

    這裡給你一個 最小可行實驗(MVP):不需要整套 Claude Corps,只要你現在有在程式裡呼叫 Claude API,就可以加上「rubric grading 迴圈」。

    假設你目前有一個簡單的 Python 流程:

    from anthropic import Anthropic
    
    client = Anthropic(api_key="YOUR_API_KEY")
    
    user_task = "請寫一篇 500 字的產品介紹文案,產品是…"
    
    # 原本:直接讓 Claude 產出
    resp = client.messages.create(
        model="claude-3-5-sonnet-20240620",
        max_tokens=1200,
        messages=[{"role": "user", "content": user_task}],
    )
    original_output = resp.content[0].text
    print(original_output)
    

    第一步:定義你的 rubric(評分標準)

    先用文字列出你在意的點,例如:

    RUBRIC = """
    你是嚴格的審稿員,負責評估一段文案品質。
    
    請依照以下四個面向,每項 1–10 分評分,並給出具體修改建議:
    1. 結構清晰度(是否有明確開頭、重點段落、結尾)
    2. 語言流暢度(是否口語自然、無明顯錯字)
    3. 說服力(是否清楚說明產品價值,舉例是否具體)
    4. 品牌一致性(是否符合「專業、友善、不浮誇」的語氣)
    
    輸出格式:
    - scores: JSON 格式,包含四項分數與總分 total
    - suggestions: 對每一項給出具體修改建議
    """
    

    第二步:新增一個評分 Agent 呼叫

    def grade_output(text: str):
        resp = client.messages.create(
            model="claude-3-5-sonnet-20240620",
            max_tokens=800,
            messages=[
                {"role": "system", "content": RUBRIC},
                {
                    "role": "user",
                    "content": f"請評分以下文案:\n\n{text}",
                },
            ],
        )
        return resp.content[0].text
    

    你可以先直接 print(grade_output(original_output)) 看看評分長怎樣,再決定要怎麼解析。


    第三步:加上「低分就重寫」的迴圈

    以下是一個簡化版迴圈(概念接近 Towards AI 文中那個 80 行示範):

    import json
    
    MIN_SCORE = 32  # 四項各 8 分的總分門檻
    MAX_TRIES = 3
    
    current_output = original_output
    
    for i in range(MAX_TRIES):
        grading_raw = grade_output(current_output)
        print("=== Grading round", i+1, "===")
        print(grading_raw)
    
        # 嘗試從回覆中抓 JSON scores
        try:
            start = grading_raw.index("{")
            end = grading_raw.rindex("}") + 1
            scores = json.loads(grading_raw[start:end])
        except Exception:
            break
    
        if scores.get("total", 0) >= MIN_SCORE:
            break
    
        # 分數不夠,帶著建議重寫
        rewrite_prompt = f"""
    你剛剛寫了一段文案,得到以下評分與建議:
    
    {grading_raw}
    
    請在保留核心資訊的前提下,依照建議,完整重寫文案。
    """
        resp = client.messages.create(
            model="claude-3-5-sonnet-20240620",
            max_tokens=1200,
            messages=[
                {"role": "system", "content": "你是專業文案撰寫人員。"},
                {"role": "user", "content": rewrite_prompt},
            ],
        )
        current_output = resp.content[0].text
    
    print("=== 最終文案 ===")
    print(current_output)
    

    做到這裡,你就已經擁有:

    • 一個主 Agent(寫文案)
    • 一個評分 Agent(打分 + 給建議)
    • 一個簡單的「多輪改善」迴圈

    💡 關鍵: 設定 MIN_SCOREMAX_TRIES,能在成本可控的情況下,讓文案經過多輪自動優化。

    下一步你可以做:
    – 把 RUBRIC 換成「技術文件」或「教學文章」版本。
    – 把同樣的架構套到「程式碼審查」:改成檢查可讀性、錯誤風險、測試覆蓋建議。


    適合誰用:先把自己當「專案經理」,再讓 AI 來當團隊

    以下幾種工作型態,特別適合導入 Claude Corps 或至少導入「審稿 Agent」:

    • 行銷 / 內容團隊:需要大量產出文案,但又要維持品牌一致、避免錯漏。
    • 產品 / UX 團隊:PRD、用戶故事、需求拆解到工單,流程清楚但繁瑣。
    • 顧問 / 研究 / 投資分析:資料搜集、整理、分析、報告撰寫有明確步驟。
    • 單人創業者 / 自媒體:你一個人要扮演整個團隊,用多代理來「外包」給 AI。

    建議起手式:
    – 不要一開始就設計 10 個 Agent。
    – 先從「主 Agent + 審稿 Agent」開始,把最痛的一個環節自動化。


    怎麼開始:從一個 rubric Agent 起步

    目前 Claude Corps 的完整能力會陸續擴展,不過你可以立刻從現有 Claude API 或 Claude 網頁版開始實驗:

    1. 如果你會寫一點程式
    2. 申請 Anthropic API Key。
    3. 建一個最小專案(就像上面的 Python 範例),先讓「主 Agent + 評分 Agent」跑起來。
    4. 把 rubric 存成版本可控的檔案,當作你團隊的「寫作 SOP」。

    5. 如果你只用 Claude 網頁版(或其他聊天介面)

    6. 在同一個對話裡,先請 Claude 當「執行者」產出草稿。
    7. 接著開新一則訊息,明確指定:

      你現在是嚴格的審稿員,請依照以下四個面向評分並給修改建議……

    8. 再下一則訊息,把整段評分貼回去,請它依建議完整重寫。

    9. 如果你準備導入多代理架構(如 Claude Corps 或其他 Agent 框架)

    10. 把目前流程畫成 3–5 個步驟(策略 / 執行 / 審查)。
    11. 每一步寫清楚:輸入是什麼?輸出是什麼?由誰接手?
    12. 在框架裡把每一步實作成單獨的 Agent,再用 workflow 串起來。

    只要你成功把「審稿 Agent」加進現有流程,通常輸出品質就會有肉眼可見的提升,接下來要不要擴充成完整多代理團隊,你會更有感覺。


    小結

    • 把 Claude 當成一個人,很容易塞爆它的 prompt;把它拆成多個 Agent,流程會變得好維護、好重複。
    • 最值得先做的第一步,就是加上一個「rubric 審稿 Agent」,讓 AI 自己打分自己改。
    • 從一個最小流程開始(例如單一文案產出),等你看見品質真的上來,再考慮把整個專案流程搬進 Claude Corps 或其他多代理框架。

    🚀 你現在可以做的事

    • 選一個你常做的任務,照「策略 / 執行 / 審查」拆成 3 段,寫成流程草稿
    • 依文中的 Python 範例,在現有 Claude API 流程中加入一個 RUBRIC 評分 Agent
    • 在 Claude 網頁版實際跑一次「先產出、再評分、再依建議重寫」的完整迴圈
  • 一行指令組好自己的 AI 代理團隊

    一行指令組好自己的 AI 代理團隊

    📌 本文重點

    • 把每個 Agent 當成可版本控制的 Git repo
    • AGENTS.mdskills/ 拆開角色與能力
    • .agentlas/ 管理記憶與設定,輕鬆切換模型
    • 用一行 CLI 指令生成並維護多代理 AI 團隊

    只用一行指令,你就能建立一個「像程式專案一樣可版本控制」的多代理 AI 團隊,解決長期記憶混亂、每次對話都要重講一遍的痛點。

    參考架構原文(作者在 Reddit 分享):https://www.reddit.com/r/artificial/comments/1twmhya/an_opensource_agent_architecture_that_solves_the/


    核心功能:把 Agent 當成一個 repo,而不是一段 prompt

    這套開源架構的關鍵想法:每個 Agent 是一個 Git 倉庫,而不是存在聊天框裡的一段系統 prompt。

    💡 關鍵: 把 Agent 轉成可版控的 Git repo,可以用熟悉的軟體開發流程(PR、review、版本管理)來調整 AI 行為,而不是每次重寫 prompt。

    1. AGENTS.md:把「人設 + 任務範圍」寫成文件,而不是憑記憶

    AGENTS.md 是這個架構的核心說明書,裡面通常會包含:

    • 每個代理的角色定位
    • 能做什麼(scope) / 不能做什麼(限制)
    • 彼此如何協作(誰丟任務給誰、輸出長什麼樣)

    你可以做的事:

    1. 在任意資料夾新增 AGENTS.md,用這樣的格式寫第一個代理:

    “`markdown
    # Agents

    ## doc_assistant
    – 角色:技術文件整理員
    – 任務:整理長篇文件、產生摘要與目錄
    – 輸出格式:Markdown,必須包含「摘要」「重點條列」「待釐清問題」三段

    ## code_reviewer
    – 角色:程式碼審查員
    – 任務:針對 Pull Request 提出具體修改建議
    – 限制:不直接改動程式,只提出建議與風險說明
    “`

    1. 把這個 repo 推上 Git(GitHub / GitLab),之後團隊改需求只改這份文件。

    2. skills/:把「能力」拆成工具,而不是糊在一大段 prompt 裡

    傳統代理常見問題是:所有指令、規則、流程都揉在一段很長的系統 prompt 中,改一行就怕爆。

    在這個架構裡,每個能力是一個 skill 檔案,放在 skills/ 資料夾,例如:

    • skills/summarize_docs.md:怎麼讀、怎麼切段、輸出格式
    • skills/review_pr.md:審查步驟、要檢查的細項
    • skills/fetch_urls.md:如何抓網頁、處理錯誤

    你可以做的事:

    1. 新增資料夾 skills/,寫一個最小可用的 skill:

    “`markdown
    # summarize_docs

    步驟:
    1. 讀取輸入文件
    2. 把文件拆成 3–7 個主題
    3. 每個主題用 3 行內說清楚

    輸出格式(Markdown):
    – 一句總結
    – 主題列表(子彈點)
    “`

    1. AGENTS.md 裡指定某個 agent 可以使用 summarize_docs 這個 skill。

    3. .agentlas/:把「記憶和設定」存在檔案,而不是模型腦袋

    .agentlas/ 是這套系統自己的設定與記憶資料夾,用來存:

    • 各代理的偏好設定(語氣、輸出格式)
    • 長期記憶索引(不是直接塞進模型,而是存成檔、用時再讀)
    • 已完成任務的 metadata(方便日後追蹤與再訓練)

    這樣的好處是:

    • 不會把所有對話硬塞進「長期記憶」變成噪音
    • 每次執行前可以用規則選擇要載入哪一段內容

    你可以做的事:

    • .agentlas/config.yaml 加上最基本設定(示意):

    yaml
    default_model: claude
    memory:
    enabled: true
    strategy: recent-and-related
    max_items: 50


    適合誰用:3 個具體場景

    1. 文件整理 + 程式碼審查:建立雙代理 pipeline

    目標:

    • 代理 A 整理設計文件
    • 代理 B 以文件為準則,審查 PR 是否符合設計

    你可以怎麼做:

    1. AGENTS.md 定義兩個代理:

    “`markdown
    ## doc_assistant
    – skills: [summarize_docs]

    ## code_reviewer
    – skills: [review_pr]
    – 會先讀 doc_assistant 的輸出再開始審查
    “`

    1. 把專案文件放在 docs/、程式碼在 src/,PR diff 存到 pr/123.patch

    2. 在終端機執行(以架構作者的描述為例):

    bash
    agentlas run doc_assistant "整理 docs/ 裡的文件,產出開發規範摘要"
    agentlas run code_reviewer "根據最新開發規範,審查 pr/123.patch"

    1. 審查邏輯日後有變,就更新 skills/review_pr.md,而不是重新教一次模型。

    2. 資料抓取 + 報表生成:自動化情報小幫手

    目標:

    • 代理 C 負責抓網站、清洗文字
    • 代理 D 讀整理後資料,輸出報表(例如每週競品動態)

    步驟:

    1. skills/fetch_urls.md 寫清楚:怎麼從列表讀網址、輸出 JSON 或 Markdown 表格。

    2. 定義兩個 agent:

    “`markdown
    ## data_collector
    – skills: [fetch_urls]

    ## report_writer
    – skills: [summarize_docs]
    – 輸出格式:週報(含「本週重點」「風險」「下週觀察」)
    “`

    1. 每週只需要:

    bash
    agentlas run data_collector "從 urls.txt 抓內容,輸出到 data/this_week.md"
    agentlas run report_writer "讀 data/this_week.md,生成 weekly_report.md"

    1. 週報模板要改,就改 skills/summarize_docs.md 或另開 skills/weekly_report.md

    3. 多人團隊:把「AI 同事」當成共同維護的 repo

    你可以把這個代理倉庫當成一個共享 AI SOP

    • PM 改 AGENTS.md 描述角色與流程
    • 開發者在 skills/ 補上新的工具使用說明(例如專案腳本、內部 API)
    • 新同事只要 clone 下來,就能直接用同一套 AI 工作流

    實際做法:

    1. 建一個 GitHub repo:company-ai-agents

    2. 定一條規則:

    3. 改 Agent 行為 = 改 AGENTS.md / skills/,必須走 PR 流程

    4. 不再使用的 Agent 要標記 deprecated,避免沒人知道它還在跑

    5. README 裡寫清楚「如何在本機執行 agentlas、如何切換模型」。


    怎麼開始:一行指令 + 接上你習慣的模型

    這個架構的一大好處是:不綁特定模型,可以跑在 Claude Code、Codex、Gemini CLI 等環境。

    💡 關鍵: 架構與模型解耦,讓你能在不改 AGENTS.mdskills/ 的情況下,自由切換到成本更低或能力更強的模型。

    1. 安裝指令(假設已提供 CLI:agentlas

    作者在 Reddit 說明,整套系統可以透過一行安裝:

    pip install agentlas  # 或作者實際提供的套件名稱
    

    接著在任意資料夾初始化:

    agentlas init
    

    這通常會自動產生:

    • AGENTS.md
    • skills/
    • .agentlas/

    你可以做的事:

    • 直接在一個新資料夾跑 agentlas init,把它當成「AI 同事模板專案」。

    2. 接上常見模型:Claude / Codex / Gemini CLI

    根據作者說明,這個架構支援多個 runtime,不鎖在某一家:

    • 想用 Claude:在 .agentlas/config.yaml 設定 runtime: claude_code
    • 想用 OpenAI / Codex:設為 runtime: codex
    • 想用 Gemini CLI:設為 runtime: gemini_cli

    範例設定:

    runtime: claude_code
    model: claude-3-5-sonnet
    api_key_env: ANTHROPIC_API_KEY
    

    你可以做的事:

    1. 先用你現在線上付費的模型(例如 Claude)跑通第一個 agent。

    2. 之後想切換模型,只改 config,不改 AGENTS.mdskills/ 的內容。

    3. 一句描述,讓系統自動幫你生出代理團隊

    根據 Reddit 原文描述,你可以直接用一句話生成整個代理團隊,例如:

    agentlas new "幫我建立一個:整理產品需求文件 + 產出技術任務清單的雙代理工作流"
    

    CLI 會:

    • 生成初版 AGENTS.md(定義 2 個代理)
    • 建好對應的 skills 檔案
    • 幫你填入基本步驟和輸出格式,之後你再微調

    你可以做的事:

    • 先讓工具幫你生一個「80 分」版本,再用 Git 慢慢調整到「95 分」。

    延伸閱讀:為什麼要從「串 prompt」升級到「Agent 專案」?

    如果你還在用 LangChain 式的「串 prompt + 自己管工具 schema」,可以參考這兩篇:

    這套開源架構跟 MCP 的共通點是:都把 Agent 當成一個長期維護的系統,而不是當場臨時寫的 prompt

    差別在於,這裡用「實際檔案 + repo」把行為和記憶拆開,讓你可以用熟悉的 Git 流程維護整套 AI 工作流。

    現在你可以做的最後一件事:

    • 開一個新 repo,跑一次 agentlas init,寫一個最小的 AGENTS.md
    • 選一個你每天真的會用到的小流程(例如「整理會議紀錄」)
    • 把它做成第一個可版本控制的 AI 代理

    之後,每次你覺得「這件事好像可以交給 AI」,就把需求寫進 AGENTS.mdskills/,你自己的多代理 AI 團隊就會越長越完整。

    🚀 你現在可以做的事

    • 在本機建立新資料夾,執行 agentlas init,產出第一版 AGENTS.mdskills/
    • 選一個日常流程(如整理會議紀錄),寫進 AGENTS.md 並建立對應的 skills/xxx.md
    • 建一個 company-ai-agents repo,推上 GitHub,讓團隊透過 PR 共同維護你的 AI 代理 SOP
  • Claude Code:把你的一人開發組變成小團隊

    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/webpackages/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,確認能在團隊內重複使用
  • 用 openai-agents-python 搭一個 AI 小團隊

    用 openai-agents-python 搭一個 AI 小團隊

    📌 本文重點

    • 用多個專職 agent 分工處理一個大任務
    • 透過 orchestrator 串起明確的多步驟流程
    • 將既有 API / 工具包成 @tool 打造可落地工作流
    • 先做最小 demo,再逐步擴展到既有系統

    只靠一個聊天機器人常常做出「四不像」的結果,而 openai‑agents‑python 要解決的,就是讓你把一個大任務拆給多個各司其職的 AI 代理人,像一個小團隊一樣協作完成。

    GitHub 專案連結:https://github.com/openai/openai-agents-python


    核心功能:把一個大任務拆給多個 AI

    1. 定義多個專長不同的 Agent

    你可以在程式裡定義多個「角色」:

    • 資料蒐集 agent:負責上網查資料、整理重點
    • 寫作/寫程式 agent:負責產出初稿或程式碼
    • 審稿 agent:負責檢查結構、風格、錯字或潛在 bug

    這些都用 Python class 或函式就能描述,像這樣:

    from openai_agents import Agent
    
    researcher = Agent(
        name="researcher",
        instructions="你負責閱讀提供的資料,整理三個重點與參考連結。",
    )
    
    writer = Agent(
        name="writer",
        instructions="你負責寫出條列清楚的技術部落格草稿,語氣教學向。",
    )
    
    reviewer = Agent(
        name="reviewer",
        instructions="你負責審稿,只給出修改建議與需要補充的段落。",
    )
    

    行動:先想一個你日常會做的「三步驟」任務,直接對應成三個 agent 的職責。


    2. 設計任務流程:交接、審查、協作

    openai‑agents‑python 的重點不只是「多個 agent」,而是讓你把流程寫清楚:誰先做、誰接手、誰審查。

    例如做一個「自動寫技術部落格」的流程:

    1. researcher:根據題目蒐集資料,產出重點摘要
    2. writer:根據摘要寫出完整草稿
    3. reviewer:審稿,給出修改建議

    💡 關鍵: 把一長串需求拆成 2–3 個明確步驟,比一次丟給單一聊天模型更穩定、可控。

    在框架裡你可以用一個 orchestrator(像主揪)來控制:

    from openai_agents import Orchestrator
    
    orchestrator = Orchestrator(agents=[researcher, writer, reviewer])
    
    async def run_blog_flow(topic: str):
        research_notes = await orchestrator.run("researcher", input={"topic": topic})
        draft = await orchestrator.run("writer", input={"topic": topic, "notes": research_notes})
        review = await orchestrator.run("reviewer", input={"draft": draft})
        return {"draft": draft, "review": review}
    

    行動:把你現在用 ChatGPT 一次請他「幫我想題目、寫文、修稿」的流程,拆成 2–3 個步驟,寫在紙上,對應到上面這種 orchestrator 程式碼結構。


    3. 串接外部工具與 API,變成真的工作流

    openai‑agents‑python 支援 agent 呼叫你自定義的工具函式,例如:

    • 網頁爬蟲(requestsPlaywright
    • 存取資料庫或 Google Sheets
    • 操作檔案系統,輸出成 Excel / CSV

    你先寫好 Python 函式,再把它註冊給 agent 使用:

    import requests
    from openai_agents import tool
    
    @tool
    def fetch_url(url: str) -> str:
        """抓取指定網址的 HTML"""
        return requests.get(url, timeout=10).text
    
    scraper = Agent(
        name="scraper",
        instructions="根據給定網址抓網頁內容並擷取需要的欄位。",
        tools=[fetch_url],
    )
    

    行動:先選一個你常用的 API(例如某個內部 HTTP API、Notion API),包成一個最小的 @tool 函式,讓 agent 能直接呼叫。


    Demo:一晚內做完的「自動寫技術部落格」小團隊

    這裡做一個最小可用版本:輸入一個主題,幫你:

    1. 蒐集重點
    2. 產生技術部落格草稿
    3. reviewer 做一次審查,輸出建議

    步驟 0:安裝與環境準備

    pip install openai-agents-python openai
    

    在專案根目錄建立 .env(或直接用環境變數):

    export OPENAI_API_KEY="你的 API Key"
    

    💡 關鍵: 只要設定好 OPENAI_API_KEY,就能在一晚內跑起一個可用的多 agent 小流程。

    步驟 1:建立第一個 writer agent

    新增 agents_blog.py

    from openai_agents import Agent
    
    writer = Agent(
        name="writer",
        instructions=(
            "你是技術部落客,請用繁體中文寫 1200 字內的教學文,"
            "條列清楚、加上小標題,讀者是有基礎的工程師。"
        ),
    )
    

    先單獨測試這個 agent:

    import asyncio
    from agents_blog import writer
    
    async def main():
        result = await writer.run({"topic": "Python logging 實戰"})
        print(result)
    
    if __name__ == "__main__":
        asyncio.run(main())
    

    行動:先確保「單一 agent + 單一呼叫」正常運作,看到一篇文章草稿再往下加複雜度。


    步驟 2:加上 researcher + reviewer

    修改 agents_blog.py

    from openai_agents import Agent
    
    researcher = Agent(
        name="researcher",
        instructions=(
            "你負責針對主題列出 5 個實用重點與常見坑,"
            "輸出 JSON 格式:{\"key_points\": [...]}。"
        ),
    )
    
    writer = Agent(
        name="writer",
        instructions=(
            "根據 research.key_points 寫技術部落格,"
            "包含簡介、實作步驟與常見錯誤排查。"
        ),
    )
    
    reviewer = Agent(
        name="reviewer",
        instructions=(
            "你是嚴格的技術編輯,檢查草稿是否:1) 結構清楚、"
            "2) 範例正確、3) 沒有太多空話。輸出建議清單。"
        ),
    )
    

    再加一個 orchestrator 流程(新檔 run_blog.py):

    import asyncio
    from openai_agents import Orchestrator
    from agents_blog import researcher, writer, reviewer
    
    orchestrator = Orchestrator(agents=[researcher, writer, reviewer])
    
    async def run_blog(topic: str):
        research_notes = await orchestrator.run("researcher", input={"topic": topic})
        draft = await orchestrator.run("writer", input={"topic": topic, "research": research_notes})
        review_notes = await orchestrator.run("reviewer", input={"draft": draft})
    
        print("=== 草稿 ===\n")
        print(draft)
        print("\n=== 審稿建議 ===\n")
        print(review_notes)
    
    if __name__ == "__main__":
        topic = input("輸入技術主題:")
        asyncio.run(run_blog(topic))
    

    行動:實際輸入你下週想寫的一個主題,看這個流程能不能生成一份你「願意再改一版就能上 blog」的草稿。


    步驟 3:做成簡單 CLI 或排程

    CLI(已經算一種):

    python run_blog.py
    

    若要每天自動產出草稿,可以用 crontab:

    crontab -e
    # 每天早上 9 點產出一篇關於 Python 的文章
    0 9 * * * cd /path/to/project && OPENAI_API_KEY=xxx python run_blog.py <<EOF
    Python 非同步程式設計實戰
    EOF
    

    行動:先用 CLI 手動跑幾次,確認品質與 token 消耗,再考慮排程自動化。


    適合誰用?幾個具體場景

    • 工程師/資料工程師
    • 資料抓取 → 清洗 → 產出報表(多個 agent 分別負責)
    • 專案 scaffold 生成 → 單元測試撰寫 → reviewer 檢查風險
    • 技術寫作者 / Developer Advocate
    • 自動產出技術部落格初稿、Release Note、API 範例
    • 內部平台團隊
    • 把既有的 CI/CD、監控 API 包成工具,讓 AI agent 幫忙查 log、整理 incident 報告

    💡 關鍵: 只要你習慣在 ChatGPT 下一長串指令,就幾乎一定能拆成 multi‑agent workflow 減少來回與手動操作。

    只要你目前已經在用 ChatGPT 做「一長串指令」,就適合把流程拆成 multi‑agent workflow 測試看看。


    延伸應用:部署、成本控制、整合現有系統

    1. 部署到雲端

    • 用 FastAPI 或 Flask 包一層 HTTP API,把 orchestrator 暴露成 /run_flow endpoint
    • 部署到 Render / Railway / Fly.io / 自家 Kubernetes,都只是一般 Python Web 服務部署流程

    2. 控制成本與錯誤

    • 限制 max_tokens / 模型:對只負責小任務的 agent 用較便宜的模型
    • 加上 retry + logging:為 orchestrator 跑的每一步記錄 prompt、輸出與 token 使用
    • 設定明確 instructions:讓 reviewer 僅輸出「建議清單」,避免重複生成整篇文章浪費 token

    3. 與既有後端或 Slack Bot 整合

    • 既有後端:在服務裡呼叫 orchestrator,把結果回寫資料庫或觸發其他工作
    • Slack Bot:
    • 用 Slack API 建一個 slash command /ai-team
    • 收到指令後,把文字丟給 orchestrator,完成後再貼回頻道

    行動:先選一個「已在跑的」後端流程(例如每週報表),先只把其中一段換成 agent 完成,觀察穩定度與成本。


    怎麼開始:最快上手路徑

    1. 看 GitHub READMEhttps://github.com/openai/openai-agents-python
    2. 先實作一個最小 demo:如本文的 blog flow 或「抓網頁 → 清洗 → 匯出 CSV」
    3. 再慢慢拆更多 agent:把你原本寫在同一個 prompt 或腳本裡的步驟,一個一個拆成獨立角色

    只要先完成一個「今晚就能跑起來」的小流程,你之後會很自然開始想:還有哪些工作可以交給這個 AI 小團隊做。

    🚀 你現在可以做的事

    • 打開專案,實作一個最小的 writer agent 並用單一呼叫產出一篇草稿
    • 把你常用的一個內部或公開 HTTP API 包成 @tool,讓 agent 能直接呼叫
    • 依照文中的 researcher → writer → reviewer 範例,寫出自己的第一個 orchestrator 流程並在本機跑一次