CodeBuddy如何基于数据库表结构自动生成Model代码

让AI根据数据库表结构自动生成Model代码，听起来是个能极大提升开发效率的“黑科技”。但在实际使用CodeBuddy这类工具时，不少开发者都遇到过这样的尴尬：生成的Model要么字段缺失，要么类型对不上，甚至干脆没生成对应的类。这背后的原因，多半是AI没能准确“理解”你的数据库元信息，或者项目上下文没有完整地“喂”给它。

别担心，这通常不是工具本身的问题，而是信息传递的环节出了岔子。下面这五个步骤，能帮你系统地排查和解决这个问题，让AI生成的Model代码既准确又省心。

一、确保CODEBUDDY.md中完整声明数据库Schema

CodeBuddy的核心工作逻辑，是读取你项目根目录下的CODEBUDDY.md文件。这个文件就像是给AI的一份“项目说明书”。如果说明书里没写清楚数据库表长什么样，AI自然只能靠猜，结果当然不尽如人意。

所以，第一步就是检查并完善这份说明书：

首先，找到或创建项目根目录下的CODEBUDDY.md文件。然后，你需要用Markdown表格的形式，把目标数据表的结构明明白白地列出来。字段名、数据类型、是否主键、是否允许为空、有没有外键关联……这些信息一个都不能少。

别忘了，在文件的“技术栈”部分，务必注明你使用的ORM框架（比如TypeORM、Sequelize还是Entity Framework Core）及其具体版本。信息越精确，AI的“发挥”空间就越小，生成的结果也就越可靠。

做完这些，保存文件，然后在CodeBuddy里尝试执行这样的指令：“根据当前CODEBUDDY.md中定义的user表结构，为TypeORM生成User实体类”。看看这次AI是不是“听话”多了。

二、使用CLI命令触发数据库反向工程

如果你已经连接了真实的数据库，那么手动维护一份Schema描述就显得有点多余，而且容易出错。这时候，CodeBuddy CLI内置的数据库反向工程（DB introspection）功能就派上用场了。它能直接从数据库里读取元数据，一步到位生成Model代码。

操作起来也很简单：确保你的项目已经配置好了正确的数据库连接信息（比如通过DATABASE_URL环境变量或者.env文件）。然后，在终端里执行类似下面的命令：

codebuddy db:generate-models --dialect postgres --output src/models/

如果一切顺利，你会在终端看到“Found 5 tables”、“Generated User.ts, Order.ts…”这样的成功提示。接下来，去检查生成的TypeScript文件，看看@Column、@PrimaryColumn、@ManyToOne这些装饰器是不是都符合TypeORM的规范。

三、手动提供SQL建表语句作为上下文输入

有些时候，数据库可能还不可访问，或者你只是在设计原型阶段。这时，直接把CREATE TABLE语句丢给AI，是个非常高效的临时解决方案。

具体做法是：复制一份完整的建表SQL语句，比如：

CREATE TABLE products (id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, price DECIMAL(10,2));

然后，在CodeBuddy的聊天框里，先发送指令：“基于以下PostgreSQL建表语句，为Prisma ORM生成Product模型定义”。紧接着，在下一行把SQL语句粘贴进去。稍等片刻，AI就会返回一个prisma/schema.prisma文件里标准的model Product { ... }代码块。

四、启用长期记忆注入数据库约定规则

你有没有发现，每次生成Model都得重复交代一遍命名规则？比如，数据库字段是snake_case，但代码里要用camelCase；created_at字段应该映射成Date类型；is_deleted字段是软删除标志，需要特殊处理……

每次都讲一遍太累了。好在，你可以把这些规则“教”给CodeBuddy，让它记住。

先在对话中输入/init指令来初始化上下文。然后，发送这样一段话：

“记住：所有数据库字段名均为snake_case；生成Model时自动转换为camelCase；含_created_at后缀的字段映射为Date类型；含_is_deleted的字段视为软删除标志，添加@default(false)和@map('is_deleted')”

设置好之后，下次你再让它“为users表生成NestJS + TypeORM User实体类”，它就会自动把created_at转成createdAt: Date，并带上@Column({ name: 'created_at' })装饰器，省心多了。

五、校验并修复生成结果中的常见偏差

即便做了以上所有工作，AI生成的Model偶尔还是会出现一些小偏差。比如，把数据库的TINYINT（布尔值）误判为number类型，忽略了某些索引或联合主键的声明，等等。这时候，就需要我们进行最后一步——人工校验和针对性修正。

打开你的数据库管理工具（比如DBea ver或pgAdmin），导出目标表的完整DDL语句。然后，逐字段比对DDL和AI生成的Model代码，重点关注数据类型、NULL约束、默认值、外键引用这些容易出错的地方。

如果发现某个字段有问题，别急着全盘重来。很多工具支持局部重生成。比如，你可以选中User.id字段所在的行，通过右键菜单选择“CodeBuddy → Regenerate this field”，然后输入针对性的提示词：

“id为BIGSERIAL主键，映射为number类型，添加@PrimaryColumn()和@Column({ type: 'bigint' })”

修改完成后，保存文件，并运行npx typeorm schema:log之类的命令，验证生成的迁移语句是否与原始表结构完全一致。这一步做完，你的Model代码就既精准又可靠了。