save-the-cat-writing

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 的结构技巧，不是他的讨好逻辑。文章值钱的地方在于敢下判断、基于一手经验、不怕得罪人。诊断时如果"让文章更好看"和"说出真正的判断"冲突了，支持后者。