guizang-social-card-skill

Guizang 社交卡片技能

为小红书/Rednote、微信公众号、文章封面和平台缩略图制作精致的社交卡片套件。

此技能独立完整。它借鉴了 Guizang PPT 风格系统的视觉原则，但不得编辑原始 PPT 技能、其模板或参考资料。如果提供了原始 PPT 技能，可以仅将其作为参考阅读。

生成的作品必须放在任务文件夹中，而不是技能根目录。默认使用此仓库内的 local-tests/<slug>/，或使用用户明确指定的输出文件夹。不要创建根目录级别的任务文件夹，例如 social-card-*、livephoto-*、wechat-*、output/，也不要将渲染后的素材散放在 SKILL.md 旁边。

需要产出的内容

以下情况请使用此技能：

• 社交卡片/轮播图片组：封面加内容页，尤其是小红书/Rednote 的 3:4 图片。
• 用户要求制作 Live Photo / 实况照片，并提供了视频素材或屏幕录制时，制作简短的 Live Photo 动态卡片。
• 用户拥有高质量视频素材，想制作单视频、双格、三格或四格动态卡片，且几乎不添加文字或完全不添加文字时，制作以素材为主的 Live Photo 拼图版式。
• 用户有三段短视频、三个结果、三个视角，或需要高信息量对比，并希望将内容放在一个图片卡片单元内时，制作三联 Live Photo 拼图。
• Live Photo 长视频素材处理：判断应裁剪、加速、拆分、制作三联拼图，还是在渲染前请用户指定时间范围。
• 微信公众号封面组：一张 21:9 主封面加一张 1:1 方形封面，并在同一 HTML 中组合，以便进行视觉检查。
• 截图较多的产品帖、文章封面、教程轮播、户外/生活方式笔记、AI/产品更新解读。
• 需要采用 Guizang 风格瑞士式或编辑杂志式版面的社交图片。

以下情况不要使用此技能：

• 完整幻灯片或横向 PPT 网站。这类内容请使用 PPT 技能。
• 长视频生成。这类内容请使用视频技能。此技能仅支持时长较短、布局受限的 Live Photo 卡片，即用视频替换静态图片占位区域。
• 无需排版或提取文章内容的纯图片编辑。

Rednote 类别能力（能力范围）

最常见的 11 类 Rednote（小红书）内容分为三组。具体方案请参阅 references/category-cookbook.md。

端到端能力强（文字、结构和图片叙事均在能力范围内）：

• 旅行、职场、推荐（需先指定子类型）。

文字与结构能力强；图片需由用户提供或从素材库获取：

• 游戏、影视、美食（仅食谱方向）、彩妆（仅教程方向）、健身、家居、穿搭（仅精选/随笔方向）。

不在能力范围内——坦诚说明限制，不要承诺无法实现的效果：

• 美食：菜品大片摆盘。
• 穿搭：日常 OOTD 全身照（我们无法生成或模拟）。
• 情感：梦核/氛围感装饰风（与编辑式和瑞士式风格都不相符）。
• Y2K/千禧辣妹/哥特萝莉/kawaii 装饰风。
• 以图片为全部交付内容的纯摄影展示帖。

如果请求属于第三组，应在接收需求时说明我们无法实现的内容——不要默默换成不符合用户意图的版式。

核心原则

表达优先。目标不是把文字硬塞进海报，而是将素材转化为清晰的视觉论证。

对于每一页，都要判断：

• 让观众一眼看懂什么？
• 哪些证据、截图或图片可以支持这一点？
• 哪些文字必须放大，哪些可以作为说明文字或元数据？
• 哪些内容属于帖子正文而不是图片，可以删去？

必需参考文件

按需阅读以下文件：

• references/platform-specs.md，了解精确比例、输出尺寸和命名规则。
• references/style-system.md，了解 Guizang 编辑风格和瑞士视觉规则。
• references/theme-presets.md，选择电子杂志配色或瑞士风格强调色时参考。
• references/layout-recipes.md，选择轮播图／社交卡片／微信公众号页面结构时参考。
• references/components.md，了解共享组件规范：字体栈、字号比例、最小可读字号、中文标题长度范围、瑞士风格卡片填充的互斥规则、图片容器比例类别、间距令牌和 Lucide 图标规则。
• references/background-systems.md，制作电子杂志 WebGL／水墨／纸张背景时参考。
• references/portrait-fill.md，调整布局以适配 3:4 并避免竖向空间填充不足时参考。
• references/content-planning.md，了解封面吸引点、页面拆分和文案精简。
• references/production-workflow.md，了解 HTML/CSS 渲染和图像处理。
• references/live-photo-production.md，当用户要求 Live Photo／实况照片／三连实况拼图、为社交卡片提供视频素材，或需要小红书／微信动态卡片交付时参考。该文件涵盖信息预算、单张或三连 Live Photo、长视频接收和平台发布提醒。
• references/image-overlay.md，只要文字叠加在照片上就必须参考：照片筛选、本地化色调回退，以及通过多模态主体映射避开人脸／主体。
• references/screenshot-treatment.md，当用户提供应用／网页／代码／仪表板截图时参考：选择 .frame-shot 而非 .frame-img，设置圆角／阴影／背景／内边距，并决定使用 .device-browser 还是 .device-phone 外框。
• references/map-component.md，当内容涉及空间关系（旅行路线、店铺位置、徒步游览）时参考：真实路线默认使用 Mapbox Static 或 OSM 静态图块；示意 SVG 仅用于概念性／说明性地图。标记使用 HTML 叠加层；切勿使用实时 JS 地图。
• references/title-shortener.md，当任务需要制作微信公众号 21:9+1:1 封面组合或跨平台复用时参考：通过 5 步提取法和 4 种模式从长标题提炼 1:1 短标题，并遵循 .poster.square 的尺寸规则。
• references/category-cookbook.md，将用户指定的小红书类别（旅行／职场／游戏／影视／彩妆／美食／穿搭／家居／健身／情感／推荐）对应到适用配方，并确认范围。
• references/qa-checklist.md，交付最终图片前参考。

工作流

1. 收集信息

只收集那些会影响输出的缺失信息：

• 目标平台和比例。

• 原文、字幕、文章或标题。

• Rednote 类别——如果用户指定了 11 种常见类型之一（旅行 / 职场 / 游戏 / 影视 / 美食 / 彩妆 / 穿搭 / 家居 / 健身 / 情感 / 推荐），请通过 references/category-cookbook.md 查找合适的配方，并确认请求在能力范围内（参见上文“Rednote 类别能力”）。如果请求超出范围，务必在设计前告知用户，不要悄悄调整方案。

• 用户提供的图片 / 截图，以及每张图片应出现的位置。对于新闻 / 教程 / 数据 / 测评内容，主动询问用户是否有截图或照片——它们是证据层。没有真实素材的海报往往会显得空洞。

• 如果用户要求制作 Live Photo，询问用户提供的视频素材。通常应使用用户提供的视频；仅在演示 / 宣传案例或用户明确要求查找素材时，才使用网上的免费视频。确认目标平台，因为时长有所不同：小红书支持 5s；微信公众号 Live Photo 应保持 3s，且必须从 iPhone 上传。剪辑前，请阅读 references/live-photo-production.md，并将请求归类为单张 Live Photo、三联拼图或长视频素材处理。如果素材太长或包含多个可用片段，请先进行低成本诊断，然后一次性询问用户是要剪短、加速、拆分到多个画面，还是使用指定的时间范围。如果素材短于目标时长，请询问用户是要提供更长的片段、接受较短的 Live Photo，还是明确允许定格 / 慢放。如果主体焦点不明确，可以提出裁剪 / 放大的选项，但执行前须让用户决定。

• 如果用户只提供文字（完全没有图片），设计前请询问一次：

  这篇我需要 1-2 张图。三种走法：
  A. 你自己有照片 / 截图，传给我（推荐——最不"AI 感"）
  B. 我去 Pexels / Unsplash / Flickr 帮你找
  C. 用 AI 生成
  

  用一句话推荐 A——自己的照片才最能让海报看起来不像 AI 生成的。接受用户选择的任何选项（包括“都行你看着办”）并继续。**之后不要再次询问，也不要在后续对话中反复引导用户选 A。**此问题只问一次。

• 用户指定的偏好风格：瑞士风格、杂志 / 编辑风格、科技、户外等。

• 硬性要求：标题文字、1:1 封面不能有图片、必须包含硬件照片、确保截图清晰可读等。

如果用户已提供足够的上下文，请基于合理假设继续。

如果内容涉及当前产品发布、政策、价格、声明或新闻，请通过浏览验证可能变化的信息，并在最终回复中引用来源。

2. 提炼故事

设计前，先将原文整理成页面规划。

对于 Rednote：

• 第 1 页是封面钩子。
• 第 2 页至第 N 页，每页只传达一个观点。
• 大多数帖子使用 5-9 页。如果页面下半部分显得空洞，请压缩或合并页面。
• 正文用于阐述细节；图片应突出钩子、对比、清单和鲜明结论。

对于微信公众号：

• 始终制作一组配套封面：21:9 主封面和 1:1 方形封面。
• 在同一个 HTML 文件中制作两种封面，并添加合并预览区域，以便一起检查它们的视觉关系。
• 21:9 封面保留完整或接近完整的标题、副标题和一个鲜明的视觉关联。
• 1:1 封面从长标题中提炼简短标题：大字居中，默认不放图片，不添加拥挤的副标题。

3. 选择风格模式

每个内容包选择一种模式。这两套系统并未与特定内容类型绑定——改变的是视觉呈现方式，而不是可以讨论的主题。职场文章可以采用编辑杂志风格，旅行账本也可以采用瑞士风格。请根据你想要的感受来选择，而不是查找内容类别。

编辑杂志风格 × 电子墨水带来：

• 衬线体／宋体标题 + 低调的无衬线正文字体，纸张与墨水配色。
• 温暖纸张基底上的氛围层（纸张颗粒／水墨晕染／WebGL 画布）。
• 账目行、边注、引文摘录、大幅照片区——营造杂志专题的感觉。
• 最适合希望页面显得从容、审慎、精心排版的场景。

瑞士国际主义风格带来：

• Inter／Helvetica 风格，大字号标题极细，小字号标签采用等宽字体。
• 严格左对齐的网格、极细分隔线、一种高饱和度强调色。
• 填充卡片矩阵、KPI 塔形图、横向条形图、编号陈述——营造系统感／数据感。
• 最适合希望页面显得精密、量化、果断的场景。

如果一项内容两种风格都适用，问题就在于编辑意图：“这是专题报道，还是发布说明？”决定模式的是这一点，而不是主题本身。

除非用户明确要求混搭，否则不要在同一组图片中混合这两套视觉系统。

然后选择一种主题：

• 编辑杂志风格 × 电子墨水使用 6 种杂志配色之一：墨色经典、靛蓝瓷白、森林墨色、牛皮纸、沙丘或午夜墨色（唯一的深色变体；仅用于游戏主视觉／夜景摄影／电影感封面）。
• 瑞士国际主义风格使用 4 种强调色配色之一：国际克莱因蓝、柠檬黄、柠檬绿或安全橙。

请阅读 references/theme-presets.md 获取确切的 CSS 令牌。除非用户有严格的品牌要求，否则不要自行编造颜色。

4. 规划页面

创建一份简洁的内部计划：

Page 01 / cover / hook / image source / layout intent
Page 02 / point / key copy / visual evidence / layout intent
...

当用户要求审批时，先展示此计划，再进行渲染。否则，将其作为内部计划，并继续执行。

使用 references/layout-recipes.md 选择页面结构。避免每页都采用重复的“标题加卡片”布局。

对于 3:4 图片，编码前先查看 references/portrait-fill.md。简短的表格或台账必须扩展为完整的竖版构图，可加入引言栏、图片证据、旁注、更大的行，或背景主视觉区。

面向受众的文案必须描述用户的实际场景，而非制作方式。3s、5s、Live Photo、triple collage、information budget、long-video intake、speed-up、highlight detection、one action point 或 layout template 等内部术语可用于规划、文件名、QA 备注和交付摘要，但除非用户明确要发布关于这些概念的教程，否则不得将其用作 H1、吸引语或正文。在渲染前，以真实观众的视角通读每条可见标题：如果听起来像任务要求，就改成贴合具体场景的文案。

不要为了满足自动密度警告而添加非模板装饰。额外的标尺、侧边栏、伪时间轴、装饰性标签或臆造徽章必须来自现有布局方案或用户要求。如果出现密度警告，应通过选择更合适的布局方案、调整真实内容的尺寸，或给出视觉理由并接受建议性警告来解决；不要在卡片上放置毫无意义的 UI 元素。

对于 Live Photo 卡片，先按普通社交卡片进行规划，再决定动态效果的作用：一个动作点、一个小流程、前后变化、三个并列结果，或氛围／证据。唯一的结构变化是一个或多个图像区域变为视频区域。保持相同的比例、裁剪、安全区域、字体排印和样式模式规则；将静态图像的裁剪逻辑应用于视频流。首帧必须通过与静态图像相同的检查：不得过度裁剪，关键 UI／内容须清晰可读，卡片仍须遵循所选布局方案。渲染前先阅读 references/live-photo-production.md。

对于素材优先的 Live Photo 拼图卡片，以视频素材为主。文案要少，甚至不加：单视频封面只需一个简短标题，双格／三格／四格版本通常不应添加文字。单视频封面若要在画面上叠加文字，请遵循 M16 Image-Led Cover 的图上文字规则：先确定主体布局，留出安全留白区，使用常规至中等字重的 Editorial 衬线体／宋体，采用纸张米白色文字，不要默认使用全画布蒙版。不要为了让叠加文字显得更有设计感而臆造额外的引题、元信息、细线、标签、标尺、徽章、副标题或制作说明术语。如果只有一个标题，就让字体排印承担布局功能：根据语义断行，克制地控制字号、字距、对齐方式和位置。将素材中原有的文字视为画面的一部分；除非用户有要求，否则只需避免添加新文字。

4.5. 复制种子模板

不要从头编写 HTML。根据第 3 步选择的风格模式，挑选一个种子模板：

• Editorial Magazine × E-ink → 将 assets/template-editorial-card.html 复制到任务文件夹，并命名为 index.html。
• Swiss International → 将 assets/template-swiss-card.html 复制到任务文件夹，并命名为 index.html。

种子模板已配置好：字体加载、主题令牌、全部三种海报尺寸（.poster.xhs / .poster.square / .poster.wide）、双联预览框、颗粒感／背景图层，以及布局配方中引用的所有类定义。

在 <html> 元素上设置主题／强调色：

• Editorial：<html data-theme="ink-classic | indigo-porcelain | forest-ink | kraft-paper | dune | midnight-ink">。
• Swiss：<html data-accent="ikb | lemon-yellow | lemon-green | safety-orange">。

将位于 `` 之后的单个占位海报替换为每页一个 <section class="poster ..."> 块，每个块都包含所选布局配方（Editorial 使用 M01-M16，Swiss 使用 S01-S12）的 HTML 骨架。切勿加载错误模板的类系统：Editorial 配方依赖衬线展示字体 + ledger/marginalia/pipeline-v；Swiss 配方依赖 Inter + card-fills + matrix/h-bar/kpi-tower。混用会导致布局在不知情的情况下出错。

5. 构建与渲染

默认实现模式：

• 默认在 local-tests/<slug>/ 下创建任务文件夹，或放在用户指定的输出文件夹中。切勿将生成的任务文件夹、渲染图像、MOV 文件、.pvt 包或下载的源文件放在 SKILL.md 旁边的技能根目录中。
• 将源图像放在 assets/ 中。
• 从第 4.5 步中复制的种子模板开始，而不是使用空白文件。优先只修改 `` 区域中的页面内容。如果任务需要自定义布局 CSS，请在复制的文件中添加一个名称清晰、仅用于该任务的代码块，并重置语义默认值（figure { margin:0; }，避免浏览器默认间距带来的意外）。
• 使用 Playwright 或浏览器截图工具导出每个 .poster 或 .cover 节点。
• 将渲染后的图像保存在 output/ 中。
• 验证尺寸并检查渲染后的 PNG。
• 保留 node validate-social-deck.mjs <task-dir>，以便执行自动检查。它会检查溢出（R1）、页脚碰撞（R2）、Swiss 粗体显示（R3）、最小字号（R4）、4 区带密度（R5）、.h-xl 行数上限（R6）、浏览器默认 figure 外边距偏移（R7）、视觉边界／底部留白（R8）以及标题与内容之间的间距（R9）。任何一项 FAIL 都会返回退出代码 1——如果用户要求自动检查，请在最终交付前修复。WARN 仅供参考，但请仔细查看。

Live Photo 分支：

• 渲染前确定信息量：3s 适合一个行动要点；5s 适合一个简短流程；三联拼贴适合三个并行片段，但不适合复杂故事；长视频需要先诊断再编辑。
• 对于较长的源视频，避免声称能精确地自动检测精彩片段。先探测时长／分辨率，生成稀疏的联系表，然后选择截取、加速、拆分／三联拼贴，或询问用户指定时间范围。
• 从每个视频中提取第一帧，将其放入最终静态卡片布局，并在制作 .pvt 前展示／检查预览。这样能以更低的 token 消耗和渲染成本发现裁剪与层级问题。
• 按平台时长渲染配套 MOV：小红书为 5s，微信公众号为 3s。
• 从具有代表性的清晰帧中提取关键 JPG。
• 使用 makelive 将 JPG + MOV 打包成 .pvt；在 iPhone 测试中，将 .pvt 作为单个项目通过 AirDrop 发送。
• 验证尺寸、时长、帧数、包内容和动态效果质量。视觉检查时优先使用联系表帧条，这样只需人工／模型检查最终拼接图像。具体命令和故障模式检查请参阅 references/live-photo-production.md。

请勿在图像中放置可见的说明、键盘快捷键或使用说明。

对于 Editorial Magazine x E-ink，请使用分层背景系统。优先使用细腻的 WebGL 墨流画布或冻结的程序生成画布，并叠加纸张颗粒纹理。请阅读 references/background-systems.md；不要使用纯米色背景，也不要添加覆盖整页的网格／圆点背景。

6. 图像与截图处理

用户提供截图时：

• 除非用户要求重新设计，否则请保留截图内容。
• 优先采用程序化构图：使用目标比例画布、安全留白、干净背景，并确保截图清晰易读。
• 不要拉伸截图。
• 如果截图清晰度很重要，请扩大截图区域并减少附近的文字。

图文叠加排版

每当海报在照片上叠加文字（满版封面、大幅图片区域、生成图片叠加层）时，都要遵循 references/image-overlay.md：

• 先选择图片，必要时才加色调。 覆盖画布 ≥60% 的照片必须先通过 image-overlay.md 中的留白区域和亮度测试。先不加遮罩进行排版；如果缩略图检查不通过，只在标题区域周围添加局部、与图片色调协调的色调。不要默认使用覆盖全画布的渐变。
• 必须标注主体位置。 放置标题前，使用 Read 工具查看图片，用通俗语言描述主体的面部／焦点特征所在位置，并将主体位置说明作为 HTML 注释放在主视觉区块旁。只在已记录的安全区域内放置文字。
• 裁切规范——为每张照片内联设置 object-position。 模板默认值（center 50%）只是备用选项，并非建议值。针对每个 <img>，根据主体位置决定并内联设置：例如，主体位于身体中部时使用 style="object-position:center 62%"；地平线处有主体、天空占比较大时使用 center 30%；前景有装备时使用 center 70%。范围请参见 references/components.md 中的表格，人像照片的具体要求请参见 image-overlay.md。如果忽略此项，在高纵横比（r-3x4、r-21x9）下，主体会被悄然裁出画面。
• 缩略图测试。 将渲染后的 PNG 缩小至宽 360 px，并确认标题仍清晰可读。如果标题与照片相互干扰，请移动标题、更换照片，或添加局部且与图片色调协调的色调；如果照片显得死板，说明色调过重，或照片不适合叠加文字。

编辑风格的暗色封面（例如以关键美术图为背景的游戏期刊）和带主视觉照片的瑞士风格封面都必须进行这些检查。跳过这些检查是已知的失败模式（参见 style-system.md 反模式 D）。

用户没有图片时：

• 仅当步骤 1 的“三选一”关卡选择了 B（网络来源）或 C（AI 生成）时，才执行此分支。绝不要擅自转向 B 或 C——用户已经做出了选择。
• 对于 C（AI 生成）：仅在确实有价值时使用生成位图，通常为 1–2 页。生成的图片应符合页面的视觉用途，而不是用作通用装饰。除非明确需要，否则生成图片中不要包含嵌入式标题、页码、徽标或伪造的 UI 标签。
• 对于 B（网络来源）：参见下文“网络来源图片”部分。

网页图片素材（用户没有图片时的备用方案）

当用户没有截图/照片，且生成的位图不适合页面用途（例如编辑风格的氛围图、户外/生活方式背景、游戏封面图、真实产品图）时，应从网上获取图片，而不是让页面内容显得单薄。

政策：**先获取，再披露，让用户决定是否标注来源。**不要根据猜测的许可条款预先筛选来源——最终作品的权利由用户持有，是否接受由用户决定。

推荐来源，按优先级排序。以下五个都是免费的图库，无需支付许可费用；我们不会从付费图库（视觉中国 / Getty / 站酷海洛等）获取素材。

1. Unsplash — https://unsplash.com/s/photos/<keyword>。适合户外/生活方式/氛围背景。英文关键词效果最好。许可较宽松，但请逐一核实。
2. Pexels — https://www.pexels.com/search/<keyword>/ 或 https://www.pexels.com/zh-cn/search/<keyword>/。原生支持中文关键词搜索——弥补 Unsplash 在国内场景（中文街景 / 国风物件 / 本地地名）方面的不足。主题与中国相关或关键词为中文时，优先使用此来源。依据 Pexels License 免费使用。
3. Flickr CC 授权图库 — https://www.flickr.com/search/?text=<keyword>&license=2%2C3%2C4%2C5%2C6%2C9。许可筛选器（license=2,3,4,5,6,9）将结果限定为 Creative Commons 照片。可弥补“纪实真实感”方面的不足：街拍、人物与环境、真实室内场景、未经摆拍的画面，这些是 Unsplash/Pexels 所欠缺的。若用户选择标注，务必保留 CC 来源标注。
4. Wallhaven — https://wallhaven.cc/search?q=<keyword>。适合游戏 / 动漫 / 壁纸主题。内容由用户上传，版权未经核实。
5. 直接网页搜索 — 需要特定主题时使用（例如产品渲染图、游戏画面、历史照片）。使用 WebFetch / WebSearch 查找候选网址。

编辑模式下的选择顺序：Pexels（关键词为中文 / 主题与中国相关时）→ Unsplash → Flickr CC（需要真实生活感时）→ 直接搜索。Swiss 模式很少需要这些素材——产品渲染图、UI 截图和 KeyShot 风格图片应由用户提供或通过 AI 生成，而不是使用图库素材。

获取方式：

• 使用 WebFetch 或 curl 将图片下载到任务文件夹的 assets/ 目录。
• 按用途命名文件，而不是使用哈希值：assets/hero-mountain.jpg、assets/ui-pulse-card.png。
• 在图片旁的 assets/SOURCES.md 文件中记录来源网址（每个文件占一行：hero-mountain.jpg ← <url>）。即使用户在最终图片中不要求标注，也始终执行此操作，以便人工作者追溯来源。

获取图片后，在完成设计前向用户说明来源：

我从 <site> 取了这些图：
- assets/hero-mountain.jpg — <url>
- assets/ui-pulse-card.png — <url>

⚠️ 版权未经核实。请你判断是否可用。
是否需要在图文中标注来源？
- 要：我把 "Photo · <site> · @<author>" 加到对应页脚 / 角标。
- 不要：原样使用,不加注释。

如果用户选择“标注”——添加小号的 mono 说明文字（Swiss：在角落使用 18-20px 的 .t-meta；编辑风格：在图片旁使用 .label）。切勿将说明文字挤进版面的视觉焦点区域。

如果用户选择“不标注”——直接继续，无需说明。来源信息仍保存在 assets/SOURCES.md 中，供用户自行留档。

如果图片只是合成图中的一个元素（例如九宫格中的一张照片），用户可以合理地选择不标注来源。不要强行添加破坏版式的署名标签。

7. 交付

先展示给用户，按需核查。 每次渲染后都自动运行验证器会耗费太长时间，延迟用户查看结果。默认流程：

1. 渲染完成后，立即以内嵌形式展示渲染出的图片（使用绝对路径），并用一句话概述制作内容。
2. 只问一个问题：“先你自己看，还是我先自动核查一遍？”（你想先自己查看，还是让我先自动核查？）
3. 如果用户说“我自己看”／“先给我”／“no need”，就在此处停止，让用户检查，并回应他们提出的问题。
4. 只有当用户说“你查吧”／“auto-check”／“yes”时，才运行 node validate-social-deck.mjs <task-dir>；修复所有 FAIL，并在最终交付前重新渲染。提及密度／上限 WARN。

在向用户展示结果之前，绝不要默默运行验证器——每轮验证要花几分钟，而且用户往往能更快发现问题。

用户查看或要求自动核查后，最终回复应包括：

• 输出文件夹路径。
• 渲染出的图片（有用时使用绝对路径内嵌展示）。
• 关于尺寸和验证情况的简短说明（或“尚未验证，等待你查看”）。
• 对于从网络获取的任何图片：来源 URL、网站，以及用户决定的署名方式。
• 对于 Live Photo：.pvt 软件包路径、调试用的 JPG + MOV 文件对、目标平台时长，以及验证摘要。
• 对于 Live Photo 发布：提醒用户两点：平台时长限制（小红书为 5s，微信公众号为 3s），以及发布路径（通过 AirDrop 将 .pvt 软件包作为单个项目发送到 iPhone，然后从对应的移动应用发布；桌面端／网页版上传路径通常无法将 .pvt 识别为可发布的 Live Photo）。
• 如果用户无法使用 iPhone／AirDrop 发布路径（例如仅使用桌面端的工作流、使用 Android，或平台不支持 Live Photo），可提供降级交付方案：从同一 MOV 源文件导出短循环 GIF 或静音 MP4 片段。GIF／MP4 会保留动态效果，但会失去 Live Photo 点按播放的体验。切换到此备用方案前，先向用户确认。
• 任何尚未解决的风险，例如源图片分辨率较低。

不可妥协的要求

• 绝不编辑原始 Guizang PPT 技能，或从其他地方复制来的任何上游技能。
• 绝不在技能根目录中创建生成文件。默认情况下，所有任务产物都必须放在 local-tests/<slug>/ 下，或放在用户指定的输出文件夹中。禁止在根目录创建 social-card-*、livephoto-*、wechat-* 等生成文件夹，也禁止散放输出素材。
• 不要创建随机的装饰性 SVG 椭圆、色块、雨滴、贴纸或毫无意义的圆形。
• 不要默认使用嵌套卡片或通用 SaaS 卡片布局。
• 不要让文字溢出、贴边，或与页脚色带重叠。在弹性纵向布局中使用 .foot 的 margin-top: auto 固定页脚位置；绝不能用 position: absolute 将页脚覆盖在不断增长的内容上。
• 内容溢出时，先测量溢出量再编辑。轻微溢出应小幅修正：1-40px 表示微调或收紧，40-90px 表示局部压缩，90-160px 表示略微压缩标题或段落，只有达到 160px+ 才应更改版式方案或删除内容。修复后，检查 R8 底部留白，避免页面从溢出变成下方大面积空白。
• 不要让标题贴到下一个内容块。主展示标题下方通常至少留出 28px；局部标题下方至少留出 16px。依赖目测之前，先使用验证器 R9。
• 不要让文字小到在手机上难以阅读。
• 在 Swiss 风格中，不要在展示标题上内联使用 font-size + font-weight。请使用类型化类（.h-hero / .h-statement / .h-xl / .num-mega）。字号为 80-120px、字重为 700-900 的大标题不符合 Swiss 风格；“越大越轻”是硬性规则。
• 不要交付背景单调平坦、每行都有单色标签且没有氛围层的 Editorial 海报。请运行 references/style-system.md 中的 Editorial Identity Test——只有衬线标题并不意味着海报具有 Editorial 风格。
• 不要编造数据、发布详情或百分比。
• 除非用户明确接受，否则不要裁切人脸、关键 UI 文本或硬件／产品细节。
• 不要把视频卡做成假的静帧序列而不作说明。如果源视频短于目标时长，请索要更长的视频源、使用平台支持的较短时长，或明确记录停帧／减速处理。
• 不要跳过 Live Photo 的首帧预览。视频是一块带有动态效果的图像区域；渲染 MOV 之前，其首帧必须符合静态 3:4 布局和裁切规则。
• 不要让成片视频在狭窄裁切区域中滚动穿过分区边界，这会造成“视频重叠”问题。打包前请检查联系表，并选择稳定的时间窗口。
• 放大／裁切视频以提升可读性时，不要猜测用户看重的视觉重点。请说明裁切与放大的取舍，并在用户确认后再处理；如果请求已明确焦点区域，则不在此限。
• 不要将 21:9 封面直接裁切成 1:1 并重复使用。每种比例都应单独构图。
• 3:4 卡片必须填满画布。内容（文字 + 图像 + 数据）必须覆盖画布高度的 ≥75%。任何超过画布高度 15% 的纯空白带都必须有“留白理由”：(a) hero image 自带呼吸感；(b) 单句宣言式 hero statement；(c) 段落顶部／底部的留白（前后总和 ≤15%）。禁止用 <div style="flex: 1"></div> 上下夹击，把内容挤到中间——杂志页的留白逻辑不适用于社交卡（杂志可以靠对开页吸收留白；社交卡是逐张独立刷的，填充不足会看起来像 PPT 漏排）。每种 recipe 的最低密度要求见 references/layout-recipes.md 中对应的「Minimum density」段。渲染后必须运行 qa-checklist.md 中的 4 横带密度检查。