入职半年才发现，写代码从来不是工程师的核心工作

最离谱不是技术栈老，是我根本不知道自己在改什么。

手册上写「字段 07 必须为 3」，我照做了。但这字段到底触发哪个下游批处理？会不会把对账跑挂？没人能在半小时内给我讲清楚——架构师早走啦，文档上次更新是 2012 年，现场只有运维大姐知道「改这行前先备份那个 VSAM」，但她也说不出业务逻辑。

KT、Simulation、Hands-on 三阶段培训走完，真上手那天才发现：模拟环境里的「成功」全是绿灯，生产环境一跑起来，CICS 事务码报 S0C7、DB2 锁升级、MQ 消息堆积，根本不按套路出牌。

后来我偷偷把关键 JCL 拉下来喂给内部部署的 CodeLlama-34B，让它帮我梳理依赖图。模型把 3000 行 JCL 里的 PROC 调用链、DD 语句依赖、GDG 版本滚动全理顺了，还标出了「修改此处会影响夜间批处理窗口的 3 个下游 Job」。审核通过那天，组长问我「怎么突然懂这么全了」，我只能说「最近在复盘文档」。

现在团队新人入职，我直接把那份模型生成的依赖图甩给他们：「先看这个，再动手。」省下两周盲摸期。

说白了，工程师的价值不在于敲多快键盘，而在于能不能在「不知道为什么」的灰度地带里，把风险锁死、把上下文补全。AI 不能替你背锅，但能帮你把那 3000 行没人维护的 JCL 变成人类可读的上下文——这才是我这半年最实在的收获。