Banger Explainer — 创建经得起分享的教学内容

教学内容在两个方向上容易失败。语气过重，读者喜欢却无法复述；规格过细，读起来像无人分享的文档。本流程将每个职责分配给其真正擅长的内容部分。

首先加载

${CLAUDE_PLUGIN_ROOT}/references/frameworks/voice-and-audience.md — 受众画像和创作者硬性约束。
${CLAUDE_PLUGIN_ROOT}/references/frameworks/technical-clarity.md — 框架/有效载荷分离及有效载荷纪律。核心参考。
${CLAUDE_PLUGIN_ROOT}/references/frameworks/writing-quality.md — 交付前的活门。
${CLAUDE_PLUGIN_ROOT}/references/platforms/platform-playbook.md 的目标平台部分。

新鲜度检查

在引用本技能或操作手册中的任何平台基准、算法声明或数值性能声明之前，请检查 references/research/source-ledger.md 中是否有未过期的支持。如果支持缺失或已过审查期，请运行 banger-research，将该声明标记为未验证，或直接省略。

步骤 1：命名机制

为自己写一句话，不是给读者看的：读者在看完后理解了什么以前不懂的东西？ 每篇内容只讲一个机制。如果需要两句话，那就是两篇内容。

然后，命名读者目前可能持有的错误模型。优秀的技术内容会替换一个错误的模型，而不是填充一个空白的模型。这个错误的模型通常是引子。

步骤 2：检查证据

在起草之前，请说明：

工件（仓库、文件、提交、截图、错误文本、基准测试），
实际发生了什么，包括失败的部分，
尚未测试的内容，必须如实说明。

如果没有工件，这是观点文章，不是讲解。请转到 banger-threads 或 banger-longform-written，并告知。

步骤 3：设定解释深度

使用 voice-and-audience.md 中的受众画像。首要原则是：使词汇与受众的实际水平相匹配。

非专家受众 — 在提及每个基础概念的同时，用简单的类比进行定义。展示确切的屏幕、提示和结果。有效载荷更长，步骤更小。决不高高在上。
从业者受众 — 可以自由使用内部行话，过度解释会浪费他们的时间。将篇幅用于权衡、失败模式以及你本可以做得不同的事情上。

步骤 4：按分离原则起草

框架（作者语气，而非清晰度规则）：

一个引子，指明具体的错误模型或具体的痛点，而非其类别。
故事：你当时在做什么，什么出了问题，代价是什么。
判断：你现在的看法，以及你有多确信。
符合平台原生习惯的行动号召。

有效载荷（技术清晰度）：

每个概念只用一个名称，并通篇保持一致。
每句话一个想法，大约 25 个单词，步骤句接近 20 个单词。
使用带有命名主体的主动语态："解析器读取文件"。
使用动词，而非名词化。展示数字，而非声称质量。
具体的工件：真实的命令、真实的错误、真实的路径。

在有效载荷中保留缩写、旁白、幽默和观点，在这些地方它们才有分量。纪律并不意味着扁平化。

步骤 5：平台形态

X 或 Bluesky 线程 — 每个帖子一个机制步骤。框架是第一个帖子也是最后一个帖子。有效载荷帖子尽可能包含代码块或截图。长度不要超过机制所需。
LinkedIn — 前 150 个字符内设置引子，采用错误模型框架，然后用三到四个短段落呈现有效载荷要点。以判断加一个问题结尾。正文中不要有链接。
Newsletter 或 Substack — 每个机制步骤一个标题，每个步骤一个图表或代码块，用引文突出判断。提供独立于框架的、从有效载荷中提取的笔记。
视频描述或文档式帖子 — 有效载荷占主导，框架缩减为两行。
Facebook 群组 — 不要使用本流程。转到 banger-longform-written，以问题引导，保持简短。

步骤 6：交付前验证

运行 writing-quality.md 活门，然后执行以下检查：

读者在关掉帖子后能否复述该机制？
每个概念是否都只用一个名称？
是否有任何内容声称了质量而不是展示了质量？
框架听起来是否仍然像是作者亲口说的？
每个数字、引文和结果是否都能追溯到真实的工件？
是否满足了创作者的硬性约束（禁止使用的标点、短语、语气）？

输出格式

首先提供最终的成品，可以直接粘贴，并按照目标平台格式化。然后列出：

机制句子及其所替换的错误模型，
每个声明所追溯的工件，
任何标记为未验证的内容，
下一步需要的批准。

起草是自由的。发布、安排和推广需要创作者对每个项目进行明确批准。

Banger Explainer