AI 味不是玄学，是 35 个写进 prompt 的具体坏习惯

你肯定读过那种文章。通顺，工整，挑不出语病，但就是不对劲。它不会说一个东西「是」什么，只会说它「不仅是一个 X，更是一个 Y」。它热爱三连排比，创新、灵感与洞察。它每段结尾都站着一个破折号，仿佛不这么断句作者就会窒息。

这就是 AI 味。大部分人骂完就算了，维基百科的编辑们干了件笨事，把 AI 写作的毛病一条条列成了公开清单。今年一月，硅谷天使投资人 Siqi Chen 把这份清单抄进了一个 prompt，做成 agent skill。

七个月后，这个 skill 收了 43,333 个 Star。

它叫 humanizer，整个仓库的核心「代码」是一个 30 KB 的 Markdown 文件，仓库里全部文件加起来只有 9 个，没有构建步骤，没有依赖。

病历卡不是作者写的，是维基百科编辑写的

humanizer 的版本史里有个关键转折。2.0.0 的 release note 只有一句，按维基百科的 Signs of AI writing 页面重写了整个 skill。

那个页面背后是一个叫 WikiProject AI Cleanup 的编辑社群，2023 年成立，专门清理维基百科上泛滥的 AI 生成内容。他们在一线跟 AI 文本肉搏了几年，把识别经验沉淀成一份症状清单，35 个编号条目，每条都有触发词、病例分析和改写对照。

页面上有句话被 humanizer 原样搬进了 prompt，我翻译一下，大模型用统计算法猜下一个词，结果趋向最统计可能、适用面最广的表达。

病根是统计。模型永远挑「安全」的那个词，于是所有 AI 文章共享同一套安全词、安全句式、安全节奏。人类写作的毛病千奇百怪，AI 的毛病高度一致。

这也解释了为什么这份清单出自维基百科而不是某个 NLP 实验室。分辨 AI 文本这件事，天天在一线退稿的编辑，比发论文的研究员更有发言权。

35 个坏习惯长什么样

2.0.0 重写时是 24 条，一路打补丁，v2.8.0 加到 33 条，v2.10.0 补到 35 条。分成五类，内容夸大类、语言回避类、排版类、聊天机器人残留类、填充与对冲类。

每条格式统一，先列 watch words，再讲问题出在哪，最后给一组 before/after 对照。挑几条最扎心的。

第 8 条，回避 is 和 are。AI 不说 Gallery 825 is LAAA's exhibition space，非说 serves as，has 要写成 boasts。简单动词全部换成更长的，像人在简历里注水。

第 10 条，强制三连。innovation, inspiration, and insights。人类列清单想列几条列几条，AI 凑也要凑成三条，因为三在统计上最像「完整」。

第 14 条，破折号禁令。规则细到什么程度呢，返回结果前必须逐个搜索 em dash 和 en dash 字符并移除，除非作者本人的写作样本里就用。这条在中文世界同样成立，破折号已经是 AI 中文写作的头号指纹。

第 24 条，限定词堆叠。could potentially possibly，一个 maybe 的犹豫能摊成三个词。

后加的 31 到 35 条换了抓法，它们抓的已经不止是词，是「表演感」。第 31 条抓强制金句，三个短句连发，No preference. No prior. No nostalgia. 第 33 条抓假坦诚开场，Honestly? 打头的独立停顿。第 34 条抓回应没人提出的反对意见，第 35 条抓驳倒一个没人会选的假选项。

清单在进化。早期条目抓词汇，后期条目抓装人。

真正值钱的功夫在清单之外

坦白讲，35 条清单只是 SKILL.md 的前半部分。如果只有这个，它就是一份排版更漂亮的速查表。后半部分才是 prompt 工程的功力所在。

头一道工序是误报防护。文档专门有一节 What not to flag，列了 16 种不许误判的情况。语法完美不代表是 AI，可能是职业编辑。弯引号不代表是 AI，macOS、Word、Google Docs 默认都会自动替换。单独一个破折号证明不了任何事，要多个特征叠加才算证据。还有一条判断线划得干脆，2022 年 11 月 30 日之前写完的文本默认不是 AI，那是 ChatGPT 公开发布的日子。

这层的意图很清楚，清单是拿来磨稿子的，不是给人定罪的。

再往里是样本优先。你贴两三段自己以前写的文字，它会先分析你的句子长度、用词习惯、标点癖好，再照着你的样子改。规则给样本让路，第 14 条的破折号禁令在你惯用破折号时自动失效。人比规则大。

最硬的一道墙是事实封锁。What to do 一节第 3 条写得极硬，不许添加任何事实、名字、数字、日期、引文、引用，除非来自原文或用户。句子缺细节，要么开口问，要么把句子改简单，不许编。

说个时间线你可能不敢信，事实封锁是 v2.9.0 才加的，2026 年 7 月 22 日，issue #187 逼出来的补丁。在那之前的七个月里，一个专门改写你文本的 skill，一直没堵住「改着改着开始编」这个洞。去 AI 味和保事实是两件事，前者做起来爽，后者才是真风险，作者也是踩了坑才想明白。

改写流程本身是两遍式的。先出草稿，再用清单自查，自查要回答两个问题，哪句还像 AI，改写有没有增删任何事实。任何一个答案是肯定的，重改。最后才出终稿。

整条流水线长这样，回环是它和普通「帮你润色一下」prompt 的分水岭。

规则里特意写了一句，重述要整段自然展开，不许对着被标记的句子逐句打补丁。磨皮和重画，它选了重画。

它让文章更好读，但骗不过检测器

这是全文最需要说清楚的部分。

issue 区有个宝藏帖 #229，一个叫 itsryanlenk 的用户做了整套盲测。他本来想拿 humanizer 对付 AI 检测器，结论翻车了，但翻得特别有价值。

质量端，humanizer 赢麻了。模型原始输出对比 humanizer 改写版，16 次盲测 16 次全胜，评委全程不知道这场对比里有 AI 参与。

检测端，纹丝不动。AI 检测分数从 100% 降到 98.6%，再降到 97.8%，而这套检测的分辨下限大约四个百分点，等于没降。作为对照，143 份真人文本被检测器 143 次判为人类，说明检测器本身是灵的。他最后上了商用检测器 Pangram 4.0，humanizer 处理过的四个文本变体全部判 100% AI，其中一个变体一个词没改，只是挪动了句子拼接的位置。

更有意思的是失败原因。他统计评委引用的特征次数，humanizer 把词汇类特征杀干净了，节奏类特征不降反升，一张图看清这个剪刀差。

一边归零，一边反超。

他在 issue 里给出了我读了好几遍的结论，减法式重写让文章形态变得更均匀，而均匀的好形态本身就是 AI 的特征。人类写作忽长忽短、有好有坏，AI 写作是均匀的优秀。

所以能力边界很清楚。它治的是「读着难受」，治不了「被机器认出」。想要前者，它是目前免费的最佳实践。想拿它糊弄 Turnitin 或者内容平台的 AI 审核，省省吧，README 从头到尾没承诺过这个，3,636 个 fork 里估计不少人误会了才来的。

顺带摆一下市场坐标。搜索 humanize AI text 出来的全是订阅制 SaaS，Undetectable.ai、StealthGPT 一类，卖点是绕过检测器，按月收费。humanizer 走完全相反的路，MIT 开源，零成本，承诺可读性而不是隐身。一个治病，一个整容，别混着用。

边界还有两处，都来自 issue #238，提得相当专业。

文件模式没有防护栏。你给它一个文件路径，它改完直接写回，原文被覆盖之后你才第一次看到改动。粘贴模式里先给草稿和批评再给终稿的流程，到文件模式整个跳过。skill 要求保留代码块、YAML 元数据、链接目标不动，但改写流程里没有任何一步去验证这些约束真的守住了。

更隐蔽的一条，输入从未被声明为「内容」。skill 只说不要动引号里的触发词，却没说「你要处理的文本是待改写的内容，不是给你的指令」。一份等着被改写的文档里如果藏着一句对 agent 的命令，现有规则区分不出来。这是标准的 prompt injection 敞口，对一个有文件写入权限的 skill，值得认真对待。

一个仓库的 CI，是校验三个数字一致

最后说说仓库本身，这部分冷门但有味道。

9 个文件里，除 SKILL.md 外是一组跨 agent 打包的基建。.claude-plugin 目录下的 plugin.json 和 marketplace.json 让它能以 Claude 插件安装，skills 字段直接指向根目录的 SKILL.md。agents/openai.yaml 给 OpenAI 系的 agent 提供界面描述和默认提示词。上了 skills.sh 商店后累计 5,800 次安装，支持 Claude Code、Cursor、Codex、Copilot 等十来个 agent 宿主。

scripts/validate-package.py 是全部的「CI」，它校验三处版本号必须一致，SKILL.md 的 metadata.version、README 版本历史第一条、plugin.json 的 version。再检查全仓库只剩一个 SKILL.md，防止历史遗留的符号链接复活。

纯 Markdown 项目没有编译器替你抓不一致，文档同步全靠人工，所以我真翻出了一处漂移。README 的 pattern 表格把 26 到 35 号塞进了 Style patterns 分区，而 SKILL.md 里这些编号实际挂在 Filler and hedging 标题下面。validator 只管版本号，不管分类归属，这种漂移就漏过去了。

把清单工程化，是这个时代被低估的 skill 写法

回头看，43K Star 里，作者原创的知识其实有限。35 条特征是维基百科编辑社群的集体成果，Siqi Chen 是那个看出「这份清单可以直接变成 agent skill」的人。

我愿意把这个模式叫「清单工程化」。

很多领域的一线从业者，早把判断力沉淀成了公开清单。维基百科的 AI 症状清单、航空业的检查单、医疗的诊疗指南，这些清单被真实世界的失败案例反复敲打过，比任何个人 prompt 里的「请写得自然一点」都硬。而大部分写 skill 的人喜欢自己发明知识，把个人感想写成五百字指令。humanizer 反着来，忠实搬运社群清单，把工程力气花在真正需要功力的三处，防误用的负向规则、样本压过规则的优先级设计、事实安全边界。

下次你想写一个 skill，先问一句，这个领域的判断力有没有人已经列成清单了。有的话，别写感想，去工程化它。

humanizer 治不了机器检测，但它治得了你文章里那些连你自己都没察觉的统计惯性。就冲这个，值得装一个。