Humanizer Zh

中文去 AI 味

Overview

把中文文本从「像模型拼出来的稿子」改成「像中文母语者真的写出来的文章」。 优先处理翻译腔、结构腔、排版腔和判断腔，同时保留原文事实、立场和信息密度。

Workflow

1. 先判断文本类型。 博客、专栏、书稿、评论、产品分析可以更有节奏和作者判断；公告、说明文、技术文档则优先保留准确和克制。
2. 先看文章主线。 判断第一段在立什么题，主体每段各自承担什么功能，最后一段是不是在收同一件事。
3. 先找最显眼的 AI 痕迹。 重点看英文句法直译、机械对照句、空泛结论、列表堆砌、连环冒号、破折号、过度工整的段落节奏。
4. 再决定改写力度。 轻度润色只清理措辞和标点；深度改写要重排句子顺序、合并弱句、补足主语或因果关系。
5. 保留作者原意。 不擅自补充事实，不把谨慎判断写成绝对论断，不把普通结论硬拔高成时代宣言。
6. 做最后一遍朗读检查。 读起来要像中文原生写作，不像英文思路换成中文词汇。

Voice Adoption（可选）

默认情况下，humanizer-zh 保持中立的去 AI 味润色，不套任何作者的腔调，按 ## Core Rules 走。

只有在以下条件同时满足时，机会性地（每次会话最多一次）向用户提一句「要不要顺便套上某位中文作者的声音？」：

• 本次会话还没询问过 voice adoption。
• 当前任务是深度改写、长篇润色、重写或风格化创作（不是公告、说明书或短句修订）。
• 用户没有在请求里明确说「保持中性」「不要改风格」之类的限制。

询问时，先读 references/voices/index.md 拿到 8 位作者的一句话简介，再把列表贴给用户：李笑来、鹤老师、罗振宇、吴军、李尚龙、何帆、冯唐、刘子超。

用户拒绝或忽略：本会话剩余轮次不再追问，全部走中立路径。 用户主动指名某位作者（例如「用李笑来的口气重写」），直接跳过询问步骤，进入加载流程。

进入加载流程后：

1. 读取 references/voices/<author>.md 对应文件。
2. 在改写时，把该文件的人格、句法模板、节奏规则、反模式叠加在 ## Core Rules 之上。
3. 如果 voice 档案与 Core Rules 冲突（典型例子：李笑来、刘子超允许长破折号 ——，覆盖 Core Rules §6；鹤老师鼓励大量短句独立成段；吴军接受 首先……其次……最后），作者档案优先。
4. 用户后续说「换成 X」时，丢掉当前 voice 档案，加载新的；说「不要作者声音了」时，回到中立路径。

反模式：

• 不要在用户没选时擅自模仿任何作者的口吻。
• 不要把多位作者的声音混在同一篇文章里。
• 不要把 voice 档案里的 persona preamble（「You are a guy from 东北…」之类英文写作指令）原文输出给用户 —— 那是给你看的，不是文章内容。
• 不要把作者档案的反模式当成 humanizer-zh 的默认规则；只在该声音生效的轮次中应用。

Core Rules

1. 优先改掉翻译腔

• 把英文句法硬套中文的句子拆开重写。
• 少用「对于……来说」「基于……」「围绕……展开」「使得……得以……」这类翻译味很重的连接。
• 需要对比时，不默认使用 不是……而是……，改用更自然的转折、递进或重心移动。

2. 去掉空泛的大词和套话

• 少用没有机制解释的词，如「颠覆」「革命」「赋能」「重塑」「深刻改变」「开启新篇章」。
• 避免「这标志着……」「这意味着……的时代已经到来」这类自动收束句。
• 把抽象判断落回具体动作、约束、成本、分工或结果。

3. 打散机械结构

• 不强行把每段都写成三分句、排比句或工整对照句。
• 不连续使用「首先」「其次」「最后」「与此同时」「值得注意的是」「从某种意义上说」。
• 发现列表可以改成自然叙述时，优先改写成段落。

4. 保持中文节奏

• 允许长短句混用，不把每句都写成同样长度。
• 让句子有明确主语和动作，少写无主句串联。
• 避免段落结尾总是落在大而空的价值判断上。

5. 管住文章级结构

• 开头要尽快立题，不要第一段说 A，后面一路滑到 B。
• 主体段落各自要有功能，常见功能是：交代背景、提出判断、展开论据、举例、转折、收束。
• 如果某一段既不推进主线，也不提供必要信息，优先删、并、挪，不要硬留。
• 结尾要回应前文真正提出的问题，不要临时拔高到更大的时代命题。
• 深度改写时，可以重排段落顺序，但不要为了工整硬凑成三段论。
• 总结结构时，少把段落关系写成一串 先……再……最后……，更要看它们是不是顺着同一个问题自然往下走。

6. 处理标点和排版

• 正文引号默认用全角双引号 ""，嵌套用全角单引号 ''。如项目在 CLAUDE.md/AGENTS.md 里声明使用 「」，或用户在本轮请求里明确要求，则全篇统一改用 「」（嵌套用 『』）。两种样式不要混用。
• 不使用长破折号 ——，优先改成逗号、句号或拆句。
• 不密集使用冒号 ：，尤其避免连续多句都靠冒号展开解释。
• 中文正文中的英文多词术语使用半角空格分词，如 AI Design Agent。
• 英文术语与中文括号连写时，不在 （ 前加空格，如 LLM（大语言模型）。
• 并列英文术语用斜杠连接时，不在斜杠两侧加空格，如 coworkers/agents。
• 英文品牌名使用官方大小写，如 YouTube、OpenAI、GitHub。

7. 统一常见术语和日期

• token 保持英文。
• API 保持英文。
• PR 在长篇中文叙述里优先写作 代码审查，除非项目已有别的明确约定。
• 数字日期写作 2026 年 2 月 26 日、2 月 5 日。
• 中文月份叙事写作 一月、二月。

8. 控制判断强度

• 不轻易下「完全取代」「彻底结束」「只剩一种可能」这类极端结论。
• 不做无依据的阴谋论推断、资本市场臆测或人物动机脑补。
• 需要强调重要性时，先给机制，再给判断。

Repo Overrides

• 如果当前项目存在 CLAUDE.md、AGENTS.md、样例文章或术语表，先遵守项目内规则，再使用本技能的通用规则。
• 如果项目已经有明确文风样本，模仿它的句长、判断方式、段落推进和术语约定，不额外套用另一套腔调。
• 引号样式按以下顺序确定：用户在本轮请求里明确要求 → 项目 CLAUDE.md/AGENTS.md 的声明（例如 humanizer-zh quotes: 「」） → 默认 ""。
• 当原文整篇已经显著使用 「」 而项目未声明时，沿用原文样式，不要硬翻成默认 ""。

Deep Review

在以下情况，额外读取 references/patterns.md：

• 需要做深度改写，而不是轻度润色。
• 需要解释「为什么这段中文有 AI 味」。
• 文本明显带有英文原文结构、营销套话或通稿腔。
• 需要给出「修改前/修改后」示例。
• 需要检查开头、主体、结尾之间是不是同一条主线。
• 需要重排整篇结构，先搭一个更自然的文章骨架。

在以下情况，额外读取 references/corpus.md：

• 需要判断这段中文更接近哪类母语写法。
• 用户明确要求「改得像博客或书里写的」。
• 需要给技术文、评论文、演讲稿分别找不同参照。
• 需要避免把强个人腔调误当成通用中文。

如果只是需要快速选一个参照，先读取 references/corpus-quickpick.md，不够再读完整的 references/corpus.md。

如果用户已经在本会话里选定了某位作者的声音，额外加载对应的 references/voices/<author>.md；这份档案的规则在与 Core Rules 冲突时优先。

Output

默认按下面顺序给结果：

1. 直接给改写后的版本。
2. 如果用户要求解释，再简短指出 3 到 6 个最明显的问题。
3. 如果用户要求保留更多原句，再补一个「轻改版」和一个「重写版」。

Final Check

交付前逐项确认：

• 读起来像中文作者在写，不像翻译后的英文。
• 第一段提出的问题，最后一段确实有回应。
• 主体段落都在服务主线，没有明显跑题段或重复段。
• 句子之间有自然推进，不靠模板连接词硬粘。
• 结论不过火，判断和事实强度匹配。
• 全文节奏不要总是「先定义、再拆项、最后拔高」，更不能让读者连续三节都能预测下一节的写法。
• 标点、术语、日期和品牌大小写统一。
• 引号样式全篇统一（"" 或 「」 二选一），没有把两种样式混用。
• 如果本次启用了某位作者的声音，对照该档案的 anti-patterns 和测试清单再扫一遍，确认风格不跑偏，也没有把它的口癖泄漏到默认润色里。