Skip to content

AI 时代的数据架构师

另有 28 种语言版本

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

A construction 3D printer lays the curved concrete walls of a small house, with the plan it is building from unrolled on a table in front.
图片由 AI 生成

第 7 个模块,共 7 个,属于 Data Architect 课程的第一章像数据架构师一样思考。每个模块都可以单独阅读。 上一篇:了解你的工具:九个问题 · 下一篇:下一章:数据建模

**本模块回答的问题:**AI 为数据架构师改变了什么,又没有改变什么?

AI 正在改变架构,但也许不是人们最初想的那种方式。

还记得本章的开头吗:我职业生涯的大部分时间都是一个构建者。在那段时间的大部分里,构建软件是昂贵的。你需要具备专门技能的人,写代码、构建集成、创建应用和测试都需要时间;哪怕只是试验一个想法,也是一笔不小的投入。AI 正在改变这个等式。今天,我可以描述我想要什么,让 AI 以惊人的速度生成数据模型、Apex、Flow、Lightning 组件、集成、测试或文档,而明天它还能做更多。

所以有理由问:如果 AI 能承担这么多构建工作,架构师会怎样?我认为答案是:架构变得更重要,而不是更不重要。

我在演讲中用过这个类比:

AI 是火箭助推器。架构是制导系统。

AI 给了我们非凡的加速度。我们能以前所未有的速度生成应用、数据模型、集成、测试和文档。但火箭助推器不决定火箭该去哪里,它只提供推力。决定航向、沿途修正的,是制导系统。

没有可靠的制导,更多的推力帮不上忙,它只会让你更快地到达错误的目的地。架构师的工作不是让一切慢下来,而是确保我们在朝正确的方向加速。

一枚土星五号风格的火箭模型横放在建筑蓝图上,红色标注表示 AI 提供的推力,蓝色标注表示架构上的制导和航向修正

图片由 AI 生成。

想象一个 AI 工具,构建应用的速度比我们以前快十倍。如果构建的是正确的应用,那太好了。但如果数据模型错了,或者我们选错了标准对象,或者误解了主数据该放在哪里,或者设计在今天的数据量下能用、多一个零就崩溃呢?AI 并没有消除错误。它帮我们更快地把错误建了出来,并且在任何人注意到之前,在错误之上又建了多得多的东西。

当实现昂贵时,注意力自然会集中在实现上:谁能构建它,要花多久,到底能不能做出来。当实现变得更便宜时,另一个问题就更重要了:**我们应该构建什么?**这是一个架构问题。

AI 可以生成二十个对象;数据架构师决定我们是否应该只有五个。AI 可以生成一个集成;架构师决定数据到底该不该被复制。AI 能在几秒内创建一个字段;架构师会问它是否有明确的含义、一个所有者和存在的理由。AI 构建我们要求的东西,所以我们提出要求的质量比以往任何时候都重要。

AI 非常擅长生成选项,这极其有用。我让它给出三种建模方式,列出权衡,质疑一个架构,告诉我数据达到 1 亿条时会怎样、设计可能在哪里失败,或者给我一个 Salesforce 不是记录系统的替代方案。我希望架构师都这样做。

但生成选项和评判选项是两回事。AI 可以告诉我选项 A 和选项 B 各自能带来什么。但仍然需要有人足够了解业务,才能知道哪些优势重要,哪些约束是真实的,什么风险可以接受,以及什么时候一个答案在技术上说得通却不适合这个组织。这就是判断,这就是架构。

这一点在我自己的工作中是这样体现的。过去一年里,我已经不再亲手写大部分代码了。我把细节交给 AI,让它生成界面和后端代码,它做得出奇地好。

但它不会退后一步,做更深入的分析。如果数据模型或设计里有缺陷,它不会质疑。它把已经存在的东西当作前提,在此之上迅速而熟练地继续构建。它很少会停下来说:“在我加上这个之前,你现有的模型也许值得改一改。”审视已有的东西,问它是否正确,而不只是问我们能否在它之上构建下一样东西,这仍然是架构师的工作。如果你想让 AI 质疑某个前提,你必须主动要求它这样做。

回到模块 3 的问题:这个决定以后要逆转会有多难?AI 改变的是生成和修改软件的成本,它不改变修改现实的成本。1 亿条记录一旦加载,就存在了。十二个系统一旦依赖某个标识符,这些依赖就存在了。客户一旦用上某个流程,或者分析一旦依赖某个字段的含义,改动它就会有后果。而数据一旦被共享到不该去的地方,再多新代码也无法把它收回。

不可逆的依然不可逆。

过去我们为两类消费者设计数据:人和软件。人读取一条记录;报表、集成或应用读取数据。现在出现了第三类:智能体。智能体可能会检索数据、解读数据、把它与其他信息结合、做出决定并采取行动,有时中间没有任何人参与。

这提高了风险。一个字段是什么意思,谁拥有它,它有多新、多可信,它是否敏感,智能体能不能、该不该看到它,两个来源不一致时怎么办:这些过去只是文档,现在则是一个智能系统理解业务的方式。

而坏数据不会因为 AI 读取它就变聪明。垃圾进,垃圾出,依然成立。重复的客户、不清晰的所有权、不一致的标识符和相互冲突的记录系统,并不会在你接入一个智能体后消失;只是后果变得更显眼了。一个人看一眼某个字段,就知道三年没人更新过它。智能体没有这种组织内部的常识,它可能会对所有人心照不宣地知道不可信的数据充满自信地采取行动。数据架构成为 AI 架构的一部分。

AI 也让创建东西变得极其容易。需要再加一个对象、六个字段、一个自动化?生成就是了。每个决定看起来都很便宜,但还记得模块 3 里的架构引力吗:这些对象和字段会聚集依赖(自动化、集成、报表、智能体),很快你就有了一个没人设计过的数据模型。它只是自己长出来的。

架构师必须敢于问:“我们真的需要这个吗?”有时最有价值的决定是不去创建某样东西。好的架构,既在于你放进了什么,也在于你留下了什么没放。

当我说应该由人类架构师来评审 AI 生成的数据模型时,我不是指“AI 创建了它,Steve 看了五分钟图就批准了”。那不是监督。架构师必须理解这个模型:为什么是这些对象,为什么是这些关系,考虑过哪些替代方案,键和主数据在哪里,数据量增长时会怎样,访问方面有什么影响,做了哪些权衡。如果我回答不了这些问题,我并不拥有这个架构,我只是盖了个章。AI 可以为架构出力、质疑它、为它写文档,但人类架构师必须能够为它辩护。

事实也是如此。我一直在用 AI 学习和做研究,我的原则是信任,但要验证。提出问题,要它解释,要它给出替代方案,并质疑它自己的答案。然后,对任何对你的架构重要的事情,点开链接,阅读文档,核对限制,确认许可,测试行为。AI 出错时可能非常有说服力,而区分事实和假设,现在在工作中占的分量更大了。

谈到成为架构师时,我常说一句话:

AI 不会缩短这段旅程。它能让每一步都更有分量。

你仍然需要理解数据、安全、集成、平台和业务,你仍然需要做决定并承担后果的经验。AI 可以加快你的学习,给你看你没遇到过的场景,为你解释,向你发起挑战,帮你构建,给你多一双眼睛。把这些都用起来。只是不要把 AI 知道答案,误当成你理解了答案。

本章开头讲的是手握蓝图的人。AI 给了这个人非凡的新工具:一个能画出部分蓝图、研究材料、提出替代方案、计算荷载、撰写文档,甚至发现你漏掉的问题的助手。用它。但仍然需要有人理解整栋建筑,问一问这是不是对的建筑,知道需求变化时会怎样、哪些决定撤销起来代价高昂,并为结果负责。

这就是为什么这门课的最后一个层级叫作 Direct(指挥)。你也许不会写每一行代码、创建每一个 Flow、构建每一个对象。但仍然得有人指挥整个解决方案,而那个人就是架构师。AI 并没有消灭架构,它在改变架构师创造价值的地方。现在正是成为架构师的非凡时刻。

  • 既然构建已经很便宜,到底该构建什么:哪些对象、字段和集成值得存在。
  • 哪些 AI 生成的选项适合这个业务,哪些看似合理实则错误。
  • AI 正在飞速掠过的哪些决定,以后逆转起来会代价高昂。
  • 智能体可以读取什么、据此做什么,以及数据是否足够好、描述是否足够清楚,能让它们这样做。
  • 来自 AI 的哪些事实,在影响设计之前需要核实。

这就是 AI 时代像架构师一样思考。