国标图号编制方法：十进位编号与特征代号字典落地

简介：《国标图号编制方法》是一份面向机械与电气产品设计、标准化管理及图纸归档人员的内部规范文档，重点解决产品图样代号不统一、装配与零件标识混乱的问题。文档以十进位编号法为主线，系统说明图号可用字符、独立代号要求、多张图纸共号标注及表格图代号的取法，并给出标准产品、工程产品、试制产品的代号组成与实例，如GGD.1.055.001L、GGD.05001—01L、GGD.S1.055.001L的逐段释义，还附有零件特征代号分组表，便于按部类与组别查找归类。压缩包内共1个doc文件，约1.53MB，适合直接查阅或作为企业图号制度模板。已有578人学习下载，可用于统一设计、工艺与档案环节的编码口径，减少图纸流转中的误读与重复编号，并快速理解总装图、分装图、焊接图、零件图等类别代号的用法。

1. 图纸发到车间，装配工拿着两张几乎一样的图问哪张才对——这个场面我在两个项目里都撞见过。根子不在绘图，在图号。一套没有硬约束的编号，三个月内必然演化出GGD-1-55、GGD.1.55.1L、GGD001055L三种写法，设计端觉得只是格式差异，采购、工艺、售后拿到手就是三份对不齐的物料。国标图号编制方法这套方案要解决的就是这件事：用一套十进位编号规则，把产品型号、设计轮次、零件特征、序列号和图纸类别压进一个不超过二十个字符的代号里，让任何人只看代号就知道这是什么图、属于哪个产品、第几次设计、哪一类图纸。它适合正在做企业标准化文档的在校生当作课程设计或毕设的规范类选题，也适合制造企业里被要求出一份《产品图样编号办法》的技术管理人员直接拿去改。

2. 编号体系总体设计：十进位法与五段式代号的职责划分

2.1 为什么是十进位编号法，而不是纯流水号

最省事的编号方式是从 0001 开始一路排下去，谁先建图谁拿号。这套做法在图纸量到几百张时就会崩：流水号不携带任何分类信息，你拿到000432完全判断不出它是总装图还是垫圈图；图纸按产品成套交付时，得靠人肉去翻台账把同一产品的图挑出来；更麻烦的是跨产品冲突——两个设计员各自维护自己的号段，合并到一套系统里必然撞号。

十进位编号法的核心思路是把 000–999 这个编码空间按「部类 — 组 — 特征」三层切分，让代号本身携带分类语义。零件是什么大类，看百位段就能猜个八九不离十；同一产品的图纸，靠产品型号前缀天然聚在一起；新增零件只需要在字典里找一个还没被占用的特征代号，不用全局重排。代价是要先建一份特征代号字典，前期投入大，后面对齐成本低。

选十进位的另一个理由是它对齐了引用标准里对编号办法的一贯思路，标准产品、工程产品、试制产品三类代号能共用同一套字段语义，只是其中某一段换了含义。这一点在第 3 章展开。

2.2 五段式代号的字段定义与取值范围

标准产品的图样代号拆开是五段，用圆点分隔四个字段，最后一段紧跟类别代号，不额外加分隔符。字段定义必须先固定下来，否则后面所有规则都是空的。

一个完整的例子是GGD.1.055.001L：产品是 GGD，第一次设计，特征代号 055 落在「底、底板、箱底」这一组，是该特征下的第 001 个零件，类别 L 说明这是一张零件图。读代号的人不需要查台账就能判断用途，这是这套编码真正的价值。

提示：设计序号只给 1–9，这是草案里最容易被质疑的一处。产品改到第十次设计时没有位可用，通常的做法是把特征代号和序列号各扩一位，或者把设计序号改成两位并约定「01 视同 1」，但一旦改了位宽，历史图号就没法等长解析，所以要么开头就留两位，要么在规则里明确写死「第十次设计起另立型号」。

2.3 字符集与分隔符的硬约束

草案里限定的字符集只有三类：0–9 阿拉伯数字、A–Z 英文字母（O 和 I 除外）、以及短横线、圆点、斜线三种符号。排除 O 和 I 不是洁癖，是血泪经验——手写图纸、传真件、老旧扫描件里，字母 O 和数字 0、字母 I 和数字 1 的混淆率极高，一旦错了位，整串代号报废。

分隔符的约束更关键：每种符号只能承担一种语义，不能混用。约定是圆点做字段分隔，短横线只出现在工程产品里连接工程编号和序列号，斜线留给需要表达层级关系的场合。这三种符号在多数 ERP 和 PDM 的检索框里都不是通配符，直接输入能精确命中；但如果混进了全角符号、中文破折号、下划线，检索就会静默失效。

草案 4.4 的例子GGD.05001—01L里用的是一个全角破折号，而 3.1 明确规定只允许短横线。这不是排版问题，是规则自相矛盾，落地时必须统一成半角-，写成GGD.05001-01L。类似的还有类别代号里的小写z（展开图），跟其他全大写代号混在一起，输入时大小写敏感的系统会直接查不到。

2.4 唯一性与「共几张、第几张」的处理

规则里有一条容易被忽略但极其重要：每个产品的装配、部件、零件必须要有独立代号。这句话的反面是——不允许两个不同的零件共用一个号，也不允许同一个零件在不同产品里复用同一个号。

另一条是多张图纸的处理：同一产品、部件、零件的图样需要画在数张图纸上时，各张图纸标注同一代号，用「共几张、第几张」加以区别。这里的实现方式通常是代号不变，在图框标题栏里加两个小字段，比如共3张 第1张。注意这个信息不进代号本体，只进标题栏和图纸属性，否则代号长度不可控。

表格图是另一个特例。用一张表格图表达多种规格的零件时，表中每一行规格都必须标出独立代号，而不是整张表共用一个号。这一条如果不写死，采购下单时按表格图号采购，供应商根本不知道要哪个规格。

3. 三类产品代号的结构拆解：标准、工程、试制的差异点

3.1 标准产品：五段式的基准形态

标准产品指按型号批量生产、不绑定具体工程的产品，代号形态就是第 2 章定义的型号.设计序号.特征代号.序列号类别代号。

解析逻辑可以写成一个函数，把代号拆成结构化字段，供后续检索和校验复用。下面这段是解析器的核心部分，处理标准产品和试制产品两种形态。

import re # 类别代号白名单，必须与《编号办法》附录保持一致 CATEGORY = {"Z", "F", "H", "L", "K", "z", "TM", "CB"} # 标准产品：型号.设计序号.特征代号.序列号+类别 STD_PATTERN = re.compile( r"^(?P<model>[A-Z]{2,6})\.(?P<design>[1-9])\.(?P<feature>\d{3})\.(?P<seq>\d{3})(?P<cat>TM|CB|[ZFHLKz])$" ) def parse_std(code: str) -> dict: """解析标准产品图号，失败时抛出带原始输入的异常，便于批量体检定位""" m = STD_PATTERN.match(code) if not m: raise ValueError(f"代号格式不合法: {code}") d = m.groupdict() if d["cat"] not in CATEGORY: raise ValueError(f"未知类别代号: {d['cat']}") return d # 示例 print(parse_std("GGD.1.055.001L")) # {'model': 'GGD', 'design': '1', 'feature': '055', 'seq': '001', 'cat': 'L'}

这里有两个设计取舍值得说明。第一，类别代号放在正则的末尾分支里，且把两位的TM、CB排在一位字母前面，否则正则会先匹配到T就停下来，GGD.1.055.001TM会被误判。第二，design限定为[1-9]而不是\d，因为 0 不合法，用\d会放过GGD.0.055.001L这种脏数据。

model段限定 2–6 位大写字母，是为了拦住混进来的数字和小写。实际项目里型号长度超过 6 位的情况不多，但如果产品线里有，改这个量词就行，改完记得同步更新规则文档里的位数说明。

3.2 工程产品：工程编号顶替设计序号

工程产品是按具体项目定制的非标产品，代号结构把第二段从「设计序号」换成了「工程编号」，取值范围 05001–05999，前两位表示年份后两位，后三位表示该年第几个工程。GGD.05001-01L读作：GGD 产品，2005 年第 1 个工程，该工程下第 01 个非标零件，零件图。

工程编号这一段有个强烈建议：优先直接使用合同号。理由是可追溯性——工程类产品最怕的是三年后客户来要图纸，你拿图号反查不到是哪个项目、哪个合同、哪次变更。用合同号做工程编号，图号到合同到客户是一条直链，中间不需要任何映射表。代价是合同号通常比五位长，得先定一套压缩规则，比如取合同号后五位加年份位，压缩规则本身也要写进办法里，不能口口相传。

注意工程产品的分隔符用法：工程编号和序列号之间是短横线-，不是圆点。这条如果不强调，实际画图时十个有八个会写成GGD.05001.01L，然后检索全崩。

3.3 试制产品：S 段的插入位置

试制产品的代号在型号后面插两段：试制代号S和试制序号1–9，后面再接特征代号、序列号、类别代号。GGD.S1.055.001L表示 GGD 产品第一次试制、特征 055、第 001 个零件、零件图。

为什么试制要单独占位而不是和正式产品共用一套号？因为试制件的图纸和正式件在工艺、材料、检验要求上完全不同，混在一套号里，一旦试制转量产，历史图纸的版本追溯就断了。独立号段的好处是试制件作废时整段归档，不影响正式产品线。

试制序号只到 9，说明规则假设试制轮次不会太多，这个假设在多数场景下成立。但试制的类别代号在草案里是「试制总装图 Z、试制分装图 F」这样描述的，实际编码时字母和正式产品完全一样，区别只在前缀的S。这一点要在文档里写清楚，否则有人会以为试制件要用两套字母表。

3.4 三类代号的结构对照

把三类代号拉平了看，差异其实只在第二段。

看清这张表，就明白为什么三类代号能共用一套字典：特征代号和序列号的语义完全一致，类别代号的字母表也一致，变的只是「这批图属于哪个批次」。这种设计让 PDM 系统可以用一张表存所有图号，靠一个doc_type字段区分类型，检索逻辑不用分三套写。

3.5 多规格表格图的编号落地

表格图在成套设备里很常见，比如一张「铜排规格表」覆盖十几种截面尺寸。规则要求表中每种规格标独立代号，实现上有两种做法：一是特征代号不变、序列号递增，一张表里出现...001L到...012L；二是把规格参数本身编进特征代号的分组里。前一种更好维护，因为规格增删只动序列号，不动字典；后一种在规格多且稳定的场景下检索效率更高。

不管选哪种，都要在图纸的明细栏里体现——表格图的主代号只标识这张表本身，具体到某一规格时，引用的是表内行号对应的独立代号。装配图画明细时填的是行内代号，不是主代号，这一点不写清楚，BOM 展开必错。

4. 特征代号字典：部类组的划分逻辑与查表落地

4.1 部类—组—特征代号的三层结构

特征代号是这套体系里工作量最大、也最容易被糊弄过去的部分。它采用三层结构：部类（百位段）、组（十位段）、特征代号（个位段加细分）。000–999 分给不同的功能大类，每个大类里面再按具体形态细分到组，组内再顺排具体代号。

划分逻辑不是按零件名称，而是按功能加形态。同样是「板」，安装板、连接板、垫板、挡板分在不同的部和组里，因为它们的装配角色不同——安装板属于「面板、安装板」组，连接板属于「筋、连接板、撑条」组，垫板属于「板、片、衬垫」组。这个划分一开始会觉得反直觉，用熟了才发现它比按名称索引准得多，因为零件名称本身在厂里就不统一。

4.2 组内取值与「其他」兜底

每个组内通常预留三类位置：具名代号（如 055 对应「底、底板、箱底」）、工艺变体（铸造 / 冲压 / 塑料各占一个号）、以及每组末尾的「（其他）」。兜底号很重要，它让新零件有地方放，不至于为了一个新结构去改字典。但兜底号不能滥用——如果一个组的「其他」占了该组一半以上的编号，说明这个组的划分粒度错了，应该拆组。

举一个具体例子看工艺变体怎么排：躯壳组的 001 是通用躯壳，003 是铸造躯壳，004 是冲压躯壳，005 是塑料躯壳。同一个功能件，工艺不同就给不同号，因为工艺决定了下游的工时定额、检验项和供应商类型，图号必须能区分。这条规则在钣金和注塑并存的厂里尤其重要。

注意：字典一旦发布，已占用的代号不能再分配给其他零件，哪怕那个零件已经停产。停产的号做逻辑删除标记，号段永久保留。这条如果破了例，五年后的历史图纸检索会彻底失效。

4.3 字典落库：表结构与维护规则

字典不能只活在一份 Word 附录里，得进数据库才能被 PDM 和 BOM 系统调用。最小可用的表结构大致是这样。

-- 特征代号字典表，一条记录对应一个「部类-组-代号」三元组 CREATE TABLE feature_code_dict ( feature_code CHAR(3) NOT NULL PRIMARY KEY, -- 001~999，全局唯一 class_no CHAR(3) NOT NULL, -- 所属部类，如 000、200、900 group_no CHAR(3) NOT NULL, -- 所属组，如 050、220 feature_name VARCHAR(64) NOT NULL, -- 标准名称，如「底、底板、箱底」 alias_names VARCHAR(255) DEFAULT NULL, -- 别名，逗号分隔，供模糊检索 apply_scope CHAR(1) NOT NULL DEFAULT 'A', -- A=装配/部件/零件通用, P=仅零件 status CHAR(1) NOT NULL DEFAULT '1', -- 1=启用, 0=已停用（保留号段） created_by VARCHAR(32) NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- 按部类查可用代号，新零件选号时用 SELECT feature_code, feature_name FROM feature_code_dict WHERE class_no = '200' AND status = '1' ORDER BY feature_code;

几个字段的设计意图要说清。status用逻辑删除而不是物理删除，是保住「号段永久保留」这条规则；alias_names让设计员用厂里的俗称也能搜到标准名，这一列的实际使用频率往往比feature_name还高；apply_scope用来区分零件专用代号和通用代号，因为部件和零件的特征划分粒度不一样，同一个号不能两边都发。

维护权限也要收口。字典的增改只允许标准化岗操作，设计员只能查不能加。新零件找不到合适代号时走申请流程，由标准化岗判断是复用现有号还是新增号，新增号必须检查是否与停产号冲突。这套流程听着繁琐，但不收口的话，一年之内字典就会被各种临时新增撑爆。

4.4 批量体检：把历史图号洗一遍

规则发布时，历史图号一定有一批不合规的。与其人工翻，不如写个批处理脚本先体检，输出问题清单再逐条定性。

import re, csv # 三类代号的统一校验：先判类型，再套对应正则 PATTERNS = [ ("STD", re.compile(r"^[A-Z]{2,6}\.[1-9]\.\d{3}\.\d{3}(TM|CB|[ZFHLKz])$")), ("ENG", re.compile(r"^[A-Z]{2,6}\.\d{5}-\d{2}(TM|CB|[ZFHLKz])$")), ("TRIAL", re.compile(r"^[A-Z]{2,6}\.S[1-9]\.\d{3}\.\d{3}(TM|CB|[ZFHLKz])$")), ] def check(code: str): code = code.strip() for name, pat in PATTERNS: if pat.match(code): return name, "OK" # 常见错误单独给出可读原因，减少人工判断 if "—" in code or "－" in code: return "UNKNOWN", "含全角破折号，应改为半角短横线" if re.search(r"[OI]", code): return "UNKNOWN", "含禁用字母 O 或 I" if "_" in code or "/" in code and "." not in code: return "UNKNOWN", "分隔符不符合约定" return "UNKNOWN", "格式不匹配任何一类代号" # 批量处理导出的图号清单，结果落到 CSV 供人工复核 with open("codes.csv", encoding="utf-8") as f, open("report.csv", "w", newline="", encoding="utf-8") as out: w = csv.writer(out) w.writerow(["code", "type", "result"]) for row in csv.reader(f): if row: w.writerow([row[0], *check(row[0])])

脚本的价值不在于自动改号，而在于把「格式错误」和「语义错误」分开。格式错误（全角符号、小写字母、位数不对）可以批量修；语义错误（特征代号与零件实际类型不符、序列号重复）必须人工判断，因为机器不知道那个零件到底是什么。我一般会先跑一遍格式体检，把能自动修的修掉，剩下的按问题类型分组，交给对应的设计组确认。

apply_scope那个字段在这里也用得上：如果体检发现某个部件图用了「仅零件」范围的代号，那就是语义冲突，得单独列出来。

5. 避坑与常见问题排查

5.1 现象：检索图号查不到，明明台账里有

原因几乎都是字符不一致。台账里存的是全角破折号或者中文圆点，实际图纸标题栏里是半角；或者字母O被当成数字0录进去；又或者类别代号小写z在大写敏感的数据库里匹配失败。这类问题在批量导入历史数据时集中爆发。

解决分三步：先把字典和台账做一次字符规范化，全角转半角、破折号转短横线、统一大小写；再在入库环节加一道正则校验，不合规的直接拒收而不是静默存进去；最后在检索端做输入预处理，用户输什么都能先规范化再查。第三道是兜底，前两道才是根治。

5.2 现象：同一张装配图被编了两个号，BOM 展开后数量翻倍

原因通常是两个人分别建图，或者试制件转量产时重新编了号而没有做号段映射。还有一种隐蔽情况：表格图的某一行被单独抽出来画成独立图纸，画图的人给了新号，但没把新号回填到表格图里。

解决办法是把「一号一图」做成系统级的硬约束，建图时先查重。查重不只查完全相同的代号，还要查「同产品 + 同特征代号 + 同序列号、只有类别代号不同」的组合，因为这类组合往往是同一零件的不同视图被拆成了两张图。试制转量产要建映射表，一条试制号对应一条正式号，历史图纸的引用关系按映射表重定向，不能直接改号。

5.3 现象：特征代号越用越乱，同一个零件在不同项目里给了不同的号

原因是字典没有唯一权威源，各组自己维护一份 Excel，时间一长就分叉了。还有一种是设计员图省事，找不到合适的就直接扔进「其他」组，导致兜底号被大量占用。

解决的核心是收口：字典只允许一个源，其他人只读；新增代号走申请审批，审批时强制填写「为什么不复用现有代号」；定期统计各组「其他」号的使用率，超过阈值就组织拆组。我一般会每季度拉一次使用率报表，把排名前几的「其他」组挑出来重划，成本不高但效果明显。

5.4 现象：工程产品图号查不到对应项目，客户要图纸时找不到

原因是工程编号用了自定义流水，跟合同号没有映射，或者映射表存在某个人的本地文件里。工程结束人员调动，映射关系就断了。

解决是强制用合同号派生工程编号，并把派生规则写进办法正文而不是附录。派生规则要满足两个条件：可逆（能从工程编号反推合同号）和定长（保证代号长度一致）。如果合同号实在没法直接压缩，至少要在 PDM 里建一张工程编号与合同号的对应表，且这张表要跟图纸一起归档，不能只存在系统里。

5.5 现象：图纸改了版，图号没变，车间拿到的还是旧图

这是版本管理的问题，不是编号的问题，但两者经常被混为一谈。规则里写的是「各张图纸标注同一代号」，有人就理解成改了版也不用动号，结果新图和旧图共用一个号，靠人工在标题栏里看日期区分。

正确的做法是图号标识的是「这个零件」，版本标识的是「这个零件的第几版」，两者分离。图号永远不变，版本号在标题栏和 PDM 里独立管理，加版次控制字段并锁定旧版。任何对外发放的图纸必须带版本标识和发放记录，不能只发一张光图。

6. 怎么验收这套编号办法：抽检、追溯演练与答辩要点

规则写完不等于落地。验收要拿真实数据跑，不能只看文档写得漂不漂亮。

第一件事是抽样体检。从历史图纸里随机抽 100 张，覆盖标准产品、工程产品、试制产品三类，用第 4 章的脚本跑一遍，统计格式合规率和语义合规率。格式合规率应该能到 100%，因为这是机器能判的；语义合规率能到 85% 就算不错，剩下的要逐个定性。

第二件事是追溯演练，这是最能暴露问题的一环。随便挑一个已交付的工程项目，从客户合同号出发，要求在三分钟内查到：整柜总装图号、关键部件图号、任意一个非标零件图号、对应的材料明细表号。反向再来一遍，从任意一个零件图号查到它属于哪个合同、哪次设计、哪张装配图。两次都走通，说明编号体系是闭环的。

第三件事是拿一份规则文档本身做交叉检查。把草案里所有举例逐个用正则跑一遍，看有没有自相矛盾的地方。第 2 章提到的全角破折号和小写z就是这么发现的——举例和规则条款打架，是最容易被评审专家抓住的点，也是最容易自己改掉的点。

如果这份东西要拿去答辩，讲的重点不要放在「我写了一份规范」，而放在「我怎么证明这套规范能跑」。带上那张抽样体检的统计表、追溯演练的路径截图、字典的使用率报表，比讲十条原则有用得多。评审最常问的两个问题是「设计序号只有一位，产品改到第十次怎么办」和「特征代号谁来维护、怎么防止乱加」，这两个问题提前准备好答案，基本就稳了。

从那以后我每次做这类标准化文档，都会强制走一遍「举例反查规则」的流程——把所有示例代号丢进校验脚本跑一遍，跑不过就说明文档里埋了雷。这个习惯帮我拦下过好几次全角符号和位数不一致的问题，省掉了发布之后被现场追问的尴尬。希望帮到你。

本文还有配套的精品资源，点击获取