代理报告43个风箱测点，我数出42个——点位梳理里差点带歧义交付的瞬间

42还是43：一个数字逼我把代理摘要推翻

烧结侧风箱测点，代理回报43个。我拿源文件一查：sb_temp1~22是22个，upres1~22跳过了第7和第9，剩20个，加起来42。差1个。

这1个看着无关紧要，但交付文档里写43就是埋雷。下游对接的人拿43去配表，多出来的那个点根本不存在，跑起来就是空值告警。所以我在动笔写文档前，专门回源文件把每一行upres的编号过了一遍，确认跳过逻辑是硬编码在SQL里的，不是代理把注释行误算进去了。最终交付数字锁定42。

把154条配置拆成可核对的清单

高炉侧核心是bf_points_config表，154条初始化数据。烧结侧更碎：sm_qs_page_points有219行趋势/风箱配置，另有料仓11个点位、风箱页226行定义。总量加起来近400行，靠脑子记不住，靠一次全量dump又不便于逐条判断。

我的做法是先建任务清单，把点位按模块切开：

• 高炉：建表SQL、初始化数据、轮询任务代码，三条线
• 烧结：趋势页、风箱页、料仓，三块独立SQL
• 动态路径：代码里有没有运行时拼接点位名的逻辑（这块靠人肉grep效率太低）

每块定好'交付物是什么'——是一行行原文，还是一个数值——再决定用代理还是自己读。

并行派两个代理，但摘要不能当结论

动态路径逻辑散落在多个类里，我同时派了两个探索代理，一个走高炉、一个走烧结，让它们各自把'点位名是怎么拼出来的'这条链路挖出来。两个代理5分钟内返回了完整梳理，质量不错。

但有个教训：烧结侧代理摘要里写风箱测点43个，跟源文件对不上。我后来验证了趋势页/风箱页的226行，是拿V4.2版本的140行定义做交叉验证，两边一致才敢写进文档。规则很简单——代理给的数字，必须回源文件核对至少一次；代理给的结构，可以信，但关键数值不能只信。

V4.20第75行那个*(

烧结侧V4.20的SQL文件，第75行开头多了一个*(，看着像注释符和左括号粘在一起。我第一反应是文件被谁手动改过，把一行注释的*和下一行SQL的(连了。

核实方式很笨：拿V4.2的同位置文件做diff，确认V4.2第74行结尾是完整闭合的，V4.20多了那个*(。结论是文件本身有语法异常，不是我的工具解析问题。这个标记写进了交付文档的'已知问题'一节，提醒后续维护的人别在V4.20上直接跑。

可带走的一条方法

这次梳理从开工到交付文档（点位对接明细文档-高炉与烧结.md），最核心的原则就一条：每个数字都有出处，每条出处都能回溯到源文件行号。

具体操作上：

1. 大任务先拆成'模块 × 交付物类型'矩阵，别一上来就通读
2. 代理/工具给的摘要当索引用，关键数值必须回原文核
3. 版本间交叉验证（V4.2 vs V4.20）能抓住单版本里的静默错误
4. 发现矛盾（42 vs 43）就停下来查，别'差不多就行'带着歧义往下走

点位对接这类活儿，错一个编号就是下游多跑一次告警，成本远大于多花十分钟核对。

---

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

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