上周赶项目交付整组3个人写的技术方案全被内部平台打回提示AI生成占比超标直接扣了半天绩效。当时我第一反应是手动改改内容就行忍不住嘀咕自己改能降低 AI 率吗动手试了第一版直接翻车。我最开始走的完全是歪路把所有AI生成的内容里的“非常”“极其”这类副词全删了同义词替换了近三分之一的词连所有标点都检查一遍全角转成半角。 折腾俩小时一测AI占比还是91%红得晃眼。当时我还以为是函数命名太规整的问题把所有蛇形命名的函数随机改了两三个字母的大小写甚至把连续的长段落全拆成两行一段的碎块。结果第二次测出来还是87%差点当场把键盘掀了。后来翻了不少开源AIGC检测模型的实现源码才搞懂我之前的操作全打在了棉花上。 现在绝大多数主流检测工具根本不是靠“有没有AI常用词”来判定的抓的是两层核心特征第一层是token级别的分布概率AI生成的每个token的衔接概率都远高于普通人随手敲的内容第二层是全局语义的平滑度AI写东西全程不会跳脱连指代用词都会保持100%统一很少出现人类经常犯的小疏漏。 很多攻略说的替换同义词、打乱段落顺序根本碰不到这两层特征的核心忙活一天都是无用功。光调整语序没用先拆AI的长句特征AI生成内容有个非常统一的习惯写出来的句子基本不会有断点二三十个字连在一起分句之间的逻辑衔接顺得毫无波澜普通人写东西哪怕是写技术文档经常写着写着就跳个小逻辑回头再补半句。 我一开始写了个几十行的小脚本专门把AI生成的长连贯句按常用标点拆成分句随机打乱部分分句的顺序人为打破这种绝对平滑的语序。import re import random def break_long_sentences(text: str, max_len: int 22) - str: # 把长于max_len的句子按标点拆成独立分句随机调整部分语序 sentences re.split(r([。]), text) processed [] temp_chunk [] for i in range(0, len(sentences)-1, 2): seg, punc sentences[i], sentences[i1] temp_chunk.append(seg punc) # 超过长度阈值就有概率打乱当前攒的分句 if len(.join(temp_chunk)) max_len and random.random() 0.3: random.shuffle(temp_chunk) processed.extend(temp_chunk) temp_chunk [] processed.extend(temp_chunk) return text if len(processed) 0 else .join(processed)我当时拿那段测出来91%的内容跑了一遍这个脚本AI占比直接从91%降到了72%效果比我瞎改俩小时强太多。 但这里要注意一个坑打乱的概率别设太高控制在30%以内就行不然出来的内容语序混乱正常人读着都费劲完全没必要。到这一步其实还不够我当时以为自己摸透了逻辑改完之后拿给组里同事看他随手一测还是70%多还是过不了阈值。人工改写降AI率的隐藏加分项我蹲了一下午模型的特征权重表才发现有个占比17%的权重项几乎所有讲降AI率的攻略都没提过实体指代的重复率。 AI生成内容的时候只要第一次定义了某个实体的名字后面全文都会100%严格复用这个标准命名比如第一次说“Redis缓存”后面几十次提都不会换说法连个简称都不会随便用。 但真实的开发者写内容根本不会这么严谨第一次提是“Redis缓存”第二次可能顺手写“这个缓存组件”第三次图省事直接敲“Redis”甚至偶尔脑抽写错了再改回来这种不统一的指代才是人类内容的典型特征。我又补了个专门处理实体指代替换的脚本把文档里出现的核心实体按一定概率随机换成不同的指代说法故意打破AI这种绝对严谨的统一性。import random # 可以根据自己的文档内容扩展实体库 ENTITY_MAP { Redis缓存: [这个缓存组件, Redis, 我们用的缓存服务, 之前搭的缓存实例], 分布式锁: [锁机制, 集群互斥方案, 这个锁, 全局锁实现], 异步队列: [消息队列, 异步任务组件, 队列服务, 我们搭的MQ] } def replace_entity_reference(text: str) - str: last_used {} for standard, variants in ENTITY_MAP.items(): last_used[standard] variants[0] parts text.split(standard) new_parts [parts[0]] for p in parts[1:]: # 70%概率不用上一次用过的指代避免规律性 if random.random() 0.7: candidates [v for v in variants if v ! last_used[standard]] cur random.choice(candidates) if candidates else variants[0] else: cur last_used[standard] last_used[standard] cur new_parts.append(cur p) text .join(new_parts) return text跑过这个脚本之后我那篇内容的AI占比直接从72%掉到了41%已经到了低风险区间。 但到这步还没完机器脚本生成的调整还是太有规律最后要补几处人工操作的细节完全模拟真人写东西的状态。 比如你可以在文档里插1~2处完全和当前技术点无关的小吐槽比如写着写着插一句“上周踩过这个场景的坑改到凌晨三点才回家”完全是真人随性加的内容AI绝对不会主动生成这种无意义的插话。 还可以故意留1处无伤大雅的小笔误比如把某个方法名拼错一个字母后面跟着括号补一句“哦这里手滑了正确写法应该是xxx”这种小疏漏也是AI输出内容里几乎不会出现的。改写完之后我习惯性地丢到团象AI检测里跑一遍确认检测率降到阈值以下再往下走。 我之前试过拿纯AI生成的2000字技术文档做对照测试原始AI率94%只跑分句打乱脚本到72%跑完实体替换脚本到41%最后加3处人工的小插话和小笔误最终测出来AI率是17%完全过了内部平台的阈值。不少人图省事直接把AI生成的内容丢给另一个大模型让它重写一遍以为这样就能蒙混过关完全是想多了。 不管你换什么大模型重写输出的内容本质上还是在大模型的训练集分布里token衔接的概率特征根本没有变很多时候重写之后的AI检测率反而更高纯纯做无用功。 之前还有同行跟我说直接在内容里插一堆乱码字符藏在页面看不见的地方用来干扰检测这种方案现在早就被检测平台堵死了只要识别到有隐藏字符直接判定最高风险碰都别碰。其实回头看最开始的问题自己改能降低 AI 率吗答案是肯定的但前提是你改的点刚好命中了检测模型抓的核心特征而不是做一些替换同义词的表面功夫。 我这段时间测下来这种方法只对纯自然语言的技术文档、方案报告有效纯代码内容根本不需要这么折腾代码本身的token分布和自然语言差异极大很少会被判定为高AI占比反而你要是瞎改变量名调整逻辑很容易引入莫名其妙的bug完全得不偿失。昨天组里新来的实习生还找我要这两个脚本说他自己改了一下午的答辩材料越改检测率越高刚才抽了两分钟给他演示了一遍操作流程把脚本发过去了等下看看他那边的实测结果咋样。