用 AI CLI Agent 建構提案自動生成管線

結論先講

你可以建一條終端管線：讀取 RFP、將需求比對到過去成功提案資料庫、產出聽起來像你們組織語氣的初稿、再匯出 markdown、PDF 和 DOCX -- 全程不到五分鐘。這篇文章完整說明：提案資料庫結構、CLAUDE.md 設定、生成腳本，以及格式轉換步驟。

問題：每份提案都從頭來過

你的團隊過去三年贏了幾十個標案。在共享雲端和 email 附件的某個角落，你有曾經得標的執行摘要、技術方法評分優良的段落、評審特別圈出來的過去績效敘述。但每當週一早上收到新的 RFP，總有人打開空白文件開始敲字。

數字很可預測。任何提案大約 60% 是可重複利用的內容：公司概述、團隊資歷、方法論描述、合規對照表、過去績效引用。另外 40% 才是需求導向的：量身定做的技術方法、特定的人力配置計畫、對應工作說明書的報價。但團隊把 80% 的時間花在那 60% 已經存在某處的內容上，因為找到它、改寫它比重寫還難。

這不是寫作問題。這是一個檢索問題，上面黏了一個格式問題。內容已經存在。挑戰在於把它對應到新需求，再重塑成不同的格式、頁數限制和評分標準。

具體情境：SaaS 廠商評估 RFP

用真實流程來說明。你的公司提供雲端基礎架構顧問服務。某中型企業發出一份 RFP，需要夥伴評估五個企業級 SaaS 平台、推薦候選名單、並管理採購流程。

RFP 規定：

• 第一章：執行摘要（最多 2 頁）
• 第二章：需求理解（5 頁）
• 第三章：技術方法與方法論（10 頁）
• 第四章：過去績效 -- 三個相關專案（每個 3 頁）
• 第五章：團隊資歷與關鍵人員（5 頁）
• 第六章：報價（獨立卷冊）
• 繳交格式：PDF，附可編輯的 DOCX 副本

你以前贏過類似的案子。兩份 SaaS 評估提案、一份 ERP 廠商遴選、還有幾份一般 IT 顧問案。原始素材都在。管線要做的是找到它、改寫它、包裝它。

架構：資料庫、上下文、生成、匯出

管線分四個階段：

1. 提案資料庫 -- 過去提案的結構化目錄，按類型和章節標記
2. 上下文組裝 -- CLAUDE.md 編碼組織語氣、制式內容和資料庫索引，讓 agent 知道手上有什麼
3. 需求比對生成 -- agent 讀取 RFP、辨識哪些章節對應哪些資料庫條目、產出草稿
4. 格式匯出 -- Pandoc 把 markdown 草稿轉成 PDF 和 DOCX

每個階段是獨立步驟。你可以分別執行、檢查中間產出、在不從頭來過的情況下重跑任何一步。

第一階段：建立提案資料庫

資料庫是一個目錄樹。每份過去提案有自己的資料夾，章節拆成獨立的 markdown 檔案，加上一個描述提案內容的 metadata 檔。

proposals/
  library/
    2025-saas-assessment-acme/
      metadata.yaml
      executive-summary.md
      technical-approach.md
      past-performance.md
      team-qualifications.md
    2025-erp-selection-globex/
      metadata.yaml
      executive-summary.md
      technical-approach.md
      past-performance.md
      team-qualifications.md
    2024-it-advisory-initech/
      metadata.yaml
      executive-summary.md
      technical-approach.md
      past-performance.md
    templates/
      executive-summary-template.md
      compliance-matrix-template.md

metadata 檔案是讓檢索生效的關鍵：

# metadata.yaml
project_name: "SaaS Platform Assessment for Acme Corp"
client: "Acme Corporation"
date: "2025-06-15"
outcome: "won"
contract_value: "$340,000"
type: "saas-assessment"
tags:
  - vendor-evaluation
  - saas
  - procurement
  - cloud
sections:
  executive-summary:
    page_limit: 2
    score: "outstanding"
    evaluator_feedback: "Clear value proposition, specific metrics"
  technical-approach:
    page_limit: 8
    score: "good"
    evaluator_feedback: "Thorough methodology, would benefit from more detail on scoring criteria"
  past-performance:
    relevance: "high"
    projects_cited: 3

兩件事很重要。第一，來自過去評審的章節層級回饋。當 agent 生成新的執行摘要時，知道評審讚賞「specific metrics」代表 agent 會優先放入量化數據。第二，outcome: won 欄位。資料庫應該只放成功提案 -- 至少 agent 應該給贏過的提案更高權重。

把現有提案轉成這個格式是一次性投資。叫 Claude Code 來做：

claude -p "Read the PDF at ./raw-proposals/acme-saas-2025.pdf. \
Break it into sections (executive summary, technical approach, \
past performance, team qualifications). Save each section as a \
separate markdown file in proposals/library/2025-saas-assessment-acme/. \
Create a metadata.yaml with the project details." \
--allowedTools "Read,Write,Bash"

每份過去提案重複一次。10 份提案的資料庫大約花 30 分鐘建立，而且只需要做一次。往後每次得標再把新提案加進去。

第二階段：用 CLAUDE.md 當組織記憶

CLAUDE.md 把 Claude Code 變成一個懂你組織的提案撰寫者。這是上下文層 -- 它編碼 agent 需要的一切資訊，那些 RFP 和資料庫檔案裡沒有的東西。

## Role
You are a proposal writer for [Company Name], a cloud infrastructure
consulting firm. You write in a professional but direct tone. Avoid
buzzwords. Prefer concrete metrics over vague claims. When citing past
performance, include contract value, duration, and measurable outcomes.

## Organization Facts
- Founded: 2018
- Employees: 85 (42 technical consultants, 12 project managers)
- Key certifications: AWS Advanced Partner, Azure Expert MSP, ISO 27001
- Win rate (last 12 months): 38% on competitive bids
- Notable clients: [redacted for public proposals, use "a Fortune 500
  financial services firm" pattern]

## Proposal Library
Past successful proposals are in proposals/library/. Each has a
metadata.yaml with project details, outcome, and evaluator feedback.
When generating new proposal sections:
1. Search the library for proposals with matching tags
2. Prioritize sections that scored "outstanding"
3. Adapt language and specifics -- never copy verbatim
4. Preserve the structural patterns that evaluators praised

## Writing Style Rules
- Active voice. "We will conduct" not "An assessment will be conducted."
- Quantify everything. "Reduced procurement cycle by 34%" not "Significantly
  improved procurement timelines."
- One idea per paragraph. Evaluators skim. Make it easy.
- Section headers must mirror the RFP's section titles exactly.
- Compliance matrix: every "shall" statement in the RFP gets a row with
  proposal section reference and compliance status.

## Format Constraints
- Body text: 11pt, single-spaced
- Margins: 1 inch all sides
- Headers: bold, 13pt
- Page numbers: bottom center
- These will be applied during Pandoc export. In markdown, focus on content.

這個 CLAUDE.md 的功能類似 RAG 知識層。不是從向量資料庫檢索，而是 agent 讀取資料庫索引和 metadata 檔案來找相關的過去提案。結構化的 metadata 代表 agent 可以按類型（saas-assessment）、標籤（vendor-evaluation）和品質（score: outstanding）來比對。這比架設完整的檢索管線簡單得多，對 10-50 份提案的資料庫來說，整個索引放得進 context window，運作穩定。

第三階段：生成腳本

以下是讀取 RFP 並產出提案草稿的腳本。

#!/bin/bash
set -euo pipefail

# ── 設定 ─────────────────────────────────────────────────────
RFP_FILE="${1:?用法: ./generate-proposal.sh <rfp-file>}"
PROJECT_NAME="${2:?用法: ./generate-proposal.sh <rfp-file> <project-name>}"
OUTPUT_DIR="./proposals/drafts/$PROJECT_NAME"

mkdir -p "$OUTPUT_DIR"

# ── 步驟一：RFP 分析 ────────────────────────────────────────
echo "[1/4] 分析 RFP 需求..."
claude -p "
Read the RFP document at $RFP_FILE. Extract:

1. All required proposal sections with page limits
2. Every 'shall' statement (mandatory requirements)
3. Evaluation criteria and their weights
4. Submission format requirements
5. Key dates (questions deadline, submission deadline)
6. Any special instructions or restrictions

Output as JSON with keys: sections, requirements, eval_criteria,
format_requirements, key_dates, special_instructions.

Use extended thinking to ensure no requirements are missed.
" --output-format json > "$OUTPUT_DIR/rfp-analysis.json"

echo "  RFP 分析已儲存。"

# ── 步驟二：資料庫比對 ──────────────────────────────────────
echo "[2/4] 比對需求與提案資料庫..."
claude -p "
Read the RFP analysis at $OUTPUT_DIR/rfp-analysis.json.
Read all metadata.yaml files in proposals/library/.

For each required proposal section, identify:
1. Which past proposals have relevant content (match by type and tags)
2. Which specific sections scored highest with evaluators
3. What gaps exist (sections with no library match)

Output as JSON with keys: section_matches (array of {section, matches,
best_source, confidence}), gaps (array of sections needing original content).
" --output-format json > "$OUTPUT_DIR/library-matches.json"

echo "  資料庫比對完成。"

# ── 步驟三：章節生成（平行） ────────────────────────────────
echo "[3/4] 生成提案章節..."

# 從 RFP 分析讀取章節清單
SECTIONS=$(claude -p "
Read $OUTPUT_DIR/rfp-analysis.json. List only the section names,
one per line, no numbering.
" 2>/dev/null)

# 平行生成每個章節
PIDS=()
while IFS= read -r section; do
  slug=$(echo "$section" | tr '[:upper:]' '[:lower:]' | tr ' ' '-')

  claude -p "
You are writing the '$section' section of a proposal for $PROJECT_NAME.

Context:
- RFP analysis: $OUTPUT_DIR/rfp-analysis.json
- Library matches: $OUTPUT_DIR/library-matches.json
- Past proposals: proposals/library/

Instructions:
1. Read the library matches for this section
2. Read the best-matching past proposal sections
3. Generate a new section that:
   - Addresses every requirement from the RFP relevant to this section
   - Adapts language and structure from the highest-scoring past sections
   - Includes specific metrics and past performance data
   - Stays within the page limit specified in the RFP
4. Use extended thinking to plan the section structure before writing

Output as markdown. Start with the section heading.
" > "$OUTPUT_DIR/${slug}.md" &

  PIDS+=($!)
done <<< "$SECTIONS"

# 等待所有章節完成
for pid in "${PIDS[@]}"; do
  wait "$pid"
done

echo "  所有章節已生成。"

# ── 步驟四：組裝與轉換 ─────────────────────────────────────
echo "[4/4] 組裝最終文件..."

# 合併所有章節為一個 markdown 檔
claude -p "
Read all .md files in $OUTPUT_DIR/ (exclude any non-section files).
Combine them into a single proposal document in the order specified
by $OUTPUT_DIR/rfp-analysis.json.

Add:
- A title page with project name, your company name, and today's date
- A table of contents
- Section dividers
- Page break markers (use \pagebreak for Pandoc)

Write the assembled document to $OUTPUT_DIR/proposal-complete.md
"

echo "  組裝完成。"
echo ""
echo "草稿已存至 $OUTPUT_DIR/proposal-complete.md"

步驟三的平行生成是真正省時間的地方。一份六章節的提案，每章節需要 30-60 秒生成，依序跑要 3-6 分鐘。平行跑只需要最長那一章的時間 -- 通常不超過 90 秒。

Extended thinking 用在兩個地方：初始 RFP 分析（確保不遺漏需求）和每個章節生成（寫之前先規劃結構）。對於有數十條「shall」條款的複雜 RFP，extended thinking 能抓到單次讀取會漏掉的需求。

第四階段：用 Pandoc 匯出格式

Markdown 草稿需要變成 PDF 和 DOCX。Pandoc 用一個參考文件就能處理兩種轉換，確保排版一致。

# ── 格式轉換 ─────────────────────────────────────────────────

# 建立 Pandoc 參考範本（只需做一次）
# 這會編碼你的排版：字型、邊距、標題樣式
pandoc -o proposals/templates/reference.docx --print-default-data-file reference.docx

# 轉換成 PDF（透過 LaTeX）
pandoc "$OUTPUT_DIR/proposal-complete.md" \
  -o "$OUTPUT_DIR/proposal-complete.pdf" \
  --pdf-engine=xelatex \
  -V geometry:margin=1in \
  -V fontsize=11pt \
  -V mainfont="Times New Roman" \
  --toc \
  --toc-depth=2

# 轉換成 DOCX（使用參考範本）
pandoc "$OUTPUT_DIR/proposal-complete.md" \
  -o "$OUTPUT_DIR/proposal-complete.docx" \
  --reference-doc=proposals/templates/reference.docx \
  --toc \
  --toc-depth=2

echo "已匯出："
echo "  $OUTPUT_DIR/proposal-complete.pdf"
echo "  $OUTPUT_DIR/proposal-complete.docx"

參考 DOCX 範本是一次性設定。用 Word 打開它、設好字型、邊距、標題樣式、頁首頁尾。之後每次 Pandoc 轉換都會繼承那些樣式。這代表你的提案排版跟內容一起版控 -- 不用再問「Acme 那次投標我們用了哪個版本的範本？」

如果 RFP 指定特殊排版（附錄用不同邊距、合規對照表用橫式頁面），把它們編碼成 Pandoc metadata 或 LaTeX 指令放在 markdown 裡。Agent 在組裝階段可以插入 \newpage 和 \begin{landscape} 指令。

完整執行

整條管線跑起來是這樣：

./generate-proposal.sh ./rfps/enterprise-saas-eval-2026.pdf "saas-eval-meridian"

輸出：

[1/4] 分析 RFP 需求...
  RFP 分析已儲存。
[2/4] 比對需求與提案資料庫...
  資料庫比對完成。
[3/4] 生成提案章節...
  所有章節已生成。
[4/4] 組裝最終文件...
  組裝完成。

草稿已存至 ./proposals/drafts/saas-eval-meridian/proposal-complete.md
已匯出：
  ./proposals/drafts/saas-eval-meridian/proposal-complete.pdf
  ./proposals/drafts/saas-eval-meridian/proposal-complete.docx

總牆鐘時間：六章節的提案 3-5 分鐘。對比手動流程常見的 2-3 天初稿週期。

產出是初稿，不是最終提交版。資深提案經理仍然需要審查策略定位、驗證過去績效引用、調整報價敘述。但機械性的工作 -- 找到相關的過去內容、改寫制式文字、維持一致語氣、排版 -- 已經完成。

用 Claude Code Skills 編碼提案模式

對於經常回應提案的組織，把管線包裝成 Claude Code Skill 可以跨專案重複使用，不需要每次重新解釋流程。

建立 .claude/skills/proposal-generator.md：

## Skill: Proposal Generator

### Trigger
When the user says "generate proposal" or provides an RFP document
and asks for a proposal draft.

### Steps
1. Read the RFP document the user provides
2. Run RFP analysis: extract sections, requirements, evaluation criteria
3. Search proposals/library/ for matching past proposals
4. Generate each section in parallel, using best-matching library entries
5. Assemble into a single document with title page and TOC
6. Export to PDF and DOCX via Pandoc

### Rules
- Follow all writing style rules from CLAUDE.md
- Never fabricate past performance data. Only cite projects from the library.
- If a section has no library match, flag it as "needs original content"
  and generate a skeleton with placeholders.
- Include a compliance matrix mapping every RFP "shall" to a proposal section.

有了這個 Skill，生成提案變成對話式互動：

> 這是 Meridian SaaS 評估專案的 RFP。
> 幫我生成提案草稿。

Agent 依照 Skill 的步驟、讀取資料庫、產出草稿。不需要手動執行腳本 -- 但腳本仍然可用於批次處理或 CI 整合。

多面板提案審查

生成步驟產出草稿。審查步驟決定它能不能出門。有效的提案審查意味著同時檢查多件事：執行摘要跟技術方法一致嗎？過去績效章節引用的指標跟方法論承諾交付的一樣嗎？合規對照表涵蓋了每一條「shall」嗎？

提案審查的高效佈局：

• 左面板（50%）： 生成的提案草稿，逐章節捲動
• 右上面板（25%）： 原始 RFP，開在評分標準的段落
• 右下面板（25%）： 資料庫中評分「outstanding」的過去提案，用來比對

你讀草稿中的一個段落、瞄右邊確認它有回應 RFP 需求、再瞄下面跟上次得標的結構比較。這種三向比對能抓到依序閱讀會漏掉的不一致 -- 執行摘要承諾「每週進度報告」但方法論章節寫「雙週」。

發現問題就直接改 markdown、重跑 Pandoc 匯出。回饋迴圈很緊：改、匯出、看 PDF、調整。不用等雲端編輯器渲染文件。不會因為別人同時在編輯同一份 Google Doc 而產生版本衝突。

不只是補助提案：這個模式適用的場景

資料庫-比對-生成-匯出的模式適用於任何範本化文件生成：

客戶提案。 顧問公司回應 Request for Proposal。資料庫放過去的得標提案；agent 按產業、服務類型和案件規模比對。

補助申請。 研究團隊申請經費。資料庫放過去的核准提案；agent 把具體目標、方法論和預算說明改寫成新的補助公告格式。

RFP 回應。 政府標案承包商回應招標文件。資料庫把過去績效對應到產業分類碼和合約載具；agent 產出合規的回應，帶上正確的法規引用。

銷售提案。 SaaS 公司回應企業採購問卷。資料庫存放已核准的安全性、合規和整合問題答案；agent 把問題配對到現有核准回應。

每個情境的結構都相同：建立過去成功案例的資料庫、在 CLAUDE.md 編碼組織知識、讓 agent 執行檢索和改寫、匯出成要求的格式。

成本與時間比較

管線不是取代提案團隊。它取代的是他們 60-70% 的前期工作 -- 檢索、改寫和排版，這些消耗天數卻不增加策略價值的工作。團隊專注在真正重要的 30-40%：策略定位、贏面主題、報價策略和主管審查。

開始動手

最小可行設定：

1. 建立資料庫目錄。 把 3-5 份過去得標提案轉成章節式 markdown 格式，附 metadata.yaml 檔。
2. 寫 CLAUDE.md。 編碼你組織的語氣、事實和寫作規則。
3. 跑腳本。 對一份真實 RFP 執行。嚴格審查產出。
4. 迭代 CLAUDE.md。 第一份草稿會顯示缺了什麼規則 -- 加上去再重跑。
5. 安裝 Pandoc。 設定參考 DOCX 範本，套用你的品牌排版。

兩三份提案之後，資料庫夠強到初稿只需要輕度修改，不需要大幅改寫。CLAUDE.md 累積你團隊的提案知識 -- 評審回應什麼、什麼用語得高分、什麼排版錯誤會被扣分。這些機構知識不再只存在某些人的腦袋裡，而是存在一個每次 agent session 都會讀取的檔案中。