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 · 成本与团队 — 云端部署额度在哪一档