文章目录
- [开发日志 2026-08-13（周四）](#开发日志 2026-08-13（周四）)
-
- 今日概览
- 一、芯片人工分类流程优化（客户项目A，主要开发）
- [二、板卡检测 NPU 推理后端切换（客户项目A）](#二、板卡检测 NPU 推理后端切换（客户项目A）)
- [三、后端仓库A 内存持续积攒排查（客户项目A）](#三、后端仓库A 内存持续积攒排查（客户项目A）)
- 五、办公自动化：局域网打印（项目B）
- 六、工程规范（客户项目A）
- 七、其他故障
- 复盘与后续
开发日志 2026-08-13（周四）
今日概览
今天共产生 14 个 Codex 会话，主要工作：
- 芯片人工分类流程优化：分类不确定时标记「待人工分类」，人工调整后重新提取参数（独立工作树实施 + 浏览器实测）
- 板卡检测 NPU 推理后端切换：ONNX → OM（昇腾），并解决首推阻塞导致 Pod 被杀的问题
- 后端仓库A 内存持续积攒排查：http.Client 复用与信号量配置化
- 办公自动化：局域网打印机批量打印与 PDF 分页
- 工程规范：测试代码统一放 tests/ 目录
- 其他：事务失败错误复现
一、芯片人工分类流程优化（客户项目A，主要开发）
背景
分类识别存在两类问题：
- 库中没有匹配的分类、或模型不确定归哪一类时（例如只识别到一级分类「接口芯片」，二级分类与库中已有分类接近但不对应），模型只能停在二级缺失状态；
- 只有叶子节点分类才带分类参数，仅识别到一级分类时参数为空，导致这类数据进入业务模块丁分析时没有参数依据。
优化方案（用户确认采用方案 1）
- 保留模型识别到的当前分类，但标记为「待人工分类」状态，明确提示人工介入；人工调整分类后自动触发重新提取参数；
- 仅识别到一级分类（无分类参数）的数据，不再纳入业务模块丁分析范畴。
实现（独立工作树 + 功能分支）
- 前端：数据结构增加分类状态 / AI 建议备注 / 跳过分类等字段，新增「分类状态」筛选；列表页在待人工分类时显示琥珀色「⚠ 待人工分类」徽标，悬浮展示 AI 的二级分类猜测；校验页顶部增加黄色提示条（含一级分类、AI 建议、操作指引），保存时检测分类是否变化，变化则提示「分类已更新，正在后台重新提取参数」并刷新详情；
- 后端配合标记与重新提取的触发链路。
验证
- 类型检查无新增错误、生产构建通过；
- 用 playwright-cli 连接真实浏览器实测：列表行显示「一级分类 ⚠ 待人工分类」徽标与悬浮提示；分类状态筛选正确携带参数；校验页提示条完整；修改分类保存后出现「正在后台重新提取参数」并重新加载详情。Console 无新增报错。
思路
与其让模型在「库中没有合适分类」时硬猜一个二级分类（昨天已修掉编造 ID 的问题），不如把不确定性显式暴露给人工确认，同时保证错误参数不会带着空模板落库或进入下游分析。
二、板卡检测 NPU 推理后端切换（客户项目A）
背景
板卡检测服务部署在华为昇腾 NPU 环境，出现两类问题：
- 实际使用 ONNX 模型，但 ultralytics 的 ONNX 后端在选 provider 时只有 CUDA / CoreML / CPU 三条路，
npu:0既不是 CUDA 也不是 MPS，图计算实际落在 CPU 上； - 首推时 torch_npu 逐算子编译导致超过 90 秒阻塞，触发 liveness 探针把 Pod 杀掉，任务反复失败（多次尝试 AI Core 占用 0%）。
排查与选型
- 确认根因不是配置问题，而是代码里写死的 provider 选择逻辑；
- 对比三条可行路线：MindIE（镜像自带，需改推理调用）、CANN Execution Provider（要重编 onnxruntime，最折腾）、ATC 转 OM + ais_bench（离线固化，规避首推编译）；用户明确不要 CPU 方案。
落地改动（本地可落地部分）
/api/detect由异步改为同步，推理走 FastAPI 线程池，不再占死事件循环，健康检查在推理期间照常响应；- 增加启动预热（预加载模型 + 哑推理，失败不阻塞启动）；
- 新增 NPU 专用配置（模型走挂载目录，不打包进镜像）；
- Dockerfile 调整：升级依赖、安装推理运行时与评测工具、删除旧模型拷贝与半精度逻辑；
- 新增导出脚本：在 Linux 构建机上完成 ONNX → OM 导出并校验元数据；
- 业务侧配套调整，并补挂模型目录。
遗留问题
昇腾侧换后端后需继续排查 AI Core 0% 的问题（按用户要求通过网络搜索方案跟进）；另「创建结构化数据失败：failed transaction」错误再次出现，待定位。
三、后端仓库A 内存持续积攒排查（客户项目A）
排查结论（按影响排序）
- P0 ：每个 LLM 请求都新建
http.Client，空闲连接从不回收------对话、Token 估算、健康检查、指标、向量化、外部检索等多处都存在，是内存持续积攒的主要来源； - 信号量类问题：quick-query 拆图、厂商补全等并发控制需要确认语义（并发数 = 同时处理的图片数，与 CPU 相关），且信号量参数需要能在配置中调整，而不是硬编码；
- 顺带梳理了 OCR / 提取 / 审核三种任务在超时时的语义差异：OCR 超时直接置失败不重试，提取超时会进入待重试直到上限，审核超时会清标记重新排队。是否给 OCR 也加上「超时重试到上限」由用户确认。
产出
排查结论 + 修复计划已输出；http.Client 复用与信号量配置化是下一步落地重点。
五、办公自动化：局域网打印（项目B）
- 将 8 份 PDF 用局域网打印机单面打印；
- 把入网承诺书 PDF 按页拆分成独立 PDF 后逐份打印；
- 提交打印任务并跟进（含重复加打一份），打印机排队出纸后完成。
六、工程规范（客户项目A）
AGENTS.md「铁律」新增：所有测试代码 / 脚本统一写在对应项目的 tests/ 目录下，项目没有该目录则先创建。
七、其他故障
- 事务失败错误「Could not complete operation in a failed transaction」在创建结构化数据时复现，进入排查列表；
- 若干 qwen 视觉分析子会话用于人工分类 UI 截图核验（列表徽标、校验页提示条）。
复盘与后续
可复用经验：
- 推理后端选型先查框架写死的 provider 路径，再决定改代码还是换后端；
- 内存类问题按「资源是否每次新建、是否回收」排序排查，http.Client / 连接池是最常见大头；
- 「分类不确定」交给人工确认，比让模型硬猜更可靠，也方便后续人工数据反哺。
待办：
- OCR 超时是否加重试（待用户确认）
- ONNX → OM 换后端后 AI Core 0% 继续排查（网络搜索方案）
- 人工分类功能分支合并回主分支
- 后端仓库A http.Client 复用与信号量配置化落地
- failed transaction 错误定位