Refactoring English: Month 11

Michael Lynch

重构英语:第 11 个月

原文由 Michael Lynch 发布,订阅该博客

一句话总结

我正式延期了。

第一次来?

嗨,我是 Michael。我是一名软件开发者,也是几家小型独立科技公司的创始人。目前我正在写一本书,叫Refactoring English: Effective Writing for Software Developers

每个月,我都会像这样发布一篇回顾,分享新书的进展以及我整体的工作情况。

本月亮点

  • 我的新书进度落后了。
  • 一篇很棒的博客文章启发我重新思考便捷的 shell 脚本。
  • 游戏《缺氧》(Oxygen Not Included)很好玩。

目标评分

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

为读过本书的读者设置编辑服务折扣

  • 结果:创建了一个说明折扣的页面
  • 评分:A

页面已经建好了,但我有意没有把它当作抢先体验的福利来宣传。我的目的是与那些本身就对这本书抱有热情的人合作,而不是用它来吸引新客户。我之所以在这篇回顾里公开这个折扣,是因为如果你对我的工作感兴趣到会来读这些月度更新,那你正是我希望合作的自由编辑客户类型。

自从我把标准收费翻倍并为抢先体验用户增加折扣以来,还没有接到自由编辑的单子,但这其实没关系。因此我的写作产出反而更多了,我希望这样算下来是划算的——如果自由编辑的工作让我不得不放下写作,那相应的报酬能让我觉得这笔交换是值得的。

整理一份可联系的抢先体验用户名单

  • 结果:整理出了一份包含 63 位可联系用户的名单
  • 评分:A

我一直给自己定下要一对一联系更多读者的目标。我意识到,寻找合适的联系对象本身阻力很大,所以我把目标简化为:先整理出一份适合我去联系的客户名单,筛选标准如下:

  1. 他们的邮箱不是 Gmail/Yahoo/Hotmail 等纯邮箱域名。
  2. 其邮箱域名下有一个真实的网站。

说白了,我想找的是那些我能通过查看其网站、从而写出独特而个性化内容的读者。基于这份名单,我联系了三位用户,其中两位作出了回应,包括一位后来参加了上个月线上分享会的读者。我猜那封个性化的邮件对他们的参与起到了作用。所以,这种一对一的联系一直在带来积极的反馈,我只是需要做得更多。

发布本书的新章节

  • 结果:发布了 2.5 个新章节
  • 评分:A

我发布了《如何获得对设计文档有价值的反馈》、《动词驱动句子》和《保持积极》三篇。其中关于设计文档的那篇严格来说只算半章,因为我计划在正式出版的书中进一步扩充,加入更多关于设计文档应包含内容的细节。

《如何获得对设计文档有价值的反馈》是我近期反响最差的一篇,无论发在哪里都几乎没有引起关注。我本来也不是百分之百确信它会受欢迎,但我觉得有九成的把握。毕竟设计文档写作曾是读者最感兴趣的主题之一,所以我原以为会有更多人关注这个话题。

Refactoring English 数据一览

指标2025 年 9 月2025 年 10 月变化
独立访客7,28322,398+15,115 (+208%)
预售收入$484.71$570.75+$86.04 (+18%)
咨询收入$429.60$0.00-$429.60 (-100%)
赞助收入$48.25$48.25$0.00 (0%)
总收入$962.56$619.00-$343.56 (-36%)

10 月份网站的访客量是自 3 月份大规模 Kickstarter 推广以来最高的。共有 2.23 万独立访客,其中 93% 来自我上个月发布的《影响我的那些软件好文》,那篇文章我觉得并没有达到预期的效果

我当然希望预售量能随着访客量的增长更线性地提升,不过博客文章能为我的书带来新读者,我已经很满意了。

我延期了

刚开始写这本书时,我很有信心能在 2025 年 10 月前完成。我对外宣布的是 12 月完稿,只是给自己留点余量,当时我还怀疑根本用不上。

结果证明,我不仅需要这点余量,还远远不够。

早在 5 月,我就估算过每一章大概需要多少写作时间。六个月后再回头看,我的估算有多准?我低估了大约 40%。

我原本以为 114 小时就能写完全书,但目前的估算(在已经投入 99 小时之后)是 157 小时,也就是说我觉得还需要 58 小时才能完成。

我当时还估计自己每周能为这本书投入 5 小时写作,但这个估计也不对,六个月写了 99 小时,平均下来每周大约只有 3.8 小时。

我一般每天最多只能写一小时。写更久也可以,但效率会大幅下降,感觉第二小时的产出只有第一小时的 20% 左右。偶尔下午能再挤出一小时,但很少见。

我也没有把那些经常会打断我、让我无法好好写作的常规情况算进去:

  • 非书籍写作
    • 例如博客文章、回顾、笔记
  • 照护孩子的临时变动
    • 平时家人会帮忙照看孩子,但如果有人生病或没空,又找不到替代人选,我或我妻子就得请假来顶上。
  • 自由编辑工作
  • 生病
  • 休假
  • 提不起劲写作的日子

如果按每周约 3.8 小时的进度继续,剩下的 58 小时大约需要 15.3 周,也就是到 2026 年 2 月中旬。为了留出余量,我的目标是争取在 2026 年 3 月底前完成全书。

对于剩下章节的时间安排,我现在更有把握了。像《直击要点》(关于如何写出吸引人的开头)这样的早期章节比较难,因为我得把脑海中模糊的思考过程整理、提炼成清晰的体系。但像我的个人写作流程或如何聘请编辑这类话题就好讲得多,因为它们是我实际采取的具体行动,而不是抽象的思维方式。

推荐

Evan Hahn 的便捷脚本

上个月我读到的最好的一篇文章是 Evan Hahn 的《我一直在用的那些自制脚本》。他在文中分享了几个为自己开发工作减负的小脚本。我最喜欢的是这几个:

  • copy:从 stdin 读取内容并存入系统剪贴板。
    • 说来惭愧,我竟然从没想过这么做。以前我一直像野人一样用鼠标在终端里复制。
  • pasta:将系统剪贴板的内容输出到 stdout。
  • pastas:监听系统剪贴板,每当内容变化就输出到 stdout。
    • 第一次读这篇文章时,我还没意识到这个脚本有多巧妙
    • 你可以在一个终端里运行 pastas | wget --input-file=/dev/stdin,然后在浏览器里不断复制 URL,pastas 命令会自动下载你复制的每一个链接,完全不用来回切换窗口。
  • emoji:通过文本搜索 emoji。比如 emoji cool 会打印出所有与“cool”相关的表情符号。

Evan 的很多脚本点子都非常棒,我立刻就用上了。

更重要的是,我喜欢 Evan 这篇文章背后的核心思想:开发者应该主动去思考那些能消除日常工作摩擦的小脚本。它也拓宽了我对“什么可以做成脚本”的认知。比如 emoji,我以前根本不会想到要做这样一个脚本,因为我手头并没有所有 emoji 及其描述的列表,但读完 Evan 的文章后我才意识到,我完全可以像他那样自动生成这个列表。

这启发我在自己的 PATH 中添加了一个 chat 脚本,用于向本地部署的 LLM 提问。我经常需要打开浏览器去查命令行工具的用法,现在不用离开命令行,直接用 chat 提问就行:

#!/usr/bin/env bash

# Read prompt from command-line arg.
PROMPT="$1"

# Add implicit context for the prompt.
PROMPT+=' Assume a Linux OS.'
PROMPT+=' Prefer command-line tools.'
PROMPT+=' Optimize for the simplest possible response.'
PROMPT+=' If there are multiple methods, show me the simplest one.'
PROMPT+=' If possible, show me just a code snippet with no additional explanation.'

# Use a default LLM model but allow the user to override it.
MODEL="${MODEL:-llama3.2:1b}"

ollama run $MODEL "$PROMPT"

例如,昨天我就用它来回忆如何调整图片大小:

速度非常快!这个提问在我的机器上 265 毫秒就完成了,比我切换到浏览器、搜索、点开答案再切回任务要快得多。

Evan 的另一篇姊妹文章《为什么我把 alias 作为别名的最后选择》与这些脚本相得益彰,文中认为,与其使用 shell 别名,不如把便捷脚本放在 PATH 下的某个目录中(例如 ~/.local/bin),这样会带来更大的灵活性。

缺氧

我不是个重度玩家,但每年会买一款电脑游戏。通常一款游戏我玩 10 到 20 小时就会腻,不过花 15 到 50 美元换来 10 到 20 小时的娱乐,我觉得很值。有些游戏我会特别投入,能玩 25 到 100 小时(星露谷物语XCOM2赛博朋克 2077)。

《缺氧》在我心里挂了快一年了,起因是看到 Andrew Kelly 和 Mitchell Hashimoto 聊起他们有多喜欢这款游戏。Andrew Kelly 甚至说,这款游戏在培养系统思维方面太出色了,应该单独作为小学的一门必修课。

我在缺氧中的太空殖民地

我从 10 月开始玩缺氧,真的很有趣。我看到有人把它和 Factorio 和 Rimworld 作比较,但我没玩过那两款。它最让我联想到的其实是星露谷物语,尤其是其中的种田部分。在这两款游戏里,你都在尝试搭建一个能产出东西的系统。初期工具都很简陋,很多事都得手动完成,但随着游戏推进,你会获得更强大的工具,可以自动化更多工作、扩大生产规模。

缺氧最大的挑战是上手难。游戏内对一些概念有解释,但很多东西我都是靠试错学会的。YouTube 上有教程,但都长得离谱。比如,玩到后面你可以建造管道系统,但我搞不懂它怎么运作,于是去 YouTube 上搜教程,结果全是 60 分钟以上的!原因在于它们讲的都是那种能扩展到超大规模的超级复杂的管道方案,而我只想建一个厕所而已。

目前我找到的最好的教程是玩家 Jahws 写的这份文字指南

如果你是厉害的缺氧玩家,不妨来看看我的殖民地,告诉我都做了哪些蠢事。

收尾

完成了什么?

经验教训

  • 我没法做到每周为写书投入五小时。
    • 如果一周只写书,轻松能达到五小时,但现实中有太多潜在的打断和需要兼顾的事务。

下月目标

  • 发布两个新的书稿章节。
  • 联系 10 位读者。
  • 制作一个能为 Refactoring English 网站引流的工具或博客文章。

本文章由 muse-spark-1.2-contributor 进行翻译

评论