前言

GMO Connect 的永田。

提案書的製作是不是很痛苦呢？😇

特別是針對官公廳的提案書，依據評估項目的不同，頁數可達數十甚至數百頁，這在所難免。若要使用 PowerPoint 製作，會面臨這樣的苦痛：

• 複製與貼上地獄：重複複製幻燈片並替換正文、調整表格的單元格寬度……這樣做數十次
• 設計崩潰：當頁數超過 30 頁後，字體大小和顏色開始出現不一致
• 版本無法管理：提案書_v3_最終版_真正的最終版_修訂2.pptx
• 檢視困難：無法回答「與上次有什麼變化？」

作為工程師，老實說，這是最不想做的工作之一。

如果只需 撰寫 Markdown，就能自動統一設計，並能透過 git diff 進行檢視，那會是怎樣？

本文將介紹如何利用 Slidev + Claude Opus 4.6 實現此功能，並附上純 Markdown 到完成幻燈片的前後對比。

總結（先說結論）

首先直接告訴你結論。

1. 使用 Slidev + Vue 元件，建立了提案書的「設計系統」
2. 提案內容的撰寫者只需撰寫 Markdown（完全不需寫 HTML 表格，無需 CSS 知識）
3. 與 Claude 的相容性極佳（Markdown 是大型語言模型（LLM）的原生語言，也能穩定生成 Vue 標籤）
4. 可進行 Git 管理的提案書（diff、branch、PR 評閱自然運作）
5. 限制：複雜的圖表或動畫表現不如 PowerPoint（誠實地說）

這次建立的模板的規模感：

Slidev 是什麼

概述

Slidev 是一個基於 Markdown 的簡報框架。它建立在 Vue 3 + Vite 上，具備以下特點：

• 使用 Markdown 撰寫幻燈片
• 透過 Vite 的 HMR（熱模組替換）在每次保存時立即反映預覽
• 可導出為 PDF / PNG / PPTX / SPA（可部署的 Web 應用）
• 本地主題：放置於 layouts/、components/、styles/ 的 Vue 文件被自動註冊

關於 Slidev 的一般介紹，以下文章提供了詳盡的內容。本文將專注於「提案書製作」的具體用例。

與 PptxGenJS 的比較

作為簡報生成的選擇之一，還有 PptxGenJS。這是一個用 JavaScript 生成 .pptx 的庫，也被 Claude 的 Cowork 功能等使用。

當需要 .pptx 原生輸出的時候，PptxGenJS 是最適合的選擇。而對於重視開發體驗（DX）和 Git 管理的情況下，Slidev 更適合。

在本次項目中，由於希望能對 Claude 生成的內容進行 diff 檢視，因此選擇了基於 Markdown 的 Slidev。

實際使用 Slidev 進行製作

架構

此次建立的模板目錄結構如下。
Slidev 的元件不是手動創建的，而是讓 Claude Opus 4.6 對過去的提案書影像進行解析，自動生成的😊

slidev-template/
├── styles/theme.css      # CSS 變數 20+（設計代幣）
├── layouts/              # 6 種佈局
│   ├── cover.vue         # 封面
│   ├── section.vue       # 章節分隔
│   ├── eval-top.vue      # 評估標準表（上部）+ 全幅內容
│   ├── eval-top-2p.vue   # 2 評估項目的同時顯示
│   ├── eval.vue          # 2 段式（側邊面板 + 主面板）
│   └── default.vue       # 全幅 + 標頭列
└── components/           # 15 個元件
    ├── DataTable.vue      # 陣列驅動表格（69 行）
    ├── CompareCards.vue   # A/B/C 比較卡片（31 行）
    ├── PolicyTagMap.vue   # CSS 網格卡片圖（24 行）
    ├── StepFlow.vue       # 流程圖（29 行）
    ├── KpiHighlight.vue   # 大型數字高亮（18 行）
    ├── ChallengeBox.vue   # 題目框型佈局
    ├── PointCallout.vue   # 主要信息強調
    └── ... 其他 8 個

設計的統一透過 CSS 變數（設計代幣）進行管理：

:root {
  --c-navy:        #1B3A5C;   /* 標頭、強調文本 */
  --c-accent:      #B22234;   /* KPI、標籤、徽章 */
  --c-accent-light: #F2D4D7;  /* 評估面板背景 */
  --c-bg-light:    #F5F7FA;   /* 卡片背景 */
  --font-main: "Meiryo UI", "Yu Gothic UI", sans-serif;
}

重點: 撰寫者只需接觸 slides.md 這一個文件。若更改 --c-accent 的一行，所有幻燈片的 PolicyTag、ChallengeBox、徽章顏色將會一起更新。

工作流程：純 Markdown → Claude → Slidev Markdown → 完成幻燈片

這是本文章最想傳達的重點。我們來看看實際的工作流程分為三個步驟。

步驟 1: 工程師撰寫普通 Markdown

工程師使用 普通的 Markdown 撰寫提案內容。無需特別知識。只需以括號或關鍵字提供元件的提示即可。

## 【幻燈片 N】傳統型瀑布模型的問題和階段性轉型

**佈局**: default

### 傳統型瀑布模型的三大問題透過階段性轉型來解決

**傳統的問題**（ChallengeBox）:

傳統的一次性轉型方法存在以下結構性問題：
- 一次性切換所有功能，故障發生時影響範圍廣泛
- 沒有並行運行的時間，撤回判斷的猶豫期極短
- 移轉演練次數有限，本番環境中仍然存在未檢驗的風險

#### 本提案的對應方針

| 問題 | 本提案的做法 | 期待效果 |
|------|--------------|----------|
| **影響範圍擴大** | 依功能群進行階段性轉型以局部化影響 | 限制故障時的影響範圍至 **1/4 以下** |
| **撤回猶豫不足** | 設定 1 個月的並行運行期 | 確保撤回判斷有 **充分的評估期間** |
| **未檢驗的風險** | 在與生產環境相同的環境下進行 2 次移轉演練 | 在正式移轉前 **檢驗所有步驟** |

**重點**: 透過階段性轉型將故障影響局限於 1/4 以下，並透過並行運行 + 兩次演練排除未檢驗風險。

如你所見，這是普通的 Markdown。僅需撰寫元件名稱的提示，如 （ChallengeBox） 及列舉項目、Markdown 表格。完全不需要了解 Vue 元件知識。

步驟 2: Claude Opus 將其轉換為 Slidev Markdown

在讓 Claude 讀入 GUIDE.md（Slidev 模板的使用指南，由 ClaudeOpus 4.6 生成）的狀態下，把上述純 Markdown 傳遞給它，然後它生成以下的 Slidev Markdown：

---
layout: default
section: "組合 1. 問題 → 解決方案模式"
evalBadge: 組合範例
---

### 傳統型瀑布模型的三大問題透過階段性轉型來解決

<ChallengeBox
  lead="傳統的一次性轉型方法存在以下結構性問題："
  :items="[
    '一次性切換所有功能，故障發生時影響範圍廣泛',
    '沒有並行運行的時間，撤回判斷的猶豫期極短',
    '移轉演練次數有限，本番環境中仍然存在未檢驗的風險',
  ]"
/>

<DataTable
  :cols="['問題', '本提案的做法', '期待效果']"
  :colWidths="['20%', '48%', '32%']"
  :boldCols="[0]"
  :accentCols="[2]"
  :rows="[
    ['影響範圍擴大', '依功能群進行階段性轉型以局部化影響', '限製故障時的影響範圍至 <span>&lt;b&gt;</span>1/4以下<span>&lt;/b&gt;</span>'],
    ['撤回猶豫不足', '設定 1 個月的並行運行期', '確保撤回判斷有 <span>&lt;b&gt;</span>充分的評估期間<span>&lt;/b&gt;</span>'],
    ['未檢驗的風險', '在與生產環境相同的環境下進行 2 次移轉演練', '在正式移轉前 <span>&lt;b&gt;</span>檢驗所有步驟<span>&lt;/b&gt;</span>'],
  ]"
/>

<PointCallout text="透過階段性轉型將故障影響局限於 &lt;b&gt;1/4 以下&lt;/b&gt;，並透過並行運行 + 兩次演練排除 &lt;b&gt;未檢驗風險&lt;/b&gt;." />

發生了什麼事呢：

• 前部資料自動設定 layout: default、section（標頭）、evalBadge（右上角徽章）
• 列舉項目 → 轉換為 <ChallengeBox> 元件（問題框型佈局）
• Markdown 表格 → 轉換為 <DataTable> 元件（透過 boldCols 指定粗體列，透過 accentCols 指定紅色列）
• **重點**: → 轉換為 <PointCallout> 元件（關鍵信息的強調帶）

Claude 參考 GUIDE.md 判斷該使用哪些元件、props 應傳遞什麼值。工程師只需在純 Markdown 中寫上元件名稱提示，轉換精度便可提高。

步驟 3: Slidev 生成完成的幻燈片

只需撰寫普通 Markdown，便能產生有海軍藍標頭列、紅色徽章、問題框型佈局、裝飾表格和強調信息帶的自動生成幻燈片。

展示案例 1: CompareCards — 3 方式比較 + KpiHighlight

首先是工程師撰寫的普通 Markdown：

### 3 方式的比較研究，選定雲原生運行

比較評估 3 種運行方式，選定在成本、可用性及運行負載的綜合評價下最適合的方式。

#### 比較表（CompareCards，推薦=雲原生）

|  | 傳統型本地運行 | 混合運行 | 雲原生（推薦） |
|---|---|---|---|
| 運行成本 | 年間 1,800 萬日圓 | 年間 1,100 萬日圓 | 年間 580 萬日圓 |
| 故障回應時間 | 平均 4 小時 | 平均 2 小時 | 平均 30 分鐘 |
| 可擴展性 | 手動・2～3 個月 | 部分自動・1 週 | 全自動・即時 |
| 運行人員 | 5 名常駐 | 3 名常駐 | 1 名 + 自動化 |

**KPI**: 運行成本削減效果 → 年間減少 1,220 萬日圓（68%）（約 3.6 人月相當）

這是普通的 Markdown 表格。只是在 （CompareCards，推薦=雲原生） 上給了一些提示。

這經過 Claude + Slidev 後，變成：

自動格式化為三列的卡片，推薦方式顯示海軍藍框 + ★，下方則有大型的 KPI 突出顯示。由 Markdown 表格所想像的外觀大相徑庭。

recommended: true 會自動附加海軍藍框 + ★，KpiHighlight 則自動渲染為大型字體大小的數字和紅色高亮註解。

展示案例 2: eval-top 佈局 + DataTable + PolicyTagMap

接下來是提案書中最常使用的「回答摘要」頁面。工程師撰寫的普通 Markdown 如下：

## 【幻燈片 2】評估標準・回答摘要

**佈局**: eval-top
**評估項目**: 24（加分・10 分）
**評估細節**: 從數據遷移計畫的制定到執行，確保現有數據的整合性，同時將遷移風險降到最低的提案。

**提案的要點**:
- 透過三階段的逐步遷移最小化停機時間
- 使用差分同步確保整合性（實現 RPO=0）
- 透過 2 次遷移演練來排除風險

### 將評估基準的關鍵詞分解，列出對應的回答

| 評估關鍵詞 | 本提案的對應 | 詳細幻燈片 |
|---|---|---|
| **遷移計畫** | 制定三階段的逐步遷移計畫 | 幻燈片 1-2 |
| **數據整合性** | 透過 AWS DMS 的差分同步實現 RPO=0 | 幻燈片 1-3 |
| **遷移風險** | 在生產等效環境中進行二次演練 | 幻燈片 1-4 |

**PolicyTagMap**:

| 關鍵詞 | 詳細幻燈片 | 摘要 |
|---|---|---|
| **逐步遷移** | 幻燈片 1-2 | 透過三階段最小化停機時間 |
| **差分同步** | 幻燈片 1-3 | 確保 RPO=0 的數據整合性 |
| **遷移演練** | 幻燈片 1-4 | 透過兩次演練排除風險 |

僅需通過 **佈局**: eval-top 指定所需的佈局，並以上述 Markdown 表格寫下評估項目信息。**PolicyTagMap**: 則是提示「這個表格需要以卡片型顯示」。

經由 Claude + Slidev 後則變為：

上方顯示評估標準表（自動生成於 YAML frontmatter），中部顯示關鍵詞分解表，下方則是卡片式導航。純 Markdown 的信息量與完成的幻燈片間的視覺差異非常大呢😊

這張幻燈片是透過三層機制達成的：

• 佈局（eval-top.vue）：撰寫前面資料的 YAML 即可自動描繪上方的評估標準表。無需撰寫 HTML 表格
• DataTable（69 行）：只需傳遞數組即會自動生成帶有海軍藍標頭和斑馬條紋的表格，且可透過 boldCols、accentCols 指定列的裝飾
• PolicyTagMap（24 行）：透過 CSS 網格 + 子網格自動排列卡片內的行。無需調整 PowerPoint 內的對齊

附錄：開發體驗的重點

• 熱重載：只需保存 slides.md，便能在 localhost:3030 即時顯示。無需 PowerPoint 的「保存 → 關閉 → 重新開啟」
• A4 縱印刷支援：僅需添加兩行 canvasWidth: 680、aspectRatio: 210/297 + 插入 <PortraitPrint /> 元件即可同時支援螢幕顯示及印刷輸出
• PDF 輸出：透過 npx slidev export slides.md --output proposal.pdf 一鍵完成

總結（重申）

使用 Slidev + ClaudeOpus 4.6，我們建立了提案書的「設計系統」。

• 工程師用 普通的 Markdown 撰寫提案內容
• Claude Opus 將其轉換為 Slidev Markdown（參考 GUIDE.md 選擇適當的元件）
• Slidev 生成 專業的幻燈片
• 所有內容皆可 進行 Git 管理。支持 diff 評閱、branch 並行作業、PR 合併

然而，也有一些限制：

• 複雜的圖表（網絡結構圖、組織圖等）需要在外部生成圖片並插入
• 原生 .pptx 輸出的品質不如 PptxGenJS（Slidev 的 PPTX 輸出將以不可編輯的圖片形式嵌入）
• 模板（佈局 + 元件）的初始構建需具備 Vue / CSS 知識（不過這是一次性的成本）

適合的團隊: 有經常需要以一致格式反覆製作提案書的組織。只要建立一次模板，後續的提案只需撰寫 Markdown 即可。

最後，GMO Connect 提供從服務開發支援到技術支援的廣泛服務，如果有任何需求，請隨時與我們聯繫。

聯繫方式: https://gmo-connect.jp/contactus/

原文出處：https://qiita.com/ntaka329/items/47fb89fb6a84d9976d36