切换语言
切换主题

guizang-social-card-skill:把小红书图文和公众号封面做成流水线

"guizang-social-card-skill GitHub README 用于确认项目定位、安装命令、版式数量、主题预设、画板尺寸、渲染流程和 AGPL-3.0 授权。"

"Claude Code skills 文档用于确认 SKILL.md、自动发现、支持文件和脚本的工作方式。"

"OpenAI Codex Skills 文档用于确认 Codex skill 的目录结构、显式 / 隐式调用和可选 scripts / references / assets。"

长文改成社媒图文,最耗人的地方通常不是想标题,而是让每张卡同时满足尺寸、留白、字体、素材、导出和复核。运营同学很快能拆出 5 个观点,却常常卡在小红书 3:4 画板、公众号 21:9 头图、1:1 分享卡这些具体格式上。临时提示词能救急,但下次再做同类内容,风格、间距和标题密度又会重新漂移。

guizang-social-card-skill 的价值在这里。它把小红书图文和公众号封面生产,包装成 Claude Code / Codex 能调用的 Skill。仓库里不是一段“请设计得高级一点”的提示词,而是包含 SKILL.md、HTML 种子模板、视觉参考、素材规则、Playwright 渲染和校验脚本的一套流程。适合它的任务,是把文章、产品笔记、截图教程、字幕或照片,整理成一组可迭代的 PNG 卡片资产。

先给结论

  • guizang-social-card-skill 面向 Claude Code / Codex 等 Agent 环境,输出小红书 / Rednote 图文组图和公众号 21:9 + 1:1 封面对。
  • GitHub README 写明它内置 Editorial 和 Swiss 两套视觉系统,覆盖 28 个版式骨架、10 套主题预设和 3 种画板尺寸。
  • 交付方式是单文件 HTML 加 Playwright 渲染 PNG,Agent 可以直接读写 HTML / CSS,再运行 node render.mjs 导出图片。
  • 它适合稳定产出“第一版可看的卡片”,不适合替代品牌设计审稿、摄影精修或平台发布审核。
  • 授权为 AGPL-3.0。团队二改、分发或做成在线服务前,要先确认开源义务。

它解决的是版式复用

很多 AI 做图文失败,问题不在模型不会写文案,而在没有可复用的版式边界。模型今天把标题放左上,明天把标题铺满全屏;今天用克制的蓝色,明天变成高饱和渐变;标题一长,footer、页码和主图主体就撞在一起。

这个 Skill 把不稳定因素收进固定流程。README 里的三种画板很明确:.poster.xhs 是 1080x1440,面向小红书 3:4;.poster.wide 是 2100x900,面向公众号 21:9;.poster.square 是 1080x1080,面向公众号分享卡。尺寸固定后,Agent 的任务从“自由发挥设计”变成“在固定容器里挑版式、压文案、替素材、跑导出”。

两套视觉系统也降低了决策成本。Editorial 更像克制的电子杂志,适合旅行、阅读、生活方式和叙事型内容。Swiss 更强调网格、锚点色和信息层级,适合工具测评、数据回顾、AI 产品说明和教程拆页。内容运营需要的往往不是每次发明新风格,而是让不同选题稳定落进少数几套可控系统。

安装和第一轮提示

GitHub README 给出的推荐安装方式是一行命令:

npx skills add https://github.com/op7418/guizang-social-card-skill --skill guizang-social-card-skill

也可以把仓库 clone 到 Claude Code 的个人 Skill 目录:

git clone https://github.com/op7418/guizang-social-card-skill.git ~/.claude/skills/guizang-social-card-skill

安装后,第一轮提示不要只写“帮我做一套小红书图文”。更稳的做法是把五件事说清楚:内容来源、平台尺寸、张数、视觉系统、素材策略。例如:

请基于这篇 AI 工具评测,做一套小红书 3:4 图文,5 张。
风格用 Swiss,主题用 IKB 蓝。
优先使用正文里的产品截图,没有合适图片时先告诉我缺哪些素材。
每张卡片控制一个核心观点,导出 PNG 前先给我看 HTML 结构和标题压缩方案。

这个提示的重点不是堆形容词,而是给 Agent 可检查的输入。平台尺寸决定画板,张数决定信息密度,视觉系统决定版式池,素材策略决定是否调用外部图源,导出前预览能提前发现标题过长和主体被遮挡。

工作流拆开看

README 把工作流拆成 Intake、Style & Theme、Layout Selection、Asset Prep、Compose & Render、Deliver & Review、Iterate。放到实际生产里,可以按下面的顺序理解。

先收集需求。目标平台是小红书还是公众号,用户有没有原图,内容是教程、测评还是旅行笔记,这些信息会影响版式和素材。

再选视觉系统。AI 工具、方法论、数据复盘优先 Swiss;人物故事、旅行和读书笔记更适合 Editorial。主题色不要临时乱填,仓库把 10 套预设列成硬边界,避免每次生成一套新配色。

然后选版式骨架。项目内置 Editorial 16 个、Swiss 12 个。对内容运营来说,这比“自由设计”更有价值,因为版式骨架会限制标题字数、信息块数量和留白比例。

素材处理要单独看。README 写了图源优先级:用户图优先,无图时按 Unsplash、Pexels、Flickr CC、Wallhaven、直接搜索取图,并落本地写 SOURCES.md。正式发布前仍然要核对授权和来源,尤其是商业账号、广告素材和品牌合作内容。

合成与导出使用单文件 HTML。Skill 会把内容放进种子模板,生成 HTML,再通过 node render.mjs 输出 PNG。HTML / CSS 是文本,对 Claude Code 和 Codex 很友好,后续改字距、留白、图片位置都可以精确修改。

最后是看图和迭代。README 特意把“默认不自动核查”写进流程,因为每轮都跑 validator 会增加等待时间。更好的节奏是先看 PNG,确认方向对,再跑 validate-social-deck.mjs 找溢出、footer 碰撞、框内元素越界和 Swiss 字重问题。

适合哪些场景

场景判断原因
技术长文拆小红书组图适合Swiss 版式能承载步骤、对比、清单和指标
AI 工具评测适合产品截图、优缺点、使用流程都能落进固定骨架
公众号封面对适合README 明确支持 21:9 与 1:1 成对输出
旅行攻略和生活方式谨慎适合Editorial 适合叙事,但素材质量决定上限
品牌级商业海报谨慎仍然需要设计师审稿、品牌手册和版权复核
纯图片修图不适合核心是排版与导出,不是精修软件
闭源二改分发高风险AGPL-3.0 对修改、分发和网络服务有开源要求

这张表可以帮你设边界。guizang-social-card-skill 不是让人瞬间变成设计师,它更像把重复、结构化、可模板化的图文生产交给 Agent。需要细腻审美判断、品牌风险判断和发布判断的地方,仍然要人接住。

QA 清单:能导出不等于能发布

社媒卡片最容易翻车的点往往很小:标题多了几个字,手机端预览糊成一团;底部来源被遮住,截图里看不见;人物脸部被遮罩压住,画面还在,信任感没了。

发布前至少检查这些项:

  • 每张卡片只承担一个主要观点,不要把长文段落直接塞进去。
  • 中文标题优先压短,公众号 1:1 分享卡尤其要保留安全边距。
  • 满铺图加遮罩后,文字落点避开人物脸、产品主体和原图文字密集区。
  • footer、页码、来源说明不能和正文块碰撞。
  • 外部图片要记录来源,商业使用前核对图库协议。
  • Swiss 模板里大字号不宜配过重字重,避免变成粗黑标题墙。
  • validate-social-deck.mjs 后,不只看 pass / fail,也要看 warning 是否指向真实视觉问题。

更稳的试用方式,是先拿一篇旧稿生成 3 到 5 张。确认版式、字号和导出链路稳定后,再批量处理一组选题。直接把一周内容全丢给它,审稿压力会集中到最后一轮,反而容易慢下来。

和普通提示词、设计工具怎样分工

普通提示词的优势是快。聊天窗口里让模型写标题、拆观点、给配色建议,几分钟就能有方向。但它的弱点也明显:版式无法稳定复现,本地图源不好承接,导出依赖截图,复盘很难。

Figma、Canva 这类设计工具更适合精修。品牌规范、组件库、多人审稿、素材管理,它们更成熟。问题是内容团队每天要出很多“够好且一致”的中间资产,全部手工做会拖慢节奏。

guizang-social-card-skill 更像内容生产里的中间层。提示词负责发散,设计工具负责精修,它负责把一套固定审美下的重复动作沉淀下来:选画板、挑骨架、压标题、放素材、跑渲染、看校验。模板、脚本、参考文档和渲染命令都在 Skill 目录里,Claude Code / Codex 按流程产出可修改的 HTML 和 PNG。对技术博主、独立开发者和小团队来说,这个中间层很实用。

接进自己的内容流程

一套稳妥流程是:

  1. 把长文压成 5 到 7 个观点,每个观点只保留一句主标题和两三条支撑信息。
  2. 用 Claude Code 或 Codex 安装 Skill,确认 SKILL.mdassets/references/ 存在。
  3. 用一篇旧文生成 3 张测试卡,不接外部图库,只用截图或纯排版。
  4. 人工检查手机端预览,记录标题长度、留白、图片遮罩和页码问题。
  5. 跑 validator,修掉溢出、footer 碰撞、框内元素越界。
  6. 扩展到 5 到 9 张组图或公众号封面对。

这个顺序能控制风险。Skill 负责把流程固化,人负责判断信息是否值得发、视觉是否合适、来源是否干净。

还有一个容易忽略的细节:把每次试跑结果留档。比如记录使用了哪套主题、哪几个版式、标题压缩前后差异、哪些图片被替换、validator 报过什么 warning。连续跑三四次后,你会得到一份适合自己账号的“小型制图规范”。以后新内容只要复用这些记录,生成速度会变快,审稿也更容易对齐。

如果团队里有多人参与,最好把原始长文、卡片 HTML、导出 PNG、SOURCES.md 和反馈记录放进同一个任务目录。这样设计同学能看到 Agent 为什么选这张图,运营同学能追踪每张卡对应的原文观点,负责人也能在发布前核对授权和文字风险。Skill 解决生产流程,目录纪律解决协作流程,两者配在一起才稳。

下一步阅读

还没用过 Claude Code Skill,可以先读 Claude Code Skill 入门指南,理解 SKILL.md 为什么比复制提示词更稳定。想让工具长期贴合项目规范,可以接着看 CLAUDE.md 写作指南。如果后面要把选题、写稿、制图、发布检查拆给不同角色,再看 Claude Subagent 实战指南

guizang-social-card-skill 值得试,但别把它当自动爆款机器。它更像一条小型生产线:把尺寸、版式、配色、渲染和检查固定下来,让人把精力放回内容判断和最后审美。先从一篇旧稿、三张图、一个主题色开始,跑顺以后再接到日常内容流水线里。

用 guizang-social-card-skill 试跑第一套社媒卡片

用一篇旧文章验证 Claude Code 或 Codex 是否能稳定生成小红书图文和公众号封面对。

⏱️ 预计耗时: 1 day

  1. 1

    步骤1: 安装 Skill

    按 GitHub README 使用 npx skills add 命令安装,或 clone 到 Claude Code 的个人 skills 目录。
  2. 2

    步骤2: 准备旧稿和素材

    选择一篇已发布旧文,准备截图或产品图,避免第一次试跑就依赖外部图库。
  3. 3

    步骤3: 写清首轮提示

    明确平台尺寸、张数、视觉系统、主题色和素材策略,让 Agent 先给 HTML 结构与标题压缩方案。
  4. 4

    步骤4: 渲染 PNG

    使用 Skill 的单文件 HTML 与 Playwright 渲染流程导出 PNG。
  5. 5

    步骤5: 人工看图

    先检查手机端预览、标题密度、遮罩、人脸避让和来源标注。
  6. 6

    步骤6: 运行 validator

    方向确认后运行 validate-social-deck.mjs,修掉溢出、footer 碰撞和框内元素越界。

常见问题

guizang-social-card-skill 能生成哪些尺寸?
GitHub README 写明它支持小红书 3:4 的 1080x1440 画板、公众号 21:9 的 2100x900 头图,以及公众号分享卡常用的 1080x1080 方图。
它和普通提示词有什么区别?
普通提示词主要靠模型即时发挥。这个 Skill 把模板、参考资料、脚本、素材规则和渲染命令放到目录里,让 Claude Code 或 Codex 按固定流程生成和迭代。
可以直接用于商业账号吗?
可以试用,但正式商用前要检查图片来源、品牌规范和 AGPL-3.0 授权。尤其是二改、分发或做成在线服务时,不应跳过许可证评估。
第一次试用该怎么做?
先拿一篇旧稿生成 3 到 5 张,不接外部图库,只用截图或纯排版。确认标题长度、留白、遮罩和导出链路稳定后,再扩展到完整组图。
需要每次都跑 validator 吗?
README 的工作流默认先交付图片给用户看,再决定是否跑 validator。正式发布前建议跑一次,重点检查溢出、footer 碰撞和框内元素越界。

10 分钟阅读 · 发布于: 2026年6月5日 · 修改于: 2026年6月8日

评论

使用 GitHub 账号登录后即可评论