悬丝诊脉—记一次AI时代debug经历

相信经验质疑AI开发、测试都不能全交给ai大撒把事情始于这两个扫出来的问题P1-1收编patch_20260629init_schema_phase1.sql中rs_data_item_metadata.spatial_refVARCHAR(64)→TEXT。patch文件保留供存量库升级不新增compose挂载。P1-2统一spatial_ref写入口径把compactSpatialRef截断≤64、超长时提取EPSG码从IngestPipelineDataItemService抽为公共静态工具建议common包或ingest包内工具类TaskPreprocessDataItemRegistrationService写spatial_ref前过同一compact。列保持TEXT兜底代码口径统一为紧凑标签优先与patch_20260629注释的设计意图一致。数据库用的postgresql需要记录坐标系信息ai建议varchar改为text后端优化解析坐标系字符串的代码很合理。我评估这两条可以一并修改突然灵机一动postgis自带spatial_ref_sys坐标定义表如下是否可以用来校验坐标系字段但是在数据库里并没有找到这个表有点疑惑问了下ai惊了不用postgis靠json存地理数据临时还行后面数据量上来了查询效率很差但和手头工作无关就先记一下手动装上了postgis扩展后续再优化现有表吧。由于服务器数据库镜像是postgresql而不是postgis所以没敢用表校验万一哪天容器重构用的还是postgresql那功能会连带着遭殃于是转而引入geotools。为什么一开始没用因为我以为有postgis无需引入新库就能解决的话何必多此一举那既然情况是这样该装就装了后端增加空间功能依赖也能提高容错算是解决眼前未雨绸缪。一番讨论开始进行并提示ai做好记录发现ai只改了初始化sql语句没有运行的记录习惯性质疑防患于未然我真怕不说清楚codex给我又装个maven或者搞出啥幺蛾子浪费我的时间和token继续质疑我需要知道这个功能的源头毕竟字符串里解析坐标系谁知道这个字符串会是个什么妖魔鬼怪最好在源头就做好限制。ai可能想到也可能没想到但我不能猜一番溯源还真让我发现个问题读不到坐标系就默认设为4490这不瞎胡闹么一些自定义坐标系或者本身就不带坐标系的都会被污染造成误解全部改完走单测结果还行问题可以关闭了总结一下不要让ai接管你的思考你要比ai更了解代码ai管的了的你要知道ai管不了的你更要知道