yetone/清除AI风格

Kill AI Slop

AI 风格的垃圾（AI slop）是丑陋的，以一种特定的方式：它堆砌了所有可能的样式和细节，却没有一个焦点。一个渐变，一个发光，一个吉祥物，emoji，一墙发光的卡片，所有默认设置全部开启，直到每个产品看起来都像同一个花哨的模板。它看起来像是“经过设计”的缩略图，但只要有人仔细看就立刻崩塌。你的任务是将其剥离，恢复到一个人真正会选择的模样。

在你进行的每次修复中，坚持以下原则：

1. 决定，再装饰。 每个视觉选择必须是可以解释的。
2. 一个强调色，一种声音。
3. 通过比例和空间建立层级。 给词语着色或更换字体是一种捷径。
4. 先做减法。 通往不丑的第一步是移除东西。
5. 具体比华丽更重要 在文案中尤其如此。
6. 装饰必须有意义 — 图标、徽章、标注都是信号。

工作流程

按顺序执行以下步骤。在用户看到报告之前，不要进行批量编辑。

1. 确定范围（Scope）

确认要扫描的范围。默认扫描应用/站点源代码（跳过 node_modules、dist、build、.git、vendor、锁文件、压缩文件）。如果项目混合了多个应用，请询问用户。

2. 扫描（Scan）

运行自带的扫描器，它会通过 grep 代码库来查找每种特征的代码层面信号，并打印分组后的 file:line 命中结果：

node scripts/scan.mjs <root>          # 人类可读的报告
node scripts/scan.mjs <root> --json   # 机器可读，用于分类

该扫描器是纯 Node.js（无依赖），且不会修改文件。将其输出作为起点地图，而不是绝对标准 — 通过阅读代码来确认每个命中是否为真正的“风格化垃圾”。

要缩小扫描范围：使用 --only=01,06 / --skip=19 按特征 ID 过滤；--exclude=legacy 可以排除路径（基于项目相对路径的子字符串匹配）。--rules=extra.mjs 可以加载额外的项目或语言特定的特征（scripts/rules.ru.mjs 是一个内置的俄语文案示例，也是你创建自定义规则的模板）。用户已确认为有意的命中，可以在源代码中用 deslop-ignore、deslop-ignore-next-line 06 或 deslop-ignore-file 注释固定 — 优先使用带 ID 范围的注释形式，这样新的特征仍然会显示。

3. 分类（Triage）

对于每个命中，打开文件并判断是风格化垃圾还是有意为之。这是该技能区别于普通 lint 规则的关键步骤。渐变、衬线字体或 emoji 都可能是一个真实的、经过辩护的选择。保留用户明确选择的任何东西（品牌标记、logo、有意的插图）。只标记那些默认的、未加思考的特征。

阅读 references/taxonomy.md 了解每个特征是什么以及为什么它看起来像是机器生成的，以及 references/detection.md 了解具体的模式及其常见的误报情况。

4. 报告（Report）

在修改任何东西之前，给用户一个分组摘要：每个特征、你确认的 file:line 命中、一句话说明原因、以及建议的修复方案。格式如下：

slop  src/Hero.tsx:12   indigo→violet 渐变                             → 一个纯色强调
slop  src/Hero.tsx:31   渐变剪裁标题                                     → 纯色字体，加大字号
slop  src/Note.tsx:8    border-l-4 标注 ×3                              → 1 个侧边栏提示，其余用正文
slop  copy.md:1         "不只是 X — 它是 Y"                          → 直接说具体的东西
→ 4 组，11 个命中。

然后询问用户要应用哪些组，或者是否全部应用。

5. 修复（Fix）

应用最少的修改，在移除特征的同时保留其意图和功能。使用 references/fixes.md 中的每个特征前后对比模式。

• 优先编辑共享的 token/组件，而不是修改每一个调用点。
• 永远不要发明新的品牌颜色；如果调色板必须更改，提出中性色 + 项目现有的强调色，并让用户确认。
• 保留文案含义；让它变得具体，不要直接删除。
• 修复后重新运行扫描器，确认计数下降，并记录任何你有意保留的命中（附上原因）。

护栏

• 尊重作者贡献。 将不熟悉的文件和精心设计的修饰视为他人的选择。当不确定某物是否为“风格化垃圾”时，请询问 — 不要直接剥离。
• 小的、易于审查的差异。 永远不要重新格式化不相关的代码。永远不要运行 git add -A；只暂存明确的文件，并避免改动他人的进行中工作。
• 完成此工作不需要新的依赖。
• 尽可能进行视觉验证。 如果开发服务器存在，查看修改前后效果；扫描通过不代表页面更美观。

参考文件

• references/taxonomy.md — 35 种特征：每种特征是什么、为什么它是“风格化垃圾”、如何进行修复。
• references/detection.md — 具体的 ripgrep/regex 模式 + 误报情况。
• references/fixes.md — 修复前后的对比模式。
• scripts/scan.mjs — 无依赖的扫描器。