code-slop

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Code Slop Detection

代码Slop检测

Taste-level review of code for AI-generated patterns. Contains 24 rules across 6 categories covering comments, naming, over-engineering, defensive overdose, test slop, and style fingerprints. Where

technical-debt

measures quantitative code debt (complexity, duplication, CVEs), this skill measures the qualitative failure mode: code that passes every metric but reads like a tutorial blog post, not like a human wrote it.

从代码品味层面审查AI生成的代码模式。包含6大类共24条规则，覆盖注释、命名、过度工程、过度防御性代码、测试slop以及风格特征。

technical-debt

用于衡量量化的代码债务（复杂度、重复度、漏洞等），而本技能衡量的是定性的失效模式：代码能通过所有指标，但读起来像教程博客文章，而非人类编写的代码。

Metadata

元数据

Version: 1.0.0
Scope: PHP / Laravel + TypeScript / React (Node)
Rule Count: 24 rules across 6 categories
License: MIT

版本： 1.0.0
适用范围： PHP / Laravel + TypeScript / React（Node）
规则数量： 6大类共24条规则
许可证： MIT

Why this skill exists

本技能的存在意义

Industry data on AI-assisted code (GitClear 2025, cURL bug-bounty shutdown 2025, arXiv 2510.03029):

Refactoring collapsed from 25% to <10% of changes
Copy-paste surged 8.3% → 12.3%; code duplication rose ~8x
Code-smell rates +42–85% over human baselines
82% of AI PRs use generic catch blocks that don't distinguish error types
76% miss timeouts on external calls

None of this fails a typical CI lint. It just makes the codebase slowly unmaintainable. This skill is the lens for catching it before it ships.

The core insight: reading cost > writing cost now. The cost of writing code collapsed; the cost of reading it didn't. Code you can't quickly understand is slop, even if it works.

关于AI辅助代码的行业数据（GitClear 2025、cURL漏洞赏金计划终止2025、arXiv 2510.03029）：

重构占比从25%降至不足10%
复制粘贴占比从8.3%飙升至12.3%；代码重复度上升约8倍
代码异味率比人类基线高出42–85%
82%的AI生成PR使用不区分错误类型的通用catch块
76%的AI生成代码遗漏外部调用的超时设置

这些问题都不会被常规CI检查工具拦截，但会让代码库逐渐变得难以维护。本技能正是在代码交付前发现这些问题的工具。

核心洞察：现在阅读成本 > 编写成本。编写代码的成本大幅降低，但阅读代码的成本并未减少。即使代码能正常运行，若无法快速理解，它就是slop。

How to Audit

审计方法

When the user asks "review for AI slop", "audit code-quality taste", or "find AI patterns" — run through this skill's rules as a checklist against the changed files (PR diff) or full repo.

当用户提出“review for AI slop”、“audit code-quality taste”或“find AI patterns”等需求时，按照本技能的规则清单，对变更文件（PR diff）或整个代码库进行检查。

Audit Step 1: Determine Scope

审计步骤1：确定范围

If a PR diff is provided: audit only files changed in the diff
If files are named: audit those
If no scope: audit the whole repo, prioritized by recently-touched files (most likely AI output)

若提供PR diff：仅审计diff中变更的文件
若指定了文件：审计这些文件
若无指定范围：审计整个代码库，优先检查最近修改的文件（最可能是AI生成的代码）

Audit Step 2: Detect Stack

审计步骤2：检测技术栈

Signal	Stack
`composer.json` + `artisan`	PHP / Laravel
`package.json` (with TypeScript/React deps)	Node / TypeScript / React
Both present	Laravel + Inertia + React

信号	技术栈
`composer.json` + `artisan`	PHP / Laravel
`package.json` （包含TypeScript/React依赖）	Node / TypeScript / React
两者均存在	Laravel + Inertia + React

Audit Step 3: Run the Slop Checklist

审计步骤3：执行Slop检查清单

For each item below, output:

CLEAN — pattern not present (brief confirmation)
SUSPICIOUS — present in small amounts; flag and discuss
INFLATED — present extensively; verbose-but-functional; remediation recommended
CRITICAL — extensive AI-fingerprint presence; full review needed before merge

对于以下每一项，输出：

CLEAN — 未发现该模式（简要确认）
SUSPICIOUS — 少量存在；标记并讨论
INFLATED — 大量存在；代码冗长但可用；建议整改
CRITICAL — 存在大量AI特征；合并前需全面审查

Comments

注释

No comments that just narrate the code (
```
// create user
```
above
```
User::create(...)
```
)
No empty docblocks (
```
/** Get user */
```
above
```
getUser()
```
)

No placeholder comments left in (

// TODO: implement

// your code here

// implementation

)

No closing-brace labels (
```
} // end function
```
,
```
} // end if block
```
)

不存在仅叙述代码的注释（如
```
User::create(...)
```
上方的
```
// create user
```
）
不存在空文档块（如
```
getUser()
```
上方的
```
/** Get user */
```
）

不存在遗留的占位符注释（

// TODO: implement

、

// your code here

、

// implementation

）

不存在闭合括号标签（
```
} // end function
```
、
```
} // end if block
```
）

Naming

命名

No generic placeholder names (
```
data
```
,
```
result
```
,
```
info
```
,
```
temp
```
,
```
helper
```
)
No over-descriptive run-on names (
```
theUserWhoIsCurrentlyLoggedIn
```
)
No suffix abuse (
```
*Helper
```
/
```
*Manager
```
/
```
*Util
```
/
```
*Wrapper
```
overused without justification)
No type-in-name patterns (
```
userObject
```
,
```
resultArray
```
,
```
stringData
```
)

不存在通用占位符名称（
```
data
```
、
```
result
```
、
```
info
```
、
```
temp
```
、
```
helper
```
）
不存在过度描述的冗长名称（
```
theUserWhoIsCurrentlyLoggedIn
```
）
不存在滥用后缀的情况（无正当理由过度使用
```
*Helper
```
/
```
*Manager
```
/
```
*Util
```
/
```
*Wrapper
```
）
不存在名称中包含类型的模式（
```
userObject
```
、
```
resultArray
```
、
```
stringData
```
）

Over-engineering

过度工程

No interfaces with exactly one implementation (and no plan for a second)
No single-method classes that should be top-level functions
No wrapper functions called once that just delegate
No new dependency added when an existing one does the same job

不存在仅有一个实现的接口（且无添加第二个实现的计划）
不存在应作为顶级函数的单方法类
不存在仅被调用一次且仅做委托的包装函数
不存在已有依赖可实现相同功能却新增依赖的情况

Defensive overdose

过度防御性代码

No generic
```
catch (e) { console.error(...) }
```
blocks around code that can't throw
No null checks for impossible nulls (after non-null assertions / type-guaranteed values)
Real defensive concerns (timeouts on external calls, rate limits) ARE present

不存在对不会抛出异常的代码使用通用
```
catch (e) { console.error(...) }
```
块
不存在对不可能为null的值进行null检查（如非null断言/类型保证的值之后）
存在真正的防御性处理（如外部调用的超时设置、速率限制）

Test slop

测试slop

No tests that mock every dependency with no real behavioural assertion
No "doesn't throw" tests that just call and check for exceptions
No tests that mirror the implementation's logic (re-encoding rather than verifying)
No snapshot tests standing in for behavioural assertions

不存在模拟所有依赖却无实际行为断言的测试
不存在仅调用函数并检查是否抛出异常的“不抛出”测试
不存在镜像实现逻辑的测试（重编码而非验证）
不存在用快照测试替代行为断言的情况

Style fingerprints

风格特征

Some formatting drift exists (no codebase looks like every file ran through the most aggressive linter)
No
```
as any
```
/
```
@ts-ignore
```
/
```
@ts-expect-error
```
sprinkled where inference is hard
Repo has some
```
// HACK:
```
/
```
// XXX:
```
/ 2am comments somewhere — codebases without scars are suspect
No debug artifacts (
```
console.log
```
,
```
var_dump
```
,
```
dd()
```
,
```
dump()
```
) left in production code
No
```
if (x) return true; else return false
```
/ redundant type annotations on obvious literals

存在一些格式差异（没有代码库的每个文件都经过最严格的检查工具处理）
不存在在类型推断困难处随意使用
```
as any
```
/
```
@ts-ignore
```
/
```
@ts-expect-error
```
的情况
代码库中存在一些
```
// HACK:
```
/
```
// XXX:
```
/ 凌晨2点编写的注释——没有“痕迹”的代码库值得怀疑
不存在遗留到生产代码中的调试产物（
```
console.log
```
、
```
var_dump
```
、
```
dd()
```
、
```
dump()
```
）
不存在
```
if (x) return true; else return false
```
/ 对明显字面量添加冗余类型注解的情况

Audit Step 4: Build the Slop Ledger

审计步骤4：生成Slop记录

End the audit with a verdict table:

undefined

审计结束后生成结论表格：

undefined

Code Slop Ledger

代码Slop记录

File	Verdict	Top findings	Suggested action
app/Services/UserExportService.php	INFLATED	12 narration comments; 3 closing-brace labels; `*Helper` overuse	Strip comments; rename Helper → split into functions
resources/js/Pages/Orders/Show.tsx	CRITICAL	4 `as any` ; mock-everything tests; useless wrapper; impossible null checks	Rewrite section; remove tests; revisit type model
app/Models/Order.php	CLEAN	—	—

文件	结论	主要发现	建议操作
app/Services/UserExportService.php	INFLATED	12条叙述性注释；3个闭合括号标签；过度使用*Helper	删除注释；将Helper重命名并拆分为函数
resources/js/Pages/Orders/Show.tsx	CRITICAL	4处 `as any` ；全依赖模拟测试；无用包装；不必要的null检查	重写该部分；移除测试；重新审视类型模型
app/Models/Order.php	CLEAN	—	—

Summary

总结

CLEAN: X files
SUSPICIOUS: Y files
INFLATED: Z files (top priority: …)
CRITICAL: N files (rewrite before merge)

undefined

CLEAN：X个文件
SUSPICIOUS：Y个文件
INFLATED：Z个文件（优先处理：……）
CRITICAL：N个文件（合并前需重写）

undefined

When to Apply

适用场景

Reference this skill when:

Reviewing an AI-assisted PR before merge
Auditing a repo that has accepted heavy AI-assisted contributions
Onboarding a codebase and assessing whether it reads as human-maintained
Hardening a team's code-review checklist against AI slop
After a "vibe coding" sprint, before declaring features done
Setting up CI gates for AI-output quality

在以下场景中使用本技能：

合并前审查AI辅助生成的PR
审计接受大量AI辅助贡献的代码库
接手代码库时评估其是否为人类维护
完善团队的代码评审检查清单以防范AI slop
“随性编码”冲刺后，在宣布功能完成前
为AI生成代码的质量设置CI关卡

Step 1: Detect Project Stack

步骤1：检测项目技术栈

Most rules are stack-agnostic in concept, but examples and detection commands differ between PHP and TypeScript.

Signal	Stack	Tooling
`composer.json`	PHP / Laravel	`phpstan` , `phpcs` , `phpmd` , manual grep
`package.json`	Node / TS / React	`eslint` , `tsc --noEmit` , `knip` , manual grep

大多数规则在概念上与技术栈无关，但示例和检测命令在PHP和TypeScript之间有所不同。

信号	技术栈	工具
`composer.json`	PHP / Laravel	`phpstan` 、 `phpcs` 、 `phpmd` 、手动grep
`package.json`	Node / TS / React	`eslint` 、 `tsc --noEmit` 、 `knip` 、手动grep

Rule Categories by Priority

规则分类优先级


comments-
naming-
over-eng-
defensive-
test-
style-

Priority	Category	Impact	Prefix
1	Comments	CRITICAL	`comments-`
2	Naming	CRITICAL	`naming-`
3	Over-engineering	HIGH	`over-eng-`
4	Defensive overdose	HIGH	`defensive-`
5	Test slop	HIGH	`test-`
6	Style fingerprints	MEDIUM	`style-`


comments-
naming-
over-eng-
defensive-
test-
style-

优先级	分类	影响	前缀
1	注释	CRITICAL	`comments-`
2	命名	CRITICAL	`naming-`
3	过度工程	HIGH	`over-eng-`
4	过度防御性代码	HIGH	`defensive-`
5	测试slop	HIGH	`test-`
6	风格特征	MEDIUM	`style-`

Quick Reference

快速参考

1. Comments (CRITICAL)

1. 注释（CRITICAL）

```
comments-narration
```
— Comments that just restate the code on the next line

comments-empty-docblocks

— Generic

/** Get the user */

over a typed

getUser()

signature

comments-placeholder

—

// TODO: implement

// your code here

// implementation

// helper function

comments-closing-brace-labels

—

} // end function

} // end if block

```
comments-narration
```
— 仅重述下一行代码的注释

comments-empty-docblocks

— 类型化

getUser()

签名上方的通用

/** Get the user */

文档块

comments-placeholder

—

// TODO: implement

、

// your code here

、

// implementation

、

// helper function

comments-closing-brace-labels

—

} // end function

} // end if block

2. Naming (CRITICAL)

2. 命名（CRITICAL）

naming-generic-placeholders

—

data

result

info

temp

helper

value

naming-over-descriptive

—

theUserWhoIsCurrentlyLoggedIn

calculateTotalAmountFromItemsList

naming-suffix-abuse

—

*Helper

*Manager

*Util

*Wrapper

*Processor

overused

naming-type-in-name

—

userObject

resultArray

stringData

listOfItems

naming-generic-placeholders

—

data

、

result

、

info

、

temp

、

helper

、

value

naming-over-descriptive

—

theUserWhoIsCurrentlyLoggedIn

、

calculateTotalAmountFromItemsList

naming-suffix-abuse

— 过度使用

*Helper

*Manager

*Util

*Wrapper

*Processor

naming-type-in-name

—

userObject

、

resultArray

、

stringData

、

listOfItems

3. Over-engineering (HIGH)

3. 过度工程（HIGH）

```
over-eng-premature-interface
```
— Interface with exactly one implementation and no second on the roadmap
```
over-eng-single-method-class
```
— Classes that exist solely to wrap one function
```
over-eng-useless-wrapper
```
— Wrapper called from exactly one place, just delegating
```
over-eng-dependency-creep
```
— New library when an existing dep already does the job

```
over-eng-premature-interface
```
— 仅有一个实现且 roadmap 中无第二个实现计划的接口
```
over-eng-single-method-class
```
— 仅用于包装一个函数的类
```
over-eng-useless-wrapper
```
— 仅在一处被调用且仅做委托的包装函数
```
over-eng-dependency-creep
```
— 已有依赖可实现相同功能却新增库的情况

4. Defensive overdose (HIGH)

4. 过度防御性代码（HIGH）

defensive-generic-catch

—

try { ... } catch (e) { console.error("error") }

everywhere

```
defensive-impossible-null
```
— Null checks after non-null assertions / type-guaranteed values
```
defensive-missing-real
```
— Defensive in the wrong places; missing timeouts/rate-limits where it matters

defensive-generic-catch

— 随处使用

try { ... } catch (e) { console.error("error") }

```
defensive-impossible-null
```
— 非null断言/类型保证的值之后进行null检查
```
defensive-missing-real
```
— 在错误的地方进行防御；在需要的地方遗漏超时/速率限制

5. Test slop (HIGH)

5. 测试slop（HIGH）

```
test-mock-everything
```
— Mock for every dep; the test re-encodes the implementation, not the behaviour
```
test-doesnt-throw
```
— Tests that just call the function and assert no exception
```
test-mirror-implementation
```
— Tests whose logic mirrors the production code being tested
```
test-snapshot-abuse
```
— Snapshot tests replacing behavioural assertions

```
test-mock-everything
```
— 模拟所有依赖；测试重编码实现而非验证行为
```
test-doesnt-throw
```
— 仅调用函数并断言无异常的测试
```
test-mirror-implementation
```
— 逻辑与被测生产代码镜像的测试
```
test-snapshot-abuse
```
— 用快照测试替代行为断言

6. Style fingerprints (MEDIUM)

6. 风格特征（MEDIUM）

```
style-hyper-consistent
```
— No formatting drift anywhere; every file looks linter-perfect

style-as-any-escape

—

as any

@ts-ignore

@ts-expect-error

sprinkled where types are hard

```
style-no-hack-scars
```
— Codebase has zero
```
// HACK:
```
/
```
// XXX:
```
markers; no "geology"

style-debug-artifacts

—

console.log

var_dump

dd()

dump()

left in production paths

style-trivial-boilerplate

—

if (x) return true; else return false;

, redundant TS type annotations on obvious literals

```
style-hyper-consistent
```
— 完全没有格式差异；每个文件都像经过检查工具完美处理

style-as-any-escape

— 在类型推断困难处随意使用

as any

@ts-ignore

@ts-expect-error

```
style-no-hack-scars
```
— 代码库中没有
```
// HACK:
```
/
```
// XXX:
```
标记；没有“历史痕迹”

style-debug-artifacts

— 生产路径中遗留

console.log

、

var_dump

、

dd()

、

dump()

style-trivial-boilerplate

—

if (x) return true; else return false;

、对明显字面量添加冗余TS类型注解

Essential Patterns

核心模式

The "would this pass code review?" filter

“这能通过代码评审吗？”筛选器

For each code chunk, ask:

Could I cut a third of these comments and the code would be clearer? → likely comment slop
Do the variable names tell me what they hold, or just what type they are? → likely naming slop
Could this class be a function? → likely over-engineering
Does this catch block actually handle anything, or just log? → likely defensive overdose
Does this test fail if I break the function? → if no, test slop
Are there any
// HACK:
/
// XXX:
markers in the diff? → if no, suspicious for AI

对于每段代码，问自己：

删除三分之一的注释后，代码会更清晰吗？ → 可能是注释slop
变量名告诉我的是存储内容，还是仅类型？ → 可能是命名slop
这个类能改成函数吗？ → 可能是过度工程
这个catch块真的处理了问题，还是仅做日志？ → 可能是过度防御性代码
如果我破坏函数，这个测试会失败吗？ → 若不会，就是测试slop
diff中存在
// HACK:
/
// XXX:
标记吗？ → 若没有，疑似AI生成代码

Verdict bands (matched to AI-SLOP-Detector's scoring)

结论等级（匹配AI-SLOP-Detector的评分）

Verdict	Meaning	Action
CLEAN	< 5% of lines flagged	Ship
SUSPICIOUS	5–15% flagged	Review changes one more time
INFLATED	15–30% flagged	Strip slop, split commits
CRITICAL	> 30% flagged	Rewrite section before merge

结论	含义	操作
CLEAN	标记行数占比 < 5%	交付
SUSPICIOUS	标记行数占比 5–15%	再次审查变更
INFLATED	标记行数占比 15–30%	清理slop，拆分提交
CRITICAL	标记行数占比 > 30%	合并前重写该部分

How to Use

使用方法

Read individual rule files for detailed conventions and examples:

rules/comments-narration.md
rules/naming-generic-placeholders.md
rules/over-eng-premature-interface.md
rules/defensive-generic-catch.md
rules/test-mock-everything.md
rules/style-hyper-consistent.md

Each rule file contains:

YAML frontmatter (title, impact, tags)
Brief explanation of why the pattern is AI-fingerprint
"Incorrect" example showing the slop
"Correct" example showing the human-equivalent
Detection guidance (grep / eslint / phpstan / heuristic)
Reference link

阅读单个规则文件获取详细约定和示例：

rules/comments-narration.md
rules/naming-generic-placeholders.md
rules/over-eng-premature-interface.md
rules/defensive-generic-catch.md
rules/test-mock-everything.md
rules/style-hyper-consistent.md

每个规则文件包含：

YAML前置元数据（标题、影响、标签）
简要说明该模式为何是AI特征
展示slop的“错误”示例
展示人类编写代码的“正确”示例
检测指南（grep / eslint / phpstan / 启发式方法）
参考链接

References

参考资料

GitClear — 2025 Code-Quality Trends Report (refactoring collapse, copy-paste surge)
arXiv 2510.03029 — Investigating the Smells of LLM-Generated Code
Addy Osmani — Comprehension Debt (O'Reilly Radar)
Stack Overflow Blog — Eno Reyes Q&A on AI code quality
hardikpandya/stop-slop — sister project for prose slop
flamehaven01/AI-SLOP-Detector — Python AST scanner with 27 patterns

GitClear — 2025代码质量趋势报告（重构占比下降、复制粘贴占比飙升）
arXiv 2510.03029 — 研究LLM生成代码的异味
Addy Osmani — 理解债务（O'Reilly Radar）
Stack Overflow博客 — Eno Reyes关于AI代码质量的问答
hardikpandya/stop-slop — 用于文本slop的姊妹项目
flamehaven01/AI-SLOP-Detector — 包含27种模式的Python AST扫描器

Full Compiled Document

完整编译文档

For the complete guide with all rules expanded:

AGENTS.md

包含所有规则扩展内容的完整指南：

AGENTS.md