软件最理想的运行环境是演示机。真实产线上跑的是网络波动、脏数据、临时改的需求，和屏幕前那台机器完全不是一回事。
十月，在某制造企业的AGV项目里，一个看似简单的问题让我重新思考了“功能完成”的标准：PDA生产领料时，AGV是否按照先进先出叫料？从操作上看，扫描单据、选择目的位置、点击呼叫，设备能够接到任务，流程似乎已经走通。但现场问的不是“能不能叫到料”，而是“叫的顺序对不对”。这两句话之间，隔着一条完整的业务链路，也隔着开发工程师对现场的理解。
一、AGV叫料“能叫到料”，为什么还不算功能完成？
顺着PDA请求、后端选料和任务下发链路检查后，我们发现原有逻辑主要按照容器编码选择候选容器，没有依据生产日期或收料日期排序。也就是说，设备能接到任务，流程能跑完，但候选容器的先后顺序并不符合“先进先出”的业务要求。
这就是开发里最容易误判的地方：把“任务下发成功”当成“功能完成”。在演示环境里，只要PDA点得动、AGV动得了，看起来就是通了；到了真实仓库，业务人员关心的是先叫哪一箱、后叫哪一箱，旧料会不会压在新料后面，批次会不会因此混乱。能够叫到料，并不代表叫料顺序符合业务要求。
功能完成的第一个标准，不是接口返回成功，而是选择规则真正参与了候选容器的筛选。如果规则没有进入候选库存查询，没有影响容器选择，只是在代码里多了一个日期字段，那它就没有真正生效。开发要做的，是把业务语言翻译成系统里的排序键、过滤条件和异常分支，而不是停在“能跑通”。
二、“先进先出”落到容器和条码上，到底以哪个日期为准？
接下来要解决的，不只是增加一个日期排序。先进先出以生产日期还是收料日期为准？一个容器里有多个条码，生产日期不同时，又该用哪个日期代表这个容器？这些条件如果没有先确认，代码即使运行正常，也可能执行了另一套规则。
经过沟通，业务口径明确为按生产日期选料；同一容器存在不同生产日期的条码时，取其中最早的日期作为排序依据。随后，我们将日期带入候选库存查询和容器选择过程，同时保留原有的锁定、预约和重复呼叫排除条件。
这一步看起来是技术实现，实际是需求澄清。比如容器A001里有10月20日、10月22日两个条码，容器日期取10月20日；容器B009里有10月10日、10月18日两个条码，容器日期取10月10日。按最早生产日期排序，B009优先叫料，而不是看容器编码谁大谁小。这个例子只用于说明规则，不是现场数据。
“先进先出”听起来没有歧义，真正落到容器、条码和库存状态上，却需要逐项说明。排序键是什么、容器代表日期怎么取、锁定和预约的容器要不要排除、重复呼叫怎么处理，每一项都会改变最终选中的容器。把这些条件问清楚，实现和验证才有共同依据。精工智能数字化工厂的研发把现场当考场，在真实数据、真实操作习惯里把系统磨稳，而不是在办公室把功能做完就算交付。
三、回库完成之后，为什么原储位还留着容器信息？
同月处理的回库问题，让我看到了链路另一端的重要性。现场反馈，容器回库后，原储位仍保留着容器信息。沿着任务创建和完成回调检查，发现任务保存的来源位置类型，与回调识别具体储位时使用的内部类型不一致，导致原储位解绑步骤被跳过。
容器已经移动，系统中的位置关系却没有同步更新。这意味着设备动作完成后，业务数据仍可能停留在上一个状态，进而影响后续储位分配和任务判断。因此，排查不能停在“任务已经完成”，还要继续确认原储位是否释放、目标位置是否正确绑定。
修复时，我们既处理了新任务的位置类型转换，也兼顾了修复前已下发、尚未完成的任务。但已经完成的历史任务，不会因为更新代码而自动重放。遗留绑定仍需核对容器实际位置后单独处理。新逻辑修复和历史数据处理，需要分别说明、分别验证。
这类问题最能说明“功能完成”的另一层含义：设备动作完成只是开始，业务数据同步更新才算闭环。开发如果只看任务状态，不看储位与容器的绑定关系，现场就会出现在制品已经走了、系统里还占着位置的情况。后续储位分配、任务判断、库存查询都会受影响。把新逻辑和历史数据分开处理，是对现场负责，也是对后续运维负责。
四、AI能帮你找代码，为什么最后还要回到现场核对？
在这些工作中，我使用AI辅助梳理调用链、比较字段含义和检查修改影响。它帮助我更快找到相关代码，也让我更清楚地认识到，工具分析必须与现场事实相互核对。业务口径需要沟通确认，容器位置需要现场核实，修改方案需要经过验证，每一步都有自己的依据。
验证时，我重点检查了一个场景：容器编码较小，但物料生产日期较新；另一个容器编码较大，但物料生产日期较早。只有后者优先被选中，才能说明新规则真正参与了选择。目前相关模块编译和独立选料检查已通过，实际叫料效果仍需结合现场库存与AGV任务联调确认。
这也是本地检查和现场联调的边界。编译通过、独立选料检查通过，证明代码逻辑在给定条件下成立；现场库存是否复杂、任务是否并发、异常容器是否被排除，还要在真实环境里验证。开发不能把本地验证当成现场结论，也不能把AI分析当成业务口径。工具能帮你找代码，但容器实际在哪、业务到底按哪个日期算，必须回到现场和业务人员那里确认。
回顾十月，我对“功能完成”有了更具体的理解：选料规则要真正影响容器选择，任务完成后要正确更新位置关系，修复要考虑已有任务，验证也要明确本地检查与现场联调的边界。后续面对“先进先出”“回库完成”这样的需求描述，我会多追问一步：具体以什么为准，由哪个环节保证，又用什么场景证明它已经生效。把这些答案提前写进需求和验证记录，让每一次问题处理都留下可复用的经验，是这个月AGV项目带给我的收获。
精工智能数字化工厂的研发，把现场当考场——在真实数据、真实网络、真实操作习惯里把系统磨稳，而不是在办公室把功能做完就算交付。
AGV叫料和回库这类功能，看起来是仓库里的“小动作”，实际决定现场愿不愿意用、敢不敢把库存交给系统。制造业数字化比的不是功能清单长短，而是业务规则能不能走完整条链路。
