用 AI CLI Agent 自動產生每日站會報告

每天早上都在浪費的那 15 分鐘

早上 9:47。站會 13 分鐘後開始。你打開 GitHub 看昨天 merge 了什麼。再開 Slack，看有沒有人昨晚 tag 你。再開 Linear，看工單狀態。你從三個 app 裡各複製一點，貼到訊息裡，整理一下措辭，發出去。三個瀏覽器分頁。十五分鐘。每天早上都來一次。

現在想像另一種畫面：你在 terminal 裡打一個指令。十秒後，一份結構化報告出現 -- 昨天 ship 了什麼、今天在做什麼、卡在哪裡。資料自動從 GitHub、Slack、Linear 拉過來。你掃一眼，按送出，回去寫 code。

這就是這篇文章要帶你 build 的東西。

做完之後，你會有：

• 三個 MCP server 連線（GitHub、Slack、Linear），設定在同一個 .mcp.json 裡
• 一段 CLAUDE.md 站會 workflow，告訴 agent 怎麼彙整和格式化你的更新
• 一個 agent 每次都會遵循的 structured output 範本
• 一個可以設成 alias 或排進 cron job 的可重複指令

整個設定大約 25 分鐘。之後，你每天的站會準備時間從 15 分鐘降到零。

為什麼站會報告是完美的自動化標的

把站會報告想成餐廳的收據。餐已經吃完了。價錢早就在系統裡了。收據只是把已經存在的資訊組成一個標準格式。沒有人用手寫收據。

你的站會也一樣。Commit 在 GitHub 裡。訊息在 Slack 裡。工單在 Linear 裡。報告只是撈取和格式化。這正好是 MCP tool chain 擅長的事 -- 你可以把 MCP server 想成 terminal 和外部世界之間的橋樑，讓 agent 走過每座橋、拿到需要的東西、然後彙整結果。

三個特性讓它特別適合自動化：

1. 輸入是確定的。 資料來源每天都一樣：過去 24 小時的 commit、進行中的工單、未讀的提及。
2. 輸出是結構化的。 報告格式永遠不變：Done、Doing、Blocked。就像填表格，不是寫信。
3. 風險很低。 稍微不完美的站會草稿，看一眼就能修好。你在貼出去之前花 10 秒檢查就好。

事前準備

你需要這些東西已安裝並完成驗證：

• Claude Code v2.1+ 搭配 API 存取
• Node.js 18+（跑 MCP server 用）
• GitHub CLI（gh）已用你的帳號登入
• Slack workspace 有 bot token（或使用現成的 MCP server）
• Linear 帳號 有 API key

如果你從來沒 build 過 MCP server，20 分鐘建一個 MCP Server 那篇教學涵蓋了基礎。這篇文章假設你已經懂 MCP tool 註冊和 .mcp.json 設定的運作方式。

第一步：設定 MCP Server 連線

MCP server 是 Claude Code 和外部服務之間的橋樑。每座橋負責一個服務。你需要三座橋：GitHub 一座、Slack 一座、Linear 一座。

你不需要從零開始自己 build。MCP 生態系已經有 production 等級的 server。在你專案的 .mcp.json 裡設定它們：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-your-bot-token",
        "SLACK_TEAM_ID": "T01ABCDEF"
      }
    },
    "linear": {
      "command": "npx",
      "args": ["-y", "@linear/mcp-server"],
      "env": {
        "LINEAR_API_KEY": "lin_api_your_key_here"
      }
    }
  }
}

或者用全域設定，讓所有專案都能用：

claude mcp add github --scope user -- npx -y @modelcontextprotocol/server-github
claude mcp add slack --scope user -- npx -y @anthropic/mcp-server-slack
claude mcp add linear --scope user -- npx -y @linear/mcp-server

加完後重啟 Claude Code，跑 /mcp 確認三個 server 都顯示綠色狀態。

重要： 把 token 放在環境變數，不要直接寫在 .mcp.json 裡。用 .env 檔或 shell profile 來 export。上面的範例寫成明碼純粹是為了說明。

第二步：理解 Tool Chain 的運作

你跟 Claude Code 要站會報告的時候，它不是發一個大 request。它會執行一連串較小的呼叫，就像一個研究員跑三間不同的圖書館，然後寫一份摘要。

底層發生的事是這樣的：

1. GitHub tool 呼叫 -- Agent 呼叫 search_repositories 或 list_commits，用日期篩選過去 24 小時、限定你的使用者名稱。也會呼叫 list_pull_requests 篩選你發出或 review 過的 PR。

2. Slack tool 呼叫 -- Agent 呼叫 search_messages，搜尋提及你的使用者名稱或你追蹤的頻道裡的訊息，限定過去 24 小時。

3. Linear tool 呼叫 -- Agent 呼叫 list_issues，篩選指派給你的 issue，狀態為 "In Progress"、"Done"（昨天完成的）、或 "Blocked"。

4. 彙整 -- Agent 收到三個來源的結構化 JSON。進行交叉比對：merge 過的 PR 對應到 "Done" 項目，進行中的 Linear 工單對應到 "Doing"，有人在 Slack 要你 review 的討論串對應到潛在的 blocker。這一步就像 agent 把所有拼圖攤在桌上，把吻合的那些拼在一起。

5. Structured output -- Agent 按照站會範本格式化所有內容。

這是一條 tool_use chain，不是單次 tool 呼叫。每一步都依賴前一步的結果。Claude Code 自動處理編排。你不需要寫任何串接的 code。你定義工具（透過 MCP server）和期望的輸出格式（透過 CLAUDE.md）。Agent 自己決定執行順序。

第三步：在 CLAUDE.md 寫站會 Workflow

CLAUDE.md 就像你交給助手的行前簡報。你寫得越具體，產出就越好。把這段加到專案的 CLAUDE.md（或 ~/.claude/CLAUDE.md 做全域設定）：

## Standup Report Workflow

When I ask for a standup report, follow this exact sequence:

### Data Collection
1. GitHub: fetch my commits and merged PRs from the last 24 hours.
   Use my GitHub username: YOUR_USERNAME
2. Slack: search for messages mentioning me or in my DMs from the last 24 hours.
   Focus on: action items, questions directed at me, decisions made.
3. Linear: list my assigned issues. Group by status: Done (completed yesterday),
   In Progress, Blocked.

### Cross-Reference Rules
- If a merged PR references a Linear ticket ID (e.g., PROJ-123), link them.
- If a Slack thread discusses a PR or ticket, note the context.
- If an In Progress ticket has no commits in 48+ hours, flag it as at risk.

### Output Format
Use this exact structure:

**Standup -- [today's date]**

**Done:**
- [ticket-id] Description (PR #number if applicable)

**Doing:**
- [ticket-id] Description -- expected completion: [date or "today"]

**Blocked:**
- [ticket-id] Description -- blocked by: [reason]
  Action needed: [what would unblock it]

**Mentions requiring response:**
- [channel/person]: summary of what they need

### Rules
- Keep each bullet to one line.
- Use ticket IDs as prefixes, not PR numbers (PRs are supplementary detail).
- If no blockers exist, write "No blockers" instead of omitting the section.
- Do not editorialize. Report facts only.

把 YOUR_USERNAME 換成你真正的 GitHub 帳號。如果你跨多個 GitHub org 工作，明確列出來讓 agent 知道搜尋範圍。

這段 workflow 設定遵循和所有 agent 任務一樣的 CLAUDE.md 撰寫原則：明確指定輸入、定義輸出結構、為邊界情況設定清楚的規則。

第四步：實際執行

打開 terminal，啟動 Claude Code，輸入：

generate my standup

第一次跑的時候，Claude Code 會詢問是否同意呼叫每個 MCP tool。核准它們。之後再跑的時候，核准紀錄會被 cache 住 -- 就像辦了一張借書證，之後進圖書館不用每次都出示證件。

你會看到 agent 依序處理：GitHub 查詢、Slack 搜尋、Linear 拉取，然後產出格式化報告。總耗時通常是 5 到 12 秒，取決於你的資料量。

輸出大概長這樣：

**Standup -- 2026-03-22**

**Done:**
- PROJ-142 Add rate limiting to /api/upload endpoint (PR #387)
- PROJ-139 Fix timezone offset in scheduled notifications

**Doing:**
- PROJ-145 Migrate user preferences to new schema -- expected completion: today
- PROJ-148 Write integration tests for payment webhook -- expected completion: Monday

**Blocked:**
- PROJ-151 Deploy staging environment for OAuth flow -- blocked by: DevOps
  team has not provisioned the new staging cluster yet
  Action needed: follow up with @infrastructure in #devops

**Mentions requiring response:**
- #frontend (Sarah): asked about the breaking change in the Button component API
- DM (James): requested review on PR #391

第五步：自動化觸發

跑了幾天確認輸出品質之後，可以把自己完全從流程中移除。

方案 A：Shell Alias

加到你的 .zshrc 或 .bashrc：

alias standup='claude -p "generate my standup"'

之後在任何 terminal 打 standup 就會產出報告。

方案 B：Cron Job

在站會前自動執行，把輸出導到剪貼簿：

# macOS -- 平日 9:45 執行
45 9 * * 1-5 cd ~/your-project && claude -p "generate my standup" | pbcopy

方案 C：直接貼到 Slack

把報告直接發到站會頻道：

claude -p "generate my standup" | curl -X POST \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"channel\": \"C01STANDUP\", \"text\": \"$(cat -)\"}" \
  https://slack.com/api/chat.postMessage

調校輸出

用了幾天後，你會發現值得調整的地方。這很正常。把第一版想成草稿 -- 它抓到了正確的資訊，現在你微調呈現方式。

太囉嗦。 在 CLAUDE.md 加一條規則：Keep the entire report under 15 lines. Summarize minor commits into a single "misc" bullet.

漏資料。 如果 agent 漏掉某個資料來源，用 /mcp 確認 server 有連上。MCP server 斷線就像橋的吊橋升起來了 -- agent 根本過不去。Tool 連不上是報告不完整的頭號原因。

工單對應錯誤。 如果你的 commit message 裡沒有工單編號，agent 就沒辦法交叉比對。要修的是你的 commit 習慣，不是 agent 設定。開始在 commit message 裡放工單編號（例如 git commit -m "PROJ-142: add rate limiting"）。

多專案。 如果你跨多個 repo 工作，在 CLAUDE.md 的資料收集步驟裡明確列出：GitHub: fetch commits from repos org/repo-a, org/repo-b, org/repo-c.

延伸應用

站會 workflow 是一個範本。同樣的 MCP tool chain 模式 -- 連接資料來源、撈取、彙整、格式化 -- 適用於：

• 週報 -- 把時間範圍擴大到 7 天，按 epic 分組而非單一工單
• Sprint 回顧 -- 拉出整個 sprint 完成的工單，計算 velocity，列出未完成的項目
• 交接筆記 -- 休假前產出一份所有進行中工作的摘要，每個項目附上脈絡

每種變體只需要在 CLAUDE.md 裡加一個新段落。MCP server 連線不用動。橋已經建好了。你只需要改變帶過橋的東西。

多窗格的優勢

剛開始設定這個 workflow 的時候，你要同時 debug 三個 MCP 連線。一個 server 可能驗證失敗，另一個可能回傳意料之外的資料格式，第三個可能初始化很慢。

想像你要修水管，但所有管線都藏在牆壁後面。單一 terminal 的 debug 體驗就是這種感覺。有效率的做法是一次看到全部：CLAUDE.md 放一個窗格、Claude Code 呼叫 tool 的 session 放另一個、第三個窗格 tail MCP server 的 log（npx @modelcontextprotocol/inspector）。哪裡出錯，馬上就看到，不用切視窗。

Workflow 穩定之後，你可以換配置：站會輸出放主窗格、GitHub 原始資料放旁邊做抽查、Slack 放第三個窗格立刻回覆報告裡提到的提及。

如果你跨多個專案工作，每個專案有自己的站會節奏，workspace 切換讓你在不同專案脈絡之間跳轉。每個 workspace 各有自己的 .mcp.json、CLAUDE.md、和 terminal 配置，不需要拆掉再重建你的 session。

總結

站會報告是一個已經被解決的問題。資料早就在 GitHub、Slack、Linear 裡了。MCP server 讓 Claude Code 直接存取那些資料 -- 它們是橋樑，資料就在橋的另一頭。CLAUDE.md 的 workflow 段落告訴 agent 怎麼彙整和格式化。結果是一份 10 秒鐘的站會報告，取代了過去 15 分鐘的切分頁和複製貼上。

整個設定：.mcp.json 裡三筆 MCP server 設定、CLAUDE.md 裡一段 workflow 區塊、一個指令來執行。之後你每天早上省下的 15 分鐘會不斷累積 -- 一年大約 60 小時，拿回來做真正的工程工作。