写作方法2018isittoasted.com
Show HN：预测读者会如何回应你的文字
Show HN: Predict how well people will react to your writing
导读
这是一个根据目标读者预测你的文字会被怎样接受的写作反馈工具（Show HN 发布），评论区集中了真实用户对它的实测反馈。对写作者来说，它既展示了"按读者群改写措辞"这一思路的价值，也暴露了只改单词、不看语境的做法有多容易翻车，还顺带提供了落地页文案该怎么演示产品的范例。
可以直接用的写作要点
- 01
只做单词级替换的"优化"很容易出笑话：把 carry out the attack 里的 attack 改成 defense、把 grow 改成 better，都说明脱离上下文的措辞建议不可信，改稿时先问"这个词在句子里到底在干什么"。
- 02
想让读者群买账，光换词不够——技术类文章在各类读者眼里都只被评为"average"，说明决定接受度的是结构、信息密度和例子，而非个别词汇。
- 03
介绍自己的产品（或任何写作）时要当场演示效果，而不是只用一句说明带过：放一段口语化说明＋几版不同受众（商务、学生、技术）的改写对比，比任何形容词都有说服力。
- 04
如果你的写作不是核心技能而是工作刚需，投入工具提升它是划算的；但要选能嵌进你日常写作场景（编辑器、邮件、文档、代码注释）的那种，否则再好的建议也不会被用起来。
HN 评论精选
专业内容营销人实测后认为工具不实用，单词级替换常有错译或同词替换，且好文章被一律评为"average"。
我作为技术垂类的内容营销从业者，大概算你们的典型用户，所以认真试了一遍。我拿一篇典型的宽泛商业文章来测，反馈是：并排视图像开发者工具（Markdown/HTML 预览那种），粘贴后其实只看右边，没什么必要；"匹配度"评分条不够醒目、信息量也不足；这篇讲软件 bug、Kerberos 的文章，在所有目标读者群里都只被评为"average"；有些替换完全是错的，比如建议用 attacks 替换 defenses；还有些替换前后是同一个词，比如建议用 security 换 security；下拉框里的颜色深浅似乎有含义，但我并不确定具体怎么用；目标读者分类有点奇怪（我猜这更多取决于你训练数据的来源），建议多做一些垂直领域。总体是有趣的实验，但在专业场景里似乎没什么用——我怀疑这里有个隐含假设：定义文章的是具体用词。
michaelbuckbee查看英文原文
I tried to give this an extensive run through as I think I'm in your future target market for this (content marketing professional in a technical vertical). I used it to evaluate the text of this article [1], which is a pretty typically broad business type article (aka not "Here's how to use XYZ.js"). Feedback - The side by side view feels like a developer thing. Like a markdown editor or HTML/CSS preview editor. I'm not sure it serves a purpose here as you only ever look at the right side after you paste in text. - The "rating" bar for "fit" isn't prominent enough and doesn't convey enough useful information. - Despite this being an article about software bugs, Kerberos, etc. it was rated as only "average" by every single target group. - Some of the substitutions were just wrong. Example, it suggested "attacks" as a replacement for "defenses." - Some of the substitutions were the same? Example, it suggested "security" for "security." - I think the coloring gradations have some meaning in the drop downs, but I'm honestly not sure exactly how it works (pinker is closer to what your target?) - Target categories are odd (I'm presuming that this was more just about where you pulled training data from than anything else), but I'd encourage more verticals. Overall, I think this is an interesting experiment but doesn't seem useful in a professional context. In particular, I think there may be an assumption at work here that it's the specific word choices that define the differences in writing for these various groups, when in fact it's much more the approach, what's considered, or what's left out that really makes the difference. 1 - https://www.varonis.com/blog/zero-day-vulnerability/
三个具体反例说明：脱离上下文的单词替换建议会把原意改错。
我拿自己的一篇博客试了，它评为"average"，给出的都是单词级修改，而且在语境里根本讲不通。比如：在"in order to carry out the attack"里建议把 attack 改成 defense；在"ifconfig gives helpful statistics"里建议 helpful 改成 supportive；在"expect [a number] to grow continuously"里建议 grow 改成 better。想法挺酷，但对我来说效果不好。
jstanley查看英文原文
I tried this out on one of my blog posts, and it classified it as "average", suggesting only single-word corrections that don't even make sense in the context. A few examples: It suggested changing "attack" to "defense", in "in order to carry out the attack". It suggested changing "helpful" to "supportive", in "ifconfig gives helpful statistics". It suggested changing "grow" to "better", in "expect [a number] to grow continuously". So while it's a cool idea, I'd say it didn't seem to work very well for me.
写作是工程师的工作刚需但非核心能力，工具的价值在于能嵌入日常写作场景（编辑器、邮件、代码注释）。
我很喜欢这类工具，以前也是 Grammarly 订阅用户。可惜我现在的雇主对用 SaaS 处理工作文档有严格限制。这工具能不能做成 Chrome 插件？我大部分写作都发生在自托管编辑器里，比如 Quip、Jira、wiki。至于邮件、README、代码注释这类写作，我愿意在插件之间来回切换。写作是软件工程师工作的核心组成部分，却不是我们的核心能力，所以能提升写作的工具是有直接价值的。
lumost查看英文原文
I love these types of tools and used to be a grammarly subscriber. Unfortunately my current employer has strict rules on using saas apps for work documents. Any chance this tool could be embedded as a chrome extension? Most of the writing I do is on Self hosted editors such as quip, jira, wikis. For most of my other writing such as email, readmes, and code comments I'd be willing to hop back and forth to the extension As writing is a core component of my job as a software engineer - but not a core competency. there is a direct value proposition in tools that enhance my writing ability.
产品介绍页应该当场演示改写效果，用不同受众风格的版本对比来证明价值。
落地页本该是展示工具实际效果的好机会：顶部放一段口语化的说明（比现在那句稍长一点），底部用不同字体展示几版不同风格的改写（商务、学生、技术圈），让人看到工具到底在做什么。再加一个醒目的示例链接，我就被说服了。换句话说：需要更有排面！
DanSmooth查看英文原文
Landing-page would have been a great opportunity to show the effects of the tool in action. Have a casual-text (a slightly longer version of what is stated there now) that explains it at the top and display different versions (utilizing different fonts) that use other lingo (i.e.: business, student, techies) at the bottom to show what the tool is actually doing. Add a prominent link to the examples, to show the actual tool in action, and I'm sold. Or to phrase it another way: Shit needs more bling!
同类还值得读
被低估的工程技能：把文章写好
Undervalued Engineering Skills: Writing Well
这篇文章讨论为什么“写得好”是被低估的工程能力，以及它如何在团队协作、系统设计和职业发展中持续带来回报。
写作方法2019 · 1,109 分 · 371 评4 条写作要点编辑精选每行只写一句话：让写作和修改都更轻松的排版法
Writing one sentence per line
这是 Derek Sivers 的一篇短文，主张写作时每行只放一个句子，而不是按段落排版。
写作方法2022 · 849 分 · 297 评4 条写作要点编辑精选书面沟通是远程工作的超级能力
Written communication is remote work super power
这篇文章讨论远程工作中书面沟通的价值，评论区则补充了异步与同步沟通的适用场景，并提醒读者：备忘录、结论先行、结构化命令格式等书面沟通传统早已有之。
写作方法2020 · 831 分 · 190 评4 条写作要点编辑精选如何写出有用的文字
How to Write Usefully
保罗·格雷厄姆在这篇文章里给"有用的写作"下了一个可操作的公式：有用≈重要×新颖×正确×清楚，任一项为零，整篇文章就等于零；他还主张敢下确定判断、删掉让自己心虚的句子。
写作方法2020 · 821 分 · 285 评4 条写作要点编辑精选如何写得更清楚、想得更清楚，并学会复杂材料（PDF）
How to write more clearly, think more clearly, and learn complex material [pdf]
这份 PDF 讨论如何把文章写清楚、把思路理清楚，并用写作来学习复杂材料。
写作方法2022 · 779 分 · 153 评4 条写作要点编辑精选