在終端建構完整的 AI 研究助理工作流

十四個分頁的問題

你一定經歷過。研究任務開始二十分鐘，瀏覽器看起來像犯罪現場。十四個分頁。Notion 上一份寫到一半的筆記。兩份下載了但還沒讀的 PDF。一個揮之不去的感覺 -- 答案好像在某個地方看過，三個分頁前？五個？記不得了。

你的 context 散落在彼此不互通的工具裡。搜尋路徑沒有記錄。明天回來，你得重走一半的路，因為線索過夜就冷掉了。

這篇文章建構一個不同的做法。終端原生的研究 workflow，每一步 -- 搜尋、擷取、摘要、引用、綜合分析 -- 都在同一個環境完成，由 AI agent 驅動，每個階段都有 structured output。想像把你桌上那堆便利貼換成一個有條理的檔案櫃，還有一個助理幫你整理。

這個 workflow 可以腳本化、可以重複執行。最終產出的是有引用來源的報告，不是一堆瀏覽器分頁。

讀完後你會有：

• 一份把 Claude Code 變成研究助理的 CLAUDE.md 設定
• 完整的多步驟 workflow：拆解問題、搜尋、擷取、綜合、報告
• 每一步都有來源引用的結構化筆記
• 可套用到任何研究主題的可重複流程

具體範例：研究「2026 年 AI CLI 工具市場全景」。

為什麼終端適合做研究

研究是一條 pipeline。你從一個大問題出發，拆成子問題，對每個子問題蒐集來源，擷取相關發現，最後綜合成連貫的產出。每一步都把前一步的輸出轉換成下一步的輸入。

這正是終端 workflow 擅長的事。Pipe、結構化檔案、可腳本化的指令，把混亂的流程變成可重現的。加上一個能搜尋網路、讀文件、產出 structured output 的 AI agent，你就有了一個把 context 存在檔案裡的研究助理 -- 可以檢視、編輯、做版本控制。

三個特性讓終端研究優於分頁跳轉：

1. 持久化 context。 研究狀態存在檔案裡，不是瀏覽器的 session memory。關掉終端，明天重開，一切都在原位。就像實體筆記本和每天晚上被擦掉的白板的差別。
2. 每階段都有 structured output。 不靠腦中記憶，每一步產出一份有引用的 markdown 檔案。綜合分析讀的是檔案，不是你的記憶。
3. 可重現性。 換個主題跑同一個 workflow，只改一個變數。過程不變，只有問題變了。就像一份可以交給同事的實驗 protocol。

前提條件

• Claude Code 已安裝並認證。需要設定說明請看 Claude Code 第一個小時。
• Web search MCP 已設定。Claude Code 內建的網路搜尋即可，或設定專用的搜尋 MCP server。
• 一個專案目錄。 為研究建立資料夾，所有筆記、來源和報告都放在這裡。

mkdir -p ~/research/ai-cli-landscape-2026
cd ~/research/ai-cli-landscape-2026
git init

研究目錄做版本控制意味著你能追蹤理解如何隨時間演進。也意味著 AI agent 可以用 git history 當 context。

第一步：設定研究用 CLAUDE.md

每個好的研究團隊都有方法論文件。這就是你的 -- 只不過機器也讀得懂。CLAUDE.md 告訴 agent 如何作為研究助理行動。不是通用指令檔，是你要 agent 遵循的特定方法論。就像新人第一天拿到的 SOP。

在研究專案根目錄建立 CLAUDE.md：

## Role
You are a research assistant. Your job is to help me investigate topics
systematically. Every claim must have a source. Never state facts without
citing where the information came from.

## Research Methodology

### Question Decomposition
When given a broad research question, break it into 3-7 specific sub-questions
that collectively answer the original. Each sub-question should be answerable
with a focused search. Present the sub-questions for approval before proceeding.

### Source Collection
For each sub-question:
1. Search the web for recent, authoritative sources (prefer primary sources,
   official docs, peer-reviewed papers, reputable industry reports).
2. For each useful source, record: title, URL, date, and a 2-3 sentence summary
   of what it contributes to our question.
3. Save source notes to research/sources/[topic-slug].md

### Extraction Rules
- Always include direct quotes with page/section references when possible.
- Distinguish between facts, claims, and opinions in your notes.
- Flag contradictions between sources explicitly.
- When two sources disagree, note both positions and the evidence each provides.

### Synthesis
When asked to synthesize, read all files in research/sources/ and produce a
structured report in research/reports/. The report must:
- Answer each sub-question with evidence from collected sources.
- Include a full reference list at the end.
- Flag areas where evidence is thin or contradictory.
- Use inline citations in [Author, Year] or [Source Title] format.

## Output Conventions
- All notes go in research/sources/
- All reports go in research/reports/
- Use markdown. No HTML.
- File names use kebab-case: market-size-estimates.md, not Market Size.md
- Every file starts with a YAML-style header: topic, date, status (draft/reviewed/final)

這份 CLAUDE.md 編碼了三個影響研究品質的關鍵模式。

第一，問題拆解。一個像「AI CLI 工具市場全景」這樣的大問題太模糊，不適合用一次搜尋回答。這就像拿一張湖那麼大的網去抓魚 -- 你需要更小的網去更小的池塘。拆成子問題 -- 市場規模、主要玩家、採用率、定價模式、技術差異化 -- 讓每次搜尋都聚焦，結果也更相關。這和 RAG（retrieval-augmented generation，一種 AI 系統透過檢索和組合聚焦資訊來回答複雜問題的技術）裡的子查詢拆解是同一個原理：多個聚焦檢索的組合結果優於單一大查詢。

第二，強制引用。「不得在沒有引用的情況下陳述事實」這條指令強迫 agent 把每個宣稱都扎根在來源上。沒有這個限制，語言模型會自信地生成聽起來合理但無法驗證的陳述。引用要求把 agent 從文字生成器變成研究工具。

第三，結構化檔案輸出。不是把所有東西倒進一長串對話，agent 寫檔案。每個檔案是獨立的研究單元，可以單獨審閱、編輯、引用。到了綜合分析的時候，agent 讀的是檔案 -- 不是可能已經被 compaction 壓縮過的對話記憶。想像鞋盒裡一堆收據和一張試算表的差別。資料一樣多，但只有一個能用。

第二步：拆解研究問題

在研究目錄開啟 Claude Code session，給它大方向的問題：

Research question: What is the AI CLI tools market landscape in 2026?
I need a comprehensive analysis covering market players, technical capabilities,
adoption patterns, and where the space is heading.

Agent 遵循 CLAUDE.md 的方法論，會把問題拆成子問題。針對這個主題，好的拆解像這樣：

## Sub-Questions

1. What are the major AI CLI tools available in 2026, and who builds them?
2. How do these tools differ technically — context windows, model access,
   extensibility (MCP, plugins, skills)?
3. What is the adoption trajectory — developer survey data, download counts,
   GitHub stars as a proxy for mindshare?
4. How do pricing and cost models compare across tools?
5. What workflows are developers actually using these tools for beyond
   code generation?
6. What are the main limitations and unresolved problems in the current
   generation of AI CLI tools?

審查子問題。補上你認為缺少的、刪掉超出範圍的。然後告訴 agent 繼續。這個審查步驟很關鍵 -- 先調好望遠鏡再觀測，比觀測了一小時才發現對準了錯的星星划算得多。

第三步：逐一搜尋與擷取

Agent 現在逐一處理每個子問題。對每個問題搜尋網路、評估來源、寫出結構化筆記檔案。

Start with sub-question 1. Search for authoritative sources on the major
AI CLI tools in 2026. Write your findings to research/sources/major-players.md

Agent 會搜尋、讀取結果，產出像這樣的檔案：

---
topic: Major AI CLI Tools in 2026
date: 2026-03-22
lastUpdated: "2026-03-22T10:46:45"
status: draft
---

## Key Players

### Anthropic — Claude Code
- Release: 2025. Current version as of March 2026 supports extended thinking,
  MCP tool use, multi-agent orchestration via subagents.
- Source: [Anthropic documentation](https://docs.anthropic.com/en/docs/claude-code)
- Notable: First major CLI tool to ship with native MCP support.

### Google — Gemini CLI
- Release: June 2025. Open-source, 1M token context window via Gemini 2.5 Pro.
- Source: [Google Developers Blog](https://developers.googleblog.com/)
- Notable: Free tier with generous rate limits. Strong for large-codebase analysis.

### OpenAI — Codex CLI
- Release: April 2025. Open-source, runs on codex-mini model by default.
- Source: [OpenAI Codex CLI repository](https://github.com/openai/codex)
- Notable: Lightweight, sandbox-first approach.

...

對每個子問題重複。Agent 為每個主題領域寫一個獨立檔案。幾輪之後，你的目錄結構像這樣：

research/
  sources/
    major-players.md
    technical-comparison.md
    adoption-data.md
    pricing-models.md
    developer-workflows.md
    limitations.md

每個檔案自成一體，有引用。你可以逐一審閱、標記為已審閱，或請 agent 在證據不足的子問題上深入挖掘。

第四步：處理矛盾與缺口

真正的研究會產生矛盾。一個來源說採用率年增 40%，另一個說市場正在整合到兩家。兩者可能同時為真，但 agent 應該標出這個張力，而不是悄悄選邊站。

初步蒐集完成後，請 agent 做稽核：

Review all files in research/sources/. Identify contradictions between sources,
areas where we only have one source (single points of failure), and questions
we have not answered well. Write the audit to research/sources/gap-analysis.md

缺口分析就是你的研究指南針。也許定價比較需要各廠商定價頁的第一手資料。也許採用數據過度依賴單一調查。這個反覆精煉 -- 搜尋、擷取、稽核、再搜尋 -- 是嚴謹分析與初次摘要的分水嶺。就像記者會找第二個消息來源交叉確認，和聽到什麼就直接發的差別。

第五步：綜合成報告

來源檔案夠紮實之後，請 agent 進行綜合分析：

Read all files in research/sources/. Synthesize a comprehensive report answering
the original research question. Follow the synthesis rules in CLAUDE.md.
Write to research/reports/ai-cli-landscape-2026.md

Agent 讀取每份來源檔案、交叉比對發現、解決或標記矛盾，產出有行內引用和完整參考清單的結構化報告。

綜合步驟受益於有結構、有引用的來源檔案，而不是原始的對話紀錄。Agent 處理的是乾淨的輸入，不是 50 輪對話中一半 context 已被 compaction 壓縮掉的殘骸。這就是檔案導向做法的回報：到了需要綜合分析的時候，輸入已經組織好了。檔案櫃的投資在這一刻回收。

第六步：迭代與精煉

第一版報告是草稿。批判性地閱讀它。請 agent 強化薄弱的段落：

Section 4 on pricing is too surface-level. Search for the actual pricing pages
of Claude Code, Gemini CLI, and Codex CLI. Update research/sources/pricing-models.md
with specific tier details. Then regenerate the pricing section of the report.

因為每份來源檔案是獨立的，你可以更新其中一份而不必重新產生整份報告。Agent 讀取更新後的檔案，只修補相關段落。就像換掉一本書的某一章，不需要重印整本。

讓 Workflow 可重複使用

上面的整個過程可以範本化。建立一個 shell script 來腳手架新的研究專案：

#!/bin/bash
# new-research.sh — scaffold a research project
TOPIC_SLUG="$1"
if [ -z "$TOPIC_SLUG" ]; then
  echo "Usage: new-research.sh <topic-slug>"
  exit 1
fi

PROJECT_DIR="$HOME/research/$TOPIC_SLUG"
mkdir -p "$PROJECT_DIR/research/sources"
mkdir -p "$PROJECT_DIR/research/reports"

# Copy the research CLAUDE.md template
cp "$HOME/research/templates/CLAUDE.md" "$PROJECT_DIR/CLAUDE.md"

cd "$PROJECT_DIR"
git init
echo "Research project scaffolded at $PROJECT_DIR"

現在開一個新研究專案只要一行指令：

./new-research.sh quantum-computing-error-correction-2026

同樣的目錄結構、同樣的 CLAUDE.md 方法論、同樣的 workflow。只有問題變了。

多面板研究佈局

研究涉及在閱讀來源檔案、與 agent 對話、審閱產出之間不斷切換。在單一終端面板做這件事就像用單口爐煮一桌菜 -- 技術上可行，但痛苦地慢。

最適合研究的佈局：

• 左面板（40%）： Claude Code session -- 在這裡下指令，agent 在這裡工作。
• 右上面板（30%）： 檔案檢視器，顯示正在生成的來源檔案或報告。即時看到它填入內容。
• 右下面板（30%）： 檔案樹或第二個檔案檢視器，用來交叉比對不同來源。

當 agent 寫入 research/sources/adoption-data.md 時，你在旁邊的面板即時看到檔案更新。想在綜合分析前比較兩份來源檔案，你在右側兩個面板各開一份。報告生成時，你一邊閱讀，agent 還在另一邊處理參考清單。

這不是為了好看。是為了讓 context 保持可見。研究失敗的原因往往是你忘了自己找到了什麼。多面板佈局讓研究狀態變得具體 -- 你看到檔案、看到 agent 在工作、看到產出。沒有東西藏在分頁後面。

如果你同時進行多個研究專案 -- 比如一個做市場全景、另一個做技術架構分析 -- 工作區切換讓你在兩者之間跳轉，而不需要拆掉終端佈局。每個工作區有自己的面板配置、自己的 CLAUDE.md、自己的檔案狀態。

比較：終端研究 vs 傳統研究

什麼時候不需要這個 Workflow

不是每個研究任務都需要這套裝備。如果你只是要快速回答一個具體問題，直接問 agent 就好。不需要腳手架。這個 workflow 是為了需要花好幾天、涉及多個來源、最後要交付成果的任務 -- 報告、簡報、決策文件。

判斷標準：

• 研究時間 30 分鐘以內： 直接問。不需要腳手架。
• 30 分鐘到 2 小時： 用 CLAUDE.md 方法論，但跳過 shell script 腳手架。
• 超過 2 小時或跨多個 session： 完整 workflow。投資在結構上的時間，在你中斷後回來發現一切都在原位時就能回收。

開始建構

建立一個研究目錄。放入本文的 CLAUDE.md。給 agent 一個真實的問題 -- 你工作上真正需要研究的東西。跑完整個循環：拆解、搜尋、擷取、稽核、綜合。第一次會慢一些，因為你在學 workflow。第二次，你已經有範本和肌肉記憶了。

重點不是 AI 取代你對什麼重要的判斷。重點是研究的機械性部分 -- 找來源、擷取相關段落、追蹤引用、整理筆記 -- 正好是終端裡的 agent 能處理好的結構化重複工作。你的工作變成閱讀、思考、決策。Agent 負責歸檔。

AI agent workflow 的完整全局觀，以及研究如何與程式碼生成、自動化、多 agent 協作並列，請看 AI Agent Workflow 指南。