Wechat article generator

Skill: 微信公众号文章生成器

核心用途

把用户输入的主题、草稿、Markdown、素材或正文，先整理成一份可审阅、可复用、可转 HTML 的公众号发布源稿，再收束为最终 HTML。

本技能的默认外部交付顺序固定为两层：

• 对话中的发布源稿审阅结果
• 最终对应的 HTML

当用户明确要求输出微信封面图时，在保持以上主交付顺序不变的前提下，可在最终 HTML 生成完成后追加一个可选封面图分支；该分支不改变主任务，也不阻塞 HTML 主交付。

其中，发布源稿的固定四部分为：

• title：公众号标题，长度不得超过 64 字
• summary：公众号摘要，长度不得超过 120 字
• cover_prompt：用于生成或设计封面的完整提示词，始终必填
• markdown：标准微信公众号正文 Markdown

默认约束：

• 用户可见中间结果只放在当前对话中；执行中间结构只允许存在于执行内存，或由同一执行上下文的内存生产者直接供应给渲染脚本的标准输入中，不得在任何位置新建中间 Markdown、JSON、说明文档、临时目录、隐藏文件、备份文件或其他过程文件。
• 用户没有明确要求文件落地时，不调用写文件流程，不额外占用用户工作区资源。
• 技能执行必须自包含：只允许依赖当前技能目录内规则、资产、脚本与用户本轮提供内容，不得把技能目录外的示例、dataset/、历史校准文件或外部页面当作运行前提。
• 内容确认后，最终要输出对应的微信兼容内联样式 HTML。
• 使用内置主题时，组件样式必须以本技能内部沉淀的主题规范与预设为权威标准，不允许只做“相近风格”近似。
• 源稿中的 title、summary、cover_prompt 与 markdown 必须彼此一致，不能各说各话。
• cover_prompt 是发布源稿的必要字段，不因用户“不需要封面”或“只关心正文”而省略；它可以不作为当前轮对话的重点展示，但在内部源稿与 source.md 中必须存在。
• 最终 HTML 只渲染面向读者的内容：title、summary 与 markdown；cover_prompt 只属于源稿元数据，不进入最终 HTML。
• 正文 Markdown 必须忠于原文，不得擅自改写事实、数字、引用、顺序关系、措辞立场或用户明确要求保留的表达。
• 正文 Markdown 必须已经满足公众号内容排版与后续 HTML 转换要求，不能把结构问题留到 HTML 阶段再补救。
• 正文 Markdown 不仅要“可转 HTML”，还要已经具备微信公众号可读性：层级清晰、段落整齐、重点明确、视觉节奏稳定，不能只是机械转写。
• 正文 Markdown 生成前必须先完成内容理解、信息单元抽取、结构组织与发布级排版审校；不得把原文机械分段后直接当作成稿。
• 正文 Markdown 是最终读者会看到的正文基准，只能承载对用户输入内容的忠实汇总、总结、重组和必要衔接；不得写入源稿文件、封面提示词、原始链接保留位置、二次编辑、复核路径、导出文件、执行过程或资产管理说明。

路由总则：

• 用户明确要求“只要最终 HTML，不要任何中间整理过程或说明”时，优先使用 wechat-html-composer。
• 只有用户明确点名本技能，或明确需要“边整理边确认”“先看发布源稿”“保留 source.md”“输出标题/摘要/封面提示词/正文四段结果”时，才继续使用本技能。
• 后文凡涉及“是否转交 wechat-html-composer”，都以本路由总则为准，不再重复发明额外判断口径。

本地资源与权威顺序

1. SKILL.md：定义触发、边界、默认流程、门禁和交付要求。
2. references/render-contract.md：定义发布源稿、内部结构与最终 HTML 的映射契约。
3. references/theme-spec.md：定义每个主题的组件职责、结构语法和禁止漂移项。
4. references/content-format-standard.md：定义发布源稿细则、正文 Markdown 语法与公众号可读性标准。
5. references/quality-gates.md：定义完整交付检查清单，供交付前复查。
6. references/maintenance-checklist.md：定义修改本技能或资源后的复评步骤。
7. assets/theme-presets.js：对脚本渲染有效的样式 token，必须与 references/theme-spec.md 保持一致。
8. references/usage-walkthroughs.md：提供代表性场景走查，不补充核心规则。
9. scripts/render-wechat-article-html.js：用户明确要求文件落地时必须使用的确定性导出脚本；可写出 final.html，也可按模式写出 source.md + final.html。文件落地结果不得由执行者自由手写 HTML 代替。
10. scripts/render-wechat-article-theme-batch.js：用户明确要求多个主题或多份主题 HTML 落地时必须使用的批量确定性导出脚本；复用单主题渲染链路，以同一份已确认源稿写出多份主题 HTML，并在需要时只写出一份 source.md。
11. 当前运行环境中已可用的图像生成能力：只在用户明确要求输出微信封面图时作为环境增强能力使用；它不是本技能主链路前提，缺失时不得影响 HTML 主交付。
12. scripts/verify-render-wechat-article-html.js：只在修改脚本或落地链路后做回归验证时使用。

若规则冲突，以上方顺序靠前者为准。

自包含边界

本技能必须在自身目录内闭环完成，不得把技能目录外资源变成隐性依赖。

允许依赖：

• 用户当前提供的正文、素材、草稿、Markdown、截图转写结果或本地文件内容。
• 当前技能目录内的 SKILL.md、references/、assets/、scripts/、_meta.json。
• 当前运行环境中已可用的图像生成能力，但仅限用户明确要求输出微信封面图时作为环境增强能力调用；它不是本技能主链路前提。

禁止依赖：

• 技能目录外的 dataset/、样式样刊、示例仓库、历史评审文档或其他技能目录文件。
• 需要执行者“再去参考外部模板”才能确定主题组件长相的流程设计。
• 用技能目录外资料修补本技能内部规则缺口，然后仍宣称本技能自包含。

执行准则：

• 若技能目录内规则已经给出主题锚点，必须直接按内部规则执行，不得再向外找“更像”的样例。
• 若内部规则不足以支撑某个额外风格请求，必须明确降级到内置主题或拒绝该附加风格，不得引入外部依赖补齐。
• 若用户明确要求输出微信封面图，则执行者必须自行判断当前运行环境中是否存在已可用的图像生成能力；存在时才进入封面图生成，缺失或不可用时只能判定封面图分支未完成，不得向用户询问当前环境是否具备图像生成能力，不得反向影响 HTML 主链路或改写本技能自包含主闭环。
• 若用户明确要求文件落地，则最终写入工作区的 HTML 发布资产必须由本技能目录内的确定性渲染链路产出并通过对应验证；多个主题或多份主题 HTML 必须使用批量确定性导出脚本。不得由执行者自行编写、改写或拼接最终 HTML 文件代替。
• “自包含”指执行闭环自包含，不禁止 _meta.json 中存在展示性质的主页链接，但该链接不得成为执行前提。

核心原则

1. 对话优先：用户可见中间输出只出现在当前对话；执行中间结构只允许存在于执行内存，或由同一执行上下文的内存生产者直接供应给渲染脚本的标准输入中，不转存为任何文件。
2. 源稿先行：必须先整理出四段式公众号发布源稿，再进入 HTML 阶段。
3. HTML 收束：内容确认后的最终交付必须是对应 HTML，而不是 Markdown、JSON 或路径说明代替品。
4. 落盘显式化：只有用户明确要求输出路径、目录或文件落地时，才进入写文件分支。
5. 先忠实整理，后视觉排版：先把内容讲清楚、讲准确，再决定标题、摘要、章节和块位。
6. 主题固定，内容动态：主题负责视觉语法，内容决定哪些块位出现。
7. 微信兼容优先：只使用公众号复制链路更稳定的基础标签和内联样式。
8. 事实审慎：涉及日期、数据、价格、政策、版本、产品能力等可变事实时，优先使用用户提供来源；无法核验时降低确定性表达。
9. 不堆过程资产：不为了“留痕”新建过程文档、草稿文件、临时目录或等价资源。
10. 规范即标准：主题一旦确定，references/theme-spec.md 和 assets/theme-presets.js 中已固化的组件样式就是标准答案；标题、导语、提示块、章节标题、引用、列表、表格、题注、代码块等都要对齐。
11. 禁止主题漂移：不得把某一主题的组件借给另一主题使用，例如把 codex-template 的左强调线二级标题放进 feishu-template。
12. 未映射即回退微信原生：若当前主题无法映射用户请求的组件或结构，必须整篇自动切换到 wechat-native-template，不允许继续自拟样式，也不允许局部偷回退到其他主题语法。
13. 严格配置映射：主题输出只能从 assets/theme-presets.js 的 preset 与 references/theme-spec.md 的组件锚点直接映射，不允许执行者按“类似某主题”的主观理解临时改色、改底、改对齐、改块型。
14. 源稿一致性优先：如果“更像公众号文风”和“更忠于原文”冲突，优先保留原文事实、语义和立场，再只做最小必要排版整理。
15. 最终 HTML 必须可验证：无论直接在对话中输出还是写入文件，最终 HTML 都必须由已确认源稿、内部文章结构、references/theme-spec.md 与 assets/theme-presets.js 映射得到，并满足本技能已有验证规则；不得把“看起来像对应主题”的自由生成 HTML 当作合格结果。
16. 封面分支状态必须显式：只要用户明确要求封面图，本轮最终交付必须显式说明封面图分支状态；状态固定为“已生成并交付”“未生成”“已生成但未写入”三类，不得静默跳过。

能力边界

适用场景：

• 用户给要点、素材、草稿、Markdown 或正文，希望先在对话里整理，再输出公众号 HTML。
• 用户希望先得到一份标准发布源稿，再确认是否转 HTML。
• 用户希望先看到标题、摘要、封面提示词、正文结构和风险点，再确认是否输出 HTML。
• 用户明确点名本技能，要求中间过程放在对话里。
• 用户最终可能需要 HTML 文件或 source.md + final.html 落地，但希望先在对话里把内容整理清楚。
• 用户通过文字明确提出“根据 xxxx 内容生成源稿、封面/封面图/微信封面/微信封面图、xxx 风格/主题/样式的 HTML”，且封面图只是随同文章交付的附加产物。

不适用场景：

• 用户只要最终 HTML，不要任何中间整理过程；此时优先 wechat-html-composer。
• 用户只要大纲、标题建议、选题建议或纯 Markdown，不要求最终 HTML。
• 用户只要求封面图、海报、插画或公众号后台发布，而不要求发布源稿或最终 HTML。
• 用户要求抄袭、洗稿、规避原创检测或伪造来源。

触发归一规则：

• 用户只提“生成公众号 HTML”“排版成公众号文章”“给我最终 HTML”，且没有要求审阅、四段式源稿、source.md、标题摘要封面提示词确认时，按上文路由总则优先 wechat-html-composer。
• 用户提到“先确认”“先看标题摘要”“先看封面提示词”“先整理源稿”“保留可复用稿”“输出 source.md”时，优先当前技能。
• 用户请求本身同时包含“最终 HTML”和“发布源稿/四段式源稿/source.md”时，必须使用当前技能，不转交。
• 用户通过文字同时要求“源稿 + 封面/封面图/微信封面/微信封面图 + HTML”，且封面图是文章交付的附加产物时，必须使用当前技能，不转交。
• 用户要求“根据这篇文章生成源稿、HTML 和配套封面图/微信头图/公众号封面”时，视为文章配套封面图，使用当前技能。
• 用户只要求“生成一张封面图/海报/插画/头图”，且没有要求发布源稿或最终 HTML 时，不使用当前技能，应转交图像生成或设计类能力。

输入识别

执行前提取以下信息：

• 内容来源：正文、Markdown、要点、素材、聊天记录，或本地文件路径。
• 输出模式：默认 conversation-review-html；只有用户明确要求路径或文件时才切到文件导出分支。
• 文件导出类型：html-file-export 或 source-html-export。
• 是否需要批量导出多个内置主题：默认否；只有用户明确要求多个主题或多份主题 HTML 时才进入批量主题导出分支。
• 是否要求输出微信封面图：默认否；只有用户通过文字明确要求封面图交付时才切到封面图附加分支。
• Markdown 整理模式：是“忠实排版整理”还是“允许在不改变事实前提下做轻度润色”。
• 风格主题：用户指定的主题名、中文风格描述，或默认主题。
• 内容约束：标题、读者、长度、语气、必须保留的信息、必须删除的信息。
• 风险事实：是否包含需要核验的时间、数据、政策、价格、版本或产品能力。
• 主题权威规则：一旦主题确定，必须定位到 references/theme-spec.md 中对应主题的组件约束。

执行时先把以上信息一次性归一化为当前轮的统一执行上下文，后续步骤只消费该上下文，不再重复从用户原话二次推断任务模式、主题模式、是否审阅、是否落盘、是否多主题或是否需要封面图。

阻塞性缺口只追问一次，最多 3 个问题：

• 主题或任务目标完全不清楚，无法判断文章要写什么。
• 用户明确要求文件落地，但没有给路径，也没有允许你代定路径。
• 用户要求必须保留或必须删除的内容彼此冲突，已经影响最终成稿。

默认规则：

• 用户未指定主题时，使用 wechat-native-template。
• academic-paper-template 是论文主题的规范名称；未指定主题时，默认样式固定为 wechat-native-template。
• 用户未指定读者时，默认面向“对该主题有实际阅读需求的公众号读者”。
• 用户未指定字数时，按手机端舒适阅读长度自动控制。
• 用户指定的主题若命中内置主题，必须读取本技能内对应的主题规则；不能只凭名字或记忆输出。
• 用户未明确允许改写时，默认采用“忠实排版整理”，只做结构重排、断句、标题层级整理、列表化和必要的微信公众号排版整理，不主动改写原意。
• 用户未指定文件导出类型、只说“落盘”或“导出文件”时，默认写出 final.html；只有用户明确要求“源稿也要保存”“输出 md + html”“保留可再编辑稿”时，才进入 source-html-export。
• 用户明确要求多个主题或多份主题 HTML 时，适用以下多主题总则：同一份已确认源稿是唯一内容基准；非落地时按同一内部结构逐主题映射，落地时必须使用批量确定性导出脚本；不得为每个主题自由重写正文、重造结构或手写最终 HTML。
• 用户使用“全部”“各种主题”“各主题”“全部主题”“所有主题”“全主题”“每种主题”“所有内置主题”“内置全部主题”“全部内置主题”“所有风格”“全部风格”“各种风格”“各种主题风格”“所有内置风格”“内置全部风格”“全部内置风格”且未列出具体主题名时，必须归一化为全部内置主题，而不是执行者自行挑选部分主题；全部内置主题固定以 assets/theme-presets.js 的 themes 键为准，且必须包含 academic-paper-template。

发布源稿标准

发布源稿是本技能的第一核心交付物，必须固定为以下四部分：

• 标题：用于公众号标题展示，长度不得超过 64 字
• 摘要：用于公众号摘要或导语区，长度不得超过 120 字
• 封面提示词：用于生成或设计封面的完整中文提示词，应包含主体、风格、构图、色调、文字处理要求和禁用项
• 正文 Markdown：用于正文排版与最终 HTML 渲染的标准 Markdown 正文

发布源稿、正文 Markdown 与公众号可读性细则必须符合 references/content-format-standard.md。主文件中的四字段和长度要求是硬约束；参考文件只展开整理细则，不改变主流程。

执行流程

Step 1：识别任务与输出模式

先判断用户要的是：

• 对话整理后输出 HTML
• 对话整理后再决定是否输出 HTML
• 对话整理后落盘 HTML 文件
• 对话整理后落盘 source.md + final.html

模式定义：

• conversation-review-html：先在对话中给出四段式发布源稿供审阅，确认后再输出最终 HTML。
• html-file-export：在对话中完成源稿确认后，只落盘 final.html。
• source-html-export：在对话中完成源稿确认后，落盘 source.md + final.html。

Step 1 的目标是一次性产出本轮统一执行上下文，至少锁定以下结果：

• 是否继续使用当前技能，或转交 wechat-html-composer
• 最终输出模式
• 是否默认对话审阅四段式源稿
• 是否需要 source.md
• 是否需要 final.html
• 是否需要批量主题导出
• 是否需要微信封面图分支
• 正文整理策略
• 风险事实等级

一旦以上结果确定，后续步骤不得重复回到用户原话重新判断同一问题；只有在阻塞性缺口出现时，才允许按本技能既有追问规则补问一次。

若用户明确要求多个主题或多份主题 HTML，不新增输出模式；它只是在 conversation-review-html、html-file-export 或 source-html-export 上追加“同一份已确认源稿 + 多个内置主题映射”的批量主题约束。若用户同时要求保留源稿，仍只保留一份 source.md。

若用户明确要求“不要中间过程，只给最终 HTML”，按以下顺序处理：

• 用户未点名当前技能，且未要求源稿、四段式结果或 source.md：按上文路由总则优先转交 wechat-html-composer。
• 用户已明确点名当前技能，或同时要求保留源稿资产：继续使用当前技能，但只在内部完成四段式源稿整理，不默认在对话中展开四段内容，直接输出最终 HTML；只有用户再次要求审阅时，才回显发布源稿。

在进入内容整理前，先完成一次性主题决议：

• 将用户主题名或中文主题描述归一化到内置主题名。
• 打开 references/theme-spec.md 与 assets/theme-presets.js，只提炼本轮实际会用到的主题组件约束，后续不再反复回读整份主题规范。
• 若用户未指定主题，默认使用 wechat-native-template 规则。
• 若用户明确要求多个主题，则逐一归一化到内置主题名；未命中的主题不补外部依赖，只能降级到 wechat-native-template 或拒绝该附加主题。
• 若用户以“各种主题”“全部主题”“所有主题”“全主题”“每种主题”或等价内置集合词要求多个主题，则直接展开为全部内置主题；展开结果不得漏掉 academic-paper-template，也不得把集合词理解为任选若干常用主题。

主题决议一旦完成，后续所有正文整理、内部结构收束、HTML 生成、批量导出与质量检查都只能基于该决议结果执行，不再重新解释主题含义或临时发明“相近风格”。

多主题总则一旦触发，后续所有生成、导出、校验与失败处理都只允许改变主题映射，不允许改变源稿内容基准、结构化文章语义或验证口径；后文凡涉及多主题，均以此总则为前提，只补充本阶段特有约束。

同时确定正文整理策略：

• 若输入已经是连续正文或较完整 Markdown，默认以“忠实整理”为主，不改原意。
• 若输入是要点、摘录、聊天记录或碎片素材，先只做信息归并与顺序整理，再成稿为标准正文 Markdown。
• 若用户明确要求润色、压缩、扩写、重写，必须先锁定哪些内容可改、哪些事实不可改。

Step 2：先整理出四段式发布源稿

这是本技能的第一核心交付步骤，必须先完成。

发布源稿必须同时满足三类要求：

• 内容忠实：与原文事实、数字、引述、判断关系、语气边界保持一致。
• 可转 HTML：标题、摘要、正文结构已经符合后续 HTML 转换要求。
• 可复用：四部分信息足以独立复现这篇公众号文章的源稿资产。

执行规则：

1. 先抽取原文中必须保留的信息单元：
   • 标题或核心主题
   • 所有明确事实、数字、时间、引用、结论
   • 用户明确要求保留的措辞、段落或顺序
2. 再归一化为四段式源稿：
   • title：压缩到 64 字内，且不损失主旨
   • summary：压缩到 120 字内，且完整交代主题与价值
   • cover_prompt：根据文章内容生成完整封面提示词
   • markdown：整理成标准正文 Markdown
3. 正文 Markdown 生成前必须按以下三层顺序完成成稿整理门禁：
   • 先定内容基准：理解原文核心问题、事实链、论证顺序、情绪边界和用户明确保留项，并抽取必须保留的信息单元，包括事实、时间、数字、引用、判断、因果关系、并列关系和限制条件
   • 再定结构层：确定导语、主章节、子章节与收尾顺序，组织 ## 与必要的 ###，章节标题必须准确、具体、有信息量，不得使用“第一部分 / 第二部分 / 其他说明”这类空标题
   • 再定呈现层：为同类信息固定 Markdown 呈现方式，决定每个信息单元进入段落、列表、引用、表格、代码块或图片说明；同类信息必须同构呈现，不把并列信息挤进逗号链，也不把散文硬拆成伪列表
4. 在三层整理完成后，再按最终 HTML 呈现效果反推正文结构，确保导语、章节、列表、表格、引用和收尾在套用任一内置主题后仍然美观、大气、克制、层级清楚，不把视觉秩序问题留给 CSS 硬救，并完成发布级排版审校，检查段落长度、层级、节奏、留白、重点呈现、同类内容排版一致性、手机端连续阅读体验和最终 HTML 的视觉节奏
5. 若输入自带 # 标题或前置摘要：
   • 抽取标题进入 title
   • 抽取可复用摘要进入 summary
   • 从正文 Markdown 中移除重复元数据
   • 无论用户是否要求封面，仍必须生成 cover_prompt
6. 未经用户允许，不做以下动作：
   • 擅自增删事实
   • 擅自改写结论立场
   • 擅自合并有区别的数字或时间
   • 擅自替换引用原话
7. 发布源稿阶段必须避免以下问题：
   • 标题、摘要、正文彼此不一致
   • 为了“更像公众号标题”而偷换原文主旨
   • 让 cover_prompt 变成空泛标签堆砌，无法作为封面生成或设计的完整语义基准
   • 把多个层级混成连续大段
   • 用视觉描述代替结构标记
   • 用“第一部分 / 第二部分 / 其他说明”之类空泛标题敷衍章节设计
   • 同类内容前后使用不同排版形态，造成段落、列表、引用、表格或提示块混用
   • 在正文、引用、提示块、表格说明或收尾中写入 source.md、final.html、cover_prompt、封面提示词、源稿文件、原始链接信息保留、后续二次编辑、复核路径 等面向执行过程或源稿资产的说明

正文 Markdown 允许的主要结构：

• ## / ###
• 普通段落
• 无序/有序列表
• 引用块
• 表格
• 代码块
• 图片占位说明

发布源稿阶段必须额外自检：

• 标题是否不超过 64 字，且足够清楚。
• 摘要是否不超过 120 字，且不是空话。
• 封面提示词是否能作为封面生成或设计的完整语义基准。
• 去掉最终 CSS 后，正文结构是否仍然成立。
• 套用最终 HTML 主题后，正文是否仍然美观、大气、规范，是否存在大段堆叠、无意义提示块、过密表格或节奏失衡。
• 同类内容是否使用同一种 Markdown 结构，列表项、同级标题、引用和表格是否前后一致。
• 正文是否只总结用户输入信息本身，是否完全排除了源稿、封面提示词、文件路径、原始链接保留位置、二次编辑或复核说明等元信息。
• 交给另一个执行者时，是否能不猜测原文意图而稳定转成 HTML。

Step 3：在对话中展示并确认发布源稿

中间整理结果只在对话中出现，默认应先展示四段式发布源稿；必要时再附极简结构说明。

默认展示格式：

标题：{内容的标题}
摘要：{内容的概括}
封面提示词：{根据内容给出制作封面的完整提示词}
正文：
{标准 Markdown 正文}

默认最小确认点应覆盖：

• 文章定位：写给谁，核心要讲什么。
• 标题与摘要是否准确，且长度合规。
• 正文 Markdown 的章节结构是否准确。
• 原文中哪些事实、案例、观点已保留。

仅在以下情况出现时，才扩展确认封面提示词、风险事实表达、主题适配或多主题共享基准：

• 存在高风险事实
• 用户明确要求微信封面图
• 用户明确要求多个主题或多份主题 HTML
• 用户明确要求保留 source.md
• 用户明确要求强保留原措辞、顺序或立场

禁止动作：

• 不生成中间 Markdown 文件。
• 不生成中间 JSON 文件。
• 不生成说明文档、临时目录、隐藏 staging 文件、备份文件或其他过程文件。
• 不为了整理过程向任何位置写入额外文件。
• 不把“内部结构对象”作为对用户的主要交付格式。
• 不跳过源稿审核直接凭印象输出 HTML。

如果信息已经足够，允许把结构说明压缩到最小，但在 conversation-review-html 模式下，四段式源稿本身仍然是默认第一中间产物；只有在“用户明确不要中间过程且仍坚持使用本技能”的特殊分支下，才允许只在内部保留四段式源稿而不对话展开。

Step 4：把发布源稿收束为内部文章结构

按 references/render-contract.md 的契约，把已确认的发布源稿收束为内部文章结构。该结构只允许存在于执行内存，或由同一执行上下文的内存生产者直接供应给渲染脚本的标准输入中；若需要用户审阅，只能在对话中以标题、摘要、章节和收尾清单的形式呈现，不得落成原始 JSON 或其他过程文件。

整理时必须做到：

• 以已确认的四段式源稿为唯一内容基准，而不是回到原始碎片重新自由组织。
• 把 summary 视为导语或摘要区的直接来源。
• 把正文 Markdown 中的段落、列表、引用、表格、代码块准确映射为内部结构。
• cover_prompt 只保留在源稿或导出文件中，不进入 HTML 节点树。
• 不允许未知块类型、空章节、空标题或空列表进入最终 HTML。
• 对应主题规范里已有的组件，必须沿用该组件的结构和样式语法，而不是临时发明新组件。
• 若某主题规范中存在 eyebrow、提示块 callout、表格题注、关键词行或论文式前置信息，优先按该主题规范组织，而不是一律压平为普通段落。

Step 5：生成对应 HTML

当信息足够且不再等待确认时，必须先生成对应 HTML；未要求文件落地时在当前回复中直接交付完整 HTML，已要求文件落地时把生成结果交给 Step 7 写入最终文件。

生成要求：

• 未要求文件落地时，默认直接输出完整 HTML，而不是“稍后可生成 HTML”的说明。
• 已要求文件落地时，本步骤只完成 HTML 生成与验证准备，实际写入统一由 Step 7 处理。
• 不额外输出 JSON、Markdown 草稿、过程解释或样式说明。
• 最终 HTML 必须忠实反映已经确认的 title、summary 与 markdown，不得在 HTML 阶段再偷偷改写内容。
• cover_prompt 不进入最终 HTML。
• HTML 必须符合 references/render-contract.md 的兼容约束。
• 最终 HTML 必须由已确认源稿收束出的内部文章结构和当前主题规范映射得到；不得绕过 references/theme-spec.md 与 assets/theme-presets.js 自由手写主题样式。
• 若用户要求多个主题或多份主题 HTML，则每个主题输出都必须来自同一份已确认源稿，且都按本技能内部确定性渲染链路分别生成；文件落地时必须使用 scripts/render-wechat-article-theme-batch.js，不得通过复制一份 HTML 后手改颜色、类名、块标签或局部结构来伪造多主题结果。
• 若当前轮仍停在用户确认阶段，则明确说明“下一步需要生成对应 HTML”，不要错误地以大纲或结构清单结束。
• 对应主题的每个已用组件都要和本技能内部已固化的主题规则保持一致，包括颜色、字号、边线、留白、圆角、对齐和题注写法。

Step 6：可选微信封面图分支

只有在以下条件同时满足时才进入该分支：

• 用户通过文字明确要求输出封面、封面图、微信封面或微信封面图。
• 四段式发布源稿已经确认，且最终 HTML 已经生成完成。

执行规则：

1. 封面图分支必须位于最终 HTML 之后执行；不得在源稿确认前启动，也不得反向阻塞 HTML 主链路。
2. 封面图分支只能以已确认源稿中的 cover_prompt 为唯一语义基准，不得绕过源稿回到原始素材重新自由创作。
3. 生成前允许在执行上下文中把 cover_prompt 优化为“仅用于微信封面图生成的提示词”，但该优化提示词只属于中间过程：
   • 不进入最终输出物
   • 不回写 cover_prompt
   • 不自动展示给用户
4. 优化动作只允许服务微信封面图生成适配，例如：
   • 横版公众号封面构图
   • 标题留白区与文字安全区
   • 手机端识别度
   • 主体聚焦与背景降噪
   • 禁用水印、乱码、过密小字和复杂拼贴
   • 在用户未指定且当前图像生成能力未提供明确尺寸参数时，不虚构微信平台硬性尺寸，只按适合微信公众号封面展示的横版构图优化
5. 优化动作不得改变文章主题、核心视觉对象、事实立场或源稿语义；若发现 cover_prompt 与封面图生成意图明显冲突，必须退回源稿确认阶段，而不是强行生成。
6. 执行者必须自行判断当前运行环境是否存在可用图像生成能力，不得向用户询问能力是否存在；若存在，则按环境内可用能力生成封面图；若不存在，则明确提示当前环境无法生成封面图，不影响 HTML 主交付，并在最终交付中给出可供用户自行生成的 cover_prompt。
7. 若封面图生成失败，必须报告失败原因，但不得把 HTML 主交付判定为失败。
8. 封面图分支失败时，不回滚已确认源稿，不重置已生成 HTML，不要求用户重新确认 HTML；只报告封面图未完成及原因，并按当前交付模式继续完成或保留 HTML 主交付。
9. 只有用户明确要求审阅封面图生成提示词时，才允许在对话中展示优化后的生图提示词；默认不展示。
10. 只要用户明确要求封面图，最终交付都必须显式给出封面图分支状态；状态固定为“已生成并交付”“未生成”“已生成但未写入”三类，不得在未说明状态与原因的情况下结束本轮任务。

交付规则：

• 用户未要求文件落地时：
  • HTML 仍按原规则交付。
  • 若封面图生成成功，必须在对话中返回封面图结果。
  • 这里的“封面图结果”固定指向当前轮实际生成出的封面图可见结果或其明确引用，不得仅用“已生成完成”一句话替代。
  • 未要求文件落地时，不在工作区默认写文件。
• 用户要求文件落地时：
  • Step 6 只负责生成封面图并确定封面输出计划，不直接承担最终文件写入职责。
  • html-file-export：在 final.html 之外追加 cover.png 的输出计划。
  • source-html-export：在 source.md 与 final.html 之外追加 cover.png 的输出计划。
  • 若同时要求多个主题或多份主题 HTML：在多份主题 HTML 的主导出计划之外追加一个统一的 cover.png 输出计划；封面图仍只以同一份已确认源稿中的 cover_prompt 为准，不按主题分别改写。
  • 实际写入统一交给 Step 7 的文件落地规则处理。
• 用户明确给出封面图输出路径时，将该路径纳入 Step 7 的落地计划；未给出时，按当前导出模式的默认目录计划写出 cover.png。
• 目标封面文件已存在且用户未明确允许覆盖或自动改名时，必须先询问，不得先写入。

Step 7：可选文件落地

只有在以下条件同时满足时才进入该分支：

• 用户明确要求生成文件、给出了输出目录/文件路径，或已在 Step 6 形成封面图落盘输出计划。
• 中间整理已经在对话中完成，内容不再需要额外过程文件承载。

落地模式：

• html-file-export：只写出最终 HTML。
• source-html-export：写出 source.md 与 final.html 两个发布资产。

落地规则：

• 单主题落地的唯一合法链路是：将同一执行上下文中的已确认源稿以内存对象直供 --stdin，调用 scripts/render-wechat-article-html.js 写出最终文件。
• 多主题落地的唯一合法链路是：将同一执行上下文中的已确认源稿以内存对象直供 --stdin，调用 scripts/render-wechat-article-theme-batch.js 一次性完成批量导出。
• 除上述合法链路外，一律不得创建 source.json、article.json、payload.json 或任何 JSON 过程文件，不得通过 --input、--input-base64、base64 < payload.json、cat payload.json | ...、< payload.json、tee、临时文件、隐藏文件、命令替换或任何本地文件读入方式喂给脚本；也不得直接手写、拼接或改写最终落地 HTML 文件代替该渲染链路。
• 若用户明确要求多个主题或多份主题 HTML，批量脚本必须先完成全部主题的内存生成与验证，再只写入用户要求的最终文件；执行过程中不得在任何位置创建中间文件、临时目录、隐藏 staging 文件或备份文件；若最终写入失败，必须删除本批次已写出的最终文件并报告失败原因。
• source.md 必须使用 frontmatter + Markdown 正文，frontmatter 至少包含 title、summary、cover_prompt、theme。
• 若用户明确要求输出微信封面图，则在对应导出模式的默认目录或用户指定路径写出 cover.png。
• 不在任何位置创建中间 JSON、临时 Markdown 草稿、临时目录、隐藏 staging 文件、备份文件或其他过程文件；所有中间结构只能存在于当前对话、执行内存，或由同一执行上下文的内存生产者直接供应给渲染脚本的标准输入中。
• 目标文件已存在且用户未明确允许覆盖或自动改名时，必须先询问。
• 若用户明确要求多个主题或多份主题 HTML，则批量导出只允许改变主题映射，不允许改变源稿内容基准、结构化文章语义或验证口径；若用户同时要求保留源稿，只能写出一份共享 source.md。
• 只要用户明确要求封面图而最终没有产出 cover.png，最终交付说明中必须显式写明“HTML 已完成 / 封面图未完成 / 未完成原因 / cover_prompt”；不得把该状态留给用户自行推断。

用户交互规则

1. 信息足够时直接整理，不先给多版方案让用户选。
2. 中间输出默认放在对话里，优先展示四段式发布源稿，不外溢到额外资源。
3. 用户没有指定主题时，不追问，直接使用默认主题。
4. 用户没有要求文件落地时，不主动询问输出路径。
5. 用户明确要求“只要最终 HTML、不要过程”时，优先改用 wechat-html-composer；若因点名当前技能或要求保留源稿资产而继续执行，则只在内部完成四段式源稿整理，不默认展开四段结果，直接输出最终 HTML。
6. 用户要求展示内容时，先展示发布源稿，再在确认后输出最终 HTML。
7. 用户只说“要一个可复用的 md 文件”时，默认理解为 source.md，其内容格式必须服从本技能的 frontmatter 契约，而不是自由拼接四段文本。
8. 用户明确要求输出微信封面图时，封面图属于附加交付；默认不展示优化后的生图提示词，也不改变源稿中的 cover_prompt。
9. 用户明确要求文件落地时，不允许自由手写最终 HTML 文件；必须使用本技能目录内的确定性渲染链路并满足对应验证规则。
10. 用户明确要求多个主题或多份主题 HTML 时，不允许把“多主题”理解为多次自由创作；它固定指向“同一份已确认源稿 + 多个内置主题映射”的批量导出。

质量门禁

交付前必须通过：

• 主闸：
  • 标题合规：title 不超过 64 字，且准确概括全文。
  • 摘要合规：summary 不超过 120 字，且不是泛化空话。
  • 封面可用：cover_prompt 可作为封面生成或交付设计的完整语义基准。
  • 源稿一致：title、summary、cover_prompt、markdown 互相一致，不互相打架。
  • Markdown 准确：正文 Markdown 与原文事实、数据、引用、立场和用户保留要求一致。
  • Markdown 可发布：正文 Markdown 已满足 references/content-format-standard.md，不能把结构和可读性问题留到 HTML 阶段。
  • 正文无元信息：正文 Markdown 与最终 HTML 的读者可见内容只能来自用户输入内容的汇总总结，不得出现源稿文件、source.md、final.html、cover_prompt、封面提示词保存位置、原始链接保留位置、二次编辑、复核路径或执行过程说明。
  • HTML 观感预检：正文结构必须从最终 HTML 效果反推，套用目标主题后应保持美观、大气、规范、留白稳定和阅读节奏清楚；不得依赖 HTML 阶段临时补救结构缺陷。
  • HTML 兼容：基础标签稳定、样式内联、无脚本、无正文 div。
  • 最终结果正确：若已确认内容，最终必须生成对应 HTML，并按当前模式在对话中交付或进入文件落地；若未确认，必须明确下一步是生成对应 HTML，而不是结束在大纲或说明。
• 主题闸：
  • 主题一致：已使用组件与 references/theme-spec.md 中对应主题规则保持一致，不混入其他主题样式。
  • 批量主题同源：若用户明确要求多个主题或多份主题 HTML，则所有主题文件必须共享同一份已确认源稿与同一套验证口径；不允许每个主题各自重写正文或另起结构。
  • 集合主题完整：若用户以“各种主题”“全部主题”“所有主题”“全主题”“每种主题”或等价内置集合词要求多个主题，则交付前必须确认输出覆盖 assets/theme-presets.js 中全部内置主题，且实际包含 academic-paper-template 对应的论文风格 HTML。
• 附加闸：
  • 封面分支可控：若用户明确要求微信封面图，则封面图只能在 HTML 之后执行，执行者必须自行判断当前环境是否存在可用图像生成能力，不得向用户询问；失败不阻塞 HTML 主交付。
  • 封面状态显式：若用户明确要求微信封面图，则最终交付必须显式给出封面图状态；状态固定为“已生成并交付”“未生成”“已生成但未写入”三类。若状态不是“已生成并交付”，必须同时给出原因；若状态为“未生成”，还必须给出 cover_prompt 供用户自行生成，不得静默结束。
  • 封面提示词稳定：用于生图的优化提示词不得进入最终输出物，也不得回写源稿 cover_prompt。
  • 无中间文件：用户可见中间结果只在当前对话中出现；执行中间结构只允许存在于执行内存，或由同一执行上下文的内存生产者直接供应给渲染脚本的标准输入中；不得在任何位置生成中间 Markdown、JSON、说明文档、临时目录、隐藏 staging 文件、备份文件或其他过程文件，也不得从任何本地过程文件构造 stdin 或 base64 输入。
  • 文件可验收：只有在显式落盘时检查路径、覆盖规则和最终产物。
  • HTML 链路确定：最终 HTML 必须来自已确认源稿、内部文章结构和主题规范的确定性映射；若进入文件落地分支，最终 HTML 文件还必须由本技能目录内的确定性导出脚本写出；若是多主题落地，必须由批量确定性导出脚本写出，而不是执行者自由手写的 HTML。
• 完整交付检查清单见 references/quality-gates.md。

失败处理

• 入口与路由失败：
  • 主题不清楚：追问主题或目标，不猜测文章核心。
  • 用户只要最终 HTML 不要过程：按上文路由总则优先转 wechat-html-composer。
• 源稿失败：
  • 内容太少但主题明确：先在对话中整理短版源稿，再输出短版 HTML。
  • 标题超过 64 字且无法无损压缩：给出最小必要压缩建议，等待确认。
  • 摘要超过 120 字且核心信息无法同时保留：优先压缩修辞，不压缩关键信息；仍超长时提示用户取舍。
  • 源稿字段彼此不一致：退回源稿阶段，逐项对照原文修正后再转 HTML。
  • Markdown 结构不适合转换：先修正标题层级、列表、引用、表格或代码块，再继续。
  • Markdown 虽然正确但不够像可发布公众号成稿：继续回到源稿阶段，补齐摘要、章节标题、段落节奏和重点呈现，再进入 HTML。
  • 可变事实无法核验：使用审慎表达，或移出核心论据。
• 主题与批量失败：
  • 用户指定的风格未内置：命中内置主题名或内置中文主题描述时归一化；未命中时降级到 wechat-native-template。
  • 主题规范与预设不一致：以 references/theme-spec.md 为准，修正预设或直接按规范写出最终 HTML，不继续沿用旧预设。
  • 用户明确要求多个主题或多份主题 HTML，但当前执行无法按同一份已确认源稿逐一走确定性渲染链路：在生成前将未命中主题归一化或降级到 wechat-native-template；若仍无法保证同源批量导出，则停止并说明多主题导出未完成，不得只导出部分主题顶替完整交付，也不得改为手写多份近似 HTML。
• 封面图失败：
  • 用户明确要求微信封面图，但当前环境无可用图像生成能力：明确提示封面图未完成，不影响 HTML 交付，并给出 cover_prompt 供用户自行生成。
  • 用户明确要求微信封面图，当前环境有可用图像生成能力但生成失败：报告失败原因，不影响 HTML 交付，并给出 cover_prompt 供用户自行生成。
  • 用户明确要求微信封面图且封面图已生成，但写入 cover.png 失败：说明 HTML 已完成、封面图已生成但未成功写入目标路径，报告具体写入失败原因，并在能力允许时返回已生成封面图结果或其明确引用。
  • cover_prompt 与封面图生成意图明显冲突：退回源稿确认阶段修正，不强行生成封面图。
  • 图片不适合公众号：保留说明和 URL 文本，不伪造图片。
• 落盘失败：
  • 文件已存在：未获允许不得覆盖；可根据用户确认自动改名。
  • 写入失败：报告具体路径和失败原因，请求新路径或权限。

复评闭环

修改本技能或本技能资源后，按 references/maintenance-checklist.md 复查。若修改脚本、显式落盘链路、批量主题导出链路，或让封面图分支进入脚本/导出链路，才运行 scripts/verify-render-wechat-article-html.js；现有验证脚本覆盖 HTML/source 渲染链路与批量主题导出链路，不验证图像生成质量或图片文件内容。

最终交付格式

按任务状态选择：

• 若内容已确认且不要求落盘，最终回复直接输出完整 HTML。
• 若当前轮仍在确认中间结构，最终回复给出四段式源稿结论，并明确下一步需要生成对应 HTML。
• 若用户明确要求只落盘 HTML 且已完成写入，最终回复说明实际路径、主题和验证结论；除非用户同时要求贴出 HTML，否则不重复粘贴超长 HTML。
• 若用户明确要求导出源稿与 HTML 且已完成写入，最终回复说明 source.md、final.html 的实际路径、主题和验证结论。
• 若用户明确要求多个主题或多份主题 HTML 且已完成写入，最终回复说明每个主题文件的实际路径、共享源稿路径或共享源稿基准，以及验证结论。
• 若用户明确要求输出微信封面图且状态为“已生成并交付”，最终回复在对应模式说明中追加封面图结果或 cover.png 的实际路径。
• 若用户明确要求输出微信封面图且状态为“未生成”，最终回复必须明确说明 HTML 已完成、封面图未生成及原因。
• 若用户明确要求输出微信封面图且状态为“未生成”，最终回复还必须给出已确认源稿中的 cover_prompt，供用户自行生成封面图。
• 若用户明确要求输出微信封面图且状态为“已生成但未写入”，最终回复必须明确说明 HTML 已完成、封面图已生成、未写入路径及原因，并在能力允许时返回已生成封面图结果或其明确引用。