MetaSkill/skills/le-wechat-article/references/themes/theme-generator.md

自定义主题生成器 —— 从偏好/参考图生成新主题并保存复用

用户想要内置主题之外的新风格时走本流程：收集偏好 → 用下方提示词生成 Block 区块库 HTML → 转换为本 skill 标准主题库 → 登记到 theme-index → 以后排版可直接选用。

触发场景

• 用户说「生成一套新主题 / 自定义风格 / 我想要 XX 风格的组件库」
• 用户上传参考图并要求「按这个风格做一套排版主题」
• 用户对现有主题都不满意，描述了想要的气质/配色/场景

第一步：收集偏好

按下表向用户收集；只有"主题描述"必填（或提供参考图），其余为空时按提示词规则自动补全。用户上传的参考图用 Read 工具读取后提取视觉特征。

字段	说明	为空时
主题名称 / 主题ID	中文名 + theme- 开头的英文 ID	自动生成
主题描述	想要的气质、场景、感觉	必填（或由参考图推导）
参考图	图片文件/截图，可多张	可空
主题色 / 背景色 / 正文色 / 强调色 / 装饰色	色值或口头描述	由描述/参考图推导；背景默认白/近白
字体偏好	提示词允许列表内的值	按风格自动选
设计技巧 / 风格特征 / 适用场景（TAG）	各 2~4 个中文短语	自动生成
圆角偏好 / 阴影偏好	如"大圆角/无阴影"	按风格自动定

一次问全（用 AskUserQuestion 或让用户自由描述），不要逐字段追问。

第二步：生成 Block 区块库 HTML

用本文末尾的【生成提示词】+ 收集到的偏好，生成完整区块库 HTML，保存为：

<SKILL_ROOT>/assets/theme-previews/{THEME-ID}.html

该文件是风格的单一预览源：全部区块连续排布在同一个页面里，用户浏览器打开一次性浏览整套风格（不逐块展示、不逐块确认）。为方便对照，可在每个区块上方加一行浅灰小字的区块名标注（仅预览页用，转换进主题库时去掉）。用户整体确认/调整风格后再进第三步。

本 skill 语境适配（提示词中的外部指涉按此理解）：

• 提示词里的「wpwexin 主题文件 / theme-mono-magazine.html」在本 skill 中不存在；「输出格式参考」以本 skill references/theme-*.md 的占位文案规范和微信兼容约束为准，骨架照提示词要求由输入推导，禁止套用现有主题结构。
• 生成结果如包含 <a> 模拟按钮，转换时改为 <span>（公众号正文外链受限）。

第三步：转换为标准主题库并登记

用户确认预览风格后，把区块库转换为本 skill 的标准主题文件 references/theme-{标识}.md，必须完成：

1. 补 <span leaf=""> 包裹：生成器输出不含 leaf 标记，转换时所有文字节点包 <span leaf="">文字</span>，装饰性空元素内放 <span leaf=""><br></span>——这是粘贴不丢样式的前提，不能省。
2. 五个必备章节（同 SKILL.md「添加新主题的规范」）：
   • 设计变量速查表（从 THEME-* 元信息注释提取）
   • 各组件完整 HTML（从 Block 区块转换，保留区块中文命名，编组为组件族；数量可从区块库中精选核心 20~35 个，预览 HTML 保留全量）
   • 完整文章模板骨架（按该主题的结构模型排定装配顺序，明确目录/导航相对封面的位置）
   • 文章类型 → 组件组合配方表
   • Markdown → 组件映射规则表
3. 平台红线复查：剔除任何 class/id 依赖（预览 HTML 里的 id="block-*" 仅用于预览定位，进主题库的组件 HTML 一律去掉 id）、禁用标签、>24px 字号；table 只保留真实表格语义的。
4. 登记 theme-index.md：主题名 / 主色（THEME-COLOR）/ 适用场景（THEME-SCENE-TAGS）/ 组件库文件 / 正文下划线 CSS（从强调色或装饰色推导一条 border-bottom 样式）。
5. 跑检查：python3 scripts/component_lint.py . 须 0 ERROR；有 ERROR 修完再交付。
6. 交付汇报：主题名 + ID + 预览文件路径 + 已可在排版流程中选用；提醒用户可随时说「用 XX 主题排版」。

维护

• 用户要改已生成主题：改 theme-{id}.md（和预览 HTML 同步），重跑 component_lint。
• 用户要删主题：删 theme-{id}.md + 预览 HTML + theme-index 对应行。
• 主题名/ID 冲突：提示用户换名或确认覆盖。

---

【生成提示词】（原样使用，填入收集到的偏好后执行）

你是一个专业的微信公众号文章主题 Block 设计生成器。

你的任务是： 根据我提供的主题偏好信息，生成一份完整的 HTML 区块库文件。你可以参考现有的 wpwexin 主题文件理解输出格式、元信息结构、微信兼容约束与区块组织方式，但不能照搬任何现有主题文件的骨架、区块顺序、区块命名方式或版式组合。

目标不是生成一篇文章，而是生成一整套"可复用的主题 Block 样例 HTML"，用于文章排版、区块预览和主题选择。

你生成的"骨架"必须来自对以下信息的综合判断：主题描述、参考图、颜色系统、字体偏好、设计技巧 TAG、风格特征 TAG、适用场景 TAG、圆角偏好、阴影偏好。也就是说，区块体系、层级节奏、版式重心、信息密度、装饰方式、卡片形式、标题结构、流程表达、数据表达、媒体表达，都应由输入条件共同推导，而不是先套一个固定模板再换配色。

【骨架生成原则】

1. 你必须先根据输入信息推导"主题结构模型"，再生成区块库；禁止先选一个现成主题文件作为母版再做改写。
2. 所谓"主题结构模型"，至少要在内部完成以下判断：

• 该主题更偏内容叙事、信息说明、目录组织、情绪表达，还是数据展示
• 该主题适合高密度、多卡片、强分隔，还是低密度、大留白、弱分隔
• 该主题的标题体系更适合刊头式、栏目条式、文档章节式、标签索引式、便签贴纸式，还是其他更匹配的形式
• 该主题的媒体区、流程区、对比区、数据区、结尾区应采用什么视觉语法

3. 区块集合的组成比例必须受主题结构模型影响，例如：

• 杂志/ editorial 倾向：可增加刊头、摘要、编者按、拉页图文、引文页等骨架
• 文档/教程倾向：可增加目录、参数表、步骤条、说明卡、FAQ、检查清单等骨架
• 科技/系统倾向：可增加状态卡、指标条、终端式代码块、对照表、模块说明区等骨架
• 品牌/叙事倾向：可增加价值主张、故事段落、关系卡、证言样式、收束总结等骨架
• 手账/生活方式倾向：可增加便签、拼贴图、清单卡、日程条、碎片摘要等骨架

4. 即使不同主题都必须覆盖通用语义类型，也不能让它们仅仅变成"同一套区块换皮肤"。
5. 你可以参考现有主题文件的输出组织方式，但最终骨架必须在区块类型、区块命名、先后节奏、信息密度、容器形式、装饰语言上体现明显的主题差异。
6. 若输入信息不足，也必须先从现有输入中推导一个合理的骨架方向，而不是默认回退到 theme-mono-magazine 或其他现成主题的结构。

【输入信息】 我会提供以下字段，其中部分字段可能为空：

• 主题名称（可为空）
• 主题ID（可为空）
• 主题描述
• 参考图（可为空；如果提供，需要提取其视觉特征）
• 主题色
• 背景色（如无特殊要求，优先使用白色或接近白色的浅色背景）
• 正文色
• 强调色
• 装饰色
• 字体偏好
• 设计技巧（TAG，可为空，为空时需自动生成）
• 风格特征（TAG，可为空，为空时需自动生成）
• 适用场景（TAG，可为空，为空时需自动生成）
• 圆角偏好
• 阴影偏好

【主题名称与 ID 生成规则】

1. 如果用户没有提供"主题名称"，你必须根据整体风格自动生成一个中文主题名称。
2. 如果用户没有提供"主题ID"，你必须自动生成合法 ID。
3. THEME-ID 必须遵守以下规则：

• 必须以 theme- 开头
• 只能包含小写英文字母、数字、连字符 -
• 不允许包含空格、下划线、中文、特殊符号
• 长度控制在 12~40 个字符之间
• 要能体现主题特征，例如：
  • theme-mono-magazine
  • theme-mist-tech
  • theme-olive-journal
  • theme-soft-editorial

4. 如果用户已提供名称或 ID，优先使用用户提供值；只有缺失时才自动补全。

5. 主题名称、主题ID、主题描述三者要保持一致，不能互相冲突。

6. 如果用户没有明确指定背景色，或只给出模糊背景倾向，你应优先将 THEME-BACKGROUND-COLOR 设为白色或接近白色的浅色值（如 #FFFFFF、#FCFCFA、#F8F8F6），仅在主题描述或参考图明确要求深底、重氛围、反白体系时才使用深色背景。

7. 名称与 ID 可以参考现有主题的命名风格，但不能因此继承现有主题的结构骨架；命名相近不等于骨架相近。

【风格标签生成规则】

1. 如果用户没有提供"设计技巧（TAG）""风格特征（TAG）"或"适用场景（TAG）"，你必须根据主题描述、颜色、字体、圆角和阴影偏好自动补全。
2. 自动生成的标签应简洁、可读、可复用，优先使用 2~4 个中文短语，使用逗号分隔。
3. 三类标签应各自聚焦不同维度，避免重复：

• 设计技巧：偏版式、构图、装饰、信息呈现手法
• 风格特征：偏气质、视觉语言、审美倾向
• 适用场景：偏内容类型、行业场景、传播用途

4. 如果用户已提供标签，则优先保留用户输入；仅在为空时自动生成。

【字体偏好约束】 字体偏好只能从以下值中选择一个写入 THEME-FONT-PREFERENCE：

• system
• pingfang
• microsoft-yahei
• source-hans-sans
• source-hans-serif
• alibaba-puhuiti
• youshe-titlehei
• serif
• monospace
• kaiti
• fangsong
• stzhongsong
• stfangsong
• stkaiti
• yuanti

如果用户没有明确指定字体，或输入字体不在允许列表中，你必须根据主题风格从上面的列表中选择最合适的一项，不能输出列表之外的字体值。

【参考图使用规则】

1. 如果用户提供参考图，你必须先提取参考图中的视觉特征，包括但不限于：主色/辅助色、背景氛围、留白比例、构图节奏、边框与圆角、阴影强度、材质肌理、装饰元素、图形语言、信息密度和整体情绪。
2. 参考图只作为"风格参考"，不是内容复制来源。你必须将其转译为微信公众号 Block 区块库的配色、版式、装饰、卡片层级、提示框、标签、按钮、分隔线等设计语言。
3. 禁止复刻参考图中的具体文字、Logo、商标、人物、可识别版权主体或完整画面构图。
4. 如果参考图与用户文字偏好冲突，以用户明确填写的文字偏好为准；未填写的部分可由参考图补全。
5. 如果用户提供参考图，则直接根据图像本身提取视觉特征，不需要额外补充说明。

【输出目标】 请生成一份完整 HTML 内容，要求如下：

1. 文件开头必须输出主题元信息注释，格式严格如下：

2. 元信息之后，生成一整套完整的 Block 区块集合。 每个区块必须遵守以下规则：

• 使用注释标记区块名称，例如：
• 紧跟一个顶层 <section> / <figure> / <hr> 等结构
• 顶层元素必须带有稳定的 id
• id 命名统一采用： block-主题缩写-语义名 例如： block-mono-hero-card block-mono-numbered-chapter block-mono-code-block
• 主题缩写应与 THEME-ID 对应，保持一致性

3. 输出内容必须是"完整区块库"，而不是单一页面正文。 也就是说，需要覆盖文章排版常见场景，但"覆盖全面"不等于"固定骨架"；你必须根据主题结构模型决定哪些类别更重、哪些类别更轻、哪些类别需要细分出更多变体。 至少包含以下大类 Block：

• 头图 / Hero / 封面（开篇组件必须是 ENGINE「版式基线」的轻量导语条形态：栏目标签 + 一句话导语，无大字主标题/头图/落款；正文字号 ≥15px、卡片侧边 padding ≤14px、容器/模块侧边 ≤6px（HTML 每侧合计 ≤16px））
• 章节标题 / 小节标题 / 标签标题
• 正文段落 / 强调段落 / 行内代码段落
• 引用块 / 提示卡 / 警示卡 / 成功卡 / 信息卡
• CTA 区块
• 步骤卡 / 流程总览 / 时间线
• 图片 / 图片占位 / 双图对比 / 视频占位
• 代码块 / 浅色代码块
• 数据表格 / 指标卡 / 进度条
• 无序列表 / 有序列表 / 任务清单
• FAQ / 作者信息 / 联系方式 / 下载引导 / 延伸阅读
• 结尾总结区 / 末尾互动区

4. 区块内容必须是"展示型占位内容"，不要留空。 每个 Block 中都要有示例标题、示例段落、示例标签、示例数字、示例按钮文案，让它可直接用于预览。

占位内容要求严格如下：

• 只能生成"示意性占位文案"，用于展示版式结构，不要写成真实产品页面、真实宣传页、真实业务介绍或真实 UI 界面文案。
• 文案风格请参考现有标准主题文件：应更像"排版占位语""结构说明语""版式演示语"，而不是一个真实产品、真实专题页、真实落地页或真实 App 界面。
• 不要生成完整品牌名、产品名、城市名、国家名、机场名、人名、公司名、航班号、价格、日期、路线、站点、下载包名、功能模块名等真实感很强的具体信息。
• 不要输出类似 TRAVEL SERVICE UI、London、KMG、ISSUE 01、搜索航班、选座支付界面、资源下载 这类像真实产品界面或真实业务页面的文案。
• 不要把区块写成"首页界面、列表界面、支付界面、功能导航、业务入口、真实 CTA 落地页、真实下载页、真实产品卖点页"。
• 允许使用抽象占位表达，例如：主标题占位、章节标题占位、卡片标题占位、说明文字占位、按钮文案占位、标签占位、数字占位、图片说明占位、流程步骤占位、引用内容占位。
• 更推荐使用接近标准文件的写法，例如：专题导语占位、结构说明占位、阶段标题占位、重点信息占位、正式说明占位、流程节点占位、案例说明占位、结尾引导占位。
• 如果需要模拟数据、按钮、标签、导航、章节、表格、流程或指标，请一律使用"结构占位 + 语义占位"的写法，而不是具体业务内容。
• 所有占位内容都应服务于"看结构、看层级、看风格"，而不是让人误以为这是某个真实行业页面的成品文案。

5. 风格必须由输入偏好驱动：

• 颜色体系必须围绕主题色、背景色、正文色、强调色、装饰色展开；若用户未对背景提出明确要求，应默认采用白色或接近白色的浅背景，并通过边框、留白、浅色层、装饰色来建立层级，而不是依赖整页深色底
• 字体偏好必须体现在 font-family 倾向上，但元信息中的字体值必须严格使用允许列表值
• 设计技巧 TAG 必须影响排版手法，例如：杂志风、卡片化、几何、极简、文档站、终端感、票据感、拼贴等
• 风格特征 TAG 必须影响具体视觉，例如：高对比、柔和、留白、纸感、科技感、拟物、活泼、理性、克制等
• 适用场景 TAG 必须影响内容语气和组件语义，例如：杂志、教程、科技、金融、品牌、产品介绍、生活方式、手账、文档、作品集等
• 圆角偏好必须影响 border-radius
• 阴影偏好必须影响 box-shadow，若为"无"则尽量不用阴影

6. 生成的区块必须具备一致性：

• 所有区块应属于同一主题体系
• 在无特殊要求时，整体版面应以白底或近白底为主，只在局部卡片、提示块、标签、强调区中使用主题色或浅色衬底，避免整套区块库大面积深色铺底
• 相同视觉语言反复出现，例如边框、标签、分隔线、按钮、标题条、装饰符号
• 不要出现风格冲突
• 骨架层级也要一致：如果主题偏克制理性，就不要混入过多舞台化封面结构；如果主题偏杂志叙事，就不要全部退化为统一卡片列表；如果主题偏文档说明，就不要把所有区块都做成情绪化视觉海报

7. 必须大量使用 inline style，保持和现有 wpwexin 主题文件一致。

• 如果提供了参考图，需直接根据该图像本身的视觉气质转译到区块设计中，但不能照搬图片内容
• 不要输出 <style> 大段样式表
• 主要通过元素内 style 完成视觉表达
• 可使用 section 嵌套、figure、figcaption 等方式增强微信兼容性，但不要把 table / tr / td 作为主要布局骨架
• 所有文字相关元素的 font-size 必须控制在 24px 及以下，禁止出现大于 24px 的字号；即使是头图主标题、封面数字、强调数据、CTA 主文案也必须遵守该限制

7.1 生成结果必须以"复制到微信公众号编辑器后可最大程度 100% 还原"为最高优先级，所有结构与样式都必须优先服从微信编辑器兼容性，而不是服从网页语义完整性或现代 CSS 写法。

7.2 标签与结构兼容规则：

• 优先使用：section、p、span、img、figure、figcaption、hr、br、strong、em、code、a。
• 可以使用少量嵌套 section 作为容器。
• 如需稳定的横向信息组织、双列内容感或并排对照，请优先通过"上下堆叠 + 明确分组 + 分隔线/留白/边框"的方式表达，而不是把 table / tr / td 当作页面布局工具。
• table 仅可在"确实是数据表格"这一语义下使用，例如参数表、对照表、字段表；禁止用 table、tr、td 承担卡片栅格、按钮排布、图文并排、整体页面分栏等布局职责。
• 顶层区块保持单一、稳定、可复制，不要依赖外层全局容器。

7.3 样式兼容规则：

• 所有关键视觉必须写在元素自身的 style 中，不能依赖 class、外链样式或全局样式继承。
• 优先使用稳定、常见、简单的 CSS 属性，例如：margin、padding、color、background、background-color、font-size、line-height、font-weight、text-align、border、border-radius、display、width、height、max-width、min-width、box-sizing。
• 如非必要，不要使用复杂 CSS 缩写、变量、高级选择器或依赖浏览器完整实现的写法。
• 阴影、渐变、圆角、边框都可以使用，但必须克制，并保证即使部分样式退化，结构依然成立。

7.4 禁止或谨慎使用的能力：

• 不要使用 <style>、<script>、form、input、button、textarea、select、video、audio、canvas、svg、iframe。
• 不要使用 JavaScript 事件、动画、悬停态、过渡、滤镜交互、粘性定位、固定定位。
• 不要使用 CSS Grid、复杂 Flex 布局、position: sticky、position: fixed、backdrop-filter、CSS 变量、伪元素、媒体查询。
• 不要把 table、tr、td 用作通用页面布局、分栏布局、按钮编排、卡片宫格或图片区块骨架；它们只应在真实表格语义下出现。
• 不要依赖 aspect-ratio、object-fit、gap、z-index、复杂绝对定位层叠来完成核心布局；这些能力即使出现，也不能成为结构成立的前提。
• 不要生成任何需要点击后才成立的交互式组件；所有区块都必须是静态内容即可成立。

7.5 图片与媒体兼容规则：

• 图片必须使用标准 img 标签，并提供明确宽度语义，保证复制后仍能独立显示。
• 图像占位必须使用 https://placehold.orence.net/宽x高?text=占位文字（尽量使用英文） 格式的占位 URL，支持通过 URL 配置占位图的尺寸（如 /600x400、/400、/600x400@2x.png）、格式（如 /600x400/png、/600x400.png）、颜色（如 /600x400/000000/FFFFFF、/600x400/orange/white、/600x400/transparent/F00）、文字（如 /600x400?text=你好+世界、/600x400?text=第一行\n第二行）和字体（如 /600x400?font=cn、/600x400?text=封面图&font=roboto），例如可直接使用 /600x400、/600x400/0f172a/e2e8f0?text=你好+世界、/600x400/0f172a/e2e8f0/png?text=商品主图&font=cn、/1200x630@2x.webp?text=社交分享图。
• 图片标签应使用 max-width:100%;height:auto;display:block;margin:0 auto; 按图片自身尺寸自适应显示并居中（不要用 width:100% 强制铺满）。
• 图片应使用固定高度或稳定比例思路来设计展示区域，避免复制到公众号编辑器后出现比例错乱；如需定高，可直接写 height；如需比例感，应通过稳定容器或占位图本身尺寸体现，而不要依赖复杂 CSS。
• 每个图片都必须提供合适的 alt 属性，内容应与图片区块语义一致或语义接近，例如 alt="头图占位"、alt="双图对比占位"；允许 alt 使用中文。
• 视频区块只能做"静态视频占位"，不要输出真实 <video>、iframe 播放器或交互控件。
• 图表、可视化、流程图等内容必须降级为静态占位图/静态区块，不要依赖脚本或 SVG 渲染。

7.6 文案与组件兼容规则：

• 按钮本质上应使用带样式的 a 或 span 模拟，不要使用真正的表单按钮组件。
• 代码块、数据卡、流程条、目录卡、双栏对照、FAQ、作者卡、CTA、下载引导等，都必须在"纯静态 HTML + inline style"下成立。
• 即使用户要求"像 App 界面""像网页组件"，你也只能输出适合微信公众号富文本粘贴的静态视觉模拟，而不能输出真实 Web 组件结构。

7.7 自检要求：输出前你必须在内部自检一次，确保生成结果满足以下条件：

• 复制到微信公众号编辑器后，不依赖外部 CSS/JS 仍能保留主要视觉层级
• 没有使用被明确禁止的标签或交互能力
• 没有依赖复杂现代 CSS 才能成立的核心布局
• 即使部分样式轻微退化，内容结构、阅读顺序、视觉重点依然完整

8. 输出必须是纯 HTML 内容，不要解释，不要加 Markdown 代码围栏，不要加"下面是生成结果"等说明。

9. 不要偷懒，不要只生成 10 个区块。 请生成"完整主题区块库"，区块数量建议 45~75 个，覆盖一个成熟主题该有的层次。 但这些区块不应表现为固定菜单式罗列；应根据主题结构模型形成有主次的区块谱系：有些主题更强调章节与引文，有些更强调流程与参数，有些更强调图文叙事与结尾收束。

10. 区块命名要具体，不要都叫"标题块""卡片块"。 要根据风格命名，例如：

• 杂志风：封面刊头、栏目条、头版摘要、编辑按语
• 科技风：状态面板、信号条、监控卡、终端日志
• 文档风：横向目录、说明卡、流程条、参数表
• 手账风：便签卡、胶带标题、拍立得图片、票据摘要
• 品牌风：品牌叙事卡、Logo 墙、案例证言、资源下载条

11. 生成区块时遵守"语义优先"原则：

• hero
• navigation
• title hierarchy
• paragraph
• quote / notice
• list
• media
• code
• data
• compare
• process
• faq / resource / author / cta / ending 这些语义必须被完整覆盖。

11.1 语义完整覆盖不代表每一类都必须以完全相同的权重和标准件数量出现；你应根据主题结构模型分配重点，并让具体实现形式发生变化。 例如同样是 title hierarchy，杂志风可偏刊头与栏目条，文档风可偏章节编号与横向目录，手账风可偏贴纸标题与便签页签。 例如同样是 data，科技风可偏指标卡和状态表，品牌风可偏关系数据摘要，生活方式风可偏轻量信息条而不是厚重参数矩阵。

12. 输出中的占位文案，要符合该主题的语气，但仍然必须保持"占位文案"属性，不要写成真实业务页面内容。 例如：

• 杂志风可以写成"专题导语占位 / 栏目说明占位 / 编辑按语占位 / 头版摘要占位"这类抽象表达，而不是某本真实刊物的内容
• 科技风可以写成"能力说明占位 / 参数说明占位 / 状态信息占位 / 节点链路占位"，而不是具体产品功能页文案
• 暖感品牌风可以写成"品牌叙事占位 / 价值说明占位 / 关系表达占位 / 结尾引导占位"，而不是具体品牌宣传语
• 允许有风格气质，但不允许出现"真实行业页面感"过强的文案；最终效果应接近 theme-mono-magazine.html 中那种"结构化占位 + 风格化表达"的程度

13. 如果用户没有提供主题名称和主题 ID，你应先在内部完成命名，再输出最终 HTML，不要先输出解释文字。
14. 再次强调：禁止把 theme-mono-magazine.html 或其他现有主题文件当作可替换文案的固定模板。你只能借鉴其"输出规范"，不能继承其"内容骨架"。最终结果必须让人看出它是由本次输入偏好专门推导出来的主题区块库。

请现在根据我提供的偏好，生成完整 HTML。