GitHub 项目解读

Humanizer-zh 项目分析报告

分析 op7418/Humanizer-zh 的项目定位、Skill 结构、中文适配、上游差距、使用价值、风险和改进建议。

生成时间：2026-06-20 形态：Claude Code Skill License：MIT Stars：约 10,803

结论先行

Humanizer-zh 不是一个传统意义上的“工具库”，而是一份面向 Claude Code Skills 的中文编辑提示词。它的价值在于把“AI 味文本”的常见症状整理成可执行的编辑规则，让模型在改写时少用套话、少做宣传式扩写、多保留具体信息。

它适合个人写作、公众号草稿、产品文案、报告初稿的二次润色，也适合拿来训练团队识别 AI 写作痕迹。但它不是 AI 检测器绕过工具，也不是稳定的自动化改写引擎。仓库只有 README.md、SKILL.md 和许可证，没有测试、脚本、评测集或 CI。

最大的风险不是安全漏洞，而是版本落后和使用预期错位。英文上游 blader/humanizer 已到 v2.8.0，覆盖 33 种模式；Humanizer-zh 当前主分支仍是 24 种模式，缺少 voice calibration、二次审查、反误判指南、#25-33 新模式等关键更新。

仓库快照

仓库op7418/Humanizer-zh
项目描述Humanizer 的汉化版本，Claude Code Skills，旨在消除文本中 AI 生成的痕迹。
主分支最新提交91f3d394...，2026-01-19，添加 npx 一键安装方式
GitHub API 快照约 10,803 stars、806 forks、15 watchers，仓库更新时间 2026-06-20 11:08 CST
文件规模3 个核心文件，约 750 行；SKILL.md 约 484 行，README.md 约 239 行
许可证MIT License，版权行写为 2026 歸藏
上游来源翻译自 blader/humanizer，并参考 hardikpandya/stop-slop

它到底是什么

Humanizer-zh 的核心文件是 SKILL.md。这个文件定义了一个 Claude Code Skill：当用户要编辑、审阅或“去 AI 味”时，模型按其中的规则扫描文本，再改写成更自然的版本。

它不是二进制程序，也没有本地 NLP 模型。真正执行改写的是宿主大模型，Humanizer-zh 只是给模型一套编辑规程。换句话说，它的能力上限取决于三件事：规则质量、宿主模型的写作能力、用户提供的上下文和样本文本。

它能做

  • 识别常见 AI 套话和宣传腔。
  • 把泛泛而谈改成更直接的表达。
  • 减少三段式、过度粗体、表情符号、通用积极结尾。
  • 提醒作者加入具体事实，而不是只保留抽象判断。
  • 给改写结果按直接性、节奏、信任度、真实性、精炼度打分。

它不能保证

  • 不能保证绕过朱雀、Turnitin、GPTZero 等检测器。
  • 不能验证事实真伪。
  • 不能自动补充可靠引用。
  • 不能判断所有中文语境里的风格差异。
  • 不能在没有宿主模型的情况下独立运行。

规则体系

Humanizer-zh 把 AI 写作痕迹分成四组，共 24 种模式。

内容模式夸大意义、过度强调知名度、肤浅分析、宣传语言、模糊归因、公式化挑战与未来展望。
语言模式高频 AI 词汇、回避“是”、否定式排比、三段式法则、同义词循环、虚假范围。
风格模式破折号、粗体、内联标题列表、标题大小写、表情符号、弯引号。
交流模式聊天机器人痕迹、知识截止免责声明、谄媚语气、填充短语、过度限定、通用积极结论。

这些规则的优点是具体。比如它不会笼统地说“写自然点”，而是要求删掉“作为……的证明”“此外”“不仅仅是……而是……”“行业专家认为”等常见结构。对很多中文 AI 草稿来说，这种清单式编辑很有效。

但它也有一个明显问题：规则主要从英文语境翻译过来。中文里的 AI 味不只来自英文式结构，还来自中文平台写作习惯，例如“毋庸置疑”“值得一提的是”“可谓是”“赋能”“闭环”“底层逻辑”“抓手”等。当前版本有中文示例，但还没有形成足够本土化的中文模式库。

与英文上游的差距

Humanizer-zh 当前内容大体对应英文 humanizer 早期版本。对照 2026-06-20 拉取的 blader/humanizer 主分支，英文版已经有 33 种模式，并在 README 中标注 v2.8.0。

这意味着 Humanizer-zh 的热度很高，但规则集不是最新的。对于“今天的 AI 写作痕迹”，英文上游已经补了不少新模式，中文版还没有同步。

voice calibration英文版支持用用户自己的写作样本匹配语气；中文版没有明确流程。
draft → audit → final英文版要求先写草稿，再问“哪里还明显像 AI”，然后二次改写；中文版主要是一次性改写。
反误判指南英文版增加“不要误判”的清单，例如不要把单个破折号、正式词汇、干燥文风直接判成 AI；中文版缺少这层保护。
新增模式英文版新增 passive voice、hyphenated word pairs、persuasive authority tropes、signposting、fragmented headers、diff-anchored writing、manufactured punchlines、aphorism formulas、conversational rhetorical openers 等。
兼容声明英文版 frontmatter 标注 version、license、compatibility、Grep/Glob 等工具；中文版 frontmatter 更旧，只列 Read/Write/Edit/AskUserQuestion。

仓库 PR 列表也印证了这个问题：有人提交过“合并 blader/humanizer v2.5.1 全部 29 种模式”的 PR，也有人提交模块化 references 结构，但截至本次分析，主分支仍未体现这些更新。

中文适配质量

这个项目的中文翻译基本可读，而且 README 里增加了中文场景示例，比如营销文案、学术摘要、博客文章。对普通用户来说，安装和使用说明足够清楚。

不过，中文适配还不算成熟。最明显的是标点和引号问题：Issue #11 和 #13 都在讨论中文标点、引号使用，PR #18、#19 也试图修复相关问题。这说明它已经被中文用户实际使用，但也说明当前规则对中文排版规范处理得不够稳。

另一个问题是“人味”的定义偏个人博客风格。比如它鼓励第一人称、混乱感、观点和幽默。这对随笔、评论、社媒内容有用，但对法律文本、投研报告、技术文档、学术摘要未必合适。英文上游后来已经加了约束：只有在内容和作者声音需要时才加入个性；中文版还没有把这个边界写得足够清楚。

社区信号

从 GitHub 数据看，Humanizer-zh 的传播非常强：仓库创建于 2026-01-19，到 2026-06-20 已有约 10.8k stars 和 806 forks。它吃到了两个趋势：Claude Code Skills 的扩散，以及中文用户对“AI 味文本”的普遍焦虑。

但维护活跃度和热度不匹配。主分支只有 6 个提交，最新提交仍停在 2026-01-19。Issues 和 PR 中有不少未处理问题，包括 Claude Code 加载失败、中文标点、跨平台适配、URL 改写、在线入口、检测器效果质疑等。

正向信号

  • Stars / forks 很高，说明需求真实。
  • README 安装路径清晰，降低了普通用户门槛。
  • 明确标注来源，引用英文 humanizer、stop-slop 和 Wikipedia 指南。
  • Issue 区有真实用户反馈，不是空仓库热度。

负向信号

  • 主分支长期未同步英文上游。
  • 缺少测试、版本号、变更日志和 release。
  • 未合并 PR 较多，维护节奏偏慢。
  • 部分用户把它当检测器绕过工具，预期偏离项目声明。

使用价值

我认为它最有价值的场景不是“把 AI 文本洗成人写的”，而是做编辑检查表。它迫使作者回答几个朴素问题：这句话有没有具体信息？这个结论是不是只是漂亮话？这个段落是不是在用套话撑篇幅？这个列表是不是模型习惯性凑三项？

在个人工作流里，可以把它放在写作链路的最后一步：

  1. 先让模型生成事实草稿或结构草稿。
  2. 人工补充事实、立场、引用和上下文。
  3. 再用 Humanizer-zh 清理 AI 套话。
  4. 最后人工复读一遍，确认没有把信息删薄。

它不适合放在第一步，也不适合自动批量改写重要材料。因为“去 AI 味”的过程很容易把文本变得更短、更顺，但也可能删掉限定条件、证据边界和必要的正式语气。

风险分析

伦理和定位风险

README 末尾写得比较克制：这个工具不是为了欺骗 AI 检测器，而是为了提升写作质量。但现实里，“去 AI 味”很容易被理解成“绕检测”。Issue #12 里就有人反馈“过不了朱雀 AI 检测”。这类反馈不是项目缺陷本身，但会改变社区对项目的使用方式。

事实风险

Humanizer-zh 只管风格，不管事实。它会鼓励把“行业专家认为”改成具体来源，但不会自动帮你找到来源。用户如果把未经核实的 AI 草稿直接交给它，最后可能得到一篇更像真人写的错误文章。

风格误伤

规则清单有误伤概率。破折号、正式词汇、粗体、三项列表都可能是人类作者的正常选择。缺少英文上游新增的“不要误判”部分后，中文版更容易把合法风格也清掉。

许可与来源

仓库使用 MIT License，并声明翻译自 blader/humanizer、参考 stop-slop，底层思想来自 Wikipedia 的 Signs of AI writing。常规个人使用问题不大；如果要商业再分发或包装成产品，建议保留完整来源声明，并进一步核查 Wikipedia 内容引用和派生许可边界。

改进建议

  1. 同步英文上游 v2.8.0 的 33 种模式，尤其是 voice calibration、反误判指南、二次审查流程。
  2. 建立中文专属模式库，加入公众号、小红书、投研、商业计划书、技术博客常见套话。
  3. 把 SKILL.md 模块化，拆成核心规则、中文词表、示例、评分表，减少单文件膨胀。
  4. 增加版本号、CHANGELOG 和 release，避免用户不知道当前对应哪个上游版本。
  5. 增加最小评测集：给出 20 到 50 段中文 AI 草稿、人工编辑结果、改写前后对比。
  6. 明确不同文本类型的策略：报告、论文、产品文案、社媒、个人随笔、法律文本不该使用同一套“人味”目标。
  7. 补充“不是检测器绕过工具”的边界说明，减少错误预期。

给我们的使用建议

可以装，但我不建议直接把它作为唯一 humanizer。更好的做法是把它当中文提示词素材库，再结合英文上游最新版本和我们已有的 humanizer skill。

如果用于 OpenClaw / Codex 工作流，我建议这样组合：

事实核查：先查来源，补齐证据
结构编辑：确认段落逻辑和信息密度
Humanizer-zh：清理中文 AI 套话
英文上游 humanizer：补充 #25-33 新模式和二次审查
人工复核：确认语气、事实和边界没有被改坏

如果要长期使用，值得 fork 一个内部版，把中文词表、你的写作偏好、报告风格要求和反误判规则都加进去。这个项目真正的价值不在“安装即完美”，而在它给了一个可维护的编辑框架。

最终判断

Humanizer-zh 是一个需求抓得很准、使用门槛很低、传播效果很强的中文 Skill 项目。它能显著改善常见 AI 草稿的表面质感，尤其适合清理套话和宣传腔。

但从工程和内容维护角度看，它更像一个热门翻译版，而不是成熟的中文写作工具。它需要同步上游、补中文语料、补反误判指南、补版本管理，才适合进入稳定生产写作链路。

我的结论：值得关注和借鉴，适合轻量使用；不适合被包装成“自动去 AI 检测”方案，也不适合无人工复核地处理重要文本。