这次 Semafor 发布的调查结果比大多数 AI 讨论都有意思他们抽查了 310 篇专栏文章发现其中 50 篇带有明显的 AI 痕迹占比大约 16.1%。也就是说在面向公众发布的正式专栏里每 6 篇中就有 1 篇可能经过 AI 辅助写作或局部生成。这个数字不是某个实验室跑出来的基准测试而是对真实内容平台的一次抽样。坦白讲这个比例比很多人预想的高。专栏通常有编辑审核、事实核查和风格要求即便如此 AI 痕迹依然出现在六分之一的文章中。这说明以 ChatGPT、Claude、文心一言、Kimi 为代表的写作辅助工具已经实质渗透进内容生产流程而不是停留在“试用阶段”。这篇博客不打算只做新闻转述。我尝试把事情拆开看AI 痕迹检测到底是怎么工作的哪些信号会被判定为“AI 痕迹”如果你想自己复现类似调查应该设计怎样的检测流程以及最关键的——这个 16.1% 的数字能不能说明专栏内容“作弊”了文章会覆盖检测原理、常用工具、批量检测方案、常见误判场景以及内容团队使用 AI 工具时的合规边界。适合内容平台运营、编辑、AI 应用开发者以及任何关心“哪些文章是 AI 写的”这件事的人。1. 核心事实速览先把这次调查的基本信息列出来。需要说明的是Semafor 的原始调查没有公开全部检测工具、模型阈值和抽样方法所以表格里只放有明确依据的事实其余用“未知/需确认”标注。调查维度说明调查发起方Semafor 媒体关注媒体行业与 AI 交叉议题样本规模310 篇已发表专栏文章检测结果50 篇含 AI 痕迹占比约 16.1%检测工具材料未公开可能是商业检测器或人工审核组合判定标准未公开通常指文本具有 AI 生成特征的概率较高“AI 痕迹”含义可能是整段生成、局部改写、翻译拼接或提示词残留是否等于违规不等于。是否违规取决于平台规则和披露政策结论倾向说明 AI 辅助写作在正式内容中已经普遍存在这个表格想说明两件事一是调查的样本量不算小51 篇带 AI 痕迹的专栏足以支撑“AI 已进入正式内容生产”的判断二是调查本身也有局限检测工具没有公开这意味着我们无法精确还原每一步结论。从技术角度看这个调查更像一次“行业体检”证明了 AI 内容检测在真实场景中是可操作的。310 篇的规模不算大却足以跑通一套检测流程文本采集、清洗、分段检测、结果归档、人工抽检。这套流程任何一个有 Python 基础的内容团队都能复现。2. 调查报告说明了什么先从数字说起。310 篇专栏50 篇含 AI 痕迹占比 16.1%。如果只看这个比例会得出“专栏作者们都在偷偷用 AI”的结论。但更准确的解读是AI 辅助写作已经进入正常的内容生产流程且很多平台尚未形成统一的披露机制。为什么这么说因为 “AI 痕迹”并不是“AI 生成”的同义词。一篇带 AI 痕迹的文章可能经历了以下几种情况作者用 AI 做资料整理之后人工润色但某些段落保留了模型惯用的总结句式。作者让 AI 生成开头或提纲后续内容全部人工撰写但开头段仍带有生成特征。作者用 AI 翻译外文素材译稿保留了生成式翻译的典型表达。作者直接复制了大段 AI 输出到文章中未经深度修改。这些情况在专栏写作中都很常见。尤其是资料整理、翻译辅助、标题生成编辑们大多数时候并不是在“用 AI 代笔”而是在“用 AI 当实习生”。但问题在于目前很多平台没有要求标注“AI 辅助”的使用痕迹。读者默认专栏是人工写作。当 16.1% 的专栏被检测出 AI 痕迹时信任问题就产生了。这未必是作者主观造假而是“使用了 AI 却未说明”这个行为本身在内容伦理上是不足的。所以这次调查的真正价值不是“抓出 50 个作弊者”而是给媒体行业和内容平台提了个醒AI 辅助写作比例已经足够高继续沿用“不披露、不标注、不检测”的旧规则迟早会出问题。对技术从业者来说这则调查还释放了另一个信号AI 检测服务不是学术界的自嗨媒体、教育、广告、出版行业都在酝酿真实需求。能接住这个需求的人不管是做产品还是做流程优化都有机会。3. AI 痕迹检测的基本原理不管用什么工具AI 文本检测的基本思路都可以归为四类。日常见到的检测服务本质上是把它们组合起来。3.1 统计特征困惑度与突发度困惑度Perplexity是语言模型对文本“意外程度”的估计。人类写作时用词选择更多样句子长度波动更剧烈因此困惑度通常更高。大模型生成文本时每一步都在选择概率最高的词整篇读下来非常“顺”困惑度反而偏低。突发度Burstiness衡量的是句子长度和结构的波动。人类写作者会自然地在长句、短句之间切换段落节奏忽快忽慢而大模型倾向于生成节奏均匀的文本短句连短句、长句连长句缺少人类写作中常见的不规则起伏。以 GPT 系列为代表的生成文本普遍是“低困惑度 低突发度”的组合。检测工具拿到一段文本后会先计算这两个统计值再对比大量人类文本的特征分布给出一个“AI 生成概率”。这个方法是大多数免费检测器的底层逻辑实现成本低对英文长文本效果尚可但对短文本、改写过的文本可靠性会显著下降。3.2 模式识别重复结构、连接词与“AI 腔”大模型在中文文本中很容易留下固定的语言习惯。比如高频使用“首先”“其次”“总的来说”或者“值得注意的是”“在当今数字化时代”这类万能起手式。检测工具会训练一个分类器专门学习 AI 生成文本中的重复短语、过渡句式和段落模板。这种模式包括段落长度过于均匀几乎每段都是 3 到 5 行。排比句使用频繁结构对称性强。总结段总是用“综上所述”“总而言之”开头。缺少口语化断句没有作者的个人语气起伏。这类模式在人工阅读时也能发现但检测工具的优势在于它可以快速扫描大批量文章把疑似文本挑出来供人工复核。3.3 分类器模型监督学习判断商业工具如 GPTZero、Originality.ai、Turnitin 等通常会训练专门的二分类模型。训练数据包含大量人工撰写的文本和多种大模型生成的文本模型会学习二者在词汇、句法、语义层面的细微差异然后对输入文本打分。分类器模型的优点是能捕捉到统计方法发现不了的隐藏特征缺点是训练数据有天花板。如果某篇 AI 生成的文本来自模型没见过的提示词风格分类器可能会给出完全错误的判断。3.4 元数据与外部证据除了文本本身检测流程还可以结合文章的发布时间、修改记录、作者历史风格来辅助判断。如果作者过去五年都是长难句风格某篇文章突然变得整齐、简洁、结构化那即使检测器给 50% 的概率人工复核也该把它列入嫌疑名单。从这些原理可以看出没有任何一种检测方法是绝对可靠的。16.1% 这个数字真正的含义是“检测工具认为有 AI 痕迹”而不是“确定是 AI 写的”。理解这一点后面才好设计检测流程和判断标准。4. 常见 AI 写作检测工具与能力参考如果你不打算自己训练分类器直接用现成的 AI 检测服务会更高效。目前市面上常见的检测工具包括 GPTZero、Originality.ai、Turnitin、Copyleaks、Sapling AI Detector以及国内平台提供的 AI 内容检测能力。下表列出的是这些工具常见的功能方向不涉及具体版本和准确率——检测工具的准确率高度依赖文本语言、长度和改写程度必须实测。工具类型主要能力适合规模注意事项GPTZero句子级打分、概率展示单篇测试、教学场景对英文效果好中文效果需实测Originality.ai批量扫描、内容管理内容团队批量检测收费工具需自行调研Turnitin学术界常用含 AI 检测学术论文、作业对中英文论文场景有针对性优化Copyleaks多语言检测中英文均可测试没有公开详细算法需实测国内大模型自带检测部分平台提供文本“AI 味”分析中文内容团队各家标准不同输出可能不稳定需要强调的是不要依赖单一检测工具的评分作为唯一依据。不同工具对同一篇文章的判断可能相差 20 个百分点以上我见过同一段文字在工具 A 被判 85% AI、在工具 B 被判 30% 的情况。更合理的做法是多个工具交叉验证 人工复核。如果你面对的是海量文章比如要检测一个网站的几百篇专栏纯手工逐篇上传效率太低。下一节会给出可复现的本地检测流程和批量处理脚本帮你把这套流程自动化。5. 复现调查思路的检测流程设计假设你想模仿 Semafor 的调查方法在自己负责的内容库或公开网页上跑一次 AI 痕迹扫描可以按下面的流程来设计。5.1 整体流程检测流程可以拆成六个阶段数据采集、文本抽取与清洗、分段处理、检测调用、结果归档、人工复核。阶段输入输出关键动作数据采集文章 URL 列表原始 HTML批量抓取正文页面文本抽取HTML 文件纯文本去除导航、页脚、广告、标签分段处理长文纯文本文本片段按 300 到 500 字切片保留段落结构检测调用文本片段检测分值调用检测 API 或本地模型结果归档检测分值JSON / CSV记录每篇文章的得分分布人工复核高分文本最终结论检查上下文、作者风格、疑似段落这个流程是通用设计不依赖某个特定检测服务。你可以把“检测调用”这一步替换成任何工具包括国产大模型平台、商业检测 API或者本地部署的开源检测模型。5.2 数据采集与文本清洗采集网页正文时不推荐直接整页保存后去解析 HTML因为会混入导航、推荐阅读、广告等噪声。更稳妥的方案是使用可编程的浏览器自动化工具加载页面再抽取正文节点。一个 Python 清洗脚本的通用模板如下import re from bs4 import BeautifulSoup def extract_article_text(html_content: str) - str: soup BeautifulSoup(html_content, html.parser) # 移除脚本、样式、导航、页脚等非正文节点 for tag in soup([script, style, nav, header, footer, aside]): tag.decompose() # 优先尝试 article 节点找不到可用体退出 article soup.find(article) or soup.find(body) text article.get_text(separator\n) if article else # 压缩连续空行去掉多余空白字符 text re.sub(r\n{3,}, \n\n, text) text re.sub(r[ \t], , text) return text.strip()这个脚本的核心价值是生成干净的正文文本避免把“评论区的 AI 痕迹”跟正文混在一起。处理完清洗再进入分段检测。5.3 分段检测策略大部分检测 API 对输入长度有上限短文本检测又容易出现统计波动。常见做法是把一篇 2000 字的文章按段落聚合成 300 到 500 字的片段逐段检测最后取整篇文章的平均分或最高分。分段时要避免把一句话拆成两半最好按照段落边界来聚合def split_text_for_detection(text: str, max_chars: int 500): paragraphs [p.strip() for p in text.split(\n) if p.strip()] chunks [] current for para in paragraphs: if len(current) len(para) max_chars and current: chunks.append(current) current para else: current \n para if current: chunks.append(current) return chunks用这个函数处理之后每篇文章会得到若干个文本块。接下来把这些文本块依次发给检测服务把返回的分数按片段顺序记录下来。5.4 判断标准设置检测完成后建议先不要急着定“是否 AI 生成”。因为检测服务的分数是连续值直接做二分类会误伤很多边界样本。比较稳健的判断方法是90 分以上明确存在 AI 生成痕迹进入人工复核。70 到 89 分可能存在 AI 辅助改写需要结合作者背景确认。50 到 69 分不确定可以抽检。50 分以下大概率人工撰写可以跳过人工复核。这样设定可以减少把“人类写的工整文本”误判为 AI 的几率。16.1% 这个比例的最终确认也应该建立在人工复核之后而不是只靠工具打分。6. 接口调用与批量任务示例如果你已经选定了一个检测服务无论是商业 API 还是内部部署模型下一步就是把检测接入自动化流程。下面给出通用的接口调用示例具体 URL 和参数以你的实际服务文档为准。6.1 curl 调用示例以本地或云端服务提供文本检测接口为例curl -X POST https://your-detection-api.example.com/detect \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d { text: 这是一段需要检测的示例文本注意这里可能存在 AI 生成的表达模式。, language: zh }需要注意实际的检测服务不可能恰好叫your-detection-api.example.com请求路径和鉴权方式也不同。使用前先读一遍服务商的 API 文档确认鉴权字段、限流策略和最大请求长度。6.2 Python 批量检测脚本对内容团队来说最实用的场景不是单篇检测而是批量处理整个文章目录。下面是一个批量任务脚本的通用模板import os import time import json import requests from pathlib import Path API_URL https://your-detection-api.example.com/detect API_KEY your-api-key input_dir Path(./articles) output_file Path(./detection_results.jsonl) results [] for article_path in sorted(input_dir.glob(*.txt)): text article_path.read_text(encodingutf-8) chunks split_text_for_detection(text) scores [] for idx, chunk in enumerate(chunks): response requests.post( API_URL, headers{Authorization: fBearer {API_KEY}}, json{text: chunk, language: zh}, timeout60, ) if response.status_code 200: score response.json().get(ai_probability, 0) scores.append({chunk_index: idx, score: score}) else: scores.append({chunk_index: idx, score: None, error: response.status_code}) # 控制请求频率避免触发限流 time.sleep(0.5) avg_score None valid_scores [s[score] for s in scores if s[score] is not None] if valid_scores: avg_score sum(valid_scores) / len(valid_scores) results.append({ file: article_path.name, average_score: avg_score, max_score: max(valid_scores, defaultNone), chunks: scores, }) with open(output_file, w, encodingutf-8) as f: for item in results: f.write(json.dumps(item, ensure_asciiFalse) \n)这个脚本把整个articles目录的文章逐篇读入切分后请求检测接口把每篇文章的平均分、最高分和分片结果写入 JSONL 文件方便后续分析。用jsonl而不是json的原因很简单批量任务可能执行到一半失败如果中途进程退出已经写入的每一行仍然保留不会丢全部结果。6.3 批量结果汇总与分布统计检测完成后还需要一次结果聚合成表格import pandas as pd records [] with open(detection_results.jsonl, r, encodingutf-8) as f: for line in f: records.append(json.loads(line)) df pd.DataFrame(records) # 按平均分区间统计占比 bins [0, 50, 70, 90, 100] labels [0-50, 50-70, 70-90, 90-100] df[score_bin] pd.cut(df[average_score], binsbins, labelslabels, rightFalse) print(df[score_bin].value_counts().sort_index())这样就能得到类似调查结论的数据多少比例的文章平均分低于 50多少比例超过 90从而形成报告基础。7. AI 痕迹检测的局限与争议检测结果不能直接等同于“文章造假”这是整个调查里最容易产生误读的部分。AI 痕迹检测本身至少存在三类局限。7.1 误判人类写手常年被误伤有些人类作者写作习惯非常规律用词规范、逻辑严密、句子长度均匀这跟大模型的统计特征高度重合。检测工具给这类作者打高分是常见现象。尤其是翻译腔严重的文章、政府公文式写作、产品说明文档这些文本本身就有很强的模板化倾向被误判率很高。如果内容团队把检测分数直接当作 KPI就会误伤一批正常作者。7.2 改写与伪装的对抗AI 生成的文本一旦经过人类二次改写、换词、打乱段落结构检测器效果会明显下降。这并不是“降 AI 率工具”的功劳——人类润色本来就是内容生产的一环。理论上写手可以先让 AI 生成草稿再人工润色 10 分钟检测器就可能看不出明显痕迹。这个局限意味着检测工具只能发现“偷懒的 AI 使用”很难发现“认真的人工加工”。所以更合理的目标不是“检测所有 AI 文本”而是“发现明显的、未经加工的 AI 生成痕迹”。7.3 中英文检测效果差异明显大多数知名 AI 检测服务都在英文语料上训练迁移到中文场景时准确率和稳定性都可能下降。中文的语法灵活度、成语使用、四字结构都跟英文有本质差异直接套用英文检测器经常会给出偏高或偏低的分数。如果你想做中文内容的批量检测更可靠的路径是先用自己的历史文章集合做一次基准测试观察检测工具对“确定人工写作”的中文内容的评分分布确认基线之后再去检测不清楚来源的文章。8. 从检测到治理内容生产者的合规使用建议检测不是目的治理才是。面对“310 篇专栏中 50 篇含 AI 痕迹”这类调查结果内容平台、企业和个人作者都应该重新审视 AI 辅助写作的边界。8.1 使用 AI 辅助写作时的几条底线涉及事实、数据、引用的内容必须由人工核实来源不能直接信 AI 输出。涉及肖像、声音、署名文章的大段生成内容要取得明确授权和许可。在需要“人工撰写”承诺的栏目中不应未经披露就直接投用大段 AI 生成内容。对读者公开的规范内容建议在显著位置标注“本文使用 AI 辅助整理资料”或“AI 生成并人工审核”避免事后被调查。这些不是空泛的合规口号而是从 Semafor 这次调查中能直接推导出来的现实问题16.1% 的比例说明 AI 已经进入正式内容生产。既然无法倒退就必须把规则定清楚。8.2 内容团队如何建立 AI 使用规范一个可落地的方案是把 AI 使用分成三个等级等级使用方式是否需要标注风险L1仅用于头脑风暴、标题建议、资料收集可不标注低L2辅助生成摘要、扩写、缩写、翻译建议标注中L3整段或多段由 AI 直接生成后发布必须标注并需人工核查高团队内部按这个模式执行既能利用 AI 的生产效率又能把合规风险控制在可追溯范围。8.3 不要把检测工具当作品质判断工具AI 检测反映的是“文本的生成特征”不是“文章质量”。一篇检测得分 85 的文章可能结构清晰、事实准确、读起来非常有价值一篇纯人工手写的文章也可能逻辑混乱、观点偏颇。如果只按 AI 得分来删稿等于把编辑权交给了统计模型。正确的做法是检测作为“线索”辅助编辑找到需要复核的稿件最终是否采用、是否标注、是否下架由人工依据内容质量、平台规则和合规要求来判断。9. 常见问题与排查方法问题现象可能原因排查思路解决方案不同检测工具对同一篇文章打分差异大工具训练语料和算法不同对比多款工具的分数注意语言环境选择和你内容类型匹配的工具必要时多工具交叉取综合判断中文文章检测分数普遍偏高检测器训练语料以英文为主用历史人工文章建立中文基线先测 50 篇确定人工文章观察分数分布再定阈值检测服务调用返回 429 或超时触发限流或单次请求文本过长检查响应状态码确认请求体大小减少单次请求字数增加 sleep 间隔失败重试最多 3 次批量脚本中途失败结果丢失没有增量保存结果检查输出文件写入方式改为每篇检测完就写入 JSONL不等到最后统一写长文章分段后整篇得分偏低分段切碎了上下文模型特征不明显查看每段单独的分数而不是只看平均分对高分段落单独复核而不是只看整篇平均分人工写作被误判为 AI作者本身写作风格过于工整结合作者历史文章对比用作者历史文章作为参照而不是只看单篇绝对分数想要本地化检测但显存不足大模型检测器显存要求较高查看本地模型是否支持 CPU 推理优先走云端 API本地部署时测试低显存量化版本10. 总结与下一步这次 Semafor 调查最大的价值是证实了 AI 辅助写作在正式内容平台中的渗透率已经不是小数。310 篇专栏、50 篇含 AI 痕迹这个比例足以让每个内容团队重新考虑编辑流程中是否应该加入 AI 痕迹检测平台上是否应该要求作者披露 AI 使用情况如果你在内容平台工作建议先做三件事第一在最早发布的一批历史文章中抽样检测看自己的内容库基线是多少第二用多款检测工具交叉验证结合人工复核确定合理阈值第三把 AI 使用规范写进作者手册明确什么场景需要标注、什么场景禁止使用。如果你是一名开发者可以考虑做这样的自动化工具抓取指定网站的文章列表自动完成文本清洗、分段、检测、汇总最终输出一份类似“310 篇专栏中 50 篇含 AI 痕迹”的报告。这个工作流本身就有实际商业价值媒体监测、舆情分析、内容风控都会用到。最容易踩的坑是迷信单一检测器并且把分数直接用于“定罪”。检测结果的正确用法是缩小人工复核范围而不是替代人工判断。下一步值得探索的方向包括针对中文内容微调的检测模型、结合写作风格历史特征的个性化判断、以及检测结果的可解释性报告。毕竟当 16.1% 的比例出现之后行业需要的不是一款“最终判决工具”而是一套经得起质疑的检测与复核流程。 AI痕迹检测原理与批量检测流程：从16.1%渗透率看内容生产新常态
这次 Semafor 发布的调查结果比大多数 AI 讨论都有意思他们抽查了 310 篇专栏文章发现其中 50 篇带有明显的 AI 痕迹占比大约 16.1%。也就是说在面向公众发布的正式专栏里每 6 篇中就有 1 篇可能经过 AI 辅助写作或局部生成。这个数字不是某个实验室跑出来的基准测试而是对真实内容平台的一次抽样。坦白讲这个比例比很多人预想的高。专栏通常有编辑审核、事实核查和风格要求即便如此 AI 痕迹依然出现在六分之一的文章中。这说明以 ChatGPT、Claude、文心一言、Kimi 为代表的写作辅助工具已经实质渗透进内容生产流程而不是停留在“试用阶段”。这篇博客不打算只做新闻转述。我尝试把事情拆开看AI 痕迹检测到底是怎么工作的哪些信号会被判定为“AI 痕迹”如果你想自己复现类似调查应该设计怎样的检测流程以及最关键的——这个 16.1% 的数字能不能说明专栏内容“作弊”了文章会覆盖检测原理、常用工具、批量检测方案、常见误判场景以及内容团队使用 AI 工具时的合规边界。适合内容平台运营、编辑、AI 应用开发者以及任何关心“哪些文章是 AI 写的”这件事的人。1. 核心事实速览先把这次调查的基本信息列出来。需要说明的是Semafor 的原始调查没有公开全部检测工具、模型阈值和抽样方法所以表格里只放有明确依据的事实其余用“未知/需确认”标注。调查维度说明调查发起方Semafor 媒体关注媒体行业与 AI 交叉议题样本规模310 篇已发表专栏文章检测结果50 篇含 AI 痕迹占比约 16.1%检测工具材料未公开可能是商业检测器或人工审核组合判定标准未公开通常指文本具有 AI 生成特征的概率较高“AI 痕迹”含义可能是整段生成、局部改写、翻译拼接或提示词残留是否等于违规不等于。是否违规取决于平台规则和披露政策结论倾向说明 AI 辅助写作在正式内容中已经普遍存在这个表格想说明两件事一是调查的样本量不算小51 篇带 AI 痕迹的专栏足以支撑“AI 已进入正式内容生产”的判断二是调查本身也有局限检测工具没有公开这意味着我们无法精确还原每一步结论。从技术角度看这个调查更像一次“行业体检”证明了 AI 内容检测在真实场景中是可操作的。310 篇的规模不算大却足以跑通一套检测流程文本采集、清洗、分段检测、结果归档、人工抽检。这套流程任何一个有 Python 基础的内容团队都能复现。2. 调查报告说明了什么先从数字说起。310 篇专栏50 篇含 AI 痕迹占比 16.1%。如果只看这个比例会得出“专栏作者们都在偷偷用 AI”的结论。但更准确的解读是AI 辅助写作已经进入正常的内容生产流程且很多平台尚未形成统一的披露机制。为什么这么说因为 “AI 痕迹”并不是“AI 生成”的同义词。一篇带 AI 痕迹的文章可能经历了以下几种情况作者用 AI 做资料整理之后人工润色但某些段落保留了模型惯用的总结句式。作者让 AI 生成开头或提纲后续内容全部人工撰写但开头段仍带有生成特征。作者用 AI 翻译外文素材译稿保留了生成式翻译的典型表达。作者直接复制了大段 AI 输出到文章中未经深度修改。这些情况在专栏写作中都很常见。尤其是资料整理、翻译辅助、标题生成编辑们大多数时候并不是在“用 AI 代笔”而是在“用 AI 当实习生”。但问题在于目前很多平台没有要求标注“AI 辅助”的使用痕迹。读者默认专栏是人工写作。当 16.1% 的专栏被检测出 AI 痕迹时信任问题就产生了。这未必是作者主观造假而是“使用了 AI 却未说明”这个行为本身在内容伦理上是不足的。所以这次调查的真正价值不是“抓出 50 个作弊者”而是给媒体行业和内容平台提了个醒AI 辅助写作比例已经足够高继续沿用“不披露、不标注、不检测”的旧规则迟早会出问题。对技术从业者来说这则调查还释放了另一个信号AI 检测服务不是学术界的自嗨媒体、教育、广告、出版行业都在酝酿真实需求。能接住这个需求的人不管是做产品还是做流程优化都有机会。3. AI 痕迹检测的基本原理不管用什么工具AI 文本检测的基本思路都可以归为四类。日常见到的检测服务本质上是把它们组合起来。3.1 统计特征困惑度与突发度困惑度Perplexity是语言模型对文本“意外程度”的估计。人类写作时用词选择更多样句子长度波动更剧烈因此困惑度通常更高。大模型生成文本时每一步都在选择概率最高的词整篇读下来非常“顺”困惑度反而偏低。突发度Burstiness衡量的是句子长度和结构的波动。人类写作者会自然地在长句、短句之间切换段落节奏忽快忽慢而大模型倾向于生成节奏均匀的文本短句连短句、长句连长句缺少人类写作中常见的不规则起伏。以 GPT 系列为代表的生成文本普遍是“低困惑度 低突发度”的组合。检测工具拿到一段文本后会先计算这两个统计值再对比大量人类文本的特征分布给出一个“AI 生成概率”。这个方法是大多数免费检测器的底层逻辑实现成本低对英文长文本效果尚可但对短文本、改写过的文本可靠性会显著下降。3.2 模式识别重复结构、连接词与“AI 腔”大模型在中文文本中很容易留下固定的语言习惯。比如高频使用“首先”“其次”“总的来说”或者“值得注意的是”“在当今数字化时代”这类万能起手式。检测工具会训练一个分类器专门学习 AI 生成文本中的重复短语、过渡句式和段落模板。这种模式包括段落长度过于均匀几乎每段都是 3 到 5 行。排比句使用频繁结构对称性强。总结段总是用“综上所述”“总而言之”开头。缺少口语化断句没有作者的个人语气起伏。这类模式在人工阅读时也能发现但检测工具的优势在于它可以快速扫描大批量文章把疑似文本挑出来供人工复核。3.3 分类器模型监督学习判断商业工具如 GPTZero、Originality.ai、Turnitin 等通常会训练专门的二分类模型。训练数据包含大量人工撰写的文本和多种大模型生成的文本模型会学习二者在词汇、句法、语义层面的细微差异然后对输入文本打分。分类器模型的优点是能捕捉到统计方法发现不了的隐藏特征缺点是训练数据有天花板。如果某篇 AI 生成的文本来自模型没见过的提示词风格分类器可能会给出完全错误的判断。3.4 元数据与外部证据除了文本本身检测流程还可以结合文章的发布时间、修改记录、作者历史风格来辅助判断。如果作者过去五年都是长难句风格某篇文章突然变得整齐、简洁、结构化那即使检测器给 50% 的概率人工复核也该把它列入嫌疑名单。从这些原理可以看出没有任何一种检测方法是绝对可靠的。16.1% 这个数字真正的含义是“检测工具认为有 AI 痕迹”而不是“确定是 AI 写的”。理解这一点后面才好设计检测流程和判断标准。4. 常见 AI 写作检测工具与能力参考如果你不打算自己训练分类器直接用现成的 AI 检测服务会更高效。目前市面上常见的检测工具包括 GPTZero、Originality.ai、Turnitin、Copyleaks、Sapling AI Detector以及国内平台提供的 AI 内容检测能力。下表列出的是这些工具常见的功能方向不涉及具体版本和准确率——检测工具的准确率高度依赖文本语言、长度和改写程度必须实测。工具类型主要能力适合规模注意事项GPTZero句子级打分、概率展示单篇测试、教学场景对英文效果好中文效果需实测Originality.ai批量扫描、内容管理内容团队批量检测收费工具需自行调研Turnitin学术界常用含 AI 检测学术论文、作业对中英文论文场景有针对性优化Copyleaks多语言检测中英文均可测试没有公开详细算法需实测国内大模型自带检测部分平台提供文本“AI 味”分析中文内容团队各家标准不同输出可能不稳定需要强调的是不要依赖单一检测工具的评分作为唯一依据。不同工具对同一篇文章的判断可能相差 20 个百分点以上我见过同一段文字在工具 A 被判 85% AI、在工具 B 被判 30% 的情况。更合理的做法是多个工具交叉验证 人工复核。如果你面对的是海量文章比如要检测一个网站的几百篇专栏纯手工逐篇上传效率太低。下一节会给出可复现的本地检测流程和批量处理脚本帮你把这套流程自动化。5. 复现调查思路的检测流程设计假设你想模仿 Semafor 的调查方法在自己负责的内容库或公开网页上跑一次 AI 痕迹扫描可以按下面的流程来设计。5.1 整体流程检测流程可以拆成六个阶段数据采集、文本抽取与清洗、分段处理、检测调用、结果归档、人工复核。阶段输入输出关键动作数据采集文章 URL 列表原始 HTML批量抓取正文页面文本抽取HTML 文件纯文本去除导航、页脚、广告、标签分段处理长文纯文本文本片段按 300 到 500 字切片保留段落结构检测调用文本片段检测分值调用检测 API 或本地模型结果归档检测分值JSON / CSV记录每篇文章的得分分布人工复核高分文本最终结论检查上下文、作者风格、疑似段落这个流程是通用设计不依赖某个特定检测服务。你可以把“检测调用”这一步替换成任何工具包括国产大模型平台、商业检测 API或者本地部署的开源检测模型。5.2 数据采集与文本清洗采集网页正文时不推荐直接整页保存后去解析 HTML因为会混入导航、推荐阅读、广告等噪声。更稳妥的方案是使用可编程的浏览器自动化工具加载页面再抽取正文节点。一个 Python 清洗脚本的通用模板如下import re from bs4 import BeautifulSoup def extract_article_text(html_content: str) - str: soup BeautifulSoup(html_content, html.parser) # 移除脚本、样式、导航、页脚等非正文节点 for tag in soup([script, style, nav, header, footer, aside]): tag.decompose() # 优先尝试 article 节点找不到可用体退出 article soup.find(article) or soup.find(body) text article.get_text(separator\n) if article else # 压缩连续空行去掉多余空白字符 text re.sub(r\n{3,}, \n\n, text) text re.sub(r[ \t], , text) return text.strip()这个脚本的核心价值是生成干净的正文文本避免把“评论区的 AI 痕迹”跟正文混在一起。处理完清洗再进入分段检测。5.3 分段检测策略大部分检测 API 对输入长度有上限短文本检测又容易出现统计波动。常见做法是把一篇 2000 字的文章按段落聚合成 300 到 500 字的片段逐段检测最后取整篇文章的平均分或最高分。分段时要避免把一句话拆成两半最好按照段落边界来聚合def split_text_for_detection(text: str, max_chars: int 500): paragraphs [p.strip() for p in text.split(\n) if p.strip()] chunks [] current for para in paragraphs: if len(current) len(para) max_chars and current: chunks.append(current) current para else: current \n para if current: chunks.append(current) return chunks用这个函数处理之后每篇文章会得到若干个文本块。接下来把这些文本块依次发给检测服务把返回的分数按片段顺序记录下来。5.4 判断标准设置检测完成后建议先不要急着定“是否 AI 生成”。因为检测服务的分数是连续值直接做二分类会误伤很多边界样本。比较稳健的判断方法是90 分以上明确存在 AI 生成痕迹进入人工复核。70 到 89 分可能存在 AI 辅助改写需要结合作者背景确认。50 到 69 分不确定可以抽检。50 分以下大概率人工撰写可以跳过人工复核。这样设定可以减少把“人类写的工整文本”误判为 AI 的几率。16.1% 这个比例的最终确认也应该建立在人工复核之后而不是只靠工具打分。6. 接口调用与批量任务示例如果你已经选定了一个检测服务无论是商业 API 还是内部部署模型下一步就是把检测接入自动化流程。下面给出通用的接口调用示例具体 URL 和参数以你的实际服务文档为准。6.1 curl 调用示例以本地或云端服务提供文本检测接口为例curl -X POST https://your-detection-api.example.com/detect \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d { text: 这是一段需要检测的示例文本注意这里可能存在 AI 生成的表达模式。, language: zh }需要注意实际的检测服务不可能恰好叫your-detection-api.example.com请求路径和鉴权方式也不同。使用前先读一遍服务商的 API 文档确认鉴权字段、限流策略和最大请求长度。6.2 Python 批量检测脚本对内容团队来说最实用的场景不是单篇检测而是批量处理整个文章目录。下面是一个批量任务脚本的通用模板import os import time import json import requests from pathlib import Path API_URL https://your-detection-api.example.com/detect API_KEY your-api-key input_dir Path(./articles) output_file Path(./detection_results.jsonl) results [] for article_path in sorted(input_dir.glob(*.txt)): text article_path.read_text(encodingutf-8) chunks split_text_for_detection(text) scores [] for idx, chunk in enumerate(chunks): response requests.post( API_URL, headers{Authorization: fBearer {API_KEY}}, json{text: chunk, language: zh}, timeout60, ) if response.status_code 200: score response.json().get(ai_probability, 0) scores.append({chunk_index: idx, score: score}) else: scores.append({chunk_index: idx, score: None, error: response.status_code}) # 控制请求频率避免触发限流 time.sleep(0.5) avg_score None valid_scores [s[score] for s in scores if s[score] is not None] if valid_scores: avg_score sum(valid_scores) / len(valid_scores) results.append({ file: article_path.name, average_score: avg_score, max_score: max(valid_scores, defaultNone), chunks: scores, }) with open(output_file, w, encodingutf-8) as f: for item in results: f.write(json.dumps(item, ensure_asciiFalse) \n)这个脚本把整个articles目录的文章逐篇读入切分后请求检测接口把每篇文章的平均分、最高分和分片结果写入 JSONL 文件方便后续分析。用jsonl而不是json的原因很简单批量任务可能执行到一半失败如果中途进程退出已经写入的每一行仍然保留不会丢全部结果。6.3 批量结果汇总与分布统计检测完成后还需要一次结果聚合成表格import pandas as pd records [] with open(detection_results.jsonl, r, encodingutf-8) as f: for line in f: records.append(json.loads(line)) df pd.DataFrame(records) # 按平均分区间统计占比 bins [0, 50, 70, 90, 100] labels [0-50, 50-70, 70-90, 90-100] df[score_bin] pd.cut(df[average_score], binsbins, labelslabels, rightFalse) print(df[score_bin].value_counts().sort_index())这样就能得到类似调查结论的数据多少比例的文章平均分低于 50多少比例超过 90从而形成报告基础。7. AI 痕迹检测的局限与争议检测结果不能直接等同于“文章造假”这是整个调查里最容易产生误读的部分。AI 痕迹检测本身至少存在三类局限。7.1 误判人类写手常年被误伤有些人类作者写作习惯非常规律用词规范、逻辑严密、句子长度均匀这跟大模型的统计特征高度重合。检测工具给这类作者打高分是常见现象。尤其是翻译腔严重的文章、政府公文式写作、产品说明文档这些文本本身就有很强的模板化倾向被误判率很高。如果内容团队把检测分数直接当作 KPI就会误伤一批正常作者。7.2 改写与伪装的对抗AI 生成的文本一旦经过人类二次改写、换词、打乱段落结构检测器效果会明显下降。这并不是“降 AI 率工具”的功劳——人类润色本来就是内容生产的一环。理论上写手可以先让 AI 生成草稿再人工润色 10 分钟检测器就可能看不出明显痕迹。这个局限意味着检测工具只能发现“偷懒的 AI 使用”很难发现“认真的人工加工”。所以更合理的目标不是“检测所有 AI 文本”而是“发现明显的、未经加工的 AI 生成痕迹”。7.3 中英文检测效果差异明显大多数知名 AI 检测服务都在英文语料上训练迁移到中文场景时准确率和稳定性都可能下降。中文的语法灵活度、成语使用、四字结构都跟英文有本质差异直接套用英文检测器经常会给出偏高或偏低的分数。如果你想做中文内容的批量检测更可靠的路径是先用自己的历史文章集合做一次基准测试观察检测工具对“确定人工写作”的中文内容的评分分布确认基线之后再去检测不清楚来源的文章。8. 从检测到治理内容生产者的合规使用建议检测不是目的治理才是。面对“310 篇专栏中 50 篇含 AI 痕迹”这类调查结果内容平台、企业和个人作者都应该重新审视 AI 辅助写作的边界。8.1 使用 AI 辅助写作时的几条底线涉及事实、数据、引用的内容必须由人工核实来源不能直接信 AI 输出。涉及肖像、声音、署名文章的大段生成内容要取得明确授权和许可。在需要“人工撰写”承诺的栏目中不应未经披露就直接投用大段 AI 生成内容。对读者公开的规范内容建议在显著位置标注“本文使用 AI 辅助整理资料”或“AI 生成并人工审核”避免事后被调查。这些不是空泛的合规口号而是从 Semafor 这次调查中能直接推导出来的现实问题16.1% 的比例说明 AI 已经进入正式内容生产。既然无法倒退就必须把规则定清楚。8.2 内容团队如何建立 AI 使用规范一个可落地的方案是把 AI 使用分成三个等级等级使用方式是否需要标注风险L1仅用于头脑风暴、标题建议、资料收集可不标注低L2辅助生成摘要、扩写、缩写、翻译建议标注中L3整段或多段由 AI 直接生成后发布必须标注并需人工核查高团队内部按这个模式执行既能利用 AI 的生产效率又能把合规风险控制在可追溯范围。8.3 不要把检测工具当作品质判断工具AI 检测反映的是“文本的生成特征”不是“文章质量”。一篇检测得分 85 的文章可能结构清晰、事实准确、读起来非常有价值一篇纯人工手写的文章也可能逻辑混乱、观点偏颇。如果只按 AI 得分来删稿等于把编辑权交给了统计模型。正确的做法是检测作为“线索”辅助编辑找到需要复核的稿件最终是否采用、是否标注、是否下架由人工依据内容质量、平台规则和合规要求来判断。9. 常见问题与排查方法问题现象可能原因排查思路解决方案不同检测工具对同一篇文章打分差异大工具训练语料和算法不同对比多款工具的分数注意语言环境选择和你内容类型匹配的工具必要时多工具交叉取综合判断中文文章检测分数普遍偏高检测器训练语料以英文为主用历史人工文章建立中文基线先测 50 篇确定人工文章观察分数分布再定阈值检测服务调用返回 429 或超时触发限流或单次请求文本过长检查响应状态码确认请求体大小减少单次请求字数增加 sleep 间隔失败重试最多 3 次批量脚本中途失败结果丢失没有增量保存结果检查输出文件写入方式改为每篇检测完就写入 JSONL不等到最后统一写长文章分段后整篇得分偏低分段切碎了上下文模型特征不明显查看每段单独的分数而不是只看平均分对高分段落单独复核而不是只看整篇平均分人工写作被误判为 AI作者本身写作风格过于工整结合作者历史文章对比用作者历史文章作为参照而不是只看单篇绝对分数想要本地化检测但显存不足大模型检测器显存要求较高查看本地模型是否支持 CPU 推理优先走云端 API本地部署时测试低显存量化版本10. 总结与下一步这次 Semafor 调查最大的价值是证实了 AI 辅助写作在正式内容平台中的渗透率已经不是小数。310 篇专栏、50 篇含 AI 痕迹这个比例足以让每个内容团队重新考虑编辑流程中是否应该加入 AI 痕迹检测平台上是否应该要求作者披露 AI 使用情况如果你在内容平台工作建议先做三件事第一在最早发布的一批历史文章中抽样检测看自己的内容库基线是多少第二用多款检测工具交叉验证结合人工复核确定合理阈值第三把 AI 使用规范写进作者手册明确什么场景需要标注、什么场景禁止使用。如果你是一名开发者可以考虑做这样的自动化工具抓取指定网站的文章列表自动完成文本清洗、分段、检测、汇总最终输出一份类似“310 篇专栏中 50 篇含 AI 痕迹”的报告。这个工作流本身就有实际商业价值媒体监测、舆情分析、内容风控都会用到。最容易踩的坑是迷信单一检测器并且把分数直接用于“定罪”。检测结果的正确用法是缩小人工复核范围而不是替代人工判断。下一步值得探索的方向包括针对中文内容微调的检测模型、结合写作风格历史特征的个性化判断、以及检测结果的可解释性报告。毕竟当 16.1% 的比例出现之后行业需要的不是一款“最终判决工具”而是一套经得起质疑的检测与复核流程。