如何使用大语言模型写作

Hacker News Top 新闻

摘要

本文提供了在写作中使用大语言模型的两个关键规则:避免使用模型建议的任何词语,并忽略保持真实声音的鼓励。

暂无内容
查看原文
查看缓存全文

缓存时间: 2026/09/18 00:15

# 如何与大语言模型协作写作 来源:https://sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/ **两条简单规则,让大语言模型精简并提升你的写作,而非将其过度加工、注入糖浆。** 讨论写作技巧本身就充满风险——这像是炫耀,暗示自己写得好。或许确实如此,但互联网上总有一群批评者认定你写得糟糕。和所有人一样,我也虚荣且缺乏安全感,写这篇文章让我感到莫名的不适。但为了重要的建议,我克服了这种心理,因为这些观点至关重要、无可辩驳且简单直接。 读者能以万亿分之一的精度识别出大语言模型生成的文字。无论你如何费力打磨、人性化处理,模型生成的段落在多数读者眼中并非真正的写作,而是机械输出。所以首先有个坏消息:你必须为自己而写。 但大语言模型依然极具价值——只是需要将其视为文字编辑而非代笔人。我的方法第一步:先写出文章初稿。第二步:交给优质模型寻找缺陷。 但在探讨具体操作前,你需要理解两条核心规则。它们能防止大语言模型的渗透将你拖入"表达"与"输出"之间的恐怖谷,让读者失去兴趣。 **规则一:绝不使用大语言模型建议的任何一个词** 违反此规则会让你陷入麻烦。原因在于:前沿模型异常擅长挑选悦耳的措辞——这几乎成了它们的本能。但模型建议的问题极其微妙。不妨这样理解:前沿模型始终处于"杂志标题模式"。标题固然精彩,但若有人整篇文章写满标题,你定会感到诧异。 因此,我建议你采用这条自我保护准则:任何大语言模型建议的具体措辞都必须舍弃。务必严格执行!核心前提在于:你无法可靠识别前沿模型试图将你的写作变成"加工奶酪"的所有方式。即便你喜欢这些词,即便确信它们优于现有表达,由大语言模型生成的措辞也必须**不合格**。 **规则二:警惕鼓励性反馈** 大语言模型还会通过"影响力攻势"污染你的写作。这种问题更为隐蔽,危害看似不明显,但仍是让大语言模型损害写作质量的途径。如果注定如此,还不如不使用大语言模型。 问题在于:将任何文章交给大语言模型,它总会回复"太棒了,杰瑞!"。但这根本不是你需要听到的反馈! 初稿阶段,你的多数段落质量堪忧,行文逻辑混乱,且至少有750字属于赘余。模型会肯定你的整体结构;接着夸奖段落衔接;随后赞扬用词和隐喻;甚至评价流行文化引用——全都很糟糕!别被迷惑! 这种鼓励会害你深陷其中。你会加倍坚持初稿的所有冲动,而非如常进行编辑、重构和段落替换。这些思考过程承载着你独特的文风。读者或许说不出具体问题,但会察觉到那不自然的"人工香精味"。 过去几年,我曾在每条编辑提示中谎称自己是在线刊物的编辑而非作者,负责筛选投稿文章。这有所助益,但模型常常过度解读,过度贴合我所谓"刊物"的目标。 因此目前最实用的建议是:禁止模型给予鼓励,并对一切赞扬保持高度警惕。 **那这些工具究竟能做什么?** 它们擅长标记问题——天知道你的文章有多少问题。你本可以机械排查,但那是枯燥耗神的工作。模型不会疲倦,因此在以下方面比你更敏锐: - 你过度使用(或若完全听信模型则可能不足使用)被动语态,将动词名词化或隐藏其动作,且重复相同句式或词汇 - 草稿中如锯末般散落着大量"非常""不幸的是""确实""实际上" - 几乎肯定有2-3个段落可通过快速调整位置瞬间提升清晰度(这类编辑真正令人满足) 如果你和我一样是程序员,或许曾渴望有本书能提供这类编辑的范式,如同《C语言接口与实现》为糟糕的编程语言所做的那样,为散文写作提供系统方案。确实存在这样一本书——它叫《风格:清晰与优雅的写作课》。我发誓它让文字编辑变得如同编写Java代码,同样的繁琐,同样的高效。我是从Richard Gabriel处得知此书的,惊讶于我认识的程序员桌上竟没有一本。 所以请阅读《风格》或类似著作,边读边做笔记。整理出针对模型的提示词清单,然后分段运行编辑程序。 你可以通过这个流程取得显著进展: 1. 让模型识别你文章中的问题 2. 针对每个问题重写段落(或句子/章节) 3. 将原文与改写内容交给模型,请它判断优劣 恼人的是,此处你又会遭遇规则二的变体——除非特别谨慎,模型知道你刚改写了内容,且想听到新版本更好的结论。因此请将比较选项交给一个不掌握你编辑过程上下文的模型。 在我终于厌倦于切换标签页、试图说服模型"我并非作者,而是严厉但热心的写作教练,正在指导一个可能优秀也可能糟糕的学生"之后,我编写了一个小工具来管理这个流程。以下是效果不错的起始提示: *"我们将构建一个**写作研讨工具**。先搭好基础框架:Python,用HTMX处理交互,SQLite数据库,Tailwind前端界面,使用本地构建而非CDN。打造一个出色的文本编辑器,类似Notion风格。支持高亮功能(用于编辑批注)。采用类似天才注释的侧边栏评论匹配高亮内容。确保可前后浏览建议。支持多文档、版本追踪,允许用户标记重大修改。先完成这些基础功能,我再告诉你具体需求。"* 运行编辑批注的研讨工具 然后将你整理的编辑提示词清单交给工具,让它通过Codex、Claude或Antigravity的命令行界面逐条运行。你在这里设计的方案肯定会优于我的版本,因为任何自主设计的工具都比别人的工具更适合自己。 总结:别让大语言模型挑选你的用词。警惕它诱使你高估初稿质量。然后将所有枯燥的编辑工作外包给模型。你的文风得以保持,作品更快、更好、更轻松。 最后提醒:别全盘接受模型的文字编辑建议。这是规则二的推论。我刚将本文交给GPT5("声明:此文非AI所写"),它说文章整体冗长20%。或许正确。但我不打算修改——我就做我自己。

相似文章

如何使用LLM写作

Simon Willison's Blog

本文介绍了Thomas Ptacek提出的规则,即使用LLMs作为文案编辑时,永远不要采用LLM建议的短语,以维护原创性和写作纪律。

在添加LLM之前要问的六个问题

Hacker News Top

本文主张不应盲目采用LLM,并提出了六个问题来评估LLM是否适合特定工作流程,强调LLM以确定性换取灵活性,仅在必要时才应使用。

为了内容而内容

Armin Ronacher

作者探讨了LLM如何影响编码和日常语言中的用词,发现LLM偏好的词汇在编程会话和Google Trends中出现的频率均有所增加,这引发了人们对人类开始采用LLM写作风格的担忧。