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 技能用一张决策矩阵来对号入座——先问导出的下一步是什么再选格式格式何时使用输出类型后续处理Internal URL异步评审、团队反馈可分享的 claude.ai URL无——仅查看Canva协作编辑、营销物料可编辑的 Canva 工程Canva UIBundle生产代码流水线包含 PROMPT.md 资产 脚手架代码的目录frontend-design插件Standalone HTML一次性落地页、静态托管单个index.html 资产极少PDF客户交付物、打印渲染后的 PDF无PPTX幻灯片演示PowerPoint 文件在 PPT/Keynote 中进一步编辑Folder本地文件归档资产目录手动处理Platform handoff直接推送到另一个工具直接导出到 Vercel、Replit、Lovable、Wix、Base44、Gamma、Miro、Adobe该平台自身的 UI2026 年 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_typefull | 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.tsbun ~/.claude/skills/Webdesign/Tools/ProcessHandoffBundle.ts bundle-dir该校验器检查PROMPT.md存在且包含必需的 frontmattertokens.json可解析且符合 schemapreview.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归入 codeREADME.md/HANDOFF.md/NOTES.md归入 notes。带--brief标志时它会输出一份 Markdown 整合简报直接可投喂给下一个 agentfrontend-design 插件bun ~/.claude/skills/Webdesign/Tools/ProcessHandoffBundle.ts $OUT/bundle --brief $OUT/integration-brief.md两种消费路径路径 A——全量代码生成对应 ExportToCode.md 工作流把 bundle 喂给 Claude Codefrontend-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打印就绪文件PDF线性幻灯片开场 → 内容 → CTAPPTX之后要在 PowerPoint/Keynote 中继续编辑的演示PPTX对 Claude Design 产物的高度保真PDF锁定外观导出后可编辑PPTX可修改的幻灯片一句话概括要锁死外观选 PDF要继续编辑选 PPTX。Token-Only 导出只交接设计系统当用户要自己手写代码时可以只导出tokens.json把实现权留在自己手里bun ~/.claude/skills/Webdesign/Tools/DriveClaudeDesign.ts export tokens path/to/out.jsonexport tokens是 DriveClaudeDesign.ts 支持的导出子命令之一完整用法见下。该命令的适用场景开发团队更愿意自己写组件你只需要确立设计系统不需要实现集成是 token 级别的见IntegrateIntoApp.md的mode: token-only模式——该模式只更新tokens.json/ tailwind 配置格式组合一个产物多种导出有时一个设计需要同时产出多种格式以服务不同干系人干系人需要提供的导出开发者 营销Bundle Canva开发者 设计评审Bundle Internal URL客户 开发者PDF Bundle内部演示 后续开发PPTX Bundle多个导出命令按顺序依次执行即可——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 3ClaudeDesign via Interceptor。SKILL.md 明确标注该路径是实验性的experimental visual-review fallback要求interceptor-testChrome 配置已登录 claude.ai且从未完整端到端跑通过。对代码绑定型工作SKILL.md 的当前建议是优先使用原生/design与/design-sync命令Path 2Bundle 交接体系是从 web 画布出发时的回退方案。理解这一点才能正确评估上述命令的适用前提。常见陷阱与最佳实践综合 ExportFormats 文档与 ExportToCode.md、IntegrateIntoApp.md 的实践沉淀导出环节最常见的失误有跳过ProcessHandoffBundle直接把原始 bundle 读给 frontend-design 插件虽然也能工作但会丢失结构化简报。总是先生成 brief。框架不匹配bundle 是为 React 导出的却喂给 Astro 工程结果必然漂移。用正确的框架重新导出或用IntegrateIntoApp做翻译。把 preview.html 当生产代码它是静态一次性渲染不是生产代码永远要跑真实框架构建。不做验证应该能跑的导出代码常有隐蔽问题缺依赖、坏导入、a11y 回归交接下游之前必须用VerifyDesign.ts验证。导出前先做设计系统提取新代码库要让 Claude Design 先跑ExtractDesignSystem否则它用通用默认值覆盖你的令牌——这也是 SKILL.md 强调的对 token 烧损最高杠杆的解法。时间预估Bundle 解析 插件交接2–5 分钟追加验证与 a11y 检查2–10 分钟单组件/单页面的应用集成IntegrateIntoApp15–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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LifeOS Webdesign 技能导出格式全解：从 Claude Design 到生产代码的选型与交付指南
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 技能用一张决策矩阵来对号入座——先问导出的下一步是什么再选格式格式何时使用输出类型后续处理Internal URL异步评审、团队反馈可分享的 claude.ai URL无——仅查看Canva协作编辑、营销物料可编辑的 Canva 工程Canva UIBundle生产代码流水线包含 PROMPT.md 资产 脚手架代码的目录frontend-design插件Standalone HTML一次性落地页、静态托管单个index.html 资产极少PDF客户交付物、打印渲染后的 PDF无PPTX幻灯片演示PowerPoint 文件在 PPT/Keynote 中进一步编辑Folder本地文件归档资产目录手动处理Platform handoff直接推送到另一个工具直接导出到 Vercel、Replit、Lovable、Wix、Base44、Gamma、Miro、Adobe该平台自身的 UI2026 年 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_typefull | 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.tsbun ~/.claude/skills/Webdesign/Tools/ProcessHandoffBundle.ts bundle-dir该校验器检查PROMPT.md存在且包含必需的 frontmattertokens.json可解析且符合 schemapreview.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归入 codeREADME.md/HANDOFF.md/NOTES.md归入 notes。带--brief标志时它会输出一份 Markdown 整合简报直接可投喂给下一个 agentfrontend-design 插件bun ~/.claude/skills/Webdesign/Tools/ProcessHandoffBundle.ts $OUT/bundle --brief $OUT/integration-brief.md两种消费路径路径 A——全量代码生成对应 ExportToCode.md 工作流把 bundle 喂给 Claude Codefrontend-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打印就绪文件PDF线性幻灯片开场 → 内容 → CTAPPTX之后要在 PowerPoint/Keynote 中继续编辑的演示PPTX对 Claude Design 产物的高度保真PDF锁定外观导出后可编辑PPTX可修改的幻灯片一句话概括要锁死外观选 PDF要继续编辑选 PPTX。Token-Only 导出只交接设计系统当用户要自己手写代码时可以只导出tokens.json把实现权留在自己手里bun ~/.claude/skills/Webdesign/Tools/DriveClaudeDesign.ts export tokens path/to/out.jsonexport tokens是 DriveClaudeDesign.ts 支持的导出子命令之一完整用法见下。该命令的适用场景开发团队更愿意自己写组件你只需要确立设计系统不需要实现集成是 token 级别的见IntegrateIntoApp.md的mode: token-only模式——该模式只更新tokens.json/ tailwind 配置格式组合一个产物多种导出有时一个设计需要同时产出多种格式以服务不同干系人干系人需要提供的导出开发者 营销Bundle Canva开发者 设计评审Bundle Internal URL客户 开发者PDF Bundle内部演示 后续开发PPTX Bundle多个导出命令按顺序依次执行即可——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 3ClaudeDesign via Interceptor。SKILL.md 明确标注该路径是实验性的experimental visual-review fallback要求interceptor-testChrome 配置已登录 claude.ai且从未完整端到端跑通过。对代码绑定型工作SKILL.md 的当前建议是优先使用原生/design与/design-sync命令Path 2Bundle 交接体系是从 web 画布出发时的回退方案。理解这一点才能正确评估上述命令的适用前提。常见陷阱与最佳实践综合 ExportFormats 文档与 ExportToCode.md、IntegrateIntoApp.md 的实践沉淀导出环节最常见的失误有跳过ProcessHandoffBundle直接把原始 bundle 读给 frontend-design 插件虽然也能工作但会丢失结构化简报。总是先生成 brief。框架不匹配bundle 是为 React 导出的却喂给 Astro 工程结果必然漂移。用正确的框架重新导出或用IntegrateIntoApp做翻译。把 preview.html 当生产代码它是静态一次性渲染不是生产代码永远要跑真实框架构建。不做验证应该能跑的导出代码常有隐蔽问题缺依赖、坏导入、a11y 回归交接下游之前必须用VerifyDesign.ts验证。导出前先做设计系统提取新代码库要让 Claude Design 先跑ExtractDesignSystem否则它用通用默认值覆盖你的令牌——这也是 SKILL.md 强调的对 token 烧损最高杠杆的解法。时间预估Bundle 解析 插件交接2–5 分钟追加验证与 a11y 检查2–10 分钟单组件/单页面的应用集成IntegrateIntoApp15–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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考