zeroz-lab 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，再明确这只是开头层，不要假装已经完成整条内容。