BuildAdmin 2.3.9 把 AI 接入了后台开发中一个很具体的环节：数据表设计。开发者现在可以从 AI 生成的表结构开始可视化 CRUD 流程，并通过“复制上下文”把当前设计交给 Agent 继续处理。与此同时，这个版本还补充了 AGENTS.md 和 AI 系统配置，并收紧了包管理、验证码、刷新令牌等关键路径。
AI 不只是生成代码，而是进入建模起点
传统的可视化 CRUD 通常从一张已经存在的数据表开始：开发者先手写迁移或 SQL，再进入后台生成模型、控制器、验证器和管理页面。2.3.9 增加“从 AI 设计数据表开始”后，入口被提前到了需求建模阶段。
这个变化适合处理结构明确、重复度高的业务模块，例如工单、公告、客户跟进记录和库存流水。开发者可以先描述业务字段、状态流转、查询方式和唯一性约束，再让 AI 给出初稿。
不过，生成结果仍然应该被视为候选设计，而不是可直接进入生产环境的最终结构。尤其要人工检查：
- 金额、比例和时间字段的数据类型是否正确；
- 唯一索引、普通索引与联合索引是否匹配查询条件；
- 字段是否需要允许
NULL，默认值是否符合业务语义； - 状态值是否留出了扩展空间；
- 用户、组织、租户等关联字段是否满足权限模型；
- 删除策略究竟需要软删除、归档还是物理删除。
用 AGENTS.md 固化项目约束
新增 AGENTS.md 的价值在于：把项目规则放进 Agent 能读取的仓库上下文中。这样 AI 在设计表结构或调整 CRUD 代码时，不必依赖开发者每次重复说明命名、索引和安全约束。
下面是一份可以改造的示例。它不是 BuildAdmin 内置配置格式，而是适合放在项目根目录的 Agent 协作约定：
# AGENTS.md
## Database
- Use MySQL 8 compatible SQL.
- Table names use the `ba_` prefix and snake_case.
- Primary keys are unsigned BIGINT named `id`.
- Store money as DECIMAL(12,2), never FLOAT.
- Add `create_time` and `update_time` as integer timestamps.
- Do not add physical foreign keys; document relationships in comments.
- Add indexes only for confirmed filters, joins, and ordering paths.
## CRUD
- Validate all writable fields on the server.
- Never expose password hashes, tokens, or internal secrets in list APIs.
- Every update and delete operation must pass authorization checks.
- Generated migrations must be reviewed before execution.
## Output
- Explain index choices.
- List assumptions and unresolved business rules.
- Include rollback SQL for schema changes.
配合可视化 CRUD 的“复制上下文”按钮，可以把当前模块信息连同下面这类提示词一起交给 Agent：
请为“售后工单”设计数据表，并遵守仓库中的 AGENTS.md。
业务要求：
1. 工单属于一个客户和一名负责人。
2. 状态包括待处理、处理中、已解决、已关闭。
3. 列表需要按工单编号精确查询，并按客户名称、负责人和状态筛选。
4. 需要记录创建时间、更新时间和解决时间。
5. 工单编号必须唯一。
输出：
- 字段定义及理由
- 索引设计及对应查询场景
- MySQL 8 建表 SQL
- 风险与待确认问题
这里最重要的不是让 AI 多写代码，而是要求它同时解释索引依据和未确认假设。没有这些信息，团队很难判断生成结果是否真的适合业务。
一条可落地的 AI 建表审查流程
假设 AI 为工单模块生成了 SQL，可以先保存为 ticket.sql，再在隔离的本地数据库中验证。下面的示例表结构仅用于展示审查流程，字段和前缀需要按实际项目调整：
CREATE TABLE `ba_service_ticket` (
`id` bigint unsigned NOT NULL AUTO_INCREMENT,
`ticket_no` varchar(32) NOT NULL COMMENT 'Ticket number',
`customer_id` bigint unsigned NOT NULL,
`assignee_id` bigint unsigned DEFAULT NULL,
`status` tinyint unsigned NOT NULL DEFAULT 0,
`subject` varchar(200) NOT NULL,
`resolved_time` int unsigned DEFAULT NULL,
`create_time` int unsigned NOT NULL,
`update_time` int unsigned NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_ticket_no` (`ticket_no`),
KEY `idx_status_assignee` (`status`, `assignee_id`),
KEY `idx_customer_id` (`customer_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
可通过 Docker 启动临时 MySQL 进行语法验证，不要直接把首次生成的 SQL 应用到生产库：
docker run --rm --name buildadmin-mysql-review \
-e MYSQL_ROOT_PASSWORD=reviewpass \
-e MYSQL_DATABASE=buildadmin_review \
-p 3307:3306 \
-d mysql:8.0
until docker exec buildadmin-mysql-review \
mysqladmin ping -uroot -previewpass --silent; do sleep 2; done
docker exec -i buildadmin-mysql-review \
mysql -uroot -previewpass buildadmin_review < ticket.sql
docker exec buildadmin-mysql-review \
mysql -uroot -previewpass buildadmin_review \
-e 'SHOW CREATE TABLE ba_service_ticket\G'
验证通过后，还应使用真实的列表查询执行 EXPLAIN，确认索引是否生效。仅仅看到 SQL 能成功执行，并不代表表结构已经满足分页、筛选和排序需求。
安全修复比 AI 功能更需要优先评估
2.3.9 同时调整了多条安全和权限相关逻辑：默认节流配置得到优化，刷新 token 的注销逻辑被修正，点选验证码在单次验证失败后会立即删除，包管理器设置被限制为仅超级管理员可操作。此外，系统安装控制器和模块安装器的 UID 设置也进行了优化。
这些变化会直接影响认证与运维流程。升级回归测试至少应覆盖：
- 退出登录后，旧刷新 token 是否还能换取新访问 token；
- 验证码答错一次后，原挑战是否确实无法再次提交；
- 普通管理员能否访问或修改包管理器设置；
- 节流策略是否误伤登录、文件上传或批量接口；
- 模块安装后的文件所有者和运行用户是否符合部署环境要求；
- 全新安装与已有实例升级是否都能正常完成。
验证码失败即删除可以降低重复试探同一个挑战的风险，但也会增加用户重新获取验证码的次数。前端应明确刷新挑战，并避免继续提交已经失效的验证码标识。
升级时把生成效率和运行安全分开验收
采用 2.3.9 时，可以把验收拆成两条独立链路。AI 与可视化 CRUD 链路重点检查字段质量、上下文完整性、生成结果的可追踪性；认证与安装链路则重点检查权限边界、令牌失效、验证码一次性和部署用户。
推荐的升级清单如下：
- 备份数据库、上传文件和现有配置；
- 对比新增 AI 配置项，并通过环境变量或密钥系统保存敏感凭据；
- 在仓库根目录维护
AGENTS.md，明确数据库和权限规则； - 只在临时数据库执行 AI 首次生成的表结构；
- 对生成的索引、默认值、可空字段和删除策略进行人工评审；
- 回归登录、刷新 token、注销、验证码和管理员权限；
- 检查模块安装产生的文件 UID，避免运行用户失去读写权限；
- 通过测试环境观察节流策略，再逐步发布到生产环境。
这次更新的关键不在于“AI 可以生成一张表”，而在于 BuildAdmin 开始把需求描述、数据建模、CRUD 生成和 Agent 协作串成连续流程。真正决定效果的仍然是项目约束是否清晰，以及团队是否保留了数据库评审和安全回归两道关口。