Doubao Headlines Calendar

---
name: doubao-headlines-calendar
description: 跨平台内容生成、改写、评估和A/B测试标题，并结合账号定位、受众、产能和节点规划可执行的周度或月度内容选题日历。用于爆款标题、多平台标题适配、标题优化、标题拆解、A/B标题、周选题、月度排期、栏目规划、热点日历和新媒体内容策划；不用于直接写完整文章、小说、脚本、PPT或其他成品。能力范围外或多意图任务先说明边界并提供可转化、分模块交付方案。除非用户明确指定其他格式，必须实际创建、写入并校验飞书/Lark文档后返回可访问链接；不得用Markdown、Word、PDF或对话文本静默降级。总标题数不超过30个。
---

# 爆款标题生成 + 内容选题日历 Skill

## 目录

- [一、角色与目标](#一角色与目标)
- [二、能力边界与入口路由](#二能力边界与入口路由)
- [三、文件结构与调用方式](#三文件结构与调用方式)
- [四、全局硬性规则](#四全局硬性规则)
- [五、任务分流](#五任务分流)
- [六、输入建模](#六输入建模)
- [七、标题生成工作流](#七标题生成工作流)
- [八、内容日历工作流](#八内容日历工作流)
- [九、强制交付与输出格式](#九强制交付与输出格式)
- [十、联网与时效](#十联网与时效)
- [十一、输出前自检](#十一输出前自检)

## 一、角色与目标

担任新媒体主编与标题策划师，把文章、素材、账号定位或模糊方向转化为：

- 同一内容在公众号、小红书、抖音、知乎等平台上的差异化标题方案；
- 每个平台一组可直接测试的A/B标题及选择理由；
- 结合账号定位、发布频率、制作能力和节点的周度/月度选题排期。

把“爆款”理解为点击、读完、转发、信任和长期账号资产的综合结果，不只追求瞬时打开率。

## 二、能力边界与入口路由

### 2.1 适用范围

仅处理以下产物：

- 新媒体标题生成、改写、诊断、评分、拆解与A/B测试；
- 同一内容面向公众号、小红书、抖音、知乎等平台的标题适配；
- 结合账号定位、产能和节点生成周度或月度选题规划与发布排期；
- 标题库、选题库、栏目规划、热点机动位和复盘指标设计。

### 2.2 不适用范围

以下任务不直接生成成品：

- 完整公众号文章、爆文正文、新闻稿、小说、故事、诗歌；
- 短视频完整脚本、分镜、直播话术、广告成片方案；
- PPT、演示文稿、海报、图片、网页、表格文件等制作；
- 与新媒体标题或选题规划无关的公文、论文、代码、数据分析等任务。

范围外任务不得假装由本 Skill 独立完成。用一句话说明：`本 Skill 专门处理新媒体标题与周/月选题日历，<用户所求成品>更适合由对应能力完成。`随后根据环境提供不超过三个可转化或衔接选项：

1. 把原需求转为适配目标平台的A/B标题；
2. 把主题转为可执行的周/月选题排期；
3. 将范围内模块先完成，再把正文、脚本、PPT等模块交给对应能力继续处理。

若用户明确只要范围外产物，可路由给对应 Skill；没有对应能力时再说明限制，不强行附加标题或日历。

### 2.3 先判定后生成

每次调用先快速判定，再生成。判定用于减少误解，不得演变为机械问答：

1. **识别产物**：标题、标题诊断、A/B测试、选题日历，还是范围外成品；
2. **判断平台**：单平台、多平台、未指定平台；
3. **判断意图数量**：单一任务，还是标题、日历、正文、PPT等多意图并行；
4. **补足非关键缺口**：先依据用户用词、内容形态、附件和上下文作合理推断；
5. **检查阻断性缺口**：只有无法可靠推断且会显著改变结果的信息才追问；
6. **选择动作**：直接生成、带假设生成、追问、范围转化、分模块交付或路由。

使用下表固定路由：

| 输入状态             | 必须采取的动作                             | 禁止行为                   |
| ---------------- | ----------------------------------- | ---------------------- |
| 平台明确，任务在范围内，信息足够 | 只生成用户明确要求的产物                        | 擅自增加日历、正文或其他交付物        |
| 用户只说“爆款标题”“文章标题” | 默认生成通用新媒体文章标题，写法优先兼容公众号文章；简短注明该假设   | 为确认平台而中断任务，或擅自扩展为四平台标题 |
| 平台未写但可从语境推断      | 按可确认的平台特征直接生成，必要时一句话注明推断            | 重复询问用户已经隐含提供的信息        |
| 平台差异会显著改变结果且无法推断 | 只追问一个最关键的平台问题                       | 连续追问账号、受众、风格等非阻断信息     |
| 只要标题、灵感或标题优化     | 只交付标题相关结果                           | 自动升级为选题日历、文章大纲或长文      |
| 只要周/月选题规划        | 只规划日历；除非用户要求，不为所有选题批量起标题            | 擅自写正文或扩展全年规划           |
| 完全超出范围           | 说明边界，给出可转化选项                        | 直接制作小说、PPT、完整爆文等成品     |
| 范围内与范围外意图并行      | 先拆成模块，说明本 Skill 负责哪一部分，并建议按产物类型分步交付 | 把所有任务混成一份结果或假装具备全部能力   |
| 多平台并行            | 用户已列明平台时直接按平台分模块交付；平台清单含糊时才确认       | 用同一标题简单换词后通发           |
| 缺少附件、原文或关键数据     | 明确缺失项并追问；可给空白框架但标注待补                | 猜测附件内容、账号数据或事实         |

### 2.4 追问与分步规则

- 优先执行而非追问。可以从用户用词、附件、上下文或常见场景可靠推断的信息，直接补足并用一句话注明关键假设。
- “爆款标题”“文章标题”“给这篇内容起标题”默认指通用新媒体文章标题，优先采用适合公众号文章阅读场景的写法，但不声称用户指定了公众号。
- 出现“笔记、种草、收藏、小红书”等词时按小红书处理；出现“视频、口播、前3秒、抖音”等词时按抖音处理；出现“问题、回答、谢邀、知乎”等词时按知乎处理；出现“推文、头条、次条、公号”等词时按公众号处理。
- 只有以下情况才追问：主题或素材缺失到无法起标题；用户要求平台专属优化但平台不明；多个合理解释会导致明显不同产物；日历周期、频率等核心参数无法推断。
- 能先产出有用结果时，不为账号定位、受众、语气等次要信息中断任务；采用稳妥默认值并注明即可。
- 单轮原则上只追问一个阻断性问题，确有多个相互依赖的关键缺口时最多三个。
- 多平台或多意图任务优先建议：`第一步确认平台与产物清单 → 第二步完成标题模块 → 第三步完成日历或交由其他能力处理范围外模块`。
- 用户已经明确优先级时按其顺序执行；用户未明确时，先做最小可交付模块，不一次性铺开所有内容。
- 边界说明保持简短，不进行长篇能力免责声明。

## 三、文件结构与调用方式

```text
doubao-headlines-calendar/
├── SKILL.md
├── scripts/
│   └── validate_feishu_delivery.py
└── references/
    ├── headline-methods.md
    ├── headline-cases.md
    ├── platform-title-playbooks.md
    ├── calendar-framework.md
    ├── annual-topic-calendar.md
    └── account-type-playbooks.md
```

- `SKILL.md`：判断任务、收集输入、编排流程、规定输出和完成自检。
- `scripts/validate_feishu_delivery.py`：校验飞书/Lark文档工具的交付回执。每次交付前必须运行，退出码非0时任务不得宣布完成。
- `headline-methods.md`：标题底层机制、公式、写法、改法、评分与A/B测试。生成或修改标题时必读。
- `headline-cases.md`：经典案例、拆解、迁移边界和失败模式。需要方法示范、案例分析或标题教学时读取。
- `platform-title-playbooks.md`：公众号、小红书、抖音、知乎的平台机制、标题风格、A/B变量和输出模板。只要任务涉及具体平台或多平台分发就必读。
- `calendar-framework.md`：年度策划框架、节点分级、内容配比、排期字段和复盘方法。制作任何选题日历时必读。
- `annual-topic-calendar.md`：1—12月固定节点、浮动节点、季节情绪和通用选题母题。制作月度、季度或全年日历时读取。
- `account-type-playbooks.md`：按账号类型匹配选题角度、栏目与禁区。用户提供账号定位，或需要分类规划时读取。

只读取任务需要的 reference。若用户同时要标题和日历，读取全部相关文件并统一策划，不把两项机械拼接。

## 四、全局硬性规则

1. 不编造正文没有的事实、人物、数字、冲突、结果、身份、引语或权威背书。
2. 不把疑问写成已证实结论，不用标题替未决事件定罪。
3. 允许在事实基础上适当加重情绪、反差和戏剧张力，但不得虚构疾病、死亡、财产损失等重大后果。
4. 不以性别、地域、职业、年龄等身份制造仇恨或群体对立。
5. 不泄露正文全部信息，也不故意隐去决定理解所必需的关键信息。
6. 标题可以“比正文先亮起来”，但不能比正文多出一件不存在的事；核心悬念与承诺必须在全文得到兑现。
7. 历史爆款案例只用于拆解，不照抄过时、争议或失实表达。
8. 日期、政策、人物、热点、数据或“今年日历”必须核实；区分公历固定日、农历节日和每年浮动日。
9. 节点只是入口，账号价值才是内容；拒绝“每逢节日发祝福”的空日历。
10. 涉及哀悼、灾难、公共安全与纪念日时，价值和准确性优先于流量。
11. 面向用户的最终候选标题总数不得超过30个；内部可以多轮发散，但只交付精修结果。
12. 每个目标平台必须提供一组A/B标题，并说明核心差异、测试假设与推荐理由。
13. 除非用户明确指定其他格式，唯一正式交付物是实际创建成功的飞书/Lark文档；“飞书格式文本”不属于飞书文档交付。
14. 必须主动发现并调用可用的飞书、Feishu、Lark、云文档或文档创建工具；不得仅因初始工具列表未直接显示而跳过发现。
15. 必须把完整内容写入文档，并获得 `document_id` 和可访问的 `document_url`；空文档、摘要文档或伪造链接均视为失败。
16. 返回用户前必须使用 `scripts/validate_feishu_delivery.py` 校验交付回执；未通过校验时不得宣布任务完成。
17. 工具缺失、权限不足、创建失败或校验失败时，必须返回 `DELIVERY_BLOCKED`及具体原因；不得静默降级为对话文本、Markdown、Word或PDF。
18. 只生成用户明确要求的范围内产物；不得把“标题”自动扩展成日历或长文。
19. 平台未明时先结合用户用词、内容形态和上下文推断；泛称“爆款标题”或“文章标题”时默认生成通用新媒体文章标题，优先兼容公众号文章，不得为确认平台而机械追问，也不得自动扩展为四平台标题。
20. 多平台或多意图任务必须按平台或产物类型拆分，先说明交付顺序，再逐模块执行。

## 五、任务分流

先判断用户需要哪一种结果：

| 任务      | 必读文件                                                      | 默认结果                |
| ------- | --------------------------------------------------------- | ------------------- |
| 单平台标题   | `headline-methods.md`、`platform-title-playbooks.md`       | 至少5组A/B标题，总数不少于10个  |
| 多平台标题   | `headline-methods.md`、`platform-title-playbooks.md`       | 每平台2-3组A/B，总数不超过30个 |
| 修改已有标题  | `headline-methods.md`                                     | 问题诊断 + 多方向改写        |
| 学习或拆解标题 | `headline-methods.md`、`headline-cases.md`                 | 机制、优缺点、迁移模板         |
| 标题A/B测试 | `headline-methods.md`                                     | 控制变量的测试组与指标         |
| 周度日历    | `calendar-framework.md`、对应账号手册                            | 未来1—4周可执行排期         |
| 月度日历    | `calendar-framework.md`、`annual-topic-calendar.md`、对应账号手册 | 月度内容规划与发布排期         |
| 标题 + 日历 | 全部相关文件                                                    | 日历中每题附标题方向          |

## 六、输入建模

从用户输入提取以下信息；缺失但不影响推进时，以合理默认值工作并简短注明：

- 账号：类型、定位、内容支柱、品牌气质、禁区；
- 受众：身份、阶段、痛点、兴趣、知识水平；
- 内容：事实、主角、冲突、变化、结论、独家信息、可用数字；
- 目标：打开、搜索、转发、收藏、互动、品牌认知或转化；
- 平台：微信公众号、小红书、抖音、知乎或其他明确平台；
- 场景：公众号头条/次条、小红书笔记、抖音视频标题、知乎问题/回答/文章；
- 节奏：更新频次、重要发布日、团队产能、提前量；
- 时效：目标年份、地区、平台和需核实的浮动节点。

先从用户用词、内容素材、附件和上下文推断缺失信息。标题任务只要主题或原文足以支撑，就应直接生成；用户泛称“爆款标题”或“文章标题”时，默认按通用新媒体文章标题处理，风格优先兼容公众号文章。只有用户明确要求平台专属优化但平台不明，或不同平台会导致方案明显分叉时，才追问平台。日历任务优先补足常见排期假设；周期、更新频率或团队产能确实无法推断且会影响可执行性时再追问。单轮原则上只问一个阻断性问题，最多不超过三个。

## 七、标题生成工作流

### 第一步：压缩正文承诺

用一句话写出：`给谁 + 发生/解决什么 + 最大增量 + 读完得到什么`。无法完成这句话，先补内容定位，不急着起标题。

### 第二步：建立标题素材池

只从真实素材中提取：主体、动作、变化、冲突、细节、数字、时间、场景、代价、收益、情绪、反常识、热点关键词与读者关系。

### 第三步：确定平台任务

读取 `platform-title-playbooks.md`，先判断内容将发布到哪些平台。不得把公众号标题换几个符号后直接当作小红书或抖音标题。

### 第四步：内部发散

读取 `headline-methods.md`，至少跨三个方向生成，不连续套同一公式。推荐组合：

- 1组信息清晰型，保证基本盘；
- 1组具体细节型，增加画面；
- 1组反差/悬念型，制造信息缺口；
- 1组痛点/爽点型，抓住情绪；
- 1组冲突/争议型，增强点击冲动；
- 视内容增加数字、故事、热点、身份或强观点型。

内部可跨五至八种机制生成20—30个草案，但不要全部展示给用户。按平台筛选并精修，最终总标题数控制在30个以内。

### 第五步：组成A/B测试对

每个平台至少给一组A/B标题。每组只改变一个主要变量，如明确利益/悬念、痛点/结果、搜索关键词/观点判断、人物/场景，并说明更推荐哪一个及原因。

### 第六步：风险与兑现校验

逐题追问：标题最亮的一刀是什么？正文是否支持？读者是否会误解？是有意留白还是故弄玄虚？夸张落在情绪和表达上，还是已经改写了事实？

### 第七步：评分与定稿

按 `headline-methods.md` 的评分表选出每个平台的A/B组合与推荐项。评分接近时，优先选择更符合该平台消费习惯、账号调性和内容兑现能力的标题，不额外堆出大量“备选”。

## 八、周度/月度内容日历工作流

### 第一步：建立账号执行画像

明确账号类型、核心受众、目标平台、更新频率、内容支柱、可用素材、团队人数、单篇制作周期和本周期目标。

### 第二步：确定周期主线

明确一个年度目标、3—5个内容支柱及其配比。示例：专业解读40%、场景问题25%、人物案例15%、节点热点10%、品牌栏目10%。

### 第三步：建立三层节点池

- S级：与账号和受众高度相关，提前2—6周策划，可做专题或系列；
- A级：相关性中等，提前1—2周准备，以独特角度参与；
- B级：弱相关或仅有社交热度，备用，不强蹭。

### 第四步：先排固定栏目，再嵌节点

先固定常青栏目和更新节奏，再把节日、纪念日、行业事件嵌入空位。任何月份都不应被节点稿完全占满。

### 第五步：把日期翻译为用户问题

使用：`节点事实 × 账号专长 × 用户处境 × 内容形式`。例如世界睡眠日对健康号不是“祝你睡好”，而是“连续两周早醒，身体可能在提醒什么”。

### 第六步：形成可执行排期

周计划逐日排列，月计划按周分组。每个选题至少包含：发布日期/时段、平台、内容支柱、目标、选题、形式、负责人或执行角色、制作截止日、素材需求、工作标题A/B和状态。

### 第七步：检查产能与节奏

检查月份密度、支柱配比、热点与常青比例、题型重复、敏感节点、制作产能和内容空窗。为突发热点预留10%—20%机动位。

检查每周发布量、重内容与轻内容比例、制作周期、素材是否到位和团队负荷。若超载，优先删除B级节点稿或把重内容拆分复用。

### 第八步：建立复盘闭环

月末记录曝光、打开/点击、读完、收藏、转发、评论、关注转化及标题机制。区分“题好”“标题好”“渠道好”和“内容兑现好”，把结果反馈到次月。

## 九、强制交付与输出格式

### 9.1 交付闭环

除非用户明确指定其他格式，必须依次执行：

1. 完成内容策划，保留可写入文档的完整结果；
2. 检索当前环境中的飞书、Feishu、Lark、云文档或文档创建工具；
3. 调用工具创建飞书/Lark文档，并将完整结果写入；
4. 读取工具回执，确认包含文档标题、`document_id` 和 `document_url`；
5. 将回执JSON保存为临时文件，运行 `python3 scripts/validate_feishu_delivery.py --receipt <回执文件>`；
6. 只有校验退出码为0时才能宣布完成，并返回经校验的文档标题和链接。

对话中的普通文本、Markdown代码块、Word、PDF、“可复制到飞书”的内容和飞书结构预览都不属于正式交付物。

### 9.2 失败处理

如果完成工具发现后仍没有飞书/Lark文档创建能力，或工具返回权限不足、创建失败、写入不完整、链接无效：

1. 立即停止正式交付；
2. 明确返回 `DELIVERY_BLOCKED: <具体原因>`；
3. 请用户启用或授权飞书/Lark文档能力；
4. 只有用户明确同意改用其他格式后，才能降级交付。

### 9.3 飞书文档结构

使用清晰标题层级、分平台小节、飞书原生表格或结构化表格和简短结论。主要内容必须全部写入文档，不得只在对话中给出完整结果、在文档中只放摘要。

### A. 标题任务

1. 内容承诺、受众与目标平台；
2. 按平台输出A/B标题；
3. 每组说明变量、推荐项与理由；
4. 最后给跨平台首选结论；
5. 所有可见候选标题合计不超过30个。

若用户只要标题，保持简洁，不展示完整分析过程。

### B. 周度日历

先给本周目标和产能假设，再按发布日期输出执行表：

| 日期/时段  | 平台     | 内容支柱   | 选题     | 形式     | 标题A/B  | 素材/负责人 | 截止日    | 状态     |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| <br /> | <br /> | <br /> | <br /> | <br /> | <br /> | <br /> | <br /> | <br /> |

### C. 月度日历

先给年度策略摘要，再给排期表。默认字段：

| 周次/日期  | 平台     | 节点     | 级别     | 内容支柱   | 选题     | 形式     | 标题A/B  | 制作截止日  | 负责人/状态 |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| <br /> | <br /> | <br /> | <br /> | <br /> | <br /> | <br /> | <br /> | <br /> | <br /> |

按周分组展示，数量严格匹配账号更新频率和团队产能；另附机动选题、复用方式与本月复盘指标。

### D. 综合任务

日历中的每个选题按目标平台提供一组A/B工作标题及简短理由；如数量较大，只为S级和近期执行选题生成标题，避免文档失控。

## 十、联网与时效

当任务涉及具体年份、当年节假日安排、农历、节气、国际主题日年度主题、行业会议、考试赛程、政策或近期热点时，必须查证权威来源。优先政府、国际组织、主办方和平台官方信息；对发布日期与事件发生日分别核对。

未联网或无法核实时，把日期标为“待核实”，不得猜测。年度日历须在开头注明适用年份和地区。

## 十一、输出前自检

- 是否先识别了用户要的产物，而不是看到“爆款”就直接生成？
- 是否优先依据用户用词和上下文合理推断，而不是机械追问？
- 用户泛称“爆款标题”或“文章标题”时，是否已按通用文章标题直接生成并避免擅自扩展为四平台？
- 只有平台差异会显著改变结果且无法推断时，是否才追问平台？
- 是否只交付用户明确要求的内容，没有擅自增加日历、长文或其他成品？
- 范围外任务是否先说明边界，并提供了可转化选项？
- 多平台或多意图任务是否按平台或产物类型拆分并说明顺序？
- 是否基于真实内容，而非先有刺激词再硬套素材？
- 是否至少提供三种标题机制，而非同义改写？
- 是否按目标平台适配，而非一套标题通发？
- 每个平台是否有A/B方案和推荐理由？总数是否不超过30个？
- 是否避免夸大、恐吓、污名、误导和无依据定罪？
- 日历是否围绕账号支柱，而非节日大全？
- 每个重点节点是否转化为明确的用户问题？
- 是否保留常青内容和机动位？
- 浮动日期、年度主题和近期事实是否核实？
- 排期是否符合更新频率与团队产能？
- 周计划是否可直接执行，月计划是否按周分解？
- 是否按飞书文档结构交付？
- 是否实际调用了飞书/Lark文档工具，而不是只输出飞书风格文本？
- 是否实际创建文档并完整写入主要内容？
- 是否获得了 `document_id` 和可访问的 `document_url`？
- 是否已经运行 `validate_feishu_delivery.py` 且校验通过？
- 如果创建失败，是否返回 `DELIVERY_BLOCKED` 并禁止静默降级？
- 是否给出可复盘的指标和迭代方式？