anti-slop

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Anti-Slop: Polyglot Code Quality Audit

Anti-Slop：多语言代码质量审计

Detect and fix patterns that make code look machine-generated, over-abstracted, unnecessarily verbose, or fluently wrong. The goal is code that reads like a competent human wrote it - minimal, intentional, grounded, and clear.

This skill covers: TypeScript/JavaScript, Python, Bash/Shell, Rust, Docker/Containers, and Infrastructure as Code (Terraform, Ansible, Helm, Kubernetes manifests). The universal patterns apply everywhere; language-specific sections add targeted checks.

检测并修复那些让代码看起来像机器生成、过度抽象、冗余啰嗦或逻辑看似通顺实则错误的模式。目标是让代码看起来像是由资深开发者编写的——简洁、有目的性、贴合实际且清晰易懂。

本技能覆盖：TypeScript/JavaScript、Python、Bash/Shell、Rust、Docker/Containers，以及基础设施即代码（Terraform、Ansible、Helm、Kubernetes清单）。通用模式适用于所有场景；特定语言章节会添加针对性检查项。

When to use

使用场景

Reviewing code that feels machine-generated, bloated, or oddly generic
Simplifying code after an AI-heavy implementation pass
Auditing comment noise, naming quality, over-abstraction, and dependency creep
Looking for "ugly but technically works" code that still hurts readability or maintainability
Looking for AI-native tells: hallucinated APIs, schema drift, fallback laundering, and tests that only ratify the implementation

审查看起来像机器生成、臃肿或异常通用的代码
在依赖AI完成大量实现后简化代码
审计冗余注释、命名质量、过度抽象和依赖膨胀问题
寻找“虽能运行但可读性或可维护性极差”的代码
识别AI生成代码的典型特征：幻觉API、 schema漂移、 fallback掩饰，以及仅验证实现逻辑的形式化测试

The Three Axes of Slop

劣质代码的三个维度

Every finding falls into one of three categories:

Noise - bulk without value (redundant comments, boilerplate, unnecessary types/annotations)
Lies - subtly wrong or outdated (hallucinated APIs, deprecated patterns, stale deps)
Soul - lacks taste (over-abstraction, generic names, defensive overkill)

所有问题都归为以下三类之一：

冗余噪声 - 无价值的冗余内容（重复注释、模板代码、不必要的类型/注解）
隐性错误 - 细微错误或过时内容（幻觉API、废弃模式、陈旧依赖）
缺乏品味 - 代码风格不佳（过度抽象、通用命名、过度防御性代码）

When NOT to use

不适用场景

Correctness, logic, or race-condition bugs - use code-review
Security vulnerabilities, secret scanning, or auth review - use security-audit
One-off prompt authoring or prompt templates - use prompt-generator
Session-end documentation maintenance - use update-docs
Prose audit of docs, READMEs, wikis, emails, or creative writing - use anti-ai-prose

正确性、逻辑或竞态条件bug - 使用code-review技能
安全漏洞、密钥扫描或权限审查 - 使用security-audit技能
一次性提示词编写或提示词模板 - 使用prompt-generator技能
会话结束时的文档维护 - 使用update-docs技能
文档、README、wiki、邮件或创意写作的散文审计 - 使用anti-ai-prose技能

AI Self-Check

AI自我检查清单

Before returning any anti-slop audit, verify:

Rewrites compile/parse: every "after" code snippet is syntactically valid in the target language
Security patterns not flagged: auth, CORS, input validation, rate limiting, TLS - these are correct even if verbose (check the "What NOT to Flag" list)
Framework idioms respected: what looks like over-abstraction might be the framework's expected pattern (e.g., Next.js layouts, Django class-based views, Terraform module structure)
Existing project conventions preserved: the repo's naming style, comment density, and abstraction level take precedence over generic "clean code" preferences
Severity is honest: don't inflate Low findings to Medium to pad the report
No hallucinated replacements: verify that suggested modern alternatives actually exist in the target language version (e.g.,
```
match
```
requires Python 3.10+,
```
LazyLock
```
requires Rust 1.80+)
Grounding checked: if flagging a hallucinated API, CLI flag, resource, chart value, or config key, verify it against local types/schema/tool help or official docs before claiming it is fake
Test theater distinguished from correctness: implementation-mirroring tests, mock-heavy ceremony, and snapshots with no semantic assertions belong here; actual failing behavior still belongs to code-review
Structural duplication sweep done: compare same-role modules/classes across sibling dirs (
```
providers
```
,
```
targets
```
,
```
sources
```
,
```
clients
```
,
```
registry
```
) and either report near-twins or note why the duplication is intentional

返回任何Anti-Slop审计结果前，请验证：

重写代码可编译/解析：每个“优化后”的代码片段在目标语言中语法有效
安全模式不被标记：权限验证、CORS、输入校验、限流、TLS等逻辑即使冗余也是正确的（参考“不应标记的内容”列表）
框架约定被尊重：看似过度抽象的内容可能是框架要求的模式（如Next.js布局、Django类视图、Terraform模块结构）
现有项目规范被保留：代码库的命名风格、注释密度和抽象层级优先级高于通用“整洁代码”偏好
严重程度如实标注：不要将低优先级问题拔高为中等优先级来凑报告内容
无虚构替代方案：建议的现代替代方案需确认在目标语言版本中存在（如
```
match
```
要求Python 3.10+，
```
LazyLock
```
要求Rust 1.80+）
真实性已验证：若标记幻觉API、CLI参数、资源、Chart值或配置项，需先对照本地类型/ schema/工具帮助或官方文档确认其不存在
形式化测试与正确性区分：镜像实现逻辑的测试、重度依赖Mock的仪式化代码、无语义断言的快照属于本技能范畴；实际运行失败的问题仍归code-review处理
已排查结构重复：对比同级目录中同角色的模块/类（
```
providers
```
、
```
targets
```
、
```
sources
```
、
```
clients
```
、
```
registry
```
），要么报告近似重复的示例，要么说明重复的合理性

Workflow

工作流程

Step 1: Scope the audit

步骤1：确定审计范围

Default scope based on context:

If invoked right after writing code in this session -> self-check (review what you just wrote)
If there are uncommitted changes (
```
git diff --name-only
```
) -> recent changes
Otherwise -> ask the user

Available scopes:

Full codebase audit - scan everything, report by category
Recent changes - check git diff or recent commits
Specific files/dirs - targeted review
Self-check - review code you just wrote in this session

基于上下文的默认范围：

如果是在本次会话中写完代码后调用 -> 自我检查（审查刚编写的代码）
如果存在未提交的变更（
```
git diff --name-only
```
） -> 近期变更
其他情况 -> 询问用户

可选范围：

全代码库审计 - 扫描所有内容，按类别报告
近期变更 - 检查git diff或近期提交记录
特定文件/目录 - 针对性审查
自我检查 - 审查本次会话中刚编写的代码

Step 2: Detect languages

步骤2：检测语言类型

Scan the project to determine which languages are present. Apply the universal patterns to everything, then layer on language-specific checks. Don't apply TS checks to Python code or vice versa.

扫描项目确定使用的语言。对所有代码应用通用模式，再叠加特定语言的检查项。不要对Python代码应用TypeScript检查，反之亦然。

Step 3: Run mechanical linters first (if available)

步骤3：优先运行机械检查器（若可用）

Before scanning for slop, run standard linters to clear the low-hanging fruit:

Shell:
```
shellcheck
```
Python:
```
ruff check
```
/
```
mypy
```
TypeScript:
```
eslint
```
/
```
tsc --noEmit
```
Terraform:
```
terraform validate
```
/
```
tflint
```

IaC schema tools:

ansible-lint

helm lint

kubectl apply --dry-run=client

kubeconform

when available

Structural patterns:
```
ast-grep
```
(tree-sitter powered AST search - write rules to catch restating comments, dead code, hallucinated imports across languages. Install:
```
npm i -g @ast-grep/cli
```
. If your tool ecosystem provides
```
ast-grep
```
helper skills or templates, use them.)

Linters handle syntax issues, unused imports, and known anti-patterns mechanically. This skill focuses on what linters can't catch: taste, over-abstraction, naming quality, unnecessary complexity, and stale idioms. Don't duplicate what a linter already covers.

Per-project tools (eslint, tsc, vitest, prettier) are project devDeps, not system tools. If they're not in the project's

package.json

devDependencies

, mention to the user what's missing and let them decide whether to install. Don't run linters that aren't set up.

在扫描劣质代码前，先运行标准检查器清理简单问题：

Shell：
```
shellcheck
```
Python：
```
ruff check
```
/
```
mypy
```
TypeScript：
```
eslint
```
/
```
tsc --noEmit
```
Terraform：
```
terraform validate
```
/
```
tflint
```

IaC schema工具：

ansible-lint

、

helm lint

、

kubectl apply --dry-run=client

、

kubeconform

（若可用）

结构模式检查：
```
ast-grep
```
（基于tree-sitter的AST搜索 - 编写规则捕获跨语言的重复注释、死代码、幻觉导入。安装方式：
```
npm i -g @ast-grep/cli
```
。若工具生态提供
```
ast-grep
```
辅助技能或模板，请使用它们。）

检查器会自动处理语法问题、未使用导入和已知反模式。本技能专注于检查器无法识别的内容：代码品味、过度抽象、命名质量、不必要的复杂度和过时写法。不要重复检查器已覆盖的内容。

项目专属工具（eslint、tsc、vitest、prettier）属于项目开发依赖，而非系统工具。若项目的

package.json

devDependencies

中没有这些工具，需告知用户缺失内容并让其决定是否安装。不要运行未配置的检查器。

Step 4: Scan for patterns

步骤4：扫描问题模式

Use Grep, Glob, and Read. Read files before flagging - context matters. A pattern that looks like slop in isolation might be justified.

Before finalizing, do one explicit structural pass:

Compare same-role files across sibling directories (
```
foo/emby.ts
```
vs
```
foo/jellyfin.ts
```
, multiple
```
registry.ts
```
files, provider adapters, target wrappers)
Look for near-twin modules/classes with the same method set and only renamed nouns, IDs, or client types
If you find a repeated pattern across many files, report one representative example and mention the spread instead of silently dropping it

Classify each finding by axis (Noise/Lies/Soul - see above), action, and severity:

Action:

Fix - clearly wrong or wasteful, should change
Consider - judgment call, present it and let the user decide
Fine - looks like slop but is justified (note why and move on)

Severity (determines report ordering - high first):

High - strongly suggests fabricated or ungrounded code (hallucinated APIs, schema drift, silent swallowing used to hide uncertainty, fallback laundering)
Medium - maintainability (over-abstraction, generic naming, missing error context, logic duplication)
Low - style (verbose patterns, comment noise, redundant annotations, barrel files)

使用Grep、Glob和文件读取功能。标记前先读取文件上下文——孤立的模式看似劣质，但可能有合理理由。

最终确定前，需完成一次明确的结构检查：

对比同级目录中同角色的文件（如
```
foo/emby.ts
```
vs
```
foo/jellyfin.ts
```
、多个
```
registry.ts
```
文件、提供商适配器、目标包装器）
查找具有相同方法集、仅重命名名词、ID或客户端类型的近似重复模块/类
若发现跨多个文件的重复模式，报告一个代表性示例并提及分布范围，而非忽略

按维度（冗余噪声/隐性错误/缺乏品味，见上文）、操作建议和严重程度对每个问题分类：

操作建议：

修复 - 明显错误或冗余，应修改
考虑 - 需主观判断，列出问题让用户决定
保留 - 看似劣质但有合理理由（说明原因并跳过）

严重程度（决定报告排序 - 高优先级在前）：

高 - 强烈暗示代码为虚构或脱离实际（幻觉API、schema漂移、用静默吞异常隐藏不确定性、fallback掩饰）
中 - 影响可维护性（过度抽象、通用命名、缺失错误上下文、逻辑重复）
低 - 风格问题（冗余模式、注释噪声、重复注解、桶文件）

Step 5: Report and fix

步骤5：报告与修复

Present findings grouped by category. For each Fix-level item, show the concrete replacement. Don't just point at problems - show the better version.

按类别分组展示问题。对于所有“修复”级别的问题，提供具体的替代代码。不要只指出问题——展示优化后的版本。

Universal Patterns (All Languages)

通用模式（所有语言）

1. Comment Slop (Noise)

1. 注释冗余（冗余噪声）

The single biggest tell. Comments that narrate what code does instead of why.

Detect:

Comments restating the next line ("Initialize array", "Loop through items", "Return result", "Set variable")
Hedging ("This should work", "This might need updating", "TODO: review this")
Overconfident assertions ("This is the most efficient approach", "This handles all edge cases")
Section dividers adding no information (
```
# --- Helper Functions ---
```
above obvious helpers)
Docstrings/JSDoc on every function when signatures are self-documenting
Inline comments on every block in a shell script or Terraform file

AI agent tells (rarely appear in human code):

Docstrings on every function regardless of complexity (
```
add(a, b)
```
-> "Returns the sum")
Restating the next line in English on every block; section headers in short functions
```
@param
```
descriptions repeating the parameter name; comments on obvious ops (
```
// increment counter
```
)
Convention blindness: camelCase in a snake_case repo, JSDoc in a no-JSDoc project

Fix: Delete obvious comments. Keep only why comments - business logic, workarounds, gotchas, non-obvious decisions. If code needs a what comment, rewrite the code. A 20-line function needs zero comments if the names are good. A 200-line module might need 3-4.

Exception: Comments explaining workarounds for bugs, API quirks, or platform limitations are valuable. Also: shell scripts benefit from more comments than typical code because the syntax is less self-documenting.

最明显的特征。注释仅描述代码做了什么，而非为什么这么做。

检测项：

注释重复下一行代码的内容（如“初始化数组”、“遍历项”、“返回结果”、“设置变量”）
不确定的表述（如“这应该可行”、“这可能需要更新”、“TODO：审查此处”）
过度自信的断言（如“这是最有效的方法”、“这处理所有边缘情况”）
无信息价值的分段分隔符（如在明显的辅助函数上方添加
```
# --- Helper Functions ---
```
）
当函数签名可自文档化时，仍为每个函数添加Docstrings/JSDoc
在Shell脚本或Terraform文件的每个代码块添加行内注释

AI生成代码的典型特征（人工编写的代码中很少出现）：

无论复杂度如何，为每个函数添加Docstrings（如
```
add(a, b)
```
-> “返回两数之和”）
每个代码块都用英文重复下一行内容；短函数中添加分段标题
```
@param
```
描述重复参数名；对明显操作添加注释（如
```
// increment counter
```
）
无视项目约定：在使用snake_case的代码库中用camelCase、在无JSDoc的项目中添加JSDoc

修复方式： 删除明显冗余的注释。仅保留解释“原因”的注释——业务逻辑、临时解决方案、陷阱、非显而易见的决策。如果代码需要“做什么”的注释，应重写代码。命名得当的20行函数不需要任何注释；200行的模块可能需要3-4条注释。

例外情况： 解释bug临时解决方案、API特性或平台限制的注释有价值。另外：Shell脚本比普通代码需要更多注释，因为其语法自文档性较差。

2. Defensive Overkill (Soul)

2. 过度防御（缺乏品味）

Error handling or validation that protects against impossible scenarios.

Detect:

Try/catch (or try/except) that catches, logs, and re-raises without adding context
Null/nil/None checks after the type system or prior logic already guarantees non-null
Input validation deep inside internal functions (validate at boundaries, trust internally)
Fallback values for things that can't be missing
Shell scripts wrapping every command in
```
if ... then ... fi
```
instead of using
```
set -e
```
Terraform
```
try()
```
/
```
can()
```
wrapping expressions that can't fail

AI agent tells (guardrails humans would never write):

Try/catch wrapping every function body, catching
```
Error
```
with a generic log message
Null checks on values from functions you control that never return null
Input validation on internal helpers that only receive pre-validated data
Fallback defaults for required config that should crash loudly if missing
```
if (!response.ok)
```
after every internal call, not just HTTP boundaries

Fix: Remove pointless error handling. Validate at system boundaries (user input, API responses, env vars, external data), not on every internal call. If a catch block doesn't add context, retry, or recover - delete it.

Exception: Defensive checks on external data (network responses, deserialized JSON, user input, third-party libraries) are correct. Security patterns (auth, CORS, SSRF protection, input sanitization) should never be flagged.

针对不可能发生的场景添加错误处理或校验。

检测项：

Try/catch（或try/except）捕获异常、记录日志后重新抛出，但未添加任何上下文
在类型系统或前置逻辑已保证非空的情况下，仍进行Null/nil/None检查
在内部函数深处进行输入校验（应在边界处校验，内部逻辑可信任）
为不可能缺失的内容添加 fallback值
Shell脚本中为每个命令包裹
```
if ... then ... fi
```
，而非使用
```
set -e
```
Terraform中用
```
try()
```
/
```
can()
```
包裹不可能失败的表达式

AI生成代码的典型特征（人类不会编写的防护逻辑）：

为每个函数体包裹Try/catch，捕获
```
Error
```
并输出通用日志信息
对自己控制的、永远不会返回null的函数的返回值进行Null检查
对仅接收预校验数据的内部辅助函数进行输入校验
为必填配置添加默认值（缺失时应直接崩溃）
每次内部调用后都添加
```
if (!response.ok)
```
检查，而非仅在HTTP边界处检查

修复方式： 删除无意义的错误处理。在系统边界（用户输入、API响应、环境变量、外部数据）处校验，而非每个内部调用都校验。如果catch块未添加上下文、重试或恢复逻辑——删除它。

例外情况： 对外部数据（网络响应、反序列化JSON、用户输入、第三方库输出）的防御性检查是正确的。安全模式（权限验证、CORS、SSRF防护、输入 sanitization）永远不应被标记。

3. Over-Abstraction (Soul)

3. 过度抽象（缺乏品味）

Creating abstraction layers for problems that need 10 lines of direct code.

Detect:

Wrappers that just forward to one thing with no added logic
Abstract/base classes with a single concrete implementation
Factory functions that always produce the same type
Separate files for types/interfaces only used in one place
"Service" or "Manager" classes wrapping a single operation
Terraform modules wrapping a single resource with no added logic
Ansible roles with one task file
Shell functions called exactly once

Fix: Inline small abstractions. Delete wrappers that add no logic. A little repetition beats a premature abstraction.

Exception: Abstractions for testing (dependency injection), multiple implementations, or isolating external deps are fine even with one current impl.

为仅需10行直接代码的问题创建抽象层。

检测项：

仅转发调用无额外逻辑的包装器
只有一个具体实现的抽象/基类
始终生成相同类型的工厂函数
为仅在一处使用的类型/接口单独创建文件
包裹单个操作的“Service”或“Manager”类
包裹单个资源且无额外逻辑的Terraform模块
仅包含一个任务文件的Ansible角色
仅被调用一次的Shell函数

修复方式： 内联小型抽象。删除无额外逻辑的包装器。少量重复优于过早抽象。

例外情况： 为测试（依赖注入）、多实现或隔离外部依赖创建的抽象，即使当前只有一个实现也是合理的。

4. Verbose Patterns (Noise)

4. 冗余模式（冗余噪声）

Using 10 lines where 3 would do.

Detect (language-agnostic):

Unnecessary intermediate variables:
```
result = foo(); return result
```
Ternaries wrapping boolean returns:
```
return x ? true : false
```
Manual iteration that the language has built-ins for
Copy-pasting code blocks with tiny variations instead of parameterizing

Fix: Use the idiomatic short form for the language. See language-specific sections for details.

用10行代码完成3行就能实现的功能。

通用检测项：

不必要的中间变量：
```
result = foo(); return result
```
用三元表达式返回布尔值：
```
return x ? true : false
```
手动遍历，而语言已有内置方法可实现
复制粘贴代码块仅做微小改动，而非参数化

修复方式： 使用语言的惯用简洁写法。具体细节见特定语言章节。

5. Generic Naming (Soul)

5. 通用命名（缺乏品味）

Names that could mean anything:

data

result

response

item

temp

value

info

handler

manager

utils

helpers

common

misc

Detect:

Variables with generic names outside tiny scopes (2-3 line lambdas are fine)
Files named
```
utils.*
```
,
```
helpers.*
```
,
```
common.*
```
,
```
misc.*
```
(junk drawers)
Functions named
```
handle_x
```
,
```
process_x
```
,
```
manage_x
```
without domain specificity
Terraform resources named
```
this
```
or
```
main
```
when there are multiple of the same type
Ansible variables named
```
item
```
or
```
result
```
in complex plays

Fix: Use domain-specific names.

data

active_subscriptions

utils.sh

-> split by concern or inline.

Exception: Generic names in genuinely generic code (a

map()

callback, a type parameter

, a Terraform module's

this

when it's the only resource of that type).

含义模糊的命名：

data

、

result

、

response

、

item

、

temp

、

value

、

info

、

handler

、

manager

、

utils

、

helpers

、

common

、

misc

。

检测项：

在小范围（2-3行lambda）外使用通用命名的变量
文件名为
```
utils.*
```
、
```
helpers.*
```
、
```
common.*
```
、
```
misc.*
```
（杂乱的“抽屉式”文件）
函数名为
```
handle_x
```
、
```
process_x
```
、
```
manage_x
```
但无领域特异性
当存在多个同类型资源时，Terraform资源命名为
```
this
```
或
```
main
```
在复杂Playbook中，Ansible变量命名为
```
item
```
或
```
result
```

修复方式： 使用领域特异性命名。

data

active_subscriptions

。

utils.sh

-> 按关注点拆分或内联。

例外情况： 在真正通用的代码中使用通用命名（如

map()

回调、类型参数

、当只有一个同类型资源时Terraform模块的

this

）。

Module-level smells

模块级问题

God modules are a structural form of generic naming: the file itself has no clear identity.

Detect:

Files named
```
utils.*
```
,
```
helpers.*
```
,
```
common.*
```
,
```
misc.*
```
with 30+ functions
A single module mixing unrelated domains (auth + formatting + DB queries + file I/O)
```
utils.py
```
with functions spanning 5+ distinct concerns

Fix: Split by domain concern, not by arbitrary grouping. A 47-function

utils.py

typically contains 3-5 coherent modules (

auth_utils.py

format_helpers.py

db_queries.py

). Steps: (1) cluster functions by what they operate on or what domain they serve, (2) create a module per cluster, (3) update imports. Do not create a new junk-drawer module - each split module should have a name that describes its single concern.

Exception: Genuinely cross-cutting helpers (e.g., a

retry()

decorator used by 8 modules) can stay in a small, tightly scoped

core.py

retry.py

“上帝模块”是通用命名的结构形式：文件本身无明确定位。

检测项：

文件名为
```
utils.*
```
、
```
helpers.*
```
、
```
common.*
```
、
```
misc.*
```
且包含30+函数
单个模块混合无关领域（权限验证 + 格式化 + DB查询 + 文件I/O）
```
utils.py
```
包含5+不同关注点的函数

修复方式： 按领域关注点拆分，而非随意分组。包含47个函数的

utils.py

通常可拆分为3-5个连贯模块（

auth_utils.py

、

format_helpers.py

、

db_queries.py

）。步骤：(1) 按操作对象或服务领域对函数分组，(2) 为每个分组创建模块，(3) 更新导入。不要创建新的“抽屉式”模块——每个拆分后的模块名称应描述其单一关注点。

例外情况： 真正跨领域的辅助函数（如被8个模块使用的

retry()

装饰器）可保留在小型、范围明确的

core.py

或

retry.py

中。

6. Logic Duplication (Lies)

6. 逻辑重复（隐性错误）

Same logic written slightly differently in multiple places - a telltale sign of context-free generation.

Detect:

Near-identical helper functions in different files
Near-twin modules for adjacent integrations/providers where only names, IDs, or injected client types change
Registry classes with the same
```
Map
```
+
```
register/get/all|list/clear
```
shape repeated across domains
Thin wrappers/adapters that repeat the same mapping code for multiple backends
Same validation logic in multiple handlers/routes
Repeated inline formatting/parsing across modules
Terraform
```
locals
```
blocks computing the same thing in different modules
Ansible tasks doing the same thing with different variable names

Fix: Consolidate into a shared helper/factory/base module or keep one representative implementation and parameterize the differences. But only if truly the same - slight variations might be intentional.

Exception: Sometimes duplication is clearer than a contorted abstraction, especially when integrations are likely to diverge. Still surface it as a Consider finding if the files/classes are near-twins today.

相同逻辑在多处以略有不同的方式实现——无上下文生成的典型特征。

检测项：

不同文件中存在近乎相同的辅助函数
相邻集成/提供商的近乎重复模块，仅名称、ID或注入的客户端类型不同
跨领域重复出现相同
```
Map
```
+
```
register/get/all|list/clear
```
结构的注册类
为多个后端重复相同映射逻辑的轻量包装器/适配器
多个处理器/路由中存在相同的校验逻辑
跨模块重复内联格式化/解析逻辑
不同Terraform模块的
```
locals
```
块计算相同内容
Ansible任务中使用不同变量名执行相同操作

修复方式： 合并到共享辅助函数/工厂/基模块，或保留一个代表性实现并参数化差异。但仅当逻辑完全相同时才这么做——细微差异可能是有意为之。

例外情况： 有时重复比扭曲的抽象更清晰，尤其是当集成可能会分化时。如果当前文件/类近乎重复，仍需将其作为“考虑”项提出。

7. Stale Patterns (Lies)

7. 过时模式（隐性错误）

Code that was fine 5 years ago but has better alternatives now.

Fix: Use the modern equivalent. Check compatibility (language version, runtime, provider versions) before changing. See language-specific sections for concrete examples.

5年前合理但现在有更好替代方案的代码。

修复方式： 使用现代等效方案。修改前需检查兼容性（语言版本、运行时、提供商版本）。具体示例见特定语言章节。

8. Error Handling Anti-Patterns (Noise + Lies)

8. 错误处理反模式（冗余噪声 + 隐性错误）

Detect:

Catch/except blocks that log a generic message and continue (error is lost)
Every function wrapped in its own error handler (handle at boundaries instead)
Errors caught and re-raised as new exceptions, losing the original stack
Silent swallowing:
```
.catch(() => {})
```
,
```
except: pass
```
,
```
2>/dev/null
```
on critical commands
Shell scripts without
```
set -e
```
that check
```
$?
```
after every command manually

Fix: Handle errors at boundaries. Let errors propagate through internal code. When catching, either recover or add context and re-raise.

Exception: Fire-and-forget operations legitimately swallow errors. Comment why.

检测项：

Catch/except块记录通用消息后继续执行（错误丢失）
每个函数都包裹自己的错误处理器（应在边界处处理）
捕获错误后重新抛出为新异常，丢失原始堆栈信息
静默吞异常：
```
.catch(() => {})
```
、
```
except: pass
```
、关键命令使用
```
2>/dev/null
```
未使用
```
set -e
```
的Shell脚本，手动检查每个命令后的
```
$?
```

修复方式： 在边界处处理错误。让错误在内部代码中传播。捕获错误时，要么恢复逻辑，要么添加上下文后重新抛出。

例外情况： 无需关注结果的操作可合法吞异常。需添加注释说明原因。

9. Cross-Language Leakage (Lies)

9. 跨语言渗透（隐性错误）

AI models trained on multiple languages bleed idioms across boundaries. A reliable tell for AI-generated code.

Detect:

JavaScript patterns in Python:

.push()

.length

.forEach()

===

console.log()

Java patterns in non-Java:

.equals()

.toString()

System.out.println()

public static void

Python patterns in JavaScript:
```
len()
```
,
```
print()
```
,
```
elif
```
,
```
def 
```
, using
```
#
```
comments in JS
Shell patterns in Python: backtick usage,
```
$VARIABLE
```
syntax
Go patterns elsewhere:
```
fmt.Println()
```
,
```
:=
```
assignment,
```
func 
```
in non-Go

Fix: Replace with the target language's idiom. This is almost always an AI generation artifact - humans don't accidentally write

.push()

in Python.

训练于多语言的AI模型会在不同语言间混用惯用写法。这是AI生成代码的可靠特征。

检测项：

Python中出现JavaScript模式：
```
.push()
```
、
```
.length
```
、
```
.forEach()
```
、
```
===
```
、
```
console.log()
```

非Java语言中出现Java模式：

.equals()

、

.toString()

、

System.out.println()

、

public static void

JavaScript中出现Python模式：
```
len()
```
、
```
print()
```
、
```
elif
```
、
```
def 
```
、在JS中使用
```
#
```
注释
Python中出现Shell模式：反引号用法、
```
$VARIABLE
```
语法
其他语言中出现Go模式：
```
fmt.Println()
```
、
```
:=
```
赋值、
```
func 
```

修复方式： 替换为目标语言的惯用写法。这几乎都是AI生成的产物——人类不会在Python中误写

.push()

。

10. Plausible Hallucinations / Schema Drift (Lies)

10. 看似合理的幻觉 / Schema漂移（隐性错误）

Code that looks locally plausible because the names sound right, but it is not grounded in the actual API, schema, CLI, provider, or framework version in use.

Detect:

Functions, methods, imports, CLI flags, config keys, or resource arguments that look real but are not in local types, tool help, or docs
Mixing adjacent ecosystems: provider arguments from the wrong Terraform resource, Helm values keys that the chart never reads, Kubernetes fields from a different API version, Ansible params from the wrong module or collection
Compatibility blind spots: using a modern API without checking the repo's runtime/tool version
"Fixes" that paper over missing understanding with
```
try()
```
, optional chaining, default fallbacks, or broad catches instead of verifying the contract

Fix: Check the actual contract first - local types, generated schema,

--help

, provider docs, chart values, API version docs. Delete invented surface area. Prefer loud failure for required config over fantasy defaults.

Exception: Compatibility shims for multi-version support are fine when the codebase clearly supports multiple runtimes, provider versions, or API levels.

代码局部看似合理（名称听起来正确），但未基于当前使用的实际API、schema、CLI、提供商或框架版本。

检测项：

函数、方法、导入、CLI参数、配置项或资源参数看似真实，但不存在于本地类型、工具帮助或文档中
混用相邻生态系统：错误Terraform资源的提供商参数、Chart从未读取的Helm值键、不同API版本的Kubernetes字段、错误模块或集合的Ansible参数
兼容性盲区：使用现代API但未检查代码库的运行时/工具版本
用
```
try()
```
、可选链、默认fallback或宽泛捕获掩盖理解不足的“修复”，而非验证契约

修复方式： 先检查实际契约——本地类型、生成的schema、

--help

、提供商文档、Chart值、API版本文档。删除虚构的代码内容。对于必填配置，优先选择明确失败而非虚构默认值。

例外情况： 当代码库明确支持多个运行时、提供商版本或API级别时，多版本支持的兼容性垫片是合理的。

11. Test Theater / Self-Confirming Tests (Lies + Soul)

11. 形式化测试 / 自我验证测试（隐性错误 + 缺乏品味）

Tests can be slop too. A green test suite is not evidence if the tests were generated from the implementation and only mirror what already exists.

Detect:

Tests written after implementation that assert the exact control flow, fixture data, or internal call graph of the current code
Mock-heavy tests where every dependency is stubbed and the only assertions are call counts, method names, or log messages
Snapshots or golden files used as a substitute for semantic assertions
"Happy path only" tests paired with broad catches, default fallbacks, or defensive code that never gets exercised
Generated tests with high coverage but no clear link to the spec, acceptance criteria, or boundary behavior

Fix: Prefer spec-driven tests, behavior-level assertions, and a real RED phase. Keep mocks at the edges. If the test would still pass when the implementation is wrong in the same way, it is ceremony, not protection.

Exception: Adapter tests, logging/metrics assertions, and contract tests may legitimately assert call shapes when that contract is the behavior under test.

测试也可能是劣质的。如果测试是根据实现生成的，仅镜像现有逻辑，那么绿色测试套件不代表代码可靠。

检测项：

实现完成后编写的测试，断言当前代码的精确控制流、测试数据或内部调用图
重度依赖Mock的测试，每个依赖都被Stub，仅断言调用次数、方法名或日志消息
使用快照或黄金文件替代语义断言
“仅快乐路径”测试搭配宽泛捕获、默认fallback或从未执行的防御性代码
覆盖率高但与需求、验收标准或边界行为无明确关联的生成测试

修复方式： 优先选择基于需求的测试、行为级断言和真正的RED阶段。仅在边界处使用Mock。如果当实现以相同方式出错时测试仍能通过，那么它只是仪式化代码，而非防护措施。

例外情况： 适配器测试、日志/指标断言和契约测试在契约为被测行为时，可合法断言调用格式。

Language: TypeScript / JavaScript

语言：TypeScript / JavaScript

Read

references/typescript.md

for the full TS/JS pattern catalog. Key highlights:

Type abuse: redundant annotations where inference works,
```
any
```
instead of
```
unknown
```
, enums instead of const objects/unions, missing
```
satisfies
```
/
```
as const
```
Stale patterns:
```
require()
```
in ESM,
```
var
```
,
```
React.FC
```
, class components,
```
PropTypes
```
alongside TS,
```
.then()
```
chains,
```
namespace
```
Verbose:
```
for
```
loops that should be
```
.filter().map()
```
,
```
Object.keys().forEach()
```
instead of
```
for...of
```
, classes for stateless logic
Dependency creep:
```
node-fetch
```
when
```
fetch
```
is global,
```
uuid
```
when
```
crypto.randomUUID()
```
exists, two libs for the same concern
AI-native tells:
```
try/catch
```
around deterministic local code,
```
new Promise(async ...)
```
, fallback defaults for required env/config, tests that only assert mocks or snapshots
Barrel files:
```
index.ts
```
re-exporting everything in small directories

完整的TS/JS模式目录请查看

references/typescript.md

。核心要点：

类型滥用：可推导时添加冗余注解、用
```
any
```
而非
```
unknown
```
、用枚举而非常量对象/联合类型、缺失
```
satisfies
```
/
```
as const
```
过时模式：ESM中使用
```
require()
```
、
```
var
```
、
```
React.FC
```
、类组件、与TS搭配使用
```
PropTypes
```
、
```
.then()
```
链、
```
namespace
```
冗余写法：应使用
```
.filter().map()
```
的
```
for
```
循环、用
```
Object.keys().forEach()
```
而非
```
for...of
```
、为无状态逻辑使用类
依赖膨胀：全局
```
fetch
```
可用时仍使用
```
node-fetch
```
、
```
crypto.randomUUID()
```
存在时仍使用
```
uuid
```
、同一功能使用两个库
AI生成特征：确定性本地代码包裹
```
try/catch
```
、
```
new Promise(async ...)
```
、必填环境/配置添加默认fallback、仅断言Mock或快照的测试
桶文件：小目录中用
```
index.ts
```
重新导出所有内容

Language: Python

语言：Python

Read

references/python.md

for the full Python pattern catalog. Key highlights:

Class-for-everything disease: stateless classes that should be plain functions/modules
Exception anti-patterns: bare
```
except:
```
catching KeyboardInterrupt/SystemExit,
```
except Exception as e: logger.error(e); raise
```
(adds nothing), type/None checks on typed parameters (e.g.,
```
if user_id is None
```
when the signature says
```
int
```
), broad try/except wrapping its own explicit
```
raise
```
statements
Stale patterns:
```
os.path
```
instead of
```
pathlib
```
,
```
.format()
```
instead of f-strings,
```
%
```
formatting,
```
if/elif
```
chains instead of
```
match
```
(3.10+),
```
typing.Optional[X]
```
instead of
```
X | None
```
(3.10+)
Type hints:
```
Any
```
used to bypass type errors, redundant hints on obvious assignments, overly complex
```
TypeVar
```
gymnastics
Verbose: manual dict/list building instead of comprehensions, nested
```
if
```
instead of early returns,
```
lambda
```
assigned to a variable (just use
```
def
```
), redundant docstrings restating the function signature
Dependency creep:
```
requests
```
for a single GET when
```
urllib
```
works,
```
python-dotenv
```
when
```
os.environ
```
is fine
AI-native tells:
```
dict.get(..., {})
```
chains laundering missing invariants, catch-log-reraise noise, mock-heavy tests with no behavioral assertion

完整的Python模式目录请查看

references/python.md

。核心要点：

万物皆类问题：应为纯函数/模块的无状态类
异常反模式：裸
```
except:
```
捕获KeyboardInterrupt/SystemExit、
```
except Exception as e: logger.error(e); raise
```
（无任何额外价值）、对带类型参数进行类型/None检查（如签名为
```
int
```
时仍写
```
if user_id is None
```
）、宽泛try/except包裹自身显式
```
raise
```
语句
过时模式：用
```
os.path
```
而非
```
pathlib
```
、用
```
.format()
```
而非f-string、
```
%
```
格式化、用
```
if/elif
```
链而非
```
match
```
（3.10+）、用
```
typing.Optional[X]
```
而非
```
X | None
```
（3.10+）
类型提示：用
```
Any
```
绕过类型错误、明显赋值添加冗余提示、过度复杂的
```
TypeVar
```
技巧
冗余写法：手动构建字典/列表而非推导式、嵌套
```
if
```
而非提前返回、
```
lambda
```
赋值给变量（直接用
```
def
```
）、重复函数签名的冗余Docstrings
依赖膨胀：单次GET请求使用
```
requests
```
而非
```
urllib
```
、
```
os.environ
```
可用时仍使用
```
python-dotenv
```
AI生成特征：
```
dict.get(..., {})
```
链掩盖缺失的不变量、捕获-日志-重新抛出的冗余噪声、无行为断言的重度Mock测试

Language: Bash / Shell

语言：Bash / Shell

Read

references/shell.md

for the full Shell pattern catalog. Key highlights:

Missing safety: no
```
set -euo pipefail
```
, unquoted variables, no
```
shellcheck
```
compliance
Useless use of cat:
```
cat file | grep
```
instead of
```
grep file
```
Stale patterns: backticks instead of
```
$()
```
,
```
expr
```
instead of
```
$(())
```
,
```
[ ]
```
instead of
```
[[ ]]
```
in bash/zsh, parsing
```
ls
```
output
Over-defensive:
```
if command; then ... fi
```
on every line instead of
```
set -e
```
, manual
```
$?
```
checks
Verbose:
```
echo "$var" | grep
```
instead of
```
[[ "$var" == *pattern* ]]
```
, external tools for built-in operations
AI-native tells: hallucinated flags/subcommands copied from adjacent CLIs,
```
2>/dev/null || true
```
used to hide uncertainty, heredoc-heavy automation instead of checked files/templates

完整的Shell模式目录请查看

references/shell.md

。核心要点：

缺失安全配置：未设置
```
set -euo pipefail
```
、变量未加引号、未符合
```
shellcheck
```
规范
无意义的cat使用：
```
cat file | grep
```
而非
```
grep file
```
过时模式：用反引号而非
```
$()
```
、用
```
expr
```
而非
```
$(())
```
、bash/zsh中用
```
[ ]
```
而非
```
[[ ]]
```
、解析
```
ls
```
输出
过度防御：每行都用
```
if command; then ... fi
```
而非
```
set -e
```
、手动检查
```
$?
```
冗余写法：
```
echo "$var" | grep
```
而非
```
[[ "$var" == *pattern* ]]
```
、用外部工具实现内置操作
AI生成特征：从相邻CLI复制的幻觉参数/子命令、用
```
2>/dev/null || true
```
隐藏不确定性、用大量heredoc自动化而非校验文件/模板

Language: Infrastructure as Code

语言：基础设施即代码

Read

references/iac.md

for the full IaC pattern catalog covering Terraform, Ansible, Helm, and Kubernetes manifests. Key highlights:

Terraform: over-modularizing, redundant
```
depends_on
```
, not using
```
locals
```
, unpinned provider versions, invented resource arguments, provider/version hallucinations
Ansible:
```
command
```
/
```
shell
```
when a module exists,
```
ignore_errors: true
```
everywhere, registering variables never used, not using handlers, invented module params or wrong collections
Helm: hardcoded values in templates,
```
tpl
```
for static strings,
```
.Values
```
spaghetti without defaults, chart version not pinned, values keys that the chart never consumes
Kubernetes: no resource requests/limits,
```
latest
```
tags, no namespace, imperative
```
kubectl run/create
```
in automation, no probes, mismatched
```
apiVersion
```
/field combinations

覆盖Terraform、Ansible、Helm和Kubernetes清单的完整IaC模式目录请查看

references/iac.md

。核心要点：

Terraform：过度模块化、冗余
```
depends_on
```
、未使用
```
locals
```
、提供商版本未固定、虚构资源参数、提供商/版本幻觉
Ansible：已有模块可用时仍使用
```
command
```
/
```
shell
```
、到处使用
```
ignore_errors: true
```
、注册从未使用的变量、未使用 handlers、虚构模块参数或错误集合
Helm：模板中硬编码值、静态字符串使用
```
tpl
```
、无默认值的
```
.Values
```
混乱写法、Chart版本未固定、Chart从未使用的值键
Kubernetes：未设置资源请求/限制、使用
```
latest
```
标签、未指定命名空间、自动化中使用 imperative
```
kubectl run/create
```
、未设置探针、
```
apiVersion
```
/字段组合不匹配

Language: Rust

语言：Rust

Read

references/rust.md

for the Rust pattern catalog. Key highlights:

Clone abuse:
```
.clone()
```
to dodge the borrow checker - the #1 AI-Rust tell
Error type proliferation: custom error enums for every module instead of
```
anyhow
```
/
```
thiserror
```

Overly generic trait bounds:

T: Display + Debug + Clone + Send + Sync

when only

Display

is used

Verbose:
```
match
```
with two arms instead of
```
if let
```
, explicit
```
return
```
at function end, manual Option/Result matching instead of combinators
Unsafe overuse:
```
unsafe
```
blocks without
```
// SAFETY:
```
comments,
```
transmute
```
when
```
as
```
works

Stale:

extern crate

#[macro_use]

try!()

lazy_static

instead of

std::sync::LazyLock

(1.80+)

完整的Rust模式目录请查看

references/rust.md

。核心要点：

Clone滥用：用
```
.clone()
```
规避借用检查——AI生成Rust代码的头号特征
错误类型泛滥：每个模块都自定义错误枚举而非使用
```
anyhow
```
/
```
thiserror
```

过度通用的 trait约束：仅需

Display

时使用

T: Display + Debug + Clone + Send + Sync

冗余写法：用两个分支的
```
match
```
而非
```
if let
```
、函数末尾显式
```
return
```
、手动匹配Option/Result而非使用组合子
Unsafe过度使用：无
```
// SAFETY:
```
注释的
```
unsafe
```
块、可用
```
as
```
时使用
```
transmute
```

过时写法：

extern crate

、

#[macro_use]

、

try!()

、用

lazy_static

而非

std::sync::LazyLock

（1.80+）

Language: Docker / Containers

语言：Docker / Containers

Read

references/docker.md

for Dockerfile and Compose pattern catalog. Key highlights:

Fat images: no multi-stage build, build tools in final stage,
```
COPY . .
```
before dep install (cache busting)
Layer waste: separate
```
RUN
```
per package,
```
ADD
```
for local files,
```
RUN cd
```
instead of
```
WORKDIR
```
Security: running as root,
```
chmod 777
```
, secrets in build args/env, missing
```
.dockerignore
```
Compose bloat:
```
container_name
```
everywhere,
```
restart: always
```
without healthchecks,
```
depends_on
```
without conditions, hardcoded ports
Stale: old base image versions,
```
MAINTAINER
```
directive, ENTRYPOINT+CMD confusion

Dockerfile和Compose的完整模式目录请查看

references/docker.md

。核心要点：

镜像臃肿：未使用多阶段构建、最终阶段包含构建工具、依赖安装前执行
```
COPY . .
```
（破坏缓存）
层浪费：每个包单独执行
```
RUN
```
、用
```
ADD
```
处理本地文件、用
```
RUN cd
```
而非
```
WORKDIR
```
安全问题：以root用户运行、
```
chmod 777
```
、构建参数/环境中包含密钥、缺失
```
.dockerignore
```
Compose冗余：到处设置
```
container_name
```
、无健康检查时设置
```
restart: always
```
、
```
depends_on
```
无条件、硬编码端口
过时写法：旧基础镜像版本、
```
MAINTAINER
```
指令、ENTRYPOINT+CMD混淆

Other Languages

其他语言

For Go and other languages without dedicated reference files: apply the universal patterns (sections 1-11) only. Note in the report that language-specific checks were skipped. Common cross-language tells still apply - over-abstraction, comment noise, cross-language leakage, schema drift, and error handling anti-patterns look similar everywhere.

对于Go等无专属参考文件的语言：仅应用通用模式（第1-11节）。报告中需说明跳过了特定语言检查。跨语言的常见特征仍适用——过度抽象、注释噪声、跨语言渗透、schema漂移和错误处理反模式在所有语言中表现相似。

Research & Citations

研究与引用

Read

references/research-sources.md

for statistics, source citations, and deeper context on the "no soul" problem. Use when the user wants data to back up findings.

关于“缺乏灵魂”问题的统计数据、来源引用和深层上下文请查看

references/research-sources.md

。当用户需要数据支持审计结果时使用。

What NOT to Flag

不应标记的内容

These look like slop but aren't:

Security patterns: auth, CORS, SSRF protection, input validation at boundaries, rate limiting, TLS configuration, RBAC policies. Correct even if "defensive".
Explicit types/annotations on public interfaces: function signatures, exported types, API contracts benefit from explicitness.
Abstractions that enable testing: interfaces with one implementation for dependency injection.
Workaround comments: "works around X bug", "API requires this", "platform-specific" - institutional knowledge.
Defensive checks on external data: network responses, user input, deserialized data, third-party library output.
Shell verbosity for clarity: complex pipelines benefit from intermediate variables and comments.
Terraform
count
/
for_each
on single resources: might be conditional (
```
count = var.enabled ? 1 : 0
```
).
Ansible
when
conditions that seem obvious: often guarding against cross-platform differences.
Compatibility shims: version- or provider-specific branches may look repetitive because they support multiple real targets.
Contract-level tests: asserting exact API payloads, SQL, CLI args, or emitted metrics is fine when that contract is the thing being tested.

这些内容看似劣质，但实际合理：

安全模式：权限验证、CORS、SSRF防护、边界处输入校验、限流、TLS配置、RBAC策略。即使“防御性”也是正确的。
公共接口的显式类型/注解：函数签名、导出类型、API契约需要显式定义。
支持测试的抽象：为依赖注入使用单个实现的接口。
临时解决方案注释：“规避X bug”、“API要求此写法”、“平台特定”——机构知识。
外部数据的防御性检查：网络响应、用户输入、反序列化数据、第三方库输出。
为清晰性添加的Shell冗余：复杂管道受益于中间变量和注释。
单个资源上的Terraform
count
/
for_each
：可能是条件化的（如
```
count = var.enabled ? 1 : 0
```
）。
看似明显的Ansible
when
条件：通常用于防范跨平台差异。
兼容性垫片：版本或提供商特定分支看似重复，因为它们支持多个真实目标。
契约级测试：当契约为被测行为时，断言精确的API payload、SQL、CLI参数或输出指标是合理的。

Related Skills

Reference Files

参考文件

```
references/typescript.md
```
- TypeScript and JavaScript anti-slop patterns
```
references/python.md
```
- Python anti-slop patterns
```
references/shell.md
```
- shell and script anti-slop patterns
```
references/iac.md
```
- Terraform, Ansible, Helm, and Kubernetes anti-slop patterns
```
references/rust.md
```
- Rust anti-slop patterns
```
references/docker.md
```
- Dockerfile and Compose anti-slop patterns
```
references/research-sources.md
```
- supporting research, citations, and external context

```
references/typescript.md
```
- TypeScript和JavaScript劣质代码模式
```
references/python.md
```
- Python劣质代码模式
```
references/shell.md
```
- Shell脚本劣质代码模式
```
references/iac.md
```
- Terraform、Ansible、Helm和Kubernetes劣质代码模式
```
references/rust.md
```
- Rust劣质代码模式
```
references/docker.md
```
- Dockerfile和Compose劣质代码模式
```
references/research-sources.md
```
- 支持研究、引用和外部上下文

Output Format

输出格式

markdown

undefined

markdown

undefined

Anti-Slop Audit: [scope]

Anti-Slop审计：[范围]

Findings

问题发现

[Category Name] ([count] items)

[类别名称]（[数量]项）

[action] ([severity], [axis])

path/to/file:line

- [description]

// before
[code snippet]

// after
[improved code snippet]

[操作建议]（[严重程度], [维度]）

path/to/file:line

- [描述]

// 优化前
[代码片段]

// 优化后
[改进后的代码片段]

Summary

总结

X findings across Y files
[top-level observations about codebase health]


Keep it concise. Show the diff, not a paragraph explaining it.

---

X个问题分布在Y个文件中
[关于代码库健康状况的顶层观察]


保持简洁。展示差异，而非用段落解释。

---

Rules

规则

Keep correctness out of scope. If it would actually break behavior, route it to code-review instead of padding this report.
Flag AI-native lies even when they look polished. Hallucinated APIs, schema drift, and self-confirming tests belong here when the problem is lack of grounding or taste rather than a demonstrated failing behavior.
Keep security out of scope. Defensive code often looks verbose on purpose. Do not flag it casually.
Read before judging. A pattern that looks generic in isolation may be justified by framework or project constraints.
Ground hallucination claims. Use local types, schema, lockfiles, generated docs, or tool help before saying a flag/resource/API is fake.
Do not bury structural duplication. If near-twin modules or repeated registry/wrapper shapes appear, surface at least one representative finding even when higher-severity hallucination findings dominate the report.
Prefer concrete rewrites. If you flag a pattern, show the simpler version.
Run the AI Self-Check. Verify findings against the checklist before returning the audit.

正确性不属于本技能范畴。如果会实际破坏行为，应转交给code-review，而非添加到本报告中。
即使看起来 polished，也要标记AI生成的隐性错误。幻觉API、schema漂移和自我验证测试属于本技能范畴，当问题是缺乏真实性或品味而非已证实的行为失败时。
安全不属于本技能范畴。防御性代码通常故意冗余。不要随意标记。
判断前先阅读上下文。孤立的模式看似通用，但可能符合框架或项目约束。
幻觉断言需验证真实性。在标记参数/资源/API为虚构前，需使用本地类型、schema、锁文件、生成文档或工具帮助确认。
不要隐藏结构重复。如果出现近乎重复的模块或重复的注册/包装器结构，即使高优先级幻觉问题占主导，也要至少报告一个代表性示例。
优先提供具体重写代码。如果标记一个模式，展示更简洁的版本。
执行AI自我检查清单。返回审计结果前，对照清单验证所有问题。

anti-slop

Original

Translation

Anti-Slop: Polyglot Code Quality Audit

Anti-Slop：多语言代码质量审计

When to use

使用场景

The Three Axes of Slop

劣质代码的三个维度

When NOT to use

不适用场景

AI Self-Check

AI自我检查清单

Workflow

工作流程

Step 1: Scope the audit

步骤1：确定审计范围

Step 2: Detect languages

步骤2：检测语言类型

Step 3: Run mechanical linters first (if available)

步骤3：优先运行机械检查器（若可用）

Step 4: Scan for patterns

步骤4：扫描问题模式

Step 5: Report and fix

步骤5：报告与修复

Universal Patterns (All Languages)

通用模式（所有语言）

1. Comment Slop (Noise)

1. 注释冗余（冗余噪声）

2. Defensive Overkill (Soul)

2. 过度防御（缺乏品味）

3. Over-Abstraction (Soul)

3. 过度抽象（缺乏品味）

4. Verbose Patterns (Noise)

4. 冗余模式（冗余噪声）

5. Generic Naming (Soul)

5. 通用命名（缺乏品味）

Module-level smells

模块级问题

6. Logic Duplication (Lies)

6. 逻辑重复（隐性错误）

7. Stale Patterns (Lies)

7. 过时模式（隐性错误）

8. Error Handling Anti-Patterns (Noise + Lies)

8. 错误处理反模式（冗余噪声 + 隐性错误）

9. Cross-Language Leakage (Lies)

9. 跨语言渗透（隐性错误）

10. Plausible Hallucinations / Schema Drift (Lies)

10. 看似合理的幻觉 / Schema漂移（隐性错误）

11. Test Theater / Self-Confirming Tests (Lies + Soul)

11. 形式化测试 / 自我验证测试（隐性错误 + 缺乏品味）

Language: TypeScript / JavaScript

语言：TypeScript / JavaScript

Language: Python

语言：Python

Language: Bash / Shell

语言：Bash / Shell

Language: Infrastructure as Code

语言：基础设施即代码

Language: Rust

语言：Rust

Language: Docker / Containers

语言：Docker / Containers

Other Languages

其他语言

Research & Citations

研究与引用

What NOT to Flag

不应标记的内容

Related Skills

相关技能

Reference Files

参考文件

Output Format

输出格式

Anti-Slop Audit: [scope]

Anti-Slop审计：[范围]

Findings

问题发现

[Category Name] ([count] items)