声明：本人仅仅负责数据工程中的数仓部分。我的主要业务包括：

• 数据建模；
• 测试以及警报系统的建构；

我的次要业务包括：

• 从各种 API 中获取数据，主要用 Python 写代码；
• 维护兄弟组的串流数据程序；
• 优化下游组的查询和程序；

我上个月开始严肃的用 Cursor 来帮助自己自动化一些开发。以下是我的经验和感触。因为我的经验并不丰富，所以估计以后会有更多的想法。

首先是判断哪些开发比较适合用 AI 自动化。一个比较简单、容易重复的开发，是给现有的 silver 表增加新的列。我们有很多 silver 表是从 s3/dynamoDB 里通过串流数据程序，以 JSON Blob 的方式导入到数据库中，然后再做一些简单的变换而生成的。这部分开发非常简单，但是频率很高，让我烦不胜烦，所以决定第一个拿它开刀。

我尝试了两种办法：

方法一，将所有变换规则都写在子目录的 cursor rules 里，再把 git flow 也写清楚。使用的时候就直接在 chat 里和 AI 对话，让它引用这两个规则，最后本人审核完毕之后，直接修改 dbt 的 models.yml ，最后提交 PR 。整体步骤大概是：

• 生成 feature branch
• 查询 bronze layer 表，确认该列在 blob 中存在，且确认其包括的数据类型；
• 已知数据类型，根据相关的变化规则在 silver layer 的数据模型中增加一列，并在 models.yml 中更新数据辞典和所需的测试规则；
• 将 feature branch 推到远端，并生成 PR ；
• 自动在 Jira 工单里增加评论；

我测试了一段时间，发现方法一还是有些问题。一个是 Cursor 的数据库插件时好时坏，还有一个是 Atlassian 的插件突然就不好用了，我也不确定是什么问题，但是最重要的是，这个方法还是没有解放我自己，我需要和 AI 进行对话。所以我后来决定自己写程序自动化这个流程。

方法二（还在制作过程中），将这部分 silver 表的元信息加入到 models.yml 中，包括列名、列类型等等。然后在 CI/CD 中增加了一个 Python 程序，一旦检测到这部分模型发生变动，那么自动将 models.yml 中的相关数据模型重新“编译”，然后用 dbt compile 和 dbt run --target dev 进行测试。这个方法的好处是，下游组想要新的列，直接修改 models.yml 提交 PR 即可，我只需要审核即可。我使用 AI 来帮我确认 yml 文件的格式，以及帮我来写 Python 程序。因为我比较喜欢写这种程序，所以大部分代码还是自己写，而不是让 AI 生成。

我同时尝试了一下让 AI 帮我从头到尾生成一个全新的数据模型。首先我写了一份详细的 Markdown 表格，里头有对业务数据的简介、下游组为什么要这个数据，每个数据流的元数据（数据流的表的名字，PK 列是哪些？怎么样避免全表扫描？等等），以及下游主所需要的每张表的特点（比如说，subscription 表是需要将数据流 A 和数据流 N 根据某几个列 JOIN 起来，最后生成的表格的每一行是一个 subscription ）。接下来我让 Cursor 直接根据这份清单，写查询从上游的 bronze 数据流的表生成我所需要的 silver 表。我觉得 AI 的表现还是可以的，不是说所有的查询都能一次性完成，但是至少能省我很多力气，总体来说就是把 boilerplate 给自动化了。对于一些比较简单的数据模型，只有 3-4 张表，又不需要非常复杂的变换的那种，基本上可以一次性生成数据模型和所有文档，就是还得自己审查一下。

这个月中，我还用 AI 帮忙生成 JIRA 工单、撰写文档、数据辞典等等。我感觉这方面它的确是个很好的助手。接下来我想要尝试把 AI 接入到 On-Call 中。我们 On-Call 经常会有一些不重要但是必须要处理的问题，而且每次处理方法完全相同。我决定让 AI 筛选一下 On-Call 的警报，如果是这类警报，那就完全交给它，最后搞完之后，重新跑一次警报查询，确认一下，就行了。如果确认不了，或者是其他警报，那么就什么也不做，还是交给我们。但是细细想来，这里其实很多细节问题，还不确定能不能比较好的自动化。

总体来说，我认为 AI 帮助很大。但是也需要接入到内部系统中，写好指示，才能真正发挥作用。我感觉 AI 对各个系统的接合可能是个难题，如果在撰写系统的时候就直接把 AI 考虑进去，那就最好了。只好有待将来继续挖掘了。AI 如果了解数据库的话，就可以回答“我想要这个数据，从哪里拿？“这个下游组经常问我们的问题，也能帮我们解除掉一点压力。

我的感觉，如果进一步整合好的话，AI 起码能够让我的效率增加 50%以上。