標籤: 工作流自動化

  • 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 流程並在本機跑一次