一键导入
xhs-image-style-duo
为已确定要生图的页面输出默认 `1` 个推荐风格和 `1` 条可直接贴到 ChatGPT / Gemini 等网页里的 final prompt。用户明确说要比较时,才输出 `2` 个风格候选。它负责风格延展,不负责整组图分工,也不负责默认首图结构。严禁默认走 API 生图。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
为已确定要生图的页面输出默认 `1` 个推荐风格和 `1` 条可直接贴到 ChatGPT / Gemini 等网页里的 final prompt。用户明确说要比较时,才输出 `2` 个风格候选。它负责风格延展,不负责整组图分工,也不负责默认首图结构。严禁默认走 API 生图。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | xhs-image-style-duo |
| description | 为已确定要生图的页面输出默认 `1` 个推荐风格和 `1` 条可直接贴到 ChatGPT / Gemini 等网页里的 final prompt。用户明确说要比较时,才输出 `2` 个风格候选。它负责风格延展,不负责整组图分工,也不负责默认首图结构。严禁默认走 API 生图。 |
在产出任何生图 prompt 前,必须做两件事:
视觉宪法 + 风格选择:
CLAUDE.md 顶部「账号视觉宪法」三条(漫画优先 / 真人脸漫画化 / photo 只取文字 anchors)references/cover-style-pool.md 风格池 + 双轴决策表选风格physically-rendered manga figure with photo-accurate likeness, rendered as comic illustration (not photo) —— 不要再写 photorealistic foreground transitionphotorealistic / cinematic photoreal / studio photo / 8k photoreal / octane render / reference photo真人辨识度 Gate:读 references/person-confidence-rubric.md
anchors_suggestion 进 prompt + 对话中提示按视觉宪法第 3 条 — photo pipeline 只用来提取文字 anchors,不 embed 照片:
# 运动号优先 ESPN:
python scripts/fetch_player_photo.py "<Player Name>" \
--espn-id <id> \
--school <team> \
--output references/players/<slug>
# 批次:
python scripts/fetch_player_photo.py --batch references/players/<manifest>.json
references/players/<slug>/espn_headshot.png(+ espn_action.png / wikipedia.jpg)references/players/<slug>/appearance.md,按 references/players/README.md 的 schema(髮型 / 髮色 / 膚色 / 臉型 / 臉部特徵 / 體型 / 招牌標記 + 一段 Prompt 用描述),信心度标「已確認」appearance.md,把「Prompt 用描述」文字段落嵌入 Final Prompt 的人物描述段
reference photo: <path> / based on photo / 照片中的人物 这类指令复用规则:appearance.md 已存在就直接 Read、不重跑脚本。照片被 .gitignore 掉不进版控,appearance.md 是金本一人一次就够。
手动 fallback:网络受限时用户手动把照片存到 references/players/<slug>/,AI 一样 Read → 写 appearance.md。Step 2-4 不变。
违反这两条铁律前请先 stop 并询问用户。
不再有「canonical / 脱离 canonical」的二元划分 — canonical-breakout 是全题型默认,按题型 / 情绪在 references/cover-style-pool.md 双轴表里切换。简化映射:
| 题目 / 用户信号 | 推荐首选 | 备选(出两版时用) |
|---|---|---|
| NBA / MLB 动作题(高张力) | ⭐ canonical-breakout | slam-dunk-classic |
| 球员故事 / 个人成长 / profile | watercolor-ink 🟡 | canonical-breakout |
| 群像 / 系列 / 多角色 | slam-dunk-classic 🟢 | 100m-poster |
| 商业题 / 薪资 / 转播(高张力) | 100m-poster 🟡 | canonical-breakout |
| 致敬 / 退役 / 生涯回顾 | slam-dunk-movie 🟡 / ink-wash-silhouette 🔬 | watercolor-ink |
| 系列统一视觉 / 设计感 | risograph-duotone 🔬 | 100m-poster |
| 轻知识 / 辅助图 / 可爱 | mascot-q 🟢 | — |
以下情况,agent 应主动出两版(不是一版):
不需要出两版的情况:标准 NBA 动作题、用户明确指定风格、节奏紧张只要出一版。
踩过的坑:同模板 {player} 变量 × 4 人 → AI 把四人都画成同一个正面跳投。详见 四大天王 post-mortem 的第 5 条。
两个工具必须一起用,缺一不可:
- {player A}: {unique action A}
- {player B}: {unique action B}
- {player C}: {unique action C}
NO ball in frame. NO arms raised in shooting motion.
Do not draw any of them in a frontal-shooting pose.
Do not show any of them holding a ball above their head.
如果是 4 人封面,再额外加 pose differentiation enforcement 段在 prompt 尾部:
POSE DIFFERENTIATION ENFORCEMENT: the four players must NOT share the same
action type. Two attacking + two defending, four different camera angles,
four different emotions.
这层 redundancy 看起来多余,实战证明是必要的。生成 prompt 时,任何「多个球员 + 同模板」场景都先检查这两条有没有放进去。
动作选择规则:动作要服务叙事。回标题找核心矛盾(进攻 / 防守 / 归来 / 王座),再分配动作。不要谁最帅画谁。
每产出一个 prompt,必须走完这三步。只走一两步不算交付。
demo_posts/<slug>/prompts/demo_posts/<date>-<slug>/prompts/(workspace 不存在就先用 scripts/scaffold_post_folder.py 建)cover_prompt.md、page2_prompt.md、page3_prompt.md …(多版本用 cover_prompt_v2.md 继续往上叠)## Final Prompt 内含 ```text ``` 代码块 / 如果要继续改stage_prompt.py 一次做完 commit + push + 印 URLpython scripts/stage_prompt.py demo_posts/<slug>/prompts/<name>_prompt.md
# 多个一起也 OK:
python scripts/stage_prompt.py path1.md path2.md -m "prompts: <自定 message>"
脚本会 git add → commit → push,并按当前 branch 印出 GitHub blob URL。URL 必须直接从脚本输出复制进聊天,不要手拼。
格式(照着 CLAUDE.md 的示例):
**<标题/图名> v<版本>**
构图:<layout、分区比例、几个模块>
动作:<镜头、姿态、关键动作瞬间>
风格:<canonical break-out / A-E 风格包的名字;非预设要写为什么>
改动:<和上一版的 diff 要点;首次生成就写 v1 锚点>
Prompt: <从 stage_prompt.py 复制的 GitHub blob URL>
```text ``` 代码块。demo_posts/<slug>/prompts/<name>_prompt.md 再走步骤 2-3。讨论稿不是交付稿。这个 skill 只做一件事:
把一个已经锁住任务的页面,变成 可直接在网页聊天界面里使用的生图 prompt。
默认交付不是“两套风格实验包”,而是:
1 个推荐风格1 条 final prompt只有用户明确说:
才进入 duo 模式,输出 2 条 final prompt。
默认交付必须满足这 5 条:
3:4 比例(小红书标准首图比例)这个 skill 不负责决定整篇帖子该用真人图、官方截图还是生图。那一步交给 xhs-visual-asset-mix。
如果是图 1 首图,但封面结构还没锁住,先回到 xhs-cover-template 或按 README 的主流程先锁首图结构。
遇到这些任务直接使用:
xhs-visual-asset-mixxhs-cover-template 或 xhs-note-assemblyexplorations/visuals/如果读者不懂赛事或规则,画面里也要有足够明确的主角、冲突和信息锚点。
图上可见文字是否真的需要,也要先判断;真正给用户看的角标和封面词,优先短中文。
内部可以按这个顺序想,但默认不要把全部中间层都交给用户:
默认只把 final prompt 交付给用户。
只有在调图阶段明确需要排查问题时,才额外展示:
story atomssubject anchor promptbackground prompt默认优先级:
欧美游戏动画电影感 / 热血运动动画封面体育商业杂志拼贴 / 极简数据海报Q 版吉祥物优先用脚本:
但这个脚本现在的职责是:
1 个推荐 prompt2 个 prompt默认产物应该是:
final_prompt.txtweb_prompts.md如果是比较模式,再额外输出:
style_1_final_prompt.txtstyle_2_final_prompt.txtprompt 落盘路径和命名见顶部「交付闭环」步骤 1,不再重复。
额外约定(不走 stage_prompt.py,手动处理):
demo_posts/<date>-<slug>/images/,用 cover.png / page2.png / cover_v2.png 这种和 prompt 文件名能对得上的命名## 推荐风格
- 风格:
- 为什么选它:
- 这张图最该卖什么:
## Final Prompt
```text
...
### 比较模式
```markdown
## Style 1
- 风格:
- 为什么选它:
## Final Prompt 1
```text
...
...
## 快速参考
- [references/style-profiles.md](./references/style-profiles.md)
何时读:要从风格包里挑主风格和备选风格时。
- [references/style-selection-rules.md](./references/style-selection-rules.md)
何时读:不确定该优先选哪一个风格,或比较模式下该选哪两个时。
- [references/prompt-polish-rules.md](./references/prompt-polish-rules.md)
何时读:用户说背景太乱、动作不够、脸不够像、Q 版不够可爱时。
- [references/output-evaluation.md](./references/output-evaluation.md)
何时读:已经有两个 prompt,但不知道该继续哪一个时。
## 不要这样做
- 不要默认输出两种风格
- 不要默认把 `story atoms / subject anchor / background prompt` 全交给用户
- 不要把流程说明、参考案例、上传图片解释写进 final prompt
- 不要让 final prompt 依赖 API 参数才能使用
- 不要默认尝试 API 生图
- 不要先决定画风,再决定这张图要卖什么
- 不要先把背景写得比主角还重要
- 不要把可见文案默认写成英文大字
从已确认的故事线出发,整合 `fact_pack`、`story_spine`、正文、封面和图组,输出最终小红书成稿。这是产出主线 skill。用户提到写标题、正文、图文页内容、四张图故事、最后成稿、整理成可发布帖子、生成 post.md 发布正文、写小红书正文、改文案、基于这个话题出一版、围绕这个事件出一篇时,务必使用这个 skill。默认直接交付 `publish-ready copy`,并保留人类在标题、封面方向和删改力度上的最终决定权。
为小红书内容发想值得研究的题目和可能切角,并维护跨 post 的 topic / angle backlog。用户提到选题、热点池、先想几个题、可能切角、哪个更值得先研究、题目 backlog、标题方向时,务必使用这个 skill。默认输出 `2-3` 个值得继续研究的候选,并给出本轮优先项,把未采用的点子沉淀到 `explorations/backlog/`。
为小红书帖子锁定首图封面结构的首图检查器。默认情况下,首图阶段要先做一次快速 `cover check`;只有账号预设明显不适配时,才继续展开替代封面探索。
对比真实发帖版本和草稿版本,整理差异、归因和下次要改的工作流。用户提到复盘、归因、为什么最后发成这样、发布后总结、真实帖子和草稿差异、更新创作方法,或说「review 这篇 / review 已发的 / 看一下我这篇 / 这篇发出去了」配合过去式(发了 / 发布了 / 已经发 / 上线了 / 贴出去了)时,务必使用这个 skill,不要走 pre-publish 产品侧评审。输出具体可执行的规则,不写空泛总结。
素材路由器(仍尽量少用)。当用户明确纠结”真人图还是生图”、需要证据截图分工、或 `2` 张以上内页还没想清每页任务时启用。默认情况下,图组分工仍由 xhs-note-assembly 直接套用账号预设完成。
将本地 `skills/` 相关改动安全同步到远端 GitHub。用户提到 `/sync-skills`、同步 skills、开新 branch、干净 commit、不要把 post 改动混进同一个 PR、把本地 skill 改动发到 GitHub 时,使用这个 skill。