一句话总结

与其全力挥棒追求全垒打，不如试试触击短打？

本月亮点

• 我正在尝试写一些低投入、低回报的博客文章。
• 我正在调整自由编辑服务的策略，只为读过我这本书的人提供服务。
• 我对登上 Hacker News 首页概率的直觉大错特错。

目标评分

每个月初，我都会定下当月想完成的目标。以下是完成情况：

发布一篇能为 Refactoring English 网站吸引新读者的内容

• 结果：发布了 《The Software Essays that Shaped Me》，发布后三天内吸引了 1.6 万名读者
• 评分：B+

虽然顺利完成了，但我在这篇文章上花了太长时间，而且对最终成果有点失望。

发布 Refactoring English 的新章节

• 结果：没有发布任何新内容
• 评分：F

我写了新章节的初稿，但没有发布。时间都花在了《The Software Essays that Shaped Me》和自由编辑客户的项目上，超出了原计划。

给 20 位从未交流过的读者发送个性化邮件

• 结果：只给两位新读者发了邮件
• 评分：D

我本来想就此作罢，觉得通过联系读者已经学不到什么新东西了。但几天前，一位我之前联系过的读者回复说，他运用从我书中学到的方法，第一次让自己的文章登上了 Hacker News 首页。这无疑非常有价值，也说明我应该多做这件事。

关于这一点，我在下文有更详细的思考。

Refactoring English 运营数据

9 月份网站访客和预售收入都有不错的增长。我希望能形成读者互相推荐的良性循环，但目前还没到那一步。不过，一个月能有将近 1000 美元的收入，还是很不错的。

尝试“触击短打”

在棒球中，触击短打是指将球棒横在球的来路上，而不是用力挥棒。好处是不容易挥空，缺点是球不会飞得很远。触击最多只能让你上一垒，几乎不可能打出全垒打。

我的大多数博客文章都是“全力挥棒”型的。我会投入大量精力，因为我想冲上 Hacker News、Reddit 或搜索结果的第一名。

问题在于，这种“全力挥棒”的文章写一篇就要花上一个月左右，如果一边写书一边发博客，每写一篇博客就得把书搁置一个月。

我一直在想，是否可以改写一些“短打”文章。这样，我只需要把书搁置一周，而不是整整一个月。

我不想把一个值得认真对待的选题草草敷衍。相反，我想挑一些本身就比较轻松的话题，写出来看看效果如何。

我的第一篇短打是 《I Once Appeared in The Old New Thing》。讲的是我 22 岁时在第一份正式工作中的一段经历。我并没有太多深刻的见解，但觉得这个故事本身挺有意思。花了大约四小时就写完了，就其本身而言已经算完整了。

下一篇短打是 《The Software Essays that Shaped Me》。我看到过别人分享自己最喜欢的软件类博客文章，觉得做个类似的清单会是一件轻松又有趣的事。更重要的是，喜欢优秀软件写作的人，或许也会对我的书感兴趣。

但动笔写《The Software Essays that Shaped Me》后，它就不再是一篇短打了。我几乎把整个 9 月都花在了上面。

我本来只想列出自己喜欢的博客文章就完事，但感觉太枯燥了。于是尝试为每篇文章加一点简短的点评，结果一发不可收拾，点评写得比原文还长。我改了好几稿才琢磨出什么样的点评才算有意思，但现在回头看，依然觉得不算成功。

最后我在这篇文章上花了 17 个小时，却从未停下来评估一下，如果要投入这么多精力，是否还值得继续写下去。

我觉得这篇文章对我的博客读者来说还是有意思的。如果是我认识的人发布一份影响过他的文章清单，我会觉得很有趣。但在文章的评论区里，大家也分享了各自的清单，我却发现陌生人的清单完全提不起我的兴趣。也许我通过大量点评在一定程度上弥补了这一点，但我还是觉得，一份优秀博客文章的清单本身，很难真正吸引人。

两篇文章的表现都不错，都登上了 Hacker News 首页，不过都是通过二次机会池（second chance pool）上去的，感觉有点像靠技术性击倒（TKO）获胜，而不是真正的击倒。

有意思的是，这次的成果几乎与投入的精力成正比，而这在平时并不常见。

浪费了高光时刻

以前，当我在 Refactoring English 上发布的文章在 Hacker News 上表现不错时，都会明显带动图书销量购买量。这一次，《The Software Essays that Shaped Me》冲到了第 2 名，在首页停留了 11 个小时，却只有一个人下单。

也许在 Hacker News 上看到这篇文章的人，早就知道我在写这本书，感兴趣的人已经都买过了？

文章已经从 Hacker News 首页掉下来的第二天早上，我醒来才突然意识到：我居然忘了放书的广告！

书的网站上所有样章都会带一个小小的自我推广，告诉读者我正在写一本关于这个主题的书，可以购买抢先版。

我忘了在博客文章里加上这个自我推广，所以最先看到文章的 1.4 万名读者根本不知道我在写书。哎呀！

我已经更新了博客模板，以后就不会再漏掉这个自我推广了。

调整自由编辑服务的策略

几个月前，我开始提供自由编辑服务，帮助其他开发者改进博客写作。我的想法是，这是一个检验书中概念讲解是否能让真实读者理解的机会。

缺点是编辑工作的成本很高。每一单都要花四到七小时，会耗尽我一天中“深度思考”的精力，所以当天很难再进行自己的写作。我也总觉得要尽快交付，虽然并没有人催我。但以我自己的写作体验来说，等待反馈好几天确实很难熬。

起初，自由编辑完全达到了我的预期：为我的书提供了不少好点子。但做得越多，从中获得的新点子就越少。现在，我写的大多数反馈，基本上都是把书里已经写过的内容，换成针对个人的版本。

我想继续做编辑，但只面向读过我书的作者。我把价格翻了一倍，现在一篇博客文章的编辑费是 400 美元。不过，对于读过我书的读者，我会提供 90% 的折扣。

打了 90% 的折扣后，其实几乎不怎么赚钱了，但我还是希望客户付一点费用，这样他们也会更认真对待。

对于没读过书的客户，我也会继续接单，但收费要高到让我觉得占用写书时间是值得的。400 美元可能还是太低了，走着瞧吧。

为什么我总是在逃避读者沟通？

我一直在想，为什么我总是完不成联系读者的目标。表面上看这件事并不难，但它似乎永远不是最重要的事，所以总被我一推再推。

有些任务我会拖延是因为不喜欢做，但联系读者我其实是喜欢的。看看不同的读者在做什么、他们如何运用我的方法，还挺有意思的。

部分原因在于，给读者发邮件需要启动成本，因为我得：

1. 打开已付费读者名单
2. 找出其中有个人网站的（这样才能写出有针对性的内容）
3. 浏览他们的网站以了解他们
4. 撰写邮件，并措辞谨慎，避免听起来像 AI 生成的

也许我可以先整理一份待联系客户及其网站的清单。这样，当我想联系读者时，就不用每次都从零开始了。

用 Stripe 发送购买后邮件的麻烦事

有几位 Refactoring English 的顾客发邮件来困惑地问，他们已经付款了，却没有收到带有图书链接的邮件。我是通过 Stripe 收款的，付款完成后 Stripe 会将顾客重定向到图书的链接页面。如果顾客没有注意到这个跳转，或忘记收藏页面，就会找不到书。

每当有顾客说找不到图书链接，我都会去 Stripe 里翻找自定义购买后邮件的设置，几分钟后放弃，然后手动给顾客发去正确的链接。

上个月，我终于静下心来，仔细查阅了 Stripe 的文档和论坛帖子，结果发现，根本找不到任何可以自定义一次性付款完成后 Stripe 所发邮件的方法。据我所知，唯一的办法就是自己搭建一个 Web 服务器来监听 Stripe 的 webhook，然后通过自己的邮件服务商发送邮件。就因为 Stripe 懒得让商家自定义付款完成邮件里的任何文字……

搭建一个响应 webhook 的 Web 服务器对我来说本不该太难，但这意味着要写代码把 Stripe、Buttondown 和 Netlify Functions 粘合在一起，而它们各自都有一些坑和 bug。尤其是 Stripe。到目前为止，我已经花了大约 10 个小时，就为了让顾客付款后能收到邮件，而且还不确定是否真的正常工作了。

以下是目前踩过的坑：

• Stripe 的 Go 客户端库只兼容某一个特定版本的 Stripe webhook API。
  • 不，文档里根本没说到底是哪个版本。跑起来，从 webhook 失败里自己去猜吧！
• 如果你把 Stripe 账户更新到最新的 webhook API 版本，然后重发一个旧事件的 webhook，Stripe 仍然会使用旧的 API 版本，尽管它声称用的是新版本。
• Stripe 针对 checkout.session.completed 的 webhook 请求实际上并不包含 line_items，尽管文档里写着有。
  • 这很麻烦，因为这意味着除非你额外调用一次 API，否则根本无法知道顾客到底买了什么。
• Netlify 会悄悄把 HTTP 头名称转换成小写，所以如果你要找 Stripe-Signature: 头，就得去找 stripe-signature。
• Stripe 的 webhook 签名密钥和你的 Stripe API 密钥是不同的。

业余项目

按小时拆解 Hacker News 的成功率

我还在捣鼓 Hacker News Observer，这个产品我还没发布，也不知道该怎么处理。目前我只是用它来收集数据，满足自己对 Hacker News 成功规律的一些好奇心。

我一直很好奇，一天中是否存在更容易让帖子登上 Hacker News 首页的时间段，于是我统计了一天中不同时段帖子登上首页的比例：

起初我以为自己代码有 bug，把成功率算高了，因为在我印象中，能登上 Hacker News 首页的投稿比例应该远低于 12%。但查看了最近几天的一些随机时间段后，发现数据似乎是对的。如果我浏览 /newest 页面，通常会有 2 到 5 篇登上过首页的帖子。我还发现几天前有一个 30 分钟的时间段内，27% 的投稿都登上了首页，这很令人意外。

我本以为周末投稿较少，成功率会明显更高。周末的帖子确实更容易登上首页，但效果远比我想的要小。

• 工作日：12.1% 的投稿登上首页。
• 周末：13.2% 的投稿登上首页。

我原本以为会是工作日 5%、周末 20% 这样的差距。这让周末投稿的吸引力降低了，因为登上首页的概率只是略高一点，而一旦成功，读者数量却会少得多。

我想尝试像在 HN Popularity Contest 中那样，把数据限定为个人博客，看看个人博客是否在某些时段有更高的成功率。

收尾

完成了什么？

• 发布了 《The Software Essays that Shaped Me》
• 发布了 《I Once Appeared in The Old New Thing》
• 发布了 《Get xkcd Cartoons at 2x Resolution》
• 为 Refactoring English 服务了两位自由编辑客户
• 搭建了 webhook 处理程序，用于向 Refactoring English 顾客发送购买后邮件
• 为 Hacker News Observer 添加了“按小时统计成功率”功能
• 开始为 Jellyfin Roku 客户端贡献代码
• 与 AirGradient 进行了通话，讨论如何改善公司与社区成员之间的关系

经验教训

• 如果一篇本想低投入的文章变成了高投入，要考虑及时止损。
• Stripe 不允许自定义购买后邮件。
  • 想给顾客发邮件，你得额外做一大堆事。

下月目标

• 为已读书籍的读者设置编辑折扣。
• 整理一份可联系的抢先版顾客名单。
• 发布书的新章节。