这是一个 Show HN 项目：AISlop 是一个 CLI（命令行工具），专门扫描代码里常见于 LLM/AI 辅助编程的坏味道，比如重复函数、死代码和冗余实现，并把结果作为额外的 lint 线索。评论区拿它和 Rector（PHP 重构工具）、ESLint（JavaScript 静态检查器）、PHPStan（PHP 静态分析器）以及 Deptrac（PHP 架构依赖检查工具）对比，核心问题是它到底比现有静态分析工具多了什么。作者强调它并不是判断代码是不是 AI 写的，而是抓那些在自动迭代中更容易堆积、最终拖垮代码库的设计问题。另一条背景线是命名争议：slop 这个词本身带贬义，评论里还拿 Anubis（一个用于对抗自动化访问/爬虫的工具）讨论过类似的企业包装问题，尤其是在 CI/CD（持续集成/持续交付）流程里。
不少人把它当成代码 review 的最后一道补漏，而不是用来给 AI 贴标签。有人把它跑在自己的 codebase 里，确实找到了有价值的问题，还能把结果转给 agent 去验证和修复。评论里多次提到 dead code、重复函数、冗余实现这类 AI 反复迭代后常留下的残留。也有人觉得在 code review 很累、甚至缺失的环境里，多一层 linter 很实用。
另一派关注的是边界：如果只是通用静态检查，为什么不直接用 Rector、ESLint、PHPStan、Deptrac 之类现成工具？有人认为重点应该永远是代码质量和可维护性，而不是是否由 AI 写出，因为人类程序员也会写出重复实现、坏设计和各种低级错误。回应里则强调，这些规则本质上是在抓 poor design choices，只是 AI 生成时更容易把这些问题规模化。这个争论的核心其实是它到底是“AI 检测器”还是“质量守门员”。
命名和品牌是另一条明显分歧线。有人直言把产品叫 slop 会削弱可信度，尤其是要进公司环境、startup 流程或 CI/CD 时，团队不想把带贬义的词塞进工具链。随后有人拿 Anubis（一个用于对抗自动化访问/爬虫的工具）举例，说它也曾通过更“企业友好”的包装来降低阻力；不过也有人反驳那并不是修复，而是原本就故意选择了带动漫头像的风格。
有人问它能不能支持 JavaScript 之外的语言。作者回复称已经支持多种语言，包括 PHP、Go、Rust、Python、JavaScript 和 TypeScript。这个回答把它从单一生态的小工具，拉成了可在混合代码库里使用的跨语言 CLI。
code smell: 代码中的坏味道，通常指可能暗示设计问题的模式，如重复、冗余或难维护的结构。
dead code: 不再被执行或已经没有实际作用的代码，常见于反复迭代后的残留。
linter: 用规则自动检查代码风格、错误和可疑模式的静态检查器。
CI/CD: 持续集成/持续交付（或部署）流水线，自动化构建、测试和发布流程。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。