写开发者技术文章时如何做选题、标题、钩子与结构

当需要为开发者受众撰写教程、解析、基准测试、Bug 追踪、复盘或「我们用 X 重写」类博客文章时，用结构化流程产出标题变体与开发者级文章结构。

适用场景

解决思路

1. 通过环境的问题工具向用户提问，一次只问一个问题，提供 2–4 个可点击选项并等待回答；若环境无问题工具，则用散文形式按同样选项逐个提问。
2. Phase 1（必做）：先停下来做选题访谈，在写任何内容前逐项确认：1) 具体主题；2) 首要目标（通过问题工具给出选项：订阅/涨粉、个人品牌/思想领导力、产品注册/试用、直接购买、线索# 生成（下载/白皮书）、预约演示或销售通话、加入社区、互动（回复/分享/评论）、读者支持（付费订阅/打赏/赞助）、无转化目标；若用户选多个要回推，因为单一主 CTA 转化更好）；3) 受众（初级开发、资深工程师、CTO、通用技术、DBA、前端等）；4) 内容类型（Bug Hunt / We Rewrote It in X / How We Built It / Lessons Learned / Thoughts on Trends / Benchmark / Tutorial / Explainer）；5) 长度目标（短 800-1200、中 1500-2500、长 3000+）；6) 一句话论点。
3. 若用户已提供大部分信息，从对话中提取并确认；但若缺少关键信息（受众、内容类型、论点），必须停下提问，不要猜测。
4. 主题含糊时（如「写 Java 性能」），追问具体方面以及读者应带走什么。
5. 受众不清时直接问，因为面向初级开发和资深工程师的文章结构完全不同。
6. 无法推断论点时问用户「你最想让读者记住的一件事是什么？」；若答不出，通过追问什么让他惊讶、会怎么跟同事说、希望早点知道什么来帮他找到。
7. 内容类型模糊时（教程还是解析），问读者应获得什么体验：跟着动手做，还是建立心智模型。
8. 在进入 Phase 2 前，必须对主题、受众、内容类型、论点有足够清晰度以写出连贯大纲。
9. 应用选题质量过滤器：Julia Evans 启发式——最好的技术内容来自你挣扎过的事，而非你已精通的事；若主题太「教科书」，推向具体的挣扎、意外或反直觉发现。
10. 应用 Julian Shapiro 新颖性过滤器，选题至少满足其一：反直觉（「没想到世界是这样运作的」）、反叙事（「跟我被告知的不一样」）、震撼（「没想到这也能做到」）、优雅表达（「我一直有这种感觉但说不出来」）、被看见（「终于有人懂我的经历」）；若都不满足，直接说明并帮用户找到能通过的切入角度。
11. Phase 2：生成 10 个标题变体，使用不同钩子策略；阅读 references/hooks-and-titles.md 获取 10 种钩子类型与标题公式。
12. 标题面向开发者受众的约束：LinkedIn/B2B 分享最佳 7-12 词；具体胜过聪明（「How to profile Go allocations with pprof」优于「Mastering Go Performance」）；数字和数据体现严谨；避免最高级（ultimate、complete、everything you need）；技术关键词吸引正确受众；认知失调制造好奇但不做标题党。
13. 按评估排序呈现 10 个标题，并简要说明每个为何有效；让用户挑选或混搭。
14. Phase 3：把钩子委托给 copywriting-hooks 技能，传入 Phase 1 的主题、受众、语言、内容类型、长度目标；该技能会提出 3-4 个钩子选项（每个 2 个候选）并等用户选择；不要自己写钩子。
15. 用户选定钩子后，围绕它写剩余引言（2-3 段）：1) 钩子；2) 利害关系（1-2 句，读者为何要在意、不知道的代价）；3) 承诺（1 句，读者读完能得到什么）。
16. 在引言中回应读者三个异议：不可信（为何听你的？用可信度钩子或具体经历）、不相关（为何与我有关？用利害关系）、不可信服（真能做到吗？用承诺+具体性）。
17. 避免引言反模式：以字典定义开头、「In today's fast-paced world...」、「Have you ever wondered...」、把有趣部分埋在 3 段背景之后、解释文章将涵盖什么而不是直接展示价值。
18. Phase 4：按内容类型选择结构，阅读 references/article-structures.md 获取每种内容类型的详细模板。
19. 通用结构原则：每节一个想法（若一节做两件事就拆分）；先展示再讲述（先给例子、代码片段或观察，再解释）；渐进披露（从最简单版本开始，再增加复杂度）；每节都要赢得下一节（每节应产生足够动量拉读者前进，若某节可跳过就删掉）。
20. 代码密集型文章：片段少于 20 行且聚焦一个概念；始终展示「before」（问题）和「after」（解决方案）；注释不明显的行；完整代码链接到仓库，正文只展示有趣部分。
21. 观点/分析类文章：在反驳前先给对立观点最强论证（steelman）；用具体例子而非抽象推理；量化主张（「2x faster」而非「much faster」）。
22. Phase 5：写完整文章，交织钩子、正文各节和结论。
23. 结论避免复述文章，改为三选一：影响（这对读者今后的工作意味着什么）、开放问题（还有什么未解决或值得探索）、行动号召（读者下一步该做什么）。
24. Phase 5b：把 CTA 委托给 copywriting-cta 技能，传入 Phase 1 的首要目标；该技能会访谈用户补齐缺失输入（文章背景、受众关系、漏斗阶段、机制）并产出完整 CTA 建议——文案、形式、机制、A/B 测试计划和无障碍检查；把 CTA 放在结论之后，不要自己写 CTA。
25. Phase 5c：调用 humanizer 技能（如 humanize、humanizer、de-slop、natural writing check、AI detection cleanup、rewrite like a human）去除 AI 生成痕迹——填充词、可预测节奏、过度对冲、空洞过渡、浮夸语言；开发者受众自带 BS 探测器，AI 味会毁掉信任。
26. 保留钩子和标题：Phase 3 的钩子和 Phase 2 的标题是为好奇心和可信度刻意设计的，指示 humanizer 不要改动它们，为「自然」而重写会破坏赢得点击和首次滚动的文案结构。
27. Phase 6：草稿完成后，建议 1-3 张图片并给出具体位置；每张图提供：位置（如 hero/封面、引言后、X 节与 Y 节之间）、目的（打破长文本、说明概念、定调、可视化数据）、描述（图应描绘什么）。
28. 为每张建议图片提供生成 Midjourney 提示词的选项；若用户接受，使用最新 Midjourney 模型惯例写提示词：hero/封面和宽幅插图用 --ar 16:9 或 --ar 3:1（最适合文章头图），较小内嵌图用 --ar 3:2；参考最新 Midjourney 文档获取当前提示词语法和参数。
29. Phase 7：回顾 Phase 2 的标题，全文完成后某些标题更合适；呈现前 3 个并给出推荐。
30. 输出格式：用干净 markdown 呈现文章——所选标题作为 H1、副标题或元描述（1 句）、完整正文、带位置说明的图片建议（若接受则附 Midjourney 提示词）、结尾「Title alternatives」区放 2-3 个备选标题、社交预告（仅在用户接受时提供，草稿后再询问，不要自动生成）。
31. 需要更多深度时阅读参考文件：Phase 2 和 Phase 3 读 references/hooks-and-titles.md（10 种钩子类型、6 个文案框架 PAS/AIDA/BAB/FAB/PASTOR/4Us、标题公式和研究数据）；Phase 4 读 references/article-structures.md（8 种内容类型的详细模板、Diataxis 框架、结构反模式和过渡技巧）。

适用边界 · 注意事项

• 不要用于 newsletter 或 Substack 文章——改用 samber/cc-skills@substack-ghostwriting。
• 不要用于固化作者个人声音——改用 samber/cc-skills@copywriting-prose-creator。
• 不适用于面向非母语读者或机器翻译的参考文档——改用 samber/cc-skills@humanizer-en-asd-ste100 技能（ASD-STE100 简化技术英语）。