# Gm X Hook Writer > 为 X/Twitter 推文生成更强的 hook 和首句，不负责写完整推文。Use when users need stronger X/Twitter hooks, first lines, or thread openers from a topic, draft, opinion, or observation without writing the full post. - Skill: `zeroz-lab/gm-x-hook-writer` (Agent Skill) - Install (CLI): `npx skillmds@latest add zeroz-lab/gm-x-hook-writer` - Raw SKILL.md: https://api.skillmd.com/api/skills/zeroz-lab/gm-x-hook-writer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: zeroz-lab (https://skillmd.com/u/zeroz-lab) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/zeroz-lab/gm-x-hook-writer --- # 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 必要时补充： - `最推荐版本：` - `为什么它更强：` - `适合后面怎么接：` 用一句话说明即可 ## 输出格式 默认使用这个格式： ```md # Hook Options ## Recommended <最佳 hook> 为什么它更强： <1-2 句> 适合后面怎么接： <1 句> ## Alternatives 1. 2. 3. ... ``` 如果当前分类是 `hook + follow-up line`，则推荐版本和备选都可以追加一句承接。 如果当前分类是 `完整推文请求`，就在 hook 结果后补一句边界说明，明确这次只先交付 hook 层。 如果用户明确要“只给我开头，不要解释”，就只输出 hook 列表，或只输出 hook + 承接句列表。 如果用户已经指定 `length`，最终交付要严格服从这个长度要求。 ## 写作原则 - hook 的任务是让人停下，不是把整条内容提前说完 - 优先写“判断 + 对象 + 差异”，不要先写背景 - 能具体就不要抽象 - 能直接说就不要绕 - 不要默认使用问句；只有真的能制造有效参与时才用 - 不要滥用数字；数字只有在能提升可信度时才值得写 - 长度要求优先于默认模板；用户要超短就不要偷偷补成两句，用户要稍长也不要硬压成一句 - 不要为了吸引力牺牲准确性 ## 边界 这个 skill 永远只交付 hook 层。 它不负责： - 完整单条推文成稿 - 完整 thread 结构 - 发帖排期或自动发布 如果用户要的是完整推文，先给 hook，再明确这只是开头层，不要假装已经完成整条内容。