name: vent-resistance-check

description: "煤矿通风系统关键阻力路线计算与阻力检查（通防管控平台 tf_mcp + 云通防知识库隐患分析）。当用户提出计算某回风井/回风系统的关键阻力路线及总阻力、最大阻力路线、通风阻力检查、全矿井各回风系统阻力对比等需求时使用。覆盖：解析回风系统名称（未指明则计算全部回风系统）、取平台默认模型、确定回风井出口节点、解算最大阻力路线、巷道名称映射与逐段阻力核验、固定模板输出（总体结论/路线走向/Top10高阻力巷道/分段阻力构成/注意事项）、结合云通防知识库做问题与隐患分析（合规项/隐患/建议动作）、报告落盘为 Markdown。跨工具通用：无 TF-MCP 环境按能力映射层适配。"

矿井通风系统阻力检查（关键阻力路线 + 隐患分析）

基于通防管控平台解算引擎计算回风系统关键（最大）阻力路线及总阻力，核验后按固定模板输出，并结合云通防知识库分析问题与隐患。

适用场景 / 触发词

"帮我计算{某回风井/回风系统}的关键阻力路线及总阻力"、"最大阻力路线"、"通风阻力检查"、"全矿井回风系统阻力分析/对比"。

用户指明回风系统（如"松定霍洛"）→ 只算该系统；
未指明 → 计算全矿井所有回风系统，逐个完整展示，最后统一汇总共性问题。

前置条件与能力要求

默认在已接入 TF-MCP（通防管控平台 MCP）的环境运行。其他智能体工具（Claude Code / Cursor / Dify / Coze / 自研 Agent 等）先按 references/capability-map.md 把能力清单映射为本环境的等价工具，再执行本流程。

必需能力：取默认模型、取回风井列表、查单条巷道详情、最大阻力路线解算、批量查巷道属性（SQL）、档案/知识库检索。
增强能力（可缺失，超时或缺失不阻塞主流程）：网络故障诊断、三区阻力分布、控风决策数据、设备实时数据。

关键技术红线（必须遵守）

模型 ID 是大整数（> 2^53）：经 JSON number 传参会精度失真。所有模型 ID 参数一律传字符串——本地工具层已统一（query_tunnel_list / get_model_wind / get_sensor_wind / query_tunnels_by_model 入参均为字符串，内部自动转换为服务端整数 schema；旧接口 get_tun_list_by_modelid 已下线）。SQL 中模型 ID 作为数字字面量直接书写无精度问题。
回风井 ID ≠ 节点 ID：get_out_shafts 返回的是巷道 ID。最大阻力路线接口需要的是节点 ID = 风硐巷道的 toId（connectType="连接到地面"一侧，即主风机侧出口）。
巷道也有大 ID（> 2^53 的后补录巷道）：整数参数的按巷道 ID 查询只对小 ID 可靠；批量取属性一律走 SQL（IN 列表 + ORDER BY FIELD 保持路线顺序）。
阻力口径：fHTotal = 摩擦阻力 + 局部/调节阻力。总阻力、Top10、分段构成统一用 fHTotal；同时记录 fHFric，用于识别调节设施阻力（fHTotal − fHFric 差值大且 nWindowID > 0 → 调节风窗，属主动控风措施，不计入降阻对象，但计入能耗分析）。
必须核验：路线各段 fHTotal 求和与解算接口 fMaxH 相对偏差 ≤ 1%（各段 0.1 Pa 舍入累积的微小偏差可接受）。核验不通过必须查明原因，不得出报告。
SQL 保留字：window 表名必须加反引号。
query_wind_by_tunid 不按模型过滤：该接口可能返回其他模型同ID巷道的记录（实测曾把模板模型 800014 的风量/风速/长度当成当前模型数据，数值全部失真）。报告引用的一切数值必须来自带 nModelID 过滤的 SQL；该接口仅用于定位节点ID与名称初判。
段数直接取 path 数组长度：巷道段数 = path.length，禁止手工清点（实测手工计数出错）。
显示单位与精度：报告中风量一律 m³/min（= 库值 × 60，保留 1 位小数）；阻力类数值（总阻力/摩擦/调节/分段/Top10）一律四舍五入取整（Pa）；风速保持 m/s；能耗估算用原始 m³/s 值计算后以 kW 取整呈现，禁止先舍入再相乘。

执行流程

第 1 步：解析意图与选定模型

从提问中解析回风系统名称（用于后续模糊匹配，如"松定霍洛"）。
取平台默认模型：get_model_param_pub_list → param.records[0].defaultmodelid，报告中注明模型 ID。仅当用户点名其他模型时才切换；平台有多个模型不主动询问。

第 2 步：确定计算对象（每套回风系统）

get_out_shafts(model_id 字符串) → 回风井巷道 ID 列表。
对每个回风井巷道 ID：query_wind_by_tunid(tun_id)（小整数，安全）→ 取 tunnelName / fromId / toId / fQ / connectType。风硐名称通常含风井名（如"松定霍洛风井风硐"），据此匹配用户指定的系统；toId 即解算终点节点。
用户指定了系统但名称匹配不到 → 列出所有风硐名称让用户确认，不要猜。

第 3 步：解算关键阻力路线

get_max_resistance_path(model_id 字符串, node_id = 风硐 toId) → fMaxH（Pa，含调节阻力）+ path（巷道 ID 有序序列，进风侧 → 风硐）。

第 4 步：巷道属性映射与核验（SQL 优先）

SELECT nTunID, strName, fLength, fQ, fV, fHFric, fHTotal, nWindowID
FROM tun
WHERE nModelID = {模型ID字面量} AND nTunID IN ({path 逗号列表})
ORDER BY FIELD(nTunID, {path 按路线顺序})

核验 ΣfHTotal ≈ fMaxH（偏差 ≤ 1%）。
无 SQL 权限时退化：query_wind_by_tunid 逐条查小 ID 巷道；大 ID 巷道查不到时在报告中明确标注"X 条巷道名称缺失"，不得编造名称。
派生指标：路线长度 = ΣfLength；风机风量 = 风硐 fQ（库内单位 m³/s，报告显示 ×60 换算为 m³/min，保留 1 位小数）；净摩擦阻力 = ΣfHFric；调节阻力 = fHTotal − fHFric（nWindowID > 0 确认为风窗）。

第 5 步：分段构成归类（按巷道名称关键字 + 路线位置）

段	归类规则
进风段	进风井筒（主斜井/平硐/进风立井）+ 进风大巷 + 途经硐室（变电所/水仓等）
中部大巷段	×水平主运/辅运/进风大巷等主干运输巷
用风段	顺槽、切眼、工作面、采区内部联巷/绕道
回风段	回风大巷 + 回风暗立井/回风立井 + 回风立井联络巷 + 风硐

归类有歧义时按巷道相对工作面的位置判断；分段边界在报告中写明。四段阻力之和须等于总阻力。

第 6 步：按固定模板输出

严格按 references/report-template.md 填充，禁止增删章节或改变顺序。多套系统时：每套输出一个完整章节（系统名作章节标题），全部展示完后输出"全矿共性问题与建议"章节（横向对比各系统总阻力/风量/阻力构成，共性隐患合并陈述，个性问题留在各自章节内）。

第 7 步：云通防知识库隐患分析

按三层来源执行，判据见 references/hazard-checklist.md：

平台档案（第一优先）：get_file_list_by_type 检索文件中心，重点找与该回风井风机设备绑定的主通风机检验报告（风量/压力/效率）、外部漏风率测定、反风演习记录、通风（反风）设施检查记录。
平台库表佐证：SQL 查 doc_vent_report 等（核对矿井名与当前模型是否一致，错位数据标注"待核实"）。
内置规程判据兜底：风速限值 / 漏风率 / 反风率 / 调节阻力占比 / 风机效率等。

每条结论必须标注来源与数据日期；档案与模型对象错位（如报告标注的矿井/风井名与当前系统不符）时如实说明，不得张冠李戴。增强诊断（故障诊断/三区分布/实时数据）超时或不可用时，在"数据来源与局限"中声明"拓扑级诊断未执行"，不得声称排除循环风、角联等问题。

第 8 步：落盘报告

在当前工作目录 vent-resistance-report/ 下生成 阻力检查报告_模型{模型ID}_{YYYY-MM-DD}.md：

正文 = 对话展示内容（与模板一致）；
附录 = 路线全部巷道明细表（巷道ID/名称/长度/风量/风速/摩擦阻力/总阻力/风窗标记）。生成后向用户报告文件路径。

完成标准

每套系统：总阻力（含/不含调节阻力双口径）、风机风量、路线长度、路线走向、Top10、分段构成、注意事项齐全；Σ核验通过。
隐患分析：合规项表、问题与隐患、建议动作（按优先级）、数据来源与局限齐全，逐条可溯源。
输出格式与 references/report-template.md 完全一致；多系统逐个完整展示、共性问题汇总在最后；报告文件已落盘。

SKILL.md 8.8 KB Постоянная ссылка История Исходник