本章要讲清 PyACL 的生命周期，也要讲清证据边界。设备枚举成功只是第一级证据。
先给出本讲路线图；后续每一段都对应这里的一行，最后回到路线收束。
先建立证据等级。学生最容易把 Found 1 Ascend devices 误写成完整推理通过，后面用原始日志纠正。
从应用层向下带读 PyACL、AscendCL、Runtime、Driver 和 AI Core。出现错误时，先定位在哪一层，不要直接归因于硬件。
一个设备可有多个上下文，一个上下文可有多个流，但流不能脱离所属上下文。释放顺序必须是 Stream、Context、Device。
真实工程必须检查每个 ret；这里突出顺序。显式资源按 Stream、Context、Device 逆序释放，最后 acl.finalize。
记住数据流而不是死背常量。无论同步还是异步，Host 可读之前必须有明确的完成条件。
向学生区分“Host 等待”与“Stream 等待”。异步任务投递成功不代表数据已经可读，也不代表资源可以立即释放。
主流程开发与应用运行逻辑要分开。运行阶段从导入、初始化、资源申请、数据传输，到执行、后处理、释放和去初始化。
模型描述是内存申请和结果解析的依据。不要根据训练脚本猜输入大小，也不要把任意长度的 NumPy 数组直接送进 Device。
ResNet18 是完整 PyACL 流程的教学实例，但当前双板记录没有执行它。课件只能展示代码路径和模型合同，不能写成已在两板通过。
两个检测模型的输入尺寸、输出张量和后处理不同。双板运行记录没有部署这些资产，因此不能从设备枚举推导检测通过。
双板环境相同不等于硬件相同。检查时也保留 Health Alarm 和温度背景，但它们不能单独决定推理成败。
这张表是本章的证据锚点。两行 Found 1 只能支持枚举结论。没有 OM、没有输入、没有 execute、没有输出，就不能写推理通过。
逐条让学生说明缺失了哪一级证据。特别禁止把设备检查、CPU ONNX 推理或 API 健康响应写成 NPU 完整推理。
排障顺序对应证据等级。当前双板记录停在设备枚举，所以不能出现“模型加载失败”或“精度差异”的结论。
每一类故障先停在对应层。没有日志和版本时，只能写 blocked 或 unknown，不能写 unsupported。
课堂任务不是再跑一遍设备查询，而是补齐从 OM 到单次推理再到应用输出的证据。没有完成的格子必须保留 untested。