mcpField
S
slop-detector

slop-detector

github.com/athola文档处理343176 次安装1 天前更新
代码仓库

关于 slop-detector

用于检查文档和代码注释中疑似 AI 生成文本特征的技能。它会结合标记密度与上下文评分,并报告文件及行号,供人工审阅。

主要功能

  1. 01按密度进行文本评分
  2. 02结合上下文分类标记
  3. 03语言检测与手动指定
  4. 04英式拼写转为美式拼写
  5. 05报告文件和行号

适用场景

  1. 01检查技术文档中的 AI 写作特征
  2. 02审阅叙述文本中的标记聚集
  3. 03检查 Python 注释和文档字符串

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/athola/claude-night-market --skill slop-detector

安装后在 Claude Code 中输入/slop-detector确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

modules/
anti-goals.md
audience-targeting.md
ci-integration.md
cleanup-workflow.md
config-file.md
document-economy.md
empirical-baseline.md
evidence-backed-claims.md
fiction-patterns.md
hallucination-detection.md
identity-and-voice-leaks.md
language-handling.md
remediation-strategies.md
reporting.md
spelling-normalization.md
structural-patterns.md
structured-finding-output.md
stub-and-deferral.md
vocabulary-patterns.md

详细介绍

AI 填充文本检测

填充文本是密度问题,不是词汇问题。

单独出现一个“delve”没问题。如果“delve”出现五次,附近还有“tapestry”和“embark”,那就是生成文本。此技能会评估每 100 个词中的密度、标记聚集情况,以及整体语体是否符合文档类型。它不会禁用词汇,只会标记过于密集的用法。

不适用场景

  • 撰写替换文本(使用 scribe:doc-generator)
  • 检查内容是否偏离特定的语气配置文件(使用 scribe:voice-review)

执行工作流

先定位发现的问题,再阅读内容。

uv run --with pyyaml python scripts/slop_score.py --audit <files>

对文件或目录执行一条命令,每条发现的问题占一行,包含文件和行号,退出码为 0。它会加载 data/languages/en.yaml 中的所有类别,包括合并门控拒绝评分的类别:negative_definition、 temporal_residue、contrastive_scaffold、over_explanation、较轻微的人格化动词,以及每篇文档的否定密度读数。这些类别会标记为 (low) 或 (medium)。 第 9 步的反目标也适用于这些类别:只提示,不要自动应用。

对于 .py 路径,会读取其中的注释和文档字符串,将代码置空并保留行号。--python 可将此功能扩展到目录扫描。下文的分类已将代码注释列为目标;在采集器支持代码注释之前,此处的所有类别都仅针对 Markdown 进行检查。

以下步骤会说明各类别的含义以及如何改写。先运行脚本,以便后续步骤可以直接处理定位结果,而不必针对每种模式重新通读文档。

然后确定目标文件,并将其分类为技术文档、叙事文本或代码注释。分类结果会影响上下文感知评分:第 1 层标记在营销文案中的得分低于其在 API 参考文档中的得分。

语言检测
  • 根据文本内容中的功能词频率自动检测语言
  • 使用显式的 --lang 参数覆盖(en、de、fr、es)
  • 从 data/languages/{lang}.yaml 加载特定语言的模式
  • 如果检测置信度较低,则回退到英语
  • 请参阅 modules/language-handling.md,了解文化校准和具体的模式集
拼写规范化(英式英语转美式英语)

默认情况下,将任何扫描文档中的英式拼写转换为美式拼写,除非文档通过 .slop-config.yaml(spelling: british)或逐词允许列表选择不转换。这是一项独立于填充文本评分的一致性检查。使用经过测试的 scribe.spelling 函数(find_british_spellings、to_american);两者都会保留大小写,并跳过代码、行内代码和 URL。

加载:@modules/spelling-normalization.md

词汇和短语检测

加载:@modules/vocabulary-patterns.md

标记分为三个置信度层级。第 1 层词汇(“delve”、“multifaceted”、“leverage”)在 AI 文本中的出现频率远高于人类文本。第 2 层涵盖依赖上下文的过渡词(“moreover”、“subsequently”)。第 3 层涵盖空洞的短语(“In today's fast-paced world”、“cannot be overstated”)。

词汇语境人类常用替代词
delve“delve into”探索、研究、查看
tapestry“rich tapestry”混合、组合、多样性
realm“in the realm of”在、在……之内、关于
embark“embark on a journey”开始、着手
beacon“a beacon of”示例、典范
spearheaded正式归因领导、发起
multifaceted描述复杂性复杂、多样
comprehensive描述范围全面的、完整的
pivotal标示重要性关键的、重要的
nuanced表示精妙程度微妙的、细致的
meticulous/meticulously标示用心程度认真、细致
intricate标示复杂性详细、复杂
showcasing表示展示展示、呈现
leveraging商业行话使用
streamline表示优化简化、改进
第 2 级:中等置信度标记(每项得分:2 分)

常见但取决于上下文:

类别词语
过度使用过渡词moreover、furthermore、indeed、notably、subsequently
强度词扎堆significantly、substantially、fundamentally、profoundly
多重模糊措辞potentially、typically、often、might、perhaps
行动夸大revolutionize、transform、unlock、unleash、elevate
空洞强调crucial、vital、essential、paramount
第 3 级:短语模式(每项得分:2–4 分)
短语得分问题
"In today's fast-paced world"4空洞的开场白
"It's worth noting that"3填充语
"At its core"2位置上的惯用表达
"Cannot be overstated"3空洞强调
"A testament to"3归因陈词滥调
"Navigate the complexities"4商务套话
"Unlock the potential"4营销套话
"Treasure trove of"3过度使用的比喻
"Game changer"3流行套话
"Look no further"4推销话术
"Nestled in the heart of"4旅游写作陈词滥调
"Embark on a journey"4过度煽情
"Ever-evolving landscape"4技术领域陈词滥调
"Hustle and bustle"3填充语

第 3 步:结构模式检测

加载:@modules/structural-patterns.md

破折号过度使用

这是 Wikipedia、Field Guide 和 Algorithmic Bridge 中最常被提及的 2026 年 AI 特征。检测分为两种模式:

审查模式(法证分析,适用于未知文本):

  • 每 1000 个词 0–1 个:正常的人类写作范围
  • 2–4 个:偏多,需检查用法
  • 5 个以上:明显的 AI 信号

预防模式(适用于 Agent 刚生成的文档):

  • 目标为零。每个破折号都应记录为一项发现。
  • 用逗号(插入语)、括号(补充说明)、冒号(定义)或句号(分开不同想法)替换。完整替换表见 modules/structural-patterns.md § 破折号分析。
# Count em dashes in file
grep -o '—' file.md | wc -l
三项并列检测

AI 喜欢使用三个带有头韵的词组成一组:

  • “快速、高效且可靠”
  • “清晰、简洁且引人入胜”
  • “稳健、可靠且有韧性”

模式:形容词、形容词和形容词,且读音相似。

列表与正文比例

统计项目符号数量与段落句子数量:

  • >60% 为项目符号:AI 倾向
  • 以表情符号开头的项目符号:技术文档中明显的 AI 信号
句长一致性

测量句子长度的标准差:

  • 差异较小(SD < 5 个词):AI 式单调
  • 差异较大(SD > 10 个词):人类写作的变化
段落对称性

AI 会生成长度均匀的“块状”文本。 检查段落的词数是否集中在相近范围。

第 4 步:身份与语气泄漏排查(P0)

加载:@modules/identity-and-voice-leaks.md

有些模式并非拙劣文风,而是 AI 生成文本泄漏到已发布内容中的直接证据。 此类别中只要匹配一处,无论其他评分如何,审核都会失败。

扫描以下内容:

  1. 身份泄漏(“As a large language model”“as of my training cutoff”“I cannot provide”)——严重程度:严重,不接受任何例外。
  2. 对话语气泄漏(“Hope this helps!”“Great question!”“Sure!”),但成绩单区块内除外。
  3. 对结构的自我叙述(“In this section, we will cover...”“Let's dive into...”“By the end of this guide...”)。
  4. 摇摆式保留态度(“While X has its merits, it's not without its challenges”)。
  5. 对比结构,包括用于句首或句尾的结构:既包括对比性否定(“not just X, but Y”“It's not X, it's Y”,以及句尾的“It's X, not Y”/“Y, not X”),也包括肯定式对照(“Less X, more Y”“Where others X, we Y”)。除非确有必要,否则一律避免;只有当对比所承载的信息在删去对比后无法保留时才保留。句尾的系词结构(“It's a tool, not a toy”)最容易被忽略,因为句首看起来像是普通定义。

完整模式目录和误报指导请参阅该模块。

第 4.5 步:谄媚模式检测

这对对话或指导类内容尤其重要(补充身份与语气泄漏模块的第 2 类):

短语问题
“I'd be happy to”谦卑顺从的开场白
“Great question!”空洞的肯定
“Absolutely!”过度赞同
“That's a wonderful point”奉承
“I'm glad you asked”填充语
“You're absolutely right”谄媚

这些短语不提供任何信息,只会暴露生成内容的痕迹。

步骤 4.6:第 5 级 / 2026 年模式(严格预防)

2026 年跨来源共识(Wikipedia Signs of AI writing、Algorithmic Bridge 10 Signs、Ignorance.ai Field Guide、Stop-Slop Claude skill、George Kao、ContentBeta、 OliviaCal)指出,少数几种表达模式主导着 GPT-5 之后 / Claude-4.5 之后的文风。每种模式都在 @modules/vocabulary-patterns.md(词汇形式)和 @modules/structural-patterns.md(结构形式)中有详细说明。

模式形式重要原因
过度使用破折号将 — 用作修辞停顿2026 年最常被引用的单一特征
用加号表示“和”在散文中写成 “hooks and skills”明显特征:人类会使用“和”
空间系词“lives in”、“sits at”、“stands as”、“boasts”无生命的主语搭配有生命主体的动词
否定平行结构(对比性否定)“Not X but Y”、“No X. No Y. Just Z.”、“No X, no Y, no Z”、“It's not X, it's Y”、“It's X, not Y”、“Y, not X”没有论证内容的修辞脚手架
对比平行结构(肯定式对偶)“Less X, more Y”、“Where others X, we Y”、“Humans propose; machines dispose”人为制造的警句效果;没有“not”的同类脚手架
清嗓式开场白“Here's the thing,”、“Look,”、“Let that sink in.”毫无信息的篇章标记
三段式短句“Focused. Aligned. Measurable.”只有节奏,没有信息
重要性词组“stands as a testament to”、“marks a turning point”只宣称重要,却不予以证明
技术文本中的智能引号使用 "text" / "text",而不是 "text"从文字处理软件粘贴的痕迹
分号拼接“The system is fast; it scales”用散文分号连接两个独立分句。除非绝对必要,否则应改写为两个句子。各项含逗号的列表不在匹配范围内
否定式替代说法“never guesses instead of measuring”、“does not retry rather than report”通过拒绝做什么来定义事物;应说明它会做什么
循环 / 级联词汇“unpack”、“surface”(动词)、“a quiet shift”2026 年系统理论式矫饰
表演式诚实“to be honest”、“Honestly,”、“An Honest Review”人为制造真实感
专业性标志词“survey the prior art”、“state of the art”、“body of work”在非学术文本中刻意彰显严谨
分词尾句“, highlighting”、“, underscoring”、“, paving the way for”虚假的分析式补充
强调拐杖语“Full stop.”、“Make no mistake”、“Read that again.”人为制造重要性的结尾语

预防规则:当文档由 Agent 自行生成后,slop 检测器会对其运行(由 /doc-generate、 /doc-polish、/update-readme、/update-docs 等自动调用),本表中的每一项匹配都算严重失败。写入前必须修正。替换表见 modules/remediation-strategies.md § 第 5 级 / 2026 年。

步骤 5:计算 Slop 密度分数

slop_score = (tier1_count * 3 + tier2_count * 2 + phrase_count * avg_phrase_score) / word_count * 100
分数评级操作
0-1.0干净无需采取行动
1.0-2.5轻微抽查并修正
2.5-5.0中等建议重写该章节
5.0+严重全文审查

第 6 步:检查文档精简度

加载:@modules/document-economy.md 和 @modules/audience-targeting.md

句子简洁是必要条件,但还不够。 文档的赘述密度可以为 0,却仍可能因篇幅过长、缺少主旨,或反复强调一切却唯独漏掉关键信息而浪费读者时间。

从以下四项检查文档(每项 0–2 分):

  1. 主旨优先:开篇是否点明唯一的核心要点?
  2. 句子分量:每个句子是否都在阐述、举例、限定或重申主旨?
  3. 重复规则:是否重申主旨(好),同时删去无关重复(也好)?
  4. 受众契合度:是否声明了读者层级,并且每个章节都服务于该层级?只服务于更高层级的内容应提取到深入探讨文档中,绝不能删除。

第 4 项需要明确读者。如果文档没有说明读者是谁,请先询问,不要猜测:modules/audience-targeting.md 包含层级表和苏格拉底式提问清单。创意内容不适用该模块的范围,因此跳过第 4 项。

将句子层面的赘述分数与文档精简度分数合并。两项都必须达标。完整评分标准、读者时间预算表和示例详见 modules/document-economy.md。

第 7 步:清查幻觉与存根

加载:@modules/hallucination-detection.md 和 @modules/stub-and-deferral.md。

幻觉不是赘述:它是用自信的措辞表达错误信息。始终为 P0。

检查以下内容:

  1. 虚构的代码引用:正文中所有用反引号括起的标识符、函数名或文件路径都必须存在于代码库中。
  2. 虚构的依赖项:每个推荐的 pip install / cargo install / npm install 都必须能在相关注册表中找到(防止 slopsquatting)。
  3. 失效的 URL:所有引用的 URL 都应返回 200。
  4. 虚构的配置键:文档中的每个配置键都必须由代码读取。
  5. 孤立的 TODO/FIXME:必须附上已跟踪问题的链接,或删除。
  6. 含糊措辞(“目前先这样”“应该能用”“占位符”“虚设”):每一处都代表延期工作。
  7. 存根结构(todo!()、unimplemented!()、NotImplementedError):任何可通过公共 API 访问的代码路径中出现这些结构,都属于缺陷。

检测命令和严重性矩阵详见相关模块。

第 8 步:有证据支撑的声明(README 和公开文档)

加载:@modules/evidence-backed-claims.md

每项质量声明都必须有同一代码库中的证据支撑。没有证据,就删除声明。

对于“可用于生产”“快速”“内存安全”“可扩展”等声明,请核实相应证据(CI 工作流、基准测试目录、审计标记等)确实存在。该模块包含完整的声明 → 所需证据对照表,以及各语言对应的检测命令。

对于 crate/库/项目 README,这一步最能发挥作用,因为功能列表中堆砌流行词是 AI 生成内容最常见的失败模式。

第 9 步:遵守反目标(安全检查)

加载:@modules/anti-goals.md

过度清理赘述也有其自身的失败模式。

应用前述步骤提出的任何修复之前,请确认它不会违反以下反目标:

  1. 不要移除 unsafe 代码、加锁代码或带有契约的代码上的安全注释(// SAFETY:、// INVARIANT: 等)。
  2. 未明确决定升级主版本前,不要合并公共错误变体。
  3. 不要将类型化错误“简化”为装箱错误或动态错误。
  4. 即使函数很短,也不要内联具有领域专用名称的函数。
  5. 不要改动生成代码、供应商代码或历史变更日志条目。
  6. 不要自动应用 confidence: low 的发现——应提交给人工判断。

有疑问时:保留并标记该匹配项,不要删除。

完整的多轮清理工作流

要系统地清理整个项目,请按顺序运行多轮工作流。完整的十轮方法及其排序依据见 @modules/cleanup-workflow.md。摘要如下:

轮次重点
0预清理:机密信息、Agent 配置
1基础表层检查(格式化工具和代码检查工具)
2幻觉与存根(模块:hallucination、stub-and-deferral)
3身份与语气泄露
4注释问题(翻译、营销、横幅、推迟处理)
5文案问题(词汇、结构、文档精简度和有证据支持的声明)
6代码惯用法(委托给特定语言的插件)
7架构(需要大量判断;参见反目标)
8测试(同义反复、模拟、快照)
9README 和公开文档
10建立防护机制(CI、代码检查、准则)

基本规则:每个提交只处理一轮;删除优于改写;不要悄悄应用低置信度修复;如果某轮没有发现问题,就停止。

实证基线(说明严重性时引用)

加载 @modules/empirical-baseline.md,查看 2025 年第一季度至 2026 年的研究基线,为严重性权重提供依据。关键数据:

  • 与仅由人类提交的 PR 相比,AI PR 携带的各类问题总数多 1.7 倍,逻辑/正确性问题多 1.75 倍,XSS 问题多 2.74 倍,过量 I/O 约多 8 倍(CodeRabbit,2025 年 12 月)。
  • 检测到的 AI 代码问题中,92%–96% 属于可维护性问题(“代码异味”),而非正确性问题(Sonar,2025 年第四季度)。
  • 模型特定模式:GPT 会捏造内容;Claude 会遗漏内容。请据此校准审计。

如果评审中有人质疑某个发现的严重性,请引用此模块中的资料,而不是诉诸权威。

第 10 步:生成报告

如需采用评审者可逐项接受或拒绝的单条发现输出格式,请使用 @modules/structured-finding-output.md 中定义的规范结构化格式。每条发现都包含 file、line、category、severity、confidence、evidence、rationale、fix,以及(高置信度时的)diff。自动应用策略由置信度决定;绝不自动应用 confidence: low。

摘要报告格式(供人阅读):

## Slop Detection Report: [filename]

**Overall Score**: X.X / 10 (Rating)
**Word Count**: N words
**Markers Found**: N total

### CRITICAL (P0, must resolve before merge)
- Line 8: "As a large language model". IDENTITY LEAK
- Line 47: References `Client.connect_with_timeout(...)` —
  HALLUCINATION (method does not exist; closest match is
  `Client.connect`)
- Line 102: "production-ready" claim with no CI workflow
 . UNVERIFIED CLAIM

### High-Confidence Markers (vocabulary)
- Line 23: "delve into" -> consider: "explore"
- Line 45: "rich tapestry" -> consider: "variety"

### Structural Issues
- Em dash density: 8/1000 words (HIGH)
- Bullet ratio: 72% (ELEVATED)
- Sentence length SD: 3.2 words (LOW VARIANCE)

### Phrase Patterns
- Line 12: "In today's fast-paced world" (vapid opener)
- Line 89: "cannot be overstated" (empty emphasis)
- Line 134: "Let's dive into" (self-narration of structure)

### Tier 5 / 2026 Patterns
- Line 19: "The skill lives in `plugins/scribe/`" → "is in"
  (spatial copula, inanimate subject)
- Line 27: "hooks + skills" → "hooks and skills" (plus-sign
  conjunction in prose)
- Line 34: "It's not a tool, it's a transformation" →
  rewrite positively (negative parallelism / contrastive
  negation)
- Line 38: "Less config, more code" → state plainly
  (contrastive parallelism; keep only if load-bearing)
- Line 56: "Here's the thing," → delete (throat-clearing
  opener)
- Line 78: "Focused. Aligned. Measurable." → "Focused,
  aligned, and measurable." (three-fragment burst)
- Line 91: 3 smart quotes outside code blocks (Word-processor
  paste signature)

### Stub & Deferral
- Line 56: bare `// TODO: handle expired tokens` (no
  tracked issue link)
- Line 71: "for now, we recommend" (deferral language)

### Document Economy Score: X / 6
- Thesis-first: 1/2 (thesis present but buried in para 3)
- Sentence weight: 1/2 (~65% of sentences earn weight)
- Repetition: 2/2 (thesis echoed; ambient repetition cut)

### Recommendations
1. **CRITICAL**: delete line 8 identity leak before merge
2. **CRITICAL**: replace `Client.connect_with_timeout`
   with `Client.connect(opts)` and update example
3. **CRITICAL**: either add CI + version >= 1.0 to back
   "production-ready", or delete the claim
4. Replace [specific word] with [alternative]
5. Convert bullet list at line 34-56 to prose
6. Hoist the thesis (line 47) into the lead paragraph
7. Link bare TODOs to tracked issues or delete code path

### Confidence-low findings (require human decision)
- Line 89: bullet count of 8 may be appropriate for this
  enumeration; do not auto-flatten
- Line 156: `Manager` suffix may be domain-meaningful;
  verify before renaming

根据 anti-goals.md:将 confidence: low 的发现单独列出。不要悄悄应用这些发现。

模块参考

  • 叙事相关的问题标记见 modules/fiction-patterns.md
  • 修复建议见 modules/remediation-strategies.md

与修复的集成

检测完成后,使用 --remediate 标志调用 Skill(scribe:doc-generator) 来应用修复,或以报告为指南手动编辑。

退出条件

  • 已扫描所有目标文件
  • 已计算密度分数
  • 已生成报告,其中包含具体且定位到行的修复方案
  • 已标记需要立即处理的高严重性问题

评论

支持 Markdown