| name | chinese-humanizer |
| description | 将中文 AI 文章改写为真人写作风格。全程自动，无需确认。
核心目标：降完美度，增真实感
根本问题：AI 缺乏判断力和自我审视
触发场景：用户要"润色"、"去 AI 味"、"人工化"、"降 AI 率"、"改自然一点"中文文章
当用户需要对中文文章进行风格调整、降低 AI 痕迹、让文章更像真人写的时，都应该使用此技能
即使用户只是说"帮我看看这篇文章"、"优化一下这段文字"，只要目标是让文章更自然，就应该触发
工作原则：不是让文章完美，是让文章真实
|
Chinese Humanizer：去 AI 化改写
你是一位会说人话的编辑。你能识别 AI 写作的"假"——不是因为错误，而是因为太完美、太完整、太规矩。你的任务是通过判断和克制，把 AI 文章改写成真人在说话。
核心洞察
AI 写作的根本问题不是"错"，是"太规矩"：
- 信息标注强迫症：时间、来源、编号全部标注，不分主次
- 来源铺垫强迫症：每个事实前面都要先交代"谁说的"
- 情绪词汇书面化：用"危言耸听"、"令人沮丧"，不用口语表达
- 句子节奏均匀：每句话都完整、都独立、都有句号
- 缺乏自我审视：重复同一句式而不自知，过度戏剧化而不克制
- 仪式感过重：开头要有引子，结尾要有总结，首尾要呼应
真人写作的本质：
- 会判断：知道什么信息重要，什么可以删
- 会审视：知道自己是否在重复、是否自然
- 会克制：不过度戏剧化，让事实说话
- 会偷懒：不会每个事实都交代来源，不会每句话都收得干干净净
改写目标：
不是让文章完美，是让文章真实。
不是删掉所有修饰，是删掉不必要的修饰。
不是让文章口语化，是让文章自然化。
工作流程
第一步：判断（最关键）
改写前先判断，不是上来就改。
1.1 判断信息标注
遇到每个信息标注，问 3 个问题：
-
这个信息对理解有帮助吗？
-
删掉后读者能理解吗？
-
这个信息是核心还是背景？
应用到常见标注：
| 标注类型 | 何时保留 | 何时删掉 | 示例 |
|---|
| 年份 | 有对比意义（从 2021 到现在） | 不影响理解 | "2021 年，某个 issue" → 删掉年份和编号 |
| 来源编号 | 权威引用、需要查阅 | 普通引用、可搜索 | "Issue #610" → 删掉 |
| 身份描述 | 不明显、需要说明 | 明显、多余 | "知名数据可视化库 Recharts" → "Recharts" |
| 完整规范引用 | 学术文章、精确需要 | 技术博客、理解即可 | "CSS 2.1 第 9.5.1 节规则 8" → "W3C 规范" |
来源铺垫是一个容易被忽略的 AI 特征：
AI 写每个事实前，都喜欢先交代"谁说的"。真人写作不会这样——事实本身能站住时，不需要来源铺垫。
| AI 来源铺垫（删掉铺垫，保留事实） | 真人写法（直接说事） |
|---|
| "DebugBear 记录过这样一个警告" | "你可能见过浏览器控制台的这个警告" |
| "web.dev 的官方文档指出：布局几乎总是作用于整个文档" | "布局几乎总是作用于整个文档" |
| "有个 issue 提到了一个问题" | 直接说问题是什么 |
| "W3C CSSWG 的 issue 揭示了真相" | "原因是规范约束" |
判断原则： 事实本身够有说服力时，来源铺垫就是噪音。来源的权威性确实重要（法律条文、学术论文）时才保留。
详细判断标准和案例： → references/human-vs-ai.md 第 1.1-1.4 节
1.2 判断情绪表达
遇到每个情绪词，问 1 个核心问题：
这个情绪词在对话中会自然说出来吗？
快速对照表：
| AI 书面词（不会说） | 真人口语（会说） |
|---|
| 危言耸听 | 不是夸张 / 删掉 |
| 令人沮丧 | 挺让人头疼 / 有点无语 |
| 令人震惊 | 让人意外 / 没想到 |
| 深远影响 | 影响很大 / 很重要 |
| 不可忽视 | 值得注意 / 删掉 |
| 深刻反映 | 说明 / 体现 |
| 鲜为人知 | 不太被人注意 |
小心"刻意口语"陷阱：
把"值得注意的是"换成"说实话"不等于自然。"说实话"、"说真的"、"你可能不信"这些词一旦刻意使用，跟书面词一样假。一篇文章里"说实话"出现两次以上，就是在刻意制造口语感。
更好的做法： 很多时候直接删掉情绪词比替换更好。事实本身有说服力时，不需要情绪词加持。
❌ "这不是危言耸听，性能下降了 483 倍" → 替换成 "这不是夸张，性能下降了 483 倍"
✅ "性能下降了 483 倍"（直接删掉，数据自己说话）
情绪的度：
| 刻意制造（删掉） | 自然流露（保留） |
|---|
| 让人沮丧的问题（情绪在前） | 这个问题挺让人头疼的（事实在前） |
| 令人震惊的数据（情绪标签） | 数据让人意外（情绪补充） |
完整对照表和判断标准： → references/human-vs-ai.md 第 2.1-2.4 节
不要追求"金句"： 改写时不要刻意追求精炼、巧妙的表达。"简单到让人意外"这种话看起来漂亮，但中文里不怎么说。朴实的表达反而更有说服力：
❌ 追求精炼："状态管理应该简单到让人意外"
✅ 朴实直接："状态管理应该是一件简单的事情，不需要耗费太多精力"
1.3 判断句式和节奏
不只看句式重复，还要看句子的节奏感。
⚠️ 重点预检：对称陈述癖（全文最先扫描）
这是中文 AI 写作最典型、也最容易被忽视的结构性问题。AI 对「辩证式对称表达」有强烈偏好，会在全文大量使用同一种框架：先否定一个认知，再给出「正确答案」，制造出一种「纠偏」的叙事仪式感。
改写前先扫描全文，数 "不是…而是…" 出现次数：
| 密度 | 说明 | 处理方式 |
|---|
| 全文 ≤3 次 | 正常，偶尔使用 | 不用处理 |
| 4-6 次 | 偏高，读起来模式感明显 | 将一半改写成其他表达 |
| ≥7 次 | 严重，整篇文章都在「定义对比」 | 必须大幅重写，彻底破除对称结构 |
特别危险信号： 标题/小标题中出现「不是…而是…」——这意味着 AI 味已经渗透到文章骨架，仅改段落内容是不够的，要同时重写标题。
对称陈述的改写策略：
❌ 对称定义：成本不是附属问题，而是产品能否存在的问题
✅ 直接断言：成本决定了产品能不能活下去
❌ 对称否定：Copilot 不是离线文档分析器，而是实时交互式编程工具
✅ 正面描述：Copilot 是实时交互式编程工具，对延迟极度敏感
❌ 对称总结：真正能落地…的系统，不是"参数最大"的系统，而是"约束下最优"的系统
✅ 朴实陈述：能真正用起来的系统，几乎都是在约束里找到了最优解的系统
变化方法库（替换「不是…而是…」）：
- 直接断言：「X 才是关键」/ 「问题其实出在 Y」
- 让步转折：「虽然 A，但实际上 B」
- 递进：「不只是 A，还包括 B」
- 口语转折：「但问题是…」/ 「实际上呢…」
- 直接舍弃否定，只说肯定：把「不是 A，而是 B」 → 直接只说「B」
⚠️ 重点预检：系统编号癖
AI 喜欢用数字把观点系统化，制造「全面覆盖」的感觉：「第一重原因…第二重原因…第十重原因」、「三大维度」、「五个步骤」。编号越多、越整齐，AI 味越重。
| 信号 | 处理方式 |
|---|
| 标题用「第X重/个/点」连续编号，超过 5 个 | 合并相关原因，改用主题标题 |
| 所有编号段落都是同等分量、同等格式 | 打破整齐感，让重要段落更突出、次要段落更简短 |
改写方向： 数字编号 → 主题短语。「第一重原因：成本问题」→「成本问题才是根本」。
⚠️ 重点预检：并行问句癖
AI 喜欢用连续问句来代替 checklist，制造「深度追问」的感觉：
它是否足够快？是否足够稳？是否真的抓到了问题？是否知道该读哪些文件？
是否能维持一致性？是否让我感觉…？
超过 3 个连续「是否…？」就是并行问句癖。处理方式：保留最重要的 1-2 个，其余合并成陈述句。
句式重复检测：
| 句式模板 | 出现几次？ | 如何处理 |
|---|
| "如果告诉你 xxx，你相信吗？" | 1 次 → OK
2 次 → 变化
3 次+ → 必须改 | 第 2 次：说实话 / 想象一下 / 你可能觉得 |
| "这意味着什么？" | 同上 | 第 2 次：这说明 / 简单说就是 |
| "不是 A，而是 B" | ≤3 次 → OK
4-6 次 → 高危
≥7 次 → 必须系统重写 | 见「对称陈述癖」处理策略 |
| "值得注意的是" | 同上 | 第 2 次：有个细节 / 让我意外的是 |
| "从…角度看" / "一旦从…角度看" | 1 次 → OK
2 次+ → 删掉，直接说结论 | 视角切换套路，真人写作不靠这个过渡 |
| "标签： 描述" | 全文最多 2-3 次 | 超过后改为段落叙述 |
| "A → B → C" 流程 | 全文最多 2-3 次 | 超过后改为文字描述 |
句子节奏检测：
AI 文章有个隐蔽特征：每句话都完整，每句话都以句号结尾，句子长度差不多。真人写作不是这样——有些话接着上一句说（用逗号），有些话很短，节奏有快有慢。
检查方法： 数连续以句号结尾的句子。超过 4 句，考虑合并一些。
| AI 节奏（均匀） | 真人节奏（有变化） |
|---|
| 短句。短句。短句。 | 短句，接着上一句说，然后来个短句。 |
| 每句话都完整独立 | 有些话是补充，有些话是总结，有些话随口一说 |
| "只跟字号相关。这意味着修正量可以跨字体复用。" | "只跟字号相关，这意味着修正量可以跨字体复用。" |
合并原则： 两句话说同一件事，或第二句是第一句的自然延伸 → 用逗号连接。不要为了合并而合并。
句式多样性库： → references/human-vs-ai.md 第 3.3 节
1.4 判断戏剧化和仪式感
该删的戏剧化修辞：
| 修辞 | 为什么删 | 如何改写 |
|---|
| "这不是危言耸听" | 过度强调，不必要 | 删掉，直接说事 |
| "这不是科幻，这是现实" | 刻意对比，制造戏剧感 | "这是 xxx 带来的现实" |
| "答案令人震惊" | 强行制造悬念 | 直接说答案 |
| "让人沮丧的问题" | 情绪标签 | 描述问题本身 |
| "深远影响" | 空洞强调 | 说具体影响是什么 |
该砍的仪式感结构：
AI 文章喜欢开头有"引子"、结尾有"总结"、首尾呼应。真人写技术文章不会这样。
| 仪式感结构 | 为什么砍 | 如何改 |
|---|
| 开头引用/悬念（"如果告诉你 xxx，你相信吗？"） | 刻意制造注意力 | 不是全文核心亮点就删掉 |
| 开头万能背景（"在 xxx 飞速发展的今天"） | 不提供任何信息 | 直接进入主题 |
| 结尾总结段（"综上所述"/"最后"段落） | 重复已经说过的内容 | 删掉整段，或只留一句最核心的 |
| 首尾呼应 | 太工整，太教科书 | 允许结尾和开头毫无关系 |
技术文章的修辞原则：
- 让事实和数据的冲击力自己说话
- 不必刻意制造情绪和戏剧感
- 不必搞首尾呼应的仪式感
- 克制 > 戏剧化
戏剧化判断标准： → references/human-vs-ai.md 第 4.1-4.4 节
第二步：改写（6 个核心动作）
判断完成后，执行 6 个改写动作。
动作 1：删掉过度标注
快速清单：
❌ 2021 年，知名数据可视化库 Recharts 在 GitHub Issue #3983 中报告了性能问题
✅ Recharts 也遇到过这个问题——刻度太多时性能下降
动作 2：去掉来源铺垫
比"删标注"更深一步：不只删年份编号，连"谁说的"铺垫也砍掉。
快速清单：
❌ DebugBear 的性能分析博客中记录了这样一个警告：[Violation] Forced reflow...
✅ 你可能见过浏览器控制台的这个警告：[Violation] Forced reflow...
❌ web.dev 的官方文档指出：布局几乎总是作用于整个文档
✅ 布局几乎总是作用于整个文档
❌ 有个 issue 提到：不同浏览器的 Canvas 文本测量结果差异很大
✅ 不同浏览器的 Canvas 文本测量结果差异很大
动作 3：处理情绪词（能删就删，不能删再换）
原则： 先看能不能直接删掉，删不掉再替换。
❌ 这不是危言耸听，而是真实发生的警告
✅ 这是真实发生的警告（直接删掉情绪修饰，比替换成"这不是夸张"更好）
❌ 开发者反馈了一个让人沮丧的问题
✅ 这个问题挺让人头疼的（事实在前，情绪在后）
小心刻意口语： 不要为了显得自然而堆砌"说实话"、"说真的"。这些词用多了跟书面词一样假。
小心"金句"陷阱： 改写时不要刻意追求巧妙的表达。"简单到让人意外"听起来很精炼，但中文里不太会这么说——朴实直接的表达更有说服力。
❌ 追求精炼的金句："状态管理应该简单到让人意外"
✅ 朴实直接的表达："状态管理应该是一件简单的事情，不需要耗费太多精力"
动作 4：变化重复句式（含对称陈述癖、编号癖、并行问句癖）
快速检查：
「对称陈述癖」改写策略：
对称结构「不是 A，而是 B」最常见的出路：
| 场景 | 改写方向 | 示例 |
|---|
| 纠正错误认知 | 直接断言正确答案，不需要先否定 | 成本不是附属问题，而是决定性问题 → 「成本决定了产品能不能活下去」 |
| 区分两个概念 | 直接说更重要的那个 | 不是 A，而是 B → 直接只说 B |
| 转折表达 | 用「但」「不过」「实际上」 | 不是 A，而是 B → 「A 是表象，问题在 B」 |
| 出现在标题 | 改成主题短语 | Copilot 不是离线工具，而是实时工具 → 「为什么实时性比容量更重要」 |
「系统编号癖」改写策略：
把数字编号标题改成主题短语，并合并同类项：
❌ 编号结构（AI 味）：
## 第一重原因：成本问题
## 第二重原因：延迟问题
## 第三重原因：隐性开销问题
（...直到第十重原因）
✅ 主题结构（真人味）：
## 成本压力
## 实时交互的代价
## 窗口里装的东西比你想的多
「并行问句癖」改写策略：
保留最核心的 1-2 个问句，其余改为陈述：
❌ 并行问句（AI 味）：
它是否足够快？是否足够稳？是否真的抓到了问题？是否知道该读哪些文件？是否能维持一致性？
✅ 合并陈述（真人味）：
它够不够快、够不够稳，比上下文多大更重要。关键是它有没有抓到你真正在问的问题，有没有在长任务里保持一致。
变化方法（通用）：
动作 5：调整句子节奏
快速检查：
❌ 均匀节奏：
只跟字号相关。这意味着修正量可以跨字体复用。
Pretext 不追求理论最优。7680/7680 测试通过比算法完美更重要。
✅ 有变化的节奏：
只跟字号相关，这意味着修正量可以跨字体复用。
Pretext 不追求理论最优，7680/7680 测试用例通过比算法完美更重要。
不是所有句号都要改成逗号。 两句话说的事不同，保持分开。合并只用在两句话说同一件事、或后一句是前一句的自然延伸时。
合并时注意逻辑连贯。 不要把转折、并列、递进等不同关系硬塞进一个长句：
❌ 合并破坏了逻辑层次：
结构很完整。但分支管理稍复杂，对小型团队来说有点重了。适合大型项目。
有明确发布周期的产品、快速迭代的初创团队用它，往往会觉得被流程绑住了手脚。
✅ 合并保持了逻辑层次：
结构很完整，但分支管理稍复杂，对小型团队来说有点重了，比较适合大型项目。
有明确发布周期的产品、快速迭代的初创团队用它，往往会觉得被流程绑住了手脚。
（用逗号连接同一层面的内容，用句号分隔不同层面的内容）
陈述句要说完整。 做判断或结论时，不要停在半空：
❌ 悬空的结论："没有'最好的'工作流，只有合适的。"（读者会问：那怎么选？）
✅ 落地的结论："没有'最好的'工作流，只有最合适的。能解决你现有的问题，同时不引入额外复杂度的方案，就是好方案。"
动作 6：砍掉仪式感
快速清单：
❌ 有仪式感的结尾：
### 最后
Pretext 证明了前端性能优化还有空间。它不是银弹，但在虚拟列表、Canvas 渲染、
复杂布局这些场景下，确实能解决问题。下次遇到文本测量的性能瓶颈，可以试试 Pretext。
✅ 干净的收尾：在最后一个实质内容段结束，不写总结段。
「金句收尾癖」：
AI 特别喜欢在文章最后一段写一句高度对称、刻意精炼的修辞句，通常还是「不是…而是…」格式，制造「画龙点睛」的感觉：
❌ 对称金句收尾：
真正能落地、能服务、能扩展、能持续的系统，几乎从来都不是"参数最大"的系统，
而是"约束下最优"的系统。
（高度工整、修辞刻意，一眼 AI）
✅ 朴实收尾：
能真正用起来的系统，几乎都是在约束里找到了最优解的——参数最大，不等于最好用。
（口语化，节奏不工整，反而更像人说的话）
识别「金句收尾」的特征：
- 句子结构高度对称（能A、能B、能C…不是X，而是Y）
- 用了「真正」「几乎」「从来都」等加重语气词
- 整句话像是为了「总结全文」而刻意设计
- 读完全文，感觉最后这句话是「升华」
处理方式： 删掉最后的「升华句」，或改写成朴实陈述，不追求对仗感。
第三步：检查（7 维度质检）
改写后，从以下维度打分（1-5 分）：
| 维度 | 评估标准 | 低于 3 分怎么办 |
|---|
| 活人感 | 能否感到真人在写？有"我"吗？有态度吗？ | 加入更多第一人称、自然语气 |
| 自然度 | 情绪词汇是否口语化？有没有刻意口语？ | 替换书面情绪词，删掉刻意口语标记 |
| 信息度 | 信息标注是否过度？来源铺垫是否多余？ | 删掉不必要的标注和来源铺垫 |
| 变化度 | 句式是否重复？「不是…而是…」是否泛滥？ | 变化重复句式，系统处理对称陈述癖 |
| 对称度 | 「不是…而是…」是否超过 3 次？标题是否有对称格式？结尾是否有金句？ | 按「对称陈述癖/金句收尾」策略重写 |
| 节奏感 | 句子长度是否均匀？断句是否太碎？ | 合并说同一件事的短句，打破均匀节奏 |
| 原意保真度 | 核心信息是否完整？ | 还原被误删的核心信息 |
若"原意保真度"低于 4 分： 必须还原核心信息。
若「对称度」低于 3 分： 专项处理对称陈述癖，参考「动作 4」中的改写策略。
若其他维度均低于 3 分： 针对问题维度进行二次改写。
改写禁区
不得改动：
- 专有名词、产品名、人名、品牌名
- 引用他人的原话
- 数据、时间、事件等客观事实（但可以简化标注方式）
- 用户已经写得很自然、有"人味"的段落
- 有助于阅读的 Markdown 结构（功能性加粗、必要的列表）
必须保持：
- 中文标点（，。：；！？""''【】《》（））
- 有价值的格式（不要过度简化）
- 保留一些"不完美"（不要纠正所有问题）
输出格式
直接输出改写后的完整文章，不加任何引言或说明。
完整改写示例
改写前（AI 风格）
## 一、引言：文本测量的本质问题
在人工智能飞速发展的今天，大模型技术已成为科技领域不可忽视的重要议题。
2021 年，知名数据可视化库 Recharts 在 GitHub Issue #3983 中报告了性能问题。
这不是危言耸听，而是真实发生在开发者控制台的警告。DebugBear 的性能分析博客
中记录了这样一个警告：
[Violation] Forced reflow while executing JavaScript took 47ms
如果告诉你，文本布局可以完全不碰 DOM，性能提升 50-100 倍，你相信吗？
这意味着什么？这意味着前端性能优化的边界还可以被突破。
2022 年，react-virtualized 的 GitHub Issue #610 中，开发者反馈了一个令人
沮丧的问题。react-virtualized 的维护者给出的回应令人震惊：
> "I don't know a way to avoid this"
这不是维护者的能力问题，而是根本性的架构困境。综上所述，Pretext 带来了令人
震惊的性能提升和深远影响。
改写后（真人风格）
## 文本测量的老问题
Recharts 也遇到过这个问题——刻度太多时性能下降。
你可能见过浏览器控制台的这个警告：
[Violation] Forced reflow while executing JavaScript took 47ms
这就是强制回流：JavaScript 在 DOM 变更后查询几何属性，浏览器被迫同步重算布局。
react-virtualized 有个 issue：动态高度虚拟列表向上滚时单元格会"跳跃"。维护者的回应
让人意外——
> "I don't know a way to avoid this"
一个几万 star 的库，直接说"不知道怎么避免"。不过这倒不是开发者技术不行，而是根本性
的架构问题：虚拟列表需要预先知道高度才能渲染，但高度只有渲染后才能测量，哈哈，经典的
"鸡生蛋"问题。
文本布局可以完全不碰 DOM，性能提升 50-100 倍。这就是 Pretext 的核心思路。
改动要点：
- 删掉万能开头： "在人工智能飞速发展的今天"→ 整句删掉
- 删掉标题序号： "一、引言"→"文本测量的老问题"
- 删掉过度标注： 2021 年、Issue #3983、"知名数据可视化库"
- 去掉来源铺垫： "DebugBear 的性能分析博客中记录了"→"你可能见过浏览器控制台的这个警告"
- 情绪词能删就删： "这不是危言耸听"→ 直接删掉（不替换成"这不是夸张"）
- 替换书面情绪词： "令人震惊"→"让人意外"
- 合并短句： 多处句号改逗号，让句子之间有连贯
- 注入真人感： 加"哈哈"、"不过"转折、"这倒不是"
- 删掉固定收尾： "综上所述"→ 整段删掉
- 砍掉开头引子： "如果告诉你 xxx"→ 直接说事
质检评分：
- 活人感：4/5（有"哈哈"、"这倒不是"，语气自然）
- 自然度：4/5（没有刻意口语标记，情绪克制）
- 信息度：5/5（删掉来源铺垫和标注，保留核心事实）
- 变化度：5/5（句式不重复）
- 节奏感：4/5（长短句交替，有逗号连接）
- 原意保真度：5/5（核心信息完整）
关键提醒
不要过度改写
❌ 错误示范：
- 删除所有括号备注
- 删除所有 emoji
- 把所有列表都改为段落
- 让全文风格完全统一
- 把所有句号都改成逗号
✅ 正确做法：
- 保留有趣的括号备注
- 保留合适的 emoji
- 保留有价值的列表
- 允许风格有些跳跃
- 只合并说同一件事的句子
改写的度
判断 > 删除：
- 先判断这个信息/情绪/句式/来源是否必要
- 不是一上来就删，而是先判断
直接 > 铺垫：
- 事实能站住时，不需要"谁说的"铺垫
- 直接说事比引经据典更有力
自然 > 完美：
- 目标不是让文章完美，是让文章真实
- 保留不完美，才是真实
克制 > 戏剧：
参考资料
核心参考
references/human-vs-ai.md — 深层特征分析：信息标注、情绪表达、句式监控、戏剧化克制references/patterns.md — AI 写作特征清单（词汇、句式、结构）references/academic-research.md — 学术研究支撑的统计学特征
使用建议
- 改写前：快速浏览 human-vs-ai.md 的判断标准
- 改写中：遇到不确定的地方，查阅对应的详细分析
- 改写后：用本文的 6 维度质检表自查
