我如何过度工程化了一本书
How I Over-Engineered My Book
我没有用 Word 或 Google Docs 写书，而是用 Git、Markdown 和 CI 流水线构建。我为这本书设置了约 5500 个自动化检查，每次 git push 都会重建五种格式，甚至有一条规则能检测我是否误写自己仍在 GitHub 工作。从实时语法检查到基于 LLM 的语义重复检测，我把写代码的严谨带入了写作。这套系统不仅帮我纠正了拼写和格式，还揪出了我无意识重复的观点。虽然过程看似荒谬，但正是这种过度工程化让我写出了《Open and Async》。
我把自己复述得太完美了，以至于除了 LLM 之外，没有任何更便宜的工具能抓到我。
HN 评论区
44- sinab
感谢演示！我喜欢这个概念。不过，我个人觉得你设计的写作风格读起来非常有 AI 生成的痕迹。比如，用“这里的讽刺在于：在自动化到这一步之后……”或者“将 emoji 转为图片解决了缺字体问题，却又制造了一个更微妙的问题”这样的短语来开启一个章节。
这两者都是 AI 生成文本的明显特征，尽管我很难准确说出具体原因。这让我不禁好奇，是你的风格进化得越来越像 AI 生成的文本了，还是 AI 生成的文本进化得越来越像你了？
- cadamsdotcom
自定义 linting 既便宜又简单，为什么不试试呢！
> “请在这个 repo 里添加一个 pre-commit hook，形式为一个脚本，打印出所有包含连字符形式 'open-source' 字符串的文件名和行号；如果发现任何实例，则返回非零退出码。然后请将其安装到 `.git/hooks` 中，这样在我和代理移除所有实例之前，提交将被阻止，从而我们再也不会在 commit 中出现 'open-source' 这个字符串。”
按下回车键一分钟之后，你就为自己保证：这个 repo 将永远不再出现 'open-source' 这个字符串。
- frizlab
> AI 审阅了每一页；我写了每一个字。
在我看来，这才是 AI 唯一正确的用法，包括在开发领域。
- t-kalinowski
看到你列出的那些用于自动化的工具，我猜你会喜欢这个，可以作为堆里的另一个工具：https://t-kalinowski.github.io/yamark/
（声明：这是我写的）
- hinkley
我曾看过一次 Bruce Eckel 的演讲，那是在《Thinking in Java》成为畅销书之后。
我原本以为他会谈谈 Java，以及写这本书时的经验教训（他并非始于 Java 也非终于 Java，而是记录了许多编程语言）。
但我们得到的，却是他如何“过度工程化”这本书的回顾。他让实习生帮他解决一个问题：如何确保出版时的代码示例在转录到编辑器中后仍能实际运行。
他们写了一个工具，用来标记实时代码中的提取点，以便自动将其摘录到他的手稿中。
大约五年后，我在一家 F50 公司工作，那里有一群承包商都在“搞定事情”（Getting Shit Done），这让周围一些更官僚的部门感到有点紧张。有人觉得抓住了把柄，抱怨我们的开发者文档不符合公司制定的既定文档标准。他们没说错，但习惯于我们构建的平台的人根本不会被我们提供的文档难住。
如果我们按照他们的建议去做，每次发布都会增加我几乎一周的工作量，而我当时已经在为分配足够的工作量以避免自己成为瓶颈而挣扎。那额外的一周会让我们的速度降一个档次，让我们看起来和其他人差不多。这是一个巧妙的计谋，但 Bruce 救了我。
与其在每个版本发布时都费力更新文档，我发现 Bruce 的策略早在 […] 就已经被制定出来了。