最近和团队一起评审一份 AI 生成的接口设计文档初看非常“完整”字段表、请求示例、时序图都有排版干净语气专业。但评审刚开始一个很基础的问题就把文档击穿了——“数据库锁等待超时的时候这个接口返回什么状态码”文档里没有写。再往下翻报错码定义也缺了三个分支生产环境必现的那种。整个过程让我意识到我需要的不仅是“识别废话”的能力而是一种更底层的 Anti-Slop Skill。这个词最近在技术圈越来越常被提到。英文里的 slop原本指食品、动物吃食也被用来形容过度感性、没有营养的创作内容放在技术语境里它指的是那些“看起来完整、读起来流畅、放到真实系统里却经不起验证”的信息。反 slop 不是写得更短也不是把话说得更狠而是让内容具备可验证的确定性。我一度以为这是表达技巧直到翻到一本 1986 年的飞机维护手册才意识到这件事可以有多硬核。那本手册排版很朴素没有花哨配色没有“注意”滥用更没有“仅供参考”。一页页翻下来能看出一个统一逻辑每个任务都从当前状态开始每个操作步骤都以可核验结果结束每个异常路径都提前写好了止损动作。没有什么“根据实际情况调整”没有“确保系统正常”这类正确的废话。它治好了我身上相当一部分“读起来对”的毛病。1. 先搞清楚Anti-Slop Skill 到底在对抗什么1.1 给 slop 一个可操作的判断标准很多人把 slop 理解为“错误信息”或“AI 废话”。但真正的问题比这更隐蔽一份内容可能每个句子都是对的组合起来却无法执行。这就是最典型的技术 slop。我自己给 slop 定过三个判断标准分享出来可以直接用来检查任何文档、注释、方案甚至邮件拿掉形容词和语气词之后内容是否还成立。如果“高效”“稳定”“友好”这些词被删掉后句子不再包含任何可验证信息那它大概率是 slop。是否允许两种相反操作同时成立。“根据实际情况调整参数”“视情况处理”“必要时升级处理”——这些话无论发生什么都是对的等于什么都没说。是否缺少执行三要素前置状态、可执行动作、可验证结果。一段内容即使写得再好只要缺了这三样就无法被别人正确执行。用一个对比表格来说明slop 式表达可验证表达确保系统稳定运行观察服务 CPU 连续 5 分钟低于 70%错误日志中无新增连接超时提高接口性能将缓存命中率从 60% 提升到 85%P95 延迟低于 500ms根据实际情况调整参数如果 P95 延迟超过 800ms将 max_concurrency 降为当前值的 50%观察 10 分钟注意数据安全生产环境数据库账号使用独立账号仅授予应用库读写权限禁止使用 root 连接从这里能看到反 slop 的核心不是把内容“写得更少”而是把模糊信息翻译成可验证信息。这也解释了为什么传统写作里“语言精炼”并不等于反 slop因为精炼可能只是省略了关键条件。1.2 为什么这个问题在 AI 协作时代被放大了AI 生成内容的默认目标是“流畅”和“全面”不断产出句子让文本看起来自洽。但这恰恰和反 slop 的目标冲突。因为自然语言模型学习到的是海量人类文本的统计学规律而人类文本中充斥着大量“听起来专业、实际无法执行”的汇报体、总结体、方案体。和 AI 协作久了会发现如果你问它“这个方案有什么风险”它会努力给出三条风险每条都正确但每条都不知道该怎么应对。这不是模型不聪明而是它被训练成“继续对话”而不是“确保你能执行”。如果使用者没有反 slop 能力就会把这种输出直接带进生产系统最后要么返工要么事故。我在团队里做过一个小实验让 AI 写一份 Redis 缓存优化方案不限制格式。它写出的方案里大量出现“合理设置过期时间”“优化数据结构”“避免大 key 问题”。单独看都对但如果一个新同事照着执行根本不知道第一步干什么。后来在提示词里加入“每个步骤必须包含前置条件、动作、验证方式”输出立刻变得可用很多。这说明一个小问题AI 输出是否 slop很大程度取决于你允许它有多 slop。2. 一本 1986 年的飞机手册为什么能治好“读起来对”的毛病2.1 手册里没有一句“仅供参考”飞机手册这种文件有一个特殊性它不能靠读者“悟”也不能让读者在几万米高空做选择题。每一句话出现的位置、每一个警告的等级、每一个步骤的顺序都必须经得起极端条件下的执行。那本 1986 年手册最让我震撼的一点是它对任务状态的描述。比如一个简单的保险丝更换流程核心逻辑大致是确认电路已断电取下旧保险丝检查新保险丝规格安装后确认接触正常。整个过程没有“断开相关电路”这种含糊表述而是明确要求使用指定规格的保险丝并且安装后要执行一项检查。看起来很基础但想一想我们平时写的技术文档有多少会明确写“使用指定版本依赖不要使用最新版”有多少会在步骤之后写“执行这条命令后应该看到什么是正常结果”大多数时候只写“执行命令”读者只能赌自己运气好。飞机手册给我的第一课是好指令的前提是知道从什么状态开始。所有后续动作都建立在“当前已断电”“当前压力已释放”“当前读数归零”这些明确状态之上。反观我们的文档经常一上来就写“然后点击保存”“然后调用接口”完全没交代前置状态。2.2 关键状态、动作、验证三要素缺一不可那本手册里的每个操作步骤都包含三个要素状态在什么条件下进行这一步当前系统应处于什么状态。动作具体执行什么操作动词明确参数明确指向单一。验证执行完之后如何确认结果正确判断标准是什么。比如维修手册里经常会出现类似这样的结构在拆卸某部件前先确认仪表读数处于零位如果读数不为零不得进入下一步应检查线路完成拆卸后检查安装表面有无划伤如果发现划伤按修理等级处理。拆开看这就是一个非常标准的反 slop 模板。它不允许执行者凭感觉判断“差不多行”。每一步都有一个明确的可观测信号。而我们日常写文档时最缺的恰恰是“验证”。动作写了一大堆但极少写“我怎么知道做对了”。我后来在做技术方案评审时开始专门查一件事文档里是否每个关键步骤都有验证方法。这不是形式主义而是因为“没有验证方法”和“无法落地”几乎是同义词。2.3 失败模式不是附录而是主流程那本 1986 年手册另一个让我印象深刻的点是失败处理不是在后面单开一章“常见问题”而是嵌在正常步骤里。很多步骤都带有类似“如果……不得……”的说明。比如如果测量值不在规定范围内不要继续下一步操作应按排故章节查找原因如果仪表读数异常应停止当前程序并上报。它没有把异常当成“小概率事件”附在文末而是直接放进主流程因为故障出现时执行者没时间翻到页尾查。这恰恰是日常文档里最容易 slop 的地方。我们的方案、接口文档、操作手册通常默认情况写得很详细但失败处理要么没有要么只写一句“如遇问题请联系管理员”。这句话除了增加焦虑不提供任何信息。好的做法是在每个步骤旁边直接标注这一步如果出现什么结果应该做什么如果出现另一个结果则不能继续。这不是写额外的“故障手册”而是让正常步骤本身就包含分支判断。飞机手册的本质也就是这样正常路径和异常路径是同一个流程的两个分支而不是两个独立文档。3. 从手册到日常一套可复用的反 slop 写作框架3.1 写之前先写“当前状态”很多人写技术方案时喜欢直接从“我们要做什么”开始但飞机手册的思路正好相反先写“现在在哪里现在是什么状态”。对应的写作模板是前置条件这个操作、方案或说明适用于什么环境、什么版本、什么角色。当前状态开始之前系统或任务应该处于什么状态哪些依赖已经具备哪些权限已经开通。不适用条件什么情况下本方案不适用应该在什么场景下停止阅读并使用另一套方案。这个习惯能过滤掉大量“看起来通用、实际没人能执行”的内容。比如写一份部署文档时开头就写“本说明适用于 CentOS 7 以上系统需要具备 sudo 权限目标端口 8080 未被占用”比写“本方案可以快速部署服务”要有用得多。我自己的做法是写每一份文档前先花十分钟把“不适用条件”写出来。写完之后会发现很多内容会自动变得精确因为一旦限定边界就不能再用“视情况”这种词。3.2 每条指令都配上验证点关于验证点有一个很实用的简单规则如果你写了一个动作请在同一个步骤里回答“我怎么知道这一步成功了”。比如不写“修改配置文件”而是写“修改配置文件后运行nginx -t看到syntax is ok表示配置有效”。不写“重启服务”而是写“重启服务后通过systemctl status确认状态为 active且日志不再出现权限报错”。不写“验证功能正常”而是写“调用带有预置数据的测试接口确认返回码为 200响应中result字段为success”。验证点不需要多高深甚至不需要自动化但它必须存在。因为一旦一个动作缺少验证点执行者就不得不靠猜猜就会产生歧义歧义就会变成 slop。从工程经验看给每个动作配验证点会让文档长度增加但阅读成本反而下降。因为读者不用自己脑补“这一步到底成功没有”。3.3 显式声明边界和停止条件反 slop 框架里最容易被人忽略的是“停止条件”。飞机手册在这一点上非常无情如果一个步骤出现了预期之外的情况它不会说“请谨慎处理”而是直接告诉你“停止操作标记部件联系检查员”。因为很多故障的扩大量不是发生在故障点而是发生在故障后执行者继续犹豫和试探的过程中。技术工作也一样。文档里应该写清楚如果这个步骤连续重试 3 次仍然失败停止操作而不是继续调整参数。如果某个迁移脚本在中间失败下一步应该做回滚而不是继续执行后面的迁移。如果线上错误率超过 5%立即关闭开关而不是先查日志。“继续尝试”在探索阶段是优点在执行阶段却是灾难。反 slop 要求我们在写清楚“做什么”的同时也写清楚“什么时候不该做”。3.4 把警告和信息分开放1986 年那本手册对信息分级极其严格警告标识不是出于排版效果。哪些情况可能造成人身伤害、哪些情况可能损坏设备、哪些情况只是影响性能分级之后执行者才能第一时间知道现在面对问题的严重程度。日常文档里我们总喜欢把所有提醒都写成“注意”或“小心”。这个词用多了其实等于取消了级别。更合理的做法是级别含义示例必须不执行会导致流程中断或数据错误导出前必须关闭写入任务禁止执行会带来明确风险禁止在迁移期间重启数据库警告可能发生故障需要提前确认涉及大表扫描时提前评估锁持有时间提示性能或可维护性建议建议在低峰期执行索引重建分级不是为了吓人而是为了让读者知道哪些话真正重要哪些只是可选建议。如果没有分级所有内容都挤在一起读者只能全部相信或者全部怀疑这两种结果都挺糟糕。4. 落到技术工作流文档、代码、AI 协作4.1 技术方案文档从“大概可以”到“确认过”写技术方案时最容易 slop 的部分是“设计原则”和“具体实现”之间的断层。原则写得很高级落地步骤却经不起推敲。我在团队里推行过一个简单格式把反 slop 落地成约束背景与目标只写现状和验收标准不写形容词。方案选择每个候选方案必须有“选它或不选它的可验证理由”比如性能数据、维护成本、团队熟悉度。具体步骤每个步骤包含前置条件、动作、验证点。回滚方案写清楚在什么条件下执行回滚回滚需要多少人、多少时间、是否会影响数据。格式本身不神奇神奇的是它会逼着写方案的人去补上那些“不知道但必须知道”的信息。我们用了几周后发现评审会上争论的“这个方案行不行”变成了“这一步的验证点能不能再明确一点”讨论质量完全不同。4.2 代码注释和 README少写感想多写约束代码注释是另一个 slop 重灾区。常见低质量注释包括“这里进行优化” —— 优化了什么为什么优化度量标准是什么“这个逻辑很复杂” —— 复杂在哪哪些条件参与决策“不要删掉这段代码” —— 为什么不能删删除后会发生什么反 slop 的注释应该写约束而不是写状态。比如# 这里不能使用批量接口 # 依赖服务的单次超时上限是 1s批量会把线程池耗尽 # 导致同进程内其他请求排队超过 3s。再比如 README很多人喜欢写“本项目是一个高效稳定的 XX 系统”但真正有用的是“本项目适用于单机部署依赖 MySQL 8.0 和 Redis 6暂不支持 Windows”。把适用边界和已知限制写清楚维护者未来会省很多事。这里有一个原则注释写错了比没有注释更危险。如果你不确定一句注释在未来是否成立就把它改成“当时为什么这样写”的理由。理由比建议更持久也更难被误执行。4.3 让 AI 产出更“不 slop”的内容和 AI 协作时反 slop 能力至少有两层一层是能识别 AI 输出中的水分另一层是能通过输入约束减少水分。第二层其实可以工程化。我常用的一个提示词结构是请按如下格式输出不要使用模糊量词 1. 当前状态明确输入数据和环境假设。 2. 执行动作每条指令以具体动词开头包含可执行参数。 3. 验证方式每个动作后面附上判断成功的指标或命令。 4. 失败路径列出可能出现的问题以及每个问题的具体停止条件和处理动作。比如让 AI 写数据迁移方案如果只是说“写一个迁移方案”它很可能会给出“备份数据库、编写脚本、执行迁移、验证数据”这种结构。先不说不算错但无法直接用。一旦要求“当前状态、动作、验证、失败路径”生成结果会明显偏向可执行。这里想专门提一句AI 生成的内容并不天然 slop但它默认倾向于“流畅”。大多数时候模型的优化目标是对话能继续而不是你的步骤能跑通。所以使用者的“反 slop 输入框架”是提升 AI 输出质量的重要手段。你越允许它模糊它就越模糊你要求它精确它通常能精确。5. 遇到问题先别改措辞按这条链路排查拿到一份文档、方案、AI 输出甚至别人写的代码时如果总觉得哪里不对但说不出来不要先纠结措辞。可以按下面四层链路排查通常问题会浮出来。5.1 第一层输入状态是否明确先问自己这段内容有没有交代从什么状态开始它适用于哪些环境哪些版本哪些权限执行者是谁是开发、运维、普通用户还是 AI前置条件有哪些比如服务是否已启动、依赖是否已安装、网络是否已连通。如果一项都没有即使后续写得再细也没法执行。因为第一步就已经出现分支了。5.2 第二层动作是否可执行逐句看每个动词。“确保”“促进”“优化”“加强”都不是动作。“执行”“安装”“配置”“调用”“回滚”才是动作。每个动作是否带参数、路径、命令或上下文动作之间是否有依赖关系顺序是否明确如果一段内容里全是抽象动词而没有具体命令或参数它就不是操作说明只是读起来像操作说明。5.3 第三层结果是否可验证关键步骤后面有没有验证点执行完命令后应该看到什么输出调用接口后预期响应码、字段值是什么有没有需要观察一段时间才能确认的结果比如错误率、延迟、日志没有验证点的步骤等于在系统里埋了一个“所有人靠猜”的坑。5.4 第四层失败路径是否覆盖最后看异常情况。如果前置条件不满足应该停在哪一步如果某个命令失败重试还是回滚连续失败几次后应该联系谁用什么方式上报如果数据已经写到一半如何清理脏数据这四层排查下来你会发现大多数看起来“还行”的内容都会现出原形。用这个链路去检查文档不是为了挑刺而是为了确认看完的人不需要在脑子里补写一半内容。6. 适用边界反 slop 不能变成机械化和过度文档化6.1 适合什么场景反 slop 框架特别适合下面这类场景多人协作的工程文档部署手册、接口文档、故障处理手册、上线检查项。会被机器或外部系统执行的配置说明CI 脚本、基础设施代码、自动化测试描述。需要交接给别人的内容离职交接、项目移交、团队内部知识库。用 AI 生成后还要人工落地的所有内容需求分析、设计文档、提示词输出。在这些场景下内容的核心价值是“可执行”不是“读得顺”。状态、动作、验证、边界每缺一项都会在某个时刻变成事故或返工。6.2 不适合什么场景反 slop 也不是万能的。如果所有内容都严格按“前置条件-动作-验证”编写会失去一些宝贵的东西头脑风暴阶段需要大量开放、发散、探索性内容。这时候用反 slop 去约束会扼杀灵感。技术战略讨论需要保留权衡和灰度判断不适合全部改写成条件分支。学习笔记和个人思考过度的模板化会让人停止真正理解只满足于填表格。另外还要注意反 slop 不能替代人的判断。面向不确定性和模糊性做出决策是人的工作。文档只能把决策依据写清楚不能让每一步都看起来像线性执行。6.3 长期看反 slop 的真正价值那本 1986 年手册真正改变我的不是某个格式而是我对“一段内容是否合格”的衡量尺度。过去我看一份技术资料第一反应是“它写得通不通顺”现在我更关心“读完它我能不能开始做并且知道自己做对了没有”。这个尺度放到 AI 时代尤其重要。AI 擅长生成看似完整但实际含混的内容而反 slop 能力就是用来抵消这种智能幻觉的。它不要求你成为一个严格的形式主义者只要求你在表达和接收信息时多问三句话从哪里开始做到什么程度算完成发生意外时停在哪里如果能回答内容就有价值不能回答那么无论遣词造句多漂亮都只是一堆带着格式的噪音。最后说回那本手册。它写得保守、克制、不讨好读者但正因如此它让每一个照着执行的人都能在万米高空安全落地。我们写代码、写文档、写提示词本质上也是在制造某种“手册”。既然接受这个设定那最好让每一条内容都经得起现场执行。