kill-ai-slop

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Kill AI Slop

清除AI模板化冗余内容(AI Slop)

AI slop is ugly in a specific way: it piles on every possible style and detail without settling on a focus. A gradient, a glow, a mascot, emoji, a wall of glowing cards, every default switched on at once, until every product looks like the same garish template. It reads as "designed" in a thumbnail and falls apart the moment anyone looks. Your job is to strip it back to something a person would actually choose.
The principles, held on every fix you make:
  1. Decide before you decorate. Every visual choice must be explainable.
  2. One accent, one voice.
  3. Hierarchy from scale and space. Coloring words or swapping fonts is a shortcut.
  4. Subtract first. The first move toward not-ugly is removing things.
  5. Specific beats punchy in copy.
  6. Decoration must mean something — icons, badges, callouts are signals.
AI模板化冗余内容(AI slop)有着独特的丑陋感:它堆砌了所有可能的样式和细节,却没有明确的焦点。渐变、光晕、吉祥物、表情符号、一整排发光卡片,所有默认选项同时开启,最终每个产品都看起来像是同一个花哨的模板。它在缩略图里显得“有设计感”,但只要有人仔细看就会破绽百出。你的任务是将其精简为真正符合人工选择的内容。
所有修复都需遵循以下原则:
  1. 先定基调,再做装饰。每一个视觉选择都必须有合理的解释。
  2. 一种强调色,一种风格
  3. 通过尺寸和空间建立层级。给文字上色或更换字体是捷径。
  4. 先做减法。摆脱丑陋的第一步是移除冗余内容。
  5. 文案要具体,而非空洞
  6. 装饰必须有意义——图标、徽章、提示框都是信号。

Workflow

工作流程

Follow these steps in order. Do not mass-edit before the user has seen the report.
按以下顺序执行步骤。在用户查看报告前,请勿批量编辑内容。

1. Scope

1. 确定范围

Confirm what to scan. Default to the app/site source (skip
node_modules
,
dist
,
build
,
.git
,
vendor
, lockfiles, minified files). Ask if the project mixes several apps.
确认需要扫描的内容。默认扫描应用/网站源码(跳过
node_modules
dist
build
.git
vendor
、锁文件、压缩文件)。询问项目是否包含多个应用。

2. Scan

2. 扫描

Run the bundled scanner, which greps the codebase for the code-level signals of each tell and prints grouped
file:line
hits:
node scripts/scan.mjs <root>          # human-readable report
node scripts/scan.mjs <root> --json   # machine-readable, for triage
It is pure Node (no dependencies) and never edits files. Use its output as a starting map, not gospel — confirm each hit by reading the code.
运行内置的扫描工具,通过 grep 遍历代码库,查找每种AI模板化特征的代码层面信号,并按
file:line
格式分组输出结果:
node scripts/scan.mjs <root>          # 人类可读格式报告
node scripts/scan.mjs <root> --json   # 机器可读格式,用于分类处理
该工具基于纯Node.js开发(无依赖),且不会修改文件。将其输出作为起始参考,而非绝对标准——需查看代码确认每一处匹配结果。

3. Triage

3. 分类处理

For every hit, open the file and decide slop vs. intentional. This is the step that separates this skill from a lint rule. A gradient, a serif, or an emoji can be a real, defended choice. Keep anything the user clearly chose (brand tokens, a logo, a deliberate illustration). Flag only defaults.
Read
references/taxonomy.md
for what each tell is and why it reads as machine-made, and
references/detection.md
for the exact patterns and their common false positives.
对于每一处匹配结果,打开文件并判断是模板化冗余内容还是刻意设计。这一步是本工具与代码检查规则的区别所在。渐变、衬线字体或表情符号都可能是经过深思熟虑的选择。保留用户明确选择的内容(品牌标识、logo、刻意设计的插图)。仅标记默认生成的内容。
查看
references/taxonomy.md
了解每种特征是什么、为何属于模板化冗余内容,以及
references/detection.md
中的具体匹配模式和常见误判情况。

4. Report

4. 生成报告

Before changing anything, give the user a grouped summary: each tell, the
file:line
hits you confirmed, one sentence on why, and the proposed fix. Mirror the format:
slop  src/Hero.tsx:12   indigo→violet gradient        → one solid accent
slop  src/Hero.tsx:31   gradient-clip headline        → solid ink, scale up
slop  src/Note.tsx:8    border-l-4 callout ×3         → 1 aside, rest is body
slop  copy.md:1         "not just X — it's Y"         → say the specific thing
→ 4 groups, 11 hits.
Then ask which groups to apply, or whether to proceed on all.
在进行任何修改前,向用户提供分组汇总:每种模板化特征、确认的
file:line
匹配结果、一句说明原因,以及建议的修复方案。遵循以下格式:
冗余内容  src/Hero.tsx:12   靛蓝→紫罗兰渐变        → 改用单一强调色
冗余内容  src/Hero.tsx:31   渐变文字标题        → 改用纯色文字,放大尺寸
冗余内容  src/Note.tsx:8    3个左侧边框为4px的提示框         → 保留1个侧边提示,其余转为正文
冗余内容  copy.md:1         “不只是X——更是Y”         → 表述具体内容
→ 4组,共11处匹配。
然后询问用户需要应用哪些组的修复,或是是否全部修复。

5. Fix

5. 修复

Apply the minimal change that removes the tell while preserving intent and function. Use
references/fixes.md
for the before→after pattern per tell.
  • Prefer editing shared tokens/components over touching every call site.
  • Never invent new brand colors; if a palette must change, propose neutrals + the project's existing accent and let the user confirm.
  • Keep copy meaning; make it specific, don't just delete it.
  • Re-run the scanner after fixing to confirm the count dropped, and note any hits you intentionally left (with the reason).
执行最小化修改,移除模板化特征的同时保留原有意图和功能。参考
references/fixes.md
中每种特征的前后对比修复模式。
  • 优先编辑共享标识/组件,而非逐个修改调用位置。
  • 切勿创建新的品牌颜色;若必须更改配色,建议使用中性色+项目现有强调色,并让用户确认。
  • 保留文案原意;使其更具体,而非直接删除。
  • 修复后重新运行扫描工具,确认匹配数量减少,并记录任何刻意保留的匹配结果及原因。

Guardrails

约束规则

  • Respect authorship. Treat unfamiliar files and deliberate flourishes as someone's choice. When unsure whether something is slop, ask — don't strip it.
  • Small, reviewable diffs. Never reformat unrelated code. Never run
    git add -A
    ; stage explicit files only, and leave others' work-in-progress alone.
  • No new dependencies to do this work.
  • Verify visually when possible. If a dev server exists, look at the before and after; a passing scan is not the same as a better page.
  • 尊重原创。将不熟悉的文件和刻意的设计视为他人的选择。若不确定某内容是否为模板化冗余内容,请询问用户——不要直接移除。
  • 小而可审查的差异。切勿格式化无关代码。切勿运行
    git add -A
    ;仅显式提交修改的文件,不干扰他人的进行中工作。
  • 无需新增依赖即可完成此项工作。
  • 尽可能进行视觉验证。若存在开发服务器,请查看修改前后的效果;扫描通过并不等同于页面体验更好。

References

参考资料

  • references/taxonomy.md
    — the 23 tells: what each is, why it's slop, the fix.
  • references/detection.md
    — concrete ripgrep/regex patterns + false positives.
  • references/fixes.md
    — before→after remediation patterns.
  • scripts/scan.mjs
    — the dependency-free scanner.
  • references/taxonomy.md
    — 23种模板化特征:每种特征的定义、为何属于冗余内容及修复方案。
  • references/detection.md
    — 具体的ripgrep/regex匹配模式+误判情况。
  • references/fixes.md
    — 前后对比修复模式。
  • scripts/scan.mjs
    — 无依赖扫描工具。