GJB 3206A技术状态管理：标识、基线、更改与审核落地

简介：配置管理与产品数据管理的核心，是让设计、制造、交付各环节对“当前有效版本”有唯一、可追溯的定义。其原理是通过标识、基线、更改控制和记实审核，把产品功能与物理特性固化到受控文件中，并在变更时维持文实一致。技术价值在于降低版本错用、追溯断链和审核不符合项，提升研发、采购、生产与保障的协同效率。应用场景覆盖装备研制、PLM实施、质量体系审核和产品交付追溯。GJB 3206A-2010 的技术状态管理程序正是这一体系在装备领域的落地框架，围绕技术状态项、三类基线、I/II/III类更改、偏离许可与让步、功能与物理审核，给出可执行的职责、时机与表单。落地实践进一步讨论如何把PDF台账转为可查询数据，让基线、更改通知与版本记录在同一标识号下对齐。

1. 技术状态管理程序到底管什么：文实一致的四条主线

图纸改了三次，车间手里还是第一版；试验报告里的参数和最新规范对不上；产品交付两年后有人问某个组件换没换，翻遍邮件也拼不出证据链。这类问题的根子通常不在技术能力，而在技术状态没有被真正管住。GJB 3206A-2010 给出的框架是把技术状态管理拆成四条主线：标识解决"管哪些项、依据哪些文件"，控制解决"谁能改、按什么流程改"，记实解决"改过什么、痕迹在哪"，审核解决"文件写的东西和实物做出来的东西到底对不对得上"。

这份《技术经验状态管理程序》适用于装备类产品及其配套产品从方案到退役的全过程，主责部门是研发部，质管部负责监督，必要时成立技术状态控制委员会做审查决策。它最实用的地方在于把标准条文翻译成了可执行的职责、时机和表单要求。做 PLM 实施、产品数据管理或者质量体系的人读它，基本等于拿到一份字段级的建表说明——三类基线对应三类文件、三类更改对应三套审批链，全是能直接落进系统里的东西。

2. 技术状态标识落地：技术状态项、文件与三类基线

2.1 从产品分解结构到技术状态项的筛选逻辑

标识的第一步不是编文件号，而是确定颗粒度。程序要求先做产品分解结构，按 GJB 2116 的要求与工作分解结构单元对应，技术状态项必须能落到某个 WBS 单元上。这一步做粗了，后面基线的覆盖面就会出现空洞；做细了，控制成本会成倍上升，一个垫片都要走更改流程。

选择准则在程序里列了六条，实操中我一般把它转成一张判定表，逐条对一个候选节点打勾，命中两条以上才考虑设为独立技术状态项：

常见误用是把"重要的零件"全拉成技术状态项，结果一个产品挂出几百个项，记实数据量爆炸而关键项反而被淹没。我的做法是用上述准则粗筛一轮，再用"功能特性和物理特性能否被单独管理"这条复核一遍，过不了复核的降级为普通件，只跟着父项走。

2.2 三类技术状态文件与三类基线的对应关系

标识的核心产出是文件体系和基线。程序把技术状态文件分三类，分别对应三种基线，各自有明确的建立时机：

接口这一块容易被忽略。按 GJB 2737 的要求，订购方必须控制的接口要求要纳入功能技术状态文件或分配技术状态文件；在基线建立之前，承制方必须规定并控制分配技术状态文件中未规定的所有接口。判断口径是：设计的各类硬件和软件之间的兼容性，以及它们与文件中接口要求的一致性，都要能被证明，而不是靠口头约定。

2.3 标识号规则与唯一性校验

技术状态项和技术状态文件是两套标识号，各自都要唯一。编规则的常见做法是让号段本身携带语义——类型、产品代号、流水号三层就够了，层数再多没人记得住。下面这段脚本负责按规则生成和批量查重：

import re # 编号规则：CI-<类型码>-<产品代号>-<4 位流水号>，例如 CI-HW-A01-0007 CI_PATTERN = re.compile(r"^CI-(HW|SW|FW|DOC)-[A-Z0-9]{3}-\d{4}$") def make_ci_id(kind: str, product_code: str, seq: int) -> str: """kind 取 HW/SW/FW/DOC；product_code 为 3 位大写；seq 从 1 开始""" if kind not in {"HW", "SW", "FW", "DOC"}: raise ValueError(f"未知类型码: {kind}") if not re.fullmatch(r"[A-Z0-9]{3}", product_code): raise ValueError("产品代号必须为 3 位大写字母或数字") if not 1 <= seq <= 9999: raise ValueError("流水号超出 4 位范围") return f"CI-{kind}-{product_code}-{seq:04d}" def check_unique(ids): """返回格式错误与重复的编号清单，供标识评审会前自查""" seen, problems = set(), [] for i in ids: if not CI_PATTERN.match(i): problems.append(("格式错误", i)) elif i in seen: problems.append(("重复", i)) seen.add(i) return problems print(make_ci_id("HW", "A01", 7)) print(check_unique(["CI-HW-A01-0007", "CI-HW-A01-0007", "HW-A01-7"]))

类型码把硬件、软件、固件、文档分开，方便后续按类统计基线的完成率；产品代号与 WBS 单元对齐，避免同一产品在不同部门被编成两套号；四位流水号留出了扩展空间，定型后新增项直接续编而不用改规则。check_unique返回的是问题清单而不是布尔值，因为标识评审时真正需要的是"哪几个号出了问题"，直接贴进会议纪要即可。

2.4 基线建立的判定与维持

基线不是"感觉设计完了"就成立。程序写得很明确：基线通过转段技术审查的方式确定，审查按 GJB 3273 执行，建立的标志是组成基线的技术状态文件全部获得订购方确认。这里有两个高频坑：一是把"评审通过"等同于"基线建立"，实际评审意见落实后文件还要重新签署批准才算数；二是文件签完了但发放记录没留，后续追版本时找不到依据。

基线一旦建立，除产品寿命周期结束外一般不再撤销，而是靠更改来演进。这一点决定了记实数据的组织方式——所有记录都应挂在"基线 + 更改"这条时间轴上，而不是按年度归档，否则追溯时会出现版本断点。

3. 技术状态更改控制：I/II/III 类判定与申请闭环

3.1 三类更改的判定边界

更改控制的第一步是分类，分类错了，审批链就整个错位。程序把更改分成 I、II、III 类，判定要点如下表：

判定顺序建议固定为三步：先看是否触及基线，再看是否影响满足产品要求，最后才看文档形式。最常见的误用是反过来——先看改动量小就定成 III 类，省掉论证和评审，结果在定型审核时被判"更改类别不实"，反而要重做全流程。若订购方对类别有异议，双方协商后最终由订购方决定，这条要在程序文件里写明，避免现场扯皮。

3.2 更改申请单的字段设计与台账表

I 类、II 类更改必须编制更改申请，III 类可直接出更改通知。申请单的字段在程序里列了 a 到 k 共十一项，落到系统里就是一张台账表。下面这份建表语句把十一项映射成了字段，顺带保留了审批和通知的关联：

CREATE TABLE t_change_request ( cr_no VARCHAR(32) PRIMARY KEY, -- 更改申请标识号，全局唯一 raise_org VARCHAR(64) NOT NULL, -- 提出单位 raise_date DATE NOT NULL, -- 提出日期 change_class CHAR(3) NOT NULL CHECK (change_class IN ('I','II','III')), ci_no VARCHAR(32) NOT NULL, -- 受影响技术状态项编号 other_ci_no VARCHAR(255), -- 受影响的其他技术状态项 doc_no VARCHAR(64), -- 受影响的技术状态文件编号 affected_scope TEXT, -- 在制品、制成品、在役品范围 reason TEXT NOT NULL, -- 更改理由 content TEXT NOT NULL, -- 更改内容 impact TEXT, -- 对使用要求、指标、质量、进度、费用的影响 plan_date DATE, -- 计划实施日期 approve_org VARCHAR(64), -- 审批单位 approve_date DATE, -- 审批日期 notify_no VARCHAR(32), -- 对应技术状态更改通知编号 status VARCHAR(16) DEFAULT '草稿' ); -- 每周自查：仍未闭环的 I 类更改，按提出日期倒序盯办 SELECT cr_no, ci_no, raise_date, status FROM t_change_request WHERE change_class = 'I' AND (approve_date IS NULL OR notify_no IS NULL) ORDER BY raise_date;

cr_no做主键是为了满足唯一性要求，评审意见、验证报告都用它做外键挂载。affected_scope单独设字段而不是塞进impact，因为"受影响的产品范围"决定了要不要同步修改合同或协议，属于必须单独检索的维度。notify_no在审批通过后才回填，所以用approve_date IS NULL OR notify_no IS NULL就能筛出卡在审批或发放环节的项。

3.3 评审与审批链的组织方式

评审内容的固定三问是：受更改影响的技术状态项及其零部组件有哪些、更改的效果如何（包括不进行更改会带来什么影响）、更改产生的费用和实施进度是多少。组织方式随类别和寿命周期阶段变化，I 类通常要拉上设计、工艺、质量、采购和订购方代表。

审批环节的边界要记牢：III 类更改申请和设计定型前的 II 类更改申请由承制方自行审批，同时通知订购方，更改通知送订购方备案；I 类更改申请和设计定型后的 II 类更改申请必须经订购方审批。审批通过后，承制方把批准内容形成技术状态更改通知，经审批、发放到相关单位和部门，再组织相关部门把更改纳入技术状态文件。当更改影响到进度或费用时，还要同步修改合同或协议，这一步在台账里体现为plan_date的复盘而非简单延期。

3.4 偏离许可与让步：别当成更改的替代品

这两类单据最容易被混用，但法律性质完全不同。偏离许可是在技术状态项制造之前，承制方认为有必要临时偏离已批准的技术状态文件而提出的申请；让步是在制造期间或检验验收过程中，认为不合格品可以返修或原样使用时提出的申请。两者经批准后仅在指定范围和时间内适用，绝不能作为功能、分配或产品技术状态文件的更改依据——这一点如果搞混，后续基线文件会和实物永久性地脱节。

级别判定上，严重级以下的都算轻度级，出现下列任一项影响即属严重级：功能；功能接口或物理接口；互换性；形状、质量、质心；可靠性维修性测试性保障性安全性环境适应性电磁兼容性等特性；人员健康与安全；服役使用与维修；以及造成严重后果的其他方面。审批权限上，设计定型前的偏离许可和让步申请一般由承制方审批，设计定型后的由订购方审批。承制方还要按 GJB 571 对不合格品进行识别和控制，防止其非预期使用或交付。

4. 技术状态记实与审核：数据、报告与两类审核

4.1 记实的六类数据与载体要求

记实不是"把文件堆进档案室"，程序列了六件事：记录并报告各技术状态项的标识号、现行已批准的技术状态文件及其标识号；记录每一项技术状态更改从提出到实施的全过程；记录所有偏离许可和让步的状况；记录技术状态审核的结果，包括不符合状况和最终处理；记录并维持已交付产品的版本信息及产品升级信息；定期备份技术状态数据、维护数据安全。

载体上有个实操细节：记实数据可以用纸质或电子载体，但归档的数据需要有纸质载体，并按档案管理规定处理，同时保持完整性和正确性。无论采用哪种存储方式，都要保证需要时数据随时可用。我一般的做法是电子台账做日常检索，节点归档时打印成册并加盖受控章，两套数据用同一个标识号串联，避免出现"电子版有、纸版没有"的追溯断点。

4.2 状态报告清单与发送节奏

从方案阶段起就要开展记实活动，研制生产阶段需与订购方协商发送以下几类文件。把它做成一张节奏表，比临时被催要资料从容得多：

这张表的价值在于把"发送时机"从人的记忆里挪到了流程里。实际执行中，最容易漏的是第三项，因为未闭环项往往在多个部门之间流转，只有集中统计才会暴露。

4.3 功能技术状态审核与物理技术状态审核的分工

每一个技术状态项都要做功能技术状态审核和物理技术状态审核，两者的数据来源和先后关系完全不同：

基线是否真的"长在"文件上，可以用一段小脚本快速核对，把文件清单导成 CSV 后跑一遍：

import csv BASELINE_NEED = { "功能基线": {"功能技术状态文件"}, "分配基线": {"分配技术状态文件"}, "产品基线": {"产品技术状态文件"}, } def baseline_ready(rows, baseline): """rows 每行含 doc_type / doc_no / status / approved_by""" need = BASELINE_NEED[baseline] got = {r["doc_type"] for r in rows if r["status"] == "已批准" and r["approved_by"]} return need <= got, sorted(need - got) with open("cfg_files.csv", encoding="utf-8") as f: rows = list(csv.DictReader(f)) ok, missing = baseline_ready(rows, "分配基线") print("可提交基线确认" if ok else f"缺少已批准文件类型: {missing}")

判断条件同时校验status和approved_by，是因为基线建立的标志是"文件全部获得订购方确认"，只签了内部批准还差一步；missing返回文件类型而不是行号，方便直接写进审查会纪要。

4.4 审核组织与纪要闭环

审核组由订购方担任组长、承制方担任副组长，成员要有代表性和相应资质，正式审核之前承制方必须自行组织内部审核——这一步做扎实，外部审核的整改量能少一大半。审核完成后由组织者向各有关方发放审核纪要，纪要要记录完成情况和结果、解决遗留问题所必需的措施，并明确给出认可、有条件认可或不认可三种结论之一。

还有一条容易被漏掉的触发条件：产品的转产、复产需要重新进行功能技术状态审核。另外，根据产品复杂性可以开展预先的物理技术状态审核，这种预先审核可以与产品质量评审结合进行，相当于把风险前置消化。

5. 从 PDF 台账到可查询数据：把程序里的表单真正用起来

程序文本本身是 PDF 文档，很多单位的台账也是以 PDF 或扫描件形式归档的，检索起来只能靠翻页。用 pdfplumber 把台账表格抽出来转成结构化数据，再做交叉校验，是把这份程序落地成本最低的一步：

import pdfplumber # 从技术状态更改通知台账 PDF 中抽取表格 records = [] with pdfplumber.open("更改通知台账.pdf") as pdf: for page in pdf.pages: for table in page.extract_tables(): for row in table: if not row or not row[0]: continue cells = [c.strip() if c else "" for c in row] if not cells[0].startswith("GX-"): # 跳过表头行 continue records.append(cells) # 校验：同一技术状态项是否有多份生效中的更改通知 from collections import defaultdict by_ci = defaultdict(list) for r in records: by_ci[r[2]].append(r[0]) for ci, notices in by_ci.items(): if len(notices) > 1: print(f"注意：{ci} 存在 {len(notices)} 份更改通知，核对是否已合并")

extract_tables默认按页返回二维数组，遇到合并单元格会填None，所以清洗时要统一转成空串；用编号前缀过滤表头比按行号跳过稳妥，因为不同页的表头行位置可能不一致。跑完这一步，把结果灌进前面那张t_change_request表，就能直接出"未闭环项""重复项""基线覆盖缺口"三类清单。

最后几条自查线，是实际审核里出现频率最高的不符合项：更改申请有了但对应更改通知没编号、基线文件版本与实物技术状态不一致、偏离许可被当成更改依据写进了正式文件、已交付产品的版本记录停留在交付当月没有更新。每一条都能用上面两段脚本加一张版本对比表查出来，比等到审核现场再翻档案高效得多。核心口径只有一句：文件上写的、系统里记的、车间里做的，三者必须在同一个标识号下对得上。

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