配置类功能最怕界面保存了、底层数据没同步。电子电器制造现场的 MES 前端开发，PDA 卡顿、PC 内存溢出、多端渲染不一致，问题大多出在复合操作场景。精工智能研发把现场当考场，先跑通数据链路再交付。
软件最理想的运行环境是演示机。真实产线上跑的是网络波动、脏数据、临时改的需求，和屏幕前那台机器完全不是一回事。这个月做 MES 平台配置和桌面设计，感受尤其深：一个功能在开发机上点十遍都顺，到了车间 PDA 上，老师傅连续点三次返回、重复保存两回，问题就出来了。
配置类功能为什么总在“编辑、删除、改子项”时翻车？
这个月大量需求属于平台配置类：工厂建模、零码查询配置、子表列配置、桌面设计。表面看都是简单表单，保存、修改、删除、回显，但最容易出隐性问题。
两个真实例子。删除查询配置的默认值，保存后列表数据没有同步清空；编辑工作单元新增工段，原有工序数据被意外清空。正向流程走一遍，什么都正常。问题全藏在复合操作里——先编辑、再删子项、再保存，界面状态和底层数据就对不上了。
这类 bug 的根子不在代码写得快不快，在操作链路有没有被完整梳理。配置数据有保存态、回显态、删除态、子项变更态，每种状态都要校验边界。开发时借助 TraeCN 加 CodeBuddyCN 能快速搭页面、生成基础脚本，但配置相关的数据联动、状态回写逻辑，工具替不了人。工具擅长产出，人得负责把链路想清楚。
开发机跑得动，现场为什么卡？多端适配的三个坑
这个月现场反馈的性能问题不少：PC 端内存溢出崩溃、PDA 脚本执行卡顿、表格左右滑动闪烁、同一配置在 PC、平板、PDA 渲染表现不一致。
第一个坑，拿开发机当判断标准。车间设备性能参差不齐，开发机上流畅的动态表格和大配置子表，到 PDA 上就是大量 DOM 渲染加脚本运算，卡顿是必然的。桌面设计的 PDA 脚本这个月专门做了执行逻辑优化，不良代码过站回显才顺起来。
第二个坑，只测正常路径。现场业务人员会重复保存、连续点击、多次返回，这些动作在自测阶段不主动模拟，上线后就是交互异常。工装点检计划多次点检后返回层级异常，就是这么暴露的。
第三个坑，多端只验一端。同一个配置功能，必须在 PC、平板、PDA 分别验证渲染效果，保证统一。工具能辅助生成基础代码和简单优化方案，但现场设备兼容和性能调优，还是要结合车间实际环境去打磨。
AI 写基础代码可以，为什么数据一致性还得人工盯？
这个月全程用 TraeCN 搭配 CodeBuddyCN 做编码、调试和重构，效率确实高。但边界也很清楚：工具擅长快速产出基础代码，复杂配置场景的数据流转、状态回写、边界校验，需要人工把操作链路梳理清楚。
换句话说，AI 把“写”的成本降下来了，“想”的成本没降。配置类功能的交付质量，取决于开发有没有在动手前把保存、修改、删除、子项变更的完整链路画出来，有没有把复合操作场景列进自测清单。这个月踩过的坑，基本都出在链路没画全，而不是代码写不出。
这套开发逻辑背后，是精工智能数字化工厂研发的常态：iMES6、iTPM、JMOM 多端前端开发，PC、平板、PDA 三端同时适配，配置类功能要在真实车间环境里跑稳，而不是在办公室把功能做完就算数。研发把现场当考场，工具提效、人工兜底，交付才稳。
精工智能数字化工厂的研发，把现场当考场——在真实数据、真实网络、真实操作习惯里把系统磨稳，而不是在办公室把功能做完就算交付。配置类功能如此，多端适配如此，AI 辅助开发也如此：工具负责快，人负责对。
