Humanizer：一个 SKILL.md 文件，用 35 条模式清单拆掉 AI 腔
代理技能可从文本中删除人工智能生成的书写痕迹。它是纯 Markdown，因此可以在任何支持技能风格指令的工具中运行。
秒懂
- 它是什么？
- blader/humanizer 是纯 Markdown 写的代理技能，规则取自维基百科《AI 写作的迹象》。这里拆它的两遍改写流程、不虚构规则、 voice 匹配机制，以及 2.9.1 为可移植性删掉了什么。
- 适合谁用？
- 适合已经在用支持技能的代理框架、且常被模型输出里的营销腔和套路句式烦到的人，也适合团队把它当代码规范那样统一文风；不适合指望它提升事实准确度，它明确不做这件事。装之前先验证三件事：它对代码、数据和 frontmatter 的边界保护在你的仓库里是否可靠，提供写作样本前后输出差异有多大，以及中文文本上那套英文句式的规则有多少真的适用。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 9 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个 SKILL.md 文件，能跑在任何支持技能的框架里
Humanizer 的运行时产物是单个 SKILL.md 文件，这一点决定了它的全部特性。它不是库，不是命令行工具，也不绑定某个模型，只要在支持技能式指令的框架里放对位置，代理就能加载。仓库语言标为 Python，但从使用方式看，Python 只是元数据上的归类，实际发挥作用的是那份 Markdown。
主页挂在 skills.sh/blader/humanizer，许可 MIT，版权归 2025 年的 Siqi Chen。抓取时 star 38556，fork 3373，未关闭 issue 只有 20 个，最近一次推送与 v2.11.1 发布同为 2026 年 8 月 18 日，v2.11.0 在 8 月 17 日，v2.9.1 在 7 月 22 日。这种一个文件撑起近四万星的情况，说明它击中了一个普遍痛点，而不是解决了什么技术难题。
35 条模式，来自维基百科那份 AI 写作迹象清单
规则的出处写得很明确：维基百科上由 WikiProject AI Cleanup 维护的 Signs of AI writing 条目。README 把它整理成 35 条，每条配改写前后的对照例子，分五类。
内容类六条，处理的是说法本身：重要性膨胀、靠点名媒体来证明重要性、用象征与展现这类 ing 结尾的空洞分析、推销腔、来源模糊的专家认为、以及先讲挑战再讲继续繁荣的公式化结构。语言和语法类七条，包括滥用 actually 与 testament 这类高频词、用 serves as 回避 is、不是 X 而是 Y 的句式、强行凑三项、同一个人换三种叫法、从大爆炸到暗物质的假范围、以及缺主语的被动句。
风格类数量最多，从破折号、过度加粗、带粗体小标题的列表、标题首字母大写、表情符号、弯引号，到过多连字符词组、假的深层道理、预告下一句、标题下方重复标题、写旧版本、硬凑的金句与残缺句、套话、假坦率的开场、回答没人提出的质疑、以及先否掉一个假选项。对话类三条管聊天残留、知识局限声明和过度附和。填充类三条管填充短语、堆叠限定词和泛泛的积极结尾。
两遍改写：先动结构，再按清单审计
流程不是一次性替换。第一步是不把原文结构当作固定前提，直接重写一遍。第二步把这一稿同时对照那 35 条模式和原文的主张逐项检查，还有问题的地方再改。改完之后还会做一次「明显是 AI 生成」的审计扫描，触发第二次重写。
这个顺序有意义：很多 AI 腔不在词句层面，而在结构层面，比如每段都以同一个词开头、或者结尾非要升华一下。只做词替换改不掉这些。
README 引用了一句对成因的解释：大语言模型用统计算法猜下一个该出现什么，结果会趋向于适用面最广、统计上最可能的那一种。这句话可以作为理解整套规则的线索，它说明这些痕迹不是模型偷懒，而是采样机制的自然产物。
不虚构规则：具体性只能来自原文或作者
这是整套规则里最值得强调的一条，也是 2.9.0 才引入的。任何姓名、数字、日期、引文、引用或其他事实细节，都必须来自原始文本或作者本人，不允许重写时补进来。为了配套，README 里所有曾经模拟编造细节的示例都被重新裁剪过。
规则还按文体分了档：个人化写作保留作者自己的风格；技术与参考类文本保持中性平实。如果提供了写作样本，技能会按样本走，而不是套用默认的风格规则。
这条约束把 Humanizer 与「让文字更好看」的工具区分开了。它改的是表达，不动内容，具体性不够时正确的行为是回头问作者，而不是自己补。
voice 匹配：给两三段落，它照着你的节奏写
想让输出像自己，做法是在调用时附一段两到三段的个人文字，说明用于匹配语气。README 说技能会分析样本的句式节奏、用词选择、标点习惯和那些刻意的怪癖，然后把这些套用到改写结果上，而不是产出一份通用的干净文本。
调用方式有三种：用 /humanizer 后直接粘贴文本；用自然语言说请把这段文字改得像人写的；或者直接给文件路径，让它改文档里的散文。
不给样本时它按默认规则走，README 没有说明默认风格具体是什么样，也没有说样本太短会有什么后果，这两点只能自己试。
三种装法，以及 2.9.1 为可移植性做的减法
最省事的是 skills 命令行：npx skills add blader/humanizer --global 全局安装，npx skills update humanizer --global 更新，加 --agent 通配可以给所有支持的框架装，也能指定某一个。省掉 --global 就是项目本地安装，可以提交进仓库共享。
Claude Code 用户走插件路径：先 /plugin marketplace add blader/humanizer，再 /plugin install humanizer@humanizer，之后用 /humanizer:humanizer 调用。手动装也行，把 SKILL.md 复制到框架预期读取技能的目录即可。
2.9.1 这个版本值得单独提，因为它做的全是减法：移除了不可移植的前置元数据和工具预批准，把全局安装定为文档默认，增加包校验，并从运行时提示里删掉了一段重复的长示例。这套改动的目标很明确，就是让同一份文件在不同框架里行为一致，代价和收益都落在可移植性上，35 条模式一条没动。
它能改什么，改不了什么
处理文件时，技能只改散文部分，代码、数据、frontmatter 和链接目标都保持原样。粘贴文本时，它会先把过程和简短的自我评判展示出来，再给最终版本，你能看到初稿和它认为哪里还像机器写的。这个展示中间步骤的设计，让使用者有机会在最终稿之前拦一道。
改不了的部分同样清楚。它不负责事实核查，不负责补细节，也不判断内容对错。清单本身是针对英文写作整理的，像标题首字母大写、弯引号、连字符词组这类规则挪到中文语境后基本不适用，而强行凑三项、套话、假的深层道理这几条倒是通用。中文使用者需要自己做一次筛选。
许可证是 MIT，按原样提供，不含任何担保，也未涉及安全、支持或维护义务。把它接进自动发布流程之前，最好留一份人工复核的环节。
编辑结论
适合已经在用支持技能的代理框架、且常被模型输出里的营销腔和套路句式烦到的人，也适合团队把它当代码规范那样统一文风；不适合指望它提升事实准确度，它明确不做这件事。装之前先验证三件事：它对代码、数据和 frontmatter 的边界保护在你的仓库里是否可靠，提供写作样本前后输出差异有多大，以及中文文本上那套英文句式的规则有多少真的适用。
社区笔记