AI 生成的技术文章怎么去 AI 味：网上方案整理和我的取舍

最近我在整理一个问题：AI 生成的技术文章，怎么去掉那种很明显的“AI 味”。

网上有很多答案。有的讲提示词，有的推荐 humanizer 工具，有的直接把目标写成“绕过检测器”。这些方案有参考价值，但如果放到技术博客、README、项目复盘和开发文档里，我觉得要先换一个问题。

不是：

怎么让 AI 文本看起来不像 AI？

而是：

怎么让 AI 起草的内容变成准确、具体、可信的技术表达？

这两个问题不一样。

前者容易走向文字游戏，后者才适合开发者。

网上方案大致分三类

我搜了一轮资料后，发现常见方案基本可以分成三类。

第一类是从提示词阶段减少模板味。

做法是让模型一开始就不要写成“宣传稿”：

• 少用宏大开场。
• 避免空泛词，比如“赋能”“显著提升”“无缝衔接”。
• 写得像真实开发者解释问题。
• 加场景、限制、错误、命令、指标和取舍。
• 不要每段都使用“首先、其次、最后”。

第二类是人工编辑。

这类方案强调：AI 初稿只是材料，最终要靠人补上下文、事实和判断。常见改法包括：

• 删掉放在哪篇文章里都成立的句子。
• 把“更稳定”“更高效”换成具体变化。
• 加真实项目里的限制。
• 写出为什么没有选择另一个方案。
• 保留不确定性，不把所有结论写死。
• 打破过于整齐的句式节奏。

第三类是工具化处理。

网上有很多 AI humanizer 工具和开源项目，会尝试改写句式、替换高频词、增加句子变化，甚至根据检测器反馈反复重写。

这类工具可以研究，但我不会把它当成技术文章的主要解决方案。

原因很简单：技术文章不能为了更像人，把事实、命令、参数、代码块和项目边界改坏。

一些可参考的项目和工具

我把搜到的工具按用途简单整理一下。

写作痕迹审查类

blader/humanizer 是一个面向 Claude / OpenCode 的 skill，思路是先审查文本里的 AI 写作痕迹，再给出改写。它参考了 Wikipedia 社区总结的 AI 写作模式，比如套话、过度平滑、结构重复、过度解释。

conorbronsdon/avoid-ai-writing 也是类似方向，偏“识别 AI 写作模式 + 给替代表达”。

这类项目对我最有参考价值。

不是因为它们能一键改好文章，而是它们提供了一种审稿思路：

先识别模式，再决定要不要改。

自动 humanizer 类

lynote-ai/humanize-text 是一个 Python 工具，里面有多轮改写、翻译链路等方案，目标是打散 AI 文本的统计特征。

rudra496/StealthHumanizer 是一个 Web 应用型项目，支持多模型、多风格、多语言，也带本地评分。

这些项目适合研究“工具怎么改写文本”，但我不会直接用它们处理技术文章正文。

技术文章里的这些内容不能被随便改：

• 命令。
• 代码。
• 配置项。
• 版本号。
• 接口字段。
• 项目已经完成和没有完成的范围。

如果 humanizer 为了让句子更自然，把 p95、Redis Lua、Docker Compose、pgvector 这类术语改坏，那就得不偿失。

检测器反馈类

ssamba1/untell 这类项目会根据检测器结果反复改写，直到检测分数下降。

这个方向很有意思，但也最容易跑偏。

如果目标是“绕检测”，文章很容易变成另一种不自然：句子看起来不那么像 AI，但信息仍然空，甚至更绕。

对我的博客来说，检测器不是核心读者。

读者才是。

商业工具可以辅助，但不要替代判断

还有一些商业工具，比如 Grammarly、QuillBot、WriteHuman、Walter Writes 这类产品，会提供 humanizer、paraphrase、tone rewrite 等能力。

它们适合做轻量润色：

• 改掉过长句子。
• 提醒重复表达。
• 调整语气。
• 让英文更自然。
• 帮忙发现明显模板词。

但我不会让它们直接决定技术文章最终版本。

尤其是中文技术文章，工具有时会把表达改得很顺，却失去工程现场感。

比如：

该方案显著提升了系统的稳定性和可维护性。

润色工具可能会把它改得更漂亮，但我真正需要的是改成：

这次改动把搜索按钮的事件绑定从“页面加载时绑定一次”改成了全局点击委托。
Astro 页面切换后，按钮节点变了也能继续打开命令面板。

这不是润色问题，而是信息问题。

我不把“去 AI 味”理解成文字美化

AI 味的核心不是某个词，而是缺少真实上下文。

常见问题有几类。

问题一：只有结论，没有过程

AI 喜欢这样写：

本次优化提升了页面的可用性和用户体验。

这句话太安全。

如果是技术博客，我更愿意写成：

项目卡片原来只有右上角一个圆形箭头，能点，但不明显。
我试过在底部再加一个“查看项目”，后来发现两个入口重复。
最后保留右上角入口，把它改成“查看项目 ↗”，GitHub 放在旁边，底部只留演示。

这段不一定更华丽，但它更真实。

问题二：只有方法，没有边界

AI 很容易给完美建议。

比如：

可以引入 Pagefind 提升站内搜索体验。

这句话没错，但缺少边界。

我会改成：

如果文章超过十篇，Pagefind 会比当前命令面板更适合。
但现在文章数量还少，先把栏目和标题做好更划算。

技术文章里，边界比口号重要。

问题三：只有抽象词，没有可验证细节

AI 生成的文章常出现：

增强稳定性
优化体验
提升效率
形成闭环
完善体系

这些词本身不是错，但需要被事实支撑。

我会用几个问题逼自己补细节：

• 改了哪个文件？
• 修了哪个行为？
• 跑了什么验证？
• 线上怎么确认？
• 哪些东西没有改？
• 为什么没有顺手做更多？

如果回答不上来，就不要急着写“提升”。

技术文章的去 AI 味流程

我现在会把 AI 初稿分成四步处理。

第一步：先当资料，不当正文

AI 生成的大纲、清单、反例、结构可以保留。

正文要谨慎。

尤其是这些内容，我不会直接相信：

• 性能结论。
• 工具排名。
• 项目事实。
• 版本差异。
• 案例来源。
• “最佳实践”。

如果一段话没有来源、没有项目上下文、没有验证路径，我会先把它当成待确认材料。

第二步：删掉通用正确的话

通用正确的话最容易制造 AI 味。

比如：

良好的文档对于团队协作和项目维护非常重要。

这句话对，但没有必要。

可以换成具体场景：

我在跨窗口接项目时，最依赖的不是聊天记录，而是 `HANDOFF.md`。
它要写清楚当前目标、改过哪些文件、验证过什么、还有什么风险。

技术文章最好让读者看到场景，而不是只看到原则。

第三步：把形容词换成事实

看到这些词时，我会停一下：

显著、有效、完整、稳定、高效、清晰、可靠、可扩展

不是说不能用，而是要问：凭什么？

比如：

搜索功能更加稳定。

可以改成：

搜索按钮原来只在页面加载时给当前节点绑定一次事件。
页面切换后节点变了，点击就可能没反应。
改成事件委托后，点击时会重新查当前页面里的命令面板。

这段没有说“更加稳定”，但读者能看出来。

第四步：补取舍，而不是补形容词

AI 很会写“做了什么”，但弱在“为什么这么做”。

我会补两类信息：

为什么做这个？
为什么没有做那个？

比如：

这次没有加大 Hero。
因为这个站不是产品官网，首屏过大反而会压住项目内容。

这类句子能体现判断。

比“保持克制、突出重点”更可信。

一个改写例子

AI 初稿：

本文介绍了如何利用 AI 辅助完成技术文章创作。通过合理使用 AI 工具，开发者可以快速生成结构化内容，并在此基础上进行优化，从而提升写作效率和内容质量。在实际应用中，我们需要结合自身经验，对 AI 生成的内容进行适当调整，使其更加符合真实场景。

这段的问题是：它没有错，但没有任何真实信息。

我会改成：

我现在会让 AI 先帮我列文章结构，但不会直接用它生成的正文。

原因很简单：它写得太顺。
每一段都像正确答案，却没有项目里的具体限制。

比如写“优化项目展示页”时，AI 很容易说“增强用户体验”。
但真实过程其实是：先加了一个底部按钮，后来发现和右上角入口重复，最后只保留一个入口。
这个取舍才是文章里真正有价值的部分。

改写后的重点不是“更像人”，而是多了上下文和判断。

我会怎么使用 humanizer 工具

如果真要用，我只会把它放在流程后半段。

AI 初稿 -> 人工核对事实 -> 人工补上下文 -> 工具做轻量润色 -> 人再检查一遍

不会这样：

AI 初稿 -> humanizer -> 直接发布

尤其是技术文章，最后必须人工检查：

• 代码块有没有被改坏。
• 命令还能不能运行。
• 术语有没有被替换错。
• 项目事实有没有被夸大。
• “计划做”有没有被写成“已完成”。

工具可以帮忙去掉一部分机械感，但不能替我承担技术责任。

我的检查清单

写完后，我会扫一遍：

有没有通用空话？
有没有真实场景？
有没有项目名、命令、指标、错误或取舍？
有没有把不确定的事写成确定结论？
有没有夸大收益？
有没有每段都像模板？
有没有只写“应该”，没写“为什么这次这么做”？
有没有工具改坏技术细节？
有没有可以删掉但不影响理解的句子？

如果删掉三分之一以后文章更清楚，说明原来有太多 AI 味。

最后

网上有很多去 AI 味方案，也有不少 humanizer 项目。

它们可以参考，但我不想把这件事变成“怎样绕过检测器”。

对技术文章来说，更重要的是：

准确。
具体。
有上下文。
有边界。
有取舍。
能验证。

AI 可以帮我整理结构，也可以帮我找到表达里的模板味。

但最后那一遍，一定要回到真实工作：我遇到了什么问题，为什么这么处理，验证了什么，没有做什么。

写到这一步，文章自然就不像 AI 了。

Brief

This note summarizes common online approaches to removing AI tone from technical writing: better prompts, manual editing, humanizer tools and open-source projects.

For technical posts and documentation, I do not treat detector bypass as the goal. Accuracy, context, real constraints and credible engineering judgment matter more.

My practical approach is to use AI for structure and rough drafts, then edit manually: remove generic claims, add project context, preserve uncertainty, verify facts and rewrite the final text in my own voice.