標籤: 開發者效率

  • 用 Vercel Skills 把 AI 變成你的命令列工具箱

    用 Vercel Skills 把 AI 變成你的命令列工具箱

    📌 本文重點

    • Vercel Skills 把 AI Agent 打包成可安裝的 CLI 工具
    • 一行 npx skills 就能體驗預設技能並接到自動化流程
    • 每個 skill 可在不同專案與 CI/CD 中重複使用與串聯
    • 適合開發者、行銷、DevOps 做文字與流程自動化

    用一句話說清楚:Vercel Skills 讓你用一行 npx skills,把一整包 AI Agent 當成可安裝的命令列工具,快速接到你的開發與自動化流程裡。

    專案連結:vercel-labs/skills on GitHub


    核心功能:把「AI 能力」做成可重用的 Skill 模組

    1. 一行指令啟動預設技能:npx skills

    想先感受效果,不想碰程式碼,可以直接這樣做:

    npx skills@latest
    

    執行後會:

    • 問你要使用哪些預設技能(例如:文件總結、PR 說明、自動整理 issue 等)
    • 在終端機互動式詢問你輸入內容或指定檔案
    • 把 AI 結果輸出在終端機,必要時也會幫你生成檔案

    你可以把它當成「AI 強化版 CLI 工具集」,用一次就知道哪些任務適合被 AI 自動化。

    💡 關鍵: 一行 npx skills@latest 就能體驗整套預設 AI 技能,是評估哪些工作可以自動化的最快方式。


    2. 每個 skill 就是一個可複用的 Agent 模組

    在 Skills 的設計裡:

    • 一個 skill = 一件具體可自動化的工作
    • 例如:summarize-doc(總結文件)、pr-description(產生 PR 描述)、rewrite-copy(改寫文案)
    • 實作上:一個 skill 就是一個 TypeScript/Node.js 模組,負責:
    • 接收輸入(檔案路徑、文字、Git diff 等)
    • 呼叫 LLM(預設走 Vercel AI SDK,可接 OpenAI / Vercel 等)
    • 回傳結構化結果(可以寫回檔案、回傳 JSON、或印在 CLI)

    這種設計的好處是:

    • 你可以在不同專案重複使用同一個 skill
    • 一個專案裡可以組合多個 skill 變成「串聯流程」(例如:先用一個 skill 擷取重點,再用另一個 skill 生成測試案例)

    💡 關鍵: 把每個任務抽象成 skill 模組後,你可以在多個專案與流程中重複組裝同一套 AI 邏輯,維護成本更低。


    3. 兩種使用方式:CLI 與程式內呼叫

    你可以把 Skills 當成:

    1. 命令列工具(CLI):適合快速手動使用、寫腳本
    2. 例如:
      bash
      # 執行某個 skill
      npx skills run summarize-doc ./docs/api.md

    3. 程式內呼叫(Node.js / TypeScript):適合接到 CI/CD、背景工作、Bot

    4. 基本結構類似:
      “`ts
      import { runSkill } from “skills”;

      const result = await runSkill(“summarize-doc”, {
      path: “./docs/api.md”,
      });

      console.log(result.summary);
      “`

    這讓 Skills 不只是一個「玩具 CLI」,而是可以被真正嵌入系統裡的 AI 自動化模組。

    💡 關鍵: 同一個 skill 既能在 CLI 使用,也能在程式碼中透過 runSkill 呼叫,降低從實驗到正式上線的落差。


    適合誰用:幾個具體場景

    1. 開發者:減少重複性的開發瑣事

    可以嘗試這幾類 skill:

    • 自動產出 PR 描述
    • CI 裡加入:檢查 PR 的 diff,用 skill 生成清楚的變更說明
    • 好處:大家不再花時間想描述格式,Reviewer 一眼看完重點
    • 整理 issue / ticket
    • 拉取標題 + 描述,讓 skill 自動標記類型、估計複雜度、抽出待辦項目
    • 好處:產品、工程、PM 都看到一致結構的內容
    • 生成測試案例
    • 針對關鍵函式或 API 定義,讓 skill 幫你列出可能的測試情境
    • 再由你挑選重要的手動補完

    可以做的行動:

    • 先用 npx skills 跑一輪預設技能
    • 想想你專案裡最常被抱怨「麻煩但又必須做」的步驟,選 1 個先做成 skill

    2. 內容與行銷:批次改寫與整理文字

    如果你常做這些事,Skills 很適合:

    • 批次改寫文案
    • 輸入一批產品描述,統一改寫成:短版、長版、社群貼文版
    • 可以客製 skill:輸入 CSV / JSON,輸出同格式檔案
    • 整理長文件摘要
    • 對內部文件(產品規格、研究報告)做摘要 + 重點 bullet points
    • 適合接到定時腳本:每天把新文件丟給 skill,產出摘要寄到 Slack

    可以做的行動:

    • 先準備一個資料夾,放你常用的範本文案或長文
    • npx skills 裡的 summary / rewrite 類 skill 試一次,感受輸出品質

    3. DevOps / 自動化工程師:接到 CI/CD、排程腳本

    你可以把 Skills 當成「AI 版 shell script 函式庫」:

    • GitHub ActionsGitLab CI 裡:
    • Pull Request 建立時自動跑 npx skills run pr-description
    • Release 前跑一次 npx skills run summarize-changelog 整理修改內容
    • cron / 定時腳本 裡:
    • 每天抓 issue / log / 監控報表丟給某個 skill,整理成一份人類可讀的摘要

    可以做的行動:

    • 在現有 CI pipeline 裡挑一個步驟,加一個額外 job 試跑 Skills
    • 先只在非必要流程執行,觀察穩定度與輸出品質

    怎麼開始:從預設技能到自訂 skill

    1. 安裝與首次執行

    前置需求:

    • Node.js(建議 18+)
    • 一個可用的 LLM API(例如 OpenAI 或 Vercel AI)

    第一步:直接執行 CLI(免全域安裝):

    npx skills@latest
    

    依照互動式提示:

    1. 選擇或設定你的模型提供者(可能會要求設定 API key)
    2. 選擇一個想先試的 skill(例如 summarize / pr-description)
    3. 依照提示輸入文字、選檔或指定路徑

    這一步的目標:先確認環境 OK + 大概知道 skill 的輸出長什麼樣子。


    2. 看一個最簡單自訂 skill 的程式結構

    接下來你可以把專案 clone 下來:

    git clone https://github.com/vercel-labs/skills.git
    cd skills
    pnpm install # 或 npm / yarn
    

    假設你要做一個最簡單的「文案改寫」 skill,概念結構會像這樣(簡化示意):

    // ./skills/rewrite-copy/index.ts
    import { defineSkill } from "skills";
    import { generateText } from "ai-sdk"; // 具體以官方範例為準
    
    export default defineSkill({
      name: "rewrite-copy",
      description: "改寫一段文案,維持原意但更口語/正式。",
      inputs: {
        text: {
          type: "string",
          description: "要改寫的原始文案",
          required: true,
        },
        tone: {
          type: "string",
          description: "語氣:casual 或 formal",
          default: "casual",
        },
      },
      async run({ inputs, model }) {
        const prompt = `請用${inputs.tone} 語氣改寫以下文案,但保留原本資訊:\n\n${inputs.text}`;
    
        const result = await generateText({
          model,
          prompt,
        });
    
        return {
          rewritten: result.text,
        };
      },
    });
    

    接著,你可以在本地 CLI 裡直接呼叫:

    npx skills run rewrite-copy --text "原始文案內容" --tone casual
    

    這就是 Skills 的基本模式:

    1. defineSkill 宣告輸入/輸出與執行邏輯
    2. run 裡呼叫你喜歡的模型
    3. 回傳一個乾淨的結果物件,方便 CLI 或其他程式接

    3. 在你的專案裡以 API / CLI 串接

    有兩種常見方式:

    方式 A:在 CI / script 裡用 CLI

    以 GitHub Actions 為例,在 .github/workflows/pr-description.yml 加上:

    jobs:
      generate-pr-description:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v4
          - uses: actions/setup-node@v4
            with:
              node-version: 20
          - run: npx skills@latest run pr-description --diff "$(git diff origin/main)"
            env:
              OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
    

    這樣每次開 PR 就會自動產生一段描述,印在 log 或寫到你指定的地方。

    方式 B:在 Node.js 應用程式裡呼叫

    在你自己的專案中安裝:

    npm install skills
    

    然後在程式裡:

    import { runSkill } from "skills";
    
    async function summarizeDoc(path: string) {
      const result = await runSkill("summarize-doc", { path });
      return result.summary;
    }
    

    接著你可以:

    • 在後端 API 提供 /summaries endpoint
    • 在排程腳本裡定時呼叫
    • 在 Slack Bot 裡接指令呼叫

    把 Skills 放進你的「AI 自動化工具箱」的建議做法

    建議一日內可以完成的小目標:

    1. 先用 npx skills 跑三個預設技能:文件摘要、PR 描述、文案改寫
    2. 挑一個你每天都會做、卻很耗時間的文字相關工作,寫成一個最小版 skill
    3. 在你現在的 CI 或本地腳本裡,接入這個 skill(先只給自己用)
    4. 一週後觀察:
    5. 節省了哪些手動步驟?
    6. 哪些輸出需要調 prompt 或加後處理?

    只要跑完這一輪,你就等於有了一個可持續擴充的「AI 自動化工具箱」,之後每多一個 skill,就是少一個你自己要反覆做的瑣事。


    專案連結再附一次:https://github.com/vercel-labs/skills

    想像一下:未來你新增工具,不是寫一串 shell script,而是新增一個 skill,讓 AI 幫你處理掉更多「人做很累、AI 卻很擅長」的工作。

    🚀 你現在可以做的事

    • 在本機直接執行 npx skills@latest,跑一輪預設技能體驗輸出
    • git clone 官方專案並閱讀 skills 目錄下的範例,試著複製一個改成自己的 skill
    • 在一個現有 CI pipeline(如 GitHub Actions)中,加上一個使用 npx skills run pr-description 的非關鍵實驗步驟
  • 用 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 routineNew 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 lintnpm 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.numberhead.refbase.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