HTRI二次开发教程15报表与工程交付自动化——Excel 输出、TEMA 规格书与图形版本与事实声明版本锚点当前Xchanger Suite 9.49.4 在 Final Results Report 新增温度有效度temperature effectiveness等内容报表项随版本演进——交付模板必须容错。官方 OutputsXist 页“Extensive set ofspreadsheet-style output reportscan be printed orexported to Microsoft® Excel®”Summary reportsDetailed reports局部温度/压力/传热系数/热流剖面“StandardTEMA specification sheet”“2D and 3D scaled drawings”“User-defined graphs”。示例代码中标识符为占位符数值均为示例性建模不代表任何标准规定不对应任何真实装置。一句话结论工程交付自动化的边界由官方 Outputs 界定——你能自动化交付的是报表导出件Excel、标准 TEMA 规格书、Summary/Detailed 报表、2D/3D 图纸与 user-defined graphs交付工程的核心不是生成一个文件而是模板化 多案例合并 版本落款 可追溯让每一份交付件都能回答它来自哪个案例、哪个软件版本、什么时候生成。〇、本篇要解决的认知问题Q1官方允许我们交付哪些成果物哪些能自动化、哪些不能Q2TEMA specification sheet 为什么是工程交付里的硬通货Q3多案例的结果怎么合并成一份交付报告而不是一堆散文件Q4交付件为什么必须版本落款落款要包含什么Q5交付自动化的脚本骨架应该长什么样一、机制解析1.1 官方 Outputs 的可交付清单把官方 Outputs 拆成可交付物交付物官方表述能否自动化用途报表导出件Excelspreadsheet-style output reports 可打印或导出 Microsoft Excel✅ 高数据交付、二次分析Summary report一两页总览✅ 中多为导出后解析决策摘要Detailed report局部剖面温度/压力/传热系数/热流✅ 中详细校核、问题定位TEMA specification sheetStandard TEMA specification sheet✅ 中导出后归档对外交付/制造依据2D/3D scaled drawings可视化确认几何⚠ 有限归档为主几何确认、评审user-defined graphs用户自定义图⚠ 有限汇报、趋势展示关键认识*.htri是专有二进制底账 U4所以交付件其实是从案例派生出来的导出件Excel/规格书/图。自动化交付 自动化导出 合并 落款。1.2 TEMA specification sheet交付硬通货Xist 官方 Outputs 明确含StandardTEMA specification sheet。TEMA 是管壳式换热器制造商协会标准其规格书是行业内通用的换热器描述格式——制造厂、审查方、业主都用它。为什么它是硬通货你用 HTRI 算得再好对方尤其是制造与采购要的是一份按 TEMA 格式写的规格书。所以交付自动化里把每个案例的 TEMA 规格书导出并归档是接近必做的一环。注意TEMA 规格书面向换热器制造/描述不含你想强调的全部性能细节——性能论证靠 Detailed/Summary 报表制造依据靠 TEMA 规格书二者分工。1.3 多案例合并从散文件到一份报告批量扫描会产出 N 个案例的导出件。交付自动化的第二步是合并按案例合并每个案例一页/一节加汇总表所有案例的关键指标汇总在首表这就是第 10 篇的宽表用途加筛选结论标记超标案例如裕量不足、压降超标。最佳实践**“一页一案例 首表汇总 末表结论”**的三段式交付结构兼顾可看决策与可查审计。1.4 版本落款交付件的身份证一份交付件至少要有四行落款软件版本如 Xchanger Suite 9.4——方法变了结果就变9.3 改 RPM 冷凝、9.4 改超临界传热生成时间案例来源模板文件 内容哈希第 10 篇单位集与免责声明示例性建模/以官方文档为准。为什么必须没有落款的交付件半年后没人敢用——因为你不知道它是哪个版本、哪个模板、什么单位算出来的。1.5 交付边界不要越界经验法则只交付官方 Outputs 覆盖的内容。不要在交付件里自己算HTRI 未输出的指标如自造一个综合评分并伪装成 HTRI 结果——那会把你的推断与官方结果混在一起审计时无法分辨。若确需衍生指标显式标注衍生计算非 HTRI 输出。1.6 交付自动化的三条纪律纪律一交付件必须自解释。一份能离开你独立存活的交付件要能在没有你讲解的情况下回答这是哪个案例、用哪个版本算的、单位是什么、结论怎么来的。四段式汇总/逐案例/结论/落款 单位列 阈值说明就是这个自解释的载体。做不到自解释的交付件半年后就是一堆无法使用的数字。纪律二交付结构要一层给决策、一层给审计。决策者看汇总与结论审计者看逐案例长表与落款。把两层塞进一张表结果是决策者嫌乱、审计者嫌缺。第 10 篇存储用长表、展示用宽表的分工在交付层就体现为逐案例 sheet 汇总 sheet。纪律三交付件要能被差异比对。工程交付常有改了一版看看变了什么的需求。做法是关键表列顺序稳定、单位稳定、case_id 稳定——这样两版交付件可以直接 diff。结构会乱跳的交付件比对成本高到让人放弃比对于是错误就藏起来了。一条边界提醒TEMA 规格书是描述不是认证。它描述换热器是什么样子便于制造与采购它不替代设计责任、也不构成合规声明。交付时把这句话放在落款附近是保护自己也是保护使用者的做法。二、完整代码与逐行剖析代码 15-1多案例报表合并为交付工作簿# -*- coding: utf-8 -*- make_delivery.py —— 多案例导出件合并为一份交付工作簿 用法python make_delivery.py 依赖results_merged_long.csv第 09/10 篇产物、run_meta.json第 10 篇 输出delivery_report.xlsx含 汇总 / 逐案例 / 结论 / 落款 四部分 说明数值为示例性建模不代表任何标准规定不对应任何真实装置。 importjsonimportdatetimeimportpandasaspd DELIVERY_META_DEFAULT{software_version:9.4,unit_set_note:以案例内设定为准跨单位集已显式换算,disclaimer:示例性建模不代表任何标准规定不对应任何真实装置,}# 结论规则示例裕量不足 / 压降超标的判定LIMITS{outputs.summary.shell_dP:30.0,# kPa示例阈值outputs.summary.duty_margin:0.10,# 10% 裕量示例阈值}defbuild_summary(long_df):宽表汇总只取 summary 段。slong_df[long_df[section]summary]wides.pivot_table(indexcase_id,columnsparameter,valuesvalue,aggfunclast).reset_index()returnwidedefbuild_conclusions(wide):rows[]for_,rinwide.iterrows():issues[]ifoutputs.summary.shell_dPinrandpd.notna(r[outputs.summary.shell_dP]):ifr[outputs.summary.shell_dP]LIMITS[outputs.summary.shell_dP]:issues.append(壳侧压降超标)ifoutputs.summary.duty_margininrandpd.notna(r[outputs.summary.duty_margin]):ifr[outputs.summary.duty_margin]LIMITS[outputs.summary.duty_margin]:issues.append(裕量不足)rows.append({case_id:r[case_id],verdict:合规ifnotissueselse需关注,issues:.join(issues)})returnpd.DataFrame(rows)defmain():long_dfpd.read_csv(results_merged_long.csv,encodingutf-8-sig)widebuild_summary(long_df)conclbuild_conclusions(wide)try:metajson.load(open(run_meta.json,encodingutf-8))exceptFileNotFoundError:metaDELIVERY_META_DEFAULT footerpd.DataFrame([[软件版本,meta.get(software_version,未知)],[模板文件,meta.get(template,未知)],[模板哈希,meta.get(template_sha256,未知)],[单位集说明,meta.get(unit_set_note,未知)],[生成时间,datetime.datetime.now().isoformat(timespecseconds)],[免责声明,meta.get(disclaimer,DELIVERY_META_DEFAULT[disclaimer])],],columns[项,值])outdelivery_report.xlsxwithpd.ExcelWriter(out,engineopenpyxl)asxw:wide.to_excel(xw,sheet_name汇总,indexFalse)long_df.to_excel(xw,sheet_name逐案例,indexFalse)concl.to_excel(xw,sheet_name结论,indexFalse)footer.to_excel(xw,sheet_name落款,indexFalse)print(f交付工作簿已生成{out}4 张表汇总/逐案例/结论/落款)print(concl.to_string(indexFalse))if__name____main__:main()逐行剖析四张表的分工汇总宽表决策用、逐案例长表审计用、结论判定用、落款可信度用——这就是 1.3 节三段式 落款的实现。LIMITS是显式阈值示例值把超标/裕量不足的判定标准写进代码而非拍脑袋且标注示例阈值实际以项目规定为准的语义。verdict只有合规/需关注两态交付件的结论要克制不下合格/不合格这种需要资质背书的判断——工程上更稳妥。footer从run_meta.json取版本/模板/哈希交付件的可信度直接继承落盘元数据第 10 篇两篇形成闭环。落款含免责声明示例性建模声明随交付件走铁律 5。用openpyxl写多 sheet零额外依赖Excel 直接可开。代码 15-2交付清单与合规核对# -*- coding: utf-8 -*- delivery_checklist.py —— 交付件清单核对 用法python delivery_checklist.py 说明核对交付包是否齐全并检查衍生指标是否被显式标注。 importcsvimportos REQUIRED[(delivery_report.xlsx,交付工作簿汇总/逐案例/结论/落款),(results_merged_long.csv,结果长表审计源),(run_meta.json,可复现元数据版本/模板哈希),(cases.csv,案例矩阵变量取值),]defmain():rows[]forfn,descinREQUIRED:rows.append({file:fn,desc:desc,exists:yesifos.path.exists(fn)elseno})withopen(delivery_checklist.csv,w,newline,encodingutf-8-sig)asf:wcsv.DictWriter(f,fieldnames[file,desc,exists])w.writeheader()w.writerows(rows)missing[rforrinrowsifr[exists]no]print(f交付清单{len(rows)}项缺{len(missing)}项)forrinrows:flagOK ifr[exists]yeselse缺 print(f [{flag}]{r[file]:26}{r[desc]})print(\n注意若交付件含任何衍生计算非 HTRI 输出指标必须显式标注来源)print( 不得与 HTRI 官方输出混排而不加区分。)if__name____main__:main()逐行剖析交付清单把交付包定义成一组文件而非单一文件现代工程交付是主件 审计源 元数据 输入矩阵的组合。缺少项显式打印[缺]交付前必须无缺项。末段提示衍生指标必须标注来源把 1.5 节的交付边界写进检查脚本——防止把自算值伪装成 HTRI 结果。产物delivery_checklist.csv归入交付包形成交付的自检记录。三、常见报错与排查报错 3-1交付件里出现 HTRI 从未输出的指标。现象某列数值在官方 Outputs 里找不到。根因有人把衍生计算混进了官方结果。解法显式标注衍生计算非 HTRI 输出或在交付件中分离官方结果与推断结果不得混排。报错 3-2多案例合并后表结构错乱。现象Excel 汇总表列对不上、单元格错位。根因把 detailed 剖面的长表直接透视进 summary 宽表第 09 篇的陷阱。解法合并前先按section分段宽表只装 summary。报错 3-3交付件打开后中文乱码。现象CSV 乱码、Excel 正常。根因中间 CSV 未用utf-8-sig。解法全链路统一utf-8-sigExcel 工作簿本身不受此影响。报错 3-4换人接手后无法复现交付结果。现象交付件数值对不上。根因落款缺失不知道版本/模板/单位。解法交付件必含落款表核对run_meta.json的software_version与template_sha256。报错 3-5升级 9.4 后旧交付模板报列缺失。现象模板引用的某项在 9.4 里改名/新增。根因报表项随版本演进9.4 新增温度有效度等。解法模板按列契约而非列名引用第 09 篇升级后重跑并核对新增/改名项。报错 3-6两版交付件无法比对。现象想对比新旧版本的差异发现列顺序、单位都变了。根因交付结构不稳定1.6 节纪律三。解法固定关键表列顺序、单位与 case_id把列契约作为交付模板的一部分两版之间用case_id做键做差异比对。四、动手练习练习 1交付工作簿对已有长表运行代码 15-1。判定生成delivery_report.xlsx含汇总/逐案例/结论/落款四张表落款表含软件版本、模板哈希、生成时间。练习 2结论判定构造一个壳侧压降超标的案例数据。判定“结论表中该案例verdict 需关注issues含壳侧压降超标”。练习 3交付清单运行代码 15-2。判定delivery_checklist.csv四项齐全能指出当前缺失项如有并补齐。练习 4边界自检检查交付件中是否存在未标注来源的衍生指标。判定若有已加衍生计算非 HTRI 输出标注若无能说明为什么。练习 5自解释检查把交付工作簿单独发给一位没参与项目的同事让他只凭文件回答这是哪个版本、什么单位、哪些案例需关注。判定他能在 5 分钟内答出三项若答不出补足落款或阈值说明。五、小结与下一篇预告本篇把自动化闭环推进到交付交付边界由官方 Outputs 界定Excel 报表、TEMA 规格书、Summary/Detailed、2D/3D 图交付结构用汇总 逐案例 结论 落款四段式TEMA 规格书是制造交付的硬通货性能论证靠报表并立下衍生指标必须标注来源的交付边界。产出delivery_report.xlsx与delivery_checklist.csv。第 16 篇《工程化许可、并发与批处理容错治理》交付链有了但要 7×24 无人值守还得治理许可与并发HTRI License Manager、HL/SL/网络许可、桌面 OLE 的挂死与残留进程、幂等重跑与会话隔离。我们会把第 07 篇的释放三步升级成一套批量守护组件。本篇认知问题回显FAQQ1官方允许交付哪些成果物哪些能自动化A官方 Outputs 界定spreadsheet-style output reports可打印或导出 Microsoft Excel、Summary reports、Detailed reports局部温度/压力/传热系数/热流剖面、标准 TEMA specification sheet、2D/3D scaled drawings、user-defined graphs。其中报表导出件、Summary/Detailed、TEMA 规格书自动化程度高导出 合并 落款2D/3D 图与自定义图自动化有限以归档为主。*.htri是专有二进制故交付件都是从案例派生的导出件。Q2TEMA specification sheet 为什么是交付硬通货ATEMA 是管壳式换热器制造商协会标准其规格书是行业通用的换热器描述格式制造厂、审查方、业主都使用它。Xist 官方 Outputs 明确含Standard TEMA specification sheet因此每案例导出并归档 TEMA 规格书接近必做。注意分工TEMA 规格书面向制造/描述性能论证靠 Detailed/Summary 报表。Q3多案例结果怎么合并成一份交付报告A采用一页一案例 首表汇总 末表结论的三段式结构汇总表放所有案例关键指标summary 段宽表逐案例表放长表供审计结论表标记超标如裕量不足、压降超标与合规状态。合并前必须按 section 分段宽表只装 summary避免 detailed 剖面把宽表撑成稀疏错位矩阵。Q4交付件为什么必须版本落款包含什么A因为方法随版本变化9.3 改 RPM 冷凝方法、9.4 改超临界传热方法没有落款的交付件无法判断可信度。落款至少含四类软件版本如 9.4、生成时间、案例来源模板文件 SHA-256 内容哈希、单位集与免责声明示例性建模/以官方文档为准。Q5交付自动化的脚本骨架是什么样A读取第 09/10 篇的结果长表 → 生成 summary 段宽表汇总 → 按阈值规则生成结论表verdict 合规/需关注只做提示不做资质判定→ 从 run_meta.json 生成落款表 → 用 openpyxl 写多 sheet 交付工作簿 → 用交付清单脚本核对主件 审计长表 元数据 案例矩阵是否齐全并检查衍生指标是否标注来源。核心是模板化 多案例合并 版本落款 可追溯。