AI 写代码最麻烦的地方，往往不是报错。

更麻烦的是它能跑。测试过了，lint 也过了，PR 看起来不大。但代码里多出一堆叙事型注释、吞掉异常的 catch、随手一个 as any、不存在的 import、重复 helper、死代码、TODO 空壳、大函数。

这些东西不会立刻炸。它们只是让代码库慢慢变软。

AISlop 这个开源 CLI，抓的就是这种“能跑但在腐烂”的味道。它真正有意思的地方，也不在于又多了一个 lint 工具，而是 AI coding agent 进入日常开发后，工程团队开始给这类隐性维护成本立闸门。

AISlop 扫的不是“AI 身份”，而是代码异味

AISlop 的定位要先说准：它不是 AI 生成代码检测器。

它不宣称能准确识别所有 AI 写的代码。它做的是另一件更工程化的事：用确定性规则，扫描 Cursor、Claude Code、Codex 等 AI 编码工具常留下的代码异味。

核心信息压缩成一张表：

问题AISlop 的做法
扫什么40+ rules，覆盖叙事型注释、吞异常、as any、幻觉 import、重复 helper、死代码、TODO stub、大函数等
支持什么语言TS/JS、Python、Go、Rust、Ruby、PHP、Java
怎么输出0-100 分，可作为质量门禁
怎么运行sub-second，确定性规则，运行路径里不调用 LLM
怎么接入npx aislop scan/fix/ci、agent hook、MCP、badge、团队 PR gate/dashboard
开源属性MIT 许可，CLI 可免费使用

它也不是重新造一套静态分析宇宙。

材料里写得很清楚：格式化、lint、安全、复杂度等部分，会接入 Biome、ruff、gofmt、clippy、golangci-lint、knip 等标准工具。AISlop 补的是另一层：更贴近 AI 代码副作用的卫生检查。

这个区别很重要。

测试关心结果对不对。lint 关心格式和规则合不合。静态分析关心复杂度、安全和潜在 bug。AISlop 更像是在问：这段代码是不是带着一股“agent 刚写完、没人真正收拾过”的味道。

比如吞异常。

测试可能没覆盖到。lint 未必报错。上线当天也许没事。但等线上出问题，日志没有、上下文没有、错误被吃掉，排查成本就从今天挪到以后。

这类成本最阴。它不进速度统计，只进维护账本。

受影响最大的，是已经把 agent 接进流程的人

个人开发者用 AISlop，最直接的动作是把它放进本地命令或 hook。

不是为了证明自己没用 AI，而是让 agent 每次改完代码后先过一遍卫生检查。分数太低，就先修掉重复 helper、TODO 空壳、异常吞噬，再提交。

技术负责人更该看 CI gate。

如果团队已经在用 Cursor、Claude Code、Codex 之类的工具改 PR，那么只靠 reviewer 肉眼看，迟早不够。reviewer 会疲劳，AI 生成的“看似合理”又很会混过去。把 AISlop 放进 PR gate，至少能把一部分低质量模式挡在主干外。

这不等于立刻采购团队版。

更现实的路径是：先在个人或小团队里跑 CLI，看误报率、修复成本和阻断频率。等规则稳定，再考虑团队 dashboard、PR gate、agent attribution 这些协作功能。材料只说明有 hosted platform 和团队功能入口，不能据此说它已经被大规模商业验证。

我会把观察点放在两件事上：

  • 规则误报能不能被团队接受.叙事型注释未必都坏，TODO stub 有时也是合理占位。
  • CI 门禁会不会变成新负担.分数好看但开发变慢，也不是胜利。

质量工具最怕两头不讨好：不拦时没人信，拦多了没人用。

所以 AISlop 的价值，不在于分数本身多权威，而在于它能不能把“AI 写完以后谁来擦屁股”这件事，提前放进开发流程。

AI 编程的账，不在生成时结

我更在意的是，AISlop 这类工具出现，说明 AI 编程已经过了只比生成速度的阶段。

早期大家关心 agent 能不能从 issue 改 PR，一天能写多少代码，能不能自动补全一整个模块。那是兴奋期。工具越快，故事越好讲。

但代码不是一次性文案。

代码会留下接口、依赖、状态、异常路径和认知负担。今天多生成一段没人理解的 helper，三个月后就可能变成没人敢动的角落。

“天下熙熙，皆为利来。”放在 AI 编程里也很贴切。开发者要省时间，管理者要吞吐量，供应商要更深地进入研发流程。所有人都在拿生产力红利，但维护成本不会凭空消失。

它只会换个地方记账。

AISlop 把这笔账往前挪了一步。它让团队可以在 hook、PR、CI 里设门槛，让 agent 每次编辑后收到反馈，也让质量趋势不再完全靠 reviewer 的感觉。

这件事不性感，但很像工程史里反复出现的一幕。

铁路提速之后，真正让系统可靠的不是更快的火车，而是信号、调度和制动。电力普及之后，断路器不酷，但没有它，规模化用电就是灾难。AI 编程也一样。模型越会写，越需要配套的治理层。

当然，确定性规则有边界。

Regex、AST 和标准工具能抓常见模式，不能理解全部业务上下文。as any 有时是现实妥协，大函数有时来自旧系统包袱，TODO 也可能是明确计划的一部分。把 AISlop 当审判机器，会误伤工程现实。

更合理的定位，是 AI 代码卫生检查。

它不替代测试，不替代 lint，不替代静态分析，也不替代 code review。它补的是一块过去没人专门管的区域：AI 生成代码里那些短期不坏、长期难受的东西。

接下来最该看的，不是它能不能喊出更大的口号。

要看三件小事：规则库能不能覆盖真实团队里的坏味道；误报处理能不能足够顺手；CI gate 能不能在不拖慢研发的前提下，挡住最脏的一批变更。

如果这三件事成立，AISlop 这类工具就会从“可选小工具”变成 AI 编程流程里的默认闸门。

模型看着更强，代码库未必更健康。生产力被放大以后，腐烂也会被放大。