4. AIT交付策划与文件体系

AIT（Assembly, Integration and Test，总装、集成与测试）交付不是把产品交出去那一刻才发生的事，而是从策划阶段就通过一套文件体系把"交付什么、按什么测、怎么判、谁签字"固定下来。文件体系的核心作用是把分散在总体、分系统、测试、质量各方的意图，收敛成可执行、可追溯、可复现的受控文本。本节围绕交付计划、测试大纲、测试细则、测试报告、评审文件五类主干文件，说明它们之间的层级关系、内容边界，以及文件树组织与版本控制的实际做法。

五类主干文件的层级与内容边界

这五类文件不是并列关系，而是自上而下逐级细化、自下而上逐级回证的关系。交付计划回答"交付哪些产品、分几批、每批包含什么、里程碑在哪"；测试大纲回答"每批产品要验证哪些指标、依据哪条要求、用什么方法"；测试细则回答"具体怎么接线、加什么激励、采哪些点、判据阈值是多少"；测试报告回答"实际测到了什么、是否满足、偏差如何处理"；评审文件则是在关键节点把上述证据组织起来供专家审查。层级越往下，可执行性越强，参数越具体。

以某型号太阳翼驱动机构（SADA）单机交付为例，交付计划中会写明"第2批交付2台SADA正样产品，交付节点为T+180天，随交付提交验收测试报告与数据包"；测试大纲据此列出"输出力矩精度、空载电流、位置保持精度、热循环后功能"等验证项，并标注每项对应的总体要求条款号；测试细则则把"输出力矩精度"展开为具体工况：母线28V±0.5V、负载力矩0.5～3.0N·m阶梯加载、采样率1kHz、每点稳定30s后取均值、判据为偏差≤±2%FS。测试报告记录实测均值、最大偏差、环境条件与设备编号，评审文件则汇总大纲符合性矩阵、报告结论与遗留问题清单。

文件树组织：按产品结构还是按阶段

文件树有两种常见组织方式：按产品结构（WBS）和按AIT阶段。工程上更实用的是"产品结构为主、阶段为辅"的混合树，因为同一产品的测试大纲、细则、报告天然聚在一起，便于成套提交和版本对齐。典型文件树如下：

SADA-AIT/
├─ 00_交付计划/
│   ├─ SADA-AIT-DP-001_交付计划_A.docx
│   └─ SADA-AIT-DP-001_交付计划_变更记录.xlsx
├─ 01_测试大纲/
│   ├─ SADA-AIT-OT-001_验收测试大纲_A.docx
│   └─ SADA-AIT-OT-002_环境试验大纲_B.docx
├─ 02_测试细则/
│   ├─ SADA-AIT-TP-001_力矩精度测试细则_A.docx
│   ├─ SADA-AIT-TP-002_热循环测试细则_A.docx
│   └─ SADA-AIT-TP-003_EMC测试细则_A.docx
├─ 03_测试报告/
│   ├─ SADA-AIT-TR-001_力矩精度测试报告_A.docx
│   ├─ SADA-AIT-TR-002_热循环测试报告_A.docx
│   └─ SADA-AIT-TR-003_EMC测试报告_A.docx
├─ 04_评审文件/
│   ├─ SADA-AIT-RV-001_出厂评审材料_A.pptx
│   └─ SADA-AIT-RV-001_评审意见闭环表_A.xlsx
└─ 05_数据包/
    ├─ RAW/            # 原始采集数据，只读
    └─ PROCESSED/      # 处理结果与图表

编号规则建议采用"产品代号-文件类别-序号-版本"结构，例如 SADA-AIT-TP-001_A 表示SADA产品AIT阶段第1份测试细则A版。类别码固定为DP（交付计划）、OT（大纲）、TP（细则）、TR（报告）、RV（评审），这样在文件系统中排序即按类别聚集，检索时不必依赖记忆。

版本控制：状态、标识与变更闭环

AIT文件的版本控制不只是改文件名加日期，而要管理"文件状态"和"变更影响"。推荐用三段式版本标识：草稿版用0.x（如0.1、0.2），首次受控发布用A版，之后每次受控更改依次B、C版。草稿版可自由迭代，一旦进入A版，任何修改都必须走变更单，并在文件首页的修订记录表中登记：版本号、变更内容摘要、变更依据（如"总体要求QR-2024-017"）、更改人、批准人、生效日期。

版本控制的关键是"上下游联动"。当测试大纲从A版升到B版，必须检查：对应的测试细则是否需同步修订、已完成的测试报告是否仍适用、评审文件中的符合性矩阵是否需更新。实践中可用一张"文件关联与版本状态表"来跟踪，避免出现大纲已B版而细则仍引用A版条款的错配。

表中"待升版"提示细则需随大纲B版同步修订，这就是版本联动的实际落点。数据包中的RAW目录应设为只读并记录采集时间戳与设备编号，PROCESSED目录中的处理脚本也应纳入版本控制，确保报告中的曲线可由原始数据复现。

实操要点：从策划到放行的检查闭环

文件体系落地时最容易出问题的三个环节：一是大纲与细则的判据不一致，例如大纲写"偏差≤±2%FS"而细则写"≤±2.5%FS"，评审时会被直接质疑；二是报告引用了旧版细则，导致测试条件与判据无法对应；三是评审文件中的符合性矩阵漏项，某个大纲验证项在报告中找不到对应记录。建议在出厂评审前做一次"三向核对"：大纲验证项清单、细则工况清单、报告实测项清单逐条对齐，任何一项缺失或版本错配都必须在评审前闭环。

对于交付计划中的批次划分，还要注意与测试资源的匹配。若第2批2台SADA共用一套力矩测试台，计划中应明确串行测试顺序与单台占用周期，避免出现"计划节点已到但测试台排不开"的情况。这类资源约束应在交付计划阶段就写入，而不是等到细则执行时才发现。

综上，AIT交付文件体系的价值在于把"交付"从一次动作变成一条可追溯的证据链：计划定边界，大纲定验证项，细则定操作与判据，报告定实测结论，评审文件定放行。文件树让这条链在工程上可检索、可成套提交，版本控制让这条链在变更中保持自洽。掌握层级边界与版本联动，是AIT交付策划能否真正落地的基础。