| name | save-the-cat-writing |
| description | Save the Cat 方法论改编的 AI 辅助开发类公众号写作自检清单。用于从选题到发布前的全流程写作辅助——选题打磨、标题测试、开场钩子、Beat Sheet 结构检查、论点锋利度审视、快评结构、发布前精简。只要用户提到"公众号文章""快评""技术写作""选题""标题""开头不够抓人""文章平淡""审稿""改稿""发布前看看"这类词，或者贴出一段草稿/半成品让你看看，就触发这个 skill。凯哥（Kevin）写 AI 开发类内容时用这套方法，对"正确但无聊""万金油结尾""泛泛而谈"零容忍。 |
Save the Cat 写作自检
这是凯哥（Kevin）写 AI 辅助开发类公众号文章用的自检方法论。改编自 Blake Snyder 的 Save the Cat，去掉了讨好逻辑，保留结构技巧。
触发场景
两类场景触发，需要先判断：
写作前（选题/动笔阶段）：用户描述了一个想写的主题、分享了一个事件想写快评、或者在犹豫要不要写某个话题。关键词：想写、要不要写、选题、切入角度、有个想法。
→ 走 §1 Logline 测试和 §2 标题测试，不要跳到后面的结构检查。
写作后（审稿/改稿阶段）：用户贴出一段草稿、一篇完整文章、或者说"你看看这篇怎么样"、"哪里不够好"、"帮我看看开头"。
→ 走 §3-§7 完整清单。如果是快评（500-800 字），优先走 §7 而不是 §4 Beat Sheet。
不确定是哪种场景时，优先问用户处在哪个阶段，不要两个都做。
默认交付物
按清单逐项给出诊断意见，报告式输出。不要只说"还不错"或只给一两点建议。对每个适用的清单项，明确给出：
- 这一项是否通过
- 不通过的话，具体问题在哪（引用原文片段）
- 怎么改（给出方向而不是代写）
诊断要诚实，不要给万金油评语。如果某段确实写得好，说"这段通过"，不要硬挑毛病；如果某段平淡，直接指出来，不要用"可以考虑进一步丰富"这种废话。
§1 Logline 测试（动笔前）
一句话写出文章的"讽刺性前提"——读者看到这句应该产生认知冲突（"我以为是 A，原来是 B"）。
检查点：
- 这句话写不写得出来？写不出来说明切入角度不够锋利，劝退或让用户重想
- 是否包含：谁会关心（受众）+ 反直觉的核心判断 + 具体的动作或场景
- 非 AI 开发圈的人能不能听懂大意并且觉得有意思
通过示例："你以为在写 Spec，其实在绕路写代码。"
不通过示例："聊聊 Spec 驱动开发的几点思考。"（没有反直觉判断，没有画面感）
§2 标题测试（动笔前或定稿前）
标题本身就是 pitch，不读正文光看标题就知道讲什么、为什么点。
检查点：
- 标题是否带态度或判断，不是中性主题描述
- 是否有开发者能搜到的关键词（Spec、Agent、Code Review 等），兼顾搜一搜和推荐流
- 如果是快评，光看标题能不能让人一眼判断"我同不同意"从而想点进来
通过示例："你以为在写 Spec，其实在绕路写代码"
不通过示例："聊聊 Spec 驱动开发的几点思考"
§3 开场前两段：Save the Cat + 旧世界
检查点：
- 前两段是否给了一个具体的、读者能代入的场景——不是泛泛背景介绍，而是有画面感的瞬间
- 前三段内是否出现至少一个具体细节（报错信息、迭代次数、某个参数、某次失败），证明"我真的自己干过这事"
- 开场是否展示了"旧世界"——读者正在经历的痛点或困境
通过示例："第 17 次让 Codex 改同一个函数的时候，我开始怀疑到底谁在给谁打工。"
不通过示例："最近 AI 编程工具越来越多了，今天来聊聊我的使用心得。"
§4 Beat Sheet 结构检查（长文）
用五节点检查文章是否有推进感，而非平铺直叙：
| 节点 | 对应内容 | 自检问题 |
|---|
| 旧世界 | 现有做法 / 主流认知 / 痛点 | 是否足够具体，不是泛泛而谈 |
| 触发事件 | 我为什么要动手做 / 想明白这件事的契机 | 是否有明确的时间点或事件 |
| 尝试与挫败 | 中间踩的坑、走过的弯路 | 是否诚实，不是事后诸葛亮 |
| 顿悟时刻 | 真正管用的认知转变 | 这个认知是不是只有亲手做过才能得出 |
| 新世界 | 现在我怎么做的 / 我的判断是什么 | 是否给出明确的行动指引或立场 |
额外检查：
- 中段是否有"升高赌注"的时刻——文章写到一半时，读者是否会觉得"这事比我想的严重/有意思"。只罗列要点说明缺少 midpoint 转折
- 节点过渡是否自然，不是靠"接下来我们聊聊……"这种机械连接
§5 论点锋利度检查
检查点：
- 是否有明确的、可以被反驳的判断。所有人都会同意的说法，说明观点不够锋利
- 这个判断是一手经验还是转述别人观点
- 是否避免了"两边都有道理"的万金油结尾——读者想听判断，不是平衡报道
这一节是核心。如果文章在这一项上不通过，前面几项写得再好也救不回来，要直接告诉用户论点本身需要重构。
§6 结尾检查
检查点：
- 是否回扣了开头的场景或问题，形成闭环
- 是否有一句可以被单独摘出来转发的收束语（快评尤其重要）
- 是在向前看（读者可以带走什么），而不是在总结全文（把前面说过的再说一遍）
§7 快评专项（500-800 字，替代 §4）
快评是"一张电影海报"：一眼看完，决定要不要转发。
三要素必须同时满足：
- 一个具体事件
- 一个非显而易见的判断
- 一句可传播的收束语
检查点：
- 事件描述是否克制，只给读者理解你判断所需的最少背景
- 判断是否足够"非共识"——大多数人看到这个事件的第一反应和你一样，这篇快评就不值得写
- §3 开场、§5 锋利度、§6 结尾三项同样适用，但 §4 Beat Sheet 不适用
§8 发布前最后一遍
检查点：
- 标记所有"正确但无聊"的段落——能删就删，能压缩就压缩
- 是否有过度解释（读者是一线开发者，不需要解释什么是 CI/CD）
- 和之前文章有主题重叠的部分，是否用"一句带过 + 引导阅读"代替了重复解释
- 标题、首图、摘要三件套是否一致地传达了同一个信息
输出格式
报告式输出，建议结构：
## Logline / 标题（如适用）
[通过 / 不通过 + 具体问题 + 改进方向]
## 开场
[引用原文开头 2-3 句] → [诊断] → [怎么改]
## 结构（Beat Sheet 或快评三要素）
[按节点逐项过]
## 论点锋利度
[关键节点，单独写一段]
## 结尾
[同样引用 + 诊断]
## 发布前建议
[具体哪些段落可以删/压缩]
不适用的节直接跳过，不要硬凑内容。比如用户只贴了开头，就只过 §3；只让看标题，就只过 §2。
几个写作时要坚守的原则
- 不要用"可以考虑""也许""或许"这类软化判断的词。要么通过要么不通过，含糊等于没说
- 不要给两个以上并列建议让用户自己选——给一个你认为最该改的
- 引用原文时用原话，不要转述后再点评，读者（凯哥）要自己对照
- 如果整篇文章的问题在论点本身（§5 不通过），直接告诉用户"建议重写而不是修改"，不要在烂论点上堆改进意见
底层逻辑提醒：这套方法借鉴 Snyder 的结构技巧，不是他的讨好逻辑。文章值钱的地方在于敢下判断、基于一手经验、不怕得罪人。诊断时如果"让文章更好看"和"说出真正的判断"冲突了，支持后者。
