LifeOS Webdesign 实战：用 WebsiteToRedesign 工作流把任意网站改造成现代化设计-育师

LifeOS Webdesign 实战：用 WebsiteToRedesign 工作流把任意网站改造成现代化设计

【免费下载链接】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 中 Webdesign 技能的WebsiteToRedesign工作流——一条"捕获线上页面 → 分析批判 → 生成改造简报 → 交给 Claude Design 重建 → 迭代对比 → 落地代码"的完整网站改版流水线。读完本文，你将掌握如何输入一个 URL 与改版方向，产出保留原站结构、换上全新审美的现代化页面，并能熟练调用 DriveClaudeDesign.ts 与 VerifyDesign.ts 两个核心工具完成截图、投喂、迭代、对比与无障碍校验。

工作流定位：改版任务在 Webdesign 技能中的归属

WebsiteToRedesign是 Webdesign 技能提供的多条工作流之一，专用于"把现有线上网站改造成新设计"这类任务。它的典型触发短语包括："redesign this site"、"rebuild this page"、"modernize this URL"、"new look for"、"give this site a facelift"。

在技能的路径体系中，它属于 Path 3（通过 Interceptor 驱动claude.ai/design的可视化画布路线），与CreatePrototype、RefinePrototype、ExportToCode、IntegrateIntoApp、DeployDesign共同构成一套"从概念到生产代码"的管道。需要说明的是：根据 SKILL.md 中的运行记录，Path 3 属于实验性通道，要求本机 Interceptor 可用且interceptor-testChrome 配置档已登录 claude.ai；在未满足前置条件时，文章第 3 节会给出明确的前置检查清单。

工作流的内核可以浓缩为一行：Live URL → capture → critique → modernized rebuild via Claude Design——即"实时网址 → 捕获 → 批判 → 通过 Claude Design 完成现代化重建"。

输入定义：改版前需要准备什么

工作流的输入分为必填与可选两类，缺一不可的是前两项：

类别	字段	说明
必填	URL	要捕获的线上页面地址
必填	Direction（方向）	要改变什么：审美迁移、面向不同受众、全新品牌、或"保留骨架只换外观"（keep-the-bones-fix-the-look）
可选	Preserve list（保留清单）	需要逐字保留的元素/区块（文案、结构、特定组件）
可选	Reference sites（参考站点）	1–3 个"观感"应启发重建的网站 URL
可选	Framework target（框架目标）	重建成果将落地到什么框架

Direction 是决定成败的关键输入。它决定了重建是"换皮"还是"换骨"：仅要求美学迁移时，保留清单可偏向结构与文案；要求全新品牌时，则几乎可以全盘推倒。

捕获现有站点：截图、HTML 快照与设计令牌

第一步是为改版建立"原状基线"。工作流默认把产出存放在$LIFEOS_DOWNLOADS_DIR（缺省为$HOME/Downloads）下的webdesign/redesign/时间戳目录中：

OUT="${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/webdesign/redesign/$(date +%Y%m%d-%H%M%S) mkdir -p "$OUT" # Full-page screenshot —— Interceptor 没有 Tools/ 目录；改用技能 API 调用。 # Skill("Interceptor", "open $URL and capture full-page screenshot to $OUT/original.png") # HTML snapshot curl -sL "$URL" > "$OUT/original.html" # Extract tokens from the live site bun ~/.claude/skills/Webdesign/Tools/VerifyDesign.ts "$URL" "$OUT/original-verify"

三条命令各司其职：

全页截图：通过 Interceptor 技能捕获原站视觉，交给 Claude Design 作为"改版前"参照物。
HTML 快照：curl -sL拉取原始 HTML。工作流的 Common Pitfalls 明确提示"仅用截图不够"——HTML 为 Claude Design 提供了像素推断不出的结构上下文（语义标签、层级、真实文案），截图与 HTML 双通道输入是保证重建不跑偏的关键。
令牌提取：调用 VerifyDesign.ts 对原站做一次冒烟检查。从源码看，VerifyDesign.ts <url-or-path> <out-dir>会通过 Interceptor 打开页面、等待渲染稳定（wait-stable）、截取当前视口图，并默认执行一次基于可访问性树启发式的 a11y 扫描（--a11y|--no-a11y可开关，默认开启）；支持的视口参数为--viewport WIDTHxHEIGHT，宽高均须落在 320–7680 之间，默认1440x900。工具在结束时输出 JSON（url、resolvedUrl、viewport、screenshot、a11y 结果、pass 标志），供后续流程解析。注意其 a11y 检测并非 axe-core 完整实现，源码中明确列出了三项局限：无对比度检查、无动态 aria-live 检查、无 CSS 解析检查。

批判性分析：重建前必须回答的问题

工作流强调批判环节不可跳过。在重新生成之前，先把截图与 HTML 喂给一次快速分析，回答四个问题：

这个页面上什么有效？什么显得过时或千篇一律？访客离开后唯一记住的东西是什么？重建应该保留什么、重新思考什么？

将批判结果写入$OUT/critique.md——Claude Design 会在重建简报中读取它。这一步的意义，工作流的 Common Pitfalls 说得很直白：跳过批判、直接"重建这个"，产出的只是"没有意图的变更"；而批判让重建变得有目的。critique.md 实际上是给下游 Claude Design 的"先验知识"，帮助它区分"这是原站值得保留的设计资产"与"这是需要淘汰的过时痕迹"。

撰写重建简报：给 Claude Design 的完整指令

批判完成之后，组合一份引用原站的重建简报。工作流给出的模板如下：

TASK: Redesign the page currently at $URL. ORIGINAL SCREENSHOT: (attached) $OUT/original.png WHAT TO PRESERVE: $PRESERVE_LIST AESTHETIC DIRECTION: $DIRECTION REFERENCE FEEL (not copy — just mood): $REFERENCE_SITES CONSTRAINTS: - Framework: $FRAMEWORK - Responsive: mobile-first, breakpoints at 640/768/1024/1280 - Accessibility: WCAG 2.1 AA minimum - Dark mode: $DARK_MODE_YN DIFFERENTIATION: The one memorable element: $DIFFERENTIATOR

模板中的每一行都对应一种约束策略，可以结合 InputFormats.md 中的"理想简报五要素"来理解其设计逻辑：

AESTHETIC DIRECTION：必须是一个明确的美学方向（如 brutally minimal、editorial、retro-futuristic、maximalist chaos 等），而非含糊的"好看一点"。InputFormats.md 提供了 12 个方向的美学目录，并警告"混搭两种可以，三种必然糊掉"；同时给出反默认清单：避开 Inter/Roboto/Arial/system-ui-only、紫色渐变白底、过度使用的 Space Grotesk、千篇一律的卡片网格，转而要求"有辨识度的字体配对（点名两种）、主色+锐利强调色（给出 hex 或命名色）、非对称或打破网格的布局、一个编排过的动画时刻"。
REFERENCE FEEL (not copy — just mood)：参考站点只取"情绪"不取"内容"。参考图的最佳实践是：混合来源（网站截图+海报+建筑照片优于三张网站截图）、逐张标注用途（"ref-1 管排版、ref-2 管色板、ref-3 管构图"）、避免 AI 生成的参考图。
CONSTRAINTS：把响应式断点（640/768/1024/1280）、无障碍等级（WCAG 2.1 AA）、深色模式行为显式写死。参考文档强调"视觉不会猜"——若简报不指定断点、对比度与深色模式，Claude Design 会使用默认值，很可能与目标应用不符。
DIFFERENTIATION：唯一令人难忘的元素，是让结果"不像模板"的核心。InputFormats.md 提供了正反例：如"超大页码从每个 section 左缘出血"（差异化成功）对比"欢迎回来式装饰"（失败）。

另外，InputFormats.md 给出了简报长度甜区：低于 50 词会产出泛化默认，100–300 词是甜区，超过 500 词 Claude Design 开始忽略部分内容；超长简报应拆成"先原型、后细化"两阶段。

提交给 Claude Design：DriveClaudeDesign 工具实操

简报就绪后，通过工具驱动 claude.ai/design：

bun ~/.claude/skills/Webdesign/Tools/DriveClaudeDesign.ts open bun ~/.claude/skills/Webdesign/Tools/DriveClaudeDesign.ts upload "$OUT/original.png" bun ~/.claude/skills/Webdesign/Tools/DriveClaudeDesign.ts prompt "$(cat $OUT/brief.md)"

从 DriveClaudeDesign.ts 源码可以看出它是 Interceptor 的薄封装：

open：执行interceptor open https://claude.ai/design打开设计画布。
prompt：先获取当前页面的可访问性树（interceptor tree --json），用"响亮可访问性树启发式"定位输入框——优先找带 ref 且role === "textbox"或contenteditable === true的节点，找不到就把整棵树 dump 到/tmp/claude-design-tree-<时间戳>.json并退出；定位后用interceptor type输入简报，再从按钮列表里按/send|submit|arrow/i正则找发送按钮（单按钮界面退化为唯一按钮），最后click发送。这意味着按钮位置变化不是障碍，工具始终按无障碍语义而非坐标定位。
前置要求：interceptor在 PATH 上，且存在一个已认证的 claude.ai 会话（源码在找不到 interceptor 时以退出码 127 报错并提示先安装 Interceptor 技能）。

值得留意的是，工作流文档中出现的upload动词在工具源码的main()分发中并未实现（支持 open/prompt/screenshot/export/bundle），这从侧面印证了该通道的实验性质；实际执行时应以源码确认的能力为准，必要时改为通过prompt携带路径说明。

迭代：用 RefinePrototype 打磨细节

第一版原型很少一次到位，工作流第 5 步要求进入 RefinePrototype 工作流进行迭代。文档给出的常见改版迭代指令都是具体而边界明确的：

"Keep the headline copy verbatim — only restyle"（标题文案逐字保留，只换样式）
"The hero felt too wide — constrain to max-w-6xl"（hero 太宽，约束到 max-w-6xl）
"Bring the testimonial section closer to the features"（把推荐语区块挪近特性区）
"The CTA color isn't working — try warmer"（CTA 颜色不对，换更暖的）

RefinePrototype 提供了四种细化模式：内联评论（元素级外科手术）、直接编辑（文案微调）、调节旋钮（间距/颜色/布局/字号，实时非破坏）、对话式提示（结构性变更）。实践优先级是：旋钮优先（最快且可回退），结构性变更才用对话提示。细化请求同样要具体："减少 hero 内边距 30%"优于"紧凑一点"；"Playfair Display 做标题、正文不动"优于"更好的字体"。若连续 5 轮以上细化仍不收敛，说明原始简报就有问题，应从 CreatePrototype 用更锐利的简报重来，而不是"细化到对的答案"。

并排对比：改造前后验收

导出前必须捕获新设计并做并排对比：

bun ~/.claude/skills/Webdesign/Tools/DriveClaudeDesign.ts screenshot "$OUT/redesigned.png" bun ~/.claude/skills/Webdesign/Tools/VerifyDesign.ts --compare "$OUT/original.png" "$OUT/redesigned.png" "$OUT/compare"

VerifyDesign.ts的--compare模式把original.png与redesigned.png合成对比目录，供人工目检。除此之外，VerifyDesign.ts还能在集成后对渲染中的真实应用做截图+a11y 冒烟检查——这是工作流链条上"输出保真 ≠ 生产就绪"的兜底闸门（见 SKILL.md 的 Gotchas：Claude Design 产出的是打磨过的视觉效果，但交接代码常常需要验证与无障碍补课）。

导出与集成：让改版落地

工作流第 7 步根据部署目标分叉：

替换现有站点→ 走 IntegrateIntoApp.md：把原型以框架感知的 diff而非绿地脚手架的形式落进现有应用。其流程是：审计目标项目（package.json探测框架、tailwind.config.*/tokens.*/theme.*/variables.css抓取既有令牌）→ 先运行 ExtractDesignSystem 让 Claude Design 用应用真实令牌而非自造色板 → 撰写集成简报（硬约束：不得发明新颜色、匹配既有组件模式、遵循路由约定）→ 用frontend-design插件做框架翻译 →diff -urN生成 patch →人工审阅 diff 闸门→ 切分支patch -p1应用 →bun dev起服务用 VerifyDesign 验证上下文渲染 →bun test && bun run typecheck && bun run lint跑全套回归。集成模式有三种：merge（默认，新增为主）、replace（显式授权后覆盖范围内路由）、token-only（只更新 tokens.json/tailwind 配置）。
绿地重建→ 先走 ExportToCode.md 再走 DeployDesign：DriveClaudeDesign.ts export bundle "$OUT/bundle"导出交接包（含PROMPT.md、tokens.json、components/、assets/、preview.html），用ProcessHandoffBundle.ts解析出结构化简报，交给frontend-design插件生成生产级代码，最后对localhost起服务做截图像素对比与 a11y 门禁。

需要提醒的是，两份工作流文档都明确标注：若本机可用原生/design-sync命令，优先走 Path 2（NativeDesignSync），交接包路径是 Path 3 的实验性回退。具体导出格式的选择矩阵（Internal URL / Canva / Bundle / HTML / PDF / PPTX / Folder / 平台直推）可查阅 ExportFormats.md。

工作流输出清单

一次完整的单页改版会产出以下可交付物：

$OUT/original.png、$OUT/original.html—— 捕获的原始状态（视觉 + 结构双基线）
$OUT/critique.md—— 重建前的批判分析
$OUT/brief.md—— 交给 Claude Design 的重建简报
$OUT/redesigned.png—— 最终原型截图
$OUT/compare/—— 前后并排对比
导出产物（bundle 目录 / HTML / URL）

常见陷阱与避坑清单

工作流文档总结了四条高频失败模式，全部可以在仓库文档与源码中找到对应依据：

跳过批判—— 直接"重建这个"只会产生无意图的变更；批判让重建有目的（对应工作流第 2 步）。
保留过多—— 如果保留清单里什么都有，那就是刷漆而不是改版。最多挑 2–4 个元素进入保留清单。
只用截图—— 截图配 HTML 双输入，才能给 Claude Design 像素推断不出的结构上下文（对应第 1 步的curl -sL快照）。
参考抄袭—— 参考站点提供的是情绪而非内容；如果改版结果像参考站，那就失败了（对应简报中的REFERENCE FEEL (not copy — just mood)措辞）。