从1986年飞机手册到AI提示词：5条Anti-Slop写作规则

先问一个很实际的问题：你有没有遇到过这种情况——用 AI 生成技术文档、教程甚至代码注释时，它写得“看起来很流畅”，但读完发现没有一句能直接用的？

这不是你的错觉。在 AI 内容创作越来越普及的今天，大量 AI 生成的内容正在变得高度同质化、信息密度极低、结构永远“三段式”、结尾永远是“综上所述”。这类内容在英文互联网里被称为Slop，对应的中文语境就是“AI 味”“流水线文章”“废话文学”。

我在调试自己的写作系统时，反复和这个问题较劲。最后真正让我把“Anti-Slop”想明白的，不是某本写作教材，也不是知乎高赞回答，而是一本1986 年出版的飞机维修手册。

这篇文章会完整拆解：

• 什么是 Slop，它为什么泛滥；
• 1986 年的飞机手册为什么没有一丁点 Slop；
• 从手册里提炼出的 5 条可执行的反 Slop 写作规则；
• 如何把这些规则写进 AI 提示词，让 AI 替你产出“能直接用的内容”。

如果你经常用 AI 写技术文档、写教程、写 prompt，或者你自己就是技术博主，这篇内容值得读完。

1. 先搞清楚：Slop 到底是什么

1.1 Slop 的定义与来源

Slop 这个词在 2024 年开始被广泛用来形容 AI 生成的低质量内容。它最初是指那些明显由生成式 AI 批量生产、缺乏人工校对、内容空洞且带有强烈模板痕迹的文本、图片或代码。

这里的核心不是“AI 生成”，而是“低质量”。我自己判断一段内容是不是 Slop，通常看三个特征：

1. 信息密度极低：一句话能说清的事，用三段话来铺垫；每段话都是正确的废话。
2. 结构高度模板化：开头“随着科技的发展”，中间“值得注意的是”，结尾“综上所述”。不同主题的文章，换个关键词就能互相替换。
3. 缺少可验证的动作：通篇没有“运行这个命令会得到什么结果”“如果报这个错说明什么”，全是抽象的描述。

换句话说，Slop 是“看起来像内容，但实际不承载信息”的文本。

1.2 为什么 AI 特别容易产出 Slop

AI 内容容易变得 Slop，不是模型“笨”，而是它的生成机制决定的。

大语言模型本质上是一个概率系统：它根据前文预测下一个最可能的词。在这种机制下，模型天然偏向生成语义连贯但信息量安全的内容。所谓“信息量安全”，就是那些在语料库中出现频率高、不冒犯任何人、不引入具体风险的表达——比如“值得注意的是”“在当今数字化时代背景下”。

因为模型没有真正执行过它写出来的步骤，它不具备后果意识。一个人类工程师写“执行 rm -rf”时会本能地警惕，因为删错了文件是要承担后果的；但 AI 没有这个约束，它只知道这两个命令经常出现在一起。

所以 Anti-Slop 的本质，不是单纯地“让 AI 少说废话”，而是给生成内容建立约束和验证闭环。

1.3 为什么开发者更需要 Anti-Slop

有人可能觉得，Slop 只是文章难看点，不是大问题。但在技术领域，Slop 的危害远不止“难看”。

当 AI 生成的代码、配置、部署步骤被直接抄进生产环境时，Slop 特征就意味着高风险：

• 代码看着逻辑完整，但没有处理边界条件；
• 配置项看起来合理，但和实际版本不匹配；
• 部署步骤缺少验证环节，执行到一半才发现环境不对。

低信息密度的文档，比没有文档更危险。因为读者会默认“写出来的都是经过验证的”，然后照着执行。这也是为什么我后来专门研究 anti-slop 的落地方法——它不只是写作技巧，更是一种工程素养。

2. 一本 1986 年的飞机手册，为什么没有 Slop

2.1 手册的背景与定位

这里要说的不是某个网红出版物，而是一本典型的飞机维护手册（Aircraft Maintenance Manual, AMM），出版年份正好是 1986 年。那个年代的飞机手册，普遍遵循 ATA 100 规范来组织内容。

ATA 100 是美国航空运输协会（Air Transport Association）制定的技术文档标准，把飞机所有系统按数字编号分类，比如 ATA 21 是空调系统，ATA 29 是液压系统，ATA 32 是起落架。每本手册按章节拆分成成百上千个“任务（Task）”，每个任务描述一个完整的维护动作。

有点意外的是，我最初拿到这类手册是为了查一个老机型的液压系统参数，结果读着读着发现：它的写作方式和我平时见到的技术博客、AI 生成内容完全是两个物种。

2.2 手册写作的三个核心特征

第一，每个任务都按照固定流程展开：准备（Preparation）→ 程序（Procedure）→ 收尾（Close-Up）。准备里写清需要的工具、耗材、资质要求；程序里按编号列出操作步骤；收尾里写清清点工具、恢复系统、做功能测试。

第二，每条指令都有验证动作。手册里很少出现“检查是否正常”这种模糊表述，取而代之的是“确认压力表读数为 3000±100 psi”“确认指示灯熄灭”这样可以直接判定结果的说法。

第三，条件和后果被显式声明。什么时候能执行这个任务、执行前必须满足什么条件、如果不按顺序执行会导致什么后果，手册里全部写得明明白白。

那个年代没有模板化的 AI 工具，每一句都要经过工程师编写、同行评审、适航审定。每一个字都可能被打印出来，由机务人员在嘈杂的机库里照着执行。这种“必须为后果负责”的写作环境，天然是 anti-slop 的。

2.3 为什么年代反而成了优势

有人会问：1986 年的手册，会不会是因为那时技术内容本来就简单？

恰恰相反。那个年代的手册虽然没有今天的交互式电子技术出版物（IETP）那么花哨，但正因为没有多媒体、没有超链接，所有信息必须通过文字精确传达。同时，飞机维护是强监管行业，手册必须通过适航当局审定，写错了就是安全事故。

这个背景给了我们一个非常重要的启发：判断内容质量的标准，不是它读起来是否流畅，而是照着做是否能得到预期结果。

这个标准，比任何文风建议都更硬核。它就是 anti-slop 的终极验收标准。

3. 从飞机手册里提炼的 5 条 Anti-Slop 规则

接下来我把读手册时最有感触的 5 个特征，转写成可以用于日常技术写作和 AI 提示词的规则。

3.1 规则一：先写目标，再写过程，最后写验证

飞机手册里每个任务，第一句一定是“本次任务的目标是拆卸/安装/测试哪个部件”，绝不会从“随着航空工业的发展”写起。

技术写作对应写法：

• 第一句告诉读者：做完这件事能得到什么结果。
• 中间写步骤：每条步骤以动词开头，描述动作。
• 最后写验证：如何确认结果正确。

这条规则对 AI 提示词同样适用。如果你让 AI 写“Python 读取 CSV 的教程”，它大概率会从“CSV 是一种常见的数据格式”开始。但如果你定义好“目标-过程-验证”，它就必须从“最终交付一个读取 CSV 并打印每行数据的可运行脚本”开始。

3.2 规则二：每条指令都必须能被验证

手册里几乎找不到“确保连接可靠”这种话，因为“可靠”不是一个可观察的标准。手册会写“拧紧力矩 25 lbf·ft”“确认保险丝安装到位”。

对应到技术写作，我们要把模糊动词替换成可测量动作：

这个原则用在 AI 提示词里，可以直接杜绝大量“看起来对但无法执行”的内容。因为 AI 一旦被要求写“可验证的指令”，它就必须把模糊表达转成有明确判定标准的语句。

3.3 规则三：删除一切不承载信息的词

飞机手册篇幅有限，每多一个词都意味着制图、校对、翻译成本的增加。所以手册里几乎不会出现“值得注意的是”“众所周知”“在一定程度上”这类填充词。

我在写文章时给自己定了一个硬指标：每句话必须比前一句话提供更多信息，否则删掉。这个指标同样可以塞进 AI 提示词里。

一些常见的应删词：

• “值得注意的是”——读者自己会判断哪些值得注意；
• “综上所述”——如果正文已经讲清楚了，这四个字不增加信息；
• “随着技术的发展”——对具体的操作步骤没有任何帮助；
• “在当今时代背景下”——无信息量，只占字数。

3.4 规则四：风险与边界条件要显式声明

飞机手册里，“警告（WARNING）”“注意（CAUTION）”“提示（NOTE）”三个层级被严格区分。什么操作可能致命、什么操作可能损坏设备、什么操作只是提供补充信息，读者一眼就能分辨。

技术写作对应写法：

• 如果某条命令可能损坏数据，必须在执行前用加粗或警示文字声明；
• 如果某段代码只适用于特定版本，必须写版本范围；
• 如果某个方案存在替代方案，需要说明适用条件。

把这个规则交给 AI，它就会主动在代码前标注“该命令会清除所有未提交的更改”这类关键信息，而不是让你在踩坑之后才发现。

3.5 规则五：读者永远不需要“猜”

1986 年的手册里有一个细节：所有零件编号都精确到厂家编号，所有工具都写规格，所有参数都写单位。为什么？因为机务人员不会去猜“合适的扳手”是多大，手册必须消除一切歧义。

在技术写作里，对应的是：给出精确的依赖版本、路径、命令、预期输出。

比如：

• 不要写“安装较新版本的 Node.js”，要写“Node.js 18.x 及以上版本”；
• 不要写“修改配置文件”，要写“打开config/application.yml，将第 47 行的端口号改为 8080”；
• 不要写“运行测试”，要写“在项目根目录执行mvn test，预期 12 个测试全部通过”。

这个原则直接决定了你的文章、文档或 AI 提示词输出是“教程”还是“散文”。

4. 实战案例：同一主题，Slop 版 vs Anti-Slop 版

理论说了一堆，我们来做一个直观对比。主题是“用 Python 读取 CSV 文件”。我故意先给一个 AI 默认会生成的 Slop 版，再用手册原则改写成 Anti-Slop 版。

4.1 Slop 版示例

在数据处理的过程中，CSV 文件是一种非常常见的数据存储格式，它以其简单易用的特点，在各种应用场景中得到了广泛的使用。在处理 CSV 文件时，Python 提供了一种非常方便的方式，这使得我们能够快速地对 CSV 数据进行读取和操作。 首先，我们需要导入 Python 内置的 csv 模块。需要注意的是，csv 模块是 Python 标准库的一部分，因此不需要额外安装任何依赖包。这为我们的开发工作提供了极大的便利。 接下来，我们使用 csv.reader 读取文件中的数据。csv.reader 可以接收一个文件对象，然后逐行返回 CSV 文件中的数据。这种方法非常直观，并且在大多数情况下都能满足我们的需求。 最后，我们对读取到的数据进行遍历，并打印到控制台。整个流程相对简单，通过上述步骤，我们就完成了对 CSV 文件的读取操作。总之，利用 Python 的 csv 模块读取 CSV 文件是一个高效且简便的解决方案。

这段话有没有错？语法没错，常识没错。但它是不是 Slop？是。

为什么？信息密度太低。读者从头读到尾，只获得了一个有效信息：“用 csv.reader”。具体代码长什么样？没有。文件路径怎么传？没有。编码问题怎么处理？没有。运行结果是什么？没有。

读者看完，依然不知道怎么把 CSV 读进来。

4.2 Anti-Slop 版示例

下面用手册的 5 条规则重写：

目标：读取 data.csv 中的全部行，并将每行以列表形式打印到控制台。 适用环境：Python 3.8+，无第三方依赖。 步骤： 1. 在项目目录下确认存在 data.csv 文件。文件第一行应为列名。如图： name,age,city Alice,28,Beijing Bob,32,Shanghai 若文件不存在，执行下面的命令创建： echo "name,age,city" > data.csv 2. 新建 read_csv.py，写入以下代码： import csv with open("data.csv", newline="", encoding="utf-8") as f: reader = csv.reader(f) for row in reader: print(row) 3. 在项目根目录执行： python read_csv.py 4. 验证：预期输出如下。若第 3 步报 UnicodeDecodeError，说明文件编码不是 utf-8，将 encoding 改为文件实际编码。 ['name', 'age', 'city'] ['Alice', '28', 'Beijing'] ['Bob', '32', 'Shanghai'] 注意：open 中必须传 newline=""，否则 CSV 字段内换行会被错误解析。这是官方文档明确规定的坑。

4.3 拆解修改点

把第一个版本改成第二个版本，核心改变了四个地方：

第一，从“介绍”改为“目标”。Anti-Slop 版第一句就告诉你做完后得到什么结果，而不是从“CSV 是一种常见格式”开始。

第二，从“描述”改为“步骤”。Anti-Slop 版给出了完整的代码，并解释了newline=""这个关键参数，还留了灾后处理方案。而 Slop 版只提到“使用 csv.reader”，没有给出实际如何打开文件。

第三，增加了验证环节。Anti-Slop 版明确写出预期输出，读者能对照检查自己的执行结果。如果用 utf-8 报错，也有处理路径。

第四，风险说明显式化。newline=""是 Python 文档里明确提到的坑，很多教程要么不提，要么一笔带过。Anti-Slop 版专门用“注意”标注。

对比一下就不难理解，为什么很多人看 AI 写的教程会觉得“都对，但没用”——因为缺少范围、路径、代码和验证结果这些关键信息。

5. 把 Anti-Slop 规则写进 AI 提示词

看到这里，你应该能意识到：Anti-Slop 不只是一种阅读品味，更是一种可以工程化的写作约束。而对普通开发者来说，最直接的落地方式就是把它写进 AI 提示词。

5.1 一份可复制的 Anti-Slop 提示词模板

下面是我现在常用的一个模板，它把前面 5 条规则全部编译成约束条件：

你是一名资深技术文档工程师。你的任务是：为主题生成一份可以直接执行的实操教程。 写作要求： 1. 开头必须写明“目标”“适用环境”“耗时预估”三项，禁止以背景介绍或行业趋势开头。 2. 所有操作步骤以动词开头，并且每条步骤都必须能被验证。模糊表达视为不合格。 3. 必须包含“预期结果”或“验证方式”。如果执行后无法确认是否成功，视为不合格。 4. 涉及命令、路径、版本时必须给具体值；无法确定时标注“请按实际环境确认”。 5. 禁止使用这些词：值得注意的是、综上所述、众所周知、随着技术的发展、在一定程度上、一般来说。 6. 如某条命令可能造成数据损坏、覆盖或不可逆操作，必须在步骤前用“警告：”标注，并给出备份建议。 7. 如果存在已知的坑或替代方案，用“注意：”补充。 主题：[在这里输入你的主题]

这个模板的写法是：把约束写在任务之前，而不是在最后说“希望语言简洁”。因为约束前置时，AI 在生成过程一开始就会围绕这些条件搜索语料中的对应模式，生成的文本结构天然不同。

5.2 进阶：给 AI 一个“坏例子”和“好例子”

光有规则还不够，对大模型来说，一个具体的“正反示例”比十条抽象规则都管用。

在提示词里，你可以增加：

请先阅读以下两段话，第一段是反面示例，第二段是正面示例，然后模仿正面示例的风格进行写作。 反面示例： “在当今的软件开发中，错误处理是一项非常重要的工作，它对系统的稳定性具有不可忽视的意义。因此，我们需要在代码中充分考虑异常情况，从而保证程序能够健壮运行。值得注意的是，异常的捕获与处理需要遵循一定的原则，不能随意地使用 try-catch 结构。总之，良好的错误处理可以提升用户体验。” 正面示例： “目标：让任意文件读取失败时打印明确错误信息，并且程序不崩溃。 适用环境：Python 3.8+。 当用 open() 读取文件失败时，可能的原因有三类：路径不存在、权限不足、文件被占用。对于前两类，捕获 OSError 后打印文件路径与具体原因；对于第三类，记录日志并重试 3 次，间隔 1 秒。 try: with open("config.json", encoding="utf-8") as f: data = f.read() except FileNotFoundError: print("错误：config.json 不存在，请先执行初始化脚本。") except PermissionError: print("错误：当前用户无权限读取 config.json。")

注意看：正面示例里没有任何一个多余的解释词，每一句都是在传递“该怎么做”“为什么要这么做”“失败后怎么判断”。这种“示范惩罚/奖励”的方式，比单纯说“要简洁、要具体”更有效。

5.3 提示词写完后先自检

写完提示词后别急着运行。先对着下面这个清单检查一遍：

自检清单的使用逻辑是：不要期望 AI 自动理解你想表达的质量标准，你需要把标准逐条量化。这和飞机手册里每个任务必须写清“耗材与工具”是一个道理。

6. 常见问题与排查思路

在实际使用中，大家会反复遇到一些 AI 内容相关的典型问题。下面整理成表格，并展开说明。

6.1 为什么 AI 内容总是重复

AI 在长文本生成中，普遍存在“语义重复”的现象。原因是模型在生成后文时，会反复引用前文已经表达过的信息来维持连贯性，结果就是同一个意思换着说法表达三次。

解决办法是你在提示词里单独加一条：

每个段落只出现一个新信息。如果某句话是在重复前面的观点，删除它。

6.2 为什么“不要 AI 味”提示词经常失效

因为“AI 味”是个审美判断，模型无法从抽象审美映射到具体句子结构。你需要把它拆成可观察的特征，比如“禁用某某词”“禁用某某句式”“必须出现可验证的结论”。

这就是从飞机手册里学到的核心思路：不要描述“应该长得好看”，要描述“哪个螺丝用多大扭矩”。

6.3 怎么快速判断一段内容是不是 Slop

我自己的判断方法，三步：

1. 问自己：看完之后，我能照着做吗？
2. 如果照着做，我能不能知道做成功了没有？
3. 删掉文章里所有形容词和过渡句，剩余内容是否还成立？

如果第 1 步是“不能”、第 2 步是“不知道”、第 3 步是“剩余内容几乎为零”，那它就是 Slop，直接重写。

7. 最佳实践与工程建议

Anti-Slop 放大了说是写作原则，缩小了说可以落成工程实践。这里给出几个具体建议。

7.1 文档写作：每一段都要有验收标准

在团队内部写技术方案、操作手册、API 文档时，建议在每节末尾增加“验证方法”小节。比如写完“数据库迁移步骤”，就一定要补充“执行SELECT COUNT(*)确认数据量一致”“执行./gradlew flywayMigrate无报错”这类可操作标准。

没有验收标准的文档，本质上是一份“未经验证的 Slop”，只是碰巧由人类写出。

7.2 AI 辅助开发：生成的代码必须跑过才能提交

我用 AI 生成代码时，默认按两条规则执行：

• AI 生成的命令、配置、代码，先在隔离环境跑一遍，确认无误后再合入。
• AI 写注释或文档时，如果它描述的步骤我无法复现，就标记为“未经验证”而不是直接发布。

把“未经验证”这个标签显式打出来，是抗 Slop 的有效方式。因为在工程语境里，未经验证的内容带上标签后，读者就不会盲目照做。

7.3 技术博客写作：像写飞机手册一样写文章

写技术博客时，我给自己定的检查清单是：

如果写完一篇文章，连自己都无法按文中步骤复现，那这篇文章就不该发布。这和手册没有任何区别——写作者必须为自己的文字后果负责。

7.4 日常练习：找一本“硬文档”读一读

最后一条建议比较个人化：如果你长期被“怎么写都像 AI”困扰，可以找一本高质量的技术手册或官方规范来读，比如飞机维护手册、汽车维修手册、ISO 标准文档，或者任何一个强监管行业的技术文档。

读这种文档时，注意观察它们是如何用有限的篇幅传递大量精确信息的。往往连续读几十页后，你自己的写作偏好都会发生变化：你会开始本能地反问自己——这句话有什么验证价值？这个动词有没有歧义？这个参数是不是必须精确到单位？

这种训练，比背一百条“写作技巧”都管用。因为这不是在学措辞，而是在建立一种对文字后果的敬畏。

8. 写在最后

回头再看标题里的那本 1986 年飞机手册，我想通了一个道理：它之所以没有 Slop，不是因为它用了什么高级词汇，而是因为它的每一个字都会被某个人在某个关键时刻照着执行。写作者知道自己要承担后果，所以每一句都不敢含糊。

今天我们用 AI 生成内容，最大的风险不是 AI 写得不好，而是我们默认了“不承担后果的写作”是正常的。当读者照着你的教程执行，如果出了问题，你愿意负责吗？如果不愿意，那你就该用飞机手册的标准来要求自己——至少，要求你的 AI 提示词。

如果你正在和 AI 生成内容的“空洞感”作斗争，不妨把这份提示词模板保存下来，下次写教程时直接套用。如果这篇文章对你有一点启发，就先从一个最小的动作开始：把你下一篇技术文章的“背景介绍”整段删掉，换成一句话目标。相信我，效果立竿见影。