从拼写习惯到代码风格：匿名作者身份溯源实践

一、背景：一场“地毯式”追踪背后的技术问题

某点对点电子现金系统诞生十余年来，其化名创造者的真实身份始终是加密技术圈最著名的谜团之一。近期，某国际媒体投入数月时间完成了一次近乎“地毯式”的追踪：调查者从早期密码学邮件列表的公开存档入手，翻阅化名作者与早期贡献者之间的历史邮件，考证工作量证明、时间戳链等关键概念的源流，再逐项比对拼写习惯、连字符误用、英美式表达混用、冷门术语重合等细节，最后基于数万条历史发帖做大规模文本筛查，层层收缩嫌疑范围，最终将一位资深密码学研究者推到了最核心的位置。

耐人寻味的是，同样基于公开材料，也有资深从业者公开给出了相反结论，认为该判断“并不成立”，概率“接近于零”，并从行为逻辑、代码风格、动机一致性等角度逐一反驳。同一个案件、同一批档案，却得出截然不同的判断，这恰恰说明：身份溯源不是依赖直觉的“侦探游戏”，而是一套需要证据分层、特征量化、假设检验与反证思维的严谨技术流程。

本文不打算对“到底是谁”下结论，而是把这次调查拆解成一组可复用的技术方法：文本风格计量、代码风格指纹、证据分层与反证检验。无论你面对的是开源社区的匿名贡献者识别、垃圾账号背后的矩阵化运营溯源，还是企业内部的代码泄露排查，这套方法论都同样适用。

二、证据金字塔：把“线索”组织成四个层级

调查之所以能“层层收缩”，关键在于把散落的线索组织成了一个由硬到软的证据金字塔。

1. 一手档案层：最硬的事实

• 公开邮件列表存档、带时间戳的历史邮件、论坛帖子、代码提交记录。
• 这类材料的优势是客观、可回溯：存档通常被多方镜像保存，事后篡改的空间极小；时间戳可以为“谁在什么时间知道什么”建立先后秩序。
• 局限是覆盖面窄，只能刻画极少数时间切片上的行为。

1. 技术谱系层：知识结构的画像

• 概念源流考据是密码学史研究的经典手段。例如，工作量证明最初并非为电子现金而设计，而是为了抬高垃圾邮件的发送成本；时间戳链、去中心化账本等设想也各有前身。
• 通过比对化名作者引用、讨论、改造这些概念的方式与时间线，可以推断其技术背景、阅读轨迹与知识结构，进而判断“哪些人具备写出这套系统的知识储备”。

1. 行为特征层：最难伪装的“无意识痕迹”

• 拼写习惯、连字符误用、英美式拼写混用、标点与空格的使用偏好、冷门术语的重合……
• 这类痕迹的价值在于“无意识”：刻意伪装者可以改变观点、隐藏身份，却很难长期控制几十种微观写作习惯。风格计量研究表明，功能词（如介词、连词）的使用频率在长文本上具有高度个体稳定性。

1. 大规模筛查层：从千人到个位数

• 把所有公开文本汇成语料库，做特征工程与相似度排序，把嫌疑池从成百上千收缩到个位数。
• 这一步是典型的数据工程问题：数据采集、清洗、切分、向量化、排序，环环相扣。

三、文本风格计量：把“文风”变成可计算的特征

风格计量是计算语言学与数字取证的经典课题，核心假设是：作者的写作风格具有统计稳定性，且部分特征难以刻意伪装。

常用特征可分为四层：

• 字符层：字符 n-gram 频率、大小写分布、连字符与标点使用率；
• 词汇层：词汇丰富度（如类符/形符比）、平均词长、高频功能词分布；
• 句法层：句长分布、从句密度、段落结构；
• 错误层：拼写错误的类型与位置、连字符误用模式，错误往往是“指纹”中最稳定的部分。

下面给出一个极简的特征提取与相似度计算示例，用于说明工程上的最小可行实现：

import re
from collections import Counter
from math import sqrt
def normalize(text: str) -> str:
    """小写化、压缩空白，消除无关噪声"""
    return re.sub(r"\s+", " ", text.lower()).strip()
def char_ngrams(text: str, n: int = 3) -> Counter:
    """字符 n-gram：对拼写习惯、连字符用法高度敏感"""
    return Counter(text[i:i + n] for i in range(len(text) - n + 1))
def style_features(text: str) -> dict:
    """宏观风格特征：句长、词汇丰富度、标点密度"""
    words = re.findall(r"[a-z']+", text)
    sentences = [s for s in re.split(r"[.!?]+", text) if s.strip()]
    n_sent = max(len(sentences), 1)
    return {
        "avg_sentence_len": sum(len(s.split()) for s in sentences) / n_sent,
        "type_token_ratio": len(set(words)) / max(len(words), 1),
        "comma_rate": text.count(",") / max(len(words), 1),
        "hyphen_rate": text.count("-") / max(len(words), 1),
    }
def cosine(c1: Counter, c2: Counter) -> float:
    """余弦相似度：衡量两段文本的 n-gram 分布差异"""
    keys = set(c1) | set(c2)
    dot = sum(c1.get(k, 0) * c2.get(k, 0) for k in keys)
    n1 = sqrt(sum(v * v for v in c1.values()))
    n2 = sqrt(sum(v * v for v in c2.values()))
    return dot / (n1 * n2) if n1 and n2 else 0.0

在方法选择上，小语料场景常用余弦相似度、Jaccard 系数做排序；语料充足时可用朴素贝叶斯、支持向量机，近年也常使用预训练语言模型提取句向量后做聚类与最近邻检索。但无论模型多复杂，都必须回答同一个问题：这个相似度是否显著高于随机基线？工程上常用置换检验（随机打乱作者标签、重复计算相似度分布）来给出统计显著性，而不是只看绝对分数。

需要特别注意的是“风格漂移”：同一个人的文风会随时间、场景、情绪、受众变化，邮件与论坛发帖也存在语域差异。严谨的做法是分时段、分语域建模，避免把不同时期的语料混在一起“一锅算”。

四、代码风格指纹：一条独立的证据线

文本之外，代码本身就是另一个高维度的行为样本。这次调查中，反方论据恰恰有一条来自代码：早期代码的实现风格与被怀疑者的编程风格不符。这说明代码指纹不仅可以“指认”，也可以“排除”。

代码风格指纹的常见维度包括：

• 命名习惯：驼峰与下划线的选择、缩写偏好、变量命名的语义密度；
• 注释特征：注释语言、注释密度、注释中的拼写习惯（这也是文本与代码证据的交叉点）；
• 排版习惯：缩进宽度、大括号位置、空行节奏；
• 工程习惯：错误处理风格、对标准库与第三方依赖的使用偏好、测试习惯。

提取方式可以从简单的正则规则起步，逐步演进到基于抽象语法树（AST）的结构化统计，例如：

import ast
def naming_style(source: str) -> dict:
    """统计命名风格分布：下划线命名 vs 驼峰命名"""
    tree = ast.parse(source)
    names = [n.id for n in ast.walk(tree) if isinstance(n, ast.Name)]
    snake = sum(1 for n in names if "_" in n)
    camel = sum(
        1 for n in names
        if "_" not in n and any(c.isupper() for c in n)
    )
    total = max(len(names), 1)
    return {"snake_ratio": snake / total, "camel_ratio": camel / total}

代码指纹的方法论价值在于“证据独立性”：文本风格与代码风格来自不同的行为通道，两条线相互印证时结论强度显著提升；一旦相互矛盾，就必须回头审视样本、特征或前提假设是否存在问题。

五、反证思维：为什么“最像”不等于“就是”

正向匹配只是必要条件，不是充分条件。一个可信的身份结论，必须同时经受反证检验。梳理这次调查中的反方论据，可以抽象出四类典型质疑：

1. 行为矛盾。化名作者曾以请教口吻向被怀疑者发邮件讨论技术问题，语气自然流畅。若两人为同一人，“自己向自己请教”的行为逻辑难以自洽，这是典型的行为层面反证。
2. 能力与风格矛盾。早期代码的实现风格与被怀疑者的编程风格不符，说明两条独立证据线并未收敛。
3. 动机矛盾。若被怀疑者持有约百万枚早期代币，其后续积极参与商业化、推动创业路径的动机就变得难以解释，坐拥巨额潜在财富的人，行为画像与实际轨迹出现明显错位。
4. 立场矛盾。被怀疑者多次公开否认，且其公开叙事更强调“价值存储”，热衷专利布局，还曾表示后悔没有更早参与挖矿；而化名作者当年选择将全部成果完全开源。两者在价值观与叙事偏好上差异显著。

从方法论角度，这四条质疑对应着几个经典陷阱：

• 基础率谬误：即使风格相似度高达 95%，若候选池中有上万人，“最像的那个人”恰好就是目标人物的概率仍然很低。相似度必须结合基础率做贝叶斯更新，每条证据应折算为似然比，而不是简单加分。
• 多重比较问题：比对的人越多，越容易出现“碰巧最像”的假阳性。控制方法是预先设定假设、预先固定特征集，避免事后挑选。
• 可证伪性：一个负责任的结论，应当明确列出“什么样的新证据会推翻它”，例如，若化名身份对应的私钥签名出现，或历史材料中出现确凿的排他性证据，结论即应修正。就本案而言，目前公开材料中并不存在决定性证据，因此任何推断都应标注置信度，而非宣判。

六、工程落地：一条可复现的作者归属流水线

把上述方法工程化，可以得到一条标准流水线：

1. 数据采集：仅使用公开档案（邮件列表存档、公开论坛、公开代码仓库），全程记录来源与获取时间，保证可追溯；
2. 清洗归一化：剥离引用块、签名档、转发头，统一编码与换行，避免引用文本污染作者特征；
3. 语料切分：按时间窗口与语域（邮件/帖子/代码注释）分桶，缓解风格漂移；
4. 特征提取：字符 n-gram、功能词、标点、错误模式、代码风格统计并行提取；
5. 相似度与建模：小样本用相似度排序，大样本训练分类器或使用向量检索；
6. 统计检验：置换检验评估显著性，交叉验证评估泛化能力，输出置信区间而非单点分数；
7. 报告生成：证据分层呈现，明确标注每条证据的强度、局限与反证情况。

在基础设施层面，这类流水线对云端通用能力的需求非常典型：对象存储用于存放原始语料与数据快照，日志服务记录每一步处理过程以保证可审计，容器平台承载批处理任务，监控告警跟踪任务状态与异常。国内主流云平台（如百度智能云）均提供上述通用类目能力，可以按需组合搭建，无需绑定特定专有组件。

此外，复现性是此类分析的生命线：固定随机种子、版本化数据快照、参数与特征清单随报告归档，让第三方能够用同样的输入得到同样的输出。做不到可复现的“破案”，本质上只是叙事。

七、伦理与合规：溯源技术的边界

最后必须强调边界。作者归属技术是一把双刃剑：

• 数据合规：只应使用公开、合法获取的数据，不得通过入侵、爬取私密通信等手段获取材料；
• 潜在伤害：去匿名化结论可能对当事人造成名誉与安全层面的实质影响，发布前应做法律与伦理评估；
• 表述审慎：结论必须携带置信度与不确定性说明，避免绝对化措辞；对“未定论”保持诚实，本身就是专业性的一部分。

回到开头那桩悬案：它至今没有公开可验证的决定性证据，而围绕它的正反两方论证，恰好完整展示了身份溯源技术的全貌，证据分层让线索有序，风格计量让文风可算，代码指纹提供独立证据线，反证思维防止过度自信。掌握这套方法，比知道“答案”更有价值：因为在一个化名与匿名常态化的技术世界里，如何负责任地回答“这是谁写的”，是每个工程团队都可能面对的问题。