“去 AI 味”不是一个按钮：我把 7 个 GitHub 项目拆成了 5 类工作
很多人第一次搜索“去 AI 味”，想找的是一个神奇按钮：把一段 GPT 味很重的文字丢进去，出来以后立刻像真人写的。 我把这批素材里的 7 个 GitHub 项目重新核了一遍，结论反而是：“去 AI 味”根本不是一个单一任务。 有的项目像语病清洁器，有的更接近事实保真的编辑器，有的只做检测，有的试图校准“你的声音”，还有的干脆把研究、写作、审稿、导出做成一整条 Agent 流程。把它们放在
“去 AI 味”不是一个按钮：我把 7 个 GitHub 项目拆成了 5 类工作
很多人第一次搜索“去 AI 味”，想找的是一个神奇按钮：把一段 GPT 味很重的文字丢进去，出来以后立刻像真人写的。
我把这批素材里的 7 个 GitHub 项目重新核了一遍，结论反而是：“去 AI 味”根本不是一个单一任务。
有的项目像语病清洁器，有的更接近事实保真的编辑器，有的只做检测，有的试图校准“你的声音”，还有的干脆把研究、写作、审稿、导出做成一整条 Agent 流程。把它们放在同一个排行榜里比 Star，信息量很低。
真正值得建立的是一张“写作质量控制地图”。
一、先把一个误区拆掉：AI味不是一种病
所谓“AI味”，通常至少混了六种问题。
第一种是套话。比如固定开场、空洞强调、机械总结、连续使用“值得注意的是”“更重要的是”。
第二种是抽象表达过多。句子看起来正确，却没有具体对象、动作、证据和限制条件。
第三种是节奏机械。每段差不多长，每个小节都三点，每个结尾都升华。
第四种是事实漂移。这是最危险的：为了改得自然，把版本号、数字、人物关系、责任归属甚至因果一起改掉。
第五种是声音丢失。原稿本来有作者自己的犹豫、偏好、断句和表达习惯，AI“一键润色”后反而变成最标准的公众号腔。
第六种才是大家最常谈的“像不像AI”。
所以如果只用一个 detector 分数衡量“去AI味”，会把真正重要的事排在后面。
对 alphahole 来说，优先级应该是：
Fact Fidelity → Voice Fidelity → Readability → Pattern Cleanup → Detector Signal。
Detector 最多是诊断参考，不是终点。
二、7 个项目，其实属于 5 种不同工具
1. qu-ai-wei：中文“清理规则”型
这类项目把中文里常见的机器化表达拆成规则：套话、抽象、节奏、语体等。它的价值不是“让检测器认不出来”，而是把编辑判断显式化。
最值得保留的一条不是某个禁词表，而是：改写时不能凭空补事实。
这比“像不像人”重要得多。
2. 说人话：事实保真型编辑器
这类项目特别适合技术写作。
README、部署说明、版本升级、开发进度这些内容最怕“润色以后更好看，但命令、版本、归属变了”。
所以它真正的定位更接近：
Humanize while preserving operational truth。
一个技术编辑器如果只会把句子变顺，却把 v3.1 改成“最新版本”、把“项目作者声称”改成“事实证明”，那就是失败。
3. Humanizer / Stop-Slop：模式清洁型
Humanizer 的思路很典型：从公开的“Signs of AI writing”一类模式出发，逐项处理固定开场、假强调、模板收尾、滥用转折、过度列表等。
Stop-Slop 更像已经成稿后的二次清洁。
这里需要一个反直觉判断：规则越多，不一定改得越好。
“不要破折号”“不要被动语态”“短句更像人”这类规则，一旦脱离语境，很容易把专业文本改坏。
医学、法律、技术、研究写作，本来就需要一定结构和被动表达。把“某种形式经常出现在AI文本里”升级成“这种形式永远不该出现”，就是从 pattern 变成 superstition。
4. no-ai-slop：最小有效修改型
这一类是我更看重的方向。
如果原稿已经有个人声音，最危险的不是“改得不够多”，而是“改太多”。
检测模式 → 找最明显的机器痕迹 → 做最小修改 → 人再过一遍，往往比整篇重写更能保住作者。
这可以总结成一个原则：
Minimum Effective Edit。
你不是要把文章洗成另一篇“更像人”的文章，而是把阻碍阅读、破坏真实感的部分修掉。
5. De-AI Prompt Enhancer：参考语料 / Voice Calibration 型
这类方法把真实文章当风格参考，让模型学习表达规律，再处理机器痕迹。
它的潜力很高，但风险也更高。
问题不在“能不能学”，而在于：你到底是在抽象结构，还是在复制一个具体作者的表达身份？
安全路径应该是：
自己的旧文章 / 已授权语料 → 抽象出句长、信息密度、常用转折、论证方式 → 形成可解释的 style profile → 新稿修改 → 相似性检查。
而不是把某位作者的文章塞进去，然后要求“写得就像他”。
6. Writing Agent：完整写作工作流型
它和前面几类其实不是一回事。
前面是在回答“稿子怎么改”，它是在回答：
选题怎么研究 → 证据怎么找 → 初稿怎么写 → 怎么审稿 → 怎么排版/导出。
因此“去 AI 味”只是其中一个环节。
这类项目的风险也恰恰在这里：流程越长，越容易把一个局部错误放大成完整成品。
如果研究源错了、引用错了、作者事实层和编辑判断混了，后面写得再自然也没有意义。
所以完整 Writing Agent 必须有：
Source Gate → Claim Ledger → Draft → Fact Fidelity → Voice Fidelity → Rights → Reverse Review → Human Final。
三、真正值得做的不是“7选1”，而是分层组合
如果只是普通中文改稿：
事实保真型 + 最小有效修改已经够用。
如果是技术内容：
优先 Fact Fidelity，任何“人类化”都不能动命令、版本、接口和责任归属。
如果是个人品牌：
先建立自己的历史语料，再做 Voice Calibration。
如果是团队批量生产：
才值得考虑完整 Writing Agent，但必须把证据、版权和最终人工审批嵌进流程。
也就是说，工具选择不应该问：“哪个最会去AI味？”
而应该问：我的失败模式是什么？
四、一个更实用的“去 AI 味”验收表
我更愿意用下面 8 个字段，而不是检测器分数。
- Claim Fidelity：重要事实有没有变？
- Number Fidelity：数字、日期、版本、价格、比例有没有漂？
- Attribution Fidelity：“作者说”“官方说”“编辑判断”有没有互相冒充？
- Voice Retention：作者原来的节奏和选择偏好还在不在？
- Specificity：抽象句有没有落到对象、动作、证据和条件？
- Repetition：有没有同义重复、机械转折、连续总结？
- Read-aloud：读出声是否像正常人会这样说？
- Regret Test：如果作者本人明天看到，会不会说“这不是我会说的话”？
最后这个问题往往比 detector 更有用。
五、这件事真正能怎么变现
“去 AI 味”本身很容易被做成廉价工具，因为规则公开、Prompt也容易复制。
真正有收费空间的是持续判断。
例如一篇文章改完以后，系统不只告诉你“AI痕迹 23%”，而是告诉你：哪句话事实可能漂移；哪句话不符合你过去 50 篇文章的声音；哪个数字没有来源；哪一段是模板化结构；哪些修改是必要的；哪些地方应该保留“不完美”。
这就从“Humanizer”变成了：
Content Voice & Fact Fidelity Audit。
免费层可以做单篇检查；会员层可以维护个人 style baseline、历史版本差异和回归；团队层可以做品牌写作规范与发布前 QA。
但这一步还不能直接做新 V2。
因为我们已经有 Content Company OS 和 Skill Trust Workbench。正确动作是把这些字段先并进去，然后做真人盲评：原稿 / 一键改写 / 最小修改三版混在一起，让真实读者判断哪版更像作者、哪版信息最清楚、哪版事实错误最少。
只有这组 V3 数据出来，才知道这个产品值不值得继续。
六、Stop Rule
如果一个“去AI味”工具只能让 detector 分数下降，却出现数字更容易错、原作者声音被抹平、引用归属漂移、专业文本被强行口语化、人工返工增加中的任意一个，就应该停止使用。
去 AI 味不是“骗过谁”。
它应该是一次编辑：让文字少一点自动生成的惯性，多一点作者真正愿意负责的判断。
七、把 7 个项目放进同一张审计表，差异才真正清楚
如果不是为了“收藏数量”，而是为了实际选工具，我会按下面几类判断：
| 工具类型 | 更适合做什么 | 最该检查什么 | 不该承诺什么 | |---|---|---|---| | qu-ai-wei 类中文规则 | 中文套话、抽象表达、节奏清理 | 规则是否误伤专业表达、事实有没有变 | 不能承诺“改完就是人写” | | 说人话类事实保真编辑 | README、技术文章、项目更新 | 命令/版本/责任归属/术语保真 | 不能为了口语化改掉技术含义 | | Humanizer | 通用模式检测与清理 | 规则是否过度泛化 | 不能把检测模式当写作真理 | | Stop-Slop | 已成稿英文的二次清洁 | 是否造成语义压缩或风格扁平 | 不能把“短句多”当人类化 | | no-ai-slop | 原稿已有声音时的最小修改 | 改动范围、误报、回滚 | 不能默认全篇重写 | | De-AI Prompt Enhancer | 个人/品牌声音校准 | 参考语料权利、相似性、身份模仿 | 不能把他人风格当可复制资产 | | Writing Agent | 研究到发布的完整流程 | Source、Claim、Rights、Human Gate | 不能把长流程当可靠性证明 |
这张表还有一个作用：让“安装工具”从默认动作退回到最后一步。
如果你的问题只是两段套话，没有必要引入完整 Agent；如果你的问题是事实经常漂，换一个更强的 Humanizer 也未必解决；如果你的问题是团队风格不统一，需要的是 Voice Baseline 和 QA，而不是更多禁词。
八、真正的失败样本应该怎么记
“去 AI 味”最容易只保留成功案例：一段文字改完好像自然了，于是就宣布方法有效。
更有价值的是建立 Failure Ledger：
- 原文事实是什么；
- 工具做了什么改动；
- 哪个改动造成事实漂移；
- 哪个改动让作者声音消失；
- 哪个规则在技术稿有效、在故事稿反而伤害表达；
- 人工修复花了多久；
- 下一版应该删规则、调阈值，还是直接不使用这个工具。
只有把失败样本积累起来，所谓“风格系统”才有可能从 Prompt 变成可维护资产。
九、如果真要做 V3，我会怎么测
我们不拿 AI detector 当主指标，而做三类盲测。
盲测一：作者识别
同一篇原稿做三版：原始AI稿、一键Humanizer、Minimum Effective Edit。让熟悉作者的人盲选“哪一版最像他”。盲测二：事实保真
把数字、日期、版本、归属、引用做成核对清单，统计每100个关键字段的漂移数。盲测三：编辑成本
记录每篇最终人工修复分钟数。一个工具如果“更自然”，却让最终编辑时间从15分钟涨到40分钟，它没有提高生产力。最后才看读者的停留、收藏或反馈，而且这些只能说明传播表现，不能反过来证明事实更准确。
这三组数据比“AI率下降了多少”更接近真实产品价值。