「这段有 AI 味」是句没法反驳、也没法执行的话。no-ai-slop 把它拆开：二元对比、清嗓子开场、假洞察铺垫、冒号揭晓、重要性吹捧、模糊归因、同义词轮换、机器人节奏、结尾回顾。每一条都有名字，配例句和改法。

仓库 2026 年 7 月 7 日创建，今天读到的数字是 11,294 stars、772 forks，MIT 许可，本周出现在 GitHub 的 Python 周榜上。装法一行：

npx skills add petergyang/no-ai-slop --skill no-ai-slop --global --yes

在 Claude Code、Codex 或 ChatGPT 里说一句「Install the /no-ai-slop skill globally from 这个仓库」，效果相同。仓库本体很小：10.8 KB 的 SKILL.md、3.2 KB 的 eval.md，加一份 Codex 插件的元数据。README 的说法是 20 条以上的模式，SKILL.md 里按名字列出来的有 18 类，另外配了三组词表，禁用词、空副词、空短语。

它最有价值的部分是它不做的事

SKILL.md 里有一句原话：AI detectors guess. Named patterns are evidence the user can check. 检测器靠猜，命名模式是你能自己核对的证据。

这句话决定了整个 skill 的形状。检测模式下它不重写、不打分、不判断这篇是不是 AI 写的，只做一件事：把命中的模式名字列出来，引用原句，给一句改法。名单上的「值得注意的是」「标志着」「不是 X 而是 Y」都能在稿子里定位、数出来。能被数出来的问题，才能被修掉。

它还给检测留了退路：只报告，不猜作者。市面上大多数「AI 检测」工具做的是相反的事，给一个 87.3% 的概率，读者既没法核对，也没法据此改稿。

第三个动作是反着用：让它故意生成一段最土的 AI 腔，当反面教材。同一份模式清单既能识别也能生成，说明它管的不是「作者是谁」，而是「哪些句式已经用滥了」。

26 条自检

改稿流程的第五步是自查：改完对照 eval.md 跑一遍，编辑原则 11 条、词表 1 条、模式 9 条、通读 5 条，任何一条不过就回去改。这个设计把「去掉 AI 味」变成有验收标准的活，而不是一句提示词。

编辑原则里最有用的一条是可移植性测试：一句话如果能原封不动搬到另一家公司、另一个人、另一个产品上，它就是填充物，删掉，或者换成一个具体事实。「这次集成显著提升了效率」改成「这次集成把部署时间从 40 分钟压到 4 分钟」。词表会被绕过去，可移植性测试绕不过去，判断标准是这句话和你写的东西有没有关系。

配套的还有「最小有效修改」：强句子别动，不要把每一段都修得一样整齐，初稿里的犹豫、离题、口语节奏属于作者本人的部分要留住。多数「AI 润色」出的稿子读起来是同一种感觉，差别就出在这一条上。

拿它扫自己的稿子

白物集的发布前检查是一份人工攒出来的红线清单，不写对比表、不用序号当标题、删掉过渡句、第三人称叙述、数据必须带出处。这些规则和 no-ai-slop 的模式清单重合度很高，区别是一份靠人记，一份写成了可以执行的文件。

为了知道差在哪，把它的模式逐条映射成中文表达，写了个正则脚本，扫了线上最近两个半月的 86 篇，时间从 7 月 18 日到 9 月 26 日，正文合计 285,746 字，平均每篇 3,322 字。

映射关系是这几种：Binary contrasts 对应「不是 X，而是 Y」「与其说……不如说」；importance puffery 对应「标志着」「里程碑」「意义重大」；interpretive metadiscourse 对应「值得注意的是」「换句话说」「关键在于」；robotic rhythm 对应「第一」「第二」「第三」这种编号推进。逐条查完才发现，中文的对应表达和英文清单并不是一一照搬的关系，有些模式在中文里换了一身衣服。

模式	命中次数	涉及篇数
破折号	650	81
序号排比（第一、第二、第三）	110	34
中文烂词（闭环、极致、革新）	38	24
元评论（值得注意的是、换句话说）	30	25
重要性吹捧（标志着、里程碑）	29	20
二元对比（不是 X 而是 Y）	20	17
模糊归因（专家表示、研究表明）	4	3
假洞察铺垫（很少有人告诉你）	0	0
结尾回顾（综上所述）	0	0

几个单项数字值得单独看。破折号 81 篇命中，平均每篇 7.6 个，最多的一篇 24 个。「第一」「第二」「第三」各出现 30 多次，而「首先」「其次」「最后」加起来只有 6 次，长文的结构还在靠编号撑着。「值得注意的是」16 次，「标志着」18 次，「闭环」19 次。

零命中的两项是意外收获。假洞察铺垫和结尾回顾这两种最典型的 AI 腔，86 篇里一次都没出现，人工红线在这两处是有效的。

方法的边界要说清楚：这张表是按它的模式清单写的映射脚本跑出来的，不是工具本身的检测结果；模式命中只是证据，不是判决。中文的破折号用法和英文的 em dash 不是一回事，650 次里有一部分是合法的插入语。真正的问题在密度，平均每篇 7.6 个，说明它已经从表达需要变成了节奏拐杖。

扫完之后值得加进发布前检查的，是三项可以数的指标：破折号密度、序号排比次数、元评论开头次数。这篇稿子按它的模式写了一遍，破折号 0 个。

适合谁，不适合谁

适合写长文并且想保住自己声音的人，它的默认动作是修尽量少的字。适合把写作放进流水线的人，eval.md 可以直接当验收标准交接。适合英文写作，词表可以直接用。

中文写作者拿不到词表。SKILL.md 的禁用词是 delve、leverage、utilize、robust 这一列，中文的「赋能」「闭环」「抓手」「极致」它管不了，上面那张中文映射是自己写的，不在仓库里。中文作者能得到的是模式，不是词表。

它也不做事实核查。数据是否真实、术语是否准确、来源能不能追溯，都在它的管辖之外，它只处理表达方式。同样，它不回答「这篇是不是 AI 写的」这个问题。

上手

npx skills add petergyang/no-ai-slop --skill no-ai-slop --global --yes

装完先检测，/no-ai-slop is this slop? (稿子)，看名单，不改稿。再编辑，/no-ai-slop (稿子)，拿回全文加一段 What changed。然后让它对照 eval.md 自检。最后把反复命中的两三条改成自己流程里的检查项。

要开始的话，先数自己最近 20 篇稿子里的破折号个数，这个数字比读完整份词表更能说明问题。