钢铁轧制数据项目AI审计：从17项问题定位到跨Agent协作

产线数据看板上，开坯工序的产量、合格率数据实时跳动，但压延、锯切工序的数据却停在半小时前。工艺员蹲在机台旁边翻了半小时数据库日志，愣是找不到轧制结束时间没落库的原因——这是我们钢铁轧制工业数据项目审计时遇到的真实场景。作为项目总架构师，我主导了对这套支撑轧制全工序数据链路的系统做了一次全量审计，过程中既挖出隐埋半年的数据链路 bug，也踩了 AI 辅助开发里"修复项假落地"的坑。

第一阶段审计：工序校验定位 17 项问题

本次审计覆盖开坯、压延、锯切、收集、收尾五个阶段共 40+ 项校验任务，先按工序链路逐节点校验：阶段一（开坯）10 项任务全部通过；阶段二（压延/锯切/收集）存在 5 项功能缺失；阶段五（重置/收尾）4 项任务里有 3 项未完成。最终梳理出 17 项问题，按优先级分高（6 项）、中（7 项）、低（4 项）。

两个典型修复案例很能说明问题。一个是 SignalSnapshotConsumer.java 的异常自吞：这个类负责消费开坯工序的快照消息、触发下游压延工序启动，但之前的实现捕获异常后直接空处理，既不打印日志也不触发重试，开坯完成后压延收不到信号直接停摆，排查了三天才发现是异常被吞了。修复后加了异常日志加重试机制，联调时压延工序启动成功率从 72% 升到 100%。

另一个是 TandemRollingJudge.java 的 end_time 落库滞后：连轧判定逻辑里，轧制结束时间只存在内存变量里，等整批处理完才统一落库，导致产线追溯时轧制时间比实际晚 2-3 分钟，质检追溯完全失效；修复后改成每判定完一块轧件就立即落库，时间误差控制在 100ms 以内。

5 项高优先级修复全部通过编译验证和工序联调，阶段一开坯全链路和基建组件达到正式交接标准，审计记录整理成标准化文档存在项目 docs/audit 目录下。

验证阶段意外：标记的修复项一个都没落地

完成第一阶段审计后，我牵头执行四阶段检查报告中修改要求的验证任务，却发现之前标记为已修复的 4 个 P0、3 个 P1 项根本没落地：包括 Base_Column_List 补列、validateSawingStatus 方案 B 优化、连轧空过逻辑修正，全部停留在"已标记修复"的状态，实际代码毫无改动。

排查后核心问题是指令不清晰：之前的修复指令只说了"要修复 XX 问题"，没说清楚验收标准、依赖模块、对接人。比如 Base_Column_List 补列需要前端同步改查询接口，但之前没同步给前端负责的 Agent，后端改了一半卡住；连轧空过逻辑的修复涉及两个模块接口对齐，之前没明确对接人，两边都以为对方会改，最后都没动。

解决思路是重新输出需求文档 V7，每个修复项都明确写"验收标准、依赖方、对接人、完成时限"，按模块给子 Agent 派任务时强制所有相关方同步参会，建立每日站会同步进度，还针对修复项设计了 36 个测试用例，覆盖正常场景（锯切正常出料、连轧正常轧制）、边界场景（锯切无料、卡料、连轧空过、断带）、异常场景（消息队列积压、数据库连接超时）、性能场景（产线峰值时段的并发处理），确保修复项真能落地。

跨 Agent 协作沉淀下来的经验

这次审计也把 AI 辅助工业项目的协作经验理清了：子 Agent 分派要按业务模块拆分，每个 Agent 只负责一个阶段的逻辑，明确输入输出和依赖关系，比如压延模块的输入是开坯的快照消息，所以要求压延 Agent 每天同步和开坯模块的联调结果，有问题 2 小时内响应；同时要明确 AI 的决策边界——涉及产线工艺规则、后续迭代规划的决策（比如锯切三场景的架构规划要不要单独立项、阶段五的重置逻辑要不要重构），全部记录下来留给业务方决策，避免 AI 乱改规则出问题。

工业数据项目的审计不能只走代码，得结合工序逻辑做端到端校验，每个时间点、每个信号都要对应产线的实际动作，否则很容易漏掉隐埋的业务逻辑 bug。给 AI 下修复指令必须附带明确的验收标准和依赖方清单，光说"修复 XX 问题"就会变成假落地；模块之间有依赖时，每日站会比一次性派完任务高效得多；测试用例也一定要覆盖卡料、断带、空过这些业务边界，它们比正常逻辑更容易出问题，也更容易影响产线运行。

---

做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。

这篇里提到的坑，都是真金白银踩出来的。
如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作
——可以在评论区说说你的场景，我看看能不能自动化掉。