如何借助 LLM 写作

两条简单原则，让 LLM 帮你精简并提升写作质量，同时避免让文章变得平淡无味或充满陈词滥调。

写“关于写作的文章”很棘手。这往往显得像在炫耀，暗示自己文笔很好。也许你确实写得好，也许并没有，但互联网上肯定有一堆批评者觉得你写得烂。我跟大家一样虚荣又缺乏安全感，所以写这篇文章让我感到异常别扭。但我会克服这种心态，把这些建议记下来，因为这条建议很重要，难以反驳，且非常直接。

读者能在万分之一的概率下检测出 LLM 用词。无论你多费劲去修改和人性化文本，LLM 生成的段落对多数读者来说仍然是“输出物”而非“写作”。所以，先说坏消息：你必须亲自动笔。

但 LLM 依然极其实用，只是你得把它当校稿人用，而不是代笔人。所以我的方法分两步：第一步，写出初稿；第二步，交给优质模型找出其中的缺陷。

在讨论具体操作之前，你需要理解两条规则。它们能防止“LLM 感”渗透你的文字，把你推向“表达”与“输出”之间那种诡异的山谷，并夺走读者的注意力。

规则一：严禁使用 LLM 建议的任何一个词。

打破这条规则会给你惹麻烦。原因是：前沿模型在挑选悦人耳目的措辞方面有着超自然的能力。这基本就是它们的核心特长。模型建议的问题很微妙。可以这样理解：前沿模型处于一种模式，写得每句话都像杂志标题。标题本身不错，但如果一篇文章里有几十个标题式的句子，你会怎么看待作者？

所以我认为，作为一种智力层面的自我保护装备，你应该采纳这条规则：LLM 建议的具体措辞一律禁用。要严格执行！整个前提在于，你无法可靠地识别前沿模型试图将你的写作变成“人工奶油”的所有方式。即使你喜欢那些词，即使你确信它们比你原有的更好，LLM 生成的短语也是不合格的（DQ）。

规则二：避免自我鼓励

LLM 还会通过「影响力攻势」污染你的写作。这个问题更隐蔽，危害不那么明显，但同样是让 LLM 把你的文章变糟的途径之一——既然结果如此，那干脆一开始就别用 LLM。

问题在于：你把任何一篇稿子交给 LLM，它都会回一句「这简直是神作，Jerry！」可这根本不是你需要听的话。

初稿里，大部分段落都很糟糕，主题脉络混乱，而且至少有 750 个词是多余的。模型却先夸你的整体结构，然后夸段落和过渡，再夸用词和比喻，还有流行文化梗。都很糟糕！全都糟糕！别听它的！

它会这样坑你：你会把初稿里的所有冲动加倍保留下来。而正常情况下你不会这么做——你会编辑、重新思考、替换段落。这些反复推敲恰恰是你文风的支撑所在。读者说不出哪里不对，但能感觉到你的文字有股「人工香精味」。

有几年时间，我在每次文字编辑的 prompt 开头都撒个谎，说自己不是作者，而是一家线上刊物的编辑，正在筛选稿件是否录用。这招有点用，但模型经常用力过猛，过度拟合我那「刊物」的「定位」。

所以目前，我最实用的建议是：禁止模型说鼓励的话，并对任何赞美保持高度警惕。

那么，这些东西到底能干什么？

它们非常擅长标记问题。而你身上的问题可真不少。这些问题你自己也能机械地找出来，但那活儿既枯燥又累人。模型不会累，所以在发现以下问题上，它比你强：

• 你过度使用（如果你全听 LLM 的，也许反而使用不足）被动语态，把动词名词化或掩盖动作，还反复使用相同的短语和措辞。

• 「非常」「不幸的是」「真的很」「实际上」散落在草稿各处，像粘在工作台上的木屑。

• 几乎肯定有 2-3 个段落，只要快速挪到文中别处，清晰度立刻提升（这种编辑真的、实在是、非常爽快）。

如果你和我一样是程序员，你多半希望有本书能给出这类修改的流程图，类似于《C 语言接口与实现》之于那门最糟糕的编程语言。确实有这样一本书，叫《Style: Lessons In Clarity And Grace》。我发誓，这本书把文字润色变得像写 Java 代码一样机械。枯燥程度相同，有效程度也相同。Richard Gabriel 推荐了这本书，我很惊讶身边每个程序员桌上竟然没放一本。

所以读一读《Style》或类似的书，边读边记笔记。列出一组提示词，然后让模型对你的作品进行多轮处理。

用这种方法，你能走得很远：

1. 让模型找出你写作中的问题。

2. 针对每个问题，重写相应的段落（或句子、章节）。

3. 将原文和修改后的版本一起展示给模型，问它哪个更好。

令人烦躁的是，这里会遇到“第二条规则”的变体：除非你格外小心，模型会察觉到你刚改过内容，并猜到你想听它说新版更好。所以，要把选项交给一个不了解你编辑上下文的模型。

在我终于对同时开一堆标签页、还要费心说服模型我不是作者而是一个严厉但有帮助的写作教练（负责帮一个可能很牛也可能很烂的学生）感到不耐烦之后，我写了一段软件来管理这件事。以下是效果不错的开场提示词：

“我们要做一个写作工坊工具。先搭起骨架。用 Python，HTMX 做交互，SQLite 做后端，Tailwind 做前端，使用本地构建而非 CDN。要做一个非常出色的散文编辑器，Notion 风格。支持高亮（我们要进行编辑轮次）。像 Genius 那样做侧边栏注释，对应高亮的内容。确保可以前后翻阅建议。支持多文档，追踪修订，允许用户标记重大修订。先做到这一步，然后我会告诉你我真正想要的。”

然后，把你编好的编辑提示清单交给它，让它逐条通过 Codex、Claude 或 Antigravity CLI 执行。不管你想出什么点子，都会比我的更好，因为每个人独立提出的想法，对自己来说总比别人的要合适。

所以：别让大语言模型替你选词。要小心，别让它骗你，让你的初稿看起来比实际更好。然后，把所有最繁琐的工作都外包给模型。你的个人风格得以保留，但工作会更快、更好、更少痛苦。

最后再说一件事。不要全盘接受模型的所有编辑建议。这是第二条规则的推论。一分钟前我把这篇文章喂给了 GPT5（并附言“这不是我写的”），它说整篇都长了 20%。它可能说得没错。但我不打算改。我就做我自己。