上周排查一个数据串台问题：2#机组的实时数据莫名出现在1#机组的看板上。顺着调用链翻了三处代码，发现unit_code字段在异常时静默兜底为SM1，三处兜底逻辑还不一致。一个字段没校验，两机组数据直接交叉。
这个bug只是冰山一角。把三项目、前后端共6个代码库拉通看了一遍，真正触目惊心的是：约170个点位仍然硬编码在Java常量类里，所有点位配置表没有任何管理界面——改一个点位，改完代码，发版，祈祷别漏改另一处。
炼铁端的bf_points_config：唯一做对了的事
在炼铁后端里找到一张表叫bf_points_config，字段关系是 custom_code ↔ point_path ↔ unit_code ↔ page_code。我翻了irononline、charge、dump、ironreport四条链路的代码，确认改点位只需UPDATE这张表，前端零硬编码、零发版。
这是整套系统里架构最干净的一块。烧结端的SM_QS_PAGE_POINTS（11个页面、140+点位）和SM_SCALE_MATERIAL_CONFIG（带enabled开关，V4.16的注释原话是"换点位UPDATE即可代码零改动"）方向一致，但覆盖面远不如炼铁端完整。
烧结端：140个字段塞进常量类，改一个点位要发版
烧结侧的硬编码重灾区集中在三个文件：
SinterBoardPointConst：11个点位，常量名直接写死前缀ProcessParamFieldConst：140个字段，每个字段对应一个点位路径StmxServiceImpl方法体：里面还残留一棵root.zhb的旧树，以及若干SJ1前缀的TODO注释
这意味着运营侧想换一个点位映射，开发得改常量→改业务方法→改前端→联调→发版。一次改动至少两三个人的工时，而炼铁端同一件事是一条SQL。
前后端双端硬编码：chart-config.ts和RealtimePointConst的同步噩梦
实时监控模块的点位定义同时存在于前端的chart-config.ts和后端的RealtimePointConst。两边没有共享数据源，全靠开发人肉同步。我对比了两份文件的字段名和path，至少有三处已经对不上——前端还在用旧的点位标识，后端已经换了，页面表现就是某条曲线偶发空白。
另外炼铁前端采用了"一炉座一后端实例"的架构，点位路径里嵌了炉座编号，多钢厂场景下同一张表要适配不同编号规则，复杂度进一步放大。
三条能带走的准则
复盘完六库，把设计建议压缩成三条，下次做多站点/多产线配置时可以直接当checklist用：
- 点位定义只允许出现在数据库里。任何Java常量类、TS配置文件里出现点位path，都视为技术债。参照bf_points_config的custom_code中间层，业务代码只认custom_code，path映射走配置表。
- unit_code等关键维度字段禁止静默兜底。兜底值写死等于把"1#"变成默认假设，多钢厂上线那一刻就是事故。要么抛异常，要么走显式配置，三处兜底逻辑必须收敛到一个公共方法。
- 前后端点位定义必须同源。要么共享一份JSON/数据库查询接口，要么至少写一个CI脚本diff两边字段集合，CI红了就不许合。人肉同步在第三处对不上的时候就已经晚了。
最后说一句交付物：完整的分析文档《点位配置现状分析与多钢厂产品化设计建议.md》已落到项目wiki。里面把170个硬编码点位按"炼铁/烧结/球团×实时/报表/告警"做了矩阵标注，每条标了迁移优先级。下次排产品化排期时，直接拿这张矩阵当拆解依据就行。
做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。
这篇里提到的坑，都是真金白银踩出来的。
如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作
——可以在评论区说说你的场景，我看看能不能自动化掉。
