夜雨聆风
一、每个公司都有一段没人敢动的祖传代码
先说个真事。
我有个朋友老陈，在一家零售企业做数据负责人。他们公司的数据仓库跑了十几年，里面躺着两千多个存储过程，全是T-SQL写的。
写这些代码的人，早就离职了。注释？基本没有。文档？不存在的。每次业务说想改个报表逻辑，团队里最怕的就是翻开那些存储过程——没人知道改了一行，会牵连出哪十行。
去年公司想换新平台，找咨询公司报了个价：七位数，工期八个月，其中一半时间花在"代码分析和翻译"上。
老板看完报价单，这事就搁置了。祖传代码继续躺在那里，像一颗谁也不敢拆的炸弹。
老陈的困扰，几乎是所有有一定年头的公司的共同困境：系统越老越不敢动，越不敢动就越老。
上周我刷到Databricks发的一篇官方博客，看完第一反应就是想起了老陈——他们新出的一个叫Genie Code的AI Agent，干的就是"拆炸弹"这件事：把各种老式数据库的私有SQL方言，自动翻译成通用的ANSI SQL。
我替你把官方文档和完整演示扒了一遍，把整套流程拆成了能看懂的5步。不管你写不写代码，这套打法都值得花20分钟看完——因为它揭示了一个更重要的东西：AI处理"烂摊子"的标准姿势，已经成型了。
二、这个工具到底干了件什么事
先交代背景，一句话就能说清楚。
以前企业用的数据仓库五花八门——微软的SQL Server、Oracle、Teradata，后来的Snowflake、Redshift、BigQuery——每家都有一套自己的SQL"方言"。同样的逻辑，在A家这么写，在B家就得那么写。
这就导致迁移系统成了一件又贵又慢的体力活：得有人一行行读懂旧方言，再一句句翻译成新语法，中间还不能把业务逻辑改错。一个大项目动辄几千个脚本，纯靠人肉，就是老陈收到的那个报价：七位数，八个月。
Genie Code这次更新的"agentic converter"，支持把T-SQL、Snowflake、Redshift、Oracle、BigQuery、Teradata这六种方言，自动转成开放的ANSI SQL。
官方的说法很值得玩味：它把数据仓库迁移，从"一个需要组建团队、立项管理的工程"，变成了"一个你配置好、点启动、然后盯着看的任务"。
而且它不是在实验室里跑通的那种玩具。它的前身Lakebridge，去年在Data and AI Summit上发布，已经帮超过一千家客户完成了向新平台的迁移。
好，背景交代完，进正题。我把它演示里的完整流程拆成了5步，每一步我都附上了"这步为什么这么设计"的解读。
三、我替你拆解了它的完整流程，一共5步
第1步：建一个"迁移项目"，把所有烂摊子收进一个篮子
第一步不是让AI上手改代码，而是先在工作区里建一个Migration Project。
源文件上传进去之后，每个文件的类型、代码行数、迁移状态，全都列在一个面板里。哪个文件多少行、改没改完、卡在哪，一目了然。
这步看起来平平无奇，但其实是所有大工程的第一原则：先把混乱可视化。 烂摊子之所以可怕，是因为它是一团看不清的迷雾。一旦变成一张清单，恐惧感就少了一半。
第2步：AI先给每个文件打"复杂度分"，先易后难
接下来，Genie Code会逐个分析文件，给每个脚本打一个复杂度评分。
演示里有个文件叫mixed_5cats_sp_string_agg.sql，评分是"低复杂度"，因为它用到的SQL特性都能干净利落地映射到ANSI SQL。
这个评分的用处是什么？排兵布阵。 真实迁移项目动辄几百上千个文件，有了评分，团队就可以先把简单的批量解决掉，快速积累战果和信心，再集中火力啃硬骨头。
而不是像以前那样，第一天上来就被最难的文件卡住，项目开工即停滞。
第3步：画出"血缘图"，搞清楚谁和谁拴在一起
这是我个人觉得最值钱的一步。
Genie Code会自动分析整个旧系统里所有对象之间的依赖关系——哪张表被哪个视图引用，哪个存储过程调用了哪几张表——然后生成一张完整的血缘图。
演示里的例子：sps_sp_update_from.sql和sps_sp_pivot.sql这两个文件，血缘图显示它们之间没有任何共享依赖。这意味着什么？它们可以分开独立迁移，互不干扰。
反过来，如果两个文件在图上纠缠在一起，你就得把它们打包成一个批次一起动，否则改了一个、另一个就崩。
以前搞清楚这些依赖，要靠最有经验的老员工翻代码翻几个星期。现在AI几分钟画完。
第4步：放出一群子Agent，并行开干
分析完，点击"Run"，正戏开始。
Genie Code不是单个AI在那顺序改代码，而是一次性放出一群子Agent，并行处理多个文件。每个子Agent还不是改完就交差——它会反复自我验证：语法能不能通过解析？语义上跟原来的业务逻辑等不等价？发现问题就自己迭代修复，直到跑通为止。
演示的结果是：8个T-SQL存储过程，6个全自动转换成功，文件按状态用颜色标好，绿色通过，红色待处理。
注意这个数字——75%的工作，人一行代码没写。
第5步：人只处理例外，并且把修法"沉淀成规则"
剩下2个标红的文件，才是真正需要人出面的地方。但即便是这里，AI也把活儿干了一大半。
点开其中一个，右侧面板直接列出了待办清单。AI用大白话告诉你问题出在哪：这两个存储过程必须改成三段式全限定名（catalog.schema.sp_string_agg），才能符合新平台Unity Catalog的规范。
你可以打开并排对比的编辑器，左边旧代码右边新代码，手动把这一处改掉。
但更精彩的操作是另一个：你可以把这条修法创建成一个custom skill——也就是一条自定义转换规则。等到跑全量迁移的时候，这条规则会自动应用到整个代码库的所有同类问题上。
修一次，处处生效。你今天踩的坑，变成明天AI的自动动作。
四、真正值钱的不是这个工具，是这套打法
我知道，看到这里很多读者会说：我又不是数据工程师，这跟我有什么关系？
关系大了。因为Databricks这个工具的设计，无意中给出了一套用AI处理任何烂摊子的通用方法论。这套方法论一共五条，我替你提炼出来了：
第一条：先评估，再动手。 不要让AI上来就蛮干。先让它给任务清单里的每一项打复杂度分，你就知道该先吃哪块、后啃哪块。
第二条：画依赖图，确定顺序。 让AI先告诉你哪些任务互相纠缠、哪些彼此独立。独立的并行处理，纠缠的打包处理。顺序错了，事倍功半。
第三条：让AI并行啃大头。 明确、重复、有固定模式的活儿，全部批量交给AI。这类工作在任何烂摊子里都占七成以上。
第四条：人只处理例外。 你的时间和精力，只花在AI标红的那25%上。而且从"做"变成了"审"——AI连问题清单和修改建议都给你列好了。
第五条：把修法沉淀成规则。 每解决一个例外，都顺手把解法变成一条可复用的规则或提示词模板。烂摊子越处理越快，这是复利。
举几个不写代码也能用的例子。
你要把几百篇旧公众号文章迁移到新平台？先让AI按格式复杂度分类，再找出互相引用的文章批次处理，最后把"图片链接替换规则"沉淀成模板，剩下的全自动。
你要交接一个烂尾项目？先让AI读完全部文档，输出一份模块依赖图和风险评分，你只看高风险的那几处。
你刚接手一个离职同事留下的几十张Excel表？让AI先盘点每张表的用途和关联，打分排序，简单的自动清洗，口径有问题的标出来给你看。
工具会变，平台会换，但这五条打法，三五年内都不过时。
五、最后，一个有点残酷的判断
过去职场里有个心照不宣的事实：脏活累活，其实是很多人的护城河。
系统越老越乱，越离不开那个愿意蹲在里面收拾的人。会读祖传代码、敢动老系统，本身就是一种稀缺能力，能换钱，能换安全感。
但Genie Code这类工具的出现，意味着这条护城河正在被填平。读旧代码、翻译方言、梳理依赖——这些过去最熬人、也最"值钱"的苦力，恰恰是AI最擅长批量吃掉的部分。
那以后人的价值在哪？往两头走。
一头是定义问题：决定迁什么、不迁什么，什么顺序迁，验收标准是什么。另一头是验收结果：AI说转换完成了，业务逻辑真的等价吗？这得有人拍板。
中间那段最漫长、最枯燥的执行，正在快速地从"人的工作"变成"盯着AI做的工作"。
老陈们的炸弹，终于有人帮忙拆了。只是拆炸弹这件事本身，也不再需要那么多人了。
结尾互动
如果这篇文章对你有帮助，点击右下角"推荐"，让更多人看到。
关注「飘雪思考」，每周更新职场干货与底层思维，和10万+读者一起成长。
💬 你怎么看？ 你公司里有那种"没人敢动的祖传系统"吗？如果AI能替你收拾，你敢用吗？
欢迎在评论区留下你的想法，我都会看的。
📌 收藏这篇文章，下次遇到接手烂摊子、迁移旧系统、整理历史资料，直接翻出来用。
觉得有用就转发给朋友，说不定正好帮到需要的人。