mcpField
A
ai-slop-cleaner

ai-slop-cleaner

github.com/yeachan-heo开发40.4k1.6k 次安装1 天前更新
代码仓库

关于 ai-slop-cleaner

ai-slop-cleaner 是用于简化 AI 生成代码的清理技能，面向希望控制重构范围并保留行为的开发者。它以回归测试、预先制定清理计划和小步验证为核心，也提供仅审查模式。

主要功能

  1. 01先保护现有行为并规划清理
  2. 02识别重复、死代码和过度抽象
  3. 03按气味分类逐步清理
  4. 04支持仅审查模式
  5. 05运行回归测试与质量检查

适用场景

  1. 01清理重复逻辑和无用代码
  2. 02在不改变行为的前提下简化模块
  3. 03审查清理改动及其测试覆盖

安装

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

$npx skills add https://github.com/yeachan-heo/oh-my-claudecode --skill ai-slop-cleaner

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

详细介绍

AI Slop Cleaner

使用这项技能可以清理 AI 生成的代码垃圾，同时不偏离范围、不改变预期行为。在 OMC 中，这是针对那些能正常工作但显得臃肿、重复、测试薄弱或过度抽象的代码的有界清理工作流。

何时使用

在以下情况使用这项技能：

  • 用户明确说出 deslop、anti-slop 或 AI slop
  • 请求是清理或重构那些显得杂乱、重复或过度抽象的代码
  • 后续实现留下了重复逻辑、死代码、包装层、边界泄漏或薄弱的回归覆盖
  • 用户希望通过 --review 进行一次仅审查者的反 slop 检查
  • 目标是简化和清理，而不是交付新功能

何时不使用

在以下情况不要使用这项技能：

  • 任务主要是新功能构建或产品变更
  • 用户想要的是大幅重新设计，而不是增量清理
  • 请求是通用的重构，没有简化或反 slop 意图
  • 行为过于不明确，无法用测试或具体的验证计划加以保护

OMC 执行姿态

  • 除非用户明确要求更改行为，否则保持行为不变。
  • 只要可行，先用针对性的回归测试锁定行为。
  • 在编辑代码之前先编写清理计划。
  • 优先删除而非新增。
  • 在引入新工具和模式之前，先复用现有的。
  • 除非用户明确要求，否则避免新增依赖。
  • 保持 diff 小、可回滚、聚焦于坏味道。
  • 保持简洁且证据密集：检查、编辑、验证、报告。
  • 将新的用户指令视为局部范围更新，同时不丢弃先前不冲突的约束。

限定文件列表用法

当调用方已经知道安全的清理范围时，这项技能可以限定到显式的文件列表或变更文件范围。

  • 适用：oh-my-claudecode:ai-slop-cleaner skills/ralph/SKILL.md skills/ai-slop-cleaner/SKILL.md
  • 适用：一个 Ralph 会话只交接该会话中变更的文件
  • 即使范围只是一个简短的文件列表，也保持同样的回归安全工作流
  • 除非用户明确要求，否则不要悄悄将变更文件范围扩大到更广泛的清理工作

Ralph 集成

Ralph 可以将这项技能作为有界的审查后清理环节来调用。

  • 在该工作流中，清理器以标准模式运行（不是 --review）
  • 清理范围仅限于 Ralph 会话中变更的文件
  • 清理环节结束后，Ralph 在完成前重新运行回归验证
  • --review 仍然是仅审查者的后续模式，而不是 Ralph 集成的默认路径

审查模式（--review）

--review 是在清理工作起草完成后进行的仅审查者环节。它的存在是为了在反 slop 工作中保持明确的写作者/审查者分离。

  • 写作者环节：在行为被测试锁定的前提下进行清理更改。
  • 审查者环节：检查清理计划、变更文件和验证证据。
  • 同一个环节不得在没有单独审查步骤的情况下，既编写又自我批准高影响的清理。

在审查模式下：

  1. 不要从编辑文件开始。
  2. 审查清理计划、变更文件和回归覆盖。
  3. 特别检查：
    • 遗留的死代码或未使用的导出
    • 本应合并的重复逻辑
    • 仍然模糊边界的多余包装或抽象
    • 针对被保留行为的缺失测试或薄弱验证
    • 看似无意中改变了行为的清理
  4. 给出审查者结论以及必需的后续工作。
  5. 将所需的更改交回给单独的写作者环节，而不是在同一步中修复并批准。

工作流

  1. 先保护当前行为

    • 确定哪些内容必须保持不变。
    • 在编辑前添加或运行所需的最小范围回归测试。
    • 如果测试无法先行，在改动代码前明确记录验证计划。

  2. 在写代码前制定清理计划

    • 将本次处理范围限定在请求的文件或功能区域内。
    • 列出要移除的具体坏味道。
    • 按从最安全的删除到风险更高的整合来安排工作顺序。

  3. 在编辑前对 slop 进行分类

    • 重复 — 重复的逻辑、复制粘贴的分支、冗余的辅助函数
    • 死代码 — 未使用的代码、不可达的分支、过期的标志、遗留的调试代码
    • 不必要的抽象 — 直通式包装器、投机的间接层、一次性使用的辅助层
    • 边界违规 — 隐藏的耦合、错位的职责、错误层次的导入或副作用
    • 缺失测试 — 行为未被锁定、回归覆盖薄弱、边界情况缺口
    • UI/设计默认值 — 让 AI 构建的界面显得未经审查的通用视觉模式
UI/设计审查清单

将这些作为审查提示，而非绝对禁令。当品牌、无障碍、产品密度或设计系统的选择有明确理由时，请予以保留。

  • 韩文可读性： 标记设置为约 11-12px 的正文文字；韩文正文通常至少需要 14px，除非适用经过验证的密集数据例外。
  • 阴影克制： 对每个表面、logo、背景、卡片或图标上的盒阴影提出质疑；仅在阴影能阐明层级或交互时保留。
  • 内容层级： 当标题已承载信息时，移除重复的眉题/标题/描述/额外 <p> 堆砌；避免通用 emoji 徽章，除非它们是产品调性的一部分。
  • 配色理由： 在没有品牌或系统理由时，质疑默认的 AI 蓝/紫配色，尤其是类似 Tailwind 的 #3B82F6。
  • 布局节奏： 当产品语境受益于节奏、强调、不对称、轮播/bento 处理或不同的卡片权重时，避免过于完美的 3 或 4 列均匀网格。
  • 渐变克制： 除非品牌有意拥有这种视觉语言，否则收敛极端的渐变。

  1. 一次只运行一个聚焦坏味道的处理轮次

    • 第 1 轮：删除死代码
    • 第 2 轮：移除重复
    • 第 3 轮：命名与错误处理清理
    • 第 4 轮：强化测试
    • 每一轮后重新运行针对性验证。
    • 不要将不相关的重构捆绑到同一组编辑中。

  2. 运行质量门禁

    • 保持回归测试通过。
    • 对触及区域运行相关的 lint、类型检查和单元/集成测试。
    • 在可用时运行现有的静态或安全检查。
    • 如果某个门禁失败，修复问题或撤回有风险的清理，而不是强行通过。

  3. 以证据充分的报告收尾 始终报告：

    • 更改的文件
    • 简化内容
    • 行为锁定 / 验证运行
    • 剩余风险

用法

  • /oh-my-claudecode:ai-slop-cleaner <target>
  • /oh-my-claudecode:ai-slop-cleaner <target> --review
  • /oh-my-claudecode:ai-slop-cleaner <file-a> <file-b> <file-c>
  • 从 Ralph 调用：仅对 Ralph 会话更改的文件运行清理器，然后返回 Ralph 进行清理后回归验证

适用场景

适合： deslop this module: too many wrappers, duplicate helpers, and dead code

适合： cleanup the AI slop in src/auth and tighten boundaries without changing behavior

不适合： refactor auth to support SSO

不适合： clean up formatting

评论

支持 Markdown