06 · 匯出、交付與版本管理

產物落在你的專案目錄裡。這句話前面說過幾次，這一篇講它的實際後果。

匯出格式

格式	適合	代價
HTML（素材內聯）	單檔案分享、存檔、直接部署	檔案大，圖片是 base64
PDF	審批、留檔、投影備份	動效和互動沒了
PPTX	交給用 PowerPoint / Keynote 的人	複雜視覺轉換會退化
MP4	影片類產物	不可編輯
ZIP	完整資產打包	對方要自己組裝
Markdown	內容層面的交接	視覺全丟
原始檔	交給工程接著寫	需要對方有開發環境

PPTX 那件事值得單說

大多數「HTML 轉 PPT」的工具做的是把頁面拍扁成圖片，一頁一張。你拿到的 .pptx 開啟是六張圖片，一個字都改不了。

OpenDesign 的 pptx-generator 走的是另一條路：原生形狀和可編輯文本，還有一套 HTML 到 PPTX 的保真度審計。

但要有正確預期：

能過去	過不去
文本（保持可編輯）	Three.js 場景
基本形狀和佈局	依賴 JS 的互動
圖表	CSS 高階特性（複雜遮罩、濾鏡）
圖片	懸停態
配色和字型（字型要對方有）	影片背景

所以如果你知道最終交付物一定是 .pptx，倒推著做會省事：動效那一步少做，別上 3D，把功夫花在排版和圖表上。

git：這套流程最被低估的部分

產物是文本檔案（HTML、CSS、JS、Markdown），所以 git 能真正管住它們。這帶來幾件傳統設計工具做不到的事：

能 diff。 「上一版和這一版差在哪」是可以精確回答的。設計稿的二進位制檔案做不到這一點，你只能靠記憶和截圖對比。

能回滾。 改壞了 git checkout 就回去了。不用「再生成一次，希望這次跟上次一樣」。

能分支。 同一份材料做兩個方向，兩個分支各走各的，最後挑一個。

能評審。 走 PR 流程，評審人能看到具體改了哪一行。

一個實際做法：每一步生成完就提交一次，commit message 寫清楚這一步做了什麼。

git add .
git commit -m "deck: 第一版，按 editorial 參考圖"
git commit -m "deck: 對照參考圖補字號階梯和疏密"
git commit -m "deck: 加真實 logo（3 處）"
git commit -m "deck: 4 張 ECharts，資料來自 Q3 報表"

跑到第 8 步發現動效做過了，git revert 掉那一個 commit 就行，前面的成果全在。

交給工程

如果這份東西要變成生產程式碼，交接方式取決於產物形態：

單檔案 HTML 原型 — 直接給原始檔。工程通常會重寫，但有一個能跑的參照物，溝通成本比給設計稿低一個量級。

帶設計系統的一組頁面 — 把 design-systems/<brand>/DESIGN.md 一起給。裡面的色值、間距、字號階梯可以直接轉成 CSS 變數或者 design token。

要求同構的場景 — 有些團隊直接把生成的 HTML 結構接進模板引擎。這條路要提前跟工程約定好類名規範，在技能的硬約束裡寫死。

部署

HTML 產物就是靜態站點，任何靜態託管都能放：

# 舉例：產物在 ./artifact 目錄
npx wrangler pages deploy ./artifact

託管套餐還包含雲端部署額度（Plus 3 次/月、Pro 20 次/月、Max 50 次/月，超出每次 2 美元），適合要快速給客戶一個連結看的場景。免費版沒有這一項，自己傳靜態託管一樣能用。

存檔

對外用過的東西建議存兩份：

1. 原始檔（在 git 裡）— 以後要改，從這裡改。
2. PDF 或者內聯 HTML — 凍結那一刻的樣子。外部素材會失效，生成的圖會丟，幾個月後開啟原始檔不一定還是當時的樣子。

第二條尤其適用於用了外部 logo 和網圖的材料。

常見坑

坑	表現	怎麼辦
不提交，一路改到底	改壞了回不去	每一步 commit 一次
只留 PDF	要改的時候得重做	原始檔和 PDF 都留
PPTX 期望過高	轉過去一堆東西沒了	提前按 PPTX 的能力倒推著做
內聯 HTML 太大	郵件發不出去	圖片先壓縮，或者改用外鏈 + ZIP
交接只給截圖	工程還得猜間距	把 DESIGN.md 一起給

相關

• PPT 工作坊 · 第 10 步 — deck 的匯出選擇
• 08 · 成本與團隊 — 雲端部署額度在哪一檔