NulightJens/humanizer-stack · 上手攻略

• 仓库：NulightJens/humanizer-stack
• 链接：https://github.com/NulightJens/humanizer-stack
• 分类：agent-skills / writing-assistant / ai-detection
• 作者：spark
• 更新：2026-08-10

是什么

NulightJens/humanizer-stack 是一个面向 Claude Code 的双通道（two-pass）"AI 写作去机器味"管线，把"表层词面改写"和"结构层改写"拆成两个独立 skill：

• skills/humanizer/ — Pass 1：词汇、标点、句法层面的修整（基于 Wikipedia "Signs of AI writing" + 3.2M Reddit 帖子的"读者实际会标哪些"统计）。
• skills/structural-humanizer/ — Pass 2：discourse 结构层改写，基于 Russell et al. 2026 发表的 StoryScope 研究（61,608 篇故事、5 个 LLM + 人类作者，仅用 discourse-level features 把 AI 检测推到 93.2% F1）。

仓库还附带两个确定性 Python 扫描器（scripts/copy_scan.py、scripts/structural_scan.py），可作为 pre-commit / CI gate。整体协议是 MIT（仓库自有代码）+ 上游条款（含 CC BY-SA 4.0 的 share-alike 义务，详见 ATTRIBUTION.md）。

解决什么问题

• 词面修整正在失效：仓库引用 GPT 5.4 已经显著降低 em-dash 使用率、fine-tuning 把 stylometric 检测从 97% 打到 3% — 单层"换词"是被快速磨平的攻击面。
• 结构指纹才是稳定信号：StoryScope 实验只给 discourse-level features（屏蔽所有 style feature），仍能达到 93.2% F1；LAMP 一次专业级表层改写只让检测下降 1.6 个百分点。结论：词层改了没用，结构层要重写。
• "用人类对 AI 的写作模式"的统一对位：表层参考 Wikipedia "Signs of AI writing" + 320 万 Reddit 帖子的人群级判断，结构层用 6 项 audit 直接对照 StoryScope 数据。
• 判定 + 改写一体化：用户既能拿到一份 markdown diff，也能在 hook / pre-commit 链路上用 --json / --strict 跑机械扫描。

快速安装

仓库提供 install.sh，默认挂到 ~/.claude/skills/：

git clone https://github.com/NulightJens/humanizer-stack.git
cd humanizer-stack
./install.sh

默认用 symlink（git pull 后自动生效）。如需自包含：

./install.sh --copy

手动等价：

mkdir -p ~/.claude/skills
cp -R skills/humanizer skills/structural-humanizer ~/.claude/skills/

项目级安装（仅当前项目生效）：

cp -R skills/humanizer skills/structural-humanizer .claude/skills/

校验依赖：

python3 --version      # 仅扫描器需要 Python 3
python3 scripts/copy_scan.py --help
python3 skills/structural-humanizer/scripts/structural_scan.py --help

核心用法

1. 在 Claude Code 里按意图触发

humanize this post
de-slop this lesson
run the structural pass on draft.md

skill 会按文件名/意图路由到 humanizer（Pass 1）或 structural-humanizer（Pass 2）。官方推荐顺序：先表层，再结构（见 docs/PIPELINE.md）。

2. 扫描器单独用（CI / pre-commit）

# Pass 1 词汇/标点扫描
python3 scripts/copy_scan.py draft.md
python3 scripts/copy_scan.py --json draft.md
python3 scripts/copy_scan.py --strict draft.md   # 命中即 exit 1
cat draft.md | python3 scripts/copy_scan.py -    # stdin

# Pass 2 结构扫描
python3 skills/structural-humanizer/scripts/structural_scan.py draft.md

两个 scanner 都是 deterministic + grep-able 的，只抓"模式可匹配"那一半（cadence、formulaic shape、polished-but-empty 仍要靠人读）。

3. 抑制扫描命中

在文本里加 magic comment 即可让扫描器跳过该行（避免误报"故意用法"）：

<!-- copy-ignore -->

4. 6 项结构 audit 速查（来自 StoryScope）

仓库原话："Do not trade one default for another." 每篇只挑 1-2 项干预，并能在事后说出"这篇为什么选这个形状"，否则反而构建新的可识别聚类。

5. 文体裁剪（genre calibration）

不同文体（邮件 / 营销 / 学术 / 博客）只有部分 audit 适用。references/genre-calibration.md 给出按文体裁剪指南。

典型适用场景

• Newsletter / 公开博客：先 Pass 1 改掉词汇暗示，再 Pass 2 让"主题直白"和"情绪身体表演"在博客语境下收敛到符合人味的角度。
• 长文 / 长篇小说：Pass 2 的 6 项 audit 在 ~5000 字的样本上做过实验，最适合迁移到类似长度的长文。
• 批量内容生产线：把 scripts/copy_scan.py --strict 接进 pre-commit，命中即拒绝合并；适合做平台化的内容质量门。
• 教学 / 培训：把 6 项 audit 作为"读者鉴别 AI 文本"的判读清单直接发给学员/同事。
• CI 钩子：在 PR 流水线里跑两个 scanner，输出 JSON 报告给审查者。

坑与注意

1. 审计 3 与"show, don't tell"传统写作建议相悖：数据显示"用身体表演情绪"是机器签名，真正的人味反而可能是直白命名情绪。在套用前要意识到这是数据结论，不是文风偏好。
2. StoryScope 样本边界：研究基于约 5,000 字的虚构文本，迁移到短篇非虚构是推断而非论文直接结果。最干净迁移的子集是 audit 1 / 3 / 4 / 6（theme explicitness、emotion mode、reference specificity、shape convergence），其他 2 项（structural tidiness、reader engagement）需要按文体重新校准。
3. 不要把一种默认换成另一种默认：所有文章都"中段开场 + 命名三种情绪 + 结尾留开放"，就会构造新可识别聚类。仓库原话："Pick one or two interventions per piece, vary them across pieces."
4. Scanner 命中率约 50%：scanner 只抓模式可匹配那一半，cadence / formulaic shape / polished-but-empty filler 仍要靠人读判断。
5. 协议混合：MIT（仓库自有）+ CC BY-SA 4.0（Wikipedia "Signs of AI writing"）+ 上游 MIT 条款。再分发时 CC BY-SA 4.0 部分带 share-alike 义务，必须看 ATTRIBUTION.md 确认范围。
6. 跨 agent 兼容性：仓库明确打包为 Claude Code Skills；其他 agent（Codex CLI、Cursor、Copilot）按各自 skill 目录约定手动 copy；不像 harshaneel/humanize 那样给 install.sh all 一键三平台。
7. Pass 顺序不可反：结构层 audit 在表层修整之前做会被词面残留误判，README 强制"Pass 1 → Pass 2"。
8. 不要把它当"反检测器"：仓库原话："Nothing here makes text undetectable, and that is not the goal." 目标是写得像有个具体观点的人写的，不是骗分类器。

与同类对比

• harshaneel/humanize：双 skill（humanize + ai-check），9 杠杆 + ai-check 取证打分，研究溯源到 50+ 检测文献；humanizer-stack 双 pass，更强调结构层 audit 与 StoryScope 实验数据，分工粒度更细。两者可叠用 — 先 harshaneel/humanize 做 ai-check 报告 + 改写，再 humanizer-stack 跑两个 pass 收结构。
• blader/humanizer：单 SKILL.md，无研究溯源，社区最大；humanizer-stack 是"在 blader 基础上加了 structural pass"的衍生，仓库 ATTRIBUTION 已注明借鉴。
• ssamba1/untell：detector-in-the-loop CLI，绑定具体 detector API；humanizer-stack 不拉外部检测器，离线/隐私友好是优势。
• Aboudjem/humanizer-skill：53 模式 + 5 voices + 0-100 AI-tell 打分；humanizer-stack 不打总分，输出更偏 audit 列表。
• Aboudjem/humanizer-skill 同类 rudra496/StealthHumanizer：4 层流水线 + 35 providers，是商业级 SaaS；humanizer-stack 保持 Claude Code skill 形态、不依赖外部 provider。
• forint573/human-copywrite：聚焦营销长文，强调品牌声口保留；humanizer-stack 通用叙事 + 文体裁剪指南，无品牌声口保留机制。
• badrusiddique/naturalize：Wikipedia 单一来源 + always-on 默认 + 内置 self-audit；humanizer-stack 把 Wikipedia 当 Pass 1 起点，Pass 2 走研究级 StoryScope 数据，结构更厚。
• 0xwilliamortiz/humanizer-cli：33 种 AI 写作判别 CLI，无改写；与 humanizer-stack 的 scanner 形成"检测 vs 改写"互补。

humanizer-stack 的差异点：(a) 唯一以 StoryScope 93.2% F1 研究为锚的结构层改写；(b) 双 pass 严格分工（词面 / 结构）；(c) 离线 + 零外部 API + Python 扫描器可接 pre-commit；(d) MIT + 上游条款混合协议明确告知。

一句话推荐结论

如果你把"AI 写作可读性"当成长期命题而不是一次性清洗，且愿意投入两个 pass 的代价认真做结构层改写，humanizer-stack 是 2026 年研究溯源最完整的 Claude Code skill；先表层再结构两遍跑下来，比单层改写在检测器和真实读者两端都更稳。

来源：

• GitHub README（NulightJens/humanizer-stack）：https://github.com/NulightJens/humanizer-stack — 双 pass 设计、6 audit、scanner 用法、协议说明、StoryScope 引用全本。
• StoryScope 研究：https://github.com/jenna-russell/storyscope — Russell et al. 2026，61,608 故事 discourse-level 分类 93.2% F1，LAMP 改写仅降 1.6 点。
• Wikipedia "Signs of AI writing"：https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing — Pass 1 词汇层参考。
• ATTRIBUTION.md（仓库内）：上游条款与 CC BY-SA 4.0 share-alike 范围。
• GitHub Topics 页面（writing-tools / humanizer / humanize-ai）：https://github.com/topics/writing-tools — 同类横向对比。

不确定处：

• scripts/copy_scan.py 与 scripts/structural_scan.py 的具体规则列表与版本号未在 README 详细列出，本机未独立枚举。
• StoryScope 研究本身的 5 个 LLM 模型清单（README 未列名）仅基于 Russell et al. 2026 论文标题；本攻略引用 61,608 故事 / 93.2% F1 / LAMP 降 1.6 点等数字均出自仓库叙述，未独立 fetch 论文原文复核。
• "GPT 5.4 already cut its em-dash usage sharply" 与 "fine-tuning drops stylistic detection from 97% to 3%" 两个数字来自 README 自述，未给出原始报告链接。
• install.sh 是否接受 --copy 之外的额外参数（如 --target）未在 README 详列；本机未运行 bash install.sh --help。
• audit 3 与"show, don't tell"的张力虽在 README 中明确，但与具体文体（如电影剧本、营销文）边界条件未在仓库内给出量化建议。