独立开发者
如何把博客文章改写成 X 单帖
把一篇博客拆成多条能独立成立的 X 单帖，每条只讲一个想法，而不是把全文压成一条摘要。
问题
- 一篇文章里其实有六七条论点，最后只有标题那条被分享过。
- 其余素材在归档里慢慢过期，除了那一周读过的人，谁也没见过。
- 把全文压成一条帖子，得到的是摘要的摘要，没人会转发。
- 从零写新帖子倒是有用，但它要占掉你写下一篇的时间。
为什么常见做法不够用
发一次链接
触达的只是本来就会读的人，之后就没有然后了。
压成一条长推串
按原文顺序复述的线程，是在要求读者跟着你的结构走，而不是带走一个想法。
摘出最精彩的段落
没有机制的引文只是一句好句子。读者的处境没变，所以也不会收藏。
用提示词生成几个版本
得到的是同一个论点换四种说法。信息流把它当成一条内容重复推送。
怎么做
-
01
先拆解，再写作把文章里的单元列出来：主张、机制、反差、可带走的物件。两千字通常能拆出六到十个，其中四到六个值得发。
-
02
按意外程度排，不按出现顺序排按「多大程度违背读者既有认知」排序。最意外的先发，它替后面的内容挣注意力。
-
03
每条单元单独写第一行文章的开头从来不能直接当帖子的开头。每条都重写，凡是需要原文上下文的开头一律删掉。
-
04
挂机制，不挂结论「autovacuum 在规模下会失效」是结论；「死元组的堆积速度快过 autovacuum 默认触发阈值」才是帖子，因为它教会了人东西。
-
05
强制独立阅读每条帖都要让一个没读过文章、也不会看下一条的人看懂。不写「第 3 部分」，不写「如上所述」。
01进来的东西
多一个配置项的真实成本
每多一个配置项，产品就多背一份永久成本：测试矩阵、文档、支持，三样涨得都比用户数快。
这是示例演示，不是客户案例：论点是——每多一个配置项，产品就背上永久的支持、文档、测试和决策疲劳成本，而大多数团队从没给这些成本定过价。一篇文章，五个角度。
02一篇文章拆出的五个角度
| 角度 | 帖子要论证什么 |
|---|---|
| Contrarian view | Your config page is not flexibility. It is deferred product decisions. |
| Mechanism | Every option multiplies the test matrix and the support surface, and both costs grow faster than user count. |
| Practical insight | Four questions to ask before shipping a flag, and the one that kills most of them. |
| Story | The option we shipped to satisfy one customer, and the three years of docs it cost. |
| Decision rule | If an option cannot be explained in one sentence, it should be a default, not a setting. |
03产出的东西
Post 1 — Contrarian view
Your settings page is not flexibility.
It is a list of product decisions you did not make.
Every option is a question the user now has to answer, and most of them will answer it wrong.
Post 2 — Mechanism
One config option does not cost one option.
It multiplies the test matrix, doubles the documentation surface, and adds a support category that will never close.
Those three costs grow faster than your user count.
Post 3 — Practical insight
Four questions before shipping a flag:
- Who asked for this, by name?
- What is the default, and why is it not good enough for them?
- How many states does this add to the product?
- What breaks if we simply do not ship it?
Question four kills most options. The ones it does not kill are worth shipping.
Post 4 — Story
We shipped a config option to close one enterprise deal.
It cost three years of documentation, a support category and two bugs that only existed for users who set it to the non-default value.
The deal was worth it. The default should still have been the only behaviour.
Post 5 — Decision rule
If you cannot explain an option in one sentence, it is not a setting.
It is a default you are avoiding choosing.
AtomSlice 怎么帮上忙
：贴已发布的文章，主张、数字和限定条件完整保留，不会被转述磨掉。
：把文章拆成机制、反差和判断规则，让你看清它到底能出几条真正不同的帖子。
：每个角度单独成帖、单独写第一行，不是同一份摘要的变体。
：按 X 的形态产出：短行、一条一个想法，没有文章式的长段落。
实用建议
- 一天发一个单元。一早上发六条读起来像倾倒；拆到两周里，读起来像一套思考。
- 建库存。拆出来还没发的单元，是糟糕的一周里唯一能撑住节奏的东西。
- 优先发机制。讲「为什么」的帖子走得比讲「是什么」的远。
- 第一行每次都重写，哪怕这个单元三周后原样重发。
- 让表现最好的单元变成下一篇文章。如果一条帖跑赢了原文，那是读者在告诉你下一篇写什么。
常见问题
一篇博客能拆出几条 X 帖子？
通常四到六条真正不同的帖子。取决于单元数量而不是字数：一个主张配四个例子的文章只有一条，因为例子是证据。
该发长推串，还是发独立单帖？
独立单帖，除非论证本身必须按顺序才成立。长推串在给出价值之前先要求读者承诺，而大多数人在第一条就决定了要不要看。
如果文章本来就很短呢？
短文里依然有机制。产出一条帖子是正常结果，目标是抽取，不是凑数。
需要回头改那篇文章吗？
不需要，也不应该。文章是终点，帖子是入口；入口指向一个更有深度的地方才有效。