命名是 LLM 语义理解与组织结构化资产之间的首要接口。糟糕的命名降低 Agent 性能的方式，与糟糕的 tokenization 降低模型训练效果的方式如出一辙。
在量化投资公司，同一个概念——"行情数据"——可以沿着交易所、品种、频率、数据源、存储格式等多个正交维度分解。当我们开始用 Claude Code 大规模服务内部研究流程时，一个问题变得尖锐：Agent 每次 ls、grep、git log 的输出都会进入 context window，而这些输出中的命名就是 Agent 理解系统的第一层——也往往是唯一一层——信息。
一个路径 mktdata/shfe/tick/cu 和 data_feed_03_raw 对人类来说都能接受——前者需要知道 shfe 是上期所，后者需要知道 03 对应什么。但对 LLM 而言，二者的可解析性有本质差异。这篇文章试图解释为什么，并给出一套可操作的命名规范。
现代 LLM 使用 Byte Pair Encoding (BPE) 分词（Sennrich et al., 2016, "Neural Machine Translation of Rare Words with Subword Units"）。关键机制是两阶段编码：正则预分词器先将文本切成 chunk，然后 BPE 合并操作在每个 chunk 内独立进行，不会跨 chunk 边界合并。
这意味着分隔符的选择直接决定分词结果：
market_data → 预分词产生 market + _data，BPE 通常保留为 2-3 个 tokenmarket-data → 预分词产生 market + data 或 market + + data，约 3-5 个 tokenmktdata → 可能被切为 mkt + data 甚至 mk + t + data，语义碎片化核心规律：常见英文单词（market、data、tick、config）几乎一定是单 token。领域缩写（shfe、mktdata）则大概率被切碎为无意义的 subword。模型需要从碎片中重建语义——可行但不可靠。
这不只是理论推测。Wang et al.（2023, Penn State & CMU, arXiv:2307.12488）的实验表明，将 Python 代码中的变量名匿名化后，CodeBERT 在代码搜索任务上的 MRR 显著下降。更关键的发现是：有意误导性的命名（名称暗示错误功能）比随机命名造成的性能下降更严重——证明模型确实在积极使用名称语义进行推理，而非仅依赖结构线索。
Le et al.（2025, arXiv:2510.03178, "When Names Disappear"）在更新的模型（GPT-4o、DeepSeek V3、Llama 4）上验证了类似结论。他们将代码理解能力分为结构语义通道（定义程序行为的形式结构）和命名通道（传达意图的人类可读命名）。移除命名通道后，类级别代码摘要准确率下降可达 30 个百分点（如 DeepSeek V3 从 87.7 降至 58.7）。
经典的 word2vec 关系 king - man + woman ≈ queen 说明：一致的语义关系会在嵌入空间中形成线性结构。应用到命名：如果 LLM 反复看到 {exchange}/tick/{instrument} 这个模式——shfe/tick/cu、cme/tick/es、ice/tick/cl——它就能构建出"tick 是一个频率维度"的向量表征，遇到从未见过的 nymex/tick/gc 时可以通过类比理解。而如果命名不一致（shfe_ticks_cu、CME-ES-TICK、ice/realtime/cl），每个模式都需要独立记忆。
Min et al.（2022, EMNLP, arXiv:2202.12837）的研究进一步支持这个观点：在 in-context learning 中，示例的格式和分布比标签是否正确更重要。12 个不同模型（包括 GPT-3）上的实验表明，随机替换示例标签几乎不影响性能。对命名来说：一个全部遵循 {category}/{source}/{type}/{symbol} 格式的文件系统就是一个 many-shot prompt——每条路径都在强化格式模式。