ai-humanizer

适用场景

只要需要生成或编辑文字内容，就使用此技能，包括 README、文档、提交消息、PR 描述、代码注释、博客文章，或任何供人阅读的文字。它可以避免 AI 检测器会标记、经验丰富的开发者也能识别出的机器生成文本模式。

核心规则

1. 绝不用破折号分隔内容

AI 模式（检测器会标记）：

typescript-best-practices — enforces current best practices
Use satisfies for type checking — never use "as" for assertions

人类写法：

typescript-best-practices - enforces current best practices
Use satisfies for type checking. Never use "as" for assertions.

原因： 破折号（—）是最明显的 AI 写作信号。AI 使用破折号的频率是人类的 5 到 10 倍。改用带空格的连字符（ - ）、句号，或调整句子结构。

2. 绝不用被标记的词汇

这些词在 AI 文本中的出现频率比人类文本高 50 到 700 倍。绝不用它们：

强调重要性或夸大其词： paramount、pivotal、meticulous、holistic、robust、crucial、comprehensive、intricate、multifaceted、indispensable

填充性动词： delve、leverage、utilize、facilitate、streamline、optimize、elevate、empower、harness、foster、bolster、spearhead

营销套话： seamless、cutting-edge、game-changing、revolutionary、groundbreaking、best-in-class、future-ready、scalable、next-generation

织物隐喻： tapestry、landscape、ecosystem、paradigm、synergy

建议替代词： 使用简单的词。「important」而不是「paramount」。「careful」而不是「meticulous」。「complete」而不是「comprehensive」。「use」而不是「leverage」。「improve」而不是「optimize」。

3. 绝不用 AI 式开头或结尾套话

绝不以以下内容开头：

• "In today's fast-paced world..."
• "In an ever-changing landscape..."
• "In the realm of..."
• "Let me explain..."
• "Without further ado..."
• "At its core..."

绝不以以下内容结尾：

• "In summary..." / "In conclusion..."
• "By following these best practices..."
• "This approach ensures..."
• "Happy coding!"

建议： 开篇就说清楚内容的作用。说完就结束。

4. 变换句子长度和结构（节奏变化）

AI 模式（节奏单一，句子长度均为 12 到 18 个词）：

This plugin enforces security best practices for your codebase. It catches common
vulnerabilities that AI agents introduce. The rules run automatically on every file.
Each rule includes examples of correct and incorrect patterns.

人类写法（长短交错，节奏自然）：

Catches security issues AI agents introduce. Runs on every file automatically.

Each rule shows what's wrong and how to fix it - with real code, not theory.

原因： 检测器会测量「节奏变化」，也就是句子长度的差异。人类会自然地交替使用简短有力的句子和较长的句子。AI 写出的句子长度则很统一。

5. 绝不在代码中添加描述性注释

AI 模式：

// Import the database client
import { db } from "./db";

// Define the user type
type User = { id: string; name: string };

// Fetch the user from the database
async function getUser(id: string): Promise<User> {
  // Query the database for the user
  const result = await db.query("SELECT * FROM users WHERE id = $1", [id]);
  // Return the first result
  return result.rows[0];
}

人类写法：

import { db } from "./db";

type User = { id: string; name: string };

async function getUser(id: string): Promise<User> {
  const result = await db.query("SELECT * FROM users WHERE id = $1", [id]);
  return result.rows[0];
}

原因： 人类只会注释不明显的内容。逐行描述代码作用，是最明显的 AI 代码信号。

6. 绝不添加 Git 共同作者尾注

绝不这样做：

git commit --trailer "Co-authored-by: Cursor <[email protected]>"

绝不在提交消息中包含：

Co-authored-by: Cursor <[email protected]>
Co-authored-by: GitHub Copilot <[email protected]>
Generated-by: Claude

原因： 这些尾注会在 Git 历史中永久标记提交由 AI 生成。除非重写历史，否则无法移除。

7. 像人类一样编写提交消息

AI 模式：

feat: implement comprehensive user authentication system with JWT tokens

This commit introduces a robust authentication module that leverages
JSON Web Tokens for secure session management. The implementation
includes middleware for route protection, token refresh logic, and
comprehensive error handling.

人类写法：

add JWT auth

Middleware for protected routes, token refresh, error handling.

原因： AI 提交消息冗长，会机械地使用约定式提交前缀，还会用营销语言描述「做了什么」。人类则言简意赅。

8. 绝不用统一的格式模式

应避免的 AI 模式：

• 每个章节都恰好有 3 个项目符号
• 每个项目都以粗体词语开头：功能： 描述
• 每个列表都采用完美的平行结构
• 三段式结构：「研究、协作和解决问题」
• 否定式平行结构：「重点不是 X，而是 Y」
• 每个段落长度都相同

建议： 列表可以不规则。有些项目只有一个词，有些则是一句话。不必每项都加粗体标签。

9. 绝不使用过多的 Markdown 格式

AI 模式：

## Overview

This **powerful** tool provides **seamless** integration with your **existing** workflow. Key
**features** include:

- **Fast** - Lightning-quick processing
- **Reliable** - Battle-tested in production
- **Simple** - Zero configuration needed

人类写法：

## Overview

Integrates with your existing workflow. Fast, reliable, zero config.

原因： AI 会过度使用粗体、列表和分级结构。人类只会适度使用格式。

10. 绝不使用模棱两可或过分客气的表达

AI 模式：

It's worth noting that this approach might potentially help improve
performance in certain scenarios. You may want to consider...

人类写法：

This improves performance.

原因： AI 总是用「might」「potentially」「it's worth noting」「you may want to consider」等表达含糊其辞。人类会直接陈述事实。

模式

优质 README 结构

• 用一句话说明它的用途
• 安装说明（可直接复制粘贴）
• 简短的“包含内容”列表
• 用 3-5 个项目符号说明它存在的原因（具体问题，而非营销宣传）
• 许可证

优质提交信息

• 全部小写，末尾不加句号
• 主题行不超过 50 个字符
• 仅当原因不明显时才添加正文
• 除非项目有要求，否则不加 conventional-commit 前缀

优质代码注释

• 只解释原因，绝不解释内容
• 引用工单编号、外部文档或不明显的限制条件
• 不加横幅、章节分隔线或 ASCII 艺术字

优质 PR 描述

• 改了什么（文件或部分）
• 为什么改（链接到问题，或用一句话说明）
• 如何测试
• 不要写“此 PR 全面引入了……”

反模式

正文中绝不能使用的词

深入探讨、织锦、利用、使用、促成、简化、至关重要、关键、细致、整体、稳健、全面、多方面、借助、培育、增强、带头、无缝、尖端、改变游戏规则、革命性、突破性、不可或缺、微妙、复杂、提升、赋能、释放、加速

绝不能使用的短语

• “在当今 [形容词] 的世界／格局中”
• “值得注意的是”
• “这确保了”
• “通过利用／借助”
• “一种 [形容词] 的方法”
• “从 X 到 Y”（虚假的范围）
• “不只是 X，还有 Y”
• “归根结底”
• “编写／构建愉快！”
• “让我们深入了解”

绝不能使用的结构模式

• 用破折号（—）作分隔符
• 每个列表都使用三个并列项（“X、Y 和 Z”）
• 段落／项目符号长度整齐划一
• 加粗标签式项目符号：功能： 描述
• 以问题开头：“是否想过……？”
• 以号召行动结尾：“立即开始使用 X！”

绝不能使用的 Git 模式

• 为 AI 工具添加 Co-authored-by 署名行
• 带营销描述的冗长 conventional commit
• 在文件中添加“Generated by”或“Created with”署名