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 生成,可能有误。

    技术写作与文档2022news.ycombinator.com编辑精选

    Ask HN:如何提升你的技术写作水平?

    Ask HN: How to level up your technical writing?

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

    导读

    这是一位架构背景的工程师在 HN 上求助如何提升技术写作能力的帖子,高赞回复从“读者意识”“先搭结构再写句子”“日常练笔与叙事化表达”到具体课程与书目,给出了一套可操作的路径。对写作者来说,这些建议不只适用于技术文档,也能直接迁移到说明文、产品文档和任何“把复杂讲清楚”的写作中。

    关键词 技术写作读者意识结构大纲写作练习

    可以直接用的写作要点

    1. 01

      动笔前先想清楚读者是谁、他们遇到什么问题,写作目标是帮他们解决问题,而不是把信息记录下来。

    2. 02

      先把内容拆成标题、小标题(必要时再加一层),检查整体流程是否连贯、有没有缺失或该独立成篇的部分。

    3. 03

      用“标题结构 → 要点列表 → 图表占位 → 扩写成完整句子”的顺序推进,能显著降低写作阻力。

    4. 04

      别怕在干巴巴的技术文本里加入个性和具体例子,适度叙事能提高读者的阅读意愿。

    HN 评论精选

    写作前先锚定读者及其真实处境,成稿后找人编辑。

    技术写作者的第一条铁律是了解你的读者:不仅要知道他们的技术问题,还要花时间共情他们为什么会有这些问题。技术写作不是“记录文档”,而是找到最好的解释方式让人解决问题。另外,请找人(真人,不是软件)帮你编辑。

    marcpaq查看英文原文

    Tech writer here. The absolute, invariable first rule in tech writing is to know your audience. Understand not just their technical problems but take the time to empathize with why they have these problems in the first place. Tech writing isn't about documenting, it's about finding the best way to explain something to people so they can solve their problems. Oh, and use an editor (the human kind, not the digital kind.)

    先搭骨架、再填要点、最后写成句子,并适度保留个性与例子。

    写技术书时出版商给我的建议是:先把要写的内容拆成标题和小标题,甚至小标题的子级,再回看结构是否连贯、有没有缺章节或该拆出去的部分。我的流程是先用要点表达想法,插入图表占位和图注,最后把要点改写成完整句子、补充例子和过渡文字。关于“简短”,我大体同意,但视媒介而定,注入一点个性也无妨——技术文本容易枯燥,会劝退读者;尽量用具体例子或引用其他支撑材料。

    Gaessaki查看英文原文

    Lots of great advice here. One piece of advice I got from my publisher when authoring a technical book was to first break down what I was going write into headings and subheadings, and if possible, into sub-subheadings. Then review that to see if your flow is coherent and whether there are sections that are missing, or could be extracted into another text. Personally, my process after this is to express my thoughts in bullet points, followed by inserting any placeholders and captions for any graphics (e.g. charts or diagrams), and then finally I start rewriting my bullet points into proper sentences, expanding my examples, and adding any interstitial text necessary to make things flow. Also, I see some comments on keeping things short and to the point. In general, I agree with this, but depending on the medium, sometimes it doesn’t hurt to inject a bit of personality into your writing. Technical writing can be dry at times, and this can deter engagement. Try to use concrete examples whenever possible or refer to other supporting texts.

    系统学习可以借助成熟课程和写作改错类书籍。

    推荐两样东西:Google 的技术写作课程,以及《Bugs in Writing》这本书——我已经向人推荐了二十年。

    gnat查看英文原文

    Two things I recommend: the Google tech writing courses: https://developers.google.com/tech-writing And "Bugs in Writing", which I've been pressing into people's hands for twenty years now. https://www.amazon.com/BUGS-Writing-Revised-Guide-Debugging/dp/020137921X

    先动笔练习,并用“执行摘要+背景+正文”的叙事结构组织文档。

    我从高中进工学院时很羡慕文科朋友总有写论文的机会,后来意识到书面/技术沟通是巨大的差异化优势。我每天写日记,但针对这个问题我想说:先开始写。了解读者是关键:我通常在设计文档或需求文档开头放一段执行摘要,说明大家为什么要在意,然后交代背景和历史给上下文。归根结底这是一篇叙事,遵循类似的弧线,只是语言更直接、事实更具体。

    mishftw查看英文原文

    When I left high school for college (to pursue engineering) I was quite envious of my friends in the liberal arts - they were assigned papers all the time and I had no outlet for writing (something I enjoyed quite a bit). I have realized that written/technical communication is a great differentiator. I journal every day but specifically to your question I would say just start writing. Knowing your audience is key. I usually include an executive summary section at the top of any design document or product requirements document for a high level view of why people should care. Then I dive into a background or history to give context. At the end of the day it's a narrative and follows similar arcs - just with more direct prose and specific facts. I'll also drop this resource here from the Pragmatic Engineer newsletter. [0] [0]: https://newsletter.pragmaticengineer.com/p/software-engineering-rfc-and-design

    同类还值得读

    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

    关注向阳乔木

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

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

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