企业官网建设流程全解析

如果你在网上搜“Claude 首页设计”，大概率会看到一堆“用AI生成落地页”的噱头帖。但很少有人把这件事当成一个工业化流程来跑。我最近刚做完一个项目：客户要在4周内交付74个产品线的首页方案，从行业调研、信息架构、文案到能直接打开的前端原型，全部走Claude生成。项目代号就叫“Using Claude to design 74 homepages”。这篇文章把这套玩法完整拆一遍——怎么用Claude批量产出一致性高、又有差异化的首页，哪些环节能提效80%，哪些坑我已经替你踩过了。

如果你正好要交付多页面、多站点、多产品线的网站需求，或者你是一个设计师、前端、内容运营、独立开发者，手里攒了一堆“能不能用AI帮我搞定”的页面，这篇内容会非常对路。我会把设计系统、内容模型、Prompt模板、批量脚本、验收工具全部交代清楚，可以直接照抄。

1. 为什么用Claude设计74个首页：从项目复盘说起

1.1 需求本质：这不是74个设计任务，而是1套生产系统

先说清楚我接到的需求长什么样。客户是一家集团，旗下74个子品牌/产品线要各自拥有独立首页，有的偏工具型SaaS，有的偏内容媒体，有的偏电商零售，有的偏咨询服务业。传统做法是：配3个设计师、1个前端，先挨个访谈业务方，再出风格稿，再一轮轮改。按这个节奏，74个页面没有8到12周根本交付不了，而且不同设计师做出来的页面风格很容易打架。

我当时做了一个关键判断：不能把74个首页当成74个独立设计任务推进，必须搭一条生产线。生产线的前端是Claude，后端是设计系统、内容模型和Prompt模板。人只负责两件事：前期定义约束，后期验收修正。真正用Claude生成每页的时间加起来不到一周，前面定义约束花了一大半时间。

这里有个很重要的认知：AI能不能帮你做出好东西，不取决于你给它的自由度有多大，而取决于你在它干活之前把边界划得有多清楚。自由度给得太高，它只会交给你一堆“看起来很AI”的正确废话。约束给得到位，它反而能在边界内做出让人惊喜的取舍。

1.2 为什么选Claude而不是其他方案

市面上能生成网页的工具不少，我对比过几类。GPT系列模型也很强，但在“超长上下文+代码输出稳定性”这个组合上，实测不如Claude顺手，尤其是当Prompt里既有大量中文文案约束、又有HTML/CSS代码约束时。Claude的上下文窗口够大，能把品牌简报、行业背景、设计令牌一次性塞进去，生成的单文件HTML结构干净，嵌套层级清晰，这是批量生产最需要的能力。

模板建站工具（那类可视化拖拽建站）生成速度确实快，但只能做通用模板，换换文案和图片就到头了，做不到按行业定制内容模型。纯人工最可控，但74个页面的工期和成本摆在那里，根本来不及。我把几个方案放在一起对比过：

最终选Claude的核心原因是：大上下文窗口适合理解行业brief，长文文案能力强，前端原型输出质量稳定。它在这套流程里不是替代设计师，而是把“重复劳动”和“基础结构生成”承接过去，让设计师只做判断和精修。

1.3 核心设计思路：一套系统，74个变体

这个思路是整个项目的灵魂。74个页面不要各自为政，先定义一套全局“设计系统”，再定义几种“内容模型”。每个频道做的事情，实际上是在这套系统里做变体。

打一个生活化的比方：连锁餐饮后厨把酱料、配菜、火候全部标准化，门店之间只换主料。首页也一样，颜色变量、间距变量、字体层级、组件库先统一，每个频道只换行业文案、主视觉氛围、特色模块。好处非常直观：品牌一致性有保障，不会出现A页面科技蓝、B页面糖果粉的割裂感；评审成本低，只看每页的差异部分；后期如果母公司换Logo色或字体，只需要改设计系统里的变量，所有页面统一更新。这也是我能在一周内跑完74页的根本原因——不是一次做了74个设计，而是做了一套设计工具，再用它批量出74个结果。

2. 核心细节解析：设计系统、内容模型与Prompt工程

2.1 先把设计系统固化成Claude能读懂的文档

我见过很多人让Claude“自由发挥配色”，结果生成出来的页面色彩五花八门，根本没法统一。正确的做法是把视觉规范翻译成机器可读的设计令牌（design tokens），直接作为项目资产存放在工作目录里。每个Prompt都要求Claude必须严格使用这个文件里的变量，不得自创新颜色、新字号。

下面是我这次项目实际使用的design_tokens.json，节选了几个关键部分：

{ "color": { "primary": "#2563EB", "primaryHover": "#1D4ED8", "accent": "#7C3AED", "bg": "#F8FAFC", "surface": "#FFFFFF", "textPrimary": "#0F172A", "textSecondary": "#64748B", "border": "#E2E8F0", "success": "#10B981" }, "typography": { "fontFamily": "\"PingFang SC\", \"Microsoft YaHei\", sans-serif", "h1": { "size": "42px", "weight": 700, "lineHeight": 1.2 }, "h2": { "size": "28px", "weight": 700, "lineHeight": 1.3 }, "body": { "size": "16px", "weight": 400, "lineHeight": 1.75 } }, "spacing": { "base": 8, "scale": [4, 8, 12, 16, 24, 32, 48, 64] }, "radius": { "sm": "8px", "md": "16px", "lg": "24px" }, "shadow": { "card": "0 4px 16px rgba(15,23,42,0.06)", "float": "0 12px 40px rgba(15,23,42,0.12)" } }

把这个文件放进项目目录后，每个Prompt里都要粘贴或引用它。实测下来，只要这一步做到位，页面之间的一致性立刻提升一个档次，因为Claude不会再自己发明颜色了。它会在CSS里用var(--primary)这类变量引用，后续全局改色也很方便。

2.2 内容模型：把74个频道分成4种页面类型

定义完视觉令牌，下一步是定义内容模型。74个频道各有各的行业属性，但页面骨架其实是有规律可循的。我把它们归成四种类型：工具产品型、内容媒体型、社区平台型、电商零售型。每个类型对应一套固定的区块顺序。

• 工具产品型：Hero + 功能列表 + 客户案例 + CTA + FAQ
• 内容媒体型：Hero + 推荐内容流 + 专题区 + 订阅CTA
• 社区平台型：Hero + 数据大盘 + 用户故事 + 入驻流程 + CTA
• 电商零售型：促销Hero + 品类矩阵 + 爆款推荐 + 品牌故事 + 订阅/客服

这个划分的价值在于，Prompt里不需要每页都从头描述结构，只需要说“使用工具产品型内容模型”，Claude就知道该排哪些区块。我通常会再补充一句：顺序可以微调，但区块不能少，尤其是CTA区域不允许缺。因为客户的核心诉求是转化，每个页面必须给用户一个明确的下一步动作。

2.3 Prompt编排：三段式结构 + 禁用词黑名单

Prompt是整个流程中最值得打磨的部分。我最后沉淀出一套三段式模板，每次只替换中间的频道信息，其他部分固定复用。

第一段是角色任务：你是拥有12年经验的网页设计师兼前端工程师，擅长信息架构、内容策略和响应式页面开发。第二段是频道信息：定位、目标用户、核心卖点、品牌调性、行业背景，控制在300字以内。第三段是输出要求：格式、语言、禁用词、技术约束。

下面是一份我实际用过的Prompt模板，保留完整版本供参考：

你是一名拥有12年经验的网页设计师兼前端工程师，擅长信息架构、内容策略和响应式页面开发。 请为【频道名称】设计一个完整的首页，输出为单文件HTML（内联CSS + 少量JavaScript）。 【频道信息】 - 定位：一句话说清这个频道/产品是做什么的 - 目标用户：具体的人群标签和使用场景 - 核心卖点：3-5条，每条都要具体可感知 - 品牌调性：专业、温暖、新锐、稳重等 - 行业背景：200字以内描述 【内容模型】 首页必须依次包含以下区块，具体顺序可微调： 1. 顶部导航（含Logo位和2个CTA按钮） 2. Hero区（主标语、副标语、主次按钮、视觉背景） 3. 信任背书区（真实数据或客户logo点位，不写夸大数字） 4. 核心能力/服务区块（建议四宫格或六宫格） 5. 典型应用场景或流程介绍 6. 客户案例/用户声音（2-3条） 7. 行动召唤区（CTA + 联系/注册入口） 8. 页脚（4栏导航 + 版权区） 【输出要求】 1. 首先输出150字以内的“设计说明”，说明你的布局思路和配色理由。 2. 然后输出完整HTML代码。 3. 文案必须为原创中文，禁止使用Lorem ipsum或英文占位。 4. 禁止出现以下空话套话词汇：赋能、抓手、闭环、一站式、全方位、助力、共创、价值最大化、深度融合。 5. 所有配图使用渐变占位块、纯色块或占位链接，不要写无意义的图片描述。 6. 使用CSS Grid/Flexbox，适配手机、平板、桌面三端，断点建议768px、1024px。 7. 不引入任何外部框架和字体库。 8. 颜色必须严格使用design_tokens.json中的色值，不得自创新色。 【设计令牌】 （此处粘贴design_tokens.json内容）

禁用词黑名单这一段特别提一下。Claude对“禁止词汇表”相当敏感，把它放在输出要求第一条，能显著减少空话套话。我遇到过很多次，不加黑名单时生成的页面里全是“我们致力于提供卓越的解决方案”这种正确但毫无信息量的句子；加上黑名单之后，文案立刻具体了不少。

2.4 为什么每次都要让Claude先写“设计说明”

刚开始跑的时候，我让Claude直接输出HTML，后来发现两个问题：一是页面做出来出了问题很难定位，不知道是没理解品牌背景还是技术实现出错；二是给客户汇报的时候，每个页面背后的设计逻辑我还得自己写一遍文档。

后来我改了规则：先输出150字以内的设计说明，再输出代码。这个说明成了质量闸门。看它写“我用蓝色是为了突出科技感”，基本可以预期页面会平庸；如果它写“这个频道主要面向财务人员，核心诉求是降低操作焦虑，所以我用深蓝作为主色，用大面积留白来建立秩序感”，说明它真的理解了业务。设计说明还能直接拼进交付文档，省了给客户解释“为什么这么设计”的时间。实测下来，这150字投入回报非常高。

3. 实操过程与核心环节实现

3.1 批量提效：用命令行把74个页面跑成文件

这个项目我全程在本地命令行环境下操作，用Claude的headless模式批量处理。项目文件结构先定下来：

project/ ├── design_tokens.json ├── channels.csv ├── prompts/ │ ├── wms.md │ └── ... ├── pages/ │ ├── wms.html │ └── ... └── scripts/ ├── build_prompts.py └── run_all.sh

channels.csv是核心清单，每一行是一个频道：slug、频道名、行业类型、内容模型、定位、目标用户、核心卖点、品牌调性、行业备注。我先把74个频道的信息整理成这个表，然后写一个Python脚本，把Prompt模板和渠道信息合并渲染成74个独立的prompt文件。手写74份Prompt既不现实也没必要，模板化之后每次只需要维护CSV数据。

import csv from pathlib import Path template = open("prompt_template.txt", encoding="utf-8").read() with open("channels.csv", encoding="utf-8") as f: channels = list(csv.DictReader(f)) for ch in channels: prompt = template.replace("【频道名称】", ch["name"]) prompt = prompt.replace("【频道信息】", f""" - 定位：{ch['positioning']} - 目标用户：{ch['target_user']} - 核心卖点：{ch['selling_points']} - 品牌调性：{ch['brand_tone']} - 行业背景：{ch['industry_note']} """) Path(f"prompts/{ch['slug']}.md").write_text(prompt, encoding="utf-8")

prompt文件生成好之后，用Shell脚本批量调用CLI：

#!/usr/bin/env bash for file in prompts/*.md; do slug=$(basename "$file" .md) echo "Processing $slug ..." claude -p "$(cat "$file")" --output-file "pages/$slug.html" sleep 3 done

这里的sleep 3是为了防止调用太频繁触发限流，实测非常有用。如果你调的是API，也可以改成requests循环，逻辑一样。个人经验是把每批数量控制在5到10个之间，跑完一批人工抽查一下，再跑下一批，避免一次性跑完74个结果全废。

3.2 单页实录：以“智能仓储管理系统”频道为例

光说方法论不够，我拿一个真实频道展示输出效果。频道slug叫wms，行业是SaaS，目标用户是仓库经理和物流总监，核心卖点是多仓协同、扫码出入库、实时库存、数据分析看板。

Claude返回的设计说明大概是这个水平：

“该页面面向仓库管理者的日常工作场景，信息密度要高于普通品牌页，但又要避免压迫感。主色采用设计系统中的深蓝，传递可靠与秩序感，Hero区采用左文右图的布局，让用户第一眼看到核心价值主张。核心功能区使用四宫格，降低阅读负担；信任背书区放置客户Logo点位，强化行业经验。行动召唤区在首屏和第二屏各出现一次，兼顾浏览型用户和决策型用户。”

这就是我前面说的“能用的设计说明”。它明确解释了布局和配色理由，证明模型理解了受众。再看HTML结构骨架，整体清清爽爽：

<header class="nav">...</header> <section class="hero"> <div class="container hero-grid"> <div class="hero-copy"> <h1>从入库到出库，库存准确率提升到99.9%</h1> <p>多仓协同、扫码出入库、实时库存看板，一套系统管好全部仓储环节。</p> <a class="btn btn-primary">预约演示</a> <a class="btn btn-secondary">查看功能</a> </div> <div class="hero-visual gradient-block">...</div> </div> </section> <section class="trust">...</section> <section class="features grid-4">...</section> ...

主标语写得很具体，“99.9%”这种数字比“高效准确”有说服力得多。需要改的地方也很明显：客户案例大概率是模型“编”的，必须替换为真实项目案例；一些卖点还能更具体，比如把“智能盘点”改成“扫码枪对准货架3秒完成盘点”。这个阶段不要指望一次到位，先让Claude把页面骨架和文案底稿搭好，人再往上补真实素材。

3.3 关键参数：上下文长度、输出截断和token控制

跑批量时会遇到三个头痛的参数问题。

第一个是上下文长度。频道资料如果超过8000字，Claude的理解能力反而下降，尤其是行业背景和竞品摘要又长又杂的时候。我的处理方式是把所有资料压缩成“频道简报”，控制在500字以内，只保留定位、目标用户、核心卖点、行业禁忌。这不是丢信息，而是逼自己把最重要的信息提炼出来——其实这也是设计师对品牌理解能力的体现。

第二个是输出截断。一个完整首页的HTML单文件往往有15KB到30KB，超过单次输出上限是常有的事。我试过几次生成到一半直接断掉，页面缺失严重。后来我要求Claude“省略可复用的页脚样式，输出差异区块和核心CSS变量”，或者“分两个阶段生成，先结构后细节”。最省事的办法是要求它用CSS变量组织全部样式，压缩重复代码，这样输出长度能减少一半。

第三个是token成本。74页加起来的输入输出量并不小，控制成本的关键是Prompt中的素材不要盲目堆长文本。设计令牌和内容模型是固定的，占用的输入量可以接受；但频道简报越长，成本越高，而且未必带来更好的输出。我给客户报的这个项目，每页生成成本估算在350到500 token输出上下，整体完全可控。

3.4 低预算模式的另类玩法：母版 + 差异增量

如果连批量调用都觉得成本高，还有一套更省的方法：母版加差异增量。先让Claude生成一个代表最佳实践的“母版首页”，把它当作标准模板；剩下73个频道，不让模型重新生成整页，只让它输出“差异包”——主标语、Hero文案、主题色变量、特色模块的HTML片段。最后用Python脚本把差异包合并进母版，输出新页面。

template = open("template.html", encoding="utf-8").read() diff = json.loads(open("diffs/wms.json", encoding="utf-8").read()) page = template.replace("{{HERO_TITLE}}", diff["hero_title"]) page = page.replace("{{HERO_DESC}}", diff["hero_desc"]) page = page.replace("{{PRIMARY_COLOR}}", diff["primary_color"]) page = page.replace("{{FEATURE_HTML}}", diff["feature_html"]) open("pages/wms.html", "w", encoding="utf-8").write(page)

这套玩法的生成成本直接降到原来的五分之一，差异增量模式的页面一致性也更高，代价是页面长得会比较像。如果客户追的是“内容型站点集群”，这个方案很合适；如果客户明确要求每个页面一眼看上去就不一样，就老老实实走全量生成路线。

4. 质量把控、翻车实录与人工兜底

4.1 批量验收：自动化截图 + 结构化检测，拒绝人肉滚屏

74个页面人肉过一遍确实可以，但效率太低，而且容易漏。我搭了一套简单的验收流水线：用Playwright批量截图手机端和桌面端视图，人只看截图判断视觉问题；再用Python写一个脚本扫描HTML结构，检查必需的区块是否完整、是否出现禁用词。

Playwright批量截图的核心逻辑很直接：

const { chromium } = require('playwright'); const fs = require('fs'); (async () => { const files = fs.readdirSync('./pages').filter(f => f.endsWith('.html')); for (const file of files) { const browser = await chromium.launch(); const page = await browser.newPage({ viewport: { width: 390, height: 844 } }); await page.goto(`file://${process.cwd()}/pages/${file}`); await page.screenshot({ path: `shots/mobile-${file}.png` }); await browser.close(); } })();

桌面端截图再把viewport改成1440乘以900跑一遍即可。结构检测用BeautifulSoup就够：

from bs4 import BeautifulSoup import glob bad_words = ["赋能", "抓手", "闭环", "一站式", "全方位", "助力", "共创", "价值最大化"] for path in glob.glob("pages/*.html"): soup = BeautifulSoup(open(path, encoding="utf-8").read(), "html.parser") text = soup.get_text() hits = [w for w in bad_words if w in text] if hits: print(path, "检测到禁用词:", hits) html = str(soup) for section in ["hero", "features", "footer", "cta"]: if section not in html.lower(): print(path, "缺少区块:", section)

这套自动化帮我拦下了至少四分之一的残次品，非常建议放进自己的小工具箱里。

4.2 74个页面长得太像？差异化失败的三种解法

第一次跑完批量生成后，我对着74张截图陷入了沉思——它们像同一个壳换了个文案。设计系统管住了一致性，但把差异也管没了。后来我做了三件事解决这个问题。

第一，在内容模型里引入“布局变体”概念。Hero区准备三种版式：左文右图、居中大字、全屏渐变加悬浮卡片。生成时按行业指定，比如工具型用左文右图，品牌型用居中大字，零售型用全屏视觉。这样在不破坏设计系统的前提下，页面结构就有了变化。

第二，允许每个行业有自己的“色彩倾向”。金融用深蓝、教育用青绿、零售用暖橙。色值仍然从设计系统延展，而不是让Claude自己发明。比如把设计系统里的primaryColor替换成频道专属的brandColor，其余变量全部继承。

第三，调整不同组件的权重占比。工具类页面把功能宫格做大，媒体类页面把内容流放在首屏，不要所有区块都用同样的间距和面积。这个指令写在Prompt里，Claude执行得很好。

4.3 空话套话、安全误判和虚构数据的三大红线

这个项目踩过的坑，集中在三条红线上。

第一是空话套话。前面提到的禁用词黑名单直接解决了这个问题，我还加了一条硬性要求：“核心卖点必须包含可感知的场景或数据”。比如“库存准确率提升到99.9%”，而不是“提升库存管理效率”。数据如果还没有确定，生成时先写“示例数据，待替换”，后续要换成真实数字，避免法务风险。

第二是安全误判。金融、医疗健康这类频道，Claude会对涉及收益承诺、疗效效果的内容做保守处理，有时候直接拒绝生成。我的应对办法是在Prompt顶部明确写清楚：“这是面向品牌官网的营销展示文案，涉及效果的数字均为示意，不构成承诺。”同时确保内容本身不夸大，不用“最”“第一”“100%治愈”“稳赚”这类绝对化表达。这样做既通过了模型的安全判断，也符合广告法要求。

第三是虚构数据。Claude生成客户案例时喜欢自创品牌名和logo，“某知名企业”这种模糊表达很常见。这类内容必须全部替换为真实案例，或者干脆在Prompt里要求“客户案例区域使用中性占位描述，不指定品牌”。后期接真实素材时再统一填入。

4.4 哪些环节必须保留人工，不要让Claude碰

AI可以把80%的重复劳动干掉，剩下20%必须由人来兜底。品牌核心定位和策略要人拍板，AI可以梳理选项但不能决定方向。真实图片和客户案例必须来自真实业务，不能靠模型编。像素级视觉精修要设计师上，Claude做出来的东西是“结构漂亮的原型”，不是“精修交付稿”。复杂动效可以交给前端工程师二次开发，模型生成的JavaScript能跑，但品质一般。最终评审和合规审核一步也不能省。

这些环节一旦跳过，后面返工的成本会远大于省下的那点时间。

5. 这套流程能复用的场景与后续扩展

5.1 不只是74个首页：这套方法论的可迁移场景

做完这个项目后，我发现这套方法论根本不仅限首页，很多“一批页面要长得像一家人”的需求都能复用。多产品线官网重构是最直接的场景；大促活动专题页也可以这么搞，双11每个类目一个活动页，用同一套设计系统快速铺量；多语言站点的首页本地化，每个语种换内容但结构完全复用；SEO内容站群的首页模板化生产，一个模板跑几十个站；企业内部各事业部子站批量搭建，同样适用。

核心就一句话：只要需求是“N个页面要做成一家人”，这套设计系统加内容模型加Prompt流水线的组合就能直接搬过去。

5.2 把项目资产沉淀成自己的Prompt Kit

这次项目结束后，我把Prompt模板、设计令牌、内容模型、禁用词列表、验收脚本全部整理成了私有仓库，命名叫prompt-kit。下一次遇到同类需求，第一天就能跑出第一批页面，不用再从头摸索。

我的目录结构大概是这样的：

prompt-kit/ ├── roles/ ├── design_systems/ ├── content_models/ ├── blacklist_words.txt ├── templates/ └── scripts/

Prompt我当成代码一样维护，每次改版都会记录改了什么、为什么改。设计系统属于代码资产，放进版本管理。未来有几个扩展方向挺值得试：把生成结果直接接入CMS字段，省掉手动搬运；用知识库的方式把客户资料自动组装进Prompt，减少人工整理；再进一步，对生成页自动化做A/B测试，不同配色方案小流量跑数据，这就变成了一套增长实验平台。

这次用Claude跑完74个首页，我最真实的体会有两个。一是AI生成内容的价值不是凭空创造，而是靠强约束把批量生产的边际成本打到极低；二是真正挑大梁的依然是人——前期把设计系统和内容模型定义清楚，后期把每一页的合规与真实素材兜住。最后再分享一个小技巧：每个Prompt都要求Claude先输出设计说明，这不仅是给AI自己搭脚手架，更是给我们留了一把验收的尺子。下次再有人问AI能不能做设计，先让他定义一个设计系统再说。