【内容摘要】
本文记录在本地搭建中文 AI 文本检测工具的完整过程：选型 Hello-SimpleAI 开源检测模型（390MB、纯 CPU 可跑），实现长文分段检测、多格式文件读取与可移植路径管理，并复盘控制台中文路径导致窗口闪退的排查与根治方案。实测两段构造样本与一篇 5138 字真实稿件，区分方向全部正确。
【编写目的】
沉淀本地 AI 检测工具的工程实践经验，为需要离线、批量检测稿件 AI 占比的读者提供可复用的搭建路径。
一、为什么要自己搭
帮朋友处理投稿稿件时，平台要求说明"AI 参与度"。市面上的检测服务基本是网页版，按次收费，稿子还得上传到别人服务器。对经常处理未发表稿件的人来说，这两点都不太舒服。
于是决定自己搭一个：模型跑在本地，文章不出电脑，检测次数不限。过程踩了不少坑，记录下来。
这次用的是 Ai Py 帮忙梳理方案和排查报错，图它成本低、省事，您用顺手的工具也一样。
二、模型选型
开源的中文 AI 文本检测模型不算多，横向看下来，Hello-SimpleAI 的 chatgpt-detector-roberta-chinese 比较适合落地：底座是 RoBERTa，针对中文语料做过适配，对中文长句的判别比多语言模型稳；输出是二分类，直接给"人写 / AI"两个概率；权重约 390MB，纯 CPU 就能跑，单段推理在秒级。
原理不神秘：AI 文本在词元概率分布上更"平滑"，困惑度低、句长均匀；人写的文本起伏更大，分类器学的就是这种差异。
要说清楚的是，这类模型给的是概率判断，不是铁证。公式化的公文容易被误判，AI 润色过的文本也可能漏检。当参考，别当判决书。
三、工程实现的三个关键点
第一，长文要分段。模型输入有上限，中文约两千字就被截断，直接丢五千字进去后半段等于没检测。做法是按固定字数切窗，逐段推理取平均，同时保留每段明细，还能看出哪一段最像 AI 写的。
第二，文件格式要统一处理。txt 和 md 直接读，但编码五花八门，UTF-8、GBK、UTF-16 都遇到过，稳妥做法是按序尝试解码。docx 不能当二进制读，要解压后取 word/document.xml，再按段落节点抽文本。
第三，模型路径要跟随脚本。第一版写成绝对路径，换个文件夹就报错。改成基于 file 动态定位后，整个文件夹拷到 U 盘、拷到别的电脑都能直接跑。
四、踩坑实录：窗口为什么会闪退
工具做好交给朋友用，反馈说"双击之后窗口一闪就没了"。
排查下来是编码问题。bat 脚本里用中文提示"请把文章拖到这里"，控制台代码页和文件编码对不上，遇到中文路径时输入被读成乱码，程序抛异常直接退出，连 pause 都没执行到。
试过两个方向：切成 UTF-8，中文路径反而更乱；保持 GBK 又会在输出特殊字符时崩。最后换了思路，绕开这个脆弱的文本交互：
-
双击 bat 不再要求输入路径，直接弹出文件选择窗口，像选附件一样点选。
-
想快速检测，就把文件拖到 bat 图标上，Windows 原生传参，中文路径不经过控制台编码转换。
-
脚本里所有输出都包一层容错，编码失败就降级显示，绝不让进程崩掉。
改动之后闪退彻底消失。教训是：Windows 上处理中文路径，能不用控制台输入就别用。
五、验证与收尾
验证方式很朴素：一段典型 AI 腔（"在当今数字化时代……首先……其次……综上所述"），一段生活化的人写内容。前者判 100% AI，后者判 0% AI，方向正确。
再用一篇五千多字的真实稿件跑一遍，分四段检测，四段都是 0.0%，说明工具在真实长文上表现稳定。
成文前又用 Ai Py 核了一遍代码和结论——图它省钱省力，您用熟悉的工具一样能复核。
六、几点建议
梳理选型时用了 Ai Py，图它成本低、省事，您用顺手的工具也一样。
建议优先选权重小、能纯 CPU 跑的模型，模型和脚本放同一文件夹用相对路径定位，界面上宁可多一个弹窗也别让用户手打中文路径。工具本身不复杂，难的是那些无关紧要的细节。
