软件最理想的运行环境是演示机。真实产线上跑的是网络波动、脏数据、临时改的需求，和屏幕前那台机器完全不是一回事。这个月，手上同时压着模具管理模块修复、边缘端通信协议与自定义API采集能力开发、UID问题排查、设备对接方案推进几条线。白天开会协调、写代码、跑环境，晚上盯版本联调、复测问题，周末也搭进去不少。多任务并行没有乱了节奏，靠的不是加班硬扛，而是把优先级和根因判断放在动手之前。
多任务并行，为什么排优先级比埋头写代码更重要？
现场问题和研发任务经常撞在一起。谁急谁先处理、哪些可以延后，都要提前判断清楚，不然容易两边都耽误。这个月几条线同时推进，模具管理模块占的工作量不小，边缘端自定义API采集又是重点研发方向，UID问题反复出现时，白天大部分精力都耗在上面。排优先级不是把任务列个顺序，而是判断哪件事卡住了现场、哪件事可以等版本窗口。
比如料桶信息管理导入的问题，和测试胡工沟通后确认负数可以正常导入，优先级不高，建议延后处理，避免占用当前版本精力。试模管理线体日计划字段非必填的需求，和产品何工讨论时发现方案理解有偏差，实际需要新增任务单号字段和对应表，后来按方案要求把实现补齐了。早发现、早纠偏，返工就少。
模具管理模块修复，怎么让现场操作不被流程卡住？
模具管理模块这个月从逻辑调整到缺陷修复，再到新功能开发，基本围绕现场用得顺不顺来一项一项处理。
委外维修逻辑这块，把原来维修完成后校验是否在库的方式改成了策略限制，委外归还时也去掉了是否在库的限制，避免流程上卡住现场操作。SOP关联产品里的物料组下拉框需要过滤禁用数据，这个后端接口直接改了，省去来回转手的麻烦。模具归还功能做了完整开发并完成联调，现在可以直接扫模具条码、扫描位完成归还，相关接口已经新增。维修任务管理这边连续处理了几个缺陷：委外维修时隐藏维修完成按钮、保存时强制更新在库状态、先保存再提交时提示重复操作等，都已修复完转给测试。模具数据下拉查询的问题排查修复了一版，关联匹配的问题也调整给相关同事处理。
边缘端自定义API，怎么把不同设备的数据收进一个入口？
边缘端通信协议与自定义API采集是本月的重点研发方向。整体思路是“统一入口、多通信源可组合、设备采集方案绑定自定义API”，把不同设备的复杂工艺从边缘端驱动里解耦出来，交回自定义API按设备工艺自行处理。以后接入新设备，就不用再为每种数据排列单独开发一套专用流程。
统一采集契约与统一入口：设计了一套统一的通信请求契约（POST /api/lotProcessing/EdgeProtocolCollect），每次通信服务收到一条数据就形成一次独立请求，携带通信类型、原始数据、设备与驱动信息、协议参数明细。COM串口数据、FILE文件流都走同一个入口转交TPM，由TPM按设备编号解析站点、已发布采集方案和绑定的自定义API，再按最新已发布版本动态生成调用地址（/custom/v[版本]/[编号]）转交JMOM，API版本号不写死，后续升级不用动代码。
可组合的多来源采集：COM和FILE是当前已实现、并已编写对接文档的通信来源；TCP、RabbitMQ预留了服务和配置扩展位置，尚未测试通过，不当作已验证能力；PLC、数据库、通用HTTP/API暂不在本次验收范围。同一设备可以配置COM加一个或多个文件源，按工艺顺序多次调用同一个自定义API，比如“先扫码后检测”“多文件先到扫码后到”“多份检测报告组合”等场景，关联、缓存、等待、提交逻辑都由自定义API脚本实现。
方案绑定与版本解析：采集方案在JMOM中维护并配置“自定义API编号”，发布版本后与设备在IMES绑定；TPM只取设备实际绑定的最新已发布方案，未配置API或没有已发布版本时返回明确错误，避免静默失败。
数据测试方面，已完成COM口加文件流方式的数据测试，曝光数据能正常传输，MongoDB里也能抓到记录，接口目前还在调试阶段，TCP、DIO等功能后续继续验证。界面完善上，和前端黄工对接，在边缘端自定义解析界面增加了“自定义API编号”字段显示，完成保存逻辑，后续又补了日志界面和“重新执行接口”按钮；同时确认业务类型为设备解析时请求参数禁止编辑，防止现场误操作。
状态返回与日志：自定义API返回Status、Message、Data，边缘端按1成功绿色、2失败红色、3警告橙色输出日志，现场人员一眼能辨别当前状态；TPM对每次JMOM出站调用都写入MongoDB日志（EdgeCustomApiRequestLog），保留设备驱动、API地址、请求头/体、原始响应、状态码等信息，可按日志ID原样重放历史调用，排查问题方便很多。兼容性上，历史EquipLinkType、LinkDataType和旧设备采集入口行为保持不变，新协议事件走独立链路，不影响存量设备；TCP、RabbitMQ、PLC在完成测试前都标记为未验证，验收口径如实反馈。
在边缘端采集这类底层能力上，精工智能数字化工厂的研发把现场当考场——先把统一入口和版本解析做稳，再谈新设备接入，而不是在办公室把功能做完就算交付。
排查问题，为什么先定位根因比反复试错高效？
UID问题这个月反复出现，边缘端持续报错的问题修复了一版并更新了代码，后面确认基本没有太大问题，封版就行。这个月处理的几类问题，都是先确认环境配置和依赖，再对症下药，避免了无效改动。另外也暴露了一个隐患：本地数据库文件打包时缺失，导致有些问题在本地无法复现。后面要养成打包前自查环境的习惯，别让这种低级问题卡住排查节奏。
设备对接这边，和产品沟通了锡膏管理柜、钢网存储柜等设备的对接需求，目前开发人力不足，建议由张工统筹安排；如果需要先出方案，可以接手，先把事情向前推。
跨团队协作也在按节奏对齐：参加《一套代码交付管理制度交流会议》，讨论代码交付规范，把交付环节的边界和标准理清楚；处理了某客户WMS测试环境的发布问题，并指导肖工完成菜单配置和授权；参与《熠日新增二开需求评估》会议，对新增需求做了评估；在《产品研讨交流会》上了解JMOM6.3.10新发布的功能；也参加了《售后工单系统-使用宣导》，熟悉售后工单系统的使用方式。最后把TPM代码从UAT推送到了master，并同步通知了产品何工。
精工智能数字化工厂的研发，把现场当考场——在真实数据、真实网络、真实操作习惯里把系统磨稳，而不是在办公室把功能做完就算交付。这个月谈不上什么亮眼的成绩，就是一件事一件事往下做：模具模块的功能逐项落地，边缘端自定义解析一步步推进，UID问题从反复出现到收敛，跨团队的需求和会议也都按节奏对齐了。
精工智能数字化工厂，制造业Online，持续在场，赋能企业高质量发展。
（作者：郑老师｜2026年10月｜素材来源：《10月份-郑浩波-月度工作总结与边缘端自定义接口功能实现》）
