메뉴
素材路由器（仍尽量少用）。当用户明确纠结”真人图还是生图”、需要证据截图分工、或 `2` 张以上内页还没想清每页任务时启用。默认情况下，图组分工仍由 xhs-note-assembly 直接套用账号预设完成。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | xhs-visual-asset-mix |
| description | 素材路由器（仍尽量少用）。当用户明确纠结”真人图还是生图”、需要证据截图分工、或 `2` 张以上内页还没想清每页任务时启用。默认情况下，图组分工仍由 xhs-note-assembly 直接套用账号预设完成。 |
这个 skill 仍然不是默认步骤。 默认情况下，图组分工直接在
xhs-note-assembly中按账号预设完成（图 1 生图封面 / 图 2-4 真人或截图）。 只有在素材选择确实需要单独讨论，或多张内页过不了最小 storyboard 检查时，才启用这个 skill。
这个 skill 负责决定：
真人图 / 官方截图 / 生图 的哪一种不要在这一步细调画风 prompt，那交给 xhs-image-style-duo。
只在以下情况才单独启用：
2 张以上内页，但每页还没有独立任务和场面主要任务通常只有这几种：
这页新增了什么如果图上需要补字：
体育知识型帖子默认优先：
1 张 生图封面1-2 张 真人或官方截图1 张 生图解释图选封面主角时：
默认需要人类提供或拍板：
xhs-cover-template + xhs-image-style-duo每一页先写清 3 件事：
例如：
示例：
任务 / 场面 / 新增信息，这页先删掉1 张强封面 + 纯文字真实截图 / 官方图，不要先补一张空泛生图但不要反过来。
先判断有没有比生图更强的真实证据，再决定要不要全生图。
如果图 1 最终是生图：
xhs-note-assembly 已经提取好的封面结构xhs-cover-templatexhs-image-style-duo 输出网页可直接使用的最终 prompt默认要求人类拍板：
如果当前已经有贴文目录，默认把视觉分工和后续图片资产放进同一个贴文工作区：
demo_posts/<date>-<slug>/prompts/ 或同目录说明文件demo_posts/<date>-<slug>/images/不要把图片计划散落在根目录。
## 图组策略
- 建议张数：
- 建议配比：
## 每张图分工
### 图 1
- 任务：
- 场面：
- 新增信息：
- 素材类型：
- 为什么：
- 小白一眼会看到什么：
- 需要人提供什么：
### 图 2
- 任务：
- 场面：
- 新增信息：
- 素材类型：
- 为什么：
- 小白一眼会看到什么：
- 需要人提供什么：
## 素材清单
- 真人素材候选：
- 官方截图候选：
- 可直接生图的页：
- 如果图 1 生图，是否需要进入 `xhs-cover-template`：
## 需要人拍板
- 封面路线：
- 真人图选择：
- 官方截图选择：
从已确认的故事线出发，整合 `fact_pack`、`story_spine`、正文、封面和图组，输出最终小红书成稿。这是产出主线 skill。用户提到写标题、正文、图文页内容、四张图故事、最后成稿、整理成可发布帖子、生成 post.md 发布正文、写小红书正文、改文案、基于这个话题出一版、围绕这个事件出一篇时，务必使用这个 skill。默认直接交付 `publish-ready copy`，并保留人类在标题、封面方向和删改力度上的最终决定权。
为小红书内容发想值得研究的题目和可能切角，并维护跨 post 的 topic / angle backlog。用户提到选题、热点池、先想几个题、可能切角、哪个更值得先研究、题目 backlog、标题方向时，务必使用这个 skill。默认输出 `2-3` 个值得继续研究的候选，并给出本轮优先项，把未采用的点子沉淀到 `explorations/backlog/`。
为已确定要生图的页面输出默认 `1` 个推荐风格和 `1` 条可直接贴到 ChatGPT / Gemini 等网页里的 final prompt。用户明确说要比较时，才输出 `2` 个风格候选。它负责风格延展，不负责整组图分工，也不负责默认首图结构。严禁默认走 API 生图。
为小红书帖子锁定首图封面结构的首图检查器。默认情况下，首图阶段要先做一次快速 `cover check`；只有账号预设明显不适配时，才继续展开替代封面探索。
对比真实发帖版本和草稿版本，整理差异、归因和下次要改的工作流。用户提到复盘、归因、为什么最后发成这样、发布后总结、真实帖子和草稿差异、更新创作方法，或说「review 这篇 / review 已发的 / 看一下我这篇 / 这篇发出去了」配合过去式（发了 / 发布了 / 已经发 / 上线了 / 贴出去了）时，务必使用这个 skill，不要走 pre-publish 产品侧评审。输出具体可执行的规则，不写空泛总结。
将本地 `skills/` 相关改动安全同步到远端 GitHub。用户提到 `/sync-skills`、同步 skills、开新 branch、干净 commit、不要把 post 改动混进同一个 PR、把本地 skill 改动发到 GitHub 时，使用这个 skill。