2026/8/30 15:45:04
FEATURED · 精选文章 
最近在整理技术文档的时候我发现 AI 生成的内容虽然速度快但总有一种“看起来什么都说了读完之后什么都没记住”的感觉。段落之间靠套话连接代码注释写的是“定义一个函数”这种废话总结干脆用“综上所述”一笔带过。真正让我停下来反思的是翻到一本 1986 年飞机维修手册的时候——那本手册的每个字都在传递信息没有任何一段是凑数的。对比之下问题就很清楚了我们缺的不是生成能力而是对内容的Anti-Slop过滤机制。这篇文章会把这段整理心得完整记录下来。我会先解释什么是 Slop、为什么 AI 时代这个词变得这么重要然后拆解 1986 年飞机手册带给我的三点核心启发接着给出一个可落地的 Anti-Slop 检查清单、一套能写进 AI 提示词的模板、一个自动扫描废话词的 Python 脚本最后聊聊日常技术写作中怎么持续保持这个标准。1. 什么是 Slop为什么技术内容越来越“水”1.1 Slop 这个词从哪里来Slop 原本是英文里“稀泥、剩饭”的意思指那些粘稠、没什么营养的东西。在 AI 生成内容兴起的这两年“AI Slop” 逐渐成为一个专门说法用来形容那些由 AI 批量生成、看起来通顺、但信息密度极低的内容。这类内容的典型特征包括大量使用“众所周知”“总的来说”“值得注意的是”等过渡废话。每个段落都在铺垫但迟迟不进入正题。代码注释写的是“这是一段代码”“循环遍历列表”而不是解释为什么要这么写。文章结构完整但去掉任何一段都不影响理解。标题很吸引人点进去发现全是概念堆砌没有可操作步骤。简单说Slop 就是没有信息增量的内容。它不一定是错的但它是“水”的。1.2 为什么技术写作特别容易被 Slop 侵蚀技术写作本质上是在传递“怎么做”和“为什么这么做”的信息。这两类信息都要求具体、精确、可验证。但 AI 生成内容在训练时往往学到了人类写作中大量的“填充习惯”——比如过度使用连接词、铺垫背景、重复结论。于是当我们让 AI 帮忙写技术文档时它天然倾向于生成那种“安全但空洞”的文本。原因并不复杂AI 通过概率预测下一个词而“综上所述”“需要注意的是”这类短语在语料中出现频率很高模型会倾向于选择它们。AI 没有真实的项目上下文不知道你卡在哪个具体报错上所以只能用通用话术覆盖。技术文章的约束条件不如代码严格。代码跑不起来立刻报错文章写得水却不报错于是问题被掩盖了。换句话说代码有编译器帮我们做质量检查而文字没有。所以我们自己需要一套 Anti-Slop 的标准。1.3 Anti-Slop 不是反对 AI而是给 AI 设定边界这里需要澄清一个误区。Anti-Slop 并不是让你放弃 AI 写作工具回到纯手工敲字的效率水平。恰恰相反它是为了让 AI 输出更可靠、更符合技术场景的要求。我在实际项目中的体会是AI 生成内容就像一位很热情但没有项目经验的实习生你问什么它都能接上话但未必知道你到底要什么。Anti-Slop 就是你的验收标准。有了验收标准你才知道哪些输出可以直接用哪些要打回重写哪些要补充上下文后重新生成。所以这篇博文的重点不是“抵制 AI”而是“教你怎么把 AI 产出中水分最多的部分挤掉”。2. 1986 年飞机手册为什么能打Anti-Slop 三原则2.1 每一句话都在回答“如果你不这么做会怎样”1986 年的飞机维修手册有一个非常突出的特点它的每一项操作都绑定了一个后果。比如它不会只写“检查液压管路密封圈”它会写“检查液压管路密封圈若发现裂纹或老化迹象须在飞行前更换否则可能导致液压系统压力下降影响起落架收放”。这种写法放在今天的互联网内容里几乎称得上“奢侈”——因为现在绝大多数技术文章只会写前半句“检查密封圈”至于为什么检查、不检查会怎样全靠读者自己脑补。这就是 Anti-Slop 第一原则每个步骤都要说明目的和风险。没有目的的操作说明本质上就是 Slop。2.2 描述的是“可验证的状态”而不是“感觉”翻那本手册时很难看到“确保连接牢固”这种模糊描述因为它无法验证。什么是“牢固”拧到什么程度算牢固手册会改成“使用扭力扳手将螺栓拧至 25 牛米并确认扭矩标记无位移”这类描述。这个思路对技术文章写作极其重要。对比一下这两种写法Slop 写法确保配置文件正确。Anti-Slop 写法检查 application.yml 中 spring.datasource.url 的值确认其指向的目标数据库实例在 3306 端口正常监听。第一种写法谁看了都点头但没人知道下一步做什么。第二种写法给出了具体的检查对象、检查标准和预期状态读者照着做就能验证。可验证性是 Anti-Slop 内容的分水岭。2.3 先给结论再给推导过程飞机手册不会像悬疑小说一样把结论放在最后。它总是先说“本操作需要更换件号为 X 的密封圈”再解释“因为该密封圈在 Y 条件下老化速度加快”。读者即使在紧急检修现场也能只读第一行就拿到关键信息有余力时再往下看原理。今天的很多技术文章包括 AI 生成的内容习惯把结论放在文章最后前面先用大段背景和概念铺垫。这在搜索引擎优化SEO上可能有意义但对读者来说是一种时间消耗。Anti-Slop 要求我们把结论前置把理由放在结论之后。这三条原则组合起来就是一套内容质量过滤器第一步看有没有结果第二步看能不能验证第三步看有没有说明风险。只要同时满足内容就不会太水。3. 技术写作中 Slop 的七种高频形态在把 Anti-Slop 落地成检查清单之前先来看看日常技术内容里最常见的七种 Slop 形态。了解这些形态相当于给你的眼睛装上“废话雷达”。3.1 概念复读机这类内容把术语定义抄了一遍又一遍但没有跟实际操作结合起来。例如微服务架构是一种将单一应用程序划分为一组小服务的方法每个服务围绕业务能力构建可独立部署。这句话没错但它没有告诉你什么时候该用微服务、什么时候不该用。复读概念的价值几乎为零。3.2 代码注释等于没写这是最普遍的一种 Slop。看下面的 Java 代码// 定义变量 count int count 0; // 循环遍历列表 for (String item : list) { // 当 item 不为空时 if (item ! null) { count; } }每一行注释都在描述代码“在做什么”而不是“为什么这么做”。真正有用的注释应该写// 统计非空条目用于后续校验数据完整性 // 如果允许空值参与统计会导致最终生成的报表数量与源数据不一致 int count 0;3.3 过渡句堆砌“随着互联网技术的飞速发展”“在这个数据爆炸的时代”“综上所述”“需要注意的是”……这些句子放在任何文章里都适用但放在哪里都不提供信息。它们的作用只有一个凑字数。3.4 万能结论好与不好都说得模棱两可。例如这种方案在某些场景下表现良好但也存在一定的局限性需要根据实际情况权衡。这句话放在任何结论里都成立等于没说。Anti-Slop 要求你写出具体的场景、具体的指标、具体的取舍条件。3.5 步骤缺失很多人写教程时会无意中跳过“理所当然”的步骤。比如直接写“修改 pom.xml 添加依赖”但不写修改前的坐标版本、不写从哪里找到这个坐标、不写改完以后怎么验证依赖生效。对于有经验的读者来说这些也许不是问题但技术教程一旦步骤缺失就无法被完整复现本质上也是一种 Slop。3.6 标题与正文不对齐标题写“从零到一实现高并发秒杀系统”正文只在最后一段写了一句“可以使用消息队列”。这种内容在信息流里浪费了大量点击却没有交付对应的信息量。3.7 数据图表不加解读贴一张性能压测的图表却不说明测试环境、压测工具、并发量、响应时间阈值。图表本身不会说话不解读等于没贴。好现在我们对 Slop 有了具体的感知。接下来进入实践环节怎么把 Anti-Slop 变成一套可执行的检查清单。4. 搭建一个可执行的 Anti-Slop 检查清单4.1 句子级检查删掉那些“删掉也不影响”的话我在整理技术文章时会用下面这套句子级过滤规则检查项判定标准处理方式是否存在套话连接词如“众所周知”“综上所述”“需要注意的是”删除或替换为具体指代是否存在没有信息增量的描述这句话是否提供了新的操作、数据或约束没有则删除是否使用模糊程度词如“较好”“较快”“比较稳定”补充具体指标如“响应时间 200ms 以内”是否缺少前置条件如“直接运行命令即可”但没写环境变量补全前置条件具体操作时我会把文章复制到纯文本编辑器里用搜索功能逐个查这些高频废话词。看到了就删删完再读一遍信息量完全没有减少——这反而验证了它们确实是废话。4.2 段落级检查一段只能有一个主题一个段落里如果同时出现“环境安装”“代码配置”“常见问题”三个主题读者读起来会非常吃力。Anti-Slop 的段落标准是每个段落只围绕一个明确主题展开。段落开头第一句往往是主题句。段落长度控制在 150 到 300 字之间便于扫读。如果需要转换主题另起一段不要硬接。这条规则看起来简单却是区分新手和资深作者的重要标志。技术写作的本质不是展示文采而是降低读者的认知负担。4.3 文章级检查结论必须前置我给自己定的要求是文章的前三屏内必须出现核心结论或核心操作步骤。如果读者读到第二屏还在看背景介绍这篇文章的跳出率会很高。具体做法是开头先交代“这篇文章解决什么问题”。然后立即给出“最快解决路径”哪怕只有三行步骤。后面再展开原理、代码、扩展场景。这套结构特别适合 CSDN 这类以问题检索为主的平台因为读者大多带着具体报错或需求来搜索很少有人从头到尾逐行精读一篇长文。4.4 可以把清单写进项目文档我目前所在的团队会把 Anti-Slop 检查清单写进 PR 模板和文档提交规范里。每次提交技术文档除了代码走查还会过一遍文档检查项。下面是一个参考模板## 文档检查清单 - [ ] 每个步骤是否有可验证的结果 - [ ] 每个代码块是否标注了文件路径 - [ ] 是否有“众所周知/综上所述/值得注意的是”等套话 - [ ] 是否有模糊程度词较好、较快、比较稳定 - [ ] 结论是否在文章前 1/3 出现 - [ ] 删除任何一段后是否仍然能看懂整体流程如果以上任一项不符合说明文档还没达到交付标准。5. 把 Anti-Slop 思路写进 AI 提示词5.1 为什么 AI 默认会生成 Slop很多开发者用 AI 写技术文章时只给一句“帮我写一篇 Spring Boot 入门教程”得到的输出自然充满了套话。原因很简单提示词里没有质量约束。AI 生成文本时会倾向于选择“最容易接下去的词”。而“总而言之”“值得注意的是”这类短语在语料库里出现频率极高模型觉得它们很安全就会高频使用。想要 AI 产出 Anti-Slop 风格的内容必须在提示词阶段就设定质量标准。5.2 一个最小可用的 Anti-Slop 提示词模板下面是我一直在用的模板适用于大多数技术写作场景你是一名资深技术文档工程师。请按照以下规范完成任务 1. 禁止使用如下词语综上所述、众所周知、值得注意的是、随着技术的不断发展、总而言之。 2. 每个操作步骤必须包含可验证的具体命令、配置项或执行结果。 3. 每个代码块必须标注文件路径或运行位置。 4. 段落开头直接进入主题不要铺垫背景。 5. 结论放在文章前三分之一位置。 6. 如果存在多种方案必须用一个表格对比优缺点并给出明确的选择建议。 7. 禁止出现“在某些情况下”“根据实际情况权衡”这类万能结论。 任务主题{在这里输入你的主题}这个模板的核心是用否定句约束 AI用肯定句给 AI 提供可执行的表达框架。我试过很多次加上这组约束后AI 生成内容的废话量至少减少一半操作步骤明显更具体。5.3 用“角色 场景 输出格式”的组合增强效果对于更复杂的技术文档需求我一般会在上面模板基础上追加场景信息。例如背景目标读者是刚接触 Docker 的 Java 后端开发者他们已经在本地安装 Docker Desktop但对镜像构建流程不熟悉。 请输出一篇题为《Docker 镜像构建避坑指南》的博文包含 1. 最小 Dockerfile 示例和逐行解释。 2. 常见构建失败报错及排查方法。 3. 关于构建缓存和 .dockerignore 的注意事项。 4. 每一条建议都要说明“不这么做的后果”。注意“每一条建议都要说明不这么做的后果”——这句话直接对应前面提到的飞机手册第一原则。它强迫 AI 在生成内容时补齐风险描述而不是只罗列操作。6. 用 Python 脚本自动扫描 Slop 词说完了提示词再分享一个能直接落地的效率工具。我写了一个简单的 Python 脚本来扫描文章里的 Slop 特征词虽然它不能替代人工阅读但能在提交文档前做第一层过滤。6.1 脚本功能说明脚本会读取一个 Markdown 文件或纯文本文件检查以下内容是否包含常见的废话连接词。是否包含模糊程度词。是否包含万能结论句。如果发现问题会输出具体的行号和关键词方便定位修改。6.2 完整代码# 文件路径slop_scanner.py import re import sys SLOP_WORDS [ 综上所述, 总而言之, 众所周知, 显而易见, 随着技术的不断发展, 值得一提的是, 需要注意的是, 在一定程度上, 某种意义上, 不可否认 ] VAGUE_WORDS [ 较好, 较快, 比较稳定, 合适的, 一定的, 某些, 各种, 所有, 许多 ] def scan_file(file_path): 扫描指定文件中的 Slop 特征词。 try: with open(file_path, r, encodingutf-8) as f: lines f.readlines() except FileNotFoundError: print(f错误: 文件 {file_path} 不存在) sys.exit(1) issues [] for line_no, line in enumerate(lines, start1): for word in SLOP_WORDS: if word in line: issues.append((line_no, word, 废话连接词)) for word in VAGUE_WORDS: if word in line: issues.append((line_no, word, 模糊程度词)) # 匹配在...下这类万能结论模式 pattern re.compile(r在[^。]{2,20}下) for line_no, line in enumerate(lines, start1): matches pattern.findall(line) for m in matches: issues.append((line_no, m, 万能结论句式)) return issues def print_report(issues): 打印扫描报告。 if not issues: print(扫描完成未发现明显的 Slop 特征。) return print(f共发现 {len(issues)} 处可疑内容\n) print(f{行号:6}{关键词:20}{类型:16}) print(- * 50) for line_no, word, issue_type in issues: print(f{line_no:6}{word:20}{issue_type:16}) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python slop_scanner.py 文件路径) sys.exit(1) file_path sys.argv[1] found_issues scan_file(file_path) print_report(found_issues)6.3 运行与预期输出把脚本保存为slop_scanner.py然后在命令行中运行python slop_scanner.py README.md假设你的 README.md 中包含下面这句话众所周知Spring Boot 在一定程度上简化了开发流程综上所述它是一种比较稳定的框架。脚本会输出类似下面的报告共发现 4 处可疑内容 行号 关键词 类型 -------------------------------------------------- 1 众所周知 废话连接词 1 在一定程度上 模糊程度词 1 综上所述 废话连接词 1 比较稳定 模糊程度词有了这个报告你就能快速定位到需要修改的句子。当然这个脚本只是辅助工具真正的质量判断还是需要人的阅读和思考。7. 常见问题与排查思路在实践 Anti-Slop 的过程中很多开发者会碰到一些具体问题。我把最常见的情况整理成下面的表格方便大家直接查阅。问题现象常见原因解决思路AI 内容还是很多套话提示词没有明确禁止废话词使用上面第 5 节的模板并加上否定句约束删掉套话后文章变得太短原本的信息密度就低套话在凑字数补充具体的代码、配置、排查步骤而不是硬撑篇幅拿不准某句话算不算 Slop判断标准不统一使用“删掉它是否影响理解”的方法测试团队文档质量参差不齐缺少统一的文档评审标准把 Anti-Slop 清单写进 PR 模板或文档规范代码注释总是写“定义变量”作者没想清楚注释的意义注释只写“为什么”不写“是什么”文章测试环境验证不全作者跳过了验证过程强制要求文档中标注“已验证环境”和“预期输出”下面单独展开两个高频问题。7.1 把 Slop 全删了文章只剩 500 字怎么办这是很多人的真实体验。解决思路是你不是删掉了有用的内容而是发现了之前的内容大部分没有用。接下来要做的不是把废话加回去而是补充信息增量。具体来说可以从三个角度补充增加可复现的代码示例和对应的运行结果。增加常见报错和排查步骤。增加不同方案的对比表格和选择建议。这三种内容都有一个共同点它们无法用空话填充要么有真实依据要么有可验证结果。换句话说Anti-Slop 客观上倒逼内容作者去掌握更多一手材料这对技术写作是好事。7.2 团队合作时怎么推广 Anti-Slop一个团队里每个人的写作习惯差异很大。有人喜欢从背景讲起有人习惯先给结论。强行统一风格很容易引起反感。我的建议是分三步推第一步先在自己负责的文档里应用 Anti-Slop 清单把成果展示给团队。第二步在文档评审会上分享具体案例比如“这句话删掉后并不影响理解”引发讨论。第三步把检查清单变成团队 Wiki 里的一页规范开放给所有人修改。关键是不要把它做成“规定”而是做成“工具”。当大家发现按这个标准写出来的文档更容易通过评审、更少被追问时推广就会顺畅很多。8. 工程实践中的 Anti-Slop 最佳实践8.1 把 Anti-Slop 内化成写作习惯工具和清单是外部的约束真正让内容质量稳定下来的是形成一套写作时的自我提问机制。我目前每次写完一段技术内容都会快速问自己三个问题这段话如果删掉会不会影响读者完成目标这段话里的每一个名词是否有明确的指代如果读者照着做能不能得到和我一样的输出如果三个问题都能给出明确回答这段话大概率是合格的。如果任何一个问题犹豫了说明需要补充信息或调整表述。8.2 代码与文档同步评审很多项目的代码评审非常严格但文档评审处于“没人看”的状态。一个可行的改进做法是把文档修改和代码修改绑定在同一个 PR 里。提交代码时同步更新受影响的 README、接口文档或部署说明。评审人在看代码的同时也能顺便确认文档是否与代码一致。这种做法有两个好处避免代码改了文档还停留在旧版本。文档的更新频率跟上了项目节奏不用集中到发版前补写。8.3 保持简洁但不牺牲必要细节Anti-Slop 反对的是“没有信息增量的废话”而不是反对“解释说明”。判断标准是这段说明是否帮助读者避免一个真实的坑。例如“在修改数据库表结构前先备份数据”这句话本身已经是常识如果单独出现就显得有点废话。但如果写成“当前项目使用的是 MySQL 8.0可以使用 mysqldump 命令备份备份文件建议存储在与数据库服务器不同的磁盘上”这就是有信息增量的建议因为它给出了具体的工具和判断标准。简洁不是少写字而是去掉那些经过思考后仍然不提供价值的字。8.4 尊重读者时间让内容可以被扫读技术文章的读者很少从头到尾逐字精读大多数人是在搜索、定位、验证。所以 Anti-Slop 的文章应该具备“扫读友好”的特征使用序号列表和表格组织并列信息。代码块标注文件名和用途。结论和注意事项用醒目标记加粗或引用。小标题用“动作 结果”的句式例如“调整连接池参数降低并发峰值时的等待时间”而不是只看得到名词的“连接池”。这也是为什么我在这篇博文里大量使用表格和编号列表因为这些形式天然具备高信息密度扫读时也不容易丢失关键信息。8.5 定期复盘自己的旧文章Anti-Slop 不是一次性标准而是需要持续维护的习惯。我每隔一段时间会翻看自己过去写的技术博客用当前的标准重新审视。经常能发现早期文章里有大量“众所周知”和“值得注意的是”。这个复盘过程很痛苦但很有价值——它能直观地告诉你写作水平的进步轨迹。复盘时重点关注三类内容早期文章中哪些段落现在读起来让你感到尴尬。哪些操作步骤因为缺少前置条件而无法复现。哪些结论放在今天已经过时或需要修正。把这些发现记录下来既可以更新旧文章也可以为下一篇内容积累素材。9. 总结与延伸思考1986 年飞机手册带给我的不是某个具体的排版样式而是一套关于“内容质量”的判断标准。它让我意识到无论写作工具怎么变——从手写文档到 Markdown再到今天的 AI 生成——读者需要的始终是可验证、可执行、有结论的信息。Slop 内容的泛滥不是因为 AI 技术本身而是因为生成内容的门槛变低了质量标准却没有同步跟上。如果你想真正掌握 Anti-Slop 的能力最有效的练习方式不是读更多文章而是回头去改一篇自己写过的技术文档。把那篇文档里的每句话都过一遍筛子删掉无法验证的空话补上缺失的操作步骤给结论加上具体指标。完成之后你会明显感觉到“信息密度”这个概念从抽象变成了具体。如果你对 AI 生成代码、自动生成技术文档、或团队文档规范这类话题感兴趣也可以先试着用文中的 Python 脚本扫描一下自己最近写的内容。看到扫描结果的那一刻你可能会和我当初翻到那本飞机手册时一样突然明白问题出在哪里。动手试试再把你的扫描结果分享在评论区看看大家是不是都在同一个坑里。
Anti-Slop：AI时代技术写作的信息密度过滤器
最近在整理技术文档的时候我发现 AI 生成的内容虽然速度快但总有一种“看起来什么都说了读完之后什么都没记住”的感觉。段落之间靠套话连接代码注释写的是“定义一个函数”这种废话总结干脆用“综上所述”一笔带过。真正让我停下来反思的是翻到一本 1986 年飞机维修手册的时候——那本手册的每个字都在传递信息没有任何一段是凑数的。对比之下问题就很清楚了我们缺的不是生成能力而是对内容的Anti-Slop过滤机制。这篇文章会把这段整理心得完整记录下来。我会先解释什么是 Slop、为什么 AI 时代这个词变得这么重要然后拆解 1986 年飞机手册带给我的三点核心启发接着给出一个可落地的 Anti-Slop 检查清单、一套能写进 AI 提示词的模板、一个自动扫描废话词的 Python 脚本最后聊聊日常技术写作中怎么持续保持这个标准。1. 什么是 Slop为什么技术内容越来越“水”1.1 Slop 这个词从哪里来Slop 原本是英文里“稀泥、剩饭”的意思指那些粘稠、没什么营养的东西。在 AI 生成内容兴起的这两年“AI Slop” 逐渐成为一个专门说法用来形容那些由 AI 批量生成、看起来通顺、但信息密度极低的内容。这类内容的典型特征包括大量使用“众所周知”“总的来说”“值得注意的是”等过渡废话。每个段落都在铺垫但迟迟不进入正题。代码注释写的是“这是一段代码”“循环遍历列表”而不是解释为什么要这么写。文章结构完整但去掉任何一段都不影响理解。标题很吸引人点进去发现全是概念堆砌没有可操作步骤。简单说Slop 就是没有信息增量的内容。它不一定是错的但它是“水”的。1.2 为什么技术写作特别容易被 Slop 侵蚀技术写作本质上是在传递“怎么做”和“为什么这么做”的信息。这两类信息都要求具体、精确、可验证。但 AI 生成内容在训练时往往学到了人类写作中大量的“填充习惯”——比如过度使用连接词、铺垫背景、重复结论。于是当我们让 AI 帮忙写技术文档时它天然倾向于生成那种“安全但空洞”的文本。原因并不复杂AI 通过概率预测下一个词而“综上所述”“需要注意的是”这类短语在语料中出现频率很高模型会倾向于选择它们。AI 没有真实的项目上下文不知道你卡在哪个具体报错上所以只能用通用话术覆盖。技术文章的约束条件不如代码严格。代码跑不起来立刻报错文章写得水却不报错于是问题被掩盖了。换句话说代码有编译器帮我们做质量检查而文字没有。所以我们自己需要一套 Anti-Slop 的标准。1.3 Anti-Slop 不是反对 AI而是给 AI 设定边界这里需要澄清一个误区。Anti-Slop 并不是让你放弃 AI 写作工具回到纯手工敲字的效率水平。恰恰相反它是为了让 AI 输出更可靠、更符合技术场景的要求。我在实际项目中的体会是AI 生成内容就像一位很热情但没有项目经验的实习生你问什么它都能接上话但未必知道你到底要什么。Anti-Slop 就是你的验收标准。有了验收标准你才知道哪些输出可以直接用哪些要打回重写哪些要补充上下文后重新生成。所以这篇博文的重点不是“抵制 AI”而是“教你怎么把 AI 产出中水分最多的部分挤掉”。2. 1986 年飞机手册为什么能打Anti-Slop 三原则2.1 每一句话都在回答“如果你不这么做会怎样”1986 年的飞机维修手册有一个非常突出的特点它的每一项操作都绑定了一个后果。比如它不会只写“检查液压管路密封圈”它会写“检查液压管路密封圈若发现裂纹或老化迹象须在飞行前更换否则可能导致液压系统压力下降影响起落架收放”。这种写法放在今天的互联网内容里几乎称得上“奢侈”——因为现在绝大多数技术文章只会写前半句“检查密封圈”至于为什么检查、不检查会怎样全靠读者自己脑补。这就是 Anti-Slop 第一原则每个步骤都要说明目的和风险。没有目的的操作说明本质上就是 Slop。2.2 描述的是“可验证的状态”而不是“感觉”翻那本手册时很难看到“确保连接牢固”这种模糊描述因为它无法验证。什么是“牢固”拧到什么程度算牢固手册会改成“使用扭力扳手将螺栓拧至 25 牛米并确认扭矩标记无位移”这类描述。这个思路对技术文章写作极其重要。对比一下这两种写法Slop 写法确保配置文件正确。Anti-Slop 写法检查 application.yml 中 spring.datasource.url 的值确认其指向的目标数据库实例在 3306 端口正常监听。第一种写法谁看了都点头但没人知道下一步做什么。第二种写法给出了具体的检查对象、检查标准和预期状态读者照着做就能验证。可验证性是 Anti-Slop 内容的分水岭。2.3 先给结论再给推导过程飞机手册不会像悬疑小说一样把结论放在最后。它总是先说“本操作需要更换件号为 X 的密封圈”再解释“因为该密封圈在 Y 条件下老化速度加快”。读者即使在紧急检修现场也能只读第一行就拿到关键信息有余力时再往下看原理。今天的很多技术文章包括 AI 生成的内容习惯把结论放在文章最后前面先用大段背景和概念铺垫。这在搜索引擎优化SEO上可能有意义但对读者来说是一种时间消耗。Anti-Slop 要求我们把结论前置把理由放在结论之后。这三条原则组合起来就是一套内容质量过滤器第一步看有没有结果第二步看能不能验证第三步看有没有说明风险。只要同时满足内容就不会太水。3. 技术写作中 Slop 的七种高频形态在把 Anti-Slop 落地成检查清单之前先来看看日常技术内容里最常见的七种 Slop 形态。了解这些形态相当于给你的眼睛装上“废话雷达”。3.1 概念复读机这类内容把术语定义抄了一遍又一遍但没有跟实际操作结合起来。例如微服务架构是一种将单一应用程序划分为一组小服务的方法每个服务围绕业务能力构建可独立部署。这句话没错但它没有告诉你什么时候该用微服务、什么时候不该用。复读概念的价值几乎为零。3.2 代码注释等于没写这是最普遍的一种 Slop。看下面的 Java 代码// 定义变量 count int count 0; // 循环遍历列表 for (String item : list) { // 当 item 不为空时 if (item ! null) { count; } }每一行注释都在描述代码“在做什么”而不是“为什么这么做”。真正有用的注释应该写// 统计非空条目用于后续校验数据完整性 // 如果允许空值参与统计会导致最终生成的报表数量与源数据不一致 int count 0;3.3 过渡句堆砌“随着互联网技术的飞速发展”“在这个数据爆炸的时代”“综上所述”“需要注意的是”……这些句子放在任何文章里都适用但放在哪里都不提供信息。它们的作用只有一个凑字数。3.4 万能结论好与不好都说得模棱两可。例如这种方案在某些场景下表现良好但也存在一定的局限性需要根据实际情况权衡。这句话放在任何结论里都成立等于没说。Anti-Slop 要求你写出具体的场景、具体的指标、具体的取舍条件。3.5 步骤缺失很多人写教程时会无意中跳过“理所当然”的步骤。比如直接写“修改 pom.xml 添加依赖”但不写修改前的坐标版本、不写从哪里找到这个坐标、不写改完以后怎么验证依赖生效。对于有经验的读者来说这些也许不是问题但技术教程一旦步骤缺失就无法被完整复现本质上也是一种 Slop。3.6 标题与正文不对齐标题写“从零到一实现高并发秒杀系统”正文只在最后一段写了一句“可以使用消息队列”。这种内容在信息流里浪费了大量点击却没有交付对应的信息量。3.7 数据图表不加解读贴一张性能压测的图表却不说明测试环境、压测工具、并发量、响应时间阈值。图表本身不会说话不解读等于没贴。好现在我们对 Slop 有了具体的感知。接下来进入实践环节怎么把 Anti-Slop 变成一套可执行的检查清单。4. 搭建一个可执行的 Anti-Slop 检查清单4.1 句子级检查删掉那些“删掉也不影响”的话我在整理技术文章时会用下面这套句子级过滤规则检查项判定标准处理方式是否存在套话连接词如“众所周知”“综上所述”“需要注意的是”删除或替换为具体指代是否存在没有信息增量的描述这句话是否提供了新的操作、数据或约束没有则删除是否使用模糊程度词如“较好”“较快”“比较稳定”补充具体指标如“响应时间 200ms 以内”是否缺少前置条件如“直接运行命令即可”但没写环境变量补全前置条件具体操作时我会把文章复制到纯文本编辑器里用搜索功能逐个查这些高频废话词。看到了就删删完再读一遍信息量完全没有减少——这反而验证了它们确实是废话。4.2 段落级检查一段只能有一个主题一个段落里如果同时出现“环境安装”“代码配置”“常见问题”三个主题读者读起来会非常吃力。Anti-Slop 的段落标准是每个段落只围绕一个明确主题展开。段落开头第一句往往是主题句。段落长度控制在 150 到 300 字之间便于扫读。如果需要转换主题另起一段不要硬接。这条规则看起来简单却是区分新手和资深作者的重要标志。技术写作的本质不是展示文采而是降低读者的认知负担。4.3 文章级检查结论必须前置我给自己定的要求是文章的前三屏内必须出现核心结论或核心操作步骤。如果读者读到第二屏还在看背景介绍这篇文章的跳出率会很高。具体做法是开头先交代“这篇文章解决什么问题”。然后立即给出“最快解决路径”哪怕只有三行步骤。后面再展开原理、代码、扩展场景。这套结构特别适合 CSDN 这类以问题检索为主的平台因为读者大多带着具体报错或需求来搜索很少有人从头到尾逐行精读一篇长文。4.4 可以把清单写进项目文档我目前所在的团队会把 Anti-Slop 检查清单写进 PR 模板和文档提交规范里。每次提交技术文档除了代码走查还会过一遍文档检查项。下面是一个参考模板## 文档检查清单 - [ ] 每个步骤是否有可验证的结果 - [ ] 每个代码块是否标注了文件路径 - [ ] 是否有“众所周知/综上所述/值得注意的是”等套话 - [ ] 是否有模糊程度词较好、较快、比较稳定 - [ ] 结论是否在文章前 1/3 出现 - [ ] 删除任何一段后是否仍然能看懂整体流程如果以上任一项不符合说明文档还没达到交付标准。5. 把 Anti-Slop 思路写进 AI 提示词5.1 为什么 AI 默认会生成 Slop很多开发者用 AI 写技术文章时只给一句“帮我写一篇 Spring Boot 入门教程”得到的输出自然充满了套话。原因很简单提示词里没有质量约束。AI 生成文本时会倾向于选择“最容易接下去的词”。而“总而言之”“值得注意的是”这类短语在语料库里出现频率极高模型觉得它们很安全就会高频使用。想要 AI 产出 Anti-Slop 风格的内容必须在提示词阶段就设定质量标准。5.2 一个最小可用的 Anti-Slop 提示词模板下面是我一直在用的模板适用于大多数技术写作场景你是一名资深技术文档工程师。请按照以下规范完成任务 1. 禁止使用如下词语综上所述、众所周知、值得注意的是、随着技术的不断发展、总而言之。 2. 每个操作步骤必须包含可验证的具体命令、配置项或执行结果。 3. 每个代码块必须标注文件路径或运行位置。 4. 段落开头直接进入主题不要铺垫背景。 5. 结论放在文章前三分之一位置。 6. 如果存在多种方案必须用一个表格对比优缺点并给出明确的选择建议。 7. 禁止出现“在某些情况下”“根据实际情况权衡”这类万能结论。 任务主题{在这里输入你的主题}这个模板的核心是用否定句约束 AI用肯定句给 AI 提供可执行的表达框架。我试过很多次加上这组约束后AI 生成内容的废话量至少减少一半操作步骤明显更具体。5.3 用“角色 场景 输出格式”的组合增强效果对于更复杂的技术文档需求我一般会在上面模板基础上追加场景信息。例如背景目标读者是刚接触 Docker 的 Java 后端开发者他们已经在本地安装 Docker Desktop但对镜像构建流程不熟悉。 请输出一篇题为《Docker 镜像构建避坑指南》的博文包含 1. 最小 Dockerfile 示例和逐行解释。 2. 常见构建失败报错及排查方法。 3. 关于构建缓存和 .dockerignore 的注意事项。 4. 每一条建议都要说明“不这么做的后果”。注意“每一条建议都要说明不这么做的后果”——这句话直接对应前面提到的飞机手册第一原则。它强迫 AI 在生成内容时补齐风险描述而不是只罗列操作。6. 用 Python 脚本自动扫描 Slop 词说完了提示词再分享一个能直接落地的效率工具。我写了一个简单的 Python 脚本来扫描文章里的 Slop 特征词虽然它不能替代人工阅读但能在提交文档前做第一层过滤。6.1 脚本功能说明脚本会读取一个 Markdown 文件或纯文本文件检查以下内容是否包含常见的废话连接词。是否包含模糊程度词。是否包含万能结论句。如果发现问题会输出具体的行号和关键词方便定位修改。6.2 完整代码# 文件路径slop_scanner.py import re import sys SLOP_WORDS [ 综上所述, 总而言之, 众所周知, 显而易见, 随着技术的不断发展, 值得一提的是, 需要注意的是, 在一定程度上, 某种意义上, 不可否认 ] VAGUE_WORDS [ 较好, 较快, 比较稳定, 合适的, 一定的, 某些, 各种, 所有, 许多 ] def scan_file(file_path): 扫描指定文件中的 Slop 特征词。 try: with open(file_path, r, encodingutf-8) as f: lines f.readlines() except FileNotFoundError: print(f错误: 文件 {file_path} 不存在) sys.exit(1) issues [] for line_no, line in enumerate(lines, start1): for word in SLOP_WORDS: if word in line: issues.append((line_no, word, 废话连接词)) for word in VAGUE_WORDS: if word in line: issues.append((line_no, word, 模糊程度词)) # 匹配在...下这类万能结论模式 pattern re.compile(r在[^。]{2,20}下) for line_no, line in enumerate(lines, start1): matches pattern.findall(line) for m in matches: issues.append((line_no, m, 万能结论句式)) return issues def print_report(issues): 打印扫描报告。 if not issues: print(扫描完成未发现明显的 Slop 特征。) return print(f共发现 {len(issues)} 处可疑内容\n) print(f{行号:6}{关键词:20}{类型:16}) print(- * 50) for line_no, word, issue_type in issues: print(f{line_no:6}{word:20}{issue_type:16}) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python slop_scanner.py 文件路径) sys.exit(1) file_path sys.argv[1] found_issues scan_file(file_path) print_report(found_issues)6.3 运行与预期输出把脚本保存为slop_scanner.py然后在命令行中运行python slop_scanner.py README.md假设你的 README.md 中包含下面这句话众所周知Spring Boot 在一定程度上简化了开发流程综上所述它是一种比较稳定的框架。脚本会输出类似下面的报告共发现 4 处可疑内容 行号 关键词 类型 -------------------------------------------------- 1 众所周知 废话连接词 1 在一定程度上 模糊程度词 1 综上所述 废话连接词 1 比较稳定 模糊程度词有了这个报告你就能快速定位到需要修改的句子。当然这个脚本只是辅助工具真正的质量判断还是需要人的阅读和思考。7. 常见问题与排查思路在实践 Anti-Slop 的过程中很多开发者会碰到一些具体问题。我把最常见的情况整理成下面的表格方便大家直接查阅。问题现象常见原因解决思路AI 内容还是很多套话提示词没有明确禁止废话词使用上面第 5 节的模板并加上否定句约束删掉套话后文章变得太短原本的信息密度就低套话在凑字数补充具体的代码、配置、排查步骤而不是硬撑篇幅拿不准某句话算不算 Slop判断标准不统一使用“删掉它是否影响理解”的方法测试团队文档质量参差不齐缺少统一的文档评审标准把 Anti-Slop 清单写进 PR 模板或文档规范代码注释总是写“定义变量”作者没想清楚注释的意义注释只写“为什么”不写“是什么”文章测试环境验证不全作者跳过了验证过程强制要求文档中标注“已验证环境”和“预期输出”下面单独展开两个高频问题。7.1 把 Slop 全删了文章只剩 500 字怎么办这是很多人的真实体验。解决思路是你不是删掉了有用的内容而是发现了之前的内容大部分没有用。接下来要做的不是把废话加回去而是补充信息增量。具体来说可以从三个角度补充增加可复现的代码示例和对应的运行结果。增加常见报错和排查步骤。增加不同方案的对比表格和选择建议。这三种内容都有一个共同点它们无法用空话填充要么有真实依据要么有可验证结果。换句话说Anti-Slop 客观上倒逼内容作者去掌握更多一手材料这对技术写作是好事。7.2 团队合作时怎么推广 Anti-Slop一个团队里每个人的写作习惯差异很大。有人喜欢从背景讲起有人习惯先给结论。强行统一风格很容易引起反感。我的建议是分三步推第一步先在自己负责的文档里应用 Anti-Slop 清单把成果展示给团队。第二步在文档评审会上分享具体案例比如“这句话删掉后并不影响理解”引发讨论。第三步把检查清单变成团队 Wiki 里的一页规范开放给所有人修改。关键是不要把它做成“规定”而是做成“工具”。当大家发现按这个标准写出来的文档更容易通过评审、更少被追问时推广就会顺畅很多。8. 工程实践中的 Anti-Slop 最佳实践8.1 把 Anti-Slop 内化成写作习惯工具和清单是外部的约束真正让内容质量稳定下来的是形成一套写作时的自我提问机制。我目前每次写完一段技术内容都会快速问自己三个问题这段话如果删掉会不会影响读者完成目标这段话里的每一个名词是否有明确的指代如果读者照着做能不能得到和我一样的输出如果三个问题都能给出明确回答这段话大概率是合格的。如果任何一个问题犹豫了说明需要补充信息或调整表述。8.2 代码与文档同步评审很多项目的代码评审非常严格但文档评审处于“没人看”的状态。一个可行的改进做法是把文档修改和代码修改绑定在同一个 PR 里。提交代码时同步更新受影响的 README、接口文档或部署说明。评审人在看代码的同时也能顺便确认文档是否与代码一致。这种做法有两个好处避免代码改了文档还停留在旧版本。文档的更新频率跟上了项目节奏不用集中到发版前补写。8.3 保持简洁但不牺牲必要细节Anti-Slop 反对的是“没有信息增量的废话”而不是反对“解释说明”。判断标准是这段说明是否帮助读者避免一个真实的坑。例如“在修改数据库表结构前先备份数据”这句话本身已经是常识如果单独出现就显得有点废话。但如果写成“当前项目使用的是 MySQL 8.0可以使用 mysqldump 命令备份备份文件建议存储在与数据库服务器不同的磁盘上”这就是有信息增量的建议因为它给出了具体的工具和判断标准。简洁不是少写字而是去掉那些经过思考后仍然不提供价值的字。8.4 尊重读者时间让内容可以被扫读技术文章的读者很少从头到尾逐字精读大多数人是在搜索、定位、验证。所以 Anti-Slop 的文章应该具备“扫读友好”的特征使用序号列表和表格组织并列信息。代码块标注文件名和用途。结论和注意事项用醒目标记加粗或引用。小标题用“动作 结果”的句式例如“调整连接池参数降低并发峰值时的等待时间”而不是只看得到名词的“连接池”。这也是为什么我在这篇博文里大量使用表格和编号列表因为这些形式天然具备高信息密度扫读时也不容易丢失关键信息。8.5 定期复盘自己的旧文章Anti-Slop 不是一次性标准而是需要持续维护的习惯。我每隔一段时间会翻看自己过去写的技术博客用当前的标准重新审视。经常能发现早期文章里有大量“众所周知”和“值得注意的是”。这个复盘过程很痛苦但很有价值——它能直观地告诉你写作水平的进步轨迹。复盘时重点关注三类内容早期文章中哪些段落现在读起来让你感到尴尬。哪些操作步骤因为缺少前置条件而无法复现。哪些结论放在今天已经过时或需要修正。把这些发现记录下来既可以更新旧文章也可以为下一篇内容积累素材。9. 总结与延伸思考1986 年飞机手册带给我的不是某个具体的排版样式而是一套关于“内容质量”的判断标准。它让我意识到无论写作工具怎么变——从手写文档到 Markdown再到今天的 AI 生成——读者需要的始终是可验证、可执行、有结论的信息。Slop 内容的泛滥不是因为 AI 技术本身而是因为生成内容的门槛变低了质量标准却没有同步跟上。如果你想真正掌握 Anti-Slop 的能力最有效的练习方式不是读更多文章而是回头去改一篇自己写过的技术文档。把那篇文档里的每句话都过一遍筛子删掉无法验证的空话补上缺失的操作步骤给结论加上具体指标。完成之后你会明显感觉到“信息密度”这个概念从抽象变成了具体。如果你对 AI 生成代码、自动生成技术文档、或团队文档规范这类话题感兴趣也可以先试着用文中的 Python 脚本扫描一下自己最近写的内容。看到扫描结果的那一刻你可能会和我当初翻到那本飞机手册时一样突然明白问题出在哪里。动手试试再把你的扫描结果分享在评论区看看大家是不是都在同一个坑里。 
