刊 DailyNews 科技 / AI 每日文摘2026 年 10 月 30 日

每日文摘

深挖 · humanizer：456 行提示词拿下去 AI 味品类第一，原理能不能抄

题图

humanizer 是「去 AI 味」这个品类里星数最高的项目：40,470 stars、3,498 forks（GitHub API，2026-09-03 抓取），2026 年 1 月创建后两周冲到 3.6k，此后每月稳定涨四五千颗、七个多月没有衰减迹象。它值得深挖的原因有点反差：这个仓库没有任何代码——全部实现就是一份 456 行的 Markdown 提示词 SKILL.md，9 个文件里唯一的 Python 是 CI 打包校验脚本，作者自己在 AGENTS.md 里写明「The repo has no build step」（AGENTS.md、git tree）。一份提示词凭什么是品类头部、它的原理能不能抄来做一个中文版，是这篇文章要回答的问题。

是什么

先给结论：是的，humanizer 就是「让 AI 输出更像真人写的」工具——官方定位是「Agent skill that removes signs of AI-generated writing from text」，把带 AI 腔的文字重写成「像作者本人写的」，同时不改动原文陈述的任何事实（SKILL.md）。

但有一个边界必须先划清：它的目标是「人读起来不像 AI」，不是「骗过 AI 检测器」。这两件事经常被混为一谈，而证据把它们分得很开：

所以对它的预期应该是：一个跑在 agent 里的文风编辑器，而不是学术不端工具。

核心机制：一份 SKILL.md 的四个部件

humanizer 的机制是纯 prompt 工程——没有统计检测、没有分类器、没有后处理代码。拆开看是四个部件。

部件一：35 条「AI 写作特征」模式清单。 这是它的知识主体，而且不是作者发明的——源头是 Wikipedia 编辑社群维护的 Wikipedia:Signs of AI writing，一群天天清理 AI 词条的编辑整理出的实战清单（SKILL.md）。每条模式的结构固定：Words to watch 词表 + Problem 说明 + Before/After 成对示例。代表性条目：

部件二：固定四步重写流程。 先对照 35 条清单标记 AI 特征；写草稿并「read it aloud」检查节奏；然后两问自检——「还有什么听起来是 AI 生成的？」「重写是否增删了任何事实、名字、数字、日期、引述？」；最后成段自然重写，而不是逐条打补丁（SKILL.md）。

部件三：防幻觉硬约束。 「Do not invent facts. Do not add a fact, name, number, date, quote, or citation unless it comes from the source or the user.」缺细节就问用户，不许编。这条是 v2.9.0 加的——早期有用户报告它重写时会编造细节，社区反馈直接变成了 prompt 的一条硬规则（SKILL.md、README 版本史）。

部件四：反误报白名单 + 声音匹配。 这是最见功力的部分。专设一节「What not to flag」：完美语法不等于 AI、正式词不等于 AI、单个破折号不算（编辑记者常用）、单独弯引号不算（macOS 和 Word 默认自动替换）——判定原则一句话：「One em dash proves nothing. Several stock patterns in the same passage are stronger evidence.」（单特征不构成证据，多特征叠加才算）。声音匹配则是让用户贴 2–3 段自己的旧文，先分析样本的句长、用词、标点、怪癖，再按这些习惯重写，且写作样本的优先级高于内置规则——样本里常用破折号，破折号禁令就不适用（SKILL.md）。

还有一个容易被忽略的设计：它对「有人味」的定义不只靠删。SKILL.md 明确要求保留这些人的痕迹——具体而反常的细节、混合情绪与未消解的矛盾、时代性梗（模型训练滞后一年以上所以写不出来）、长短句交替、真正的插入语与自我纠正。判定锚点也很有意思：「2022-11-30（ChatGPT 发布）之前的编辑几乎不可能是 AI 写的」（SKILL.md）。

怎么跑起来

它不是 npm/pip 包，没有可执行文件，就是一个 agent skill：

数据说话

值不值得跟：对「收集资料 → 整理文章给人读」的场景

这个场景（比如本站的日报和深挖文章：AI 收集资料、整理成文、读者是人）恰好是 humanizer 的正面战场——有用，但有三点要想清楚。

第一，用法要对：它是发布前的最后一道文风编辑，接入点在「草稿 → 发布」之间，不是写作环节的一部分。

第二，直接拿来用会水土不服。35 条 pattern 面向英文写作——delve/tapestry 的词表、Title Case 标题、em dash 禁令，这些放到中文文章里要么不适用、要么规则完全不同（中文的「AI 味」是另一套：排比、「值得注意的是」、空洞总结段）。中文可参考社区本地化 fork：Humanizer-zh-TW（826★）和 De-AI-Prompt-Enhancer-Writer-Booster（743★），但都远不如原版打磨。

第三，真正值得搬的是原理，自己做一个中文版 skill 时有四件内容层设计可以直接抄：

  1. 模式清单每条带 Before/After 成对示例——成对示例比抽象规则对 LLM 有效得多，这是整份 SKILL.md 最核心的格式决策
  2. 四步流程 + 两问自检——尤其是第二问「事实有没有漂移」，把防幻觉做进流程而不是靠模型自觉
  3. 防幻觉硬约束写成禁令——不许增删事实、名字、数字、日期、引述，缺信息就问（对资料整理类文章这是底线）
  4. 反误报白名单 + 声音样本优先——「单特征不构成证据」防止把正常文风抹平；让用户贴旧文做 voice matching，比套一个统一的「人味」模板高明——已有社区实践（voice-humanizer）在此基础上加个人语料 CORPUS.md（dev.to）

工程层还有三件值得抄：CI 校验三处版本号一致、pattern 必须连续编号且与 README 表格同步、SKILL.md 不超过 500 行（validate-package.py）——把一份 prompt 当软件包来维护，是这个项目最被低估的护城河。它的维护史也说明了规则式路线的宿命：只覆盖已知特征，新型 slop 要靠持续发版跟进词表，所以 v2.6 到 v2.11.2 的每次 minor 都在改内容。它动不了采样层——那是 antislop-sampler 那条路线（生成时命中 slop 短语就回退重采）的地盘，但那个需要自己控制推理栈，门槛完全不同。

一句话总结：humanizer 证明了「知识整理 + 流程设计 + 工程化维护」这份看起来最没有技术含量的工作，在 prompt 工程里能做到什么高度——40k stars 拜的不是算法，是 Wikipedia 编辑社群的众包知识被包装成了可执行、可分发、可迭代的 skill。

参考阅读