AI生成文本检测实战：破折号并非指纹，概率特征与本地部署指南

如果你最近在刷社交媒体，一定看过一条判断 AI 文本的“铁律”：出现长破折号（em dash）就是 AI 写的。这条经验流传了很久，但这期视频标题直接否定了它——真正暴露 AI 生成文本的，往往不是最显眼的标点符号。破折号只是最容易被人记住的表象，把“— ”替换成“，”只需要一个正则，AI 文本马上就不符合这个“特征”。真正让 AI 文本露馅的，是结构层面的概率特征：一段序列是模型逐个 token 生成的，还是人一个字一个字写出来的，会在困惑度、突发性、词汇分布、句式重复度上留下痕迹。这就是 AI 生成文本检测的核心逻辑。

这篇文章把话题展开成一篇可落地的技术笔记。会先讲 AI 文本检测任务的规格和适用边界；然后解释为什么破折号不是可靠指纹；接着给出一套通用的环境准备和本地部署思路；再用几段示例代码演示特征统计、分类模型和批量任务；最后整理资源占用、问题排查和工程化建议。无论你是做内容审核、学术诚信初筛，还是想给自己的 AI 应用加一道文本合规过滤器，都可以照着做。

先说明一点：本文不承诺任何一种工具能 100% 识别 AI 文本，也不会教你如何制作“降 AI 率”的逃避工具。检测结果始终是辅助信号，不是最终判决。下面进入正题。

1. 核心能力速览

先给一张规格表。这不是某个商业工具的广告参数，而是 AI 生成文本检测方案最常见的能力边界。

这个表格是给整体方案定位用的。实际项目里，你可能会遇到三类工具：

• 纯规则脚本：统计破折号、高频词、句长分布，轻量但容易被绕过。
• 基于语言模型的分类器：用 RoBERTa、DeBERTa 等模型判断 Real/Fake，准确率更高，但需要模型文件和推理资源。
• 在线 SaaS：提供网页或 API，使用简单，但要考虑数据隐私和成本。

从工程实践看，比较合理的做法是“规则快速筛查 + 模型二次判断”。规则部分负责把明显异常的文本挑出来，模型部分负责给出概率分，最后再由人工复核。这个流程可以嵌到内容审核、文档管理、AI 应用后台等场景里。

2. 为什么“破折号”不是 AI 文本的指纹

很多检测技巧喜欢拿标点说事，比如“AI 喜欢用破折号”“AI 偏爱冒号”。这些观察确实有统计依据，但把它们当成硬性特征是很危险的。

先说破折号。大语言模型在训练语料里确实看到了大量英文科技写作和营销文本，这些文本里长破折号出现频率不低。模型在生成时也会模仿这种风格，于是一段时间里，“检测 AI 文本”变成了“检测破折号”。但问题在于，破折号是最容易被后处理去掉的特征。普通用户可能手动删掉，自动化工序可以用一个正则替换成逗号或句号。删完之后，文本内容几乎不变，但“标点特征”失效了。

更本质的问题是：什么是 AI 生成文本的本质特征？语言模型按概率逐 token 生成，模型会倾向于选择它认为“最自然”的下一个词。因此一段 AI 生成文本整体上更平滑、更符合统计规律、更难出现让人意外的用词。人类写作者则不同，我们会在不同语境里突然改变节奏，会不经意重复某个口头禅，也会写出语法上不完美但信息量大的句子。这些差异不是某个标点能概括的，而是整个序列的概率分布差异。

用技术语言说，有三个方面值得关注：

1. 困惑度（Perplexity）。用一个语言模型计算目标文本的困惑度，AI 生成文本通常困惑度较低，因为模型生成时就是在最大化概率；人类写作的用词更难预测，困惑度通常更高。
2. 突发性（Burstiness）。人类文本中罕见词、长句、短句的分布更不均匀，会出现“突然冒出一个不常见的词”的情况；AI 文本的词汇选择和句子长度往往更平滑，突发性更低。
3. 重复与模板化。AI 在长文本里容易出现语义重复、固定的过渡句型、相似的并列结构。这种重复不是简单词语重复，而是深层模板重复，人工检查时可能不易发现，但 n-gram 统计和句法特征可以捕捉到。

所以，正确理解标题里的“Not Em Dashes”应该是：不要把检测系统建立在容易被抹掉的表面特征上，要建立在对文本产生机制的建模上。破折号可以作为辅助线索，但不应成为判断依据。

3. 适用场景与使用边界

AI 生成文本检测能用在很多地方，但边界也很清晰。

适合的场景包括：

• 内容平台过滤低质量批量生成文。比如垃圾信息、低质营销稿，检测系统可以作为第一道筛选。
• 学术诚信初筛。论文、作业提交后，先用检测工具标出可疑段落，再由导师或评审人工确认。
• 编辑与小编辅助。判断来稿是否可能由 AI 生成，辅助选题和原创性评估。
• AI 应用合规。如果 Agent 或机器人产生面向用户的文本，可以在输出前加一道检测，避免无限制重复或模板化严重。
• 文本质量评估。检测模型返回的风险分可以当作文本多样性指标之一，接入内容生成链路做反馈。

不适合的场景更需要注意：

• 不能作为学术处分、法律纠纷的唯一证据。检测模型有误报率，一个真实的人类作者可能写出低困惑度、高重复度的文本，也可能被误判为 AI。
• 不能用于公开“挂人”。把检测结果截图发到公开平台，容易造成名誉风险。
• 不能训练一个“绕过检测”的工具。这不是技术做不到，而是应用场景很容易滑向学术造假和平台作弊，合规风险高。
• 涉及隐私数据时不能直接上传到第三方 SaaS。医疗、法律、商业机密类文本，应该在本地部署或做脱敏处理。

安全边界说白了就是：检测工具是辅助判断，不是裁决工具。前端可以提示“该文本包含 AI 生成内容特征”，但不能自动封号、不能直接定罪，必须保留人工复核链路。

4. 环境准备与前置条件

以本地部署文本检测服务为例，环境准备并不复杂。这个任务对硬件的需求远低于图像生成或视频生成。纯规则脚本用任何一个带 Python 的机器都能跑；加载一个 RoBERTa 分类器的显存需求通常不高，CPU 也能推理，只是批量时会慢一些。

推荐的环境清单如下：

• 操作系统：Windows 10/11、Ubuntu 20.04 或 macOS 12+ 均可。
• Python：建议 3.10 或 3.11，创建独立虚拟环境。
• 包管理：pip 即可。
• 深度学习框架：PyTorch。
• Transformers 库：用于加载分类模型。
• 可选 GPU：NVIDIA 独立显卡，需要安装对应 CUDA 驱动；没有 GPU 也能跑，性能要求用 CPU 凑合。
• 磁盘：模型文件一般几百 MB 到 2 GB 左右，加上依赖，预留 5 GB 比较保险。

如果之前没有配置过 Python 虚拟环境，先执行：

mkdir ai-text-detector && cd ai-text-detector python -m venv venv # Windows venv\Scripts\activate # Linux / macOS source venv/bin/activate

然后安装依赖：

pip install --upgrade pip pip install transformers torch pandas tqdm fastapi uvicorn pydantic

如果所在网络环境访问 Hugging Face 比较慢，可以配置镜像源，例如使用 HF 端点的镜像域名。这里只提示一句：不要在命令行里写死任何代理配置，直接修改环境变量是更安全的方式。

export HF_ENDPOINT=https://hf-mirror.com

这行命令在部分网络环境下可以加快模型下载，具体是否可用取决于你的网络环境。如果不需要，跳过即可。

5. 本地部署与启动方式

这里给出两套启动方式：一套是轻量规则脚本，另一套是深度学习分类器。先跑通规则脚本，再接入模型，排错会容易很多。

5.1 规则特征统计脚本

规则脚本的作用不是“判断 AI”，而是快速提取文本特征。你可以自己定义哪些信号值得关注。下面的示例会统计：长度、句子数、句长均值、句长方差、破折号数量、重复 n-gram 比例等。

import re import statistics from collections import Counter def split_sentences(text): # 简单按中英文句末标点切分 parts = re.split(r'[。！？!?\.]', text) return [p.strip() for p in parts if len(p.strip()) > 0] def get_ngrams(tokens, n=2): return list(zip(*[tokens[i:] for i in range(n)])) def text_features(text: str) -> dict: sentences = split_sentences(text) words = re.findall(r'\w+', text, flags=re.UNICODE) word_count = len(words) if word_count == 0: return { "word_count": 0, "sentence_count": 0, "mean_sentence_len": 0, "sentence_len_std": 0, "em_dash_count": 0, "repeat_bigram_ratio": 0, } sentence_lens = [len(re.findall(r'\w+', s, flags=re.UNICODE)) for s in sentences] mean_len = statistics.mean(sentence_lens) if sentence_lens else 0 std_len = statistics.stdev(sentence_lens) if len(sentence_lens) > 1 else 0.0 bigrams = list(get_ngrams(words, 2)) repeat_ratio = 0.0 if bigrams: counter = Counter(bigrams) total = len(bigrams) repeat_count = sum(1 for c in counter.values() if c > 1) repeat_ratio = repeat_count / total return { "word_count": word_count, "sentence_count": len(sentences), "mean_sentence_len": round(mean_len, 2), "sentence_len_std": round(std_len, 2), "em_dash_count": text.count("—"), "repeat_bigram_ratio": round(repeat_ratio, 4), } if __name__ == "__main__": sample = "这是一个测试句子。第一句话已经结束。第二句话的破折号——其实并不代表AI，只是文本特征之一。" print(text_features(sample))

运行脚本后，你会看到单词数、句子数、破折号数量、重复 bigram 比例等结果。这套特征并不能直接告诉你“是不是 AI”，但它是后续判断的基础。调试时，把已知的人工文本和 AI 文本分别跑一遍，对比特征差异，你会对“哪些信号在你的语料里有效”产生更直观的感受。

5.2 使用 Hugging Face 分类模型

规则脚本只能做辅助，主流做法是加载一个文本分类模型。这里以 Hugging Face 上的roberta-base-openai-detector为例，它是社区常用的 AI 文本检测模型之一。注意：模型仓库可能随政策变化下架，实际使用时先在 Hugging Face 搜索确认。

from transformers import pipeline detector = pipeline( "text-classification", model="roberta-base-openai-detector", truncation=True, max_length=512 ) def detect_with_model(text: str): result = detector(text)[0] return { "label": result["label"], "score": round(result["score"], 4) } if __name__ == "__main__": sample = "In this paper we explore the effects of language models on text generation." print(detect_with_model(sample))

这个 pipeline 会自动下载模型和分词器，第一次运行较慢，之后会走本地缓存。模型输出通常是Real或Fake，score表示置信度。要注意不同模型对label的语义可能相反，比如Real是人类写作还是真实文本，需要看模型卡片说明。

如果显存或内存不足，可以改用 CPU 推理，只需在 pipeline 中传入device=-1；如果 GPU 可用，传device=0。

detector = pipeline( "text-classification", model="roberta-base-openai-detector", device=-1, truncation=True, max_length=512 )

5.3 启动本地 Web 服务

模型跑通后，把它封装成 HTTP 服务会更方便。这里用 FastAPI 写一个最小服务，路由包括健康检查GET /health和检测接口POST /detect。

from fastapi import FastAPI from pydantic import BaseModel from transformers import pipeline app = FastAPI() detector = pipeline( "text-classification", model="roberta-base-openai-detector", truncation=True, max_length=512 ) class DetectRequest(BaseModel): text: str @app.get("/health") def health(): return {"status": "ok"} @app.post("/detect") def detect(req: DetectRequest): if not req.text.strip(): return {"label": "empty", "score": 0.0} result = detector(req.text)[0] return { "label": result["label"], "score": round(result["score"], 4) }

保存为app.py，然后启动：

uvicorn app:app --host 127.0.0.1 --port 8000

启动后，可以在浏览器打开http://127.0.0.1:8000/health确认服务存活。接下来用 curl 测试接口。

curl -X POST http://127.0.0.1:8000/detect \ -H "Content-Type: application/json" \ -d '{"text": "This is a sample text generated by an AI model or written by human."}'

返回结果会是一个 JSON：

{ "label": "Fake", "score": 0.9876 }

这里label的含义同样以模型卡片为准。如果你把服务部署在服务器上，记得修改监听地址和端口，并限制访问来源，避免未授权调用。

6. 功能测试与效果验证

本地部署完成后，先别急着接业务。花一点时间做功能测试，才能知道当前方案在你的语料上表现如何。

6.1 构造测试样本集

准备两组文本：

• 人工写作样本：你自己写一段技术说明、一段项目复盘，或者使用公开的人类写作语料。
• AI 生成样本：用大模型生成同一主题的短文，比如“什么是文本分类”“如何部署 API 服务”。

注意，测试样本不能只用破折号来区分。你可以在 AI 样本里手动删除所有破折号，看看检测模型是否仍然能识别。这个操作能直观验证“不是破折号在起作用”。

6.2 测试维度

建议至少覆盖以下维度：

• 短文本：一句话或几句话，模型可能因信息不足而摇摆。
• 长文本：数百字以上，观察模型是否能稳定输出。
• 中英文混合：如果业务语料是中文加英文，规则脚本和模型都要测试。
• 改写后的文本：把 AI 生成的文本手动改几个词、删除破折号、拆分长句，看检测结果是否变化。
• 正式文书类文本：例如公告、邮件、报告，这些文体本身风格接近 AI 输出，容易误报。

6.3 判断标准

不要只看单一条目的判定。正确做法是建立一个小规模标注集，比如 50 条已知来源的文本，然后统计：

• 真阳性率：AI 生成文本中被正确识别出的比例。
• 假阳性率：人类写作文本中被误判为 AI 的比例。
• 阈值影响：模型输出分数分布在哪里，选定 0.5 还是 0.7 作为阈值。

你可以把结果保存成 CSV，方便后续分析。

import csv from pathlib import Path def run_batch_test(input_dir: Path, output_csv: Path): rows = [] for txt_path in input_dir.glob("*.txt"): text = txt_path.read_text(encoding="utf-8") result = detect_with_model(text) rows.append({ "file": txt_path.name, "label": result["label"], "score": result["score"], "text_length": len(text), }) with output_csv.open("w", encoding="utf-8", newline="") as f: writer = csv.DictWriter(f, fieldnames=["file", "label", "score", "text_length"]) writer.writeheader() writer.writerows(rows) if __name__ == "__main__": run_batch_test(Path("./test_samples"), Path("./results.csv"))

如果你的输入目录里没有.txt文件，这个脚本不会报错，但会输出一个只有表头的 CSV。所以第一步永远是准备测试集。

7. 接口 API 与批量任务

把检测服务封装成 API 之后，就可以接入批量任务。批量任务的关键点有三个：输入目录管理、批量请求调度、失败重试。

7.1 批量检测脚本

下面的脚本会遍历指定目录下的所有.txt文件，调用上面定义的detect_with_model函数，并把结果写入 CSV。这个脚本默认是串行执行，如果文件很多，可以改成线程池或进程池，但需要注意模型推理是 CPU/GPU 密集任务，盲目加线程不一定更快。

import csv import time from pathlib import Path def detect_with_model(text: str): # 这里可以替换成本地 FastAPI 调用或模型直接推理 result = detector(text)[0] return { "label": result["label"], "score": round(result["score"], 4) } def batch_detect(input_dir: Path, output_csv: Path): txt_files = list(input_dir.glob("*.txt")) rows = [] for file_path in txt_files: try: text = file_path.read_text(encoding="utf-8") if not text.strip(): continue start = time.time() result = detect_with_model(text) elapsed = round(time.time() - start, 3) rows.append({ "file": file_path.name, "label": result["label"], "score": result["score"], "elapsed": elapsed, "status": "ok", }) except Exception as exc: rows.append({ "file": file_path.name, "label": "", "score": "", "elapsed": "", "status": f"error: {exc}", }) with output_csv.open("w", encoding="utf-8", newline="") as f: writer = csv.DictWriter(f, fieldnames=["file", "label", "score", "elapsed", "status"]) writer.writeheader() writer.writerows(rows) print(f"done: {len(rows)} files processed -> {output_csv}") if __name__ == "__main__": batch_detect(Path("./batch_input"), Path("./batch_result.csv"))

如果服务已经通过 FastAPI 启动，可以把detect_with_model换成 HTTP 调用：

import requests def detect_via_api(text: str): resp = requests.post( "http://127.0.0.1:8000/detect", json={"text": text}, timeout=60 ) resp.raise_for_status() return resp.json()

注意：本地 API 模型推理是串行的，如果批量请求并发太大，可能会把显存打满或超时。建议先单线程跑一个小批量，观察耗时和资源占用，再决定并发数。

7.2 批量任务的工程化建议

批量任务不能只写一个脚本就上线。需要加三类组件：

• 日志：每处理一个文件，记录文件名、耗时、异常信息。
• 失败重试：网络超时或模型推理异常时，单独写到errors.log，而不是直接跳过。
• 结果持久化：CSV 或 SQLite 都可以，但一定要保留原始文本 ID，方便追溯。

配置文件可以用 JSON 维护，方便切换输入路径、输出路径、阈值和服务地址。

{ "input_dir": "./batch_input", "output_csv": "./batch_result.csv", "model_name": "roberta-base-openai-detector", "max_length": 512, "threshold": 0.5, "api_url": "http://127.0.0.1:8000/detect", "timeout": 60 }

使用时用 Python 的json模块读取：

import json with open("config.json", "r", encoding="utf-8") as f: config = json.load(f) print(config["input_dir"])

这套配置结构是通用的，字段名可以根据实际项目调整。

8. 资源占用与性能观察

AI 文本检测模型的资源占用远低于图像生成模型，但也不是零成本。要观察性能，建议从以下三个维度入手。

8.1 观察工具

在 Linux 服务器上：

nvidia-smi -l 1

可以每秒刷新一次 GPU 显存和利用率。如果机器没有 GPU，直接用：

htop

观察 CPU 和内存占用。另外可以用time命令看单条检测耗时：

time python detect_one.py

8.2 影响性能的因素

• 输入长度：max_length=512和max_length=1024的耗时差异很大。长文本需要被截断或分块，截断会丢失后半部分信息，分块会增加推理次数。
• Batch Size：一次推理多条文本可以提升 GPU 利用率，但也会增加显存占用。如果没有专门优化，建议从 batch_size=1 开始。
• 并发请求：FastAPI 默认是同步阻塞函数时，多个请求会排队。要提升吞吐，可以改用async def或在独立线程池里处理。
• CPU 推理：CPU 跑 RoBERTa 这类模型完全可行，但吞吐低。如果每小时处理量超过几千条，建议使用 GPU 或降低文本长度。

8.3 降低资源占用的方法

• 先切分文本：长文本先按段落切分，只对关键段落打分。
• 使用量化模型：部分模型提供 8bit 或 4bit 量化版本，显存占用更低，精度损失需自行测试。
• 控制并发：批量任务设置max_workers=4或更小，避免 OOM。
• 使用规则预筛：先用破折号、重复度、困惑度等规则筛掉明显正常或明显异常的文本，减少模型调用。

由于没有固定的显存数字，实际部署时应以本机测试为准。第一次运行时观察显存占用，如果 OOM，降低 batch size，或者把device改为 CPU。这个调整过程比任何“推荐配置”都可靠。

9. 常见问题与排查方法

表格形式列出常见问题，方便对照排查。

排查时记住一个基本原则：先看日志，再看资源，最后看代码。不要一上来就怀疑模型有问题。大多数启动类问题来自环境，而不是模型本身。

10. 最佳实践与使用建议

AI 生成文本检测系统要真正落地，不能只靠一个模型和一条 API。下面是几条工程化建议。

第一，先做小样本标定。模型输出的是一个分数，不是最终事实。上线前准备至少 100 条已知来源的文本，人工标注好“人类/AI”，跑一遍检测，画出分数分布。这样你能知道 0.5 阈值是否合适，还是 0.7 更合适。

第二，多种信号交叉验证。不要因为“破折号不是指纹”就完全忽略规则特征。合理的做法是：规则脚本先输出异常信号列表，模型再给概率分，最后人工查看。规则负责快，模型负责准，人工负责终审。

第三，日志要完整。每次检测都记录输入文本的长度、来源 ID、模型版本、分数、耗时、异常信息。这样后续模型升级或阈值调整时，可以对比新旧结果，也可以追溯误报案例。

第四，保护隐私和数据安全。不要在未脱敏的情况下把业务数据发送到第三方 API。如果数据敏感，使用本地部署或做同态脱敏。模型本身也可能从输入文本中泄露内容，这一点在长文本场景尤其要注意。

第五，合规优先。检测工具可以用于内容审核和原创性初筛，但不能作为侵犯隐私、自动处罚或公开告发的依据。涉及人脸、声音、版权素材的场景，需要先确认授权和合法用途。本话题虽然只涉及文字，但同样要遵守隐私和版权要求。

第六，不要试图绕过检测。市面上有些“降 AI 率”“改写降重”工具，本质是修改表面特征让检测器失效。这种需求本身带有规避平台规则的风险，不建议作为技术产品方向。更稳妥的思路是优化生成质量，让 AI 文本更可读、更有信息量，而不是教它伪装成人类。

11. 总结与下一步

回到标题：什么暴露了 AI 生成文本？不是破折号。真正有价值的是序列概率分布中的异常信号，比如困惑度、突发性、重复度和语义平滑性。部署检测系统时，重点不是找出一个神奇的特征，而是建立一套“规则 + 模型 + 人工复核”的流程。

最先应该验证的能力是：本地模型能否跑通，批量任务能否稳定输出 CSV。最容易踩的坑则是把检测结果当作唯一标准，导致误报。建议先准备一个小规模测试集，用规则脚本统计特征，再用分类模型打分，最后把结果和人工判断放在一起对比。这套流程稳定后，再考虑接入 API 服务或扩展到更多业务场景。

如果你正在做 AI 应用开发，可以把文本检测当作一个独立服务，挂到内容生成链路后面。尤其适合那些会面向用户的 AI Agent 场景——输出前先过滤一遍模板化内容，能显著提升用户阅读体验。检测技术不是用来“抓人”的，而是用来提高文本质量和内容可信度的。

下一步可以做的事情有三件：一是把你自己的业务文本收集起来，建立标注集；二是跑通本文第 5 节的本地服务和第 7 节的批量脚本；三是记录不同模型的分数分布，确定合理阈值。这个流程跑完，你手里就有了一套可维护的 AI 文本检测基础方案，后续要换模型、加规则、接业务，都能快速扩展。