反Slop技能：把技术文档从模糊推向可验证

最近和团队一起评审一份 AI 生成的接口设计文档，初看非常“完整”：字段表、请求示例、时序图都有，排版干净，语气专业。但评审刚开始，一个很基础的问题就把文档击穿了——“数据库锁等待超时的时候，这个接口返回什么状态码？”文档里没有写。再往下翻，报错码定义也缺了三个分支，生产环境必现的那种。整个过程让我意识到，我需要的不仅是“识别废话”的能力，而是一种更底层的 Anti-Slop Skill。

这个词最近在技术圈越来越常被提到。英文里的 slop，原本指食品、动物吃食，也被用来形容过度感性、没有营养的创作内容；放在技术语境里，它指的是那些“看起来完整、读起来流畅、放到真实系统里却经不起验证”的信息。反 slop 不是写得更短，也不是把话说得更狠，而是让内容具备可验证的确定性。我一度以为这是表达技巧，直到翻到一本 1986 年的飞机维护手册，才意识到这件事可以有多硬核。

那本手册排版很朴素，没有花哨配色，没有“注意”滥用，更没有“仅供参考”。一页页翻下来，能看出一个统一逻辑：每个任务都从当前状态开始，每个操作步骤都以可核验结果结束，每个异常路径都提前写好了止损动作。没有什么“根据实际情况调整”，没有“确保系统正常”这类正确的废话。它治好了我身上相当一部分“读起来对”的毛病。

1. 先搞清楚：Anti-Slop Skill 到底在对抗什么

1.1 给 slop 一个可操作的判断标准

很多人把 slop 理解为“错误信息”或“AI 废话”。但真正的问题比这更隐蔽：一份内容可能每个句子都是对的，组合起来却无法执行。这就是最典型的技术 slop。

我自己给 slop 定过三个判断标准，分享出来，可以直接用来检查任何文档、注释、方案甚至邮件：

1. 拿掉形容词和语气词之后，内容是否还成立。如果“高效”“稳定”“友好”这些词被删掉后，句子不再包含任何可验证信息，那它大概率是 slop。
2. 是否允许两种相反操作同时成立。“根据实际情况调整参数”“视情况处理”“必要时升级处理”——这些话无论发生什么都是对的，等于什么都没说。
3. 是否缺少执行三要素：前置状态、可执行动作、可验证结果。一段内容即使写得再好，只要缺了这三样，就无法被别人正确执行。

用一个对比表格来说明：

从这里能看到，反 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 落地成约束：

1. 背景与目标：只写现状和验收标准，不写形容词。
2. 方案选择：每个候选方案必须有“选它或不选它的可验证理由”，比如性能数据、维护成本、团队熟悉度。
3. 具体步骤：每个步骤包含前置条件、动作、验证点。
4. 回滚方案：写清楚在什么条件下执行回滚，回滚需要多少人、多少时间、是否会影响数据。

格式本身不神奇，神奇的是它会逼着写方案的人去补上那些“不知道但必须知道”的信息。我们用了几周后发现，评审会上争论的“这个方案行不行”，变成了“这一步的验证点能不能再明确一点”，讨论质量完全不同。

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 能力就是用来抵消这种智能幻觉的。它不要求你成为一个严格的形式主义者，只要求你在表达和接收信息时，多问三句话：

• 从哪里开始？
• 做到什么程度算完成？
• 发生意外时，停在哪里？

如果能回答，内容就有价值；不能回答，那么无论遣词造句多漂亮，都只是一堆带着格式的噪音。

最后说回那本手册。它写得保守、克制、不讨好读者，但正因如此，它让每一个照着执行的人都能在万米高空安全落地。我们写代码、写文档、写提示词，本质上也是在制造某种“手册”。既然接受这个设定，那最好让每一条内容都经得起现场执行。