| name | xhs-note-assembly |
| description | 从已确认的故事线出发，整合 `fact_pack`、`story_spine`、正文、封面和图组，输出最终小红书成稿。这是产出主线 skill。用户提到写标题、正文、图文页内容、四张图故事、最后成稿、整理成可发布帖子、生成 post.md 发布正文、写小红书正文、改文案、基于这个话题出一版、围绕这个事件出一篇时，务必使用这个 skill。默认直接交付 `publish-ready copy`，并保留人类在标题、封面方向和删改力度上的最终决定权。 |
XHS Note Assembly
这个 skill 是从 story_spine 到可发稿的主装配器。
它负责：
- 读取
fact_pack 和 story_spine
- 输出标题、正文、图组任务
- 默认交付
publish-ready copy，必要时再附 research-safe draft
- 从成稿中提取封面结构
前提：
如果还在发想题目，先回到 xhs-topic-angle-shortlist。
如果正在做单篇研究但故事线还没收住，先完成 fact_pack 和 research/story_spine.md。
什么时候用
- 用户说“现在写成稿”
- 用户要标题、正文、图上文案一起出
- 用户要 3-4 张图的故事板
- 用户要把前面讨论整理成最终笔记
- 用户说「基于这个话题出一版 / 围绕这个事件出一篇 / 给我这条的标题和正文」，即使没有显式说「成稿」
绝对禁区（违反就是不合格稿）
这几条是硬红线，不允许为了速度跳过：
- 发布正文里禁止出现
Page X / 第 X 图 / P1-P8 / 图组 / 图上文案 字样
- 发布正文是读者看到的，图组分工是工作稿，两个必须是物理分开的 section
- 如果正文里蹦出了「第 1 图讲...」这种话，直接不合格，回去重写
- 研究数据没进
fact_pack.md 不准进正文
- 任何 WebSearch / WebFetch 抓来的数字、报价、报道，必须先 Edit 进
fact_pack.md 对应 section，才能被 post.md 引用
- 「查完直接写正文」是最容易吃亏的 shortcut，不允许
- 没有 post workspace 不允许只在聊天里交稿
- 当用户 ask 已经是「围绕 X 出一篇」级别，而 repo 里没有
demo_posts/<date>-<slug>/ 时，第一步必须先 scaffold 工作区，不是直接回聊天稿
- 用
python scripts/scaffold_post_folder.py --date <YYYY-MM-DD> --slug <slug> --title "..."
- 聊天里的 publish-ready copy 只能当预览，repo 产物才是交付完成
- 封面没过四项检查不算锁定
- 主角 / 动作 / 冲突 / 场景背景，四项必须逐项回答，不能跳
写作前必答 checklist（每题一句话，写在脑中或 post.md 顶部）
开始写正文之前，先把这六题答出来。没答出来就是还没准备好动笔。
研究输入
默认先读取：
research/fact_pack.mdresearch/story_spine.md
成稿时要做的是：
- 从
fact_pack 中挑出最该进正文和图上的事实
- 服从
story_spine 的单一故事线
- 成稿底部附上事实包摘要，供用户核对数字和来源
如果 fact_pack 缺失，可以补一个轻量事实整理再继续；但默认 workflow 仍然是先有研究底稿，再写成稿。
如果材料还不完整
- 如果角度已锁、但研究资料不足：
先产出
标题候选 + 正文骨架 + 缺失信息清单，不要假装已经能写最终版
- 如果用户只想先看文字方向：
可以先省略 prompt 和素材说明
交付层级
- 默认直接给用户
publish-ready copy
- 只有在用户明确要保留研究口径，或事实仍待核时，再额外附
research-safe draft
- 不要把研究稿语气直接当成发布稿交出去
通用写作约束
1. 少用不必要英文，默认输出简体中文
- 标题、正文、图上文案、话题标签默认都用简体中文
- 如果用户给的是繁体草稿，最终成稿默认转成简体中文，引用原话或专有名词除外
- 只有在专有名词确实必要时才保留英文，并且第一次出现要给中文解释
- 不要为了“像体育媒体”保留一串英文术语，读者看不懂就会直接划走
2. 先给总判断，再把故事讲明白
- 默认读者不懂这项赛事、规则或商业背景
- 开头第一句优先给一个总判断，先回答“这事到底说明了什么”
- 如果是商业题，默认先写
结果 / 结论 + 最大数字 + 最短归因，不要先用问题句把读者挂着
- 开头前两段必须回答：
这是什么、为什么现在热、为什么你该关心
- 解释顺序优先是：事件 -> 冲突 -> 背后的钱/规则 -> 你的判断
3. 语气与 emoji
- 语气：street-smart analyst — “说白了就是...”、”真相是...”，不要文邹邹，也不要暖心鸡汤
- 标题允许
1-2 个 emoji 开头
- 正文用
2-4 个 emoji，放在模块开头或关键数字前，不要装饰性地散落
- emoji 是叙事工具（AutoResearch 验证）：🔍📈💸 分别对应谜面/揭答/金钱逻辑，本身在做敘事工作。移除后情绪损耗明显。数字型 ①②③ 替换全败
- 优先用和运动、情绪、涨跌、对比相关的图像 emoji
组装原则
1. 正文结构要短，但论点链不能断
默认写成 3-5 个模块，按故事需求而定。简单商业题 3 块就够，复杂争议题或多方对比题可放宽到 5 块。
每个模块只回答一个读者问题。如果一个段落在回答两个问题，拆开或砍掉。
推荐段落动作：
- 每段前半句优先出现一个数字、变化或明确事实
- 可以用很短的小标签起段，例如：
先说结论、为什么现在、但问题还没完
- 最后一段要留一个”事情还没讲完”的尾钩，不要平着收掉
- 每模块 2-4 句，不要堆墙
推荐问题块（按需取 3-5 个）：
- 这到底是什么
- 发生了什么
- 为什么这样做
- 谁在赚钱 / 背后的商业逻辑
- 为什么大家在吵
- 现在看值不值 / 该怎么判断
正文总字数 150-300 字。低于 150 内容撑不住，高于 300 读者划走。
1.1 叙事结构（AutoResearch 验证）
优先使用 mystery arc：先埋一个反直觉的事实或异常，让读者想知道”为什么”，再在后面揭答案。
备选：number shock — 第一句直接扔出最令人意外的数字，再解释为什么意外。
避免：contrast 开场（”所有人都说X，但真相是Y”）和 in_media_res（竞技现场描写和商业知识腔有摩擦）。
1.2 场景细节与具体引言（AutoResearch 验证）
- Scene scripting：开场模块写一句能让读者”看见”的细节（地点、动作、人物做了什么）。不要把场景描写扩散到所有模块，否则稀释商业密度。
- Concrete quote rule：模块 1 展示公众反应时，用一个具体的引言或行动，不要用模糊的群体描述。
- 差：「粉丝讨论区天天吵要不要放弃他」
- 好：「球迷讨论区里最高票的那条评论是『这球队根本选错人了』。他就是在这种声音里，把每一场败仗打完的」
1.3 固定讲故事动作
产文时，默认先检查这 5 个动作有没有做到：
- 开头用 mystery 或 number shock 制造阅读拉力
- 开场模块至少一句可视化场景细节
- 每段前半句尽量先给数字、变化或反直觉事实
- 每个模块至少 1 个具体数字（不可移除，数字是可信度和传播力的基础）
- 最后一段留一个”但问题还没完”的尾钩
1.4 当前账号默认完整介绍风格
如果是“人物带动变化”的介绍型帖子，默认写成这个顺序：
- 第 1 段：
先给总判断，再说
这是什么 + 为什么现在
- 第 2 段：
只补足够理解这件事的背景，不写成长人物百科
- 第 3 段：
落到
为什么值得关心 / 大家在吵什么 / 你怎么看
要点：
- 介绍人物，不等于写人物简历
- 默认先写“这个人改写了什么”
- 让不懂的人 3 段内跟上，比写全更重要
2. 标题先抢打开率（AutoResearch v3 验证，605+ 轮 A/B）
规则：
- 18-20 个中文字符（不含 emoji），用满字数预算，每个字都要赚到位置
- 1-2 个 emoji 开头，不要堆
- 至少一个具体数字（移除数字的 mutation 只有 ~4% 胜率，几乎全败）
- 核心人名/联盟/赛事出现在前 12 个字
- 驱动词：为什么、值不值、凭什么、谁更强、怎么做到、背后是什么
最强结构（83% 胜率）：
- 对比钩子：「你以为X...其实Y」/「都说X...但Y」— 同时制造好奇缺口和挑战假设
语气：
- Street-smart analyst（唯一有效语气）："说白了"、"别被骗了"、"真相是"
- 暖心 / 随意语气 ~14% 胜率，几乎全败
经验证的标题骨架：
X 身价翻了 Y 倍，凭的是什么？X 做对了一件事，Y 都慌了三个数字看懂 X 到底有多夸张X 这笔交易，到底谁是冤大头？都说 X，但真相是 Y你以为 X 是 Y，其实是 ZY 年前没人看好 X，现在呢？
标题优先顺序要看题型：
商业题默认优先：
争议题或纯讨论题再优先：
已淘汰的策略（不要再用）：
- 调整字数到 12 字以下（0%）
- 换 emoji（0%）
- what-if 假设句（0%）
- 强制公式如"人名 + 为什么"（只有 20%，太机械）
无论哪种题型，都至少产出一版 结果句版 标题。
3. 图文分工要互补
- 图上讲最直观的东西
- 正文讲“为什么”
- 来源沉到底部
同时要满足：
- 首图和首段让不懂的人也知道主题大概是什么
- 图上文案不要堆英文缩写
4. 互动收口（AutoResearch 验证优先级）
收口不要问太空泛的问题。永远不要用"你怎么看"收尾。
优先级从高到低：
- hate_bait 讽刺弧线（最强）：当年骂最凶的人现在翻脸最快。格式：「当年最大声[骂/唱衰]的[球迷/媒体]，现在[具体态度逆转行为]最快」— 触发"说的就是我"的自我代入评论
- 反转：引入一个之前没提到的隐藏数据点，改变整题的结论框架。需要确实有新信息，否则会空洞
- A/B/C 押注：选项 C 设计成呼应标题关键词，形成首尾闭环
- 判断二选一：值/不值、稳了/悬了 — 干净的二元选择
三选一 / 预测 / 站队 — 在商业知识型话题效果差，强迫读者"押注"不如让读者"判断"
5. 人工最终拍板
默认由人类决定：
6. 话题标签要能搜到，不要只是凑数
- 默认输出
4-8 个话题标签
- 前
2-3 个标签优先绑定核心人物、赛事或联盟
- 其余标签再补项目大类、情绪入口或话题场景
- 以简体中文标签为主，只有平台常用英文标签才保留英文
- 不要堆太泛的空标签，也不要用和正文无关的流量词
图组预设
默认不需要单独跑 xhs-visual-asset-mix，直接套用账号预设：
- 图 1：生图封面
- 图 2-4：真人照片或官方截图为主
如果准备发 2 张以上内页，先在这里写一个最小 storyboard：
三者缺一，就先缩减页数，不要硬做满。
只有在用户明确纠结"真人图还是生图"，或 storyboard 过不了这道检查时，才单独启用 xhs-visual-asset-mix。
封面提取
封面仍从成稿中提取，但默认先过一次简版 cover check；只有预设结构不适合这题，才展开 xhs-cover-template。
提取规则
- 标题：直接使用成稿锁定的最终标题
- 检查是否符合两行限制（每行不超过 8 字）
- 如果超过，在这步砍字
- 主角：从正文中识别绝对主角（通常是第一段提到的核心人物）
- 动作：先用一句话说清人物或画面正在发生什么
- 冲突：确认这张封面到底在放大哪一个结果、张力或反差
- 场景：从正文背景信息中提取场景符号
封面结构（账号预设）
三层，从上到下：
- 标题区：超大判断句或数字，最多两行，第一视觉中心
- 人物区：可辨识人脸，半身构图
- 场景背景：深色场景底，体育现场符号
不加背景说明小字。封面只靠标题和人物拦停。
封面字体
- 统一使用
阿里巴巴普惠体 Bold/Heavy
- 靠字重区分层级，不混用其他字体
- 深色背景用白字或亮色字，标题和背景必须有明确对比
什么时候需要单独启用 cover-template
- 这篇没有人物主角，需要探索替代封面方向
- 用户明确说要换封面结构
- 预设结构明显不适合这个题
Publish Polish
交付前必须再过一次 publish polish：
- 去掉反引号和 Markdown 痕迹
- 把裸列年份改成因果链，不要直接堆时间线
- 把术语翻成人话，精确口径留给事实摘要
- 查一次错别字、异常空格和断句
存档约定
成稿必须落到 demo_posts/<date>-<slug>/text/post.md，聊天里的输出只能当预览。
两种情况：
「没有目录时也允许聊天交稿」不是合法例外，是漏洞。任何时候只要用户的 ask 已经落到「出一篇」，就先建目录再动笔。
输出格式
## 标题候选
1. ...
2. ...
3. ...
## 最终标题
- ...
## 正文
### 小标签 1
...
### 小标签 2
...
### 小标签 3
...
## 封面（从成稿提取）
- 标题：（从最终标题带入，确认符合两行限制）
- 主角：
- 动作：
- 冲突：
- 场景背景：
- 字体：阿里巴巴普惠体 Bold/Heavy
- 对比方式：
- 是否走预设：是 / 否（如否，说明探索方向）
## 图组
### 图 1（生图封面）
- 任务：
- 画面说明：
- 给 xhs-image-style-duo 的 brief：
### 图 2
- 任务：
- 场面：
- 新增信息：
- 建议素材类型：真人照片 / 官方截图 / 生图
- 图上文案：
- 素材说明：
### 图 3
...
### 图 4
...
## 事实包摘要
- 关键数字：
- 来源：
- 待确认项：
## 话题标签
- #...
- #...
## 需要人拍板
- 标题：
- 封面方向：
- 删减：
不要这样做
- 不要重新发明角度
- 不要把 fact pack 原封不动贴进正文
- 不要一边写成稿一边重新定义每张图的任务
- 不要把所有信息都塞进标题和封面
- 不要默认读者已经懂这项赛事或规则
- 不要用英文和黑话制造”懂的人自然懂”
- 不要在封面步骤重新想标题，标题从成稿带入
- 不要每篇都单独跑 visual-asset-mix，套用图组预设即可
快速参考
