先说结论：十一天前挂上 arXiv 的那篇 2610.27863，骨架是对的，数字得打对折看。
不是水分那种对折。是「72.4」这个数不该被当成结论，「62.5」才是能拿出去说的那个。两个数搁在同一篇摘要里，摆明了等人误读。
先说为什么愿意花时间看它。
因为这行被「文件级一个分数」这种形态糟蹋太久了。
你拿现有的检测器跑一个两千行的服务，它回你 0.87。然后呢？没有然后了。这个 0.87 既不能拿去问人，也不能拿去当证据，更没法告诉你哪三十行是补出来的。真要追究，你得把整个文件摊开一行行对——那还不如一开始就别用这工具。
论文里那句判断我认：「把整个文件压缩成一个分数，局部证据会被稀释」。
稀释这个词用得准。两千行里塞了三十行模型补的，剩下全靠人手敲。文件级分类器看到的是什么？一堆人类特征里混着一点噪声。判人类，那三十行就这么过去了。过去那批检测器在大文件上永远显得很宽容——不是它判断力差，是它的输出形态根本装不下这种信息。
这篇干的事，说白了就是不给文件打分，改给每个 token 打分，再往上汇总。
机制部分值得单拎出来。冻结一个代码语言模型，挂两个低秩适配器。一个拿机器生成的文件训，一个拿人写的训。同一个 token 过两遍，两个适配器各吐一个对数似然，相减，得到逐 token 的比值。这个比值就是「这一小段更像谁写的」的局部证据，再拿轻量预测头结合周边上下文，在行内、块内汇总，最后才汇到文件级。
我得承认，这个设计比我预期聪明。
因为它输出的是似然比，不是概率分数。似然比这东西天生带判决语义——你可以直接拿阈值卡，卡在哪个点、对应的假阳性率是多少，统计上说得清。那些端到端训个二分类头的方案，吐你一个 0.87，你既不知道这数怎么来的，也推不出「我要 1% 误报时阈值该设哪」。
这次算往好的方向打脸。我原以为又是一篇换 backbone 刷榜的。
不过适配器那部分我还没细究——人类原始文件和它的 AI 修改版怎么配对、续写和 fill-in-the-middle 两种场景的比例怎么分，论文讲得不算透。这条先存疑，别信我这半句。
现在开始照。
「72.4 macro F1」——看清楚前提。内部测试集，11,773 个 AI 参与文件覆盖六种生成模式，2,541 个人类文件。自己造的集，自己训的适配器，自己调的 1% 操作点。
自己造的测试集报 72 以上，我一点也不惊讶。这个数能证明方法跑得通，不证明它在你仓库里也跑得出这个数。任何人在自己造的集上报 72 我都不惊讶，这是基本礼貌。
真正让我坐直的是下一行。
HybridCodeAuthorship，人机共写基准，这基准连训练集都没有。论文没做任何适配，直接上，行级 F1 62.5。基准原论文报的最佳行级结果是 56。
「62.5 对 56」——差的不是 6.5 个点，差的是「没在你的数据上训过」这个前提。
这才是硬证据。
但别高兴太早。
行级 F1 62.5 意味着什么，粗算一下：大概每三行就有一行判错。这个精度够不够用，完全取决于你拿它干什么。
做数据集清洗、做「这个 PR 大概多少 AI 参与」的粗筛、做研究方向定位，够了，够用得很。
拿去认定某个学生作业抄袭、某位员工产出注水？
差得远。这不是这套方法的锅，是任何 62.5 的东西都不配干这个。
还有一条数据被埋得很深，我倒觉得是全篇最该看的一行。
19,445 个 2022 年之前建的老仓库里的人类文件，按迁移过去的 1% 阈值跑，假阳性落在 0.55% 到 0.81% 之间。
为什么这条比 72.4 有用？
因为检测器最恶心的失败模式从来不是漏检，是诬告。漏掉一个 AI 写的文件，无非少抓一个；把一个人手敲的老文件判成高比例 AI 生成，那要出事的——学术上叫不端，公司里叫绩效谈话。🙃
0.55% 到 0.81%，说明这套阈值迁到分布外的老代码上没崩。这是防守数据。防守数据比进攻数据可信，因为它不给你挑口子的空间。
顺手记一笔：29 页，主分类 cs.SE，交叉挂 cs.CL 和 cs.LG。软件工程的论文往机器学习分类里挤，这年头不新鲜，翻实验部分的时候心里有个数就行。
评分卡。
这东西不卖钱，换个问法——现在值不值得跟。
值得跟，不值得现在拿去判决。
方法上它把粒度这件事做对了：token 级证据往上汇总成行、块、文件，这条路径我信，而且比文件级打分那条路更能装信息。数字上内部那 72.4 得打对折看，外部那 62.5 才是能拿出去说的，而 62.5 离「能当证据」还差一大截。
真要验它，别看 abstract。拿你自己的仓库跑一遍，跑之前先数数 2022 年前的老文件有多少——那批就是你的照妖镜，误报全从那儿冒出来。
跑完你大概会跟我一样，对这套方法的耐心比对它的期待多一点。