xhs-note-assembly

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 张图的故事板
• 用户要把前面讨论整理成最终笔记
• 用户说「基于这个话题出一版 / 围绕这个事件出一篇 / 给我这条的标题和正文」，即使没有显式说「成稿」

绝对禁区（违反就是不合格稿）

这几条是硬红线，不允许为了速度跳过：

1. 发布正文里禁止出现 Page X / 第 X 图 / P1-P8 / 图组 / 图上文案 字样
   • 发布正文是读者看到的，图组分工是工作稿，两个必须是物理分开的 section
   • 如果正文里蹦出了「第 1 图讲...」这种话，直接不合格，回去重写
2. 研究数据没进 fact_pack.md 不准进正文
   • 任何 WebSearch / WebFetch 抓来的数字、报价、报道，必须先 Edit 进 fact_pack.md 对应 section，才能被 post.md 引用
   • 「查完直接写正文」是最容易吃亏的 shortcut，不允许
3. 没有 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 产物才是交付完成
4. 封面没过四项检查不算锁定
   • 主角 / 动作 / 冲突 / 场景背景，四项必须逐项回答，不能跳

写作前必答 checklist（每题一句话，写在脑中或 post.md 顶部）

开始写正文之前，先把这六题答出来。没答出来就是还没准备好动笔。

• 目标字数（150-300）：
• 计划几段（3-5）：
• 开头用 mystery 还是 number shock：
• 每段计划塞哪个数字：
• 收口用 hate_bait / 反转 / A-B-C / 二选一 哪一种：
• fact_pack.md 是否已经落盘：

研究输入

默认先读取：

• research/fact_pack.md
• research/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，其实是 Z
• Y 年前没人看好 X，现在呢？

标题优先顺序要看题型：

商业题默认优先：

• 结果 / 结论
• 人物判断
• 人名 / 赛事
• 数字

争议题或纯讨论题再优先：

• 争议
• 问题
• 人名 / 赛事
• 数字

已淘汰的策略（不要再用）：

• 调整字数到 12 字以下（0%）
• 换 emoji（0%）
• what-if 假设句（0%）
• 强制公式如"人名 + 为什么"（只有 20%，太机械）

无论哪种题型，都至少产出一版 结果句版 标题。

3. 图文分工要互补

• 图上讲最直观的东西
• 正文讲“为什么”
• 来源沉到底部

同时要满足：

• 首图和首段让不懂的人也知道主题大概是什么
• 图上文案不要堆英文缩写

4. 互动收口（AutoResearch 验证优先级）

收口不要问太空泛的问题。永远不要用"你怎么看"收尾。

优先级从高到低：

1. hate_bait 讽刺弧线（最强）：当年骂最凶的人现在翻脸最快。格式：「当年最大声[骂/唱衰]的[球迷/媒体]，现在[具体态度逆转行为]最快」— 触发"说的就是我"的自我代入评论
2. 反转：引入一个之前没提到的隐藏数据点，改变整题的结论框架。需要确实有新信息，否则会空洞
3. A/B/C 押注：选项 C 设计成呼应标题关键词，形成首尾闭环
4. 判断二选一：值/不值、稳了/悬了 — 干净的二元选择
5. 三选一 / 预测 / 站队 — 在商业知识型话题效果差，强迫读者"押注"不如让读者"判断"

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。

提取规则

1. 标题：直接使用成稿锁定的最终标题
   • 检查是否符合两行限制（每行不超过 8 字）
   • 如果超过，在这步砍字
2. 主角：从正文中识别绝对主角（通常是第一段提到的核心人物）
3. 动作：先用一句话说清人物或画面正在发生什么
4. 冲突：确认这张封面到底在放大哪一个结果、张力或反差
5. 场景：从正文背景信息中提取场景符号

封面结构（账号预设）

三层，从上到下：

1. 标题区：超大判断句或数字，最多两行，第一视觉中心
2. 人物区：可辨识人脸，半身构图
3. 场景背景：深色场景底，体育现场符号

不加背景说明小字。封面只靠标题和人物拦停。

封面字体

• 统一使用 阿里巴巴普惠体 Bold/Heavy
• 靠字重区分层级，不混用其他字体
• 深色背景用白字或亮色字，标题和背景必须有明确对比

什么时候需要单独启用 cover-template

• 这篇没有人物主角，需要探索替代封面方向
• 用户明确说要换封面结构
• 预设结构明显不适合这个题

Publish Polish

交付前必须再过一次 publish polish：

• 去掉反引号和 Markdown 痕迹
• 把裸列年份改成因果链，不要直接堆时间线
• 把术语翻成人话，精确口径留给事实摘要
• 查一次错别字、异常空格和断句

存档约定

成稿必须落到 demo_posts/<date>-<slug>/text/post.md，聊天里的输出只能当预览。

两种情况：

• 已有贴文目录：直接 Edit 到 demo_posts/<date>-<slug>/text/post.md，标题候选 / 最终标题 / 发布正文 / 图组分工 / 来源都塞进同一个文件
• 没有贴文目录：先 scaffold，再写稿

  python scripts/scaffold_post_folder.py \
    --date <YYYY-MM-DD> \
    --slug <short-ascii-slug> \
    --title "工作标题"
  

  scaffold 出来的 post.md 已经带骨架（Working Brief / 写作前必答 / 标题候选 / 发布正文 + 自检 checklist / 图组分工 / 来源尾注），直接在里面填就行。

「没有目录时也允许聊天交稿」不是合法例外，是漏洞。任何时候只要用户的 ask 已经落到「出一篇」，就先建目录再动笔。

输出格式

## 标题候选
1. ...
2. ...
3. ...

## 最终标题
- ...

## 正文
### 小标签 1
...

### 小标签 2
...

### 小标签 3
...

## 封面（从成稿提取）
- 标题：（从最终标题带入，确认符合两行限制）
- 主角：
- 动作：
- 冲突：
- 场景背景：
- 字体：阿里巴巴普惠体 Bold/Heavy
- 对比方式：
- 是否走预设：是 / 否（如否，说明探索方向）

## 图组
### 图 1（生图封面）
- 任务：
- 画面说明：
- 给 xhs-image-style-duo 的 brief：

### 图 2
- 任务：
- 场面：
- 新增信息：
- 建议素材类型：真人照片 / 官方截图 / 生图
- 图上文案：
- 素材说明：

### 图 3
...

### 图 4
...

## 事实包摘要
- 关键数字：
- 来源：
- 待确认项：

## 话题标签
- #...
- #...

## 需要人拍板
- 标题：
- 封面方向：
- 删减：

不要这样做

• 不要重新发明角度
• 不要把 fact pack 原封不动贴进正文
• 不要一边写成稿一边重新定义每张图的任务
• 不要把所有信息都塞进标题和封面
• 不要默认读者已经懂这项赛事或规则
• 不要用英文和黑话制造”懂的人自然懂”
• 不要在封面步骤重新想标题，标题从成稿带入
• 不要每篇都单独跑 visual-asset-mix，套用图组预设即可

快速参考

• references/examples.md 何时读：要确认正文是不是太像整理稿、太长、或没有尾钩时。

• references/research-validated-rules/body-rules.md 何时读：写正文骨架（3 模块顺序 / mystery arc / scene scripting / 收口选择）。来自 5 话题 × 25 轮 + Pistons v1/v2/v3 共 155 次 A/B 验证。

• references/research-validated-rules/title-rules.md 何时读：写标题（具体数字 / 反问句 / 护城河三元素）。来自跨 5 话题 80+ 次 A/B 验证。