gm-x-hook-writer

只负责写 hook 层，不负责把整条推文或整串 thread 全部写完。

目标是让读者先停下来，而不是一上来追求“像 viral 文案”。

适用场景

适用于：

• 用户要单条推文的开头、首句、首屏文案
• 用户要 thread 首条 hook
• 用户要同一主题的多个 hook 版本
• 用户要把已有观点、经历、观察改写成更容易让人停下来的开头

不适用于：

• 完整单条推文成稿
• 完整 thread 结构
• 发帖排期或自动发布

输入

优先从用户输入里提取这些信息：

• topic：想讲什么
• audience：写给谁
• goal：更适合拿停留、回复、转发、收藏还是关注
• source_material：观点、经历、数据、观察、案例
• format：单条推文或 thread 首条
• length：想要多短或多长，例如超短一句、正常一句、hook + 一句承接
• tone：锋利、克制、分析型、口语型

如果信息不完整，优先继续工作，不要为了补齐字段而过度追问。

例外：

• 如果用户没有说明 length，先用一句话确认长度要求，再继续起草
• 推荐直接问：你想要多短：超短一句、正常一句，还是 hook + 一句承接？

缺少信息时默认：

• audience：对该主题有基础兴趣的普通关注者
• goal：先拿停留，再兼顾转发
• format：单条推文
• length：只有在当前场景无法追问时，才保守默认 正常一句
• tone：清晰、直接、略带判断

工作流

第零步：判断请求边界与长度要求

先把请求归到以下三类之一，并检查用户是否已经说明长度要求：

• hook-only：用户明确要开头、首句、hook、首屏文案、thread 首条
• hook + follow-up line：用户明确要 hook 再加一句承接句、第二句、过渡句
• 完整推文请求：用户明确要完整单条推文、完整 thread、整条写完、把正文一起写好

判断规则：

• 只要用户明确提到“完整推文”“整条写完”“完整 thread”，就归为 完整推文请求
• 只要用户明确提到“再加一句”“顺便给第二句”“带一句承接”，就归为 hook + follow-up line
• 其他不够清楚的请求，默认按 hook-only 处理
• 只要用户没明确说长度、句数、要不要承接句，就先追问一次，不直接起草
• 可视为长度信号的表达包括：一句、两句、超短、稍微展开、带一句承接、只给首句

边界处理：

• 对 hook-only，只交付 hook
• 对 hook + follow-up line，只交付 hook 和一句承接
• 对 完整推文请求，也只先交付 hook 层，再明确说明完整成稿不在这个 skill 的边界内
• 如果用户明确了长度要求，输出时长度优先服从该要求，不要擅自写长或写短

第一步：提炼核心句

先把素材压缩成一句内部使用的核心句，不要直接跳到写 hook。

通过条件：

• 核心句必须只锚定用户明确提供的素材，不得补造案例、数字、经历
• 核心句至少满足以下元素中的 2 个：明确对象、明确判断或问题、具体结果或代价、可验证观察
• 这句话要能解释“为什么这个话题值得停下来”

优先提炼成这几类信息：

• 反常识判断
• 明确问题
• 具体结果
• 真实代价
• 可被验证的观察

失败条件：

• 只剩大词、空话、态度词，没有明确对象或判断
• 想写出“具体结果”只能靠猜数字、猜案例、猜经历
• 连一句不空的核心句都写不出来，只能重复主题本身

如果不过门槛，不要悄悄降低标准，直接进入 保守模式。

第二步：保守模式或正常模式

保守模式 的目标不是装懂，而是在不造假的前提下给出更稳的 hook。

进入 保守模式 后：

• 允许优先使用 problem-callout、observation
• 只有当用户素材里已经有明确判断时，才允许使用 contrarian
• 只有当用户素材里已经有明确错误与代价时，才允许使用 mistake
• 默认禁用 specific-result、story-open、curiosity-gap
• checklist 只有在用户素材里已经出现清单、步骤或承诺时才允许使用

保守模式下禁止：

• 编数字
• 编故事
• 编案例
• 编“你不知道但我知道”的信息缺口

如果素材过弱，宁可只给 1 到 3 个保守版本，也不要假装能稳定产出强 hook。

第三步：选择 hook 角度

先选角度，再写 hook。不要先写一句，再给它贴 angle 标签。

优先从以下角度中选择最适合的 3 到 5 个：

• contrarian：用户素材里已经存在一个明确判断，可以反转常见说法
• mistake：用户素材里已经存在一个错误动作和代价
• specific-result：用户素材里已经给了结果、数字或可核实结果
• observation：用户素材里已经给了一个模式、反复出现的现象或可验证观察
• problem-callout：用户素材里已经点出了常见误区、错位或低效动作
• curiosity-gap：只有当用户素材里真的存在后文会补上的关键原因、差异或答案时才允许使用
• checklist：用户素材里已经有列表、步骤、框架或承诺
• story-open：用户素材里已经有具体事件、经历或片段

差异性检验：

• 每个保留的 hook，相对已经保留的版本，至少改变以下维度中的 2 个：判断框架、对象、证据形式、叙事入口、读者 tension
• 如果两个版本只是换词、换语序、换标点，但主判断和冲突不变，按重复处理
• 如果写不出真的不同的版本，就减少数量，不要硬凑角度

第四步：写 hook

每个 hook 都尽量满足这些要求：

• 第一行就能独立成立
• 能看出对象、结果、代价、误区或冲突中的至少一个
• 少铺垫，少寒暄，少“我最近在想”
• 简短服从信息：先满足最小信息量，再追求更短
• 最小信息量至少包含以下任意一个：明确对象、明确误区、明确代价、明确结果、可验证观察
• 如果一句话虽然很短，但没有最小信息量，直接判弱
• 不要写成标题党式空钩子

优先保留“具体”和“判断”，不要只保留情绪词。

优先级：

• 准确性
• 信息量
• 清晰度
• 简短

第五步：筛掉弱 hook

以下类型直接判弱，必要时说明原因并重写：

• 太宽泛，谁都能套
• 只有情绪，没有信息
• 太像营销口号
• 开头像背景介绍
• 只是把主题重复一遍
• 靠夸张承诺吸引，但正文材料撑不住
• curiosity-gap 但后文材料根本撑不住答案
• 在多版本输出里和其他版本高度重复

筛选时至少检查：

• 是否有最小信息量
• 是否真的锚定用户素材
• 是否和已保留版本足够不同
• 是否为了吸引力牺牲准确性
• 是否越过了当前边界分类

第六步：批量输出规则

如果用户一次要很多版本，或明确说“只给 hook，不要解释”，仍然要跑完整 workflow。

规则如下：

• “只给 hook，不要解释”只改变最终输出格式，不改变内部 workflow
• 用户要 6 个以上版本时，先按不同 angle 起草，再做差异性检验和弱 hook 过滤
• 如果通过过滤的 hook 不够多，就直接少给
• 宁可少给，也不要凑数

第七步：输出最佳版本和备选

如果用户没有指定数量，默认输出：

• 1 个推荐 hook
• 5 到 10 个备选 hook

必要时补充：

• 最推荐版本：
• 为什么它更强：
• 适合后面怎么接： 用一句话说明即可

输出格式

默认使用这个格式：

# Hook Options

## Recommended
<最佳 hook>

为什么它更强：
<1-2 句>

适合后面怎么接：
<1 句>

## Alternatives
1. <hook>
2. <hook>
3. <hook>
...

如果当前分类是 hook + follow-up line，则推荐版本和备选都可以追加一句承接。

如果当前分类是 完整推文请求，就在 hook 结果后补一句边界说明，明确这次只先交付 hook 层。

如果用户明确要“只给我开头，不要解释”，就只输出 hook 列表，或只输出 hook + 承接句列表。

如果用户已经指定 length，最终交付要严格服从这个长度要求。

写作原则

• hook 的任务是让人停下，不是把整条内容提前说完
• 优先写“判断 + 对象 + 差异”，不要先写背景
• 能具体就不要抽象
• 能直接说就不要绕
• 不要默认使用问句；只有真的能制造有效参与时才用
• 不要滥用数字；数字只有在能提升可信度时才值得写
• 长度要求优先于默认模板；用户要超短就不要偷偷补成两句，用户要稍长也不要硬压成一句
• 不要为了吸引力牺牲准确性

边界

这个 skill 永远只交付 hook 层。

它不负责：

• 完整单条推文成稿
• 完整 thread 结构
• 发帖排期或自动发布

如果用户要的是完整推文，先给 hook，再明确这只是开头层，不要假装已经完成整条内容。