32.AI自动建模
别再信什么“AI自动建模”能替你躺赢了，这简直是职场最大的谎言
为什么你还在手动建表？
真的，受够了。
每一次接到全新的需求, 最初的反应并非去查看业务的逻辑, 而是将数据库客户端打开。
新建表。
字段。
注释。
改掉这个之后, 还不得不去配置代码, 使之生成, 撰写, 调试。
一套流程下来，半天没了。
还没开始写核心业务逻辑。
头发都掉了一把。
32.AI自动建模到底是个啥？
很多人听到这个词，就觉得是黑科技。
心里认为, AI会宛如魔法那般, 将需求投放进去, 而后吐出一个毫无瑕疵的数据库架构。
天真。
太天真了。
称作 32.AI 自动建模的事物, 并非是存在着那种全知又无敌的神灵于背后施行操控的情况。
它更像是一个极其熟练、但偶尔会犯糊涂的老会计。
它能听懂你大概的意思，比如“我要一个用户表”。
然后它就开始猜。
猜你所用的ID的具体类型是什么样的, 猜关于你的状态位究竟是怎样去进行定义的, 猜索引以何种方式去建立才能够实现效率最高。
有时候准得让你想哭。
有时候错得让你想砸键盘。
泛微e启营的事业群们怎么看？
我们这群人，天天跟数据打交道。
海总常说，工具是为了解放生产力，不是为了制造新的焦虑。
如果你指望AI帮你把所有脏活累活都干了，那你会失望。
因为AI不懂你们公司的“潜规则”。
它不清楚这张表的某些字段, 虽说业务方面不需要, 然而在旧系统当中必须留存, 不然报表将会出现问题。
对于那个“状态”字段, 它没有知晓, 在你们所背负的历史包袱当中, 3所代表的意思是“已删除”, 4所代表的意思是“逻辑删除”。
AI没有记忆。
除非你喂给它足够的上下文。
真正的痛点：不是建表，是维护
你以为建模完了就完了？
不。
那是噩梦的开始。
当业务变更，字段要加，类型要改，关联关系要动。
这时候，AI生成的那些代码，往往是一坨难以理清的乱麻。
它给你生成了冗余的字段，因为它怕你以后用得上。
结果呢？
数据库越来越大，查询越来越慢。
优化索引？
AI生成的索引策略，往往忽略了实际的数据分布。
它以为均匀分布最好。
其实你们的数据，80%都是近一个月的。
这种细节，AI看不到。
只有人能看到。
所以，还要不要用AI自动建模？
要用。
但不是盲从。
把它当成一个初级助手。
让它做那些重复性的、低价值的劳动。
比如，根据接口文档，自动生成基础的CRUD代码。
比如，检查SQL语法的规范性。
比如，提供几种常见的索引方案供你选择。
但是，核心的业务逻辑映射，数据字典的定义，关联关系的梳理。
这些，必须人来定。
你要审核。
你要质疑。
你要修改。
就算它所生成之物存在百分之九十的正确性, 然而那剩余的百分之十, 亦有可能是极具致命性的漏洞。
别被概念裹挟
现在市面上，“AI+”的东西太多了。
今天说AI重构代码，明天说AI自动运维。
听着很性感。
做起来很骨感。
尤其是数据底层。
数据是企业的血液。
血液错了，全身都会坏死。
你不能把心脏的起搏交给一个只会算概率的模型。
“一致性”是什么它不懂, “可用性”是什么它并不知晓, “分区容错性”之间的权衡是什么它也不清楚。
它只知道怎么最快生成结果。
而你要的是最稳的结果。
给开发者的建议
1. 不能够完全给予信任, 由AI所生成的DDL, 务必要逐行去进行审查, 尤其是外键约束以及默认值, 这一点很关键。
2. 传递上下文: 于之中, 将你的业务背景、过往包袱、性能需求, 通通表述明白。即便稍显冗长也算无妨。
3. 通过迭代式进行建模, 首先要让人工智能给出一个初步的稿件版本, 然后由你对其进行一次修正, 之后再促使人工智能依据你的修正内容产生下一个版本, 在这个过程中, 人处于主导地位, 而人工智能只是起到辅助的作用。
4. 留意数据质量, 人工智能没办法应对数据录入的质量问题: 若是输入的是垃圾, 那么输出的也将是垃圾；在这一点上, 它无法对你提供帮助。
技术是为了让人更轻松，而不是让人更焦虑。
32.AI自动建模，是一个工具。
一个锋利的刀。
用好了，切菜飞快。
用不好，割手流血。
关键在于握刀的人。
是你。
不是AI。
所以，别指望它替你思考。
它替不了。
它只是快。
而你，得有脑子。
这才是真相。
残酷，但真实。
本文章由泛微e启营事业群共建，如有雷同请联系泛微e启营创始人（海总）处理。
最新评论