企业官网建设流程全解析

LifeOS Webdesign 技能导出格式全解：从 Claude Design 到生产代码的选型与交付指南

【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS

本指南以 LifeOS 仓库中 ExportFormats.md 为骨架，系统讲解 Webdesign 技能在 Claude Design 产出设计稿后的全部导出路径：内部 URL、Canva、Bundle、独立 HTML、PDF、PPTX、Folder 以及各类平台直推目标。你将掌握每种格式的适用场景与不适用场景、Bundle 交接格式的内部结构与校验方法、token 专属导出命令，以及从导出到生产代码（ExportToCode → DeployDesign）的完整落地链路。

导出格式速查表

Claude Design 的导出选择器提供多种格式，Webdesign 技能用一张决策矩阵来"对号入座"——先问"导出的下一步是什么"，再选格式：

2026 年 6 月更新：新增平台直推目标

根据 ClaudeDesignCapabilities.md 的记录，2026 年 6 月的更新扩展了导出选择器，新增直接目的地：Adobe、Base44、Canva、Gamma、Lovable、Miro、Replit、Vercel、Wix，与 PDF、PPTX 并列。这些平台直推目标适合把设计交给一个非 LifeOS 的工具去消费，例如让营销团队在 Canva 里继续改、让无代码平台直接拉取设计。

注意：对 LifeOS 的代码工作而言，Bundle 导出仍是正确的选择——那些平台目的地是用于交接给 LifeOS 之外的工具的，而不是把代码落进你自己的仓库。代码的归宿应当是 Claude Code，而不是某个第三方画布。

决策树：根据下一步动作选择导出格式

Webdesign 技能把格式选择收敛成一条决策树，核心问题是"导出后的下一步是什么"：

Q: 导出后的下一步是什么？ │ ├─ 评审 / 反馈 → Internal URL │ ├─ 非开发者要编辑 → Canva │ ├─ 生产代码，进入现有应用 → Bundle → IntegrateIntoApp │ ├─ 生产代码，全新独立应用 → Bundle → ExportToCode → DeployDesign │ ├─ 静态一次性页面 → Standalone HTML → DeployDesign │ ├─ 客户演示 → PDF 或 PPTX │ └─ 归档 / 本地保留 → Folder

可以看出，凡是"代码"这条路径，最终都会落到 Bundle——区别只在于是走 IntegrateIntoApp.md（并入现有应用）还是 ExportToCode.md（生成全新应用代码后经 DeployDesign.md 部署）。非代码路径则按消费方能力选择：评审看 URL、非开发者改图用 Canva、对外交付用 PDF/PPTX、纯归档用 Folder。

Bundle 格式（最重要）：代码路径的承重结构

当目标是代码时，handoff bundle（交接包）是整个流程的承重输出。它不是单个文件，而是一个有固定结构的目录：

bundle/ ├── PROMPT.md # 给 Claude Code 的结构化简报 ├── tokens.json # 设计令牌（颜色、排版、间距） ├── preview.html # 静态预览渲染 ├── components/ # 组件脚手架 │ ├── button.tsx │ ├── card.tsx │ └── ... ├── assets/ # 图片、字体、图标 │ ├── logo.svg │ ├── fonts/ │ └── images/ └── README.md # Bundle 元数据

完整规格见 HandoffBundleSpec.md，该规范补充了更多可选成员：pages/（多页面 bundle 的页面脚手架）、integration/（框架专属配置如tailwind.config.ts、astro.config.mjs）、manifest.json（框架 + 版本元数据）。

PROMPT.md——bundle 的心脏

PROMPT.md 包含：

• 项目目的 + 目标受众
• 已选定的美学方向（aesthetic direction）
• 目标框架与约定
• 逐 section 的拆解说明
• 所需组件清单
• 给frontend-design插件的显式指令

当 bundle 被喂给 Claude Code 时，插件首先读取 PROMPT.md，其余一切都是上下文。HandoffBundleSpec 进一步揭示了它的"契约"性质：带 frontmatter + 结构化 Markdown 正文，frontmatter 记录generated_by、generated_at、claude_design_session、framework、design_system、handoff_type（full | partial | token-only）等关键元数据；正文则用固定的章节模板约束下游——Project Purpose、Audience、Aesthetic Direction、Framework Target、Sections、Component Inventory、Integration Notes、Must-Preserve（必须逐字落地的内容）、Must-NOT（明确禁止的模式）。

tokens.json——机器可读的设计令牌

tokens.json 是框架无关的设计令牌 JSON，消费方负责翻译成自己的格式：

{ "color": { "primary": { "50": "#...", "500": "#...", "900": "#..." }, "neutral": { "50": "#...", ...}, "accent": { ...} }, "typography": { "display": { "family": "...", "scale": [...] }, "body": { "family": "...", "scale": [...] }, "mono": { "family": "...", "scale": [...] } }, "spacing": { "unit": 4, "scale": [0,4,8,12,16,24,32,48,64,96] }, "radius": { ... }, "shadow": { ... } }

HandoffBundleSpec 给出了该 schema 的完整形态：包含$schema、version、metadata（名称/来源/生成时间），颜色分为primary、neutral、accent以及语义色semantic.success/warning/error/info；排版分为display、body、mono三族，每族含family、weights、scale甚至lineHeight；间距带unit基准与scale数列；此外还有radius、shadow、motion（时长 + 缓动曲线）。

框架翻译器直接读取这份文件——Tailwind 配置、Styled Components 主题、CSS 自定义属性（custom properties）都从它派生。例如一个 Astro 工程消费 bundle 时，tokens.json 会映射进tailwind.config.ts的 theme 段。这就是"一套令牌，多框架落地"的机制。

Bundle 校验与消费：从目录到生产代码

先校验，再投喂

把 bundle 喂给 Claude Code 之前，先做结构校验。工具是仓库内的 ProcessHandoffBundle.ts：

bun ~/.claude/skills/Webdesign/Tools/ProcessHandoffBundle.ts <bundle-dir>

该校验器检查：

• PROMPT.md存在且包含必需的 frontmatter
• tokens.json可解析且符合 schema
• preview.html存在
• 若存在manifest.json，则声明过的框架文件必须真实存在
• components/中引用的资产在assets/中存在
• 任何文本文件中不得出现密钥或 API key

从源码看（ProcessHandoffBundle.ts），它按扩展名对 bundle 资产做分类：.png/.jpg/.webp/.svg/.avif归入 images（文件名含logo/mark/brand的额外归入 logos），.woff/.woff2/.ttf/.otf归入 fonts，.tsx/.jsx/.vue/.svelte归入 components，.ts/.js/.css/.scss/.html归入 code，README.md/HANDOFF.md/NOTES.md归入 notes。带--brief标志时它会输出一份 Markdown 整合简报，直接可投喂给下一个 agent（frontend-design 插件）：

bun ~/.claude/skills/Webdesign/Tools/ProcessHandoffBundle.ts "$OUT/bundle" --brief > "$OUT/integration-brief.md"

两种消费路径

• 路径 A——全量代码生成（对应 ExportToCode.md 工作流）：把 bundle 喂给 Claude Code，frontend-design插件自动激活，先读 PROMPT.md，再应用 tokens.json，产出生产级代码。生成后必须用 VerifyDesign.ts 截图对比preview.html做视觉保真度校验，并跑--a11y无障碍扫描——critical/serious 级别的问题会阻塞发布。
• 路径 B——并入现有应用（对应 IntegrateIntoApp.md 工作流）：针对目标应用的约定做翻译，产出的是diff（补丁）而不是新文件，尽量复用现有令牌、显式标记冲突。该工作流有严格的门禁：先审计目标工程（framework、tokens、components），再跑ExtractDesignSystem让 Claude Design 吃透应用真实令牌，然后生成 diff 并经过人工评审门禁，最后才在分支上应用、跑测试、在真实页面 shell 中截图验证。

Standalone HTML 导出的注意事项

独立 HTML 导出是单文件，CSS 内联、JS 通常也内联。它适合：

• 静态托管（Cloudflare Pages、Netlify、S3）
• 邮件内嵌的原型
• 一次性落地页

它不适合：

• 集成进基于组件的框架
• 动态内容 / 数据获取
• 多页面站点（没有路由）

凡是超出单页静态页面的需求，一律改用Bundle。ExportToCode 工作流中反复强调：preview.html只是静态的一次性渲染，它不是生产代码，永远要跑真实的框架构建。

Canva 导出的注意事项

Canva 导出产生一个可编辑的 Canva 设计，保留：

• 布局结构（映射为 Canva 图层）
• 排版（映射到 Canva 字体库——可能需要替换）
• 调色板（映射为 Canva 色板）
• 图像（作为上传的 Canva 资产）

选择 Canva 的正确时机：

• 非开发者（营销、创始人、设计师）需要继续细化设计
• 计划打印输出（Canva 支持 CMYK 与出血）
• 设计是社交/营销物料，而不是软件

Canva不适合代码交付：从 Canva 回到代码的往返（round-trip）是有损的。SKILL.md 中的路由规则也印证了这一点——当用户需要非开发者细化设计时，应走ExportToCode工作流的--format canva分支。

PDF vs PPTX：客户交付物的选择

一句话概括：要"锁死外观"选 PDF，要"继续编辑"选 PPTX。

Token-Only 导出：只交接设计系统

当用户要自己手写代码时，可以只导出tokens.json，把实现权留在自己手里：

bun ~/.claude/skills/Webdesign/Tools/DriveClaudeDesign.ts export tokens path/to/out.json

export tokens是 DriveClaudeDesign.ts 支持的导出子命令之一（完整用法见下）。该命令的适用场景：

• 开发团队更愿意自己写组件
• 你只需要确立设计系统，不需要实现
• 集成是 token 级别的（见IntegrateIntoApp.md的mode: token-only模式——该模式只更新tokens.json/ tailwind 配置）

格式组合：一个产物，多种导出

有时一个设计需要同时产出多种格式以服务不同干系人：

多个导出命令按顺序依次执行即可——Claude Design 会按需重新渲染每种格式。这与DriveClaudeDesign.ts的驱动方式一致：每次 export 都是独立的"点击导出按钮 → 等待下载 → 移动到输出目录"循环。

导出命令的底层实现：DriveClaudeDesign.ts

所有导出动作的底层驱动是仓库中的 DriveClaudeDesign.ts，它是一层"薄薄的 Interceptor 包装"，通过可访问性树（accessibility tree）启发式来定位 claude.ai/design 界面上的控件：

Usage: DriveClaudeDesign.ts open | prompt "<brief>" | screenshot <out-path> DriveClaudeDesign.ts export <html|pdf|pptx|canva|url> <out-dir> DriveClaudeDesign.ts bundle <out-dir> Prereqs: `interceptor` 在 PATH 上，且存在已认证的 claude.ai 会话。

关键实现细节：

• 前置依赖：interceptorCLI 必须在 PATH 上（resolveInterceptorBin），否则退出码 127；同时需要已登录的 claude.ai 会话。
• 导出流程：commandExport先在可访问性树中找/export/i按钮并点击，等待 500ms 让菜单打开，再匹配包含目标格式文本的菜单项，点击后等待下载，最后从~/Downloads取最近 10 秒内的新文件移动到输出目录（commandExport）。
• Bundle 导出：commandBundle匹配Claude Code|handoff|Send to Claude等文案点击交接按钮，下载最近 20 秒内的 ZIP，解压到目标目录（commandBundle）。

在 ExportToCode 工作流中，实际使用的导出命令是：

OUT="${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/webdesign/export/$(date +%Y%m%d-%H%M%S) mkdir -p "$OUT" bun ~/.claude/skills/Webdesign/Tools/DriveClaudeDesign.ts export bundle "$OUT/bundle"

需要强调的前提：Webdesign 技能共有三条路径，本导出格式体系属于Path 3（ClaudeDesign via Interceptor）。SKILL.md 明确标注该路径是实验性的（experimental visual-review fallback）：要求interceptor-testChrome 配置已登录 claude.ai，且从未完整端到端跑通过。对代码绑定型工作，SKILL.md 的当前建议是优先使用原生/design与/design-sync命令（Path 2），Bundle 交接体系是从 web 画布出发时的回退方案。理解这一点，才能正确评估上述命令的适用前提。

常见陷阱与最佳实践

综合 ExportFormats 文档与 ExportToCode.md、IntegrateIntoApp.md 的实践沉淀，导出环节最常见的失误有：

1. 跳过ProcessHandoffBundle：直接把原始 bundle 读给 frontend-design 插件虽然也能工作，但会丢失结构化简报。总是先生成 brief。
2. 框架不匹配：bundle 是为 React 导出的，却喂给 Astro 工程，结果必然漂移。用正确的框架重新导出，或用IntegrateIntoApp做翻译。
3. 把 preview.html 当生产代码：它是静态一次性渲染，不是生产代码，永远要跑真实框架构建。
4. 不做验证："应该能跑"的导出代码常有隐蔽问题（缺依赖、坏导入、a11y 回归），交接下游之前必须用VerifyDesign.ts验证。
5. 导出前先做设计系统提取：新代码库要让 Claude Design 先跑ExtractDesignSystem，否则它用通用默认值覆盖你的令牌——这也是 SKILL.md 强调的"对 token 烧损最高杠杆的解法"。

时间预估

• Bundle 解析 + 插件交接：2–5 分钟
• 追加验证与 a11y 检查：2–10 分钟
• 单组件/单页面的应用集成（IntegrateIntoApp）：15–45 分钟；复杂多路由集成应拆成多次会话，一次一个集成目标。

延伸阅读

• HandoffBundleSpec.md——bundle 目录结构的完整规范、tokens.json/manifest.json 全量 schema、框架专属脚手架对照表与版本策略
• ExportToCode.md——bundle → 生产代码的完整工作流（解析、投喂插件、验证、a11y 门禁）
• IntegrateIntoApp.md——bundle 并入现有应用的 diff 化集成流程与 merge/replace/token-only 三种模式
• DeployDesign.md——生成代码部署到 Cloudflare Pages/Vercel/Netlify/GitHub Pages/S3 的逐宿主命令与回滚方案
• ClaudeDesignCapabilities.md——Claude Design 的能力边界、访问层级与 2026 年 6 月更新内容
• SKILL.md——三条路径（DirectDesign / 原生 CLI / ClaudeDesign）的路由规则与全部前置条件

【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS