L5-06：Web组件构建器 —— 搭积木一样搭建复杂网页功能

🎯 学什么：用自然语言描述，让 AI 生成独立的、可交互的网页小工具——计算器、诊断器、对比工具、流程图编辑器——像乐高积木一样拼进你的网站。核心洞察：好的 Artifact 不是「万能工具」，而是「专注做一件事且做到极致的小工具」。衡量标准：如果删掉某个功能，Artifact 还能不能正常完成核心任务？如果能——删掉。专注的工具永远比万能工具更有用。 💡 难易度：⭐⭐⭐ | ⏱️ 预计时间：40 分钟

---

1. 课程概览

💡 白话小课堂：想象你要装修厨房。你不需要自己造一个水槽、一个灶台和一个冰箱——你去宜家买成品，回来一拼就行。web-artifacts-builder 就是给你生成这些「厨房组件」——每个都是一个独立可用的网页小工具，直接嵌入你的网站。

来源：Anthropic 官方 Skills 仓库

---

2. Artifact 的四个设计原则

2.1 S-I-P-R 原则

原则 1：Self-Contained（自包含）
  → 单个 HTML 文件包含所有 HTML/CSS/JS
  → 不依赖外部 CDN（零网络依赖）
  → 拖到浏览器就能运行
  → 好处：零部署、零依赖故障、可离线使用

原则 2：Interactive（可交互）
  → 不是静态展示，用户能操作
  → 点击、输入、拖拽、选择、切换
  → 有明确的输入 → 处理 → 输出流程
  → 用户 10 秒内理解「这工具干什么的」、30 秒内能上手

原则 3：Purposeful（有明确目的）⚠️ 最难做到
  → 只做一件事，做到极致
  → 功能膨胀测试：删掉这个功能 → 核心任务还能完成吗？→ 能 → 删掉
  → 「万能工具」= 什么都不精 → 用户每个功能都用不好

原则 4：Responsive（响应式）
  → 桌面端、平板、手机都能正常使用
  → 不是「三个版本」，是一个版本自适应
  → 按钮在手机上要够大（≥ 44px 点击区域）

2.2 什么是好的 Artifact

好的 Artifact 特征：
  ✓ 一个贷款计算器（输入金额/利率/年限 → 输出月供+总利息）
  ✓ 一个肤质诊断器（6 个选择题 → 自动判定 → 产品推荐）
  ✓ 一个产品对比工具（选 2-3 个产品 → 并排对比规格/价格/评价）
  ✓ 一个尺寸推荐器（输入身高/体重/偏好 → 推荐最合适的尺码）

差的 Artifact 特征：
  ✗ 「做一个淘宝首页」——这是完整的电商系统，不是 Artifact
  ✗ 「做一个带用户登录的内容管理系统」——有数据库、后端、多页面
  ✗ 功能描述超过 3 句话还没说完——说明它是一个应用，不是 Artifact

Artifact vs 应用的分界标准：
  → 能否用 3 句话描述完整功能？能 → Artifact / 不能 → 应用 → 拆成多个 Artifact
  → 是否依赖后端数据库？是 → 应用 / 否 → Artifact
  → 是否 ≤ 3 个核心交互？是 → Artifact / 否 → 可能太大了

---

3. 功能膨胀的防范

3.1 为什么最难做到 Purposeful

功能膨胀（Feature Creep）是人的天性：

初始需求：「做一个贷款计算器」
  ↓
「要不要加一个导出 PDF 的功能？」
「再加一个历史记录功能吧？」
「再加一个图表显示还款曲线？」
「再加一个分享到朋友圈的功能？」
「再加一个贷款利率比较？」

每个功能单独看都有道理，加起来这个工具就失去了焦点。

衡量标准：
  如果删掉这个功能，Artifact 还能不能正常完成核心任务？
  → 能 → 删掉
  → 不能 → 保留

以贷款计算器为例：
  → 删掉「导出 PDF」→ 核心任务（计算月供）能完成 → 删掉
  → 删掉「分享朋友圈」→ 核心任务能完成 → 删掉
  → 删掉「月供计算」→ 核心任务不能完成 → 这是唯一必须保留的

3.2 电商 Artifact 的最佳实践

花 80% 的精力想「客户到底卡在哪个决策上」，花 20% 让 AI 生成代码。

三种最适合电商的 Artifact 类型：

类型 1：选购决策器
  → 解决问题：「选项太多不知道该选哪个」
  → 例子：3 个问题判断你适合哪款手机/护肤品/床垫
  → 输入：用户偏好（3-6 个选择题）
  → 输出：1 个推荐产品 + 理由

类型 2：尺寸/用量计算器
  → 解决问题：「怕买错规格」
  → 例子：根据房间大小计算需要多大功率的空调
  → 输入：客观参数（面积/人数/使用频率）
  → 输出：推荐规格 + 预估使用成本

类型 3：对比工具
  → 解决问题：「产品看起来都一样」
  → 例子：并排比较 3 款竞品的规格/价格/评价
  → 输入：用户关心的维度（价格/性能/外观/售后）
  → 输出：加权评分 + 差异高亮

核心原则：
  → Artifact 的任务是「帮助客户更快做决定」
  → 不是「展示所有产品信息」（那是产品页的任务）
  → 工具小但精，用户 10 秒理解、30 秒上手

---

4. 技术栈选择

4.1 为什么选择 React + TypeScript + Vite + Tailwind + shadcn/ui

web-artifacts-builder 针对的是「复杂多组件工件」场景：

简单场景（单文件 HTML）：
  → 一个纯 JavaScript 的计算器
  → 一个静态的展示页面
  → 不需要状态管理、路由、多组件交互

复杂场景（React + TS）：
  → 一个含 5 个 tab 的仪表盘（需要路由/状态管理）
  → 一个多步骤的诊断器（步骤间状态传递、数据验证）
  → 一个含 40+ 组件的交互工具（shadcn/ui 预置组件直接使用）
  → 单文件 HTML 无法维护这种复杂度

技术栈优势：
  → React 18：组件化 + Hooks 状态管理
  → TypeScript：类型安全（复杂工具更需要）
  → Vite：秒级热更新开发体验
  → Tailwind CSS：原子化样式，不用写 CSS 文件
  → shadcn/ui：40+ 预置组件 + Radix UI 无障碍支持

4.2 何时用简单方案、何时用复杂方案

用单文件 HTML（不需要 web-artifacts-builder）：
  → 单个简单计算器
  → 静态信息展示
  → 不超过 3 个交互元素

用 web-artifacts-builder（React + TS）：
  → 多步骤交互流程
  → 需要状态管理（用户输入跨多个组件共享）
  → 需要路由（tab 切换、流程步骤跳转）
  → 需要 3+ 个 shadcn/ui 组件

---

5. 结构拆解：Web 工件构建型 Skill 模板

---

6. 电商案例：商品规格选择器组件

某服装品牌天猫旗舰店（主营羽绒服）的产品详情页存在一个严重的转化瓶颈——规格选择器（颜色 + 尺码 + 厚度）是三个独立的下拉框，互不联动。用户选了「黑色」+「XL」后发现这个组合没有库存，需要退回重选，来回复选 3-4 次后直接跳出。详情页加购率仅 3.1%，远低于品类平均 5.5%。

用 web-artifacts-builder 构建了一个「颜色/尺码/厚度三维联动选择器」组件，嵌入详情页替换原生下拉框。

功能设计（3 句话描述）： 「用户依次点击颜色色块、尺码方块、厚度标签三个维度选择商品规格，每一步选择后实时过滤不可用的后续选项（灰色置灰+划线），防止用户选到无库存的组合。」

交互流程：

Step 1：颜色选择——8 个圆形色块横向排列（已售罄的颜色标灰+斜线），点击任一可用色块 → 进入尺码选择
Step 2：尺码选择——5 个方形尺码块（S/M/L/XL/XXL），根据 Step 1 所选颜色的库存自动置灰无货尺码
Step 3：厚度选择——3 个标签（轻薄款/标准款/加厚款），根据前两步组合自动置灰不可用厚度
Step 4：确认——实时显示「已选：黑色 · XL · 加厚款」+ 库存剩余提示（「仅剩 3 件」）+ 加入购物车按钮

技术实现：

• 单文件 HTML（自包含，直接嵌入详情页自定义模块）
• 库存矩阵数据通过 JSON 配置驱动（sku_matrix.json），运营可直接修改无需开发
• 颜色块使用 CSS appearance: none 自定义 radio button 样式
• 尺码/厚度过滤使用纯 JavaScript 的 Array.filter() 实时计算，零框架依赖
• 移动端：色块和尺码块增大至 48×48px（拇指点击区域 ≥ 44px）

效果：

• 嵌入后，详情页「加入购物车」按钮点击率从 3.1% 提升到 5.7%（+84%）
• 规格选择后退率（选择后又取消重选的次数 / 总选择次数）从 42% 降至 6%（因为不可用组合直接被置灰，用户不会选到无库存组合）
• 平均选择完成时间从 18 秒降至 7 秒（直观的色块点击 vs 下拉框翻找）

🔑 启示：电商 SKU 选择器的本质不是「展示所有选项」而是「防止用户选错」。三维联动的核心价值不是看起来更炫，而是每一步帮用户排除不可能的组合——用户从 120 个理论组合（8 色×5 码×3 厚）中，只需要关注「当前还能选的那几个」。工具小但精——10 秒理解、30 秒上手。

---

7. 掌握检验

Q1：一个合格的 Artifact 必须满足哪四个设计原则？

• A) Scalable, Integrated, Public, Responsive
• B) Self-Contained, Interactive, Purposeful, Responsive
• C) Simple, Inexpensive, Pretty, Reliable
• D) Secure, Isolated, Private, Robust

Q2：以下哪个最像一个好的 Artifact，哪个最不像？请分别说明理由。

• A) 一个完整的淘宝商城系统
• B) 一个嵌入详情页的「肤质诊断器」——6 个选择题 + 自动判定 + 产品推荐
• C) 一个独立运行的 Markdown 在线编辑器
• D) 一个贷款计算器，输入金额/利率/年限，输出月供和总利息

Q3：四个设计原则中，「Purposeful」为什么被课程称为「最难做到的原则」？请用具体例子说明。

Q4：Artifact 与完整网站/应用的区别是什么？如果你发现自己描述的功能超过 3 句话还没说完，你应该怎么做？

Q5：对于电商场景，列出 3 种最适合做成 Artifact 的客户决策辅助工具，并说明每种工具解决的是什么客户痛点。

Q6：为什么 web-artifacts-builder 采用 React + TypeScript + Vite + Tailwind + shadcn/ui 这一技术栈，而非简单的单文件 HTML？

• A) 因为这个技术栈是免费的
• B) 因为 Artifact 需要状态管理、路由和多组件交互——复杂场景下单文件 HTML 难以维护
• C) 因为浏览器只支持 React
• D) 因为 shadcn/ui 有最多的模板

Q7：「Self-Contained（自包含）」原则中，「单个 HTML 文件包含所有 HTML/CSS/JS」有什么实际好处？如果依赖 5 个外部 CDN 会带来什么风险？

---

8. 答案

点击查看答案

Q1：B — Self-Contained（自包含）、Interactive（可交互）、Purposeful（有明确目的）、Responsive（响应式）。

Q2：参考答案 — 最像好的 Artifact：B（肤质诊断器）和 D（贷款计算器）——两者都只做一件事且做到精。最不像：A（完整的淘宝商城）——这是一个完整的电商系统，不是一个 Artifact 而是几十个 Artifact 的组合。

Q3：参考答案 — 「Purposeful」最难做到是因为功能膨胀是人的天性——「再加一个导出 PDF」「再加一个分享」「再加一个历史记录」——每个单独看都有道理，加起来工具就失去了焦点。衡量标准：如果删掉这个功能，Artifact 还能不能正常完成核心任务？如果能——删掉。

Q4：参考答案 — Artifact 是「独立的功能构件」（单一 HTML 文件，一个核心功能，可嵌入任何页面），完整网站/应用是「功能集合体」（几十个页面、数据库后端、用户系统）。如果你描述需求超过 3 句话还没说完，说明它是一个完整应用而不是一个 Artifact——应该把它拆成多个 Artifact。

Q5：参考答案 — (1) 选购决策器（如「我应该选哪款手机」——解决「选项太多不知道选哪个」的决策瘫痪）；(2) 尺寸/用量计算器（如「根据房间大小需要多大功率空调」——解决「怕买错规格」的担忧）；(3) 对比工具（如「这 3 款竞品有什么区别」——解决「产品看起来都一样」的认知模糊）。

Q6：B — web-artifacts-builder 针对的是复杂多组件工件场景（状态管理、路由、多组件交互），不是简单场景。简单场景用单文件 HTML 没问题，但当一个 Artifact 需要 40+ shadcn/ui 组件、React 状态管理、TypeScript 类型安全时，单文件 HTML 会变得不可维护。

Q7：参考答案 — 好处：(1) 零部署——拖到浏览器就能用；(2) 零依赖故障——不会因为 CDN 挂掉而罢工；(3) 可离线使用。5 个外部 CDN 依赖的风险：(1) CDN 故障/不可用 → Artifact 完全失效；(2) CDN 版本更新 → 可能引入不兼容；(3) 加载速度受 CDN 影响；(4) 安全风险——CDN 被劫持可能导致代码注入。

（5/7 通过）

---

9. 延伸阅读

• [[L5-05-主题工厂|上一课：主题工厂]] —— 用主题给 Artifact 一键换肤
• [[L5-07-Web应用自动化测试|下一课：Web应用自动化测试]] —— AI 帮你把网站的每个角落都点一遍