用 AI CLI Agent 從 5 個管道彙整使用者回饋

你會做出什麼

一條多 agent 管線，從五個管道讀取使用者回饋 -- GitHub Issues、Slack、Linear、email 匯出檔、app store 評論 -- 對每則回饋做情感分析和分類，按主題叢集，產出一份優先級排序的洞察報告。你只需要一個指令：claude "synthesize this week's feedback"。60 秒內，你會拿到一份結構化報告，顯示哪些主題正在升溫、哪些是緊急問題、哪些有最多跨管道的佐證。每條洞察都附上原文引述，讓你不用翻原始資料就能驗證。

這篇文章結束後，你會有：

• 五個 MCP server 連線，對接你實際的回饋管道
• 一個 orchestrator-workers agent 架構：每個管道一個 worker、一個 synthesizer 負責合併結果
• 帶有情感分數、信心指數、佐證引述的結構化輸出
• 一份 CLAUDE.md 編碼了你的產品領域知識，提升分類準確度
• Batch processing 設定，API 成本省約 50%
• Prompt caching 設定，支援每週重複分析

整個設定大約 45 分鐘。之後，每週回饋彙整從 PM 花一整天，變成一個終端指令。

問題：回饋散落在五個地方

如果你經營一個開發者工具 -- 或任何 SaaS 產品 -- 使用者回饋從各處湧入：

• GitHub Issues：bug 回報、功能請求，有時偽裝成問題
• Slack：社群頻道、support 討論串、隨口提到的問題
• Linear：內部 bug 分類、support 轉來的客戶回報工單
• Email：support 信箱匯出、業務轉寄的回饋、使用者直接寄來的信
• App store 評論：如果你有桌面或行動 app，附帶文字的星級評分

PM 手動做這件事的流程：開五個分頁，讀幾十則回饋，在腦中標記每一則，試著找出規律，最後寫一份摘要。每週花 4 到 6 小時。主題會被漏掉，因為人腦工作記憶在處理 30-40 則之後就飽和了。凌晨兩點埋在 Slack 討論串裡的緊急問題，三天後才被注意到。

這些資料的結構化程度已經足夠讓機器讀取。GitHub Issues 有 label、時間戳、reaction 數量。Slack 訊息有頻道、討論串、表情反應。Linear 工單有優先級和狀態。缺少的環節是跨五個來源的同步彙整和模式偵測。

架構：Orchestrator-Workers 模式

這條管線使用多 agent 模式。不是讓一個 agent 依序處理五個管道（慢、context 太重），而是每個管道跑一個 worker agent，平行執行，再由一個 synthesizer agent 合併結果。

                    Orchestrator
                   /  |   |  |  \
                  /   |   |  |   \
           GitHub  Slack Linear Email  Reviews
           Worker  Worker Worker Worker Worker
                  \   |   |  |   /
                   \  |   |  |  /
                    Synthesizer
                        |
                  Insight Report

為什麼這個模式重要：

1. 平行化。 五個 worker 同時跑。循序管線要花 5 倍時間。
2. 隔離。 每個 worker 的 context window 只包含自己管道的資料。沒有交叉汙染，不會 context 溢出。
3. 專精化。 每個 worker 的 prompt 針對自己的資料格式做了調校。GitHub worker 知道怎麼解析 issue label。Slack worker 知道怎麼從嘈雜的討論串裡提取有效訊號。
4. 成本效率。 Worker 把原始資料處理成精簡摘要。Synthesizer 只看到預處理過的結構化輸出 -- 遠少於原始輸入的 token 量。

事前準備

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

• Claude Code v2.1+ 搭配 API 存取
• Node.js 18+（跑 MCP server 用）
• GitHub CLI（gh）已用你的帳號登入
• Slack workspace 有 bot token
• Linear 帳號 有 API key
• Email 回饋匯出成 .csv 或 .json（從你的 support 工具 -- Zendesk、Intercom、或簡單的郵件匯出）
• App store 評論匯出成 .csv（從 App Store Connect、Google Play Console、或爬蟲工具）

如果你從來沒設過 MCP server，20 分鐘建一個 MCP Server 那篇教學涵蓋了基礎。

第一步：設定 MCP Server 連線

為三個 API 管道設定連線。Email 和 app store 評論使用本機檔案讀取，不需要 MCP server。

{
  "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"
      }
    }
  }
}

Email 和 app store 評論，每週匯出到一個 feedback/ 目錄：

feedback/
  email-export-2026-03-22.csv
  appstore-reviews-2026-03-22.csv

Agent 用標準檔案工具讀取這些檔案。不需要 MCP server。這讓設定保持簡單，避免為已經有匯出功能的資料來源另建整合。

重要： 把 token 放在環境變數，不要直接寫在 .mcp.json 裡。用 .env 檔或 shell profile。

第二步：在 CLAUDE.md 編碼領域知識

有用的回饋分類和雜訊之間的差別，就在領域知識。通用情感分類器不會知道「CLI 在 pipe 輸出時卡住」對開發者工具來說是 P0 bug，而「可以有深色模式就好了」是 P3 功能請求。

把這段加到你專案的 CLAUDE.md：

## Feedback Synthesis Workflow

### Product Context
Product: [Your Product Name] -- a developer CLI tool for [description].
Key user personas: individual developers, tech leads, DevOps engineers.
Current version: v2.3. Recent major release: v2.0 (new plugin system).

### Classification Taxonomy
When classifying feedback, use these categories:
- **bug-critical**: crashes, data loss, security issues, blocking workflows
- **bug-minor**: UI glitches, typos, non-blocking annoyances
- **feature-request**: new capabilities not currently in the product
- **ux-improvement**: existing features that work but are hard to use
- **documentation**: missing docs, unclear instructions, outdated examples
- **praise**: positive feedback (track for morale and marketing)
- **noise**: off-topic, spam, unactionable venting

### Priority Scoring Rules
- P0 (ship-breaking): affects >10% of users OR causes data loss OR security vulnerability
- P1 (next sprint): multiple users report the same issue OR blocks a common workflow
- P2 (backlog): single-user report OR nice-to-have improvement
- P3 (monitor): low signal, watch for recurrence

### Sentiment Scale
Score from -1.0 (extremely negative) to +1.0 (extremely positive).
Include a confidence score from 0.0 to 1.0.
Sarcasm, passive-aggressive tone, or "it would be great if [thing that is obviously broken]"
patterns should be scored as negative despite surface-level politeness.

### Known Issues (Do Not Re-Report)
- Plugin loading slow on Windows (PROJ-892, fix shipping in v2.3.1)
- OAuth token refresh race condition (PROJ-901, fix in progress)

這段領域知識是讓通用 LLM 變成領域感知分類器的關鍵。已知問題清單防止報告被已在追蹤的問題佔滿。分類法確保五個管道的分類一致。

第三步：定義 Worker Prompt

每個 worker agent 需要針對管道的 prompt。在 CLAUDE.md 裡加入這些工作流段落：

### GitHub Feedback Worker
When processing GitHub Issues feedback:
1. Fetch issues from repos [org/repo-a, org/repo-b] created or updated in the last 7 days.
2. Include: title, body, labels, reaction counts, comment count, author.
3. Exclude issues created by bots or with the "internal" label.
4. For each issue, output a JSON object:
   {
     "source": "github",
     "id": "org/repo#123",
     "title": "...",
     "summary": "one-line summary",
     "category": "from taxonomy",
     "sentiment": -0.6,
     "confidence": 0.85,
     "priority": "P1",
     "quote": "exact user quote that best represents the feedback",
     "signals": { "reactions": 12, "comments": 5, "duplicates": 2 }
   }

### Slack Feedback Worker
When processing Slack feedback:
1. Search channels: #support, #feedback, #general for messages in the last 7 days.
2. Filter to messages that contain product feedback (ignore social chat, meeting logistics).
3. Thread replies count as part of the parent message's feedback.
4. Same JSON output format as GitHub worker.

### Linear Feedback Worker
When processing Linear feedback:
1. Fetch issues with label "customer-reported" updated in the last 7 days.
2. Include: title, description, priority, status, customer quotes from comments.
3. Same JSON output format.

### Email Feedback Worker
When processing email exports:
1. Read feedback/email-export-*.csv from the last 7 days.
2. Parse columns: date, sender, subject, body.
3. Same JSON output format. Use sender email domain for signal weighting
   (company domains > personal emails for B2B products).

### App Store Review Worker
When processing app store reviews:
1. Read feedback/appstore-reviews-*.csv from the last 7 days.
2. Parse columns: date, rating, title, body, platform (iOS/Android).
3. Same JSON output format. Star rating maps to initial sentiment
   (1-2 stars = negative, 3 = neutral, 4-5 = positive), but override
   based on text content if they conflict.

關鍵設計決策：每個 worker 輸出相同的 JSON schema。這種一致性讓 synthesizer 的工作變得可處理。它不在乎回饋來自哪裡 -- 只看到一個扁平的已分類項目列表。

第四步：定義 Synthesizer Prompt

Synthesizer 接收所有 worker 輸出，產出最終報告：

### Feedback Synthesizer
When I ask to synthesize feedback, after all workers have completed:

1. **Deduplicate.** Group items that describe the same underlying issue across channels.
   Use semantic similarity, not exact string matching.

2. **Cluster by theme.** Group related items into themes. A theme needs 3+ items.

3. **Rank themes by urgency.** Score = (count of P0/P1 items * 3) + (total items * 1)
   + (sum of reaction/signal counts * 0.5). Higher score = higher urgency.

4. **Output the report** in structured format with:
   - Sources processed count per channel
   - Top themes ranked by urgency, each with summary, priority, evidence quotes, suggested action
   - Praise highlights (top 5 positive items)
   - Low-signal items to monitor

第五步：執行管線

有兩種方式：循序（較簡單）和平行（較快）。

循序執行

一個指令搞定：

claude -p "synthesize this week's feedback"

Claude Code 讀取 CLAUDE.md 工作流，循序呼叫每個 worker 的 MCP tool chain，再跑 synthesizer。可以用但要 2-3 分鐘，因為每個管道是逐一處理。

平行執行：多 Agent

要更快的結果，每個 worker 跑在獨立的終端窗格：

# 窗格 1：GitHub worker
claude -p "run the GitHub feedback worker, output to feedback/github-results.json"

# 窗格 2：Slack worker
claude -p "run the Slack feedback worker, output to feedback/slack-results.json"

# 窗格 3：Linear worker
claude -p "run the Linear feedback worker, output to feedback/linear-results.json"

# 窗格 4：Email worker
claude -p "run the Email feedback worker, output to feedback/email-results.json"

# 窗格 5：App Store worker
claude -p "run the App Store review worker, output to feedback/appstore-results.json"

五個都完成後，跑 synthesizer：

claude -p "read all JSON files in feedback/*-results.json and run the feedback synthesizer"

平行方式把牆鐘時間從 2-3 分鐘降到約 40 秒。五個 worker 同步執行，synthesizer 只處理預分類的輸出。

第六步：成本最佳化

每週跑這條管線會累積成本。這三招能大幅降低：

Batch Processing

用 Claude 的 batch API 做非緊急的每週分析。Batch 請求只要標準價格的 50%：

# 排進 batch job（24 小時內執行完，便宜 50%）
claude -p "synthesize this week's feedback" --batch

如果你每週一早上跑分析，週日晚上排 batch job。隔天早上結果就好了。

Prompt Caching

你的 CLAUDE.md 領域知識、分類法、worker prompt 每週都一樣。只有回饋資料會變。Prompt caching 代表 prompt 的靜態部分（分類法、分類規則、輸出格式）在第一次執行後就被快取。後續的執行只對新的回饋資料付全價。

一次典型的週分析約 200 則回饋，prompt caching 能降低 60-70% 的 input token 成本，因為 CLAUDE.md 指令佔了 prompt 的大部分。

Token 高效的 Worker 輸出

Worker JSON schema 刻意設計得精簡。每個 worker 產出結構化摘要，不是原始資料傾倒。Synthesizer 處理大約 2,000-3,000 tokens 的 worker 輸出，而不是 50,000+ tokens 的原始回饋。Synthesizer 輸入的 10-20 倍縮減才是真正省錢的地方。

範例輸出

以下是管線為一個虛構的開發者 CLI 工具產出的結果：

## Feedback Synthesis Report -- 2026-03-15 to 2026-03-22

**Sources processed:** GitHub (34), Slack (28), Linear (15), Email (12), App Store (8)
**Total items classified:** 97
**Themes identified:** 7

### Top Themes (ranked by urgency)

#### 1. Plugin System Crashes on M-series Macs -- Score: 42 | Items: 11 | Channels: GitHub, Slack, Email
**Summary:** Apple Silicon 使用者回報第三方 plugin 在初始化時 crash。
大約 30% 的冷啟動會觸發，非確定性。從 v2.3 開始出現，
與該版本引入的新 plugin sandbox 相關。
**Priority recommendation:** P0
**Evidence:**
- github org/cli#487: "Plugin X crashes every other launch on my M2 MacBook,
  never happened on 2.2" (sentiment: -0.8, confidence: 0.92)
- slack #support: "Anyone else seeing plugins fail on Apple Silicon? Three
  people on my team hit this today" (sentiment: -0.7, confidence: 0.88)
- email support-4521: "We cannot roll out v2.3 to our team until this plugin
  crash is fixed. Blocking our adoption." (sentiment: -0.9, confidence: 0.95)
**Suggested action:** 調查 ARM64 上 plugin sandbox 的記憶體配置。
檢查 v2.3 sandbox 是否使用了假設 x86 的記憶體對齊。

#### 2. Config File Documentation Gaps -- Score: 18 | Items: 8 | Channels: GitHub, Slack, App Store
**Summary:** 使用者在設定進階功能時遇到困難，因為 config file
參考文件不完整。Plugin system 的設定選項和環境變數覆寫
在 changelog 裡有提到，但文件裡沒有。
**Priority recommendation:** P1
**Evidence:**
- github org/cli#501: "Where is the documentation for plugin config options?
  The changelog says 'see docs' but there is nothing there" (sentiment: -0.5,
  confidence: 0.90)
- appstore ios-2026-03-18: "Great tool but I spent 2 hours figuring out config.
  3 stars until docs improve." (sentiment: -0.3, confidence: 0.82)
**Suggested action:** 撰寫 config 參考文件。優先處理 plugin system
和環境變數段落。

### Praise Highlights
- github org/cli#492: "The new pipe operator support is incredible. Cut my
  build script from 40 lines to 12."
- slack #general: "Just showed the team demo. Everyone wants to switch from
  our current tool."
- appstore ios-2026-03-20: "Best CLI tool I have used in 10 years. 5 stars."

### Low-Signal Items (Monitor)
- 1 email requesting Windows ARM support (no other signals yet)
- 1 Slack message about slow startup in Docker containers (could be environment-specific)

調校管線

跑了幾週後，你會發現需要調整的地方。

低優先級項目太多。 把主題門檻從 3 則提高到 5 則。在 CLAUDE.md 加：A theme requires 5+ items to be included in the main report. Items below threshold go to the Low-Signal section.

漏抓諷刺語氣。 如果分類器把禮貌但暗藏怒氣的回饋標為中性，在 CLAUDE.md 的情感分析段落加入更多範例。用你自己回饋裡的真實案例，比泛用指令更有效。

重複主題。 如果「performance」和「speed」出現為不同主題，加入同義詞段落：Treat these as the same theme: performance, speed, slow, latency, lag, hang, freeze.

管道比例失衡。 如果 GitHub 因為量最大而主導結果，加入訊號加權：Weight items by signal strength: items with 5+ reactions or 3+ duplicates count as 2x. Single-occurrence items count as 0.5x.

多窗格的優勢

平行 worker 模式正好展現多窗格終端排版的價值。五個 agent 同時跑在五個管道 -- 你會想要同時看到它們全部的狀態，提早抓到錯誤，在 synthesizer 執行前驗證輸出品質。

執行期間的理想配置：上方五個小窗格，各顯示一個 worker 的進度。下方一個大窗格等著跑 synthesizer。某個 worker 完成時，你立刻看到輸出。如果 Slack worker 驗證失敗，前 5 秒就能發現，不用等其他四個 worker 跑完才知道。

管線穩定後，配置切換成 review 模式：主窗格放 synthesizer 報告，側窗格放 worker 原始輸出做佐證抽查，另一個終端準備好對洞察採取行動 -- 開工單、擬回覆、更新 roadmap。

延伸應用

同樣的架構可以改裝到相鄰工作流：

• 競品分析。 把回饋管道換成競品評論網站、Twitter 上提及競品的訊息、G2/Capterra 評論。叢集邏輯不變，資料來源不同。
• 版本發佈影響監控。 大版本發佈後，把時間窗口縮到 48 小時，加上警報門檻：如果 P0 主題在發佈 24 小時內出現，觸發 Slack 通知。
• 客戶健康度評分。 改成按客戶而非按管道跑。把單一客戶在所有管道的回饋彙整，隨時間建立健康度分數。

每種延伸都重用同樣的 MCP 連線和 orchestrator-workers 模式。你改的是 CLAUDE.md prompt，不是基礎設施。

總結

使用者回饋彙整是一個散佈在太多工具裡的模式識別問題。MCP server 讓 Claude Code 連上五個管道。Orchestrator-workers 模式平行處理它們。CLAUDE.md 裡的領域知識把通用分類變成產品感知的分析。帶有情感分數和佐證引述的結構化輸出讓報告是可執行的，不只是描述性的。

完整設定：五個 MCP/資料連線、一份包含領域知識和 worker prompt 的 CLAUDE.md、一個觸發管線的指令。每週回饋彙整從 PM 花一整天，變成 60 秒運算加 10 分鐘審閱。第一週就抓到的主題，正是那些不抓的話會拖到變成火燒屁股才被注意到的問題。