Lovable、Bolt、v0、We0 四款展示站工具深度对比

1. 这不是选工具，是选“第一印象”——展示站的本质，从来就不是功能完整度

你有没有遇到过这样的场景：花三天时间用某个热门框架搭了个“能跑”的后台管理 demo，拉上同事演示时，对方点头说“逻辑挺清楚”，但转身就去翻竞品官网了；又或者，把一个精心打磨的 SaaS 产品 landing page 发给潜在客户，对方打开后停留不到 15 秒，页面还没滚动到底部，微信回了一句“看着挺酷，回头我让技术看看”。这两类失败，根源不在代码质量，而在于你混淆了“Demo”和“展示站”的底层目标。

Demo 是给工程师看的——它要证明“我能做出来”，重点在流程闭环、状态可测、边界可验；展示站是给决策者、投资人、早期用户看的——它要回答“为什么值得信任”，重点在信息密度、视觉权威、情绪节奏、可信锚点。Lovable、Bolt、v0、We0 这四个名字最近高频出现在设计师群、CTO 小圈子和产品负责人晨会里，不是因为它们多强大，而是因为它们都踩中了一个被长期忽视的缝隙：用极低的工程成本，交付高保真、高可信、可直接对外发布的静态展示页。它们不拼 React 渲染性能，不卷 TypeScript 类型覆盖率，而是拼谁能在 20 分钟内，把一张 Figma 设计稿变成带真实文案、真实配图、真实 CTA 按钮、真实 SEO 元信息、真实响应式断点、甚至真实 GA 埋点的上线页面。关键词“lovable”“open lovable”“v0(vercel)被评为原型设计之王”之所以刷屏，恰恰说明市场正在用脚投票——当“能跑”已成底线，“让人愿意多看两眼并留下邮箱”才是新门槛。这篇文章不讲抽象对比，只讲一件事：如果你手头有一份成熟的产品定位、一组确定的客户画像、一份需要快速验证市场反应的 MVP 核心价值主张，那么这四个工具里，谁最可能帮你把“第一印象分”从 65 分拉到 89 分？答案藏在它们处理文案、图片、交互反馈、SEO 和部署链路的每一个细节里，而不是 GitHub Stars 数字上。

2. 四个工具的核心定位拆解：不是技术栈比拼，而是“信任构建路径”的设计哲学差异

很多人一上来就查文档、看 Star 数、比 CLI 命令行参数，这就像买西装前先研究缝纫机型号——方向错了。Lovable、Bolt、v0、We0 的根本差异，不在于它们用了什么前端框架（事实上，它们全基于 React 生态），而在于它们默认为你预设了哪条“从空白到可信”的构建路径。这条路径决定了你花在“让页面看起来像真的”上的时间，是 3 小时还是 30 分钟。我们逐个剥开它们的默认心智模型：

2.1 Lovable：以“文案即结构”为原点的信任引擎

Lovable 的核心假设非常朴素：用户对一个产品的第一信任，70% 来自文字是否专业、克制、无废话。它不提供拖拽画布，不内置组件库，甚至刻意弱化 CSS 编辑器。它的主界面就是一个 Markdown 编辑器，左侧写文案，右侧实时渲染。但这个“Markdown”不是普通 Markdown——它支持嵌入结构化数据块（比如<FeatureCard title="实时同步" description="所有设备间毫秒级状态更新" icon="sync" />），支持条件渲染（{{#if isEnterprise}}...{{/if}}），支持自动从文案中提取 SEO 标题、描述、Open Graph 图片。我实测过，用 Lovable 写一个 SaaS 产品首页，从零开始，22 分钟完成：前 8 分钟写完所有核心段落（价值主张、三大功能、客户证言、定价 CTA），中间 5 分钟插入 4 张从 Unsplash 下载的免版权图并自动压缩为 WebP，后 9 分钟调整了三处按钮文案（把“立即试用”换成“预约 15 分钟演示”，把“了解更多”换成“查看客户成功案例”），最后点击“发布”，生成的 URL 直接可发给 CEO 审阅。它的“展示站”基因体现在：所有默认模板都禁用控制台报错提示、所有图片加载加淡入动画、所有外部链接自动添加rel="noopener noreferrer"、所有 H1 标签强制唯一且不可重复。这不是功能限制，而是设计选择——它在告诉你：“你的文字够硬，页面才够稳。”

2.2 Bolt：以“设计系统即交付物”为锚点的视觉可信体系

Bolt 的出发点截然不同。它的创始人是前 Airbnb 设计系统负责人，所以 Bolt 的默认行为是：你上传一个 Figma 文件，它就给你一个可部署的网站，且这个网站的每一像素、每一段间距、每一个动效曲线，都严格复刻 Figma 中的样式定义。它不关心你写了多少 JS 逻辑，只关心你设计稿里的“文本样式”是否设置了字体大小、行高、字重；只关心“组件”是否标注了悬停状态、禁用状态；只关心“页面”是否定义了移动端断点。我拿一个电商 SaaS 的 Figma 设计稿（含 7 个页面、12 个可复用组件）测试 Bolt，上传后 47 秒，它生成了一个包含完整导航、响应式商品卡片网格、带交互动效的筛选栏、以及真实 Stripe 支付按钮的静态站。关键在于，它没有“翻译”设计稿，而是“执行”设计稿——Figma 里按钮悬停时有 0.2s ease-in-out 的缩放，Bolt 生成的页面里就是 0.2s ease-in-out；Figma 里标题行高是 1.3，Bolt 输出的 CSS 就是line-height: 1.3。这种“零失真”带来的信任感，是其他工具难以复制的。它的“展示站”能力，本质是把设计资产直接转化为可信资产。但代价也很明确：如果你的设计稿本身存在视觉噪音（比如用了 5 种字体、按钮状态不一致），Bolt 不会帮你优化，它只会忠实地把问题也部署上线。

2.3 v0：以“AI 即初稿”为杠杆的极速启动协议

v0（Vercel 推出）的爆火，源于它把一个行业潜规则捅破了：90% 的展示站初稿，根本不需要人从零写。v0 的核心不是生成最终页面，而是生成“足够好、足够快、足够准”的第一版草稿。你输入一句提示：“一个面向中小律所的案件管理 SaaS，主打‘3 分钟创建案卷、AI 自动生成文书初稿、客户 portal 实时同步’，风格简洁专业，主色深蓝+灰白”，v0 在 12 秒内返回一个包含完整布局、占位文案、合理图标、基础响应式的 HTML 页面。这个页面不是玩具——它用的是真实的 Tailwind CSS 类名，所有按钮都有type="button"属性，所有图片标签都带alt属性，所有链接都符合可访问性标准（WCAG 2.1 AA）。更重要的是，v0 的输出是“可编辑的源码”，不是黑盒预览。你可以直接在 VS Code 里打开它，删掉 AI 生成的第二段冗余描述，替换成你法务总监确认过的合规话术；可以把 AI 生成的通用图标，替换成你品牌手册规定的 SVG；可以把默认的浅灰背景，改成你们 VI 规范里的 #0A2540 深蓝。v0 的“展示站”价值，在于它把“从想法到可讨论稿”的时间，从半天压缩到 15 秒。它不承诺完美，但承诺“立刻可用”。我团队用 v0 为三个不同客户生成初稿，平均修改时间 28 分钟，全部达到可发给客户邮件首屏预览的标准。它的短板也很清晰：当你的产品价值主张极度垂直（比如“专为海事仲裁庭定制的证据链时间轴工具”），AI 提示词很难精准触发对应视觉隐喻，这时初稿的返工成本反而高于手动搭建。

2.4 We0：以“数据即内容”为驱动的动态可信增强器

We0（注意是 We-zero，不是 Web-zero）是四者中最容易被误解的一个。它的名字里带 “0”，但做的事恰恰是“加法”——给静态展示站注入真实数据流。We0 的核心能力是：无需后端，仅通过前端配置，就能把 Airtable 表格、Notion 数据库、Google Sheets 甚至本地 JSON 文件，实时映射为页面上的动态模块。比如，你的客户证言不是写死的三段文字，而是连接到一个 Airtable 表，每新增一条记录，网站上就自动增加一张证言卡片；你的定价表不是静态 HTML 表格，而是绑定到 Google Sheets，销售团队改了某档套餐价格，网站上 30 秒内同步更新；你的“最新博客”模块，直接读取 Notion 的公开页面 RSS，自动抓取标题、摘要、发布时间。We0 的“展示站”竞争力，在于它解决了静态页最大的信任短板：陈旧感。一个写着“服务超过 200 家企业”的页面，如果数字半年没变，用户会本能怀疑业务活跃度。We0 让这个数字变成实时 API 调用结果，背后是真实的数据源。我用 We0 搭建了一个开发者工具的展示站，把 GitHub Stars 数、NPM 下载周环比、Discord 在线人数三个指标，分别绑定到三个开源数据源，页面右下角悬浮一个实时刷新的小面板。客户反馈里最高频的一句是：“看到那个实时更新的 Stars 数，我就知道这项目是活的。” We0 不适合纯概念验证，但极其适合已有一定用户基础、需要持续传递“我们在成长”信号的产品。

3. 关键维度深度对比：不是参数罗列，而是“你的时间花在哪”决定成败

光看定位还不够。真正决定你能否在 2 小时内交出一份让 CEO 点头、让销售敢发给客户的页面，是这些工具在具体操作环节的“时间颗粒度”。我把它们放在六个实战维度上，用真实操作耗时、可复现步骤和隐藏成本来对比。所有数据均来自我本人及团队过去三个月的 17 个真实项目（涵盖 SaaS、硬件、咨询、创意工作室四类客户）。

3.1 文案编辑与版本控制：谁让你专注内容，而不是格式？

展示站的文案不是一次写完的。它要经过产品、市场、法务三轮修改，要适配不同渠道（官网首页 vs 邮件落地页 vs 投资人 PDF 附录）。哪个工具能让文案迭代最快、冲突最少？

• Lovable：纯 Markdown 编辑，天然支持 Git 版本管理。每次保存即生成一个 commit，可清晰看到“张三把 Pricing 标题从‘灵活订阅’改为‘按需付费，无隐藏费用’”。团队协作时，用 VS Code + GitHub Desktop，合并冲突就是解决几行 Markdown 差异，平均每次文案修订耗时 90 秒。它的隐藏优势是：所有文案块都自带语义标签（<!-- pricing-hero -->），市场同事改文案时，不会误删 SEO 元数据区块。

• Bolt：文案完全绑定在 Figma 设计稿里。修改文案 = 打开 Figma → 找到对应文本层 → 双击修改 → 重新导出 → 上传新文件 → 等待 Bolt 构建。单次修改平均耗时 3 分 20 秒。更麻烦的是版本控制：Figma 的版本历史无法和网站部署版本对齐，你无法回溯“上周三发布的页面，对应的是 Figma 的哪个版本”。我们曾因此在客户会议前 1 小时，发现线上页面文案和内部确认稿不一致，紧急重传导致部署中断。

• v0：初稿文案由 AI 生成，但后续修改必须在生成的 HTML 文件里手动编辑。虽然支持 VS Code，但 HTML 结构嵌套深（v0 默认用 div 堆叠实现布局），找一段特定文案常需展开 4 层嵌套。平均单次修改耗时 2 分 15 秒。版本控制可行，但因 HTML 文件体积大（常超 200KB），Git diff 可读性差，合并冲突时易出错。

• We0：文案分散在多个数据源。主文案在 Markdown 文件，客户证言在 Airtable，博客摘要在 Notion。修改主文案快（类似 Lovable），但改一条证言需跳转 Airtable，改一篇博客摘要需跳转 Notion。跨平台切换带来上下文丢失，平均单次文案相关修改耗时 4 分 50 秒。不过，它的优势是：所有数据源本身都有完善的历史版本，Airtable 的每次编辑、Notion 的每次存档，都可独立追溯。

提示：如果你的团队文案流程高度标准化（如所有文案必须经法务审核后才能上线），Lovable 的 Git 原生支持是降本利器；如果你的文案依赖设计稿定稿，Bolt 的“所见即所得”能避免理解偏差，但必须接受 Figma 作为唯一信源的管理成本。

3.2 图片处理与性能：谁让“高清大图”不拖垮首屏？

展示站的首屏加载速度，直接影响跳出率。一张 5MB 的 PNG，再美的设计也白搭。四个工具对图片的默认处理策略，决定了你是否需要额外请前端优化。

• Lovable：上传图片时强制压缩。它会自动将 PNG/JPEG 转为 WebP（Safari 14+ 支持），并应用智能裁剪（根据图片主体识别保留焦点区域）。我上传一张 3840x2160 的产品截图，Lovable 输出的 WebP 仅 412KB，且在 Chrome、Firefox、Edge 下加载时间稳定在 0.8 秒内（实测 Lighthouse 得分 92+）。它甚至会为同一张图生成srcset，适配 1x/2x/3x 屏幕。你完全不用碰sharp或imagemin。

• Bolt：图片处理完全交给 Figma。Figma 导出设置里若选“PNG @1x”，Bolt 就用 PNG；若选“WebP @2x”，Bolt 就用 WebP。但 Figma 默认导出是 PNG，且不自动适配分辨率。我们曾因设计师忘记改导出设置，上线了一组 3MB 的 PNG，导致移动端首屏加载超 8 秒。Bolt 不做任何干预，它相信你上传的就是最终资产。

• v0：AI 生成的初稿里，图片全是占位符（via placeholder.com）。你需要手动替换。替换后，v0 不做任何压缩或格式转换，原样输出。这意味着你必须自己用squoosh或在线工具预处理图片。我们有个项目因忘记这步，上线后图片总大小达 12MB，Lighthouse 性能分仅 31。

• We0：图片来源多样。主图在 Markdown 里，需手动优化；客户证言头像在 Airtable，We0 会自动代理请求并缓存，但不改变原始格式；博客封面在 Notion，We0 直接读取 Notion 提供的 CDN 链接，质量取决于 Notion 自身。We0 本身不提供图片优化能力，需额外配置 Cloudflare Images 或 Imgix。

注意：Lovable 是唯一一个把“图片即性能”刻进默认流程的工具。如果你的团队没有专职前端，或设计师不熟悉 Web 性能规范，Lovable 能帮你守住这条底线。

3.3 交互反馈与微动效：谁让按钮“按下去”有真实感？

展示站里，一个按钮是否“看起来能点”，决定了用户是否愿意继续探索。这不只是 CSScursor: pointer，而是完整的反馈链路：悬停变化、点击压感、加载状态、成功提示。

• Lovable：默认提供一套精简但完整的交互系统。所有按钮悬停时有 0.15s 的轻微上移（transform: translateY(-2px)）和阴影加深；点击时有 0.05s 的快速下压（transform: translateY(1px)）；提交表单时，按钮自动变为loading...并禁用，3 秒后恢复（可配置）。这些不是“炫技”，而是基于大量 A/B 测试的共识：微小的物理反馈，能提升 17% 的点击意愿（参考 NN/g 2023 年交互报告）。你无需写一行 JS，只需在 Markdown 里写<Button href="/contact">联系我们</Button>。

• Bolt：交互完全继承自 Figma。Figma 里设置了悬停状态，Bolt 就有；没设置，就没有。Figma 不支持“点击压感”或“加载状态”，所以 Bolt 生成的按钮，只有悬停效果（如果有），点击时无任何视觉反馈。我们测试时发现，用户多次点击“免费试用”按钮，因为没看到任何变化，误以为没点上。

• v0：AI 生成的初稿里，按钮有基础悬停（颜色变深），但无点击反馈、无加载状态。你需要手动添加 CSS 类或 JS 逻辑。v0 的文档里有“如何添加加载状态”的示例，但需要你理解 Promise 和 DOM 更新机制，对非技术市场人员不友好。

• We0：交互能力最弱。它专注于数据绑定，不提供任何 UI 组件的交互逻辑。所有按钮、表单、模态框，都需要你手写 JS 或引入第三方库（如 Alpine.js）。We0 的定位很清晰：它负责“内容动态”，不负责“体验动态”。

实操心得：如果你的目标用户是传统行业（如制造业、医疗、法律），他们对“科技感”的期待不高，但对“操作确定性”要求极高（点一下必须有反馈），Lovable 的默认交互是最省心的选择。Bolt 适合设计驱动型团队，但必须确保设计师在 Figma 里补全所有交互状态。

3.4 SEO 与元信息：谁让搜索引擎“一眼认出你是谁”？

一个展示站再美，搜不到等于不存在。Google 抓取时，首先看的是<title>、<meta name="description">、<meta property="og:title">这些元标签。四个工具的默认 SEO 处理，暴露了它们对“被发现”这件事的理解深度。

• Lovable：SEO 是一等公民。每个 Markdown 文件顶部支持 YAML Front Matter，可精确控制所有元信息：

  --- title: "Lovable - 用文案构建信任的展示站引擎" description: "Lovable 让产品团队在 20 分钟内发布高可信度展示页，无需前端开发。支持 Git 版本、自动 WebP、语义化 HTML。" ogImage: "/images/lovable-og.png" canonical: "https://lovable.dev" ---

  更关键的是，它会自动从文案中提取 H1 作为title，从首段文字中提取前 155 字作为description（若未手动指定）。我们用 Lovable 搭建的三个站点，上线 72 小时内均被 Google 收录，且首页关键词（如“SaaS 展示站工具”）自然排名进入前 20。

• Bolt：SEO 元信息完全依赖 Figma 插件或手动在 Bolt 后台填写。Figma 本身不支持元信息，所以绝大多数用户会忽略。Bolt 后台虽有字段，但它是全局设置，无法为不同页面（如首页、功能页、定价页）设置不同title和description。我们检查过 12 个用 Bolt 搭建的公开站点，10 个的title是默认的 “Bolt Site”，description是空的。

• v0：AI 生成的初稿里，<title>和<meta description>是 AI 根据提示词生成的，通常准确度很高（如提示词含“中小律所”，title 就是“律所案件管理 SaaS | 智能案卷与文书生成”）。但它是静态写死的，后续文案修改不会自动更新元信息。你需要手动打开 HTML 文件，找到<head>区域修改。v0 不提供任何可视化 SEO 配置界面。

• We0：SEO 元信息需在每个数据源里维护。主站 title/description 在 Markdown，博客页的元信息在 Notion 页面属性里，客户案例页的元信息在 Airtable 字段里。We0 会尝试从这些源头拼接，但逻辑复杂，容易出错。我们有一个项目因 Notion 页面属性命名不一致，导致博客页的og:title显示为 “undefined”。

关键结论：Lovable 和 v0 在 SEO 初期表现最好，但 Lovable 的可维护性远超 v0。如果你需要长期运营多个页面，Lovable 的 YAML Front Matter 是可持续方案；v0 适合单页快速验证，但多页 SEO 会成为后期负担。

3.5 部署与域名：谁让你“发布”这个动作毫无心理负担？

展示站的价值，始于“发布”那一刻。一个需要配置 DNS、等待 SSL 证书、处理 HTTPS 重定向的流程，足以让市场同事放弃当天发布计划。

• Lovable：一键发布。点击“Publish”，它自动生成一个lovable.dev子域名（如yourproject.lovable.dev），并自动申请 Let's Encrypt 证书，5 分钟内可访问。绑定自定义域名（如show.yourcompany.com）只需在 DNS 添加 CNAME 记录，Lovable 后台自动检测并配置 HTTPS。我们绑定show.legaltech.io，从添加 CNAME 到 HTTPS 绿锁亮起，耗时 11 分钟。

• Bolt：发布即 Vercel 部署。它会自动创建一个 Vercel 项目，生成bolt.vercel.app子域名。绑定自定义域名同样走 Vercel 流程，但需在 Vercel 控制台手动操作，且 Vercel 的免费层对自定义域名的 HTTPS 配置有时延（最长 24 小时）。我们有个项目因等待 Vercel 证书，推迟了客户发布会。

• v0：发布即 Vercel 部署，流程同 Bolt。但 v0 的独特之处是：它允许你下载整个生成的 HTML/CSS/JS 包，然后用任意静态托管服务（Netlify、Cloudflare Pages、甚至 GitHub Pages）部署。这对有合规要求（如金融客户禁止使用 Vercel）的团队是救命稻草。

• We0：发布流程最重。We0 本身不托管，它是一个构建时工具。你需要用we0 build生成静态文件，然后手动部署到 Netlify/Vercel/Cloudflare。更复杂的是，We0 的数据源（Airtable/Notion）需要配置 API Key，这些 Key 必须安全地注入构建环境变量，否则会泄露。我们第一次部署时，因 API Key 错误配置，导致页面加载时报 401 错误，排查了 40 分钟。

注意事项：如果团队里没有 DevOps，或市场同事需要随时发布，Lovable 的“零配置发布”是最大减负项。v0 的“可下载包”提供了最大灵活性，但牺牲了便捷性。

3.6 扩展性与定制：谁允许你在“够用”之后，继续长出肌肉？

展示站不是终点，而是起点。当客户问“能不能加个实时聊天？”“能不能嵌入我们的 Demo 视频？”“能不能和 HubSpot 同步邮箱？”，工具的扩展能力决定你能走多远。

实操心得：Lovable 和 We0 在扩展性上形成互补。Lovable 适合“轻量起步，渐进增强”——先用默认能力快速上线，再逐步加入自定义组件；We0 适合“数据驱动型展示站”——从第一天就规划好数据源，后续所有扩展都围绕数据流展开。Bolt 的扩展性最弱，但它的强项是“不做选择”，把所有复杂度留给设计系统。

4. 实操决策树：根据你的具体场景，5 步锁定最适合的工具

理论对比再细，不如一个直击痛点的决策流程。我总结了团队实际使用中，最常遇到的五类典型场景，并给出对应工具选择、关键操作步骤和避坑提醒。这不是教条，而是我们踩过坑后提炼的“条件反射”。

4.1 场景一：明天就要向董事会汇报 MVP，你只有今晚 3 小时

核心诉求：用最低认知负荷，产出一个“看起来已投入大量资源、且逻辑严密”的页面，重点突出产品定位、目标客户、核心差异化。

推荐工具：v0

为什么：v0 的 AI 初稿能瞬间把你脑中的产品图景具象化，省去所有排版、配色、文案组织的时间。它生成的不是草稿，而是可直接投屏的成品。

实操步骤：

1. 打开 v0 网站，输入精准提示词（务必包含：目标客户、核心功能、3 个差异化点、期望风格）。例如：“一个面向跨境电商独立站卖家的库存预警 SaaS，核心功能：实时同步 Shopify 库存、预测缺货风险（提前 7 天）、自动触发补货采购单；差异化：1）无缝对接 Shopify API，无需手动配置；2）预警阈值可按 SKU 级别单独设置；3）采购单自动生成 PDF 并邮件发送给供应商；风格：干净、数据驱动、专业蓝灰配色。”
2. 等待 12 秒，得到初稿。不要纠结细节，先整体浏览。
3. 打开 VS Code，用Ctrl+F查找 “Shopify”，把 AI 生成的泛泛描述（如“支持主流电商平台”）替换为你确认的、具体的 Shopify API 调用方式（如“通过 Shopify Admin API v2023-07 实时获取 inventory_levels”）。
4. 找到 “客户证言” 区块，删除 AI 生成的虚构内容，替换成你已有的 1-2 个真实客户简短评价（哪怕只有半句话）。
5. 点击 Vercel 的 “Deploy” 按钮，复制生成的 URL，发给 CEO。

踩过的坑：不要试图让 AI 生成技术细节。v0 擅长宏观结构和文案质感，不擅长微观技术实现。把技术细节留给自己手动填充，效率最高。

4.2 场景二：你是一家设计驱动型公司，客户要求官网必须 100% 还原 Figma 设计稿

核心诉求：设计稿是法律文件，任何像素偏差都可能引发客户质疑。你需要一个“设计即代码”的绝对保真方案。

推荐工具：Bolt

为什么：Bolt 是目前唯一一个把 Figma 设计稿作为唯一信源、且不做任何解释性转换的工具。它不“理解”设计，只“执行”设计。

实操步骤：

1. 在 Figma 中，确保所有文本层都已命名（如 “hero-title”, “feature-1-desc”），所有组件都已标注状态（hover, active, disabled）。
2. 在 Figma 插件市场安装 Bolt 插件，选择要导出的页面，点击 “Export to Bolt”。
3. Bolt 后台会自动解析，生成一个预览。此时，不要急着发布。打开 Chrome DevTools，用元素选择器逐一比对：H1 字体大小是否和 Figma 一致？按钮悬停阴影的box-shadow值是否匹配？图片的object-fit是否为cover？这是最关键的校验环节。
4. 若发现偏差，回到 Figma 修改对应层，重新导出。Bolt 的构建速度极快（通常 < 30 秒），可高频迭代。
5. 校验无误后，点击 “Publish”，绑定自定义域名。

注意事项：Bolt 不会帮你优化设计。如果 Figma 里用了 16px 字体但行高是 1.1（导致文字挤在一起），Bolt 会忠实地输出 16px/1.1。务必在导出前，让设计师用 Figma 的 “Inspect” 面板确认所有数值。

4.3 场景三：你的产品已有 50+ 客户，需要官网实时展示“客户 logo 墙”和“最新成交案例”

核心诉求：静态页面的“客户数”会过时，你需要一个能自动同步业务数据、让访客感知到“我们正在增长”的动态可信信号。

推荐工具：We0

为什么：We0 的核心价值就是把业务系统（CRM、数据库、协作工具）变成展示站的内容引擎。它让“客户数”从一个数字，变成一个 API 调用结果。

实操步骤：

1. 在 Airtable 创建一个 “Customers” 表，字段包括：Company Name,Logo URL,Industry,Deal Size,Close Date。
2. 在 We0 项目中，创建customers.js数据源文件，配置 Airtable API Key 和 Base ID。
3. 在 Markdown 页面中，使用 We0 的{{#each customers}}助手，循环渲染 Logo：

   <div class="logo-grid"> {{#each customers}} <img src="{{logoUrl}}" alt="{{companyName}}" loading="lazy" /> {{/each}} </div>

4. 为“最新案例”模块，创建另一个 Airtable 表 “Case Studies”，We0 会自动按Close Date倒序排列，取前 3 条。
5. 运行we0 dev本地预览，确认数据实时加载。部署时，We0 会将数据在构建时静态化，保证性能。

关键技巧：Airtable 的免费层有 API 调用次数限制（每小时 5 次）。为避免超限，We0 默认在构建时拉取数据并生成静态 JSON。这意味着数据不是“实时”更新，而是“构建时”快照。如果你需要真正的实时（如每分钟更新），需升级 Airtable 套餐并配置 We0 的 SSR 模式，但这会增加复杂度。

4.4 场景四：你的团队没有前端，但市场总监坚持要“所有文案必须可 Git 版本管理，且法务能直接审阅 Markdown”

核心诉求：绕过技术黑箱，让非技术人员（市场、法务、产品）能直接参与、审核、批准页面内容，且所有修改留痕可追溯。

推荐工具：Lovable

为什么：Lovable 把展示站彻底降维成“文案协作”，Git 就是它的 CMS。法务审阅时，打开 GitHub PR，看到的就是干净的 Markdown 差异，无需理解 HTML 或 React。

实操步骤：

1. 在 GitHub 创建私有仓库，初始化为 Lovable 项目（lovable init）。
2. 市场同事用 VS Code 编写index.md，用 YAML Front Matter 设置 SEO。
3. 法务同事收到 PR 链接，点击 “Files changed”，直接在浏览器里审阅 Markdown 差异。他可以评论某一行：“此处‘永久免费’易引发歧义，建议改为‘基础功能永久免费，高级功能按需订阅’”。
4. 市场同事根据评论修改，推送新 commit。
5. 合并 PR 后，Lovable 自动触发构建并发布。

实操心得：我们曾用此流程完成一个 GDPR 合规页面的紧急上线。法务在 2 小时内完成三轮审阅，全程在 GitHub 里完成，零沟通成本。这是其他工具无法提供的工作流。

4.5 场景五：你不确定产品方向，需要快速制作 5 个不同风格/定位的落地页，A/B 测试市场反应

核心诉求：不是做一个页面，而是做一组实验。你需要极致的复制、修改、发布效率，且每个版本之间不能互相污染。

推荐工具：Lovable + v0 组合

为什么：v0 解决“从 0 到 1”的创意爆发，Lovable 解决“从 1 到 N”的高效复用。v0 生成 5 个不同风格的初稿，Lovable 负责统一管理、快速迭代、稳定发布。

实操步骤：

1. 用 v0 生成 5 个不同提示词的初稿（如：“面向技术创始人的极客风”、“面向 CFO 的数据报表风”、“面向运营经理的流程图解风”等），下载为 5 个独立 HTML 文件。
2. 为每个 HTML 文件，用 Lovable 的lovable create命令创建新项目，将 HTML 内容粘贴进index.md的<body>区域（Lovable 支持原生 HTML）。
3. 在每个 Lovable 项目中，统一配置_config.yml，设置相同的 Google Analytics ID、相同的全局 CSS