写技术文档最讨厌的几类文本分别是“车轱辘话”“正确的废话”和“AI 味很重的注水段落”。当你让 LLM 帮你写周报、PRD、接口文档甚至博客草稿时经常能一眼认出哪些句子是模型“注水”生成的比如 “In todays fast-paced world”在当今快节奏的世界里、delve into深入研究、Moreover此外、It is important to note值得注意的是……这些短语本身没有语法错误但堆在一起就会让一份文档显得空洞、浮夸、缺少信息量。这种文本在英文语境里被叫做llm-slop也就是由大型语言模型LLM批量生产的内容“稀泥”。怎么在写作流程里自动识别并拦截这些废话答案是用prose linting工具。而把两者结合起来的思路就是本文要聊的主题Vale-LLM-slop —— 面向 LLM 文本的 prose linting 规则实践。本文会从 llm-slop 到底是什么开始讲再介绍 Vale 这个开源 prose linter 的核心概念最后带着你从零搭建一套专门检测“AI 味”文本的 Vale 规则包并把它接入命令行、编辑器和 CI 流程。整个过程不需要太复杂的编程基础只要会写 YAML、能跑命令行就能在半天内给团队建立一道“AI 废话防火墙”。1. 什么是 llm-slop以及为什么要做 prose linting1.1 一眼认出 llm-slopAI 写作的“水词”先看一段典型的“AI 味”文本In todays fast-paced digital landscape, it is important to note that leveraging cutting-edge AI solutions can effectively optimize workflows and drive innovation. Moreover, by fostering a culture of seamless collaboration, organizations can unlock new opportunities and elevate overall productivity. In conclusion, embracing these transformative technologies is imperative for sustained success.这段文字语法完全正确读起来也“挺高级”但信息密度极低它没有告诉你任何具体方案、数据、场景或工具。如果你把 digital landscape 换成 world把 leverage 换成 use整段内容依然成立说明这些词都是可替换的“填充物”。这种文本就是llm-slop。它通常有这几个特征大量使用空泛的抽象名词solution、innovation、opportunity、synergy。堆叠无信息量的过渡词moreover、furthermore、additionally。喜欢用“开头金句”In todays fast-paced world、It is important to note that。结尾总爱喊口号In conclusion、To sum up、It is imperative to。注意llm-slop 指的是文本风格问题不是指内容是否真实。有些 AI 生成的教程干货多、代码准就不算 slop反之哪怕人类作者写产品文案也可能写得像 slop。1.2 prose linting 是干什么的传统上lint指对代码做静态检查比如 ESLint 检查 JavaScript 语法和风格。Prose linting就是把同样思路用到自然语言上检查一段文字里的拼写错误、句式问题、术语不统一、过度使用某些词等。常见的 prose linter 有Vale、textlint、write-good、alex用于检测 insensitive writing等。它们共同的特点是不是“改写”而是“提示”。它们不会帮你把句子改得更好而是在有问题的地方打一个警告把决定权还给你。为什么需要 prose linting文档团队需要维护术语表避免同一个接口在不同文档里被叫三个名字。技术写作有风格规范比如login不要写成log ine-mail统一写成email。代码注释和 README 存在大量“AI 味”文本需要批量定位。1.3 Vale-LLM-slop 在其中的定位Vale 本身是一个语法灵活、跨平台、支持自定义规则的 prose linter。Vale-LLM-slop可以理解为一个“围绕 LLM 生成文本风格检测”的规则集或项目实践。它的核心目标不是检查拼写而是检测 LLM 写作中高频出现的“水词”。检测 AI 常用的固定句式开头和结论。提醒作者把空泛表达替换成有信息量的内容。在 CI/CD 流程中自动标记“疑似 AI 生成风格”的段落。所以接下来我会先用 Vale 本身再给出如何写一套专门针对 llm-slop 的规则让你不仅能直接使用现成规则还能根据自己的业务扩展词表和句式。2. 环境准备与版本说明2.1 安装 ValeVale 是跨平台工具支持 macOS、Linux、Windows。具体安装方式会随版本变化但通常可以从以下方式中选择。macOS 下使用 Homebrewbrew install valeLinux 下如果系统里有snapsudo snap install vale或者使用 Go 直接安装前提是本机有 Go 环境go install github.com/errata-ai/vale/v3/cmd/valelatestWindows 用户可以下载预编译的二进制包或者使用choco install vale需要确认包源是否可用。本文示例采用常见的 Vale v2 或 v3 命令行语法。不同大版本之间配置兼容性略有差异如果命令输出与你本机不一致请以vale --version和vale --help为准。2.2 验证安装安装完成后在终端执行vale --version能看到类似vale version 3.x.x的输出说明已经装好。接下来先创建一个简单的测试文件mkdir -p vale-llm-slop-demo cd vale-llm-slop-demo touch test.md在test.md中写入一段普通英文文案Our platform helps teams collaborate better.然后第一次运行 Valevale test.md如果提示找不到配置文件vale.ini或.vale.ini是正常的下一步我们就来创建配置。2.3 目录结构规划一个完整的 Vale-LLM-slop 项目我建议采用下面的结构vale-llm-slop-demo/ ├── .vale.ini # Vale 主配置 ├── styles/ │ └── LLMSlop/ │ ├── AIOpening.yml # 检测“AI 味”开头句式 │ ├── AIConclusion.yml # 检测结论性套话 │ ├── Buzzwords.yml # 检测高频抽象名词 │ ├── TransitionWords.yml# 检测过渡水词 │ └── README.md # 规则说明 ├── docs/ │ └── sample.md # 示例文档 └── scripts/ └── check.sh # 批量检查脚本后面我们会按这个结构逐步搭建。3. Vale 核心概念与配置拆解Vale 的学习成本不算高核心就三块配置文件、规则文件和命令行调用。理解这三块你就能自己扩展规则。3.1 .vale.ini 配置解析.vale.ini是 Vale 的入口配置它告诉 Vale你的规则放在哪、针对哪些文件生效、错误级别是多少。# 文件路径.vale.ini StylesPath styles MinAlertLevel suggestion [*.md] BasedOnStyles LLMSlop逐项解释StylesPath指定规则目录。Vale 会在这个目录下按“样式包”找规则。例如styles/LLMSlop/就是一个样式包。MinAlertLevel允许显示的告警级别。可选值包括suggestion、warning、error。设置为suggestion时所有提示都会显示适合本地写作如果用于 CI建议调成warning或error避免太多噪音。[*.md]这是文件匹配规则。*.md表示对 Markdown 文件生效。BasedOnStyles LLMSlop启用名为LLMSlop的样式包。可以写多个用逗号分隔。如果只写以上配置Vale 还不会输出任何规则因为LLMSlop样式包里还没有规则文件。接下来看规则文件怎么写。3.2 规则文件的最小 YAML 结构Vale 的每个规则是一个单独的 YAML 文件放在styles/包名/目录下。一个最简单规则长这样# 文件路径styles/LLMSlop/Demo.yml extends: existence message: 发现可能的水词%s。 level: warning ignorecase: true tokens: - demo每个字段含义extends规则类型。existence表示只要文本中出现tokens里的词就触发提示。message命中的提示信息。%s会被替换成实际命中的词。level告警级别。可以是suggestion、warning、error。ignorecase是否忽略大小写。设为true时Demo和demo都会命中。tokens要匹配的词语列表。3.3 常见规则类型Vale 支持多种规则类型推荐掌握这几种类型作用适用场景existence检查是否存在某些词/短语检测禁用词、水词substitution把旧说法替换成新说法术语统一、推荐替换表达spelling检查拼写专业词表维护sequence检查连续出现的模式检测多余空格、连续空行其中existence和substitution是定义 llm-slop 规则包最常用的类型。4. 搭建 Vale-LLM-slop 规则包完整实战这一节我们把前面提到的概念落到实际项目里手写一套能直接运行的规则包。4.1 创建项目结构在vale-llm-slop-demo目录下执行mkdir -p styles/LLMSlop docs scripts4.2 编写核心规则检测“AI 味”开头句式很多 LLM 生成的段落喜欢用“In todays fast-paced world”这类开头。我们可以用existence定位它们。# 文件路径styles/LLMSlop/AIOpening.yml extends: existence message: 疑似 AI 味开头句式%s。建议直接切入主题避免空泛引言。 level: warning ignorecase: true tokens: - In todays fast-paced world - In todays digital landscape - In the modern era - It is important to note that - It is worth noting that - It should be noted that - It is crucial to understand that这里每命中一个短语Vale 就会给出 warning。实际项目中你还可以继续扩充比如When it comes to、In the realm of、At the end of the day等口语化、泛化表达。4.3 编写结论套话规则AI 段落结尾很爱用 “In conclusion” 或 “To sum up”。这种表达本身没问题但在技术文档里结论应该是对事实的归纳而不是套话。# 文件路径styles/LLMSlop/AIConclusion.yml extends: existence message: 检测到结论性套话%s。建议用实际结果或下一步动作替代。 level: suggestion ignorecase: true tokens: - In conclusion - To sum up - To summarize - In summary - All in all - Ultimately - It is imperative to - It is essential to4.4 编写高频抽象名词规则这是值得重点建设的一个规则因为 llm-slop 的另一大特征就是“抽象名词堆砌”。例如leverage、synergy、seamless、elevate、unlock、revolutionize等。# 文件路径styles/LLMSlop/Buzzwords.yml extends: substitution message: 检测到抽象/营销味表达%s。建议替换为更具体的技术描述。 level: warning ignorecase: true swap: leverage: use utilizes: uses synergize: collaborate seamless: smooth elevate: improve unlock: enable revolutionize: transform state-of-the-art: modern cutting-edge: current innovative: newsubstitution类型的关键字段是swap格式为关键词: 建议替换词。注意这里的“替换”只是提示不会自动修改文件。4.5 编写过渡水词规则AI 还特别爱用moreover、furthermore连接论点偶尔用没问题但频率太高说明逻辑结构散。# 文件路径styles/LLMSlop/TransitionWords.yml extends: existence message: 过渡词滥用%s。一句话里如果超过一个建议删除或改为具体的承接句。 level: suggestion ignorecase: true tokens: - moreover - furthermore - additionally - in addition - consequently - hence - thus需要说明这类规则是启发式的。thus在数学和逻辑推导里是正常表达所以我把TransitionWords.yml的 level 设置成suggestion而不是warning。阈值和级别需要根据自己的文档场景调整。4.6 配置 .vale.ini 并启用规则写好了规则文件接下来在.vale.ini里启用它们# 文件路径.vale.ini StylesPath styles MinAlertLevel suggestion [*.md] BasedOnStyles LLMSlop同时给LLMSlop包加一个说明文件# 文件路径styles/LLMSlop/README.md # LLMSlop 规则包 用于检测 LLM 生成文本中常见的“AI 味”表达包括 - 空泛开头句式AIOpening - 结论套话AIConclusion - 抽象营销词Buzzwords - 过渡水词TransitionWords4.7 准备示例文档并运行检查创建docs/sample.md# Project Proposal In todays fast-paced world, it is important to note that leveraging cutting-edge technology is essential for business success. Moreover, organizations should foster a culture of seamless collaboration to unlock innovation. Furthermore, it is imperative to embrace these transformative solutions. In conclusion, our team aims to revolutionize the industry.在项目根目录运行vale docs/sample.md预期输出类似docs/sample.md 5:5 warning In todays fast-paced world LLMSlop.AIOpening 5:39 warning It is important to note that LLMSlop.AIOpening 6:6 suggestion Moreover LLMSlop.TransitionWords 6:40 suggestion seamless LLMSlop.Buzzwords 6:75 warning unlock LLMSlop.Buzzwords 7:3 suggestion Furthermore LLMSlop.TransitionWords 8:1 suggestion In conclusion LLMSlop.AIConclusion ✖ 0 errors, 4 warnings, 4 suggestions in 1 file.看到这个输出就说明规则包已经生效。如果你发现只显示 warning、不显示 suggestion多半是MinAlertLevel没有设置成suggestion或者配置写法有误。4.8 结果说明与调优思路上面的输出中每个告警都包含文件路径和行列号。告警级别error / warning / suggestion。命中的短语。规则来源格式为样式包名.规则文件名。调优时你可以把明显误报的短语从tokens中移除或把过于敏感的规则改为suggestion。规则包的目标不是“零命中”而是帮你或你的团队在成文前快速扫一遍人工决定是否调整。5. 常见问题与排查思路5.1 Vale 提示 “No configurations were found”这个错误表示没有找到.vale.ini。Vale 默认从当前目录向上查找配置文件。解决方法是在项目根目录创建.vale.ini或者用参数指定vale --config /path/to/vale.ini docs/5.2 明明写了规则但运行时没有命中先自查这几点规则文件是否放在StylesPath对应的目录下例如StylesPath styles规则就需要在styles/LLMSlop/下。.vale.ini中是否通过BasedOnStyles LLMSlop启用了该样式包MinAlertLevel是否过低如果设为error那 warning 和 suggestion 都不会显示。规则文件里tokens是否包含了实际文本有些短语因为单词拼写或大小写问题ignorecase: false时不会匹配。排查时可以先用一个极其明确的词测试比如把规则里临时加入TODO确认整个链路没问题。5.3 中文文档生效吗Vale 支持 Unicode但很多内置规则基于英文词形变化。对于中文主要问题是分词中文没有天然空格像人工智能这种词你不能用tokens里的空格分词直接匹配。但有几种应对方案直接匹配中文短语例如tokens: [值得注意的是, 综上所述, 赋能]这种方式在中文文档里是可用的。配合正则规则匹配更复杂的模式。对中文标点、空格规范做独立规则。下面是一个中文规则示例# 文件路径styles/LLMSlop/ZhTemplate.yml extends: existence message: 检测到常见 AI 模板化表达%s。建议改为具体说明。 level: warning ignorecase: false tokens: - 值得注意的是 - 综上所述 - 众所周知 - 随着技术的不断发展 - 赋能ignorecase对中文没有意义但保留无妨。5.4 规则没生效只有内置的 Microsoft 等包生效如果你在.vale.ini里配置了Packages引入第三方包又自己写了规则要注意名字冲突。Vale 按照BasedOnStyles中声明的顺序加载同名规则可能被覆盖。建议不要把自己的规则放在官方包名目录下而是用一个独立目录名比如LLMSlop。6. 集成到编辑器与 CI 流程手动在终端跑 Vale 只是第一步。更实用的方式是把 Vale-LLM-slop 集成到编辑器和 CI 中让它在保存文件或提交代码时自动提示。6.1 编辑器插件VS Code 安装Vale扩展后在项目根目录有.vale.ini时打开 Markdown 文件会自动启用检查。JetBrains 系 IDE 也可以通过插件或外部工具集成。使用插件的好处是你可以在书写时立刻看到波浪线不用等提交后才发现问题。6.2 接入 GitHub Actions在仓库根目录创建.github/workflows/vale.ymlname: prose-lint on: push: paths: - docs/** - *.md pull_request: jobs: vale: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkoutv4 - name: Install Vale run: | curl -L -o vale.tar.gz \ https://github.com/errata-ai/vale/releases/latest/download/vale_3.x.x_Linux_64-bit.tar.gz tar -xzf vale.tar.gz sudo mv vale /usr/local/bin/ - name: Run Vale run: vale docs/注意上面脚本中的下载地址写的是示例实际使用时请到 Vale 官方仓库 Releases 页面获取当前最新版本的下载链接替换vale_3.x.x_Linux_64-bit.tar.gz。这里演示的是完整思路不要直接复制不确定的版本号。如果你希望 PR 被规则拦截可以在 CI 最后一步加上失败判断例如让 Vale 的error级别启用vale --minAlertLevelerror docs/6.3 与 AI 生成内容流程结合如果你在团队里引入了 LLM 辅助写作我建议把 Vale-LLM-slop 放在“生成后检查”环节让 LLM 生成初稿。粘贴到本地项目或文档站点。运行vale扫描。人工根据告警修改而不是直接发布。你也可以把规则集作为 Prompt 的一部分告诉 LLM“请避免在输出中使用以下短语delve into、In todays world、Moreover 等。”不过 Prompt 约束永远可能被绕过规则检查是最后的兜底。7. 最佳实践与工程建议7.1 规则集要“少量、高价值”这是我最想强调的一点。如果你一上来就维护 500 个禁用词必然导致大量误报最后团队直接把 CI 检查关掉。更好的做法是先选 20 到 30 个最典型的 llm-slop 词。运行一个月后根据命中频率调整集合。每个季度 review 一次规则。7.2 分级处理我的建议是error只留给“必须满足的硬性规范”例如公司品牌词拼写错误。warning留给“大概率需要改写”的水词如leverage、cutting-edge。suggestion留给“存在争议但建议人工再看一眼”的过渡词。这样既能过滤 slop也不至于让作者对告警麻木。7.3 让团队成员参与词表维护Vale 规则本质上是 YAML 文件可直接进 Git 仓库管理。当产品经理、技术写作人员、研发都对词表有意见时通过 Pull Request 更新即可。这比在群里口头约定“少用 AI 味表达”要可靠得多。7.4 规则包要附带测试用例社区里有些人会把规则和测试示例放在一起。Vale 本身没有强制要求但你可以为每条规则准备一个“通过样例”和“失败样例”这在后续升级时很有用。比如在styles/LLMSlop/test/下放两个文件pass.md没有 slop 的正面示例。fail.md故意触发规则的负面示例。运行检查时把这两个文件排除出正式检查路径或者单独做断言脚本。7.5 延伸思考LLM 生成时代的写作规范随着 GitHub、文档站、微博、公众号里涌现大量由 LLM 生成的文本判断“这段文字是不是 AI 写的”会越来越重要。风格检测是一种参考但它不能替代事实核查。Vale-LLM-slop 这类工具的价值在于它能快速提醒你哪些句子是套话但它不能判断内容真实与否。实际项目中建议把工具链分成三层Vale 负责文本风格和术语。事实核查靠人或靠数据库和代码库验证。AI 生成内容必须标注来源和风险级别。另外很多人关注的一个问题是 “ComfyUI 与 LLM 必须在同一台电脑上么”。这个问题和本文主题看似无关但背后思路与 prose linting 的“服务化”很像工具本身在本地运行但它检测的文本可以来自任何地方。同样地ComfyUI 和 LLM 服务也不一定部署在同一台机器上它们可以通过 HTTP API 或队列解耦。Vale 也一样你可以把.vale.ini和规则包放在统一配置中心让所有开发者的本地检查保持一致。如果要把 LLM 检测做成更大规模的服务可以考虑使用vale --outputJSON输出结构化结果方便下游处理。在 CI 中把结果聚合到仪表盘。将词表和规则放到中心化管理平台定期同步到各端。7.6 关于 Vale 与其他工具的选择如果需求只是“过滤中英文 AI 套话”Vale 和 textlint 都能胜任。Vale 的优势在于配置灵活、可扩展、有社区样式包textlint 的优势是 npm 生态对前端团队更友好。如果你要同时处理 Markdown、HTML、Latex两者都可以尝试。建议先花一小时跑通 Vale 链路再决定是否引入更多规则。8. 最后从一个词开始维护你的“AI 废话清单”Vale-LLM-slop 不是一个装完就万事大吉的神器它是一套“持续维护的可执行规则”。它能不能生效取决于你是否愿意认真维护那个 YAML 文件取决于团队是否愿意在文档评审会上多看一行 lint 输出。你可以从下面这件事开始用本文的例子创建.vale.ini和styles/LLMSlop/下几个规则文件。挑一份你最近写的、由 LLM 辅助生成的文档跑一遍 Vale。把告警中你觉得“确实很烦人”的词留下来把误报词删掉。提交这个规则包到仓库让团队成员都能用。下一步可以学习的方向包括Vale 的 Sequence 规则、自定义正则、JSON 输出、多包管理以及如何把 lint 结果接入团队内部的评审核按钮。工具本身不难难的是让团队形成“写完再看一眼 lint 输出”的习惯。如果这轮文章对你有帮助可以把它收藏起来下次拿到一篇“AI 味很浓”的文档时按文中的思路跑一遍试试。