humanizer-zh

---
name: humanizer-zh
description: Remove signs of AI-generated, translated, or overly mechanical Chinese prose. Use when rewriting, editing, or reviewing Chinese blog posts, essays, newsletters, nonfiction chapters, product analysis, or long-form commentary so they read like native Chinese writing. Trigger this skill when the user asks to 「去 AI 味」, 「润色成中文母语表达」, 「改得像博客或书里写的」, 「减少翻译腔」, or similar. Detect and fix translation-like phrasing, empty big words, formulaic contrast frames, sloganized endings, list inflation, punctuation misuse, terminology/casing inconsistencies, and paragraph rhythm that feels assembled rather than written.
---

# 中文去 AI 味

## Overview

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

## Workflow

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

## Voice Adoption（可选）

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

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

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

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

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

进入加载流程后：

1. 读取 [references/voices/<author>.md](references/voices/) 对应文件。
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](references/patterns.md)：

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

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

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

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

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

## Output

默认按下面顺序给结果：

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

## Final Check

交付前逐项确认：

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