通义灵码是阿里巴巴推出的AI编程助手，基于通义大模型打造，可以在IDEA、VS Code等主流开发工具中以插件形式使用。它最实用的能力之一，就是根据自然语言描述生成数据库相关代码，包括建表SQL、实体类、Mapper映射文件、Repository接口等。这篇文章带你完整走一遍流程，从安装配置到实际生成，再到生成后的检查事项，看完就能上手。
一、安装通义灵码插件
以IntelliJ IDEA为例，打开Settings（macOS上是Preferences），进入Plugins市场，搜索“TONGYI Lingma”，找到通义灵码插件后点击Install，安装完成重启IDE即可。VS Code用户则在扩展商店中搜索同样的关键字安装。重启后IDE右侧或底部会出现通义灵码的面板图标，点击后需要用阿里云账号登录，支持手机号、钉钉等方式，登录成功后就能免费使用个人版功能。
登录完成后建议先确认网络连接正常，因为代码生成依赖云端大模型推理，如果公司内网有代理限制，需要在插件设置中配置HTTP代理，否则会出现请求超时的问题。配置妥当后，新建一个Java项目或打开已有项目，就可以开始体验了。
二、用自然语言生成建表SQL
通义灵码提供了AI程序员对话框和代码注释补全两种交互方式。第一种是直接在对话框中描述需求，比如在右侧面板输入“生成一个用户表的MySQL建表语句，包含id主键自增、用户名、密码、邮箱、创建时间、更新时间，使用utf8mb4字符集”，它会返回一段完整的SQL：
CREATE TABLE `user` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID', `username` VARCHAR(64) NOT NULL COMMENT '用户名', `password` VARCHAR(128) NOT NULL COMMENT '密码', `email` VARCHAR(128) DEFAULT NULL COMMENT '邮箱', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
生成结果通常带有字段注释和合理的索引设计，但要注意字段长度、索引策略是否符合你所在团队的规范，必要时在对话中追加要求让它调整，例如“把用户名字段改成32位并增加邮箱唯一索引”，模型会基于上下文给出修改后的版本。
三、通过注释引导生成实体类和CRUD代码
第二种方式更贴近日常编码习惯，直接在代码文件里写注释。新建一个空的Java文件，输入注释描述你想生成的类，然后按回车等待补全：
// 用户实体类，对应user表，使用MyBatis-Plus注解，
// 字段包括id、username、password、email、createTime、updateTime
// 并生成对应的Mapper接口，包含按用户名查询和分页查询方法
public class User {
}通义灵码会根据注释内容自动补全整个类结构，包括@TableName、@TableId等注解以及Lombok注解，同时可以继续生成Mapper接口：
@Mapper
public interface UserMapper extends BaseMapper<User> {
// 按用户名精确查询
@Select("SELECT * FROM user WHERE username = #{username}")
User selectByUsername(@Param("username") String username);
// 分页查询用户列表
IPage<User> selectUserPage(Page<User> page);
}如果项目使用的是原生MyBatis而不是MyBatis-Plus，只需在注释中说明“使用MyBatis XML映射文件”，它就会生成接口加XML的组合，把SQL写在<mapper>文件里。这种注释引导的方式的好处在于，注释越具体，生成结果越贴近预期，你可以在注释中约定返回值类型、异常处理方式甚至日志打印格式。
四、生成JPA或Spring Data版本的代码
不使用MyBatis的团队同样适用。在对话框中输入“基于Spring Data JPA生成用户实体的Repository，支持按邮箱查找、按创建时间范围分页查询”，会得到类似下面的代码：
public interface UserRepository extends JpaRepository<User, Long> {
Optional<User> findByEmail(String email);
Page<User> findByCreateTimeBetween(
LocalDateTime start,
LocalDateTime end,
Pageable pageable);
}Spring Data JPA的方法名推导规则比较严格，findByCreateTimeBetween这类命名必须准确，手动写容易拼错，交给AI生成反而出错的概率更低。不过仍然要自己确认实体字段上的@Column映射是否与真实表结构一致，尤其是驼峰与下划线转换的部分，不同项目的命名策略配置可能导致映射偏差。
五、生成后的检查要点与常见坑
AI生成的代码不能盲目照搬，数据库操作尤其如此。第一，检查SQL注入风险，如果生成的查询语句采用了字符串拼接，务必改成占位符传参的写法。第二，检查事务注解，涉及多表写入的方法需要确认是否补上了@Transactional，AI有时会遗漏。第三，核对字段类型映射，比如MySQL的DATETIME映射为Java 8的LocalDateTime还是旧的Date类，按团队规范统一。
另外有几个实际使用中的小技巧：生成大段代码时如果中途中断，可以直接回复“继续”让它接着输出；对生成结果不满意时，明确指出哪里需要改，比重新描述一遍需求效果更好；在项目根目录放置规范说明文件并在对话中引用，可以让生成风格与团队规范保持一致。工程实践上建议把建表SQL、实体类、Mapper分层生成，每层确认后再生成下一层，这样可控性远高于一次性生成全部代码。
整体来看，通义灵码在数据库代码生成场景下能省掉大量模板化编码时间，尤其是字段众多的宽表和重复的CRUD逻辑。把AI的产出当作一份高质量初稿，再叠加自己的审查和调整，才是当前阶段最稳妥的用法。