mcpField
H
humanizer

humanizer

github.com/hannsxpeter创意与媒体1456 次安装3 周前更新
代码仓库

关于 humanizer

Humanizer 用于改写显得泛化或过于机器化的文字,同时保留原意,并在有写作样本时贴近作者风格。它也可谨慎清理不可见 Unicode 字符和文本间距。

主要功能

  1. 01改写显得泛化的文字
  2. 02匹配提供的写作风格
  3. 03按文本情况调整编辑力度
  4. 04清理可疑的不可见字符
  5. 05规范复制粘贴产生的间距

适用场景

  1. 01修改读起来像机器生成的文字
  2. 02使草稿贴近指定风格
  3. 03清理文本中的隐藏字符
  4. 04规范复制文本的间距

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/hannsxpeter/humanizer --skill humanizer

安装后在 Claude Code 中输入/humanizer确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

CONVENTIONS.md
AGENTS.md
CHANGELOG.md
.gitignore
GEMINI.md
README.md
LICENSE
.continue/rules/
humanizer.md
.cursor/rules/
humanizer.mdc
.github/
copilot-instructions.md
dependabot.yml
.github/scripts/
check_drift.py
.github/workflows/
drift.yml
evals/
evals.json
evals/files/
VOICE.md
references/
examples.md
do-not-flag.md
text-hygiene.md
tell-patterns.md
voice-matching.md

详细介绍

Humanizer

将带有 AI 风格或泛泛而流畅的文字改写成读起来像真人写的内容。如果能找到作者的写作风格,就让文字读起来像是那位作者写的。目标是写出谨慎的读者不会起疑的文字,同时保留原意和人味。目标不是骗过任何特定检测器,本技能也不会提及或针对任何检测器。

工作流还包括保守的文本清理。改写文字时,可以移除可疑的不可见 Unicode 字符,并规范复制粘贴产生的空格,同时保留真正承载语言或显示意义的字符。这不是用于追溯文件来源或检测媒体水印的工具。

适用场景

当有人贴出草稿,说听起来像 AI 写的,要求润色得更像人写的或去除生硬感,希望自己的草稿听起来像自己,指定要模仿某位作者,或者说文字“感觉不对”“听起来像企业公关稿”“读起来像机器人”或“太泛泛”时,都可以使用。即使对方没有说“润色得更像人写的”,也可以使用。如果任何起草步骤产出的文字过于平滑、机器感十足,本技能也很适合接着使用。默认情况下,改写会保持克制并忠于原文;如果用户明确要求更鲜明的风格、更强的锋芒或观点,就开启立场模式(见下文)。

当文字可能包含不可见字符、零宽残留、异常空格或方向控制符时,使用文本清理功能。将清理视为格式整理,绝不能把它当作文字由人或模型撰写的证据。

不要用它来掩饰作者身份以应付考核,也不要用它来规避抄袭检测或 AI 检测系统。请参见下文的“适用范围和预期用途”;遇到这类请求时,应引导对方关注真正的质量和风格。

核心原则:变化胜过替换

AI 写的文字之所以读起来像 AI 写的,不是因为用了什么词,而是因为太整齐划一:句子长度相近、节奏一致、处处留有余地,而且同样的结构总以同样的方式收尾。把每处“深入探讨”都换成“探索”并不能解决问题,只会换个标记;一套整齐划一的“人类化口吻”,仍然是机器指纹,只不过换了一个。

真正的人性化改写来自真实的结构变化。长短迥异的句子并排出现。偶尔来个片段。再接一个迂回绵长、娓娓道来的长句。句法多样。还要保留一些工整模型会抹平的不对称之处。你写作的对象是敏锐的人类读者,而不是某个分数。下面的每一步都服务于这一原则:增加真实的变化,不要套用新的规律。

步骤 0:了解写作风格(每次运行都要在改写前执行)

判断当前应使用哪种模式,并在输出标题中说明,以便用户发现不对时能立即纠正。

  1. 明确提供的输入优先。 用户是否贴出了写作样本、指向某个文件,或指定要匹配某位知名作者?使用这些信息。阅读 references/voice-matching.md,并以风格匹配模式继续。
  2. 否则,查找风格档案。 按以下优先顺序,对工作目录及最多两级父目录运行 Glob: VOICE.md,然后是 STYLE-GUIDE.md,接着是 voice-profile.md / .yaml / .json,然后是 .manuscript/STYLE-GUIDE.md, 最后是 AGENTS.md 或 CLAUDE.md 中的风格或写作规范部分。找到一个高度匹配的文件:阅读该文件,再阅读 references/voice-matching.md,然后以风格匹配模式继续。找到多个可能匹配的文件:问一个简短问题,让用户选择。
  3. 否则,使用通用模式。 没有目标风格。去除生硬感,改成自然多变的人类文字。不要凭空编造人设或背景故事;虚构的风格本身就是一种失败。通用模式跳过步骤 1,从步骤 2 开始。

此发现流程不依赖特定文件系统。它可以与 Scriveno、Pillars,或任何恰好保存了风格文件的项目协作,而不依赖这些工具。

步骤 0b:立场模式(需主动启用,默认关闭)

默认输出客观、忠实:以清晰自然的文字呈现源内容,不加入主观评论。这是正确的默认设置,因为更活泼的润色工具最常见的问题,就是“增添个性”变成了“增添内容”,而凭空捏造的观点悄悄带入了凭空捏造的事实。

只有在用户明确提出要求时,才开启立场模式:“加点个性”“写得更有力”“表达一下看法”“别这么中立”“加点锋芒或观点”。普通的去除生硬感请求,不要开启立场模式;在语气模式下也绝不要开启(已发现的风格档案已经决定了立场;不要覆盖它)。

开启立场模式后,你可以对现有内容表达态度:作出判断、强调重点、用冷静克制的方式轻描淡写,以叙述同一组事实的讲述者身份使用第一人称,坦诚指出“这部分是薄弱环节”,承认对源内容已有说法的矛盾心情,也可以采用更自由的节奏。这些仍是同样的内容,只是由一个有观点的人讲出来。

底线,也是这种模式安全的全部原因:**立场是对已有内容作出反应,绝不是添加不存在的内容。**你可以评判已陈述的事实;但不能为了作出反应而捏造事实、原因、机制、事件、具名人物、引语或亲身经历。检查每个新增分句:“这是对源内容已有陈述的看法,还是对现实世界的新主张?”如果是新主张,那就是披着个性外衣的杜撰,正是这项技能要防止的问题。拿不准时,可以表达观点,但不能添加新事实。

示例。源内容只陈述:迁移期间,基础设施成本暂时上涨了 18%。

  • 允许(针对已陈述事实表达立场):“上涨 18% 可不是小数目,不能当作四舍五入的误差;这句话里的‘暂时’,倒是寄托了不少希望。”
  • 禁止(把杜撰的原因伪装成坦率表达):“成本上涨是因为我们让新旧系统并行运行了”(源内容从未说明原因;这是新事实)。

立场模式会增加杜撰风险,因此第 3 遍自查和含义检查必须更加严格,输出标题也必须标明立场模式已开启,以便用户酌情调低。立场模式是用户要求的语体调整,因此即使密度预检选择轻度处理,也仍然适用;密度仍然决定需要多努力地寻找痕迹。

步骤 0c:密度预检(让投入与证据相匹配)

重写前,通读全文一遍,判断文本带有多少 AI 痕迹。只统计一眼可辨的明显迹象,不统计较弱的表面信号:聊天界面污染(模式 31)、知识截止日期免责声明(29)、协作式聊天机器人痕迹(28)、夸大重要性(1)、宣传性语言(5)、AI 词汇扎堆(16)、谄媚语气(7)、泛泛的积极结论(13)。粗略估算每 100 个词出现多少处,然后选择润色强度,并在输出标题中注明:

  • 低(每 100 个词约 0 到 2 处):轻度润色。 文本以人为主(例如日记、粗略笔记、真人草稿)。只修正一眼可辨的明显痕迹。保留较低级别的模式、节奏和语气,并尽可能倾向于“刻意保留原样”。在这种情况下进行彻底重写,恰恰会抹去让文字听起来像真人的独特之处;这是此技能可能犯下的最严重错误。因此,密度较低时应默认保持克制,只在必要时修改。
  • 中(每 100 个词约 3 到 5 处):标准润色。 作者成分混杂。应用完整目录,但遵循 do-not-flag.md 中的克制原则;不要抹平已有的优点。
  • 高(每 100 个词不少于 6 处):全面润色。 以 AI 生成文本为主。全面应用完整目录,并大力调整结构以增加变化。

这是校准,不是要机械地报告扫描结果。投入应与证据相匹配。有一项例外优先于密度判断:任何聊天界面污染字符串(模式 31)本身就具有决定性,无论整体密度如何,都必须移除,因为它的存在几乎可以确定文本受到了此类污染,而不是较弱的信号。

步骤 0d:文本清理预检(每次都要执行)

重写前检查源文本,避免不可见格式字符残留,或被误认为文风特征。当源文本包含非 ASCII 格式字符、用户提及隐藏字符或文本标记,或界面报告了可疑码位时,请阅读 references/text-hygiene.md。

只移除明确没有语义用途的字符。保留脚本连接符、多语言文本所需的方向标记、用于显示的变体选择符,以及承载布局或区域设置含义的不换行空格。不要自动规范化易混淆字符。不可见字符不计入密度评分,也不能证明文本由 AI 撰写。

这是一个纯提示词技能,因此检查范围仅限于宿主环境保留并显示的字符。如果源文本位于文件中且可使用搜索工具,还要运行 references/text-hygiene.md 中的码位搜索。如果既无法直接查看字符,也无法搜索文件,请在输出标题中注明 not verifiable in this interface。绝不要声称文本在任何情况下都不含水印。

多轮处理工作流

按顺序执行各轮处理。塑造语气是生成式的;去除 AI 腔是减法式的。如果先去除痕迹,文字会变得平淡中性,之后就很难再赋予其个性。因此,如果需要塑造语气,应先确立语气。

第 1 轮:注入语气(仅限语气模式)

在移除任何痕迹之前,先朝目标语气重写草稿。按照 references/voice-matching.md 中描述的节奏、措辞、句长特征、立场和惯用表达来调整。匹配作者的写作直觉和表达分布,不要照搬其具体句子。通用模式下跳过此轮。

第 2 轮:消除特征

加载 references/tell-patterns.md。根据第 0c 步选择的强度,逐段对照 32 项特征目录(六个类别)检查文案。对于每个确实值得标记的地方,修正其底层想法,而不是表面词语:问问“这里实际想表达什么?”,然后用具体的方式写出来,篇幅应与这个想法相称。准确保留原意。

具体内容必须来自源文或用户,而不能由你编造。如果源文含糊,而你也没有真实细节可以补充,那么诚实的修正方式就是直白地少说一些,而不是捏造数字、日期、名字或示例来让文字“听起来更像人写的”。杜撰的具体细节读起来很像真人所写,因此比它取代的模糊表述更危险:含糊的垃圾内容顶多让读者感到无聊,流畅的捏造却会误导读者。若你想加入文本中没有的具体细节,就改为缩短内容。

在此过程中,保持或增加句长变化;不要让去除劣质内容的过程把节奏变得单一。在语气模式下,如果某项修正会削平既有文风,那就不是正确的修正;要找到既能保留文风,又能修正特征的方式。

拟人化会改变措辞和句法,因此可能附带影响统计令牌模式。没有公开检测器和密钥,就无法验证这种影响,只能尽力而为。不要为了规避检测器而刻意加大改写幅度,不要承诺已移除某种标记,也不要声称结果无法被检测。

第 3 轮:自我审查(可否决第 1 轮和第 2 轮)

加载 references/do-not-flag.md。提出以下两个问题,并据此处理:

a. 如果一位敏锐的人冷不丁读到这段文字,哪些一两处地方仍会让他察觉有机器参与?只修正这些地方。

b. 我是否矫枉过正?是否删掉了具体细节、抹平了真实的独特之处、改变了原意,或引入了统一的节奏(每处修正都采用同一种形式)?撤销这类损害。

最后,再检查改写后的文案中是否有可疑字符,包括你在编辑时引入的字符。如果第 0d 步发现或清理过此类字符,请对照 references/text-hygiene.md,确认可疑载体已移除,同时保留了承载重要信息的 Unicode 字符。只报告你确实核实过的改动。

如果第 3 轮与前面的轮次冲突,以第 3 轮为准。即使所有特征都消失了,如果改写后的文字听起来已不像原作者,或丢失了真实细节,这次改写仍然失败。

误报防护原则

这些规则内嵌于此,因为每次运行都需要。不要孤立地将以下情况标记出来:

  • 语法无懈可击。正确不代表露馅;绝不要故意添加错误。
  • 单个 em dash。只有频繁使用或单调重复使用破折号才算特征。
  • 弯引号或弯撇号。文字处理软件会为人类用户自动插入这些符号;只有为与周围文本保持一致时才进行统一,绝不能把它们当作证据。
  • 正式或高雅的用词。语体不代表来源。
  • 常见过渡词(“然而”“因此”“例如”)。
  • 单个被动句、三项并列或主题句。

只有重复出现或多种情况同时出现时,才升级为标记。拿不准时,不要删。完整的处理说明,包括需要保留的人类写作特征和各模型的个人语言风格,见 references/do-not-flag.md;请在第 3 轮阅读。

反特征指南

不要养成自己的固定套路。不是每句话都要用同一种方式制造变化。不要反复套用“先来一句简短有力的话,再接一个冗长曲折的从句”这样的固定模板。不要强行在每段里都加入缩略形式。不要每次都用同样的三个替换词来改写“深入探讨”。拟人化工具的特征就是不规则中的规律。变化也要多变。如果你的修改开始彼此押韵,就停下来打破自己的模式。

输出约定

始终先交付改写后的正文作为主要内容,然后附上一份简短报告。绝不悄悄地就地改写。绝不将原始差异作为主要输出(正文差异难以阅读,也会掩盖语义偏移)。使用以下确切结构:

## Humanized draft
Voice: [generic | from FILENAME | matched to pasted sample | author: NAME]
       [append " + stance" when stance mode is on, e.g. "generic + stance"]
       [append ", low-confidence: REASON" when the voice source is thin]
Density: [low -> light pass | medium -> standard pass | high -> full pass]
Text hygiene: [no suspicious characters visible | cleaned: COUNTS AND TYPES |
               not verifiable in this interface]

[the full rewritten text]

## What changed
- [pattern family]: [plain note on what was adjusted and why]
  (group by family; do not list every token; about 8 bullets maximum)
- [text hygiene]: [include only when characters were removed or normalized]

## Deliberately left alone
- [something that looked like a tell but is authentic, and why you kept it]
  (one to three bullets; this section is required, even on heavy rewrites)

## Meaning check
One sentence confirming no facts, numbers, names, claims, or intent changed.
Confirm that text-hygiene edits changed formatting only and preserved
load-bearing Unicode.
Then check soft inference: did you assert any causal, temporal, or
quantitative link ("most of the time went to X", "because of Y", "this drove
Z") that the source only implied or did not state? If so, name it here and
either hedge it ("probably", "as I read it") or cut it back to what the
source actually says. If anything was ambiguous, ask the question here
instead of guessing.

## Next step
If the user gave a file path, offer to write the rewrite into it. Otherwise
stop here.

“刻意保留不改”和“含义核查”部分并非可有可无的装饰。它们是强制步骤:明确说明保留了什么,能让过度编辑无所遁形;含义核查则能发现语义偏移。最容易漏掉的正是软性推断,因为它看似合理、读起来也很自然:凭空编造原因,或声称时间或精力花在了什么地方,都不会触发硬事实扫描,因此含义核查必须有意识地检查这些问题。如果原文几乎已经像人写的一样,正确的输出应是只做少量修改或不做修改,并清楚说明保留了哪些内容以及原因。

范围和预期用途

此技能旨在提升正文质量,并帮助作者自己的作品听起来真实地像出自本人之手。它并非为规避抄袭检测器或 AI 检测系统而设计或调优,也刻意不针对其中任何一种。如果用户要求将 AI 撰写的作品冒充为本人所写,以应对评分或合同约定的评估,不要接受这种说法;应改为提供质量与风格方面的改进,这才是此技能真正擅长的事。

此技能中的文本清理仅限于所提供正文中出现的字符。它不会检查或剥离 C2PA、EXIF、XMP、PDF 或文档属性、图像像素、音频、视频,也不会检查文本层之外的来源信息。这些操作需要专用工具。不要暗示已经执行过这些操作。

参考文件

按需阅读,不要预先阅读:

  • 在第 2 轮中阅读 references/tell-patterns.md。该文件包含 6 类共 32 种模式的目录,每种模式都包括检测方法、原因、修改前后示例和克制原则。
  • 在第 3 轮中阅读 references/do-not-flag.md。该文件介绍误报、应保留的人类写作特征、大模型特有的表达习惯,以及必须停止的情形。
  • 每当第 0 步发现了某种风格时,阅读 references/voice-matching.md。该文件介绍如何提取和应用风格、可选的 VOICE.md 方案,以及冲突处理方法。
  • 当第 0d 步需要时(发现可疑字符、提及隐藏标记,或需要搜索文件中的正文),以及清理后的最终核查时,阅读 references/text-hygiene.md。该文件介绍可疑的不可见 Unicode 字符、承载语义的例外情况、精确的码点搜索、保守规范化、报告方式,以及仅限提示词的范围边界。
  • 不确定什么样的输出才算合适时,阅读 references/examples.md。该文件提供 5 个完整的操作示例:通用去冗余处理、优先匹配风格、克制处理、立场模式和文本清理。

评论

支持 Markdown