你有没有遇到过这种情况让 AI 写一段技术说明它交回来一篇“在当今信息化时代……具有重要意义”的官样文章。你把“不要说废话”打在提示词里它删掉了第一段套话又补了两段同义反复。问题出在哪问题不在于模型“不听话”而在于我们没有把“什么是好的输出”翻译成模型能执行的结构。就像你不能只对一位刚入职的工程师说“把系统做好”你得告诉他什么情况下做什么、做到什么程度、交付前检查什么。这个认知是我在翻一份 1986 年飞行手册时真正想通的。写这篇文章之前我重新梳理了一遍 Anti-Slop Skill 的完整设计思路。它不是一个只写“禁止废话”的提示词文件而是一套“限制—程序—检查单”的结构化规则系统。本文会讲清楚四件事第一Slop 到底在对抗什么第二1986 年飞行手册的结构为什么值得参考第三如何把这种结构落到 Claude Agent Skills 里给你一份完整可用的 SKILL.md第四怎么验证一个 Anti-Slop Skill 真的生效以及在团队中如何持续维护它。1. 先回答一个问题Anti-Slop 到底在对抗什么1.1 Slop 不只是“废话”Slop 这个词在 AI 圈子里流行起来指的不是所有冗长内容而是那种“流畅但信息量极低”的生成文本。它看起来通顺、结构完整读完之后你却抓不住任何具体信息。典型表现是大量使用“值得注意的是”“众所周知”“总而言之”这类连接词每一段都在重复上一段的观点形容词不少动词和数字很少。这类输出对技术场景的伤害是具体的。技术文档、代码注释、故障排查报告的共同特点是读者是为了“执行”而读不是为了“感受”而读。如果一段说明可以被删除三分之一而不损失任何操作步骤那这三分之一就是 Slop。更麻烦的是Slop 的评价标准带有场景性。同一句话在文学创作里可以叫“风格”在运维手册里就叫“噪声”。因此一个有效的 Anti-Slop Skill 不可能只靠一句“不要写废话”完成它必须把不同场景下的质量标准拆成可检查的规则。1.2 为什么一句“别说废话”没用原因很简单“废话”是意图不是指令。“在当今时代”这句是不是废话在绝大多数技术文档里是但在一篇时评里未必是。“请给出简短的回复”到底多短是 50 字还是 200 字模型没有你的上下文它只能猜。当你第一次说“别写废话”模型会删掉最明显的套话但当你再追问时它没有持续的质量判断能力只能继续从概率上生成它认为“写得更仔细”的句子于是 Slop 又回来了。这不是模型能力不够而是我们给它的约束不够结构化。这也是 Anti-Slop Skill 存在的意义它把“质量好”这个主观目标拆成模型在生成时能够逐条执行的客观规则。2. 一份 1986 年飞行手册为什么能当参考2.1 手册是给“必须执行”的人写的前阵子翻到一份 1986 年出版的飞行手册。注意让我印象深刻的不是飞机本身而是它的写作方法。飞行手册的读者很特殊他可能在极端条件下依靠这本手册操作一台复杂机器操作错误会有严重后果。因此手册里几乎没有“安全很重要”“请谨慎操作”这类话因为读者默认就是要执行任务的人不需要被说服只需要被准确告知。整本手册的结构相当固定大体可以分成几个模块限制章节明确什么是允许的、什么是不允许的正常程序按任务阶段给出逐步操作非正常程序和应急检查单面向异常状态性能数据表用表格和数字描述边界条件系统描述分系统讲原理。这种结构不是出版者随手排的而是按“任务执行顺序”和“风险等级”组织的。它假设读者面临的是一个连续的操作过程而手册的价值就是把每个阶段要做什么、做到什么标准、出现异常先检查哪几项提前定义清楚。2.2 模型和“照着手册执行的人”很像我当时产生了一个判断大语言模型的输出行为和“照着手册执行任务的人”非常接近。模型没有天然的“质量手感”它是在逐 token 预测下一个词真正能稳定控制输出质量的不是用户的一句口头要求而是被写进上下文里的规则结构。用户说“好好写”模型不知道标准但如果上下文里有一本“手册”里面写着“输出前逐句检查删掉不能增加信息的句子”“禁止使用‘在当今时代’等空泛开头”“每个结论必须给出依据”模型的输出就会显著偏向这些规则。这不是玄学而是上下文约束在起作用。也就是说一份好的飞行手册证明了在复杂任务里稳定性来自流程和检查单而非个人发挥。这个原则完全可以迁移到 AI Skill 设计中。2.3 真正值得借鉴的四个模块飞行手册对我最大的启发是把“质量”拆成了四个可以独立维护的模块限制清单明确什么不能做。对应到 AI 输出就是禁止使用的表达、必须删掉的空话模式。正常程序明确按什么顺序输出。对应到 AI 输出就是先写结论、再写依据、再给示例的流程。检查单在交付前逐条自检。对应到 AI 输出就是“有没有模糊词”“有没有重复观点”“结论有没有对应论据”。性能边界明确交付物的规格。对应到 AI 输出就是字数范围、格式要求、是否必须包含代码块。一旦把 Anti-Slop 从“一句口号”升级成这四个模块它就不再依赖模型的临场发挥而是变成一套稳定的执行规则。3. 从手册到 Skill把规则翻译成机器可听懂的文件3.1 Claude Agent Skills 到底是什么在 Claude 的生态里Skill 是一种把“指令 资源 工具”打包成文件的能力。一个 Skill 通常是一个文件夹里面有一个 SKILL.md 主文件可能还有脚本、模板、示例等辅助文件。SKILL.md 的顶部有一段 YAML 格式的元信息其中最关键的是 description它决定了模型在什么情况下会主动调用这个 Skill。可以把 Skill 理解成给模型安装在场景里的“职业说明书”。没有 Skill 时你每次都要在对话里重复你的要求有 Skill 后模型只要判断当前任务匹配某个 Skill 的 description就会主动加载对应的规则文件按文件里的流程执行。对 Anti-Slop 来说这意味着质量规则可以被复用、被版本管理、被团队共享。今天写好的检查单不再只是某次对话里的一句提示词而是一个独立的工程资产。3.2 飞行手册模块与 Skill 文件的映射关系我建议把飞行手册的四个模块直接映射成 Skill 里的几种内容飞行手册模块Skill 中的实现作用Limitations 限制清单SKILL.md 中的禁止项列表明确哪些词、哪些句式不能出现Normal Procedures 正常程序SKILL.md 中的输出步骤规定先写什么、后写什么Checklists 检查单checklist.md 等独立文件输出前逐条核对质量指标Performance 性能边界SKILL.md 中的格式与长度要求规定字数、结构、必要元素这样的设计有一个直接好处每个模块都可以单独测试和修改。你觉得检查单太繁琐只改 checklist.md 就行你觉得禁止词列表不够只增补限制清单就行。规则之间不会互相纠缠。3.3 一个反直觉的设计点很多人写 Anti-Slop Skill 时会把大量精力放在“禁止词列表”上这其实是反的。禁止词列表有用但它针对的是表层特征真正决定输出质量的是正常程序和检查单。举个例子模型输出“通过优化系统参数显著提升了系统稳定性”这句话里面没有任何禁用词但它仍然是 Slop因为它没有说清了什么参数、怎么优化、提升了多少。只靠禁止词列表永远拦不住这类“正确但空洞”的句子。只有检查单里加了“每个结论后是否跟了具体依据”这一条模型才会真正修改表达方式。这是 Anti-Slop Skill 设计中最容易被忽略的一点不要只堵负面要定义正面流程。4. 环境准备与前置条件4.1 需要什么运行环境要跑通下文示例你需要一个支持 Claude Agent Skills 的 Claude 环境。常见的路径包括 Claude Code 命令行工具以及 Claude 桌面端或网页端中支持 Skill 的版本。这里不展开安装步骤因为工具更新很快请以当前官方文档为准。需要的基础条件大致如下一个可用的 Claude 账号并开通支持 Agent Skills 的订阅或权限如果使用 Claude Code需要准备对应的运行环境。版本要求请以官方文档为准本文重点演示通用思路本地有合适的目录权限用于创建 Skill 文件夹。这样做的好处是你可以先在小范围验证 Skill 设计确认规则有效后再考虑同步给团队。4.2 Skill 应该放在哪里Skill 的存放位置通常有两种个人级目录和项目级目录。个人级目录好处是全局生效适合“无论写什么都要控制废话”的习惯项目级目录适合特定团队项目比如某个项目要求提交说明必须包含测试结果和回滚方案。具体路径因客户端版本而异。常见做法是~/.claude/skills/ # 个人级 Skill 目录 .claude/skills/ # 项目级 Skill 目录在最终确定前建议先查看官方文档确认目录结构。下文示例默认放在个人级目录~/.claude/skills/anti-slop/4.3 最小验证路径不要一开始就设计十几个规则。先建一个最小版本只放一个 SKILL.md包含三条规则然后跑一个真实任务看模型是否自动加载、是否按规则执行。跑通后再逐步添加限制清单和检查单文件。5. 完整示例一个最小 Anti-Slop Skill5.1 文件结构这里给出一套可直接复制的文件结构~/.claude/skills/anti-slop/ ├── SKILL.md ├── checklist.md └── examples/ └── before-after.mdSKILL.md主规则文件包含触发描述、输出流程、限制清单。checklist.md输出前自检清单让模型在交付前逐条核对。examples/before-after.md一个典型对比示例帮助模型理解“什么叫改写后的输出”。5.2 SKILL.md 主文件--- name: anti-slop description: 对即将输出的文本进行质量把关减少空话、套话和低信息密度表达。适合撰写技术文档、代码注释、故障排查报告、评审意见、教程和需要高信息密度的回复时使用。当用户要求“别写废话”“直接说重点”“认真检查输出质量”时应主动应用本规则。 --- # Anti-Slop 输出规范 ## 目标 本 Skill 的目标是提高输出的信息密度让每个句子都承担可验证的信息而不是堆砌连接词和修饰词。 ## 输出前必须执行的三个步骤 1. 逐句过滤先写出完整回复然后逐句判断“删掉这句话是否损失任何信息”。不损失就删。 2. 替换模糊表达把“进行了优化”改成“调整了连接池最大连接数从 10 调到 50”把“显著提升”改成“请求耗时下降 35%”。 3. 确认每个判断都有依据如果一句话是结论则其后必须跟一个具体论据否则删除该结论。 ## 禁止项 - 禁止使用“在当今时代”“随着技术的发展”“众所周知”“值得注意的是”“综上所述”等空泛开头或过渡。 - 禁止同一语义在一篇回复中重复出现两次以上。 - 禁止使用“非常重要”“具有重要意义”“值得关注”等没有信息量的评价词。 - 禁止用“可以这么说”“某种程度上”“众所周知”等模糊限定词代替事实。 ## 格式要求 - 技术教程类内容先给最终结论再给操作步骤最后给验证方式。 - 代码块必须标注语言类型且包含关键注释。 - 字数不是目标信息量才是能短则短但不得删掉必要的操作细节。这段文件的核心是把“输出前检查”变成三个固定步骤。注意步骤顺序先过滤句子再替换模糊表达最后核对结论依据。顺序很重要因为先删句子可以减少后续替换的工作量。5.3 checklist.md 辅助文件# 输出前检查单 在交付最终回复前逐条核对以下问题。任何一项为“否”都需要修改后再输出。 1. 是否存在删掉后不影响信息量的句子如果没有此项为“是”。 2. 是否存在“进行了优化”“实现赋能”“提升效率”这类没有具体对象的模糊动词 3. 每个具体结论后面是否跟了至少一个证据、数字或步骤 4. 全文是否没有重复表达同一个观点 5. 是否完整覆盖了用户问题中的所有要求而不是只挑容易写的部分回答检查单的意义在于给模型一个“终检”动作。很多模型输出 Slop不是因为它不知道规则而是生成过程中没有机会回头检查。有了这个文件模型在输出前会多一轮自我审视。5.4 examples 对比示例# Before 示例 “在现代软件系统架构中数据库连接池作为一项非常基础且重要的技术对于系统性能的稳定性和高可用性具有十分关键的作用。在高并发场景下如果连接池参数配置不当往往会对系统的整体表现产生负面影响。因此我们必须重视连接池的配置优化工作采取一系列合理措施以确保系统能够平稳高效运行。” # After 示例 “连接池默认配置无法覆盖高并发场景。先确认三个参数最大连接数、最小空闲连接数、获取连接超时时间。以 HikariCP 为例当等待获取连接的时间超过 30 秒且排队请求数持续上升时调大 maximumPoolSize 并不能解决所有问题还需要同时检查数据库端最大连接数和应用所在主机的文件句柄数。” # 对比结论 Before 段落的问题没有给出任何可执行信息删掉任意一句都不影响理解。After 段落的问题标准每句话都对应一个参数、一个条件或一个操作步骤。示例文件的价值是给模型提供“正面范例”。这类比只写禁止项有效得多因为它让模型看到一个合法的输出长什么样而不是只知道什么不能做。5.5 如何让 Claude 使用这个 Skill使用方式分为自动触发和手动提示两种情况。自动触发依赖 SKILL.md 中的 description。当用户的任务与 description 中描述的场景匹配时模型会主动加载 Skill。如果模型没有自动触发你可以明确要求使用它。例如对 Claude 说“请加载 anti-slop Skill按里面的检查单写一段数据库连接池说明。”这会强制模型读取并应用该 Skill 中的规则。实际效果可以用下面这段对话示意用户帮我写一段 Redis 缓存冷启动的处理方案。 Claude已应用 anti-slop 检查单。下面按“结论—步骤—验证”输出。关键在于你不需要每次重复你的质量要求。只要 Skill 的描述和内容设计合理质量约束会自动进入模型的上下文。6. 效果验证怎么判断 Skill 真正生效6.1 用同一任务做对照验证 Skill 是否生效最直接的方法是做一个对照实验用同一个任务分别在“加载 Skill”和“不加载 Skill”的情况下跑一次比较两次输出。我建议选一个有代表性的任务比如“请写一段说明介绍项目中如何决定数据库连接池的最小空闲连接数。”不加载 Skill 的输出很可能出现空泛叙述加载 Skill 后输出应该变成“先看监控指标再看数据库端限制最后给出参数建议”这类结构。差异越大说明 Skill 的约束力越强。6.2 判断成功的三条标准判断一个 Anti-Slop Skill 是否生效不要凭“感觉更像人写的”而是看三条可量化的标准模糊词出现频率是否下降。比如“显著”“非常”“重要”“值得关注”这类词在同等字数下的出现次数明显减少。结论与依据是否成对出现。检查每个判断句后面是否跟了数字、事实或具体的操作条件。可执行性是否提高。把输出当作操作手册看读者能否不追问就完成操作。如果还需要问“到底怎么配置”说明信息密度不够。这三条标准可以在评审阶段直接套用也可以作为团队检查提交内容的统一口径。6.3 如果失败先从两个方向排查对照实验不理想时先不要急着加规则。第一个方向是看 description 是否写得太模糊。如果 description 只写了“帮助提升输出质量”模型很难判断何时触发把它改成“撰写技术文档、代码注释、故障排查报告时”这种带场景的描述触发率会明显上升。第二个方向是看规则是否过于抽象。SKILL.md 里如果写“输出要有深度”模型无法执行改成“每个结论后必须跟一个数字或步骤”后模型就能照做。规则能被 check才叫规则。7. 常见问题与排查方法问题现象可能原因排查方式解决方案Skill 没有被自动触发description 与任务场景不匹配查看模型是否输出了 Skill 加载相关提示或在对话里直接询问“你加载了哪些 Skill”重写 description加入具体的场景词例如“技术文档”“代码注释”“评审意见”模型加载了 Skill 但输出仍啰嗦规则条目太多模型上下文取舍时忽略了关键规则检查 SKILL.md 的规则数量是否超过 8 条精简到 5 条以内把最核心的规则放在文件最前面输出变得过于简短缺少必要细节负面清单过强正面流程缺失观察输出是否被“禁止”成车轱辘话在 SKILL.md 中增加“必须包含的要素”清单例如“必须包含具体参数或步骤”规则与用户当前指令冲突Skill 规则优先级不明确检查用户指令是否明确要求另一种风格在 SKILL.md 开头写明“当用户指令与本规则冲突时以用户最新指令为准”团队其他人使用同一个 Skill 效果不同不同客户端版本的 Skills 解析有差异确认团队环境版本一致在 Skill 目录中增加 README写明最低版本要求检查单文件没有被读取Skill 主文件没有引用辅助文件查看 SKILL.md 中是否指示模型读取 checklist.md在 SKILL.md 中加入“输出前必须打开 checklist.md 逐条核对”的指令需要特别提醒一点不要试图通过 Anti-Slop Skill 绕过系统的安全规则或改变模型的安全边界。Skill 的定位是输出质量约束不是解除限制。任何质量检查都应在系统安全规则允许的范围内工作。8. 最佳实践与工程建议8.1 把 Skill 当作代码管理Skill 文件是纯文本完全可以纳入 Git 版本管理。我建议团队为 Skill 单独建一个仓库每次修改都走代码评审流程。评审的重点不是语法而是“这条规则是否可检查”“这条规则是否和现有规则冲突”。当模型升级后同一套规则的表现可能变化。因此Skill 应该配套一组测试任务每次模型版本更新后跑一遍回归测试。测试任务不用多三到五个覆盖典型场景即可。8.2 负面清单与正面示范成对出现只写“不要写废话”的 Skill 是失败的。每个负面规则最好都配一个正面示范。最直接的做法是在 examples 目录里维护一组 before-after 对比让模型在不确定时能找到一个“合法的改写方向”。如果你要新增一条禁止项比如“禁止在开头使用设问句”同时就要在示例里展示一个“没有设问句但读起来依然自然的开头”。没有正面示范的禁止项很容易让输出变得生硬。8.3 description 是一切的上限在 Agent Skills 里description 决定了模型是否调用这个 Skill也就是 Skill 的“入口”。一个写得差的 description会让规则文件形同虚设。写 description 时不要用形容词要用场景。把“提升输出质量”改成“撰写技术文档、代码注释、故障排查报告、评审意见时”触发率会明显不同。原因是模型判断的是“当前任务是不是这个场景”而不是“当前任务需不需要高质量”。8.4 不要一次堆太多规则规则越多模型在有限上下文里对每条规则的注意力就越低。我见过不少团队的 Anti-Slop Skill 写了二十多条规则结果模型只执行了前三条。真正有效的 Skill核心规则控制在 5 条左右辅助规则可以放到单独的文件里。主文件只承担“流程 最关键的限制”其余细节由检查单和示例文件承载。8.5 注意安全边界Skill 会进入模型的上下文因此绝对不要在 Skill 文件里存放任何密钥、Token 或内部敏感信息。另外如果 Skill 被配置为自动执行某些操作比如修改文件或调用工具必须增加人工确认机制。质量控制工具不应该变成静默执行的自动化脚本。团队共享 Skill 时还需要考虑审核机制。不要把个人习惯直接推到全团队先在小范围试用确认规则不会影响正常业务表达后再推广。9. 小结与下一步回看开头的那个问题为什么“不要说废话”经常无效因为它是一条意图不是一套流程。1986 年飞行手册给我的真正启发不是某个具体的句子而是那个稳定的结构限制清单、正常程序、检查单、性能边界。把这套结构写进 Anti-Slop Skill输出质量的稳定性会明显好于只加一句“认真一点”。下一步的实践建议很明确不要试图一次做出一个完美的 Skill。先复制本文中的最小 SKILL.md放到你的 Skill 目录里选一个你日常真实遇到的写作任务跑一次对照实验。观察模型在哪里仍然会写废话再针对那一个点补充规则。一轮一轮迭代比一次设计二十条规则更有效。如果你的团队每天都和 AI 生成的长文、评审意见、技术文档打交道我建议把 Anti-Slop 这类质量约束当作团队基础设施来维护而不是某个人电脑里的临时提示词。它越是能被复用、被测试、被讨论你对 AI 输出质量的掌控力就越强。