一句话总结

与其全力挥棒，不如试试触击？

亮点

• 我正在尝试低投入、低回报类型的博客文章。
• 我正在调整自由编辑服务的策略，专门面向读过我这本书的人。
• 对于登上 Hacker News 首页的概率，我的直觉完全错了。

目标评分

每月月初，我会宣布想要完成的目标。以下是我对这些目标的完成情况：

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

• 结果：发布了 《影响过我的软件随笔》，前三天吸引了 1.6 万读者
• 评分：B+

我确实完成了这件事，但在这篇文章上花了太长时间，对最终结果也有些不满意。

发布 Refactoring English 的新章节

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

我写好了一个新章节的初稿，但没有发布。结果我在《影响过我的软件随笔》和自由编辑客户上花费的时间超出了计划。

给 20 位从未联系过的读者写个性化邮件

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

我本来打算就此作罢，说联系客户已经学不到什么新东西了。然而几天前，我联系过的一位读者回复了我，他说他运用从我的书中学到的东西，第一次让一篇文章登上了 Hacker News 首页。所以这无疑是很有价值的，也告诉我应该多做一些这样的事。

我在下文对此有更多思考。

Refactoring English 各项指标

9 月的网站访客量和预售量都有不错的增长。我希望达到读者相互推荐、形成良性循环的地步，但我觉得还没有做到。不过，一个月能赚到将近 1000 美元还是很不错的。

尝试“触击”式写作

在棒球中，触击是指把球棒放在球的路径上而不是挥棒。好处是不太容易挥空，坏处是球不会打得很远。触击最好的结果是上一垒，但触击几乎不可能打出本垒打。

我的大部分博客文章都是“全力挥棒”式的。我投入大量精力，是因为想登上 Hacker News、reddit 或搜索结果的第一名。

问题在于，我的“全力挥棒”式文章大约要花一个月来写，所以如果我一边写书一边发布博客文章，那每写一篇博客就得把书搁置一个月。

我一直在想，能不能改写一些“触击”式的文章。这样，我只需把书搁置一周，而不是整个月。

我不想把一个值得认真对待的话题草草了事。相反，我想挑一个容易覆盖的话题，看看效果如何。

我的第一次触击是 《我曾经出现在 The Old New Thing 里》。它讲的是我 22 岁在第一份正式工作时的一段经历。关于这件事我没什么特别深刻的见解，但我觉得它是个有趣的故事。我只用了大约四个小时就写完了，就其本身而言感觉是完整的。

我的下一次触击是 《影响过我的软件随笔》。我见过别人分享他们最喜欢的软件博客文章清单，我觉得这会是件轻松有趣的事。最妙的是，欣赏优秀软件写作的人可能也会对我的书感兴趣。

但当我开始写《影响过我的软件随笔》时，它就不再只是一次触击了。结果我几乎花了整个 9 月在上面。

我原本想列出我最喜欢的博客文章就完事了，但那样感觉太无聊。于是我尝试给每篇文章加上简短的评论。接着我就收不住了，最后写出的评论比原文还长。我改了好几稿才弄明白什么样的评论才有趣，而且至今仍觉得自己没有完全成功。

我最终在《影响过我的软件随笔》上花了 17 个小时，而且中途从未停下来评估：如果要做这么多工作，它还值不值得写。

我觉得这篇文章对读我博客的人来说是有趣的。如果我认识的人发布一份影响过他们的文章清单，我会觉得有趣。但在关于这篇文章的评论串里，人们分享了他们自己的清单，而我发现陌生人的清单完全无趣。也许我在评论上投入很多多少弥补了这一点，但我就是不觉得一份优秀博客文章的清单能有多有趣。

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

有趣的是，结果几乎与我投入的精力成正比，而这通常并不符合我的经验。

浪费了我的高光时刻

以前，当我的某篇 Refactoring English 文章在 Hacker News 上表现出色时，购买这本书的读者会明显增多。而这一次，《影响过我的软件随笔》冲到了第 2 名，在首页停留了 11 个小时，却只有一个人购买。

也许在 Hacker News 上看到我文章的人都已经知道我在写书了，所以感兴趣的人都已经买了？

文章跌出 Hacker News 首页后的第二天早上，我醒来突然意识到：我根本没放书的广告！

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

我忘了在博客文章里加这个自我广告，所以前 1.4 万读者看了我的文章，却完全不知道我在写书。哎呀！

我已经更新了博客模板，这样以后就不可能再忘记加自我广告了。

调整自由编辑服务的做法

几个月前，我决定提供自由编辑服务，帮助其他开发者改进他们博客上的写作。我的想法是，这是一个机会，可以确保我书中解释概念的方式对真实的人说得通。

缺点是编辑的成本很高。每一单要花我四到七个小时，而且会消耗掉我当天的“深度思考”精力，所以同一天很难再写自己的东西。我还会感到要快速交付的压力，尽管没人催过我。但了解自己的写作流程就知道，等反馈等上好几天是很糟糕的。

一开始，自由编辑服务如我所愿：它给了我很多写书的灵感。但随着接的单越多，我获得的写书灵感就越少。现在，我写的大部分反馈，基本上都是把我已经写进书里的内容做一份个性化版本。

我想继续做编辑服务，但只面向读过我这本书的作者。我把价格翻了一倍，现在编辑一篇博客文章收费 400 美元。但我打算给读过这本书的读者打 9 折优惠——即 90% 的折扣。

打了九折后，收费几乎等于白送，但我希望客户支付一点费用，这样他们也会觉得自己有切身投入。

我仍会接没读过书的客户，但我要收足够的钱，让我觉得占用写书时间是值得的。400 美元可能还是太低，走着瞧吧。

为什么我总是跳过读者联络？

我一直在想，为什么我总是完不成读者联络的目标。表面上它似乎并不难，但它从来不像是最重要的事，所以我一直往后推。

有些任务我拖延是因为不喜欢做，但实际上我喜欢联系读者。看看不同的读者都在忙什么、他们如何应用我的技巧，是件有趣的事。

部分问题在于，给读者发邮件需要启动能量，因为我必须：

1. 打开我的预付费读者名单
2. 找出有网站的人（这样我才能说些个性化的内容）
3. 浏览他们的网站以了解更多
4. 写一封邮件，并仔细措辞以免听起来像 AI 生成的

如果我先整理一份要联系的客户名单和他们的网站，可能会有帮助。这样，当我想联络时，就不必每次都从零开始。

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

有几位 Refactoring English 的客户给我发来困惑的邮件，说他们付了钱却从没收到包含书籍链接的邮件。我通过 Stripe 收款，Stripe 在客户完成付款后会把他们重定向到书籍的 URL。如果客户没注意到重定向，或者忘了收藏页面，他们就失去了访问书籍的途径。

每当客户告诉我找不到书籍链接时，我就会在 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 Old New Thing 里》
• 发布了 《以 2 倍分辨率获取 xkcd 漫画》
• 为 Refactoring English 服务了两位自由客户
• 搭建了 webhook 处理器，向 Refactoring English 客户发送购买后邮件
• 为 Hacker News Observer 添加了“按小时统计成功率”功能
• 开始为 Jellyfin Roku 客户端代码做贡献
• 与 AirGradient 通了一次电话，讨论如何改善公司与其社区成员之间的关系

学到的教训

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

下个月的目标

• 为读过这本书的读者设置编辑服务折扣。
• 创建一份要联络的抢先版客户名单。
• 发布书的一个新章节。