HN 写作课

工程师们二十年里聊过的写作。

工程师、作家、编辑和创业者在 Hacker News 上聊了二十年“怎么写”:怎么写得清楚、怎么讲好一个故事、技术文档怎么写、小说和出版是怎么回事。这里把其中关于写作与讲故事的帖子挑出来,配上中文导读、可以直接用的写作要点和评论翻译。

从必读开始
  • 2,600+篇关于写作的 HN 讨论

Writing tips

写作锦囊

正在抽一条写作要点…

Essential

必读 30 篇

在讨论库里看全部精选

编辑精选里 HN 讨论最热的 30 篇,每篇都有中文导读和写作要点。

  1. 正在载入…

Archive

讨论库

按发帖年份分布,点柱子筛选。

排序

    About

    这些讨论是怎么挑出来的

    1. 01

      从全量里捞

      读取 Hacker News 自 2006 年以来的全部帖子,用关键词先捞出 40 分以上、可能和写作有关的约 1.1 万篇。

    2. 02

      只留真正讲写作的

      由 AI 逐条判断是否和写作、讲故事、文风、出版有实质关系,剔除“写代码”“编辑器”这类字面撞车,并分进十个类别。

    3. 03

      提炼可用的要点

      为值得读的帖子写中文导读,提炼 2-4 条可以直接用到自己写作里的要点,并精选翻译 HN 高赞评论。内容由 AI 生成,可能有误。

    技术写作与文档2015archieml.org

    ArchieML:为人类可写性优化的结构化文本格式

    ArchieML is a structured text format optimized for human writeability

    阅读原文 HN 讨论
    67HN 得分
    13条评论
    4条写作要点

    导读

    这篇介绍 ArchieML——一种为「人写得顺手」而优化的结构化文本格式,常用于编辑室里把文档中的结构化数据抽出来。讨论既有对「简单即好」的赞赏(拿 INI 作比),也有对其「不报解析错误」策略的批评,还追问了它与 TOML 等现成格式的关系。对写作者来说,它提醒我们:格式本质上是人和机器之间的沟通契约,设计格式时要同时考虑写得顺手和错得可查。

    关键词 结构化文本格式设计可写性错误处理

    可以直接用的写作要点

    1. 01

      设计或选用格式时,优先考虑人手写的顺手程度,而不只是机器解析的便利。

    2. 02

      简单往往最好:INI 式格式说明,规则越少、越直白,越不容易写错。

    3. 03

      别把「不报错」当成「没错误」——结构写歪了却看起来像普通文本,问题只会在后面爆发,写作时要主动校验结构。

    4. 04

      引入新格式前先讲清它相对 JSON/YAML/TOML 解决了什么,否则读者第一反应就是「为什么不用现成的」。

    HN 评论精选

    批评「不报解析错误」的设计,认为隐藏错误只会在后期造成更大问题。

    「无结构的文本会被忽略;不存在解析错误这回事」——这是个天真且方向错误的做法,问题会在后面冒出来。如果结构被打错,以至于看起来像无结构文本呢?这个格式是有结构的,因此该格式的示例也可能出错。你不诊断错误,不代表错误不存在。

    kazinator查看英文原文

    > "Unstructured text is ignored; there is no such thing as a parsing error" That is a naively wrong-headed recipe for problems later down the road. What if structure is mistyped such that it looks like unstructured text? The format has structure, and consequently, examples of that format can be erroneous. Just because you don't diagnose errors doesn't mean they aren't there.

    简单格式(如 INI)往往最实用。

    让我有点想起 INI 文件。它们很好地证明了有时简单就是最好的。

    TazeTSchnitzel查看英文原文

    Reminds me a little of INI files. They are a good demonstration of how sometimes simplicity is best.

    质疑为何不与 TOML 比较,新格式应说明相对现有方案的优势。

    有意思的是,文中提到了 JSON 和 YAML,却没提 TOML。我更想听的是:为什么 TOML 不算一个够用的方案。

    burke查看英文原文

    Interesting that there's mention of JSON and YAML, but no mention of TOML. I'm more interested in hearing why TOML wasn't an adequate solution.

    同类还值得读

    1. 编写更好文档的框架

      A Framework for Writing Better Documentation

      这是 Divio 的文档写作框架,把技术文档按「读者的目标」分成四类:教程(学习导向)、操作指南(问题导向)、参考(信息导向)、解释(理解导向)。

      技术写作与文档2021 · 637 分 · 76 评4 条写作要点编辑精选
    2. 写好一份设计文档

      Writing a good design document

      这篇 HN 帖子标题为《Writing a good design document》,主题是如何写好一份设计文档;对写作者来说,它值得作为技术写作和结构化说明文的参照。

      技术写作与文档2025 · 581 分 · 147 评3 条写作要点编辑精选
    3. 技术写作课程

      Technical Writing Courses

      这是 Google 官方免费技术写作课程(两门),讲受众定义、主动语态、短句、文档结构等基础方法。

      技术写作与文档2020 · 571 分 · 73 评4 条写作要点编辑精选
    4. 写出更好的错误信息

      Write better error messages

      这篇帖子讨论如何写出更好的错误信息,评论补充了开发者场景下的具体做法和真实反面案例。

      技术写作与文档2022 · 566 分 · 253 评4 条写作要点编辑精选
    5. 写一本技术书的经济账

      The Economics of Writing a Technical Book

      一位技术书作者拆解写书的真实经济账:版税收入往往远低于投入的时间成本。

      技术写作与文档2018 · 519 分 · 149 评4 条写作要点编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。