Humanizer：用35种模式清理AI腔
一个给AI文稿去掉机器腔的Markdown技能，按35种模式改写，还会保留代码和事实。
GitHub blader/humanizer 更新 2026-09-04 分支 main 星标 51.1K 分叉 4.1K
Markdown Skills CLI AI writing Claude Code 2.1.142+

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你的agent支持skills，并要处理AI生成的Markdown prose
    README 的“How it works”写明“it works with any agent that supports skills”，并说明文件模式只改prose。
  • 你希望依据Wikipedia的35种模式检查AI写作痕迹
    README 的“The 35 patterns”列出35种模式，来源是Wikipedia的“Signs of AI writing”。
  • 你能提供原文事实或2-3段个人写作样本
    README 写明事实细节必须来自source或writer，并支持提供写作样本进行voice matching。

不适合，如果你

  • 你的agent不支持skills，或运行环境不是README列出的安装路径
    README 只明确支持Skills CLI、Claude Code插件、Claude Desktop技能上传和手动复制SKILL.md。
  • 任务要求Humanizer补写缺失的姓名、数字、日期或引用
    README 的“How it works”明确写着“These must come from the source or the writer”，并说明“It does not make things up”。
  • 你需要已有版本、发布记录或贡献者信息来评估维护轨迹
    项目元数据显示贡献者为0、版本发布为0，最新版本为“No releases”。

前置条件

  • README 原文："Because it is just Markdown, it works with any agent that supports skills."
  • Skills CLI安装命令为：`npx skills add blader/humanizer --global`
  • Claude Code要求“2.1.142 or newer”才能安装插件。
  • Claude Desktop需要将仓库ZIP上传为skill，手动安装则复制`SKILL.md`。

第一步命令（README 原文）

npx skills add blader/humanizer --global

要注意

  • 文件模式只改prose，不会改代码、data、frontmatter或link targets
    README 的“How it works”明确列出这些保留内容。
  • 默认技术与参考文风保持neutral and plain
    README 写明“Technical and reference prose stays neutral and plain”。
  • 最终版本前会先展示first rewrite和short critique
    README 写明粘贴文本时会先展示初次改写及对人工感残留的简短批评。

材料未说明

  • README没有列出具体支持的agent名称或完整兼容性矩阵。
  • README没有提供性能、上下文长度、批量处理规模或运行成本数据。
  • README没有提供测试套件、准确率、人工评测结果或35种模式的覆盖指标。
  • README没有说明文本是否发送到外部模型、数据保留多久或隐私边界。
  • README省略了“Style patterns”和“Version history”章节，无法核对完整规则与变更记录。

💡 深度解析

6
不适合 我只允许 Humanizer 改写语言和常见 AI 写作模式，但必须保证文章通过任意 AI 检测系统；这个项目能满足这个要求吗？
适合读者： 希望保证文章通过任意 AI 检测系统、但只允许做语言改写而不改变事实的博客作者

不适合，因为项目目标是降低常见 AI 写作模式，不是提供通过任意检测系统的保证。

  • README 将功能定义为把 AI-sounding text 改写得像人写的，并以 Wikipedia 的 35 类模式作为编辑依据。
  • 它强调不改变原文所说的内容，也禁止自行补造姓名、数字、日期、引语和引用；因此它不是为了制造一套可验证的“人类来源证明”。
  • 项目洞察明确提醒，用户不应把工具当作 AI detector 或“绕过检测”的保证。
  • README 没有提供独立检测器、客观分数、确定性输出或任何检测系统的兼容性测试。
  • README「Humanizer」："Humanizer rewrites AI-sounding text so it reads like a person wrote it, without changing what it says."
  • README「How it works」："Humanizer uses 35 patterns from Wikipedia's 'Signs of AI writing'"
  • README「How it works」："It does not make things up."
  • 项目洞察「user_experience / common_pitfalls」：不代表能通过任何检测系统
/humanizer

[paste your text here]
材料未说明：README 没有说明任何具体 AI 检测器的测试结果或通过率。；README 没有定义“像人写的”的客观评分标准。
不适合 我正在处理包含学术引用和关键数字的高风险文本，要求不能新增事实；Humanizer 能否在不依赖人工终审的情况下直接交付最终稿？
适合读者： 编辑法律、医疗、金融或学术引用内容，并要求姓名、数字、日期、引语和引用绝不被补造的研究人员

不适合直接无人审查交付；Humanizer强调事实不能编造，但项目洞察明确不建议把它用于无人工审核的高风险文档。

  • README 要求姓名、数字、日期、引语和其他事实细节必须来自来源或作者，不能由工具自行补造。
  • 它会在首次改写后对照原始 claims 检查，这能降低风险，却不是独立的事实核验机制。
  • 项目洞察指出，底层代理仍可能发生语义漂移、遗漏限定条件或错误合并句子。
  • 对法律、医疗、金融、学术引用和高风险技术文档，项目明确列为不适合无人工审核的场景。
  • README「How it works」："A name, number, date, quote, citation, or other factual detail must come from the source or the writer."
  • README「How it works」："Then it checks the draft against those patterns and the original claims"
  • 项目洞察「user_experience / usage_limitations」：不适合在没有人工审核的情况下处理法律、医疗、金融、学术引用或高风险技术文档
  • 项目洞察「user_experience / common_pitfalls」：可能发生语义漂移、遗漏限定条件或错误合并句子
材料未说明：README 没有说明事实一致性检查的算法、覆盖率或可验证准确率。；README 没有说明引用解析、来源访问或法律与学术格式校验能力。
适合 我正在使用 Claude Code 2.1.142，同时还要让 Codex 或 Cursor 使用同一套规则；Humanizer 是否适合作为不引入独立服务和运行时的共享技能？
适合读者： 使用 Claude Code 2.1.142、Codex 或 Cursor，并希望把同一套写作规则接入 Agent Skills 工作流的开发者

适合，因为 Humanizer 本身就是 Markdown 格式的 Agent Skill，不需要独立服务、数据库或编译型运行时。

  • README 明确说它“因为只是 Markdown，适用于任何支持 skills 的 agent”。
  • 安装方式覆盖 Skills CLI、Claude Code 插件、Claude Desktop 上传和手动复制 SKILL.md。
  • Claude Code 插件要求版本为 2.1.142 或更新版本；这与你的版本约束直接匹配。
  • 它的规则和多阶段流程由提示词驱动，因此可以复用，但结果仍取决于所接入代理的指令遵循能力和上下文窗口。
  • README「Humanizer」："Because it is just Markdown, it works with any agent that supports skills."
  • README「Installation」：Skills CLI、Claude Code 插件、Claude Desktop 上传和手动安装
  • README「Installation」："Claude Code 2.1.142 or newer can install the plugin instead"
npx skills add blader/humanizer --global
材料未说明：README 没有提供 Claude Code、Codex 和 Cursor 的完整兼容性矩阵。；README 没有说明不同代理之间的输出一致性、性能或上下文窗口要求。
适合 我可以提供自己 2 至 3 段样文，并且希望保留节奏、用词、标点和有意保留的怪癖；Humanizer 会不会把文章统一改成默认的平滑风格？
适合读者： 希望保留个人语气、能提供 2 至 3 段写作样文的个人作者或研究人员

适合，前提是你把样文和目标文本一起提供；README 明确规定样文会优先于默认风格规则。

  • 使用 /humanizer 时，可以附上“2-3 paragraphs of your own writing for voice matching”。
  • Humanizer 会跟随样文的 rhythm、word choice、punctuation 以及 deliberate quirks，而不是只追求统一、平滑的表达。
  • 对个人写作，它承诺保留 writer’s style；对技术和参考文本，则会维持 neutral and plain 的风格。
  • 仍需注意，样文过短、风格不一致或体裁差异过大时，项目洞察指出风格匹配可能不稳定。
  • README「Match your voice」："paste 2-3 paragraphs of your own writing for voice matching"
  • README「Match your voice」："Humanizer follows the sample's rhythm, word choice, punctuation, and deliberate quirks."
  • README「How it works」："For personal writing, Humanizer keeps the writer's style."
  • 项目洞察「user_experience / common_pitfalls」：样文过短、风格不一致或体裁差异过大时效果可能不稳定
/humanizer

Here's a sample of my writing for voice matching:
[paste 2-3 paragraphs of your own writing]

Now humanize this text:
[paste AI text to humanize]
材料未说明：README 没有给出样文长度、体裁差异与风格匹配质量之间的量化关系。；README 没有提供风格保持的自动评分或回归测试。
视情况 我们要处理多份 Markdown 文件，并要求每个文件只改正文；README 是否提供了批量处理接口，而不是只能一次处理一段文本或一个路径？
适合读者： 需要处理多份 Markdown 文档，并要求批量保留代码、数据、frontmatter 和链接目标的文档团队

视情况：它支持文件级正文改写，但 README 没有承诺批量接口或目录递归处理，因此不能确认适合自动化处理整批文件。

  • Usage 章节给出的文件调用方式是提供单个路径：Humanize the prose in docs/launch-post.md。
  • 文件处理规则明确保留代码、数据、frontmatter 和 link targets，这满足单文件结构保护需求。
  • 项目以 Markdown Skill 运行在 Agent 内，而不是独立的批处理引擎；是否能循环处理多文件取决于具体 Agent 的工作流能力。
  • README 没有 CLI 的批处理参数、并发模型、失败重试或输出目录约定。
  • README「Usage」："To rewrite a file, give Humanizer its path"
  • README「Usage」："Humanize the prose in docs/launch-post.md"
  • README「How it works」："it changes only the prose, leaving code, data, frontmatter, and link targets alone."
  • 项目洞察「solution_analysis / usage_limitations」：不是独立文本处理引擎，主要面向 Markdown 和 Agent Skills 工作流
Humanize the prose in docs/launch-post.md
材料未说明：README 没有说明目录递归、批量输入、并发处理或失败重试。；README 没有说明批量处理后的文件命名、备份和差异输出方式。
视情况 我需要改写 `docs/launch-post.md` 的正文，但不能改变代码、数据、frontmatter 或链接目标；Humanizer 是否适合直接处理这个文件？
适合读者： 维护包含代码块、结构化数据、Markdown frontmatter 和链接的技术文档的内容作者

视情况：README 对这类 Markdown 结构保护有明确承诺，但复杂嵌套语法仍依赖代理正确执行技能指令。

  • 文件模式下，README 明确要求“只修改 prose”，保留代码、数据、frontmatter 和链接目标。
  • 它先改写，再根据 35 类模式和原始 claims 检查，并继续修订残留问题，适合处理语言层面的 AI 腔调。
  • 但项目不是独立文本处理引擎，结构保护实际上由底层 Agent 遵守提示词来完成。
  • README 未说明复杂模板语法、嵌套 Markdown 或特殊 CMS 标记的兼容性，因此不能把它当作结构化文档解析器。
  • README「How it works」："it changes only the prose, leaving code, data, frontmatter, and link targets alone."
  • README「How it works」："It makes a first pass... Then it checks the draft against those patterns and the original claims"
  • 项目洞察「user_experience / common_pitfalls」：复杂嵌套 Markdown、模板语法或特殊文档格式可能被意外修改
Humanize the prose in docs/launch-post.md
材料未说明：README 没有定义结构保护的自动化测试或失败检测机制。；README 没有列出复杂 Markdown、模板语法和 CMS 格式的兼容性范围。

✨ 核心亮点

  • 基于Wikipedia的35种AI写作模式
  • 保留原意，不补造姓名数字和引用
  • 文件模式只改 prose，保留代码与数据
  • 支持样本文风匹配节奏与用词
  • 社区元数据显示贡献者与版本均为0

🔧 工程化

  • 用35种模式检查初稿与原始事实主张
  • 通过/humanizer处理粘贴文本或文件路径
  • 文件改写保留代码、frontmatter和链接目标
  • 用2-3段写作样本匹配个人声音

⚠️ 风险

  • 依赖支持skills的agent，兼容范围未列明
  • 贡献者0人、版本0个，维护连续性未知
  • 缺失事实不会自动补造，需由来源或作者提供

👥 适合谁？

  • 使用Skills CLI的agent用户可直接安装
  • 需要清理AI腔的Markdown文档作者
  • Claude Code 2.1.142+用户可安装插件