JSON Website Generator v2.0：将任意需求转化为生产级网站蓝图的 LLM 提示系统

背景：网站开发中的决策碎片化问题

在传统的网站开发流程中，从需求到上线通常需要经历多个阶段：需求分析、设计系统定义、信息架构规划、技术栈选择、SEO 策略制定、内容规划等。每个阶段都可能涉及不同的工具和人员，导致信息在传递过程中不断失真或遗漏。

更常见的情况是，许多项目从一开始就缺乏系统性的规划。设计师可能凭空创造一套视觉系统，开发者可能基于个人偏好选择技术栈，SEO 往往是事后补救而非前置规划。这种碎片化的决策方式不仅效率低下，还常常导致最终产品与原始愿景背道而驰。

JSON Website Generator v2.0 正是为了解决这一痛点而设计的。它不是一个代码生成器，而是一个"决策编排器"——通过结构化的 LLM 提示系统，将任何模糊的用户输入转化为一份完整、连贯、可直接投入生产的网站蓝图。

核心设计理念：零偏见与渐进式信任

零行业偏见（Zero Sectorial Bias）

该系统的首要原则是"绝不编造或假设任何数据"。传统 AI 生成器的一个常见问题是"幻觉"——它们会生成看似合理但实际上完全虚构的内容，比如编造的品牌名称、与主题无关的 SEO 关键词、从竞争对手那里复制来的通用配色方案。

JSON Website Generator 通过以下机制避免这一问题：

• 每个字段必须是从用户输入中推导得出，或明确标记为默认值（[DEFAULT]），或标记为待澄清（[À CLARIFIER]）
• 未知字段使用占位符 {{VARIABLE}} 而非虚构值
• 系统不会为了输出看起来完整而填充虚假数据

渐进式信任评分（Progressive Confidence Scoring）

系统不会输出半吊子的蓝图。它基于从输入中提取的维度数量计算信任评分：

• High（高信任）：≥5 个维度已验证 → 完整生成
• Medium（中信任）：3-4 个维度 → 生成但标记 default_fallback: true 并附明确说明
• Low（低信任）：<3 个维度 → 完全停止并要求澄清

这种设计防止了像"网站"这样模糊的输入产生看似完整实则完全虚构的蓝图。

六阶段流水线架构

生成器采用严格的六阶段顺序处理流程，确保每个决策都在正确的时机做出，且下游决策依赖上游决策：

Phase 0 → 输入提取（7 个维度）
Phase 1 → 设计系统推导
Phase 2 → 网站架构（路由 + 区块）
Phase 3 → 技术栈条件选择
Phase 4 → SEO 与 Schema.org 配置
Phase 5 → 质量门（发射前验证）
        ↓
    JSON 输出

每个阶段都是自包含的：有明确的输入（Phase 0 提取的维度或前一阶段的决策）和明确的输出（最终 JSON 的对应区块）。

Phase 0：输入提取的七个维度

这是整个系统最关键的环节。在生成任何内容之前，LLM 必须从用户输入中提取以下七个维度：

维度	捕获内容	示例提取值	默认值
sector	行业或领域	"律师事务所"	"general_services"
target_audience	目标受众	"寻求法律咨询的中小企业"	"broad_public"
tone_vibe	情感基调	"专业、令人安心"	"professional_neutral"
primary_goal	主要转化目标	"预约咨询"	"generate_leads"
brand_name	品牌或企业名称	"杜邦联合律所"	"{{BRAND_NAME}}"
locale_lang	语言和地区	"fr-FR"	"fr-FR"
constraints	技术约束、预算、特殊要求	["CMS_required", "budget_low"]	[]

如果某个维度无法确定，它会获得默认值并被明确标记。这种透明度让下游工具或开发者清楚知道哪些内容是推导出的，哪些需要补充。

Phase 1：设计系统推导

基于提取的维度，系统会生成完整的设计令牌（Design Tokens）：

颜色系统（HSL 格式）

为什么选择 HSL 而非 Hex 或 RGB？因为 HSL 是可计算的——你可以通过调整色相、饱和度或亮度来程序化地生成变体，而不仅仅是显示。

生成的令牌包括：

• 主色（Primary）：基于行业推断的品牌色
• 辅色（Secondary）：互补或对比色
• 中性色（Neutral）：灰度阶梯，从最深到最浅
• 语义色（Semantic）：成功、警告、错误、信息
• 背景色（Background）：表层、卡片、遮罩

排版系统（模块化比例）

采用 1.25 的模块化比例（行业标准），生成从正文到超大标题的完整字体阶梯。每个级别都有明确的用途：

• text-xs：辅助说明、标签
• text-sm：元数据、脚注
• text-base：正文标准
• text-lg：引言、强调段落
• text-xl 至 text-6xl：各级标题

间距与动效

间距令牌遵循 4px 基准网格（4、8、12、16、24、32、48、64...），与 Tailwind CSS 等主流框架兼容。

动效令牌则考虑无障碍需求，包含 prefers-reduced-motion 媒体查询的适配，确保对动画敏感的用户也能舒适浏览。

Phase 2：网站架构设计

系统会生成完整的网站结构，包括：

路由规划（Routes）

每个路由都有明确的定义：

• URL 路径
• 页面类型（首页、落地页、博客文章、产品页等）
• 主要转化目标
• SEO 优先级（priority 字段，供爬虫参考）

内容区块（Sections）

每个页面被分解为语义化的内容区块，每个区块包含：

• 区块类型（Hero、Features、Testimonials、CTA、FAQ 等）
• 内容简报（Content Brief）：该区块需要传达的核心信息
• 建议的文案长度和风格
• 视觉元素建议（图片、图标、视频）

页面级 SEO

每个页面都有独立的 SEO 配置：

• Title 标签（遵循最佳长度 50-60 字符）
• Meta Description（150-160 字符）
• Open Graph 标签（用于社交媒体分享）
• 关键词意图分类（信息型、导航型、交易型）

Phase 3：技术栈条件选择

技术栈的选择不是随意的，而是基于 Phase 0 提取的约束条件进行条件判断：

前端框架

• 如果 constraints 包含 "CMS_required" 且 budget_low → 推荐静态站点生成器（如 Astro、11ty）
• 如果需要复杂交互 → 推荐 React/Vue/Svelte
• 如果团队熟悉特定技术 → 尊重该偏好

CMS 选择

• 如果内容更新频繁且非技术团队维护 → 推荐 Headless CMS（如 Sanity、Contentful）
• 如果内容相对静态 → 推荐基于文件的方案（如 Markdown + Git）
• 如果预算严格受限 → 推荐开源方案（如 Strapi、Directus）

其他技术决策

• 分析工具：基于隐私合规要求（GDPR/CCPA）推荐 GA4、Plausible 或 Fathom
• 国际化（i18n）：基于 locale_lang 和预期市场推荐方案
• CI/CD：基于团队规模和部署目标推荐 GitHub Actions、Vercel、Netlify 等
• 测试策略：单元测试、E2E 测试、视觉回归测试的工具选择

Phase 4：SEO 与 Schema.org 配置

这是许多项目最容易被忽视的部分。系统会生成完整的 JSON-LD Schema.org 标记，采用 @graph 格式支持多类型实体：

常见 Schema 类型

• Organization：企业基本信息、联系方式、社交媒体链接
• WebSite：网站搜索功能、站点名称
• WebPage：页面级元数据（最后修改日期、面包屑）
• Article/BlogPosting：博客文章的作者、发布日期、修改日期
• Product：产品名称、描述、价格、库存状态
• LocalBusiness：本地企业的地址、营业时间、评价
• FAQPage：常见问题页面的问答对

每个 Schema 都包含所有 Google Search Console、社交媒体和审计工具要求的必填字段。

Phase 5：质量门与性能预算

在输出最终 JSON 之前，系统会进行一系列质量检查：

性能预算（Performance Budget）

为每个资源类型设定目标大小：

• HTML 文档：< 50KB
• CSS（关键路径）：< 20KB
• JavaScript（关键路径）：< 100KB
• 首屏图片：< 200KB
• 字体文件：< 100KB（每个权重）

启动检查清单（Launch Checklist）

• 所有 {{VARIABLE}} 占位符是否已被替换或标记？
• 每个页面是否有明确的转化目标？
• Schema.org 标记是否通过验证？
• 无障碍检查（颜色对比度、ARIA 标签、键盘导航）
• 性能指标目标（LCP < 2.5s, CLS < 0.1, FID < 100ms）

输出结构：Master Blueprint JSON

最终输出是一个单一的 master_blueprint 对象，包含六个主要区块：

{
  "master_blueprint": {
    "meta": {
      "project_id": "{{PROJECT_ID}}",
      "input_confidence": "high",
      "default_fallback": false,
      "execution_order": ["design_system", "site_structure", "tech_stack", "seo_schema", "performance_budget"]
    },
    "design_system": { /* 颜色、排版、间距、动效、断点 */ },
    "site_structure": { /* 路由、区块、内容简报、页面级 SEO */ },
    "tech_stack": { /* 框架、CMS、分析、测试、CI/CD、i18n */ },
    "seo_schema": { /* JSON-LD Schema.org @graph */ },
    "performance_budget": { /* 资源目标大小 + 启动检查清单 */ }
  }
}

使用场景与消费方式

这份蓝图可以被多种角色和工具消费：

开发者

作为脚手架的起点，直接根据 tech_stack 和 site_structure 初始化项目。设计令牌可以直接转化为 Tailwind 配置或 CSS 变量。

第二个 LLM 提示

将 Blueprint JSON 作为上下文输入给代码生成 LLM，让它直接生成组件代码、页面模板或 CMS 配置。

无代码/低代码工具

解析 JSON 结构，自动创建页面、应用设计系统、配置 SEO 设置。

项目经理

作为协调文案、设计师和开发者的单一事实来源。每个角色都能从蓝图中找到明确的交付物定义。

局限性与边界情况

1. 输入质量依赖：系统无法从极度模糊的输入中创造魔法。"做一个网站"这样的输入会被拒绝，要求提供更多维度。

2. 行业知识边界：虽然系统努力保持零偏见，但某些行业的特定惯例（如金融服务的合规要求、医疗行业的隐私规范）可能需要人工补充。

3. 技术栈时效性：推荐的技术栈基于当前主流实践，但技术生态变化迅速，建议定期审查技术选择。

4. 语言限制：当前版本主要针对法语和英语市场优化，其他语言的支持可能需要调整。

结语：从模糊意图到精确执行的桥梁

JSON Website Generator v2.0 代表了 AI 辅助开发的一种新范式。它不是取代人类决策，而是将决策过程结构化、透明化、可审计化。通过强制性的七维度提取、渐进式信任评分和六阶段流水线，它确保了从模糊意图到精确执行的每一步都有据可查。

对于需要频繁启动新项目的团队（如数字代理、SaaS 公司、创业工作室），这套系统可以显著缩短从需求到开发的准备时间。更重要的是，它确保了每个项目都有一个坚实的基础——不是基于假设，而是基于明确提取和验证的需求维度。

在 AI 生成内容日益普及的时代，能够区分"看似合理的虚构"和"基于证据的推导"变得尤为重要。JSON Website Generator 通过其严格的不编造原则和占位符机制，为 AI 辅助开发树立了一个值得参考的质量标杆。