用 anti-slop 让你的 Linter 拒绝低证据 TypeScript

TypeScript 的 unknown 是诚实的；把值用一串 as 硬塞出去绕开它的代码不是。anti-slop 是一个 6k 星的 Oxlint 规则集，它把这种品味变成 lint 阶段机械化执行的报错：拒绝低证据、低信号模式的规则——链式类型断言、unknown 参数和返回值、模块 mock、不断复制的 reducer。

为什么这个 Skill 重要

README 开宗明义：这是某一位开发者的规则集——"我和我的工作、项目、团队在用的规则集……反映的是我的偏好和品味，而不是一套通用编码标准"——这也正是它的分发方式如此特别的原因：**它被设计为 vendor 进仓库，而不是作为固定的 npm 依赖安装。**没有官方 npm 包。你把规则复制进自己的仓库，读一遍，把团队不认同的改掉。附带的 Agent skill 负责初始的复制和配置；之后这些 vendored 文件就归你维护。

规则集包含 18 条通用规则和 5 条 Effect 专属规则，后者放在单独的插件里，不使用 Effect 的项目永远不会继承 Effect 的架构政策。通用规则围绕 README 明说的一个主题——证据：no-chained-type-assertions 拒绝嵌套 as 伪造出的类型，no-widen-then-assert 拒绝把已知的值先加宽再断言回来，require-safety-comment-for-type-assertion 要求每处非常量断言附近给出理由注释。另一些规则针对可读性与性能（require-readable-spacing、no-array-filter-map、no-reduce-accumulator-copy）和测试诚实度（no-module-mocking 拒绝 Vitest 和 Jest 的模块 mock，要求真实的依赖接缝）。

安装

npx skills add dmmulroy/anti-slop --skill install-anti-slop

然后让你的编码 Agent 在当前仓库里安装或配置 anti-slop。按 README 的说法，这个 skill 会复制插件、安装兼容的 Oxlint 依赖——仓库里已有 Oxlint 时匹配现有版本——把插件合并进现有 lint 配置，启用每一条通用规则，并校验结果。在直接依赖 Effect 的仓库里，它还会启用可选的 Effect 规则组。安装前想先看看仓库提供什么，用 --list：

npx skills add dmmulroy/anti-slop --list

实战：先 Vendor，再接管

skill 跑完之后，你的仓库里会把规则 vendor 到某个路径——README 手动安装的示例路径是 tools/oxlint/anti-slop/——并在 oxlint.config.ts 里注册好入口。下一步是 README 坚持的那一步：读这些规则，然后调校。删掉团队不接受的，其余保持 error。

日常使用时，这些规则以普通 lint 错误的形式出现，但每条都带着观点。no-array-filter-map 会盯上 users.filter(u => u.active).map(u => u.email)，要求改成惰性的迭代器管道；require-safety-comment-for-type-assertion 会盯上光秃秃的 const userId = value as UserId，直到一条 // SAFETY: 注释解释清楚让这个断言成立的不变量。README 的分析边界章节有一个关键提醒：这些规则用的是 Oxlint 的 ESTree 和词法作用域 API，不是 TypeScript 类型检查器——它们能解析同文件内的别名，但不会推断导入的类型或跨文件的调用签名，所以一些规则注明执行范围刻意限定在本地。

更新走同样的路。让你的 Agent 在保留本地定制的前提下更新 anti-slop：skill 会把上游源码先放到单独的位置，在上游快照可恢复时做三方合并，并保留你的本地规则——遇到策略冲突时先询问，而不是强行替换 vendored 目录。

技巧

• 把 vendored 的副本当成你自己的：README 邀请你这样做，社区维护的 fork 也被明确欢迎。
• 把 oxc/no-accumulating-spread 和 no-reduce-accumulator-copy 一起启用——原生的那条规则覆盖 reducer 和受支持循环里的展开操作。
• require-readable-spacing 能自动修复顶层声明之间缺失的空行；先跑 oxlint --fix，再跑格式化器，然后再 lint 一遍。
• Effect 规则按设计是可选的——只在真正依赖 Effect 的仓库里注册第二个插件。

何时不用这个 Skill

如果你想要一套中立的、与团队无关的风格指南，这里恰好相反：按作者自己的描述它就是有态度的，而且 no-module-mocking、no-runtime-typeof 这类规则会和你的代码库可能正当依赖的模式对着干——README 期望你改掉 vendored 的规则，而不是忍受它们。另外因为分析是纯语法层面的，想要类型检查器级别执行的团队需要别的工具。

查看 排行榜 了解更多 skill。