# Xhs Content

> 小红书短图文内容生成。从AI日报中提取选题，生成适合小红书平台的短图文帖子（300-800字），推送飞书审稿。 触发词：小红书、写小红书、生成图文、XHS、红书内容、小红书选题、小红书帖子。 即使用户只是说"帮我写几篇小红书"或"从日报里选几个题"，只要上下文涉及小红书内容产出，都应该触发。 不要用于公众号长文（那个用 khazix-writer skill）。

- Skill: `guzhezao/xhs-content` (Agent Skill)
- Install (CLI): `npx skillmds@latest add guzhezao/xhs-content`
- Raw SKILL.md: https://api.skillmd.com/api/skills/guzhezao/xhs-content/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: guzhezao (https://skillmd.com/u/guzhezao)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/guzhezao/xhs-content

---


# 小红书短图文内容生成

## 账号定位

- **领域**：AI 科技泛类
- **受众**：开发者 + 愿意学习 AI / 关注 AI 的人群（公司潜在客户）
- **人设**：一个在 AI 行业深耕的内容创作者，用大白话聊 AI 新鲜事
- **内容形式**：短图文帖子（300-800 字 + 封面图 + 3-5 个标签）

---

## 风格基底：复用 writer skill

本 skill 的写作风格继承自 `writer`（khazix-writer）skill 的核心方法论，以下原则直接沿用，不再重复：

- **核心价值观**：永远保持好奇、讲人话像个活人、真诚是唯一的捷径
- **HKR 选题质检**：Happy + Knowledge + Resonance，至少占两项
- **事实核查**：所有可验证的事实必须有来源（详见 writer skill 第 2.5 步）
- **禁用词和禁用标点**：与 writer skill 完全一致（禁冒号/破折号/双引号，禁"说白了""本质上"等）
- **口语化表达**：沿用 writer skill 的推荐口语化词组
- **知识输出方式**：聊着聊着顺手掏出来，不是"下面我来科普"

**关键适配**：以上方法论在小红书上要进一步压缩密度、提高信息冲击力。公众号是 4000-8000 字的长跑，小红书是 300-800 字的短拳，每一句都要有存在的理由。

---

## 选题来源：从 AI 日报中提取

当与 `ai-daily-report` skill 配合使用时，从日报中提取 3 个最适合小红书的选题。

### 去重（铁律，必须在选题前执行）

选题前**必须先查询多维表格过去 7 天的已有记录**，获取已写过的标题和选题来源，作为去重黑名单。

**查询命令**：
```bash
lark-cli base +record-list --base-token OPgkbbFjNa0v3csZRsoc4sXOnVg --table-id tblvmMEa9LlCIFYK --as user --limit 30
```

**去重判定（三选一即算重复）**：
1. **选题来源 URL 相同**（最准——同一条推文/新闻/项目）
2. **核心信息点相同**（哪怕 URL 不同，但讲的是同一件事——例如"Manus 被收购"不管从哪个来源写都算重复）
3. **标题高度相似**（同一个事件用不同钩子重写）

**命中黑名单的素材直接跳过，不做为选题候选。没有例外。**

### 选题筛选标准

1. **新鲜度**：必须是 24 小时内的新信息，过时的不选
   - **核查铁律**：GitHub Trending 高星不等于新（11 万星项目大概率是老的，今日新增 +N 只说明今天又被翻红，不是首发）。任何 GitHub 项目入选前必须查 first commit / release 时间
   - 任何"X 早就出了"能打的题，直接砍
2. **可感知性**：普通人能直接感受到影响的话题 > 纯技术/纯学术
3. **数据支撑**：有具体数字、对比、排名的话题优先

### ⚠️ 用户场景过滤（硬门槛，必须通过）

每个候选选题在进入评分前，**必须先回答这一个问题**：

> **"用户读完这条会想干什么？"**

只有以下三种答案之一可以通过门槛：

| 答案 | 选题归类 | 例子 |
|---|---|---|
| **想立刻试 / 想推荐给朋友** | 分享型 | Claude 操控 PS/Blender、49 个 AI Agent 搭工作室 |
| **想存起来回头看** | 收藏型 | Karpathy 金句、10 年设计经验压成一个文件 |
| **想发评论说话（有情绪点）** | 评论型 | Manus 代码进 Meta 仓库（争议+八卦） |
| **答不出来 / 读完没下一步动作** | ❌ 直接砍 | OpenAI 做手机、Cerebras IPO、Google 75% 代码 AI 写 |

**这是在 13 条已发数据中验证出的核心规律**：综合分前 6 名都明确属于以上三类之一，倒数 5 名全部是"读完没下一步动作"的内容。

### 选题禁区（直接 ban）

通过 13 条数据观察到的扑街专业户：
- 估值 / IPO / 融资类（Cerebras IPO 综合分 182 但纯靠阅读量充数，0 评论 0 分享）
- 政策 / 诉讼类
- 纯产品发布（X 公司发了 Y，没说"你能拿它干嘛"）
- 没有可验证细节的"计划中"事件（如"OpenAI 据说要做手机"）
- 工程师小工具但非工程师无法脑补使用场景的（GitHub Trending 80% 是这类）

### 信源命中率参考（按 13 条数据反推）

| 信源 | 命中率 | 用法 |
|---|---|---|
| Karpathy / op7418（原创/资源型 KOL） | 高 | 优先 |
| 主流外媒报道"产品能做新事情" | 高 | 优先（Claude 操控 PS） |
| 主流外媒报道"产业新闻" | 低 | 大幅降权（融资/政策） |
| GitHub Trending 但能脑补"非工程师也想用" | 中 | 选择性用 |
| GitHub Trending 纯工程师小工具 | 低 | 砍 |
| dotey 类搬运型 KOL | 低-中 | 用前先去 KOL 原文找原创点，否则砍 |

### 选题优先级（按用户场景类型）

```
分享型（能脑补使用场景）> 评论型（有情绪点/争议）> 收藏型（金句/方法论/工具）
>>>>> 其他全部砍
```

### ⚠️ 数量与类型分布原则（铁律）

**质量 > 数量 > 类型分布**。

- **不强求每天 3 篇 / 4 篇固定数量**——日报里有几条够格就出几条
- **不强求三种类型各占一篇**——3 篇全是分享型完全 OK，3 篇全是评论型也 OK
- **宁可少出一篇，不为凑数硬选不达标的题**

**为什么**：之前为了凑"分享/收藏/评论"三种类型各一篇，硬选了第 1 篇（11 万星老项目，过不了"24 小时新鲜度"门槛）和第 3 篇（标题党，没有评论弹药）。质量被结构需求拖垮了。

**正确做法**：先把所有候选过"24 小时新鲜度 + 用户场景过滤"双门槛，剩下几条就出几条。如果只剩 1 条够格也就出 1 条，绝不为了"今天该有 3 篇"补水。

### 选题自主判断权

执行过程中如果发现某个选题过不了"用户场景过滤"门槛，可以自主替换，无需请示。替换时说明理由即可。**宁可少一篇也不要发"读完没下一步动作"的内容。**

---

## 写作规范

### 结构模板

一篇小红书帖子的标准结构：

```
【标题】一句话钩子，制造好奇心或信息冲击（不超过 20 字，英文两个字母算一个字）

【正文】
第一段：抛出核心信息或让人"？？？"的事实（1-2 句）

第二段：展开说明，带入个人视角或场景（2-4 句）

第三段：关键信息/数据/对比（这是帖子的"干货核心"）

第四段（可选）：延伸思考或行动建议（1-2 句）

收尾：一句话总结或留个钩子引导评论

【标签】#标签1 #标签2 #标签3 #标签4 #标签5
```

### 与公众号长文的关键区别

| 维度 | 公众号长文 | 小红书短图文 |
|------|-----------|-------------|
| 字数 | 4000-8000 | 300-800 |
| 开头 | 叙事铺垫，慢慢进入 | 第一句就要炸，没有铺垫空间 |
| 结构 | 无小标题，一口气读 | 短段落，视觉分块，手机阅读友好 |
| 深度 | 层层剥开，文化升维 | 聚焦一个点，讲透就收 |
| 语气 | 聊天感，偏私人叙事 | 更直给，偏分享/种草/信息差 |
| 收尾 | 哲思余韵/回环呼应 | 一句话钩子，引导互动 |
| 段落 | 一句一段制造呼吸感 | 2-4 句一段，但段间留空行 |

### 小红书专属写作技巧

**1. 标题必杀技**

好标题的公式（选一种，严格控制 20 字以内，英文两个字母算一个字）：
- **数字冲击**：`GPT-5 发布 24 小时，这 3 个变化你必须知道`
- **信息差**：`99% 的人不知道，Claude 其实可以这样用`
- **争议性**：`Karpathy 说大部分人用 AI 的方式都错了`
- **场景代入**：`用 AI 写了一周小红书之后，我发现...`
- **反常识**：`AI 最大的问题不是太强，而是太弱`

禁止的标题：
- "浅谈 xxx" / "关于 xxx 的几点思考" ← 公众号味
- "震惊！xxx" / "太牛了！xxx" ← 低质营销号味
- 纯陈述句，没有钩子

**2. 第一句话法则**

小红书用户划走一篇帖子只需要 0.5 秒。第一句话必须让人停下来。

好的第一句：
- 直接抛事实：`Karpathy 昨天发了条推，409 万人看了，说的是...`
- 制造悬念：`我测了 6 个 AI 模型做同一件事，只有 1 个活下来了`
- 反常识开场：`GitHub 上最火的 AI 项目，居然不用写一行代码`

**3. 段落节奏**

- 每段 2-4 句，绝不超过 5 句
- 段与段之间空一行（手机端视觉呼吸感）
- 关键数据或金句可以单独成段，加粗或用 emoji 标记
- 全文 emoji 使用克制（3-5 个足够），不要每句都带

**4. 收尾**

沿用 writer skill 的收尾哲学——不要用"你觉得呢？评论区聊聊"这种营销号式互动引导。好的收尾是自然地留一个悬念、一个未解的问题、或者回扣开头的意象，让读者自己想说点什么，而不是被你催着说。

好的收尾示例：
- 留悬念：`但真正让我好奇的是，这件事三个月后会变成什么样`
- 回扣开头：开头讲了一个场景，结尾用同一个场景的变体收束
- 抛出真实困惑：`说实话我也没想明白，这到底是好事还是坏事`

禁止的收尾：
- "你们觉得呢？" / "评论区聊聊" / "关注不迷路" ← 营销号味
- "以上就是今天的分享" ← 教科书味

**5. 来源链接（必须）**

每篇图文正文末尾必须附上选题来源的原始链接（推文链接、新闻链接、GitHub 链接等）。用户需要点进去查看原文和配图。没有链接的图文不合格。

**6. 标签策略**

每篇 3-5 个标签，组合逻辑：
- 1 个大流量词：`#AI` / `#人工智能` / `#ChatGPT`
- 1-2 个中等词：`#AI工具` / `#效率提升` / `#开源项目`
- 1-2 个精准词：`#Claude` / `#GPT5` / `#AI日报` / 具体产品名

---

## 事实核查（简化版）

沿用 writer skill 的核查原则，但流程压缩：

1. **提取待核查项**：帖子中所有数字、排名、人物引用、事件时间
2. **逐条核查**：每条用搜索工具确认，找原始来源
3. **标注来源**：帖子正文中用括号附来源（如 `（来源：@karpathy 推文）`）
4. **人物引用规则**：与 writer skill 一致——找不到原始来源的引用不得写入

核查报告不需要单独输出表格（公众号才需要），但在生成帖子时需要确保每条事实都有来源，来源以自然方式嵌入正文或标注在末尾。

---

## 质检体系（小红书适配版）

写完每篇帖子后快速过一遍：

### Q1 钩子检查
- 标题是否能在信息流中让人停下来？
- 第一句话是否有"然后呢"的冲动？

### Q2 信息密度检查
- 全文是否每句话都有存在的理由？（没有的删掉）
- 是否聚焦一个核心点？（散了就拆成两篇）
- 有没有"水字数"的段落？

### Q3 禁区检查
- 沿用 writer skill 的 L1 硬性规则（禁用词、禁用标点）
- 额外禁止：教科书语气、过度结构化（不要 "首先/其次/最后"）
- 额外禁止：营销号语气（"震惊""太牛了""必看"）

### Q4 平台适配检查
- 段落是否手机端友好？（太长的段拆开）
- emoji 是否克制？（3-5 个，不是每句都带）
- 标签是否合理？（3-5 个，覆盖大中小流量词）
- 有没有引导互动的收尾？

### Q5 来源检查
- 所有事实是否都有可追溯来源？
- 人物引用是否有原始出处？

---

## 配图方案

每篇帖子需要配图，直接截取真实来源（不要自制卡片，用户更看重真实感和效率）。

**CDP 不可用时的降级策略**：如果 Chrome CDP 端口（9222）连接失败或超时，**跳过配图步骤**，在飞书文档中每篇选题正文前标注「⚠️ 配图待补（CDP 不可用）」。绝不能因为配图失败阻塞文字内容产出和飞书文档创建。

### 配图类型

- **KOL 推文截图**：用 CDP 浏览器打开推文，使用 Twitter 内置翻译功能翻译成中文后截图
- **GitHub 项目页截图**：截项目首页 + star-history.com 走势图
- **新闻页面截图**：优先截中文翻译版（注意部分网站如 TechCrunch 屏蔽 Google Translate 代理，只能截英文原版）

### 配图截取流程

1. 用 CDP 浏览器访问目标页面
2. 如需翻译，使用页面内置翻译或 Google Translate 代理
3. 截图保存到本地临时目录

### 配图插入飞书文档

> **⚠️ 这是反复出错的环节，必须严格按以下步骤执行，不得简化或跳步。**

配图必须放在对应选题正文**前面**，**严禁堆在文档末尾**。

**完整操作步骤（逐步执行，每步验证）：**

**步骤 A**：先用 `docs +create` 或 `docs +update --mode overwrite/append` 写入全部文字内容
**步骤 B**：用 `docs +media-insert` 逐张上传截图到文档，记录每张图的 image token
**步骤 C**：对每篇选题，用 `docs +update --mode insert_before` 将对应配图插入到该选题正文第一句话前面

步骤 C 的命令格式：
```bash
lark-cli docs +update --doc "<doc_token>" \
  --mode insert_before \
  --selection-with-ellipsis "该选题正文的第一句话前几个字" \
  --markdown '<image token="<image_token>" width="3154" height="1488" align="center"/>'
```

**常见错误（已发生 3 次以上，必须避免）：**
- 把所有图片用 media-insert 追加到文档末尾就完事 ← **这是错的**
- 只执行步骤 A 和 B，跳过步骤 C ← **这也是错的**
- 步骤 C 中 selection-with-ellipsis 找不到匹配文本导致跳过 ← 检查拼写，用正文前 10 个字

**验证方法**：步骤 C 全部执行完后，用 `docs +get` 重新拉取文档内容，检查每张配图是否出现在对应选题正文前面。如果不对，立即修正。

**关键发现**：飞书文档中已存在的 image token 可以直接在 `docs +update` 的 markdown 中复用，用 insert_before/insert_after 模式可以将图片插入到文档任意位置。`media-insert` 只能追加到末尾，但 `docs +update` 没有这个限制。

---

## 输出格式

每篇帖子的最终输出格式：

```
---
选题来源：[日报中的具体素材]
核心角度：[一句话说明这篇帖子在讲什么]
选题类型：[分享型/收藏型/评论型]（必须三选一，否则砍）
用户场景过滤：[读完用户会想干什么？必须答出"立刻试/想推荐/想存起来/想发评论"四选一]
事实来源：[列出主要来源链接]
预测评分：点击力 X/5 | 收藏力 X/5 | 争议分享力 X/5
---

【标题】xxx

【正文】
xxx

【标签】#xxx #xxx #xxx #xxx #xxx

【配图说明】
1. 封面：xxx
2. 内页（如有）：xxx
```

---

## 预测评分（每篇必填）

生成每篇帖子时，必须对以下 3 个维度打分（1-5 分），作为后续数据反馈的对照基线：

- **点击力**：标题+封面能不能在信息流里赢冷启动？(1=普通陈述 5=必停)
  - 加分项：数字反差 / 熟悉品牌的意外动作 / 情绪冲突
- **收藏力**：内容是否值得用户存起来回头看？(1=看完就忘 5=必收藏)
  - 加分项：可复用工具/方法/资源/金句
- **争议分享力**：能不能激发"想说话"或"想推荐给朋友"？(1=看完没反应 5=必转/必评论)
  - 加分项：争议点 / 八卦情绪点 / "我也想试"的产品案例

> **三维改造来源（2026-05-06，基于 13 条已发数据复盘）**
>
> 老 4 项（钩子力/信息密度/传播性/互动潜力）有两个问题：
> 1. "信息密度"和"传播性"高度重合，但和实际表现弱相关
> 2. 没有"用户场景"维度，导致老评分把多源新闻当 Top 1 但实际数据全扑街
>
> 13 条数据的真实分布表明，三类内容各走各的路：
> - 分享型靠分享拉分（Claude 操控 PS/Blender 综合 #1）
> - 评论型靠评论拉分（Manus 进 Meta 综合 #2）
> - 收藏型靠赞藏拉分（Karpathy 综合 #3）
>
> 综合分公式：阅读×1 + 赞藏×10 + 评论×100 + 分享×50

评分要诚实，不要全打高分。如果一篇帖子点击力 5 但收藏力 2，就老实写。打分的目的是校准预测能力，全打 4-5 分等于没打。

---

## 数据追踪（多维表格）

每篇文章生成后，自动写入飞书多维表格进行追踪：

- **表格 token**：`OPgkbbFjNa0v3csZRsoc4sXOnVg`
- **表 ID**：`tblvmMEa9LlCIFYK`
- **写入时机**：图文生成完成后，立即写入预测数据
- **帖子链接留空**：由用户发布后手动填入小红书链接（飞书会自动识别标题）

### 表格字段结构

| 字段 | 类型 | 谁填 | 说明 |
|------|------|------|------|
| 帖子链接 | URL（主字段） | 用户 | 小红书帖子链接，飞书自动识别标题 |
| 发布日期 | 日期 | 管线 | 生成日期，毫秒时间戳 |
| 标题 | 文本 | 管线 | 文章标题 |
| 选题类型 | 单选 | 管线 | 分享型/收藏型/评论型（新口径） |
| 选题来源 | 文本 | 管线 | 来源（如 @karpathy 推文、GitHub Trending） |
| 预测-点击力 | 评分1-5 | 管线 | 标题+封面冷启动能力 |
| 预测-收藏力 | 评分1-5 | 管线 | 内容是否值得存 |
| 预测-争议分享力 | 评分1-5 | 管线 | 是否激发讨论或推荐 |
| 阅读量 | 数字 | 用户 | 阅读总量（小红书里=封面+标题点击率） |
| 赞藏 | 数字 | 用户 | 点赞+收藏合计 |
| 评论 | 数字 | 用户 | 评论数 |
| 分享 | 数字 | 用户 | 分享/转发数 |
| 经验总结 | 文本 | Mavis | 偏差分析和经验沉淀 |

> **过渡说明（2026-05-06）**：表格里历史的"预测-钩子力 / 预测-信息密度 / 预测-传播性 / 预测-互动潜力"四列保留不动，作为历史对照。新写入的记录在新三维评分上，老 4 列留空即可。后续考虑用 base 字段重命名做迁移。

### 写入命令示例

```bash
lark-cli base +record-upsert --as user --base-token OPgkbbFjNa0v3csZRsoc4sXOnVg --table-id tblvmMEa9LlCIFYK --json '{
  "发布日期": <毫秒时间戳>,
  "标题": "文章标题",
  "选题类型": "分享型",
  "选题来源": "@op7418 推文",
  "预测-点击力": 4,
  "预测-收藏力": 5,
  "预测-争议分享力": 4
}'
```

注意：
- 帖子链接、阅读量、赞藏、评论、分享 不写入，由用户在小红书发布后手动贴入表格。
- **必须 `--as user`**（bot 没有写入用户多维表格的权限）。

---

## 反馈与迭代

用户发布帖子后，在多维表格的「帖子链接」列贴上小红书链接，并填入「赞藏」和「评论」数据。Mavis 收到数据后执行：

1. **偏差分析**：对比预测评分和实际赞藏/评论数据，找出预测偏差
2. **经验沉淀**：将分析结论写入「经验总结」字段 + agent 记忆层
3. **规律提炼**：积累 10-20 篇后，提炼选题类型 × 表现的规律，更新 skill 中的选题优先级

注意：不要用 CDP 抓取小红书页面数据，有封号风险。数据由用户手动提供。

---

## 推送飞书

生成完成后，每天新建一份飞书文档推送审稿：
- **文档标题**：`小红书短图文 | {YYYY}年{M}月{D}日 AI日报精选`
- **创建方式**：使用 `docs +create` 新建文档（不覆盖旧文档，保留历史）
- **文档结构**：每篇帖子独立一个板块，配图在正文前，来源链接在正文后
- 创建完成后返回文档链接给用户

---

## 注意事项

1. **字数控制**：宁可写短写精，不要为凑字数注水。300 字的帖子如果信息密度高，比 800 字的水文强
2. **一篇一个点**：每篇帖子只讲一个核心信息点，讲透就收。想讲两个点就拆成两篇
3. **不要公众号化**：最大的风险是把小红书帖子写成了缩短版公众号文章。小红书更直给、更碎片、更视觉化
4. **评论区思维**：写的时候想一下"这篇帖子的评论区会聊什么"，如果想不出来，说明帖子缺少讨论点
5. **复用不照搬**：writer skill 的风格方法论是底座，但表达密度和结构必须为小红书重新适配