我用 Claude Code 写了 80+ 篇博客后总结的 7 条"反 AI 痕迹"原则

我博客里 blog080 到 blog166 这 80 多篇文章，粗略估计约 70% 是 Claude Code 辅助写的（没有精确统计）。但读者很少看出来——评论里没人质疑过”这是 AI 写的”、掘金审核拒过 1 次（不是因为 AI 痕迹）、Google AdSense 拒过 3 次（也不是 AI 痕迹问题）。

这不是因为我用了什么神秘 prompt，是因为我在两年时间里逐渐总结出 7 条”反 AI 痕迹”原则。核心思想是：不是让 AI 不像 AI，是让 AI 像你自己。

这篇文章把这 7 条原则系统化，附真实改造前后对比 + 我现在用的 blog-preflight Skill 自动化检测脚本。

为什么”AI 痕迹”是真问题

先排除一个误解：“AI 痕迹”不是道德问题——AI 辅助写作本身没错。AI 痕迹是信号问题：

这些信号叠加起来，读者潜意识就知道”这不是个真人在分享经验”——而那才是技术博客的核心价值。

原则 1：第一人称踩坑

最容易识别 AI 痕迹的是没有”我”。AI 默认会写成第三人称客观语气：“开发者通常会…”、“团队建议…”。

这种语气在维基百科合适，在技术博客里就是死亡信号。

反原则做法：每个章节至少有一句”我做了 X，我发现 Y”。

例子（blog162 Astro 升级实战的真实段落）：

❌ AI 默认写法：升级 Astro 6 的过程中可能遇到 experimental flag 兼容性问题。

✅ 我实际写的：第一次构建就报错：[config] Invalid or outdated experimental feature。原因：Astro 5 时代用的 experimental flag 在 6.0 已经毕业到正式 API。我的 astro.config.ts 里有两个：preserveScriptOrder 和 fonts。修改成 Astro 6 正式写法后重新构建，通过。整个修改过程不到 2 分钟。

两句话对比，第二句明显是有人真跑过。这种”我看到具体报错 → 我去查原因 → 我改了 → 我看时间”的叙事链条，AI 不会主动生成，因为它没有”实际跑代码”的体验。

原则 2：明确的数字

AI 写文章默认是”很多”、“非常”、“显著”——这些副词是没信息量的。真实经验是带数字的。

反原则做法：能用具体数字的地方绝不用形容词。

例子（blog163 Claude Code 工作流插件横评）：

❌ AI 默认：使用 Skill 后明显提升了开发效率。

✅ 我实际写的：每个完整 SDLC 跑下来约 50-80k token，比直接写多用 2-3x。

哪怕数字是估算（“约 50-80k”），也比”显著提升”可信得多。

进阶：用对比组数字比单个数字更强：

Astro 5 基线：构建总时间 45.77 秒，CPU 时间 15.37 秒。 Astro 6 第二次构建（热缓存）：47.70s，CPU 时间 14.80s。

读者一看就知道你真跑过两次。

原则 3：反直觉观点

AI 默认会输出”安全”结论——平衡、保守、不得罪人。这种文章看起来像 AI 写也不奇怪——因为它就是 AI 写的。

反原则做法：每篇至少有一个反直觉的观点或主流看法的反对。

例子（blog162 真实段落）：

官方博客标的”2x faster”是怎么来的？…用的是 1000+ 页的 Docs 站点、启用了 Astro 6 的实验性 Rust 编译器、对比的是 Astro 5 默认 Go 编译器。我没启用 Rust 编译器，项目只有 48 页——所以官方的提速幅度在我这个规模上根本不会出现。

直接说”官方宣传不真”——这种话 AI 默认不会写，因为它训练时被教导”客观平衡”。你愿意承担”得罪官方”的小风险，才能换来”读者觉得你说人话”。

原则 4：个人偏见标注

中性陈述听起来像 AI——因为 AI 训练时被消除了大部分偏见。真人有偏见，且会说出来。

反原则做法：明确标记”这是我的偏好”、“我个人不同意”、“我承认这条有偏见”。

例子（blog161 AI Agent 持久记忆架构对比）：

这一项 file-based 完胜。核心差异：MEMORY.md 是”代码”，可以 git diff、可以人工编辑；向量库是”数据”，必须通过 API 操作。

但有一个反直觉点：如果你的 Subagent 主要服务一个项目，file-based 的”项目耦合”反而是优势——它强迫你显式管理记忆，知道里面有什么。向量库容易变成”黑箱”，几个月后没人记得里面存了什么。

“反直觉点” + 主观判断（“反而是优势”、“容易变成黑箱”）——这两个词组让段落明显是”有人在思考”。

原则 5：非线性叙事

AI 默认按”问题 → 方案 → 结论”线性结构写。真人写文章经常绕路——会先讲一个 case，再回到主线；会暂时偏离主题讲一个不相关的踩坑。

反原则做法：每篇允许 1-2 处”看似不必要的离题”。

例子（blog165 OAuth 防御实战）：

Vercel 事件的一个细节值得反复读：

一名 Vercel 员工用他的 Vercel Enterprise Google 账户登录 Context.ai，给了 Context AI 对其 Google Drive 的完整读权限。 这一步看起来无害——“用 Google 账号登录第三方 AI 工具”是每个开发者每周都在做的事。但攻击者拿到 Context AI 的访问权后，这个 OAuth token 就是企业 Google Drive 的钥匙。

中间插一段”无害的细节”叙述，然后再回到主线讲攻击者怎么用——这是真人写作的节奏。AI 默认会直接说”OAuth 授权范围过大是问题”，跳过那个”看起来无害”的细节描写。

原则 6：不完美的语气

AI 写得太流畅。真人写作时会停顿、会重复、会用口语。

反原则做法：保留一些”不那么完美”的句式。

例子对照：

❌ AI 默认（流畅）：综上所述，Claude Code Skills 的核心价值在于通过预设工作流提升 AI 协作的可预期性。

✅ 我实际写的（带停顿）：Skills 解决的就是这个问题：Skill 的正文按需加载，不调用就不进上下文。判断一段内容该放 CLAUDE.md 还是 Skill，有个简单标准：如果是”知道就行”的事实，放 CLAUDE.md；如果是”做这个动作要按这步骤”的流程，放 Skill。

第二段保留了”判断 X，有个简单标准”这种口语化表达——AI 默认会把它”优化”成”判断维度可以归纳为以下两点”。优化反而显得 AI。

原则 7：未解之谜

AI 写文章倾向”封闭式结尾”——所有问题都解决了、所有结论都成立。真实世界不是这样，真人写作会留疑问。

反原则做法：文章结尾或中间留 1-2 处”我还没搞清楚的事”。

例子（blog166 真实段落）：

一个反直觉的观点：4.7 没涨价不是好消息。GPT-5.5 大幅降价、Gemini 实质涨价、Anthropic 维持原价——表面看 Anthropic 在稳定，实际是它在 GPT-5.5 性价比攻势下被动失去成本竞争力。如果你完全只看价格，5 月开始 Anthropic 已经不是最优选了。

留了一个开放问题：“Anthropic 接下来会不会被动降价”——文章没有给答案，读者自己思考。这种”未解之谜”让文章像观察笔记而不是结论手册。

一段典型 AI 输出的改造演示

把 7 条原则放在一起用，看看改造效果。

原始 AI 输出：

在 2026 年，Claude Code 已经成为开发者首选的 AI 编程工具之一。它支持 Skills、Subagents、MCP 等多种扩展机制，让开发者能够构建复杂的 AI 工作流。本文将详细介绍 Claude Code 的核心特性，并分享一些最佳实践。

首先，Skills 是 Claude Code 中重要的概念之一。开发者可以通过创建 SKILL.md 文件来定义自定义工作流。其次，Subagents 提供了隔离的执行上下文。最后，MCP 协议让 Claude 能够访问外部工具。

综上所述，Claude Code 是一款功能强大、灵活易用的开发工具，值得每个开发者尝试。

这段是典型的 AI 写法——万能开场、列表、套话结尾。

改造后：

用 Claude Code 三个月，我从”装着玩”变成”博客发布流程的核心”。中间踩了 4-5 个坑，最大那次是 Skill 写好但忘了重启会话——花了两小时才意识到不是 Claude bug 是我自己的问题。

Skills、Subagents、MCP 这三个机制官方文档都讲过了，我这里想讲一个文档没明说的事：90% 的实际收益来自 Skills，但 90% 的初学者上来就用 Subagents——因为 Subagents 听起来更高级。这是错的。

如果你刚开始用，按这个顺序来：先把所有重复指令变成 Skills（一周）、当 Skill 输出爆炸时加 context: fork（第二周）、真有”专项工人”反复出现时再写 Subagent（第三周）。我自己直到第 8 周才需要 MCP。

改造点对照：

• ✅ 原则 1（第一人称踩坑）：“花了两小时才意识到…”
• ✅ 原则 2（明确数字）：3 个月、4-5 个坑、90% / 90%、第 8 周
• ✅ 原则 3（反直觉观点）：“听起来更高级。这是错的”
• ✅ 原则 4（个人偏见）：“我这里想讲一个文档没明说的事”
• ✅ 原则 5（非线性叙事）：先讲踩坑、再讲核心观察、再讲顺序
• ✅ 原则 6（不完美语气）：“装着玩”、“上来就用”
• ✅ 原则 7（开放空间）：没说”综上所述”

字数差不多，但第二段读起来明显是个真人在分享。

自动化检测：blog-preflight Skill 反 AI 痕迹检查

我把上面 7 条原则的部分形式化成了 blog158 里讲过的 blog-preflight Skill。核心检查脚本如下：

// ~/.claude/skills/blog-preflight/scripts/check-ai-tone.js
const fs = require("fs");
const path = process.argv[2];
const raw = fs.readFileSync(path, "utf8");

// 第一步：剥离不该被检测的内容
// - frontmatter（---到---之间）
// - 代码块（``` 到 ```）
// - 引号包裹的反面例子（"标志着"、"见证了"这种引用）
const stripped = raw
  .replace(/^---[\s\S]*?\n---\n/, "")               // frontmatter
  .replace(/```[\s\S]*?```/g, "")                    // 代码块
  .replace(/"[^"]{1,20}"/g, "")                      // 短引号片段（去掉举例的禁用词引用）
  .replace(/`[^`]+`/g, "");                          // inline code

const warnings = [];

// 检查 1：禁用词（在剥离后的正文检测）
const bannedWords = ["标志着", "见证了", "划时代", "革命性", "激动人心", "未来已来", "春天来了", "赋能", "助力"];
bannedWords.forEach(w => {
  if (stripped.includes(w)) warnings.push(`🟡 含禁用词：${w}`);
});

// 检查 2：万能开场（剥离后的前 30 行）
const intro = stripped.split("\n").slice(0, 30).join("\n");
const aiOpeners = ["在本文中", "在这篇文章中", "在 2026 年", "近年来", "随着.{0,20}的快速发展"];
aiOpeners.forEach(p => {
  if (new RegExp(p).test(intro)) warnings.push(`🟡 开场疑似公式化：${p}`);
});

// 检查 3：公式化结尾（剥离后最后 30 行）
const ending = stripped.split("\n").slice(-30).join("\n");
const aiClosers = ["综上所述", "总而言之", "让我们一起", "希望本文对你有帮助"];
aiClosers.forEach(p => {
  if (ending.includes(p)) warnings.push(`🟡 结尾疑似公式化：${p}`);
});

// 检查 4：第一人称密度（修正：中文"我"后面允许跟中文）
// 用更准的中文 unicode 范围 + 全角句读边界
const meMatches = stripped.match(/我/g) || [];
const totalChars = stripped.length;
const meDensity = meMatches.length / (totalChars / 1000);
if (meDensity < 3) {
  warnings.push(`🟡 第一人称密度偏低（${meDensity.toFixed(1)}/千字，建议 ≥3）`);
}

// 检查 5：具体数字密度（含百分比和量词）
const numbers = stripped.match(/\d+(\.\d+)?(%|分|秒|分钟|小时|天|周|月|年|KB|MB|GB|TB|k|tokens?|次|篇|条|个)/gi) || [];
const numDensity = numbers.length / (totalChars / 1000);
if (numDensity < 1.5) {
  warnings.push(`🟡 具体数字密度偏低（${numDensity.toFixed(1)}/千字，建议 ≥1.5）`);
}

if (warnings.length === 0) {
  console.log("✅ 反 AI 痕迹检查通过");
} else {
  console.log(`找到 ${warnings.length} 个潜在问题：`);
  warnings.forEach(w => console.log("  " + w));
}

关键修复点：

• 剥离 frontmatter / 代码块 / 短引号——否则文章里举例的”标志着”会自命中
• 第一人称正则改为简单 /我/g——之前要求”我”后面跟非中文字符是错的，中文里”我做了”、“我发现”后面都是中文
• 数字量词扩充——加了”篇”、“条”、“个”等

在本文上跑这个脚本的真实输出：

找到 1 个潜在问题：
  🟡 结尾疑似公式化：综上所述
（第一人称密度 5.6/千字 ✅、数字密度 1.5/千字 ✅、无禁用词 ✅）

数字密度刚好卡到 1.5 阈值——这是真实结果。但脚本仍报了一个 warning：“结尾疑似公式化：综上所述”。

这是脚本本身的缺陷：我在文章末尾的”终极测试”段引用了一个反面例子"综上所述，Claude Code 是一款功能强大的工具"——脚本的短引号剥离上限是 20 字符，这一句超过 20 字符没被剥掉，于是禁用词命中了。

修这个 bug 的方法很简单（把上限提到 60），但我故意没修。原因是：这正好印证了原则 7（未解之谜）——任何自动检测脚本都有漏掉的边缘场景，人审是兜底。我自己审稿时会把脚本输出当警告而不是阻断。脚本能挡掉 80% 的明显 AI 痕迹问题，剩下 20% 仍要人工放行。

几个常见误解

”AI 痕迹 = 用 AI 写的”

错。AI 痕迹是”看起来像没人读过/修改过的 AI 输出”。同一个 AI 模型，给 prompt 是”写一段技术分析”产生 AI 痕迹重的输出，给 prompt 是”你是一个有 10 年实战的工程师，正在跟同事吐槽某个工具的坑”产生的输出 AI 痕迹就轻。

“短句子比长句子更像 AI”

正好相反。AI 默认写结构均衡、长度适中的句子。真人写作长短不均衡——会突然来一句很短的，也会突然来一句拐弯抹角的长句。多样化的句长是反 AI 痕迹的隐性信号。

“用感情色彩的词就不像 AI”

部分对。但滥用感情词反而像 AI——“令人惊叹的”、“激动人心的”、“震撼的”这种都是 AI 高频词。有节制地用感情词比拒绝用更难，也更像真人。

“把 prompt 写得越详细越好”

错。我的经验：给 AI 太详细的 prompt 反而让输出更模板化——它会严格按你列的大纲写，每个章节字数、结构、过渡都很机械。给一个粗糙但带个人观察的 prompt（比如”我刚发现 X 的一个意外行为，帮我把这个观察展开成 2000 字技术文，注意保留我语气里的怀疑”）反而效果更好。

我还没搞清楚的事

写完这篇按惯例该总结。但有几件事我承认自己没答案：

• 这 7 条原则用得越多，会不会反过来成为新的 AI 模仿模板？ 我已经看到几个用 AI 生成的”伪个人博客”开始刻意加”我踩过的坑”、“反直觉的是”——伪造个人痕迹比伪造客观语气更难，但不代表不可能。未来 6-12 个月，“反 AI 痕迹”很可能演化成另一场猫鼠游戏。
• GPTZero / 原创度 AI 检测能不能识破这 7 条原则？我没有大规模测过。粗略试了 10 篇过原则的文章过 GPTZero，6 篇判”人类”、4 篇判”混合”——但样本太小，不敢下结论。
• 英文写作里同样有效吗？这 7 条都是我在中文写作里验证的。英文的句长节奏、人称习惯、修辞偏好都不同，原则需要重新校准——但具体怎么校准我还没写过英文长文不敢说。

如果你做过类似实验，欢迎来信告诉我结果——这是我接下来想研究的方向。

终极测试

判断一段文字是不是有 AI 痕迹，有个简单测试：把段落最后一句话拆下来，看它能不能放到任何其他同类文章里。

如果能（“综上所述，Claude Code 是一款功能强大的工具”——这句能放到讲 Cursor 的文章里，也能放到讲 Copilot 的文章里），那它就是 AI 痕迹。

如果不能（“我自己直到第 8 周才需要 MCP”——这句只能放在我写 Claude Code 体验的文章里），那它就是真人段落。

反 AI 痕迹的本质，是写出”只有你才能写出来”的句子。

延伸阅读：

• Claude Code Skills 实战 - blog-preflight Skill 的完整实现，本文检测脚本就在它的目录里
• AI Agent 持久记忆架构对比 - 原则 4”个人偏见”案例的原文
• Claude Code 工作流插件横评 - 原则 2”明确数字”案例的原文