夜雨聆风这个月我干了三件事：用AI辅助写了12篇银行数据需求文档，用Codex跑了80条Hive SQL review，顺手把一个EAST报送的字段口径梳理流程自动化了。结果呢？数据组说"省了30%人工审校时间"，但我自己的感受是：这30%全变成学新工具的时间了。AI提效这东西，领导看见数字觉得值，具体干活的人知道——前三次切换成本最高。
一、本月成果：三个场景真实测出AI能做什么
场景一：需求文档从两天到三小时以前接一个1104新报送任务，需求文档要两天——读制度、扒历史模板、问业务口径、等业务确认。7月份我试着用Codex读制度PDF做摘要，再让ChatGPT按模板出草稿，最后我逐条核对。实际跑了三小时出初稿，业务确认只花了一轮。
关键不是"AI能写"，是"AI能把你最不想写的初稿先搞出来"——这个动作本身就让业务方觉得你在推进，他们愿意配合确认细节。反过来，如果你拿着空白文档去问业务，业务的第一反应是"你先把框架给我看看"。AI解决了这个冷启动问题。
场景二：Hive SQL review从人工全检到AI初筛数据组的SQL review以前是全检，每条都要人肉过一遍语法和口径逻辑。这个月我让Codex先跑一遍初筛，标出"可能有问题"的字段（比如SUM和COUNT混用、日期分区写法不统一、NULL处理缺失），reviewer只看不通过的。80条SQL里，AI初筛标了15条有问题，人工复核确认了11条确实有问题，命中率73%。
但有一个问题我没解决：AI标"没问题"的65条里，我抽查发现3条有口径问题——AI没拦住。AI擅长找语法问题，不擅长找业务语义问题。这个弱点要认。
场景三：EAST报送字段口径文档自动化EAST报送最麻烦的不是跑SQL，是每期报送前要核对字段口径——哪些字段变了、哪些取值范围调整了、哪些是新增的。以前这事靠EXCEL台账手工维护，每次报送前要花两天核对。
7月份我写了一个小工具，自动从制度文件和历史报送SQL里提取字段元信息，生成字段变更说明文档。这事AI帮了忙，但核心是结构化提取逻辑，不是生成式AI。这个场景说明：不是所有银行数据工作都适合用生成式AI，有些场景用规则+正则更稳。
二、本月踩的三个坑
坑一：AI生成SQL直接上生产，差点出事7月第二周，一条AI生成的ODS→DWD的SQL被提交到灰度环境，AI写了三表JOIN，其中一个JOIN条件用了"近似匹配"（LIKE '%关键字%'），数据量一大直接拉爆了灰度节点。
复盘根因：AI不知道生产环境的ODS表数据量级。它按"语法正确+逻辑看起来对"出结果，但没有考虑到这条SQL在生产环境里要跑多少数据。我后来加了一条规则：所有AI生成的SQL，上了生产之前必须跑EXPLAIN看执行计划，数据量超过1000万的JOIN必须人肉review。这个规则救了我后面好几次。
坑二：用DeepSeek处理客户数据，差点碰合规红线7月中旬，数据组有个同事问：能不能用DeepSeek处理一批脱敏后的客户交易数据做特征工程？
我当时第一反应是：脱敏了应该没事。后来仔细看行里关于数据外用的规定，发现"脱敏"和"外送"是两个独立动作，脱敏数据如果是通过API发送给外部模型商，仍然属于"数据出境"的范畴，要过合规审批。
后来我和同事说：这个场景合规上不确定，先不走。同事说"那我们手工处理"。这事让我意识到：AI工具进银行数据岗，第一关不是"会不会用"，是"能不能用"——合规判断比工具使用更前置。
坑三：AI日报写了一周，信息密度越来越低7月上半月我每天用AI整理一份"银行AI动态"发给团队，后来停掉了。不是AI不行，是我自己信息源没那么多——每天真正值得说的银行AI落地案例，能收集到的高质量信源就那么两三条。强行日更到第三天，我发现自己开始用"某银行探索AI应用"这种空话填充篇幅。
后来改成周更，有实质性进展才发。阅读量没降，信任度反而升了——团队知道这份简报不是AI自动生成的废话。
三、三个教训：AI进了银行IT，规则要变
教训一：AI是提效工具，不是免责工具AI生成的SQL跑挂了，责任人还是开发。AI写的需求文档出错了，签字的人还是你。银行里没有"AI生成所以我无责"这个说法。
所以核心规则要改：不是"要不要用AI"，是"用AI的结果谁来背"。我现在定的规则是：AI生成的内容，最终审核权在人，AI可以加速初稿，但所有对外交付的东西必须是人签字。
教训二：合规判断要前置，不是后置DeepSeek那个场景，如果我先问合规再决定能不能用，而不是先用再补合规审批，这个坑就不会出现。银行IT的节奏本来就慢，合规前置不是拖后腿，是省去事后补救的时间。
教训三：AI提效的账要算对省了30%人工审校时间——这个数字是怎么算出来的？是我自己填的。数据组的人说"感觉"省了时间，但没有实际度量。AI提效如果没有度量，到年终总结的时候就是一本糊涂账：你自己知道干了多少，领导和审计看的是数字。
建议：选一个高频重复任务（比如每月EAST报送的SQL review），连续记录AI前和AI后的人工耗时，用数据说话。
四、下月计划：两个方向，一个暂停
继续：EAST报送全流程自动化现在只做了字段口径文档，下月目标是：制度解析→字段提取→口径映射→SQL生成→校验逻辑，整条链跑通。如果能跑通，报送前的人工工作量可以从两天压缩到两小时。
继续：AI SQL review工具化初筛命中率73%这个结果让我愿意继续投。下月目标：积累一批"AI漏拦"的案例样本，训练规则让命中率再提一档。同时把工具部署到内部平台，让数据组reviewer可以直接用，不用我本地跑脚本。
暂停：AI日报7月的教训告诉我：信息源的密度不支持日更，硬做是消耗自己的公信力。暂停AI日报，改为有实质性进展才发。有好的案例素材欢迎在群里甩给我。
你们行EAST报送现在是什么状态？
手工跑还是半自动化？每次报送前最费劲的是哪个环节？有没有遇到字段口径对不上、数据源找不到的问题？
我是晓彬,20 年数据经验,10 年银行 IT。
前面的话,都是真金白银换来的。银行监管 / 数据治理 / AI 提效 / 业务连续性。
扫码关注「晓彬聊数据」
