两条简单规则，让 LLM 帮你精简和改进写作，而不会把你的文字巴氏消毒、再灌满玉米糖浆。
写关于写作的文章很棘手。它看起来像在自夸；你是在暗示自己写得好。也许你确实写得好，也许并不，但互联网上肯定有一群批评者认为你写得很烂。我和其他人一样虚荣又缺乏安全感，写这篇文章让我觉得莫名地不愉快。但我还是放下自我，把它写下来，因为这个建议很重要、很难反驳，而且直截了当。
读者能在万亿分之一的水平上察觉出 LLM 的文字。无论你花多少功夫去打磨、让它更像人写的，一段 LLM 生成的文字在你的许多读者看来都不是写作，而是输出。所以，先说坏消息：你必须自己写。
但 LLM 仍然极其有用。只是你需要把它们当作文字编辑，而不是代笔。所以，我方法的第一步：写出你的文章。然后，第二步：把它交给一个好的模型，让它找出缺陷。
但在我们讨论这如何运作之前，有两条规则你需要理解。它们会防止 LLM 蔓延，这种蔓延会把你推入表达与输出之间的恐怖谷，并让你失去读者的注意力。
规则一：LLM 向你建议的任何一个词，你都不能用。
违反这条规则就会让你陷入麻烦。原因是：前沿模型在挑选讨喜的措辞方面好得近乎超自然。这差不多就是它们的看家本领。模型建议的内容问题很微妙。这样想吧：前沿模型被卡在一种模式里，它们写的一切都像杂志标题。标题很好，但要是有人写一篇文章，里面塞满几十个标题，你会觉得这人有点问题。
所以我认为，作为一种智识上的个人防护装备，你应该采纳这条规则：LLM 建议的任何具体措辞都不得使用。严格执行这条规则！这里的前提是，你无法可靠地识别出前沿模型会试图把你的写作变成 Velveeta 奶酪的所有方式。即使你喜欢那些词，即使你确信它们比你已有的更好，LLM 生成的短语也一律取消资格。
规则二：避免鼓励
LLM 还会通过影响力宣传来感染你的写作。这是一个更微妙的问题，损害也没那么明显，但它仍然是 LLM 让你的写作变差的一种方式；如果结果会是这样，那你干脆别用 LLM 了。
问题在于：把任何一篇文章交给 LLM，它都会回复“这真是金子，Jerry！”但那不是你需要听到的话！
在你的初稿里，大多数段落都很糟，主题流不连贯，而且你至少有 750 个词是多余的。模型却会就你的整体结构鼓励你。然后，接着是段落和过渡。再然后是措辞和隐喻。流行文化梗。它们很糟！全都糟！别听！
以下是这会如何坑害你。你会加倍坚持所有初稿的冲动。但这通常不是你会做的事。你会编辑、重新思考并替换段落。那些重新思考是你声音的承重部分。读者不会指出哪里不对，但他们会感觉到你变得人工调味了。
有几年，我在每个复制编辑提示开头都撒谎说我不是作者，而是一家在线出版物的编辑，筛选作品以供收录。这有帮助，但模型通常会过度，过度拟合我的“出版物”的“目标”。
所以目前，我最好的实用建议是：禁止模型鼓励，然后对赞美保持高度警惕。
那么，这些东西能做什么？
它们非常擅长标记问题。天哪，你有很多问题。你可以机械地发现它们，但那是乏味且令人疲惫的工作。模型不会累。所以它们比你更擅长注意到：
-你过度使用（或者，如果你全信LLM的话，可能使用不足）被动语态，将动词名词化或埋没其动作，并重复相同的措辞或词语选择。
-你的草稿中到处散落着“very”、“unfortunately”、“really”和“actually”，就像工作台上粘着的锯末。
-几乎肯定有2-3个段落，你可以快速移到文章中其他地方，立即提高清晰度（这些是真正、确实、非常令人满意的编辑）。
如果你像我一样是程序员，你希望有一本书为这类编辑提供示意图，一种“C Interfaces And Implementations”，为散文做Hanson为最伟大的糟糕编程语言所做的事。而且：确实有那本书。它叫“Style: Lessons In Clarity And Grace”，我向上帝发誓它把复制编辑变成Java编码。完全相同的乏味，完全相同的有效性。我从Richard Gabriel那里得知这本书，我惊讶于我认识的每个程序员桌上都没有一本。
所以读“Style”，或类似的东西，并边读边做笔记。为模型列出一系列提示，然后对你的作品进行多轮运行。
用这种方法你可以走得很远：
-让模型发现你写作中的问题。
-对于每个问题，重写段落（或句子，或部分）。
-将原始和新写作呈现给模型，问它哪个更好。
烦人的是，这里你遇到规则二的变体，因为除非你小心，模型知道你刚重写了东西，并知道你想听到新版本更好。所以把选项给一个没有你编辑过程上下文的模型。
在我终于失去耐心，不再 juggling 标签页并试图说服模型我不是作者，而是一个有帮助但严厉的写作教练，试图帮助一个可能好也可能糟糕的学生后，我变出了一些软件来为我管理这个。这里有一个效果很好的开场提示：
“我们要构建一个写作工作坊工具。先把骨架搭起来。用 Python，交互用 HTMX，后端用 SQLite，前端用 Tailwind，使用本地构建而不是 CDN。要一个真正出色的散文编辑器，Notion 风格。支持高亮（我们要做编辑轮次）。做 Genius 风格的侧边栏评论，与高亮的内容对应。确保我们能在建议之间前后切换。支持多个文档、跟踪修订、允许用户标记重大修订。先把我带到这一步，然后我再告诉你我真正想要什么。”
然后，把你想到的那份编辑提示词清单交给这个东西，让它把每一条都通过 Codex、Claude 或 Antigravity 的 CLI 跑一遍。你在这里想出的任何东西，都会比我的更好，因为任何人自己想出来的东西，对他们自己来说，都比别人给的要好。
所以：不要让 LLM 替你选词。小心别让它骗得你以为自己的初稿比实际更好。然后把所有最枯燥的工作外包给模型。你的声音保持完整，但你的工作会更快、更好、更少痛苦。
最后一件事。不要全盘接受模型的所有文字编辑建议。这是第二条规则的推论。我刚刚把这篇文章喂给了 GPT5（“这不是我写的”），它说整篇东西长了 20%。它大概是对的。但我不改。我就做我自己。