AI 味从哪来？5 个去 AI 味 Skill 实测

让 AI 写完一篇稿子，读者扫两行就说「一股 AI 味」，这事你大概碰到过。我翻了维基百科编辑总结的识别指南和三篇相关论文，又把 GitHub 上 star 最高的 5 个「去 AI 味」Skill 克隆下来逐个读规则，拿一段中文样稿实测了一遍。下面讲清 AI 味从哪来、怎么改、该装哪个。

AI 味的根子：模型挑的是「最不会错」的说法

维基百科的 WikiProject AI Cleanup 维护着一份《Signs of AI writing》，开头就讲了原理：模型按统计规律猜下一个词，结果会向均值回归，倾向于选「适用范围最广」的说法；再经过人类反馈强化学习（RLHF），输出又被调成大多数人都能接受的样子。条目里有个比喻很准：具体的细节被抹掉，换成泛泛的正面评价，「主题变得既更模糊，又更夸张」。

论文也给了证据。Kirk 等人在 2023 年比较了监督微调和 RLHF，发现 RLHF 明显降低了输出多样性，不同输入下也更容易写出同一种风格。这就是为什么十篇 AI 稿读起来像一个人写的。

高频词会过时，结构套路才是硬伤

英文里最有名的例子是 delve。Kobak 等人分析了 1500 多万篇 PubMed 摘要，2024 年 delves 的出现频率是按往年趋势预期值的 28 倍，据此估计当年至少 13.5% 的摘要经过了大模型处理。Juzek 和 Ward 进一步追问「为什么偏偏是 delve」：他们没找到训练数据或模型架构导致的证据，对比 Llama 2 基础版和对话版的结果与「RLHF 起了作用」一致，但人类偏好实验没有得出定论。

词会随着模型更新变化。维基条目已经把「滥用长破折号」挪进了「历史特征（2022 年至 2026 年 9 月）」一栏，原因是新模型被刻意调得少用破折号。Humanizer 的 SKILL.md 也写得直白：用词习惯每次发版都在变，结构习惯一直都在，所以它把结构问题排在清单最前面。

只删「赋能」「深入探讨」这些词，AI 味只会少一点；把「不是 A 而是 B」和每段结尾的总结句拆掉，读者才会觉得像人写的。

中文自查清单：先查结构，再查用词

下面这些综合自 Humanizer-zh 的 31 个检查点和 lieflat-less-ai-tone 的语料统计，按我认为的优先级排：

1. 「不是 A，而是 B」「不仅……更……」：前半句否定一个没人说过的观点，只为了衬托后半句。直接说 B。
2. 空泛开头：「在当今……飞速发展的时代背景下」。背景里没有信息就删掉。
3. 套话收尾：「总而言之，让我们拭目以待」「标志着新纪元」。不提供信息的结尾整句删。
4. 首先、其次、最后，以及凑数的三段式排比。真有顺序可以留，硬凑的改成两项或直接列。
5. 段首直接下评价：新段落开头就是「值得注意的是」「说白了」，读者得翻回上一段找它在评价什么。
6. 高频词：赋能、助力、至关重要、深入探讨、无缝、闭环。只在空泛或用词不准时换，工程术语照留。
7. 格式：每条都加粗、小标题都用序号或问句、破折号密集。

有两条流行建议要小心。lieflat 作者用自建的 629 篇、约 283 万字语料对照了 26 项公认的「AI 特征」，只有 11 项站得住；其中人类用比喻的频率是 AI 的 2.4 倍，正文设问句是 17 倍。所以「删掉所有比喻和设问」反而会让文章更不像人写的。破折号差异也很大：同一份统计里 DeepSeek 每千字 5.16 个，GPT 只有 0.11 个。这些数字来自作者自己的语料，外部无法复核，作者在局限一节里也承认了这一点。

5 个去 AI 味 Skill 怎么选

star 数是我 10-19 晚用 GitHub API 现查的：humanizer 58,348、Humanizer-zh 20,070、stop-slop 18,143、lieflat 3,174、说人话 2,177。日期均为北京时间。

我的建议：写中文先装 Humanizer-zh，它把「保留事实和确定程度」放在第一优先级，明确说不保证通过 AI 检测器。改英文用 humanizer，它的 README 写明目标是给人读，检测器多数时候照样能认出来。stop-slop 规则很硬，比如所有副词都删、破折号一个不留，适合当参考，不建议照单全收。

安装：三条命令

以下命令摘自各仓库 README，需要 Node.js（npx）和一个支持 Agent Skills 的客户端：

# 中文：Humanizer-zh（也可 git clone 到 ~/.claude/skills/humanizer-zh）
npx skills add https://github.com/op7418/Humanizer-zh.git

# 英文：humanizer（Claude Code 示例）
npx skills add blader/humanizer --global --agent claude-code

# 中文 + 数据依据：lieflat-less-ai-tone
npx skills add larashero3-dotcom/lieflat-less-ai-tone

装好后在对话里这样用（Humanizer-zh README 的写法）：

请用 humanizer-zh 润色下面的文章，保留技术评论的语气：
[原文]

没有 Skill 的环境，可以把 SKILL.md 全文贴进系统提示词或自定义指令，lieflat 和 stop-slop 的 README 都说可以这样用。

实测：一段 191 字的 AI 腔样稿

10-19 晚我在自己的 Linux 机器上（Python 3.13）把 5 个仓库都克隆下来读了规则。这台机器上没有可调用的大模型客户端，所以改写是我对照 Humanizer-zh 的 SKILL.md（提交 f4518a8）逐条手工完成的，再用 lieflat 仓库自带的 check-translationese.py（提交 27d2923）统计改写前后的标记数。

样稿是我故意写的：「在当今人工智能飞速发展的时代背景下……不仅是提升内容质量的关键所在，更是……」「首先，值得注意的是……其次……最后……」，结尾是「总而言之，让我们携手并进……标志着内容创作迈入全新纪元」。

改后全文：

怎么去掉文章里的 AI 味，关系到内容质量，每个写东西的人都绕不开。要改的是写作习惯，光润色几个字不够。

大语言模型倾向于生成结构工整、语气中性的文本，爱用「赋能」「助力」「不仅……更……」这类表达，破折号和粗体也常用过头。

脚本结果：改写前命中破折号 2 处，「值得注意的是」类形式主语、句首连接词、「不仅仅是」、段首序数词各 1 处；改写后全部为 0。我另外数了一遍：「首先/其次/最后」3 处、「时代背景下」「总而言之」「标志着」「深入探讨」各 1 处，改后都没了。汉字从 191 个减到 88 个，少掉的主要是整段套话收尾。另外跑了两个仓库的自带检查：humanizer 的 validate-package.py 输出「Humanizer package v3.1.0 is valid」，Humanizer-zh 的结构检查脚本对未修改副本返回 passed。

常见坑

• 坑 1：改着改着就加了料。我第一版改写顺手加了「写公众号、产品说明时」和「先装个 Skill 再改」，原文根本没这些。对照 Humanizer-zh 的交付前核对（每个新增的具体信息能否在原文找到）才发现，删掉重写。
• 坑 2：词表会误伤「谈论这个词」的句子。我自己写的正则把改后稿里的「赋能」「助力」也算成命中，可那句是在讨论这些词，不是在用。humanizer 和 Humanizer-zh 都写了：引语和讨论措辞的地方不改。
• 坑 3：字数大降不等于改好。样稿只剩 46%，是因为删掉的段落本来就没有信息。说人话的评测工具把长文字数留存率 0.85 设为硬下限，低于它要回头查是不是删掉了真信息。Humanizer-zh 也说别拿字数下降或「AI 味消失」代替事实核对。

未实测：在 Claude Code、Codex、Cursor 里实际安装并自动触发这几个 Skill；用大模型跑整篇长文的改写效果；任何「过 AI 检测」的效果。这几个仓库也都没有把规避检测当目标。

完成标准

• 改完的稿子里，清单 1–5 项一处不剩，6–7 项只留有实际作用的；
• 原文每个数字、条件、「可能」「计划」这类限定词都还在，没有多出原文没有的事实；
• 自己大声读一遍，听着像在跟朋友讲事，不像念通稿。

最后

把你最近一篇 AI 帮写的稿子拿出来，先只对照上面清单的前 3 条删一遍，再装 Humanizer-zh 跑一次，对比两版哪个更像你自己写的。