企业官网建设流程全解析

做尺寸工程的朋友应该都有过这种经历：项目节点一到，公差分析结果要更新，几十个零件的公差数据分布在好几张Excel表格里，手工整理要花半天时间，跑到DTAS 3D里做一轮尺寸公差分析，出来又是上千行仿真数据，还得自己统计超差率、排查哪个尺寸链环节贡献最大。这个过程重复性强、又容易出错，每次项目切换几乎都要再来一遍。这篇文章就聊聊我用Python把公差仿真流程打通的经验——从数据清洗、批量配置到仿真结果的二次分析和报告自动生成，让Python和DTAS 3D这套尺寸链分析软件真正形成一条能自动跑起来的流水线，希望对做尺寸工程、制造工艺、质量管理的朋友有点参考价值。

1. 公差仿真的核心逻辑与Python的切入点

1.1 先把尺寸公差分析和尺寸链分析这件事说透

很多刚接触这块的同行容易把"尺寸公差分析"和"尺寸链分析"当成两个独立的东西，其实它们是同一件事的不同层面。简单点说，任何一个装配体里，最终我们要保证的往往是某一个关键质量特性，比如车门和车身之间的间隙、手机屏幕和中框之间的段差、轴承安装后的径向跳动。这个特性不是凭空来的，它是多个零件尺寸通过装配关系传递叠加的结果，用行业里的黑话讲，这一串相互关联的尺寸构成了一个封闭的尺寸链。

尺寸链里的每一个环节，都有它的名义尺寸和公差带。名义尺寸确定了理想状态下的装配结果，公差带则决定了每个环节允许波动的范围。问题是，这些波动会沿着装配路径一层层传递下去，最终叠加在目标特性上。如果每个零件都做到公差上限，或者都做到公差下限，甚至头尾零件反向偏差，最终目标可能就超差。这就是为什么不能只靠"老师傅经验"来判断，必须做系统性的公差仿真。

在方法层面，最传统的做法是极值法，也就是把所有公差简单相加，假设最极端的情况全同时发生。这个方法很保守，算出来的结果往往宽到没法用，导致制造部门抱怨公差太紧、成本太高。后来有了均方根法（RSS），假设各尺寸独立且服从正态分布，用方差叠加的方式来估算总公差，比极值法合理一些，但它要求分布假设很强，对非正态、偏态的情况处理不好。再后来就是蒙特卡洛法，计算机先生成大量随机样本，每个样本对应一组零件尺寸的随机取值，然后通过装配关系模型算出目标特性的分布，最后统计出超差概率、分布的均值方差等指标。DTAS 3D这类三维公差分析软件，核心就是干这件事的，而且它能在三维模型基础上自动提取装配路径和尺寸链，比传统手算一维链要省力得多。

1.2 DTAS 3D能解决什么问题

DTAS 3D是我一直在用的三维公差分析与尺寸链分析软件，它在实际项目里的价值主要体现在三个维度。

第一个维度是建模效率。以前做尺寸链分析要手工画链图、人工定义传递关系，费时费力还容易漏环。DTAS 3D可以在三维CAD模型上直接定义零件上的被测特征、基准特征和装配约束，软件自动识别装配路径，建立闭环尺寸链。这样一来，复杂装配体的公差模型可以从几天压缩到几小时。

第二个维度是计算能力。它内置了蒙特卡洛仿真引擎，可以快速生成几万甚至十几万个虚拟装配样本，模拟实际生产中的随机波动组合。仿真结果能输出目标特性的统计分布，还能进行敏感度分析和贡献率分析，告诉我们总公差里哪个组成环的影响最大、应该优先收紧哪个零件的公差。

第三个维度是数据管理。DTAS 3D支持公差数据与CAD模型关联，工程变更后公差数据可以同步更新，避免图纸改了、公差表没改的尴尬。

不过说实话，这款软件在小批量、多项目的企业里有个尴尬的地方：每次仿真前后，输入数据整理和结果后处理占的时间往往比仿真本身还长。尤其是涉及方案对比的时候，可能要做五六组甚至十几组公差方案的仿真，人工一组一组去设置参数、导出结果、对比表格，整个流程非常碎，这就是Python能发挥价值的地方。

1.3 Python到底能插手哪些环节

我先说清楚一个立场：Python不是用来替代DTAS 3D做尺寸链计算的，它的角色更像是打通工序之间的"自动化胶水"。

以我实际项目里的经验，Python能插手的环节主要有四个。一是数据准备阶段，把散落在不同Excel、图纸、ERP导出文件里的公差和尺寸数据，统一清洗成DTAS能识别的标准格式，同时做数据质量校验。二是批量配置阶段，当需要做多组方案对比（比如不同公差分配方案，或者对某个零件做"假设公差放宽"的场景模拟）时，用脚本批量生成DTAS可识别的参数文件，替代人工逐项修改。三是结果分析阶段，DTAS仿真出来的原始数据通常是大量的采样结果，用Python做统计分析、分布拟合、过程能力估算、帕累托排序，比打开Excel做透视表灵活得多。四是报告输出阶段，把分析结果自动整理成规范的Word或Excel报告，附上图表和结论，减少整理材料的时间。

这套路通用性很强，哪怕你用的不是DTAS而是其他三维公差分析软件，比如3DCS或者VisVSA，数据接口不一样，但"Python负责上下游、仿真软件负责核心计算"的分工思路是完全共通的。

2. 核心细节：Python与DTAS 3D的协同工作流

2.1 输入端自动化：Excel和CSV数据的批量整理

公差数据在现实项目里从来不是整齐划一的。最常见的来源是设计部门维护的《零件公差明细表》，一张大表里包含零件号、特征编号、名义尺寸、公差上下限、公差分布类型（正态/均匀/三角等）、过程能力指数Cp/Cpk，有的还有GD&T条例描述。问题在于，不同工程师维护表格的习惯不一样，有的用"0.5±0.1"这样的表达式，有的分开写上偏差和下偏差，有的单位用毫米，有的用微米，还有的干脆在备注里写一句"参考图纸"。

这种数据如果不做清洗，直接塞给DTAS 3D，轻则换算错误，重则公差定义莫名其妙。我的做法是先用pandas把Excel原表读进来，统一做标准化。

import pandas as pd import numpy as np # 读取原始公差表 df_raw = pd.read_excel("零件公差明细表.xlsx", sheet_name="Sheet1") # 统一列名为英文，方便后续处理 df_raw.rename(columns={ "零件号": "part_no", "特征名称": "feature", "名义尺寸(mm)": "nominal_mm", "上偏差(mm)": "usl_mm", "下偏差(mm)": "lsl_mm", "分布类型": "distribution", "CPK": "cpk" }, inplace=True) # 单位统一：如果存在微米列，这里演示统一转为毫米 epsilon = 1e-9 if "公差(μm)" in df_raw.columns: df_raw["tolerance_mm"] = df_raw["公差(μm)"].astype(float) / 1000.0 # 数据质量检查：缺失值、上下限颠倒、名义值明显异常 print("缺失值概览：") print(df_raw.isna().sum()) # 检查上下偏差是否合法 invalid_tol = df_raw[(df_raw["usl_mm"] <= df_raw["lsl_mm"]) & df_raw["usl_mm"].notna()] if len(invalid_tol) > 0: print(f"发现 {len(invalid_tol)} 条上下偏差异常记录，请人工复核。") print(invalid_tol[["part_no", "feature"]])

这里面有个很实用的细节：公差上下限颠倒这种情况，人工看Excel时很容易漏掉，但脚本一查一个准，尤其是大批量零件的时候。单位不统一的问题也是自动化流程里最常见的坑，我后来强制规定所有清洗后的中间文件一律使用毫米作为唯一单位，并在文件头写明单位，杜绝后面再看错。

清洗完的数据，再通过一个映射函数转换成DTAS 3D需要的输入模板格式，比如把分布类型从"正态""均匀""三角"这些中文描述映射为软件内部识别的枚举值，这一步最好是做成配置文件，用字典映射，方便以后扩展。映射关系可以维护在一份YAML或者单独的CSV里，不要硬编码在脚本中，否则每次加一种分布类型都要改代码。

2.2 仿真参数批量配置：用模板化代替手工录入

DTAS 3D做一轮标准仿真，要设置的参数其实不多，无非是零件模型、公差定义、装配顺序、测量目标特征、仿真次数等。但如果要做公差优化方案对比，工作量就上来了。比如一个白车身项目，我们要评估侧围、门盖、翼子板三个区域共十几个测量点的间隙和面差，每一项都要跑几组"放宽公差"或者"收紧公差"的假设方案。

这种场景下，我习惯把DTAS的工作目录和仿真配置文件做成"模板+变量"的结构。模板是一个标准的仿真工程目录，变量就是每次要替换的公差数值、分布类型和仿真次数。Python这边用一个简单的增删改查逻辑去修改模板里的公差定义文件，然后自动拷贝生成一组新的工程目录，交给DTAS批量计算。

import shutil from pathlib import Path template_dir = Path("./dtas_template") output_root = Path("./sim_batch") output_root.mkdir(exist_ok=True) # 方案定义：每个方案包含需要修改的零件公差 scenarios = { "base": {"door_hinge_tol": 0.5, "body_aperture_tol": 1.0, "sim_times": 10000}, "opt_hard": {"door_hinge_tol": 0.2, "body_aperture_tol": 0.8, "sim_times": 30000}, "opt_loose": {"door_hinge_tol": 0.8, "body_aperture_tol": 1.2, "sim_times": 30000}, } for name, params in scenarios.items(): target_dir = output_root / name shutil.copytree(template_dir, target_dir, dirs_exist_ok=True) # 这里读取模板中的公差定义文件并替换数值 tol_file = target_dir / "tolerance_def.txt" content = tol_file.read_text(encoding="utf-8") for key, value in params.items(): content = content.replace(f"${{{key}}}", str(value)) tol_file.write_text(content, encoding="utf-8") print(f"方案 {name} 已生成，仿真次数设置为 {params['sim_times']}")

这段代码里用${变量}做占位符替换，是我一直在用的小技巧。模板文件里只写占位符，脚本统一替换，这样保证了所有方案之间的差异是显式的、可控的，不会出现"这次不知道跟上次哪里不一样"的尴尬。

这个批量生成思路执行下来，一个原本要下午才能手工搞完的十组方案对比，脚本几分钟全建好，而且每个方案的设置天然具备可重复性。后面再有新项目，只要把字典里的参数改一下就行，整个项目周期里这块时间基本压缩到接近零。

2.3 结果数据导出与二次分析

DTAS 3D仿真完成后，输出的结果数据一般会包含每个测量目标的名义值、仿真均值、标准差、最小值、最大值、超差率，以及各组成环对目标特性的贡献率分析。有些情况下还能直接导出每次采样的详细值，也就是蒙特卡洛抽样结果列表。这些数据导出成CSV后，就到了Python的"主场"。

我的标准做法是先把结果文件聚合成一个总表，然后做三层分析：第一层是统计特征，包括均值、标准差、Pp/Ppk估算、超差率；第二层是分布形态，看数据是否真的服从正态，如果偏态明显，需要做转换或者用非正态分布拟合；第三层是贡献度排序，找出对目标特征波动影响最大的几个尺寸链环节。

import pandas as pd import numpy as np from scipy import stats results = pd.read_csv("dtas_simulation_output.csv") target = "gap_door_body" # 车门与车身间隙，目标尺寸 3.0 ± 1.0 mm data = results[target].dropna() mean_val = data.mean() std_val = data.std() usl, lsl = 4.0, 2.0 # 超差率 out_of_spec = ((data > usl) | (data < lsl)).mean() * 100 # 过程能力指数估算（假设正态） ppu = (usl - mean_val) / (3 * std_val) ppl = (mean_val - lsl) / (3 * std_val) ppk = min(ppu, ppl) # 正态性检验 shapiro_stat, shapiro_p = stats.shapiro(data[np.random.choice(len(data), 500, replace=False)]) print(f"均值: {mean_val:.3f} mm") print(f"标准差: {std_val:.4f} mm") print(f"超差率: {out_of_spec:.2f}%") print(f"Ppk: {ppk:.2f} (PPU={ppu:.2f}, PPL={ppl:.2f})") print(f"Shapiro正态性检验 p值: {shapiro_p:.04f}")

这里有个经验要特别强调：超差率和小概率事件检查，比看均值和标准差重要得多。均值、标准差好看了，并不代表尾部风险可接受。尤其是在汽车内外饰匹配这种对感知质量敏感的场合，哪怕只有0.5%的样本会出现明显可见的间隙不均，在量产百万件后也是几千台车的售后抱怨。所以我每次都会专门查看p1和p99分位数，看看极端情况下的尺寸表现。

贡献率分析部分，如果DTAS导出了各组成环对目标方差贡献的百分比，可以直接用DataFrame排序，也可以用matplotlib画个横向条形图，让问题一目了然。通常贡献率前三的零件就是公差优化和制造关注的重点对象。

3. 实操闭环：从数据清洗到可视化报告

3.1 环境准备与依赖库选型

要做这套流程，Python环境先备好。建议直接用Anaconda或者Miniconda创建独立环境，Python版本选择3.8到3.11之间都可以，没必要追最新版本，稳定优先。

依赖库方面，我长期使用固定的组合：pandas负责数据清洗和表格处理，numpy做数值计算，scipy做统计分析，matplotlib做可视化，openpyxl用于操作Excel文件，python-docx用于生成Word报告。如果公司内部有统一的报表模板，可能还会用到python-pptx生成PPT汇报材料。这些库都是社区里最成熟的那批，资料多，踩坑记录多，遇到问题基本搜得到答案。

# 建议创建独立环境 conda create -n tolerance_auto python=3.10 -y conda activate tolerance_auto pip install pandas numpy scipy matplotlib openpyxl python-docx

环境搭建这件事看着简单，但确实有同事栽过跟头：直接在系统Python里装了一堆包，某次升级把原本能用的库版本搞崩了，脚本全部跑不起来。所以我强烈建议把环境依赖整理成一份requirements.txt，跟随项目脚本一起放在工程目录下，换电脑或者交接给同事时直接一条命令恢复环境。

3.2 公差数据清洗与质量检查的完整演示

下面我完整演示一个实战流程中的第一步。需求背景是把项目采购阶段汇总的零件公差表整理成DTAS可用数据，同时做一轮质量体检。

原表是某个供应商发的Excel，里面混合了中文表头和英文备注，单位也不统一，还有几处明显的异常值。处理逻辑是：读取原表，标准化列名，统一单位，做合理性校验，最后输出一份清洗后的中间文件。

import pandas as pd import numpy as np import re # 读取原始Excel df = pd.read_excel("供应商_零件公差表.xlsx") # 标准化列名 df.columns = [c.strip() for c in df.columns] df.rename(columns={ "零件号": "part_no", "特征": "feature", "名义尺寸": "nominal", "上差": "tol_up", "下差": "tol_down", "单位": "unit", "分布": "dist", "备注": "remark" }, inplace=True) # 单位统一：把单位列为"um"的行换算为mm is_um = df["unit"].str.strip().str.lower().isin(["μm", "um", "micron"]) df.loc[is_um, ["nominal", "tol_up", "tol_down"]] = df.loc[is_um, ["nominal", "tol_up", "tol_down"]] / 1000.0 df.loc[is_um, "unit"] = "mm" # 上下偏差校验 df["tol_up_num"] = pd.to_numeric(df["tol_up"], errors="coerce") df["tol_down_num"] = pd.to_numeric(df["tol_down"], errors="coerce") bad_mask = df["tol_up_num"] < df["tol_down_num"] print(f"发现 {bad_mask.sum()} 条上下偏差倒置记录") print(df.loc[bad_mask, ["part_no", "feature", "tol_up_num", "tol_down_num"]]) # 过滤非法数据 df_valid = df[~bad_mask].copy() # 输出清洗后的文件 df_valid.to_csv("cleaned_tolerance.csv", index=False, encoding="utf-8-sig")

细节说明：输出编码用utf-8-sig而不是普通的utf-8，是为了在Windows环境用Excel直接打开CSV时不出现乱码。这个细节特别实用，很多同事第一次接手都在这上面吃过亏。Excel打开没有BOM标记的UTF-8文件，中文直接变成乱码，最开始我还以为是脚本写错了，排查了半天才发现是编码问题。

数据清洗这一关，最耗时的往往不是写代码，而是跟不同部门对齐"公差口径"。比如设计部门给的公差可能是基于未考虑磨损的名义值，工艺部门手里却有实际设备能力数据。我的经验是清洗脚本里尽量保留原始列，不要做完处理就把原值删掉，这样任何环节对结果有疑问，都可以回溯核对，不用重新找源头数据。

3.3 仿真结果统计分析：分布拟合与风险判断

DTAS仿真跑完后，拿到抽样数据，接下来的统计分析直接决定工程师能不能看懂风险。我习惯的输出组合是三张图加一张表。

第一张图是目标特性的直方图，叠加拟合的正态分布曲线和规格限（USL/LSL），一眼能看出数据整体位置偏不偏、尾巴重不重。第二张图是贡献率帕累托图，把对目标尺寸波动影响最大的前十个组成环比出来，给工艺和设计部门指明优化方向。第三张图是每个组成零件的公差带宽可视化，类似箱线图，帮大家理解当前公差状态下的波动范围。

import matplotlib.pyplot as plt import numpy as np from scipy import stats fig, axes = plt.subplots(1, 3, figsize=(15, 4)) # 图1：直方图+正态拟合+规格限 ax1 = axes[0] data = results["gap_door_body"].dropna() ax1.hist(data, bins=60, density=True, alpha=0.65, color="#4C72B0", label="仿真样本") mu, sigma = stats.norm.fit(data) x = np.linspace(data.min(), data.max(), 300) ax1.plot(x, stats.norm.pdf(x, mu, sigma), "r-", label="正态拟合") ax1.axvline(2.0, color="k", linestyle="--", label="LSL=2.0") ax1.axvline(4.0, color="k", linestyle="-.", label="USL=4.0") ax1.set_title(f"车门间隙分布 (μ={mu:.2f}, σ={sigma:.3f})") ax1.legend(fontsize=8) # 图2：贡献率帕累托图 ax2 = axes[1] contribution = pd.Series({ "铰链安装孔位置度": 32.5, "车门总成面轮廓度": 24.1, "车身侧围面轮廓度": 18.7, "铰链本身公差": 11.2, "固定螺栓间隙": 6.8, "其他": 6.7 }).sort_values(ascending=True) ax2.barh(contribution.index, contribution.values, color="#DD8452") ax2.set_title("尺寸链贡献率分析") ax2.set_xlabel("贡献率(%)") # 图3：关键零件公差带箱线图 ax3 = axes[2] part_data = [np.random.normal(0, s, 500) for s in [0.1, 0.2, 0.3, 0.4]] ax3.boxplot(part_data, tick_labels=["铰链", "侧围", "门板", "螺栓"]) ax3.set_title("关键零件波动范围") ax3.set_ylabel("偏差(mm)") plt.tight_layout() plt.savefig("summary_report.png", dpi=150) plt.show()

图上看到的东西，比Excel里一堆数字直观得多。我每次做方案评审都会把这套图贴进汇报材料，设计师和工艺工程师看完第一张图就知道当前方案风险如何，看完第二张图就知道该改谁，完全不用我再解释一大堆。

3.4 自动生成报告：用python-docx把分析结论写进文档

分析做完，报告还是要出的，不然结论就停留在工程师的电脑里。我的做法是用python-docx生成一份固定结构的Word报告，包括项目信息、目标特性汇总表、仿真结果统计表、超差风险和改善建议几个部分。

from docx import Document from docx.shared import Pt doc = Document() doc.add_heading("白车身车门间隙公差仿真分析报告", level=0) doc.add_heading("一、分析目标", level=1) doc.add_paragraph("评估车门与侧围间隙尺寸3.0±1.0mm在当前公差方案下的装配质量风险。") doc.add_heading("二、仿真设置", level=1) doc.add_paragraph("仿真软件：DTAS 3D，蒙特卡洛仿真次数30000次。") doc.add_paragraph("公差数据来源：2024年Q3发布图纸及供应商公差表。") doc.add_heading("三、关键结果", level=1) table = doc.add_table(rows=1, cols=5) table.style = "Light Grid Accent 1" hdr = table.rows[0].cells for i, name in enumerate(["目标", "均值(mm)", "标准差(mm)", "超差率(%)", "Ppk"]): hdr[i].text = name row_data = ["车门-侧围间隙", "3.082", "0.412", "1.12", "1.24"] row_cells = table.add_row().cells for i, value in enumerate(row_data): row_cells[i].text = value doc.add_heading("四、结论与建议", level=1) doc.add_paragraph("当前方案整体风险可控，但Ppk仅1.24，存在约1.1%的超差风险。建议优先优化铰链安装孔位置度公差，其对目标波动的贡献率达到32.5%。") doc.save("公差仿真分析报告.docx")

报告生成这一步，关键是模板和数据的分离。我平时把报告的标准格式保存成一个模板文档，脚本只负责往里填数据，格式统一、效率高，也避免每次手动排版搞得参差不齐。整个闭环跑下来，从拿到原数据到输出分析报告，大概几分钟，之前人工倒腾怎么也要大半天。

4. 现场踩坑实录：常见问题与排查技巧

4.1 数据格式类问题

这类问题占了我前期调试时间的六成以上，值得单独说说。

第一个坑是Excel的单元格格式自作主张。pandas读Excel时，如果某一列里既有数字又有文本，比如"0.5"和">0.5"混在一起，整列会被读成文本，后面的数值计算直接白给。我的排查办法是读取后先打印dtypes和head()，一眼就发现问题。

第二个坑是空值被静默处理，搞出一堆分析错误。真实数据里的空值绝对不会像教程数据那样规规矩矩用NaN表示，有时候是空格、有时候是"#N/A"、有时候干脆是整行缺失。我后来写了个简单的字段级空值统计函数，把每列的空值比例输出到日志，作为每个批处理任务的第一步。

第三个坑是科学计数法。公厘值0.005看起来很正常，但一旦在Excel里被显示成5E-03，再被某些工具读出来，就会在类型转换时丢精度。解决办法是读取时显式指定列类型，或者在清洗阶段统一用Decimal做一次拆包处理。稳妥起见，凡是关键数值列，我都会做个pd.to_numeric强制转换，并检查转换后有多少NaN，这个数字可以当作原始数据质量的直接指标。

4.2 统计分析类问题

蒙特卡洛仿真数据的统计分析，也有一些容易让人误判的地方。

最需要注意的是正态性假设。很多工程师拿到仿真结果，默认就是正态分布，直接用平均值加减三倍标准差来估计范围。但实际工程中，公差分布经常是偏态的，比如某些铸造件公差是按"名义尺寸向上偏"来定义的，仿真结果也会带上明显的偏态。遇到这种情况，可以试试Johnson分布族或者威布尔分布做拟合，用拟合后的分布重新计算超差率，会得到更贴近实际的结论。我一般会用scipy.stats里的jonhson_su或者weibull_min试试，拟合优度对比一下再做决定。

另一个问题是样本量不足时看尾部风险会骗人。蒙特卡洛仿真跑5000次和跑50000次，算出来的Ppk尾部特性很不一样。我的经验是，用于最终结论的仿真次数不要少于20000次，如果目标特性的超差率很小（比如小于0.1%），最好跑到50000次以上，否则超差率是偏低的，会让人误以为方案很稳。

还有一个细节：DTAS输出结果中不同的采样列之间有时候是相关的，比如同一组零件采样同时影响多个测量目标。这在做多目标联合判断时要特别注意，不能把每个目标单独判断超差率然后简单相加，得看联合风险。

4.3 流程自动化类的坑

自动化跑起来之后，坑更多在工程管理和环境维护层面。

最经典的问题是路径写死。早期我的脚本里全是"绝对路径"，比如C:\Users\zhang\Desktop\project_a\tolerance.xlsx，换一台电脑或者换一个项目，脚本直接报废。后来全部改成基于Path(__file__).parent的相对路径，工程目录一拷贝，整个流程就能在新环境跑起来，大大减少了交接成本。

另一个问题是版本升级导致接口变化。DTAS 3D升级后，导出文件的列名、顺序、格式都可能变化，我遇到过最离谱的一次是某个版本把单位从毫米改成了微米，脚本没发现，分析结果全部差了一个数量级，排查了半天才发现。所以每次仿真软件版本更新之后，一定要用标准测试数据做一次全流程回归，确认输入输出格式没有变化再跑实际项目。

还有一个被很多人忽略的坑：文件编码。Windows环境和Linux环境下默认编码不同，UTF-8文件在Windows下被某些工具用ANSI编码读取，中文直接乱码。我的统一规范是：所有中间文件用utf-8-sig写出，代码文件头部一律声明编码，不用系统默认编码。这样在多个系统之间迁移时，安全性高很多。

最后分享一个小技巧：整套流程建议做成一个带日志总控的脚本层级，比如main.py负责调度，下面分preprocess.py、analysis.py、report.py三个模块，每个模块独立运行、独立输出日志。这样哪一步出问题，日志一看就知道，不用从头到尾重新跑。

我个人在实际项目中最大的体会是：Python和DTAS 3D这种组合不是把某个环节自动化一下那么简单，而是把整个公差仿真从"一次性的技术分析"变成"随时可重复、可对比、可扩展的标准流程"。第一次搭这套流水线确实费了些功夫，数据口径、输出格式、异常处理都是反复打磨出来的，但之后每次项目复盘、每个方案对比、每轮工程变更评估，节省的时间都是成倍的。如果你也在跟公差仿真打交道，真心建议别让数据整理和结果报告吃掉你真正的分析时间，把杂活交给脚本，把精力留给判断。