从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通常看三个特征信息密度极低一句话能说清的事用三段话来铺垫每段话都是正确的废话。结构高度模板化开头“随着科技的发展”中间“值得注意的是”结尾“综上所述”。不同主题的文章换个关键词就能互相替换。缺少可验证的动作通篇没有“运行这个命令会得到什么结果”“如果报这个错说明什么”全是抽象的描述。换句话说Slop 是“看起来像内容但实际不承载信息”的文本。1.2 为什么 AI 特别容易产出 SlopAI 内容容易变得 Slop不是模型“笨”而是它的生成机制决定的。大语言模型本质上是一个概率系统它根据前文预测下一个最可能的词。在这种机制下模型天然偏向生成语义连贯但信息量安全的内容。所谓“信息量安全”就是那些在语料库中出现频率高、不冒犯任何人、不引入具体风险的表达——比如“值得注意的是”“在当今数字化时代背景下”。因为模型没有真正执行过它写出来的步骤它不具备后果意识。一个人类工程师写“执行 rm -rf”时会本能地警惕因为删错了文件是要承担后果的但 AI 没有这个约束它只知道这两个命令经常出现在一起。所以 Anti-Slop 的本质不是单纯地“让 AI 少说废话”而是给生成内容建立约束和验证闭环。1.3 为什么开发者更需要 Anti-Slop有人可能觉得Slop 只是文章难看点不是大问题。但在技术领域Slop 的危害远不止“难看”。当 AI 生成的代码、配置、部署步骤被直接抄进生产环境时Slop 特征就意味着高风险代码看着逻辑完整但没有处理边界条件配置项看起来合理但和实际版本不匹配部署步骤缺少验证环节执行到一半才发现环境不对。低信息密度的文档比没有文档更危险。因为读者会默认“写出来的都是经过验证的”然后照着执行。这也是为什么我后来专门研究 anti-slop 的落地方法——它不只是写作技巧更是一种工程素养。2. 一本 1986 年的飞机手册为什么没有 Slop2.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”“确认保险丝安装到位”。对应到技术写作我们要把模糊动词替换成可测量动作模糊表达可验证表达配置好环境执行python --version输出 3.10.x启动服务执行systemctl status nginx显示 active (running)优化性能压测 QPS 从 1200 提升到 2000注意安全确认所有数据库账号未使用默认密码这个原则用在 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, encodingutf-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, encodingutf-8) as f: data f.read() except FileNotFoundError: print(错误config.json 不存在请先执行初始化脚本。) except PermissionError: print(错误当前用户无权限读取 config.json。)注意看正面示例里没有任何一个多余的解释词每一句都是在传递“该怎么做”“为什么要这么做”“失败后怎么判断”。这种“示范惩罚/奖励”的方式比单纯说“要简洁、要具体”更有效。5.3 提示词写完后先自检写完提示词后别急着运行。先对着下面这个清单检查一遍检查项说明是否明确写了“禁止以背景介绍开头”防 AI 用“随着...发展”开头是否指定了代码/配置的载体防止 AI 只给代码片段不给路径是否要求给出验证方式防止 AI 输出“然后检查是否正常”是否要求标注风险防止危险命令裸奔是否给出正反示例让模型在同一上下文中对比风格自检清单的使用逻辑是不要期望 AI 自动理解你想表达的质量标准你需要把标准逐条量化。这和飞机手册里每个任务必须写清“耗材与工具”是一个道理。6. 常见问题与排查思路在实际使用中大家会反复遇到一些 AI 内容相关的典型问题。下面整理成表格并展开说明。问题现象常见原因解决思路AI 文章总以背景介绍开头提示词中没有约束开头结构在提示词中明确“第一句必须写目标”要求“不要废话”后仍然废话连篇约束过于抽象模型无法翻译成具体规则给出禁用词列表、正反示例教程没有验证环节提示词中没有要求“预期输出”强制要求“必须写验证步骤与预期结果”命令缺少路径和版本模型按通用知识生成没有具体场景在提示词中提供项目路径、依赖版本输出太冗长未限制段落结构和篇幅按手册的“目标-步骤-验证”结构约束代码可行但教程描述错误模型没有实际执行代码的能力人工抽查或用工具实际执行后再发布6.1 为什么 AI 内容总是重复AI 在长文本生成中普遍存在“语义重复”的现象。原因是模型在生成后文时会反复引用前文已经表达过的信息来维持连贯性结果就是同一个意思换着说法表达三次。解决办法是你在提示词里单独加一条每个段落只出现一个新信息。如果某句话是在重复前面的观点删除它。6.2 为什么“不要 AI 味”提示词经常失效因为“AI 味”是个审美判断模型无法从抽象审美映射到具体句子结构。你需要把它拆成可观察的特征比如“禁用某某词”“禁用某某句式”“必须出现可验证的结论”。这就是从飞机手册里学到的核心思路不要描述“应该长得好看”要描述“哪个螺丝用多大扭矩”。6.3 怎么快速判断一段内容是不是 Slop我自己的判断方法三步问自己看完之后我能照着做吗如果照着做我能不能知道做成功了没有删掉文章里所有形容词和过渡句剩余内容是否还成立如果第 1 步是“不能”、第 2 步是“不知道”、第 3 步是“剩余内容几乎为零”那它就是 Slop直接重写。7. 最佳实践与工程建议Anti-Slop 放大了说是写作原则缩小了说可以落成工程实践。这里给出几个具体建议。7.1 文档写作每一段都要有验收标准在团队内部写技术方案、操作手册、API 文档时建议在每节末尾增加“验证方法”小节。比如写完“数据库迁移步骤”就一定要补充“执行SELECT COUNT(*)确认数据量一致”“执行./gradlew flywayMigrate无报错”这类可操作标准。没有验收标准的文档本质上是一份“未经验证的 Slop”只是碰巧由人类写出。7.2 AI 辅助开发生成的代码必须跑过才能提交我用 AI 生成代码时默认按两条规则执行AI 生成的命令、配置、代码先在隔离环境跑一遍确认无误后再合入。AI 写注释或文档时如果它描述的步骤我无法复现就标记为“未经验证”而不是直接发布。把“未经验证”这个标签显式打出来是抗 Slop 的有效方式。因为在工程语境里未经验证的内容带上标签后读者就不会盲目照做。7.3 技术博客写作像写飞机手册一样写文章写技术博客时我给自己定的检查清单是检查项对应手册原则开头是否在 50 字内说明读者能得到什么任务目标前置每段代码是否标明路径/运行方式消除歧义是否给出预期输出操作可验证是否标注了坑和版本边界风险显式声明是否删掉了所有不承载信息的句子信息密度优先如果写完一篇文章连自己都无法按文中步骤复现那这篇文章就不该发布。这和手册没有任何区别——写作者必须为自己的文字后果负责。7.4 日常练习找一本“硬文档”读一读最后一条建议比较个人化如果你长期被“怎么写都像 AI”困扰可以找一本高质量的技术手册或官方规范来读比如飞机维护手册、汽车维修手册、ISO 标准文档或者任何一个强监管行业的技术文档。读这种文档时注意观察它们是如何用有限的篇幅传递大量精确信息的。往往连续读几十页后你自己的写作偏好都会发生变化你会开始本能地反问自己——这句话有什么验证价值这个动词有没有歧义这个参数是不是必须精确到单位这种训练比背一百条“写作技巧”都管用。因为这不是在学措辞而是在建立一种对文字后果的敬畏。8. 写在最后回头再看标题里的那本 1986 年飞机手册我想通了一个道理它之所以没有 Slop不是因为它用了什么高级词汇而是因为它的每一个字都会被某个人在某个关键时刻照着执行。写作者知道自己要承担后果所以每一句都不敢含糊。今天我们用 AI 生成内容最大的风险不是 AI 写得不好而是我们默认了“不承担后果的写作”是正常的。当读者照着你的教程执行如果出了问题你愿意负责吗如果不愿意那你就该用飞机手册的标准来要求自己——至少要求你的 AI 提示词。如果你正在和 AI 生成内容的“空洞感”作斗争不妨把这份提示词模板保存下来下次写教程时直接套用。如果这篇文章对你有一点启发就先从一个最小的动作开始把你下一篇技术文章的“背景介绍”整段删掉换成一句话目标。相信我效果立竿见影。