大佬们, 设计数据库, 是交给 AI 还是自己设计?

需求确定交给 AI，不确定等自己梳理完再让 AI 处理。

自己出方案让ai辅助写DDL啊。

自己只梳理需求, 具体的数据库让 AI 处理吗? 这个需求, 是产品需求还是数据库设计指南呢?

需求文档自己提炼重点模块，喂给ai，让他设计，设计完，你自己过一遍，再让他输出ddl，再过一遍，再执行

然后再把剩余的模块按上述步骤弄完

业务需求，你固定的一些限定条件，需要哪种形式，使用的环境。也可以在对话中逐步完善。

全交给ai设计了 反正领导也不看数据库 只关心token用的多不多

能跑就行 需求给AI，AI出结果，自己就是个测试 ^-^

这样搞过, 迭代到后面, 感觉成了一坨^-^ ^-^

一直是这样的, 但越迭代, 代码越臭, 感觉还不如手搓代码, 想提炼一套方法论出来, 避免不停踩坑

有明确的想法直接告诉ai让它执行生成DDL和实体类和基础的crud就行，没有明确想法就讨论出一个满意的方案后再让它执行上述内容。大部分业务自己大概都知道怎么设计更合适，没必要讨论半天或者去赌它设计的结构。

现在我根本就不考虑了,反正领导只想提效,我现在每天想的就是如何快速烧token

就是说, AI 设计, 自己审核, 是吗?

那要干涉具体的设计还是只纠正业务理解?

就像上面那个例子, 自己要下场和 AI 说使用第2种数据库设计, 还是从业务层面纠正呢?

这种还是要结合具体业务需求考虑。方案里不一定需要直接规定最终一定拆成几张表，而是应该说明当前两个实体存在较多字段重合，需要评估它们是否属于同一业务实体，以及未来变化方向是否一致。

如果两个实体生命周期和业务逻辑基本一致，可以考虑抽取公共字段，通过单表 + 类型扩展的方式设计；如果虽然字段类似，但后续业务行为和扩展方向差异较大，则拆成独立表会更合适。具体表结构可以再根据实际需求由 AI 辅助设计。

AI 其实无法感知你的业务扩展逻辑，它看到的只是当前需求。两个实体现在字段一样，不代表未来一定会一样。到底合并还是拆分，关键看后续业务会不会分叉、生命周期是不是一致，这个应该在方案阶段考虑清楚，不能完全丢给 AI。AI 更适合帮你优化实现，而不是替你做业务架构决策。

有道理, 谢谢, 看来我还是太纠结如何让 AI 主导设计, 有点太依赖 AI 的权威性了.

无论是你还是agent发现需求问题、设计问题、代码问题，从效率、省token、别让代码成屎山难维护角度，人都需要随时干预、审核、修改

有道理, 谢谢, 看来有些事件不管用不用 AI, 都是省不掉的.

当前的这个时代，尽可能，就不要自己插手了，AI很棒

回复里, 基本分两派, AI 辅助设计, 和 AI 主导设计.

目前我(独立开发)的使用体验下来, AI 主导设计还是差点意思, 特别是在持续迭代方面.

也可能和我没有好的 Agents 或 Skills 有关, 又或者文档管理, 项目管理没做好.