命名模板直接抄：日期_项目缩写_场景描述_镜头类型_版本号

一、命名熵增：一个被低估的工程问题

任何一个经历过项目交付的从业者，大概都见过这样的文件夹：最终版、最终版2、最终版_改、最终版_真最终。这不是段子，而是大量中小型制作团队、数据标注团队乃至研发团队的日常。命名混乱带来的成本，往往在项目中期才集中爆发：找不到文件、版本覆盖、交接困难、自动化脚本失效。

从信息论的角度看，命名混乱本质上是信息熵在文件系统层面的累积。每一次“随手命名”都在向系统注入噪声，而检索、排序、匹配这些操作的成本，会随着噪声增加而非线性上升。美国国家标准与技术研究院（NIST）在数字取证领域的研究中反复强调，文件元数据的完整性与一致性直接影响证据链的可追溯性（NIST SP 800-101 Rev.1，2014）。虽然该标准面向取证场景，但其关于“命名与元数据一致性”的论述，对普通工程团队同样具有参考价值。

影视后期行业对此感受尤深。美国电影电视工程师协会（SMPTE）在2014年前后推动的IMF（Interoperable Master Format）标准（SMPTE ST 2067系列），其核心目标之一就是让不同厂商、不同环节的母版文件能够被机器正确识别与组装。IMF对文件命名和目录结构有明确约束，这从侧面说明：当协作规模超过某个阈值，命名就不再是个人习惯问题，而是系统接口问题。

本文评述：把命名问题上升到“熵增”层面，不是为了故弄玄虚，而是为了说明一个工程事实——命名规范的收益是延迟兑现的，而成本是即时感知的。这解释了为什么绝大多数团队明知命名重要，却始终无法坚持。要破解这个困局，必须让规范的执行成本趋近于零，这正是后文“命名即接口”与自动化校验要解决的问题。

1.1 命名混乱的三类典型代价

根据笔者对多个制作团队与数据团队的观察（以下为整合性经验总结，非严格统计数据），命名混乱的代价可归纳为三类：

• 检索代价：无法通过文件名快速定位目标资产，依赖记忆或翻找，单次检索耗时从秒级上升到分钟级。
• 协作代价：交接时需额外沟通“哪个文件是哪个”，版本覆盖导致返工，跨部门传递时语义丢失。
• 自动化代价：脚本无法可靠解析文件名，批处理、转码、归档、检索等自动化流程频繁失效。

第三类代价在AIGC时代被显著放大。当生成式工具每天产出成百上千个中间文件时，人工命名根本不可行，命名必须由工具自动完成，而自动命名的前提是有一套机器可解析的模板。

1.2 为什么是“模板”而不是“规范”

很多团队写过命名规范文档，但落地效果参差不齐。笔者认为，问题出在“规范”这个词本身——规范是描述性的，它告诉人们“应该怎样”，但不提供执行路径。而模板是结构性的，它直接给出一个可填充的骨架，把“自由命名”转化为“填空”。

这类似于编程语言中“约定优于配置”（Convention over Configuration）的思想。Ruby on Rails框架在2004年推广这一理念后，深刻影响了后续大量框架的设计。本文评述：命名模板就是文件系统层面的“约定优于配置”——用一套固定结构替代无限选择，把认知负担从“想名字”转移到“填字段”，从而大幅降低执行成本。

二、“命名即接口”：本文的核心分析主线

在软件工程中，接口（Interface）是不同模块之间约定的通信契约。它规定了输入输出的格式、类型和语义，使得模块可以独立演化而不破坏整体。笔者认为，文件名在资产管理系统中扮演着完全相同的角色：它是人、工具、流水线之间传递语义的最小契约。

这个类比并非文字游戏，它带来三个可操作的推论：

1. 接口需要版本管理。命名模板本身会演化，字段增减、顺序调整都需要像API一样管理版本，避免旧资产无法被新脚本解析。
2. 接口需要校验。就像API需要参数校验一样，文件名需要格式校验，非法命名应在入口处被拦截。
3. 接口需要文档。模板的每个字段都应有明确定义、取值范围和示例，否则不同人理解不一致，接口就失效了。

把命名当作接口来设计，意味着我们在写模板时，要同时考虑三类“调用方”：人类读者、检索工具、自动化脚本。一个优秀的命名模板，应该让这三类调用方都能低成本地获取所需信息。

三、模板五字段逐层拆解

模板“日期_项目缩写_场景描述_镜头类型_版本号”采用下划线分隔，共五个字段。下划线的选择有其工程理由：在多数文件系统和URL中，下划线无需转义，且不会与空格混淆（空格在命令行中需要引号包裹，是脚本处理的常见痛点）。下面逐字段拆解设计逻辑。

3.1 日期：排序锚点与时间语义

日期放在首位，核心目的是利用字典序实现时间排序。这要求日期必须采用YYYYMMDD格式，而非YYYY-MM-DD或MMDDYYYY。

这一格式的权威依据来自ISO 8601国际标准（ISO 8601:2019 Data elements and interchange formats）。ISO 8601规定的基本格式为YYYYMMDD，扩展格式为YYYY-MM-DD。在文件名场景中，基本格式更优，因为连字符在某些工具链中可能被特殊处理，且去掉连字符后更紧凑。

本文评述：日期字段的真正价值不在于“记录创建时间”，而在于提供一个稳定、单调、可排序的锚点。很多团队用“项目名_版本”命名，结果版本号在不同项目间不可比，排序时完全失效。日期锚点让跨项目、跨场景的资产能够被统一排序，这对归档和检索至关重要。

需要提醒的是，日期应记录资产产生日期而非修改日期。修改日期会随每次编辑变化，破坏排序稳定性。如果需要在文件名中体现修改时间，应通过版本号字段间接表达，而非改动日期字段。

3.2 项目缩写：命名空间与冲突隔离

项目缩写承担“命名空间”职能，用于隔离不同项目的资产。设计要点有三：

• 长度控制在2-6个字符。过短易冲突，过长影响可读性。业界常见做法是取项目英文名的首字母组合或前几个字母。
• 全大写或全小写统一。混用大小写会在跨平台（Windows不区分大小写，Linux区分）时引发问题。建议统一大写，视觉上更醒目。
• 建立缩写注册表。团队应维护一份项目缩写对照表，避免“两个项目用了同一个缩写”或“一个项目在不同人手里缩写不同”。

在软件工程中，命名空间冲突是经典问题。C++的namespace、Java的package、Python的module，本质都是通过前缀隔离来避免命名碰撞。项目缩写在文件命名中扮演同样角色。笔者认为，缩写注册表应作为团队资产的一部分被版本控制，而非散落在个人笔记里。

3.3 场景描述：语义载体与检索关键词

场景描述是模板中最“自由”的字段，也是最容易失控的字段。它承载资产的语义信息，是人工检索时的主要依据。设计难点在于：既要表达充分，又要控制长度和字符集。

建议采用以下约束：

• 使用英文或拼音，避免中文。中文文件名在跨平台传输、URL编码、命令行处理时经常出问题。如果团队全中文环境且无跨平台需求，可酌情使用，但需统一编码为UTF-8。
• 用连字符连接单词，而非空格。如night-city-chase。空格在脚本中需要转义，是常见故障源。
• 长度建议不超过30个字符。过长会导致文件名整体超限（多数文件系统限制255字节），且可读性下降。

从检索角度看，场景描述应包含最具区分度的关键词。例如“夜晚城市追逐”比“动作场景”更有检索价值。这类似于信息检索中的TF-IDF思想：高频通用词（如scene、shot）区分度低，应避免；低频具体词（如rooftop、rain）区分度高，应优先。

3.4 镜头类型：结构化分类字段

镜头类型是典型的受控词表（Controlled Vocabulary）字段，取值应来自预定义集合，而非自由填写。常见取值包括：

缩写	全称	说明
WS	Wide Shot	全景，展示环境与人物关系
MS	Medium Shot	中景，腰部以上
CU	Close-Up	特写，面部或细节
ECU	Extreme Close-Up	大特写，局部极致放大
OTS	Over-the-Shoulder	过肩镜头，对话常用
POV	Point of View	主观视角

表2：常见镜头类型缩写（笔者根据影视行业通用术语整理）

受控词表的价值在于让机器可以可靠分类。如果镜头类型字段允许自由填写，那么“特写”“CU”“closeup”“close-up”会同时出现，检索时需枚举所有变体，自动化脚本也无法可靠匹配。受控词表把这个开放问题转化为闭合问题。

本文评述：受控词表的维护成本常被低估。词表需要有人负责增删改，需要有版本记录，需要通知所有使用者。但相比自由填写带来的长期检索成本，这笔投入是值得的。建议词表初始规模控制在20个以内，随需求逐步扩展，避免一开始就设计过于庞大的分类体系。

3.5 版本号：单调递增的演化标记

版本号字段的设计要点是单调递增、定长补零、语义明确。推荐格式为v001、v002，而非v1、v2。

定长补零的理由同样是字典序：v1、v10、v2按字典序排列会变成v1、v10、v2，完全错乱。补零为v001、v002、v010后排序正确。这是软件工程中版本号管理的通用实践，语义化版本（Semantic Versioning，semver.org，2010年提出）虽采用三段式，但其“可比较性”原则同样适用于文件名版本号。

关于版本号语义，团队需明确约定：是每次保存都递增，还是每次交付才递增？笔者认为，文件名中的版本号应记录交付级版本，而非每次保存。频繁保存的中间态应由版本控制系统（如Git、Perforce）管理，文件名版本号只标记有意义的里程碑。否则版本号会迅速膨胀到v100+，失去区分价值。

四、编码规则与字符集：从可读性到可解析性

命名模板的字段设计只是第一步，字符集与编码规则决定了模板能否被可靠解析。这一节讨论三个层面的问题：允许字符集、分隔符选择、长度限制。

4.1 允许字符集：ASCII安全子集

建议将文件名字符集限制在ASCII安全子集内：

允许字符：A-Z a-z 0-9 _ - .
禁止字符：空格 / \ : * ? " < > | 以及所有非ASCII字符

禁止字符列表中的/ \ : * ? " < > |来自Windows文件系统保留字符（Microsoft Docs, Naming Files, Paths, and Namespaces, 2023更新）。这些字符在Linux上部分可用，但跨平台传输时会失败。空格的问题在于命令行处理，虽然可以转义，但增加了脚本复杂度。

非ASCII字符（中文、日文、emoji等）的问题更隐蔽：不同操作系统、不同压缩工具、不同传输协议对UTF-8的处理不一致，可能导致乱码或文件丢失。ZIP格式在历史上对UTF-8支持不佳，虽然2006年后有UTF-8标志位，但旧工具仍可能出错。

4.2 分隔符：下划线与连字符的分工

模板使用下划线_作为字段分隔符，字段内部使用连字符-连接单词。这种分工让解析变得明确：按_分割得到字段，字段内部的-不参与分割。

20250315_PRJ01_night-city-chase_WS_v003
│        │     │                │  │
│        │     │                │  └─ 版本号
│        │     │                └──── 镜头类型
│        │     └───────────────────── 场景描述（内部用-连接）
│        └─────────────────────────── 项目缩写
└──────────────────────────────────── 日期

本文评述：分隔符的分工设计体现了“命名即接口”的核心思想——接口必须无歧义。如果字段分隔符和词内连接符混用，解析器就需要复杂规则来消歧，这违背了接口应简单可靠的原则。下划线与连字符的分工是一个低成本、高收益的设计决策。

4.3 长度限制：255字节的硬约束

多数主流文件系统对单个文件名有255字节限制（ext4、NTFS、APFS均如此）。ASCII字符每字节1字符，所以255字符是上限。但实际使用中，建议将文件名控制在80字符以内，理由有三：

• 完整路径长度限制更严格（Windows传统上限260字符，虽可通过注册表放宽，但兼容性风险仍在）。
• 过长文件名在UI中显示不全，影响人工识别。
• 刻录光盘、发送邮件等场景对路径长度有额外限制。

按模板结构估算：日期8 + 下划线1 + 项目缩写4 + 下划线1 + 场景描述30 + 下划线1 + 镜头类型3 + 下划线1 + 版本号4 + 扩展名4 ≈ 57字符，留有充足余量。

五、校验工程化：正则、脚本与CI流水线

模板设计完成后，如果不校验，执行率会迅速衰减。这一节给出从正则到CI集成的完整校验方案。

5.1 正则表达式：模板的机器可读形式

将模板翻译为正则表达式，是校验的第一步：

^(\d{8})_([A-Z]{2,6})_([a-z0-9-]{1,30})_([A-Z]{2,4})_(v\d{3})\.([a-zA-Z0-9]+)$

逐段解释：

正则片段	含义	对应字段
(\d{8})	8位数字	日期
([A-Z]{2,6})	2-6位大写字母	项目缩写
([a-z0-9-]{1,30})	1-30位小写字母数字连字符	场景描述
([A-Z]{2,4})	2-4位大写字母	镜头类型
(v\d{3})	v+3位数字	版本号
\.([a-zA-Z0-9]+)	点+扩展名	扩展名

表3：正则表达式逐段解析（笔者整理）

5.2 Python校验脚本：可直接复用

以下脚本可批量校验目录下的文件名，输出不合规清单：

import os
import re
import sys
from datetime import datetime

PATTERN = re.compile(
    r'^(\d{8})_([A-Z]{2,6})_([a-z0-9-]{1,30})_([A-Z]{2,4})_(v\d{3})\.([a-zA-Z0-9]+)$'
)

VALID_SHOT_TYPES = {'WS', 'MS', 'CU', 'ECU', 'OTS', 'POV'}

def validate_filename(filename):
    """返回 (是否合规, 错误信息列表)"""
    errors = []
    match = PATTERN.match(filename)
    if not match:
        return False, ['文件名不符合模板格式']
    
    date_str, proj, scene, shot, ver, ext = match.groups()
    
    # 校验日期真实性
    try:
        datetime.strptime(date_str, '%Y%m%d')
    except ValueError:
        errors.append(f'日期无效: {date_str}')
    
    # 校验镜头类型是否在受控词表内
    if shot not in VALID_SHOT_TYPES:
        errors.append(f'镜头类型不在受控词表: {shot}')
    
    # 校验场景描述不含连续连字符
    if '--' in scene:
        errors.append('场景描述含连续连字符')
    
    return len(errors) == 0, errors

def scan_directory(root_dir):
    """扫描目录，返回不合规文件清单"""
    bad_files = []
    for dirpath, _, filenames in os.walk(root_dir):
        for fn in filenames:
            if fn.startswith('.'):
                continue  # 跳过隐藏文件
            ok, errs = validate_filename(fn)
            if not ok:
                bad_files.append((os.path.join(dirpath, fn), errs))
    return bad_files

if __name__ == '__main__':
    target = sys.argv[1] if len(sys.argv) > 1 else '.'
    bad = scan_directory(target)
    if not bad:
        print('全部文件命名合规')
    else:
        print(f'发现 {len(bad)} 个不合规文件：')
        for path, errs in bad:
            print(f'  {path}')
            for e in errs:
                print(f'    - {e}')

这个脚本的设计要点：

• 分层校验：先校验格式，再校验语义（日期真实性、受控词表）。格式校验快速失败，语义校验提供更具体的错误信息。
• 跳过隐藏文件：以.开头的文件通常是系统文件，不应纳入校验。
• 返回结构化错误：便于后续集成到报告系统或CI日志。

5.3 CI流水线集成：让校验成为门禁

脚本只有集成到流水线才能持续发挥作用。以下是一个GitLab CI配置示例（GitHub Actions类似）：

stages:
  - validate

naming-check:
  stage: validate
  script:
    - python scripts/validate_naming.py assets/
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - assets/**/*
  allow_failure: false

关键配置说明：changes规则让校验只在资产目录变更时触发，避免每次提交都跑全量扫描；allow_failure: false让校验失败阻塞合并，形成真正的门禁。

本文评述：把命名校验放进CI，是把“规范”转化为“约束”的关键一步。规范靠自觉，约束靠系统。当不合规命名无法合并时，团队会迅速形成肌肉记忆。这比开十次宣贯会都有效。需要注意的是，门禁应设置合理的豁免机制（如紧急修复可临时绕过），避免规范成为交付的阻碍。

六、跨工具链落地：剪辑、DCC与版本控制

命名模板最终要落到具体工具链中。不同工具对文件名的处理方式不同，需要针对性适配。

6.1 剪辑软件：DaVinci Resolve与Premiere Pro

DaVinci Resolve的媒体池支持按文件名排序，但默认排序规则可能受系统区域设置影响。建议在媒体池中启用“按名称排序”，并确保所有素材遵循YYYYMMDD格式，这样时间线顺序与文件名顺序一致。

Premiere Pro的“项目”面板支持自定义列，可以添加“注释”列记录更多元数据。但注释不随文件走，换项目就丢失。因此，关键元数据应优先写入文件名，注释作为补充。

Adobe官方文档（Adobe Premiere Pro User Guide, 2024）提到，Premiere对含特殊字符的文件名支持有限，建议使用字母数字下划线。这与本文模板的字符集约束一致。

6.2 DCC工具：Maya、Blender与Houdini

三维工具对文件名的处理更敏感。Maya的引用路径（Reference）如果包含空格或特殊字符，在跨平台协作时经常断裂。Autodesk官方建议（Maya User Guide, 2023）使用相对路径且避免特殊字符。

Blender的bpyPython API可以读取文件名并解析字段，这为自动化提供了可能。例如，可以根据文件名中的镜头类型字段自动设置渲染参数。

# Blender中根据文件名自动设置输出路径
import bpy
import os
import re

blend_path = bpy.data.filepath
filename = os.path.basename(blend_path)
match = re.match(r'^(\d{8})_([A-Z]{2,6})_(.+)_([A-Z]{2,4})_(v\d{3})', filename)

if match:
    date, proj, scene, shot, ver = match.groups()
    output_dir = f'/renders/{proj}/{date}_{scene}'
    bpy.context.scene.render.filepath = os.path.join(output_dir, f'{shot}_{ver}_')

Houdini的$HIPNAME变量可获取当前HIP文件名，结合Python表达式可实现类似的自动化。SideFX官方文档（Houdini Docs, 2024）提供了相关API说明。

6.3 版本控制：Git与Perforce

Git对二进制大文件支持不佳，影视资产通常用Perforce或类似工具。Perforce的仓库路径（Depot Path）可以与文件名模板配合，形成“路径+文件名”的双重语义结构。

建议的Perforce目录结构：

//depot/projects/PRJ01/
  ├── assets/
  │   ├── 20250315_PRJ01_night-city-chase_WS_v003.blend
  │   └── 20250315_PRJ01_night-city-chase_CU_v001.blend
  ├── renders/
  └── docs/
      └── naming-convention.md

本文评述：工具链适配的核心原则是“让工具服务于命名，而非让命名迁就工具”。如果某个工具不支持标准命名，应通过脚本或插件做转换层，而非放弃命名标准。转换层虽然增加了一次性开发成本，但保护了命名接口的一致性。

七、AIGC时代的命名新命题

生成式AI的普及，让命名问题从“人工规范”转向“机器自动生成”。这一节讨论AIGC场景下的命名挑战与应对。

7.1 生成式资产的命名困境

Stable Diffusion、Midjourney、ComfyUI等工具每次生成会产生多个输出文件，默认命名通常是随机种子或时间戳。如果不加干预，一个下午就能产生数千个00001.png、00002.png，检索几乎不可能。

ComfyUI的SaveImage节点支持filename_prefix参数，可以嵌入变量。Stable Diffusion WebUI（AUTOMATIC1111）的[date]、[seed]等占位符也可用于命名。这些机制为自动化命名提供了基础。

建议的AIGC命名模板扩展：

日期_项目缩写_场景描述_模型标识_种子_版本号
20250315_PRJ01_night-city-chase_sdxl-1.0_123456789_v001.png

增加“模型标识”和“种子”字段，是因为生成式资产的可复现性依赖于这两个参数。没有它们，即使有提示词也无法精确复现。这类似于机器学习实验管理中的“实验追踪”（Experiment Tracking），MLflow、Weights & Biases等工具都强调参数记录的重要性。

7.2 提示词与文件名的映射

生成式资产的另一个挑战是：提示词（Prompt）往往很长，无法直接放入文件名。解决方案是建立“提示词哈希→完整提示词”的映射表，文件名中只放哈希前缀。

20250315_PRJ01_night-city-chase_sdxl-1.0_a3f8c2_123456789_v001.png
                                        └──────┘
                                        提示词哈希前6位

# 映射表（JSON）
{
  "a3f8c2": "cinematic night city chase, neon lights, rain, wide angle, 35mm film grain..."
}

本文评述：哈希映射方案在软件工程中很常见（如Git的commit hash），它用短标识符引用长内容，兼顾了文件名长度限制和语义完整性。但哈希的缺点是人工不可读，需要配套查询工具。建议在团队内部部署一个简单的Web查询界面，输入哈希即可看到完整提示词。

7.3 生成式流水线的命名自动化

在自动化流水线中，命名应由脚本统一生成，而非依赖工具默认。以下是一个ComfyUI工作流的命名节点思路（伪代码）：

def generate_filename(project, scene, shot_type, model, seed, version):
    date = datetime.now().strftime('%Y%m%d')
    prompt_hash = hashlib.md5(prompt.encode()).hexdigest()[:6]
    return f'{date}_{project}_{scene}_{model}_{prompt_hash}_{seed}_{version}'

# 在保存节点前调用
filename = generate_filename(
    project='PRJ01',
    scene='night-city-chase',
    shot_type='WS',
    model='sdxl-1.0',
    seed=123456789,
    version='v001'
)

这套方案的核心思想是：命名逻辑集中在一处，所有生成节点调用同一函数。这样当模板演化时，只需修改一个地方，避免散落在各处的命名规则不一致。

八、命名治理：从模板到组织共识

技术方案再完善，没有组织层面的治理也无法持续。这一节讨论命名治理的落地路径。

8.1 命名委员会与变更流程

建议设立轻量级的“命名委员会”（可由2-3人兼任），负责：

• 维护项目缩写注册表。
• 审批命名模板变更。
• 处理命名冲突申诉。
• 定期审计命名合规率。

模板变更应遵循类似API版本管理的流程：新字段先在小范围试点，验证后再推广；旧字段废弃需设置过渡期，期间新旧模板并行；变更记录写入CHANGELOG，通知所有使用者。

8.2 合规率度量与反馈

无法度量就无法改进。建议定期（如每周）运行校验脚本，统计合规率，并在团队看板上公示。合规率低于阈值时，触发提醒或培训。

指标	定义	目标值
命名合规率	合规文件数 / 总文件数	≥ 98%
缩写注册覆盖率	已注册缩写 / 实际使用缩写	100%
CI拦截次数	每周因命名不合规被拦截的提交数	趋势下降

表4：命名治理度量指标（笔者整理，目标值为经验参考）

本文评述：度量指标的设计要避免“唯合规率论”。如果团队为了达标而把不合规文件改名到临时目录，合规率上去了但问题没解决。建议同时关注“命名相关故障数”（如因命名问题导致的检索失败、脚本报错），从结果侧验证治理效果。

8.3 新人培训与文档

命名规范应纳入新人入职培训，且培训材料要包含：

• 模板速查卡：一页纸说明各字段含义与示例。
• 常见错误案例：展示不合规命名及其后果。
• 校验工具使用：演示如何运行校验脚本。
• 缩写注册流程：说明如何为新项目申请缩写。

文档应放在团队Wiki或代码仓库中，与代码一同版本控制。避免放在个人云盘或聊天记录里，否则很快失效。

九、前沿预判与开放问题

命名问题看似传统，但在新技术背景下正在产生新的研究课题。这一节讨论三个前沿方向。

9.1 基于嵌入的语义命名检索

传统命名检索依赖字符串匹配，无法处理语义近似。例如搜索“夜晚追逐”找不到命名为night-chase的文件。基于文本嵌入（Text Embedding）的语义检索可以解决这个问题。

具体思路：将文件名各字段拼接为文本，用Sentence-BERT等模型编码为向量，存入向量数据库（如Milvus、Qdrant）。检索时，将查询语句也编码为向量，做近似最近邻搜索。这样“夜晚追逐”可以匹配到night-chase，即使字面不同。

相关研究可参考Reimers & Gurevych (2019)的Sentence-BERT论文，以及向量数据库领域的综述（如Wang et al., 2021, Survey on Approximate Nearest Neighbor Search）。本文评述：语义检索的前提是命名本身有语义，如果文件名全是00001.png，再强的嵌入模型也无能为力。这再次说明命名模板是语义检索的基础设施。

9.2 大模型辅助的命名生成与纠错

大语言模型（LLM）可以用于：

• 命名生成：根据资产内容描述自动生成符合模板的文件名。
• 命名纠错：识别不合规命名并建议修正。
• 缩写推荐：根据项目全称推荐不易冲突的缩写。

但LLM的引入也带来新问题：生成结果不稳定（同一输入可能产生不同输出），需要额外的校验层。建议将LLM定位为“建议者”而非“决策者”，最终命名仍由确定性脚本生成。

9.3 开放问题

笔者认为，以下问题值得进一步研究：

1. 命名的跨语言问题：多语言团队如何统一命名？拼音、英文、本地语言如何取舍？
2. 命名的隐私与安全：文件名可能泄露项目信息、客户名称，如何在命名中平衡可读性与保密性？
3. 命名的长期归档：项目结束数年后，命名模板可能已废弃，如何保证旧资产仍可被检索？
4. 命名与元数据的边界：哪些信息应放入文件名，哪些应放入侧车文件（sidecar）或数据库？

这些问题没有标准答案，但值得每个团队结合自身场景思考。

视频动画 视频动画技术