AI替代数据开发?我用了半年,觉得你们想多了

上周在技术群里，有人发了张截图：

某大厂数据团队，8个人缩到3个，剩下5个岗位"由AI工具承接"。

底下一堆人回复"瑟瑟发抖""准备转行了".

我盯着那条消息看了很久。

不是因为我怕——说实话，半年以前我也怕过。那时候我刚把AI工具塞进日常工作流，每天试各种生成SQL的prompt，心里也在算：这玩意儿再进化两轮，我这岗位还在不在？

但用了半年之后，我的结论可能跟你想的不太一样：

AI替代数据开发？我觉得你们想多了。

不是唱反调，是这半年里，我亲眼看着它撞上了三道墙——而且这三道墙，短期内根本过不去。

上个月发生了一件事。

业务部门要做一个"新品首月动销率"的看板。需求很简单，一句话。我把这句话丢给AI，让它生成SQL。

AI 30秒吐了一段代码，看起来挺像样的。

但我看了一眼就知道有问题——它把"动销"理解成了"有销售记录就行"，可我们公司对"动销"的定义是"单款单色单码有销售才算"，而且要剔除内部调拨和退货。

这些规则散落在三个不同的文档里，还有两个是口头约定的。

我后来算了算，让AI把这段SQL改对，我前前后后喂了7轮上下文，加起来花的口舌，比自己写还多。

这是上个月另一个真事。

上游系统改了订单表的一个字段长度，从varchar(50)扩到varchar(100)。改动很小，业务部门觉得"没什么影响"。

但我知道有问题——这条字段在数仓里被17个ETL任务引用，下游串联了5层模型，最终影响到3个业务部门的日报和1个给老板看的经营分析大屏。

这种影响面，不是靠血缘工具扫一圈就能完全覆盖的。有些任务虽然引用了这张表，但逻辑上并不依赖那个字段；有些任务表面没直接引用，但通过中间表间接关联——这些隐性链路，只有人才能判断。

AI可以告诉你"这张表被哪些地方引用了"，但它判断不了"这次改动到底影响多大、风险在哪"。

这面墙最硬。

去年双十一，某条核心供应链数据延迟了3小时入账。结果是：大区总监在早上8点的经营会上，看到的库存数据是昨天的。

会后有人问：这个数据谁负责？

你总不能指着一段AI生成的代码说："是它干的。"

数据开发有一个隐性职责，是兜底。系统挂了要有人排查，数据错了要有人溯源，业务凌晨打电话来问"这个数怎么不对"要有人接。

AI可以生成代码，但它不能承担责任。而在企业的生产环境里，"责任"不是虚词——它意味着凌晨两点从床上爬起来排查故障，意味着跟业务部门解释"为什么这个数延迟了"，意味着在复盘会上说"这个问题我认，下次怎么防"。

说到这儿，你可能会觉得我在全盘否定AI。

不是。这半年里，有两个场景我确实离不开它了。

建数仓的时候，最烦的不是写复杂逻辑，是写那些结构一模一样、只有表名和字段名不同的ETL脚本。

比如从ODS层清洗到DWD层，10张表，每张表都要写一段"去重、格式标准化、异常值过滤"的标准流程。以前我一张一张写，一张表15分钟，10张就是两个半小时。

现在我把标准流程写成prompt模板，给AI一张表的字段说明，它30秒出一版，我审一遍直接可用。10张表，30分钟搞定。

这种高重复、低创造性的活儿，AI确实比人快，而且不容易写错。

以前写完ETL代码，还要补数据字典、写逻辑说明文档、更新口径文档。这些文档的准确性和代码同步率，向来是个老大难——改了代码忘了改文档，改了文档忘了同步给下游。

现在我把SQL直接丢给AI，让它反向生成逻辑说明、字段注释、口径定义。虽然生成的内容不能直接用，但作为初稿骨架，省了我80%的敲字时间。

文档这件事，AI不需要理解业务，它只需要准确翻译代码里的逻辑——而这恰恰是目前AI最擅长的。

这半年我的真实体感是：AI像一台挖掘机。以前挖坑靠铁锹，现在有了挖掘机，挖得又快又深——但你得有人坐在驾驶室里，知道往哪挖、挖多深、挖到水管了怎么办。

没有人，挖掘机就是一堆废铁。

—

数据+AI · 数字化实战

专注数据治理与AI落地