第一次准备软著材料时，我最头疼的不是代码，而是数据库设计文档。项目是自己一点点做出来的，表结构也在数据库里躺着，可真要按申报材料的格式整理成文档，才发现事情没那么简单。
字段要补注释，表关系要画图，主外键、索引、默认值、字段含义都得说清楚。更麻烦的是，代码迭代过几轮，早期建的表和后来临时加的字段混在一起，单靠手写很容易前后不一致。后来我开始用 AI生成数据库设计文档，效率确实高了不少，但中间也踩过一些坑。
一、不要一上来就让AI自由发挥
刚开始我试过直接给AI一句提示：“帮我生成一份电商系统的数据库设计说明书。”结果它很快吐出几十页内容，用户表、订单表、商品表看着都挺完整，但仔细一看，很多内容并不属于我的项目。
比如它默认加了会员等级、积分账户、第三方登录表，可我的系统里根本没有这些模块。字段类型也偏理想化，动不动就是 BIGINT、JSON、DECIMAL(18,2)，和我实际数据库里的 VARCHAR、INT、DATETIME 对不上。这种文档如果直接放进软著材料里，风险很明显：文档和源代码、数据库实际结构不一致，审查时容易被认为材料拼凑。
后来我调整了做法。先从数据库导出真实的建表语句，也就是 SHOW CREATE TABLE 的结果，或者直接导出 schema.sql，再把这些内容交给AI。提示词也不再写得很虚，而是明确要求：只基于我提供的 SQL 生成，不允许新增不存在的表和字段；字段名、类型、长度、是否为空、主键、索引必须原样保留；每个字段要结合字段名和业务含义补中文说明。
这样生成出来的内容才真正像自己项目里的东西，而不是一份通用模板。
二、AI最适合处理的是“整理”，不是“发明”
数据库设计文档通常包括系统概述、表结构汇总、各表字段说明、表关系说明、主键索引设计，以及实体关系图说明。真正费时间的，是把几百个字段逐条搬成表格，还要统一语言风格。
这件事AI做得很快。我一般会先让AI按表输出字段清单，包括字段名、数据类型、约束、默认值和说明。然后让它单独整理一份表关系说明，例如用户表和订单表是一对多，订单主表和订单明细表是一对多，商品表和分类表通过分类字段关联。最后再让它根据已有 SQL 归纳主键设计和索引设计。
但这里有个边界：业务含义不能完全交给AI猜。像 status 这种字段，不同表里可能差别很大。订单状态可能是 0待支付、1已支付、2已取消；售后状态又是另一套编码。AI不知道枚举值时，会写成“状态字段，表示业务状态”，这种话放在文档里价值很低。我的做法是把代码里的枚举类、常量定义或注释一并贴给它，让它按真实取值补说明。
还有一些字段名是团队历史习惯，比如 is_del 实际用 0 和 1 表示未删除和已删除，type 字段在不同表里含义完全不同。这种地方一定要人工核对，不能图省事。
三、软著材料里，数据库文档要和系统截图对得上
软署申报不是单纯交一份数据库说明。它需要源代码、操作说明书、系统功能说明、数据库设计等材料之间能够互相印证。我后来检查材料时，会专门看三个地方。
第一，功能模块里出现的名称，能不能在表结构中找到依据。比如后台有“优惠券管理”，数据库里就应有优惠券相关表；如果文档写了“供应商结算”，但代码和界面完全没有，这就很突兀。
第二，字段说明不能和界面对不上。截图里显示的是“客户编号”，文档里却写成“会员ID”；页面上叫“入库单号”，表里字段注释成“订单编号”，这种小错特别容易出现。AI润色时喜欢统一术语，但软著材料更看重前后一致。
第三，表关系不要写得过度复杂。有些AI为了显得专业，会把所有表都连成一张密密麻麻的关系图，还会虚构外键。实际上不少业务系统在物理数据库层面并没有建外键，只是通过 user_id、order_id 这样的字段做逻辑关联。文档里应如实写成“逻辑关联”，不要硬说创建了外键约束。
如果平时经常要整理这类材料，也可以试试 软著Pro，网站是 https://ruanzhu.pro。我比较喜欢它的一点，是能围绕软著申报场景处理文档和代码材料，不用自己在各种模板之间来回搬内容。不过无论用什么工具，最终导出的数据库文档都建议人工过一遍。
四、我的实际操作流程
现在再做新项目，我基本按固定流程走。先确认当前数据库版本，把建表语句完整导出；然后清理测试阶段废弃的表，避免把临时表、备份表也写进正式文档。接着把 SQL 分段发给AI，表太多时不要一次性塞进去，否则它容易漏掉后面的表，或者把字段串到别的表里。
AI生成初稿后，我会先核对表数量和表名，再逐表抽查字段类型、主键和索引。字段说明主要看三类：状态类、类型类、金额类。金额字段尤其要小心，比如 DECIMAL(10,2) 和 DECIMAL(18,4) 含义不同，单位是元还是分也必须写清楚。
之后再补系统概述和设计说明。这部分我不会让AI写得太宏大，通常只说明系统采用 MySQL 数据库，字符集使用 utf8mb4，主键采用自增ID或业务唯一编号，核心表围绕用户、业务单据、商品或项目信息展开。简单、真实，比堆概念更有用。
最后一步是排版。软著材料的文档不建议颜色花哨，表格宽度要统一，字段名尽量用等宽样式，表名和标题层级保持一致。AI生成的 Markdown 表格转成 Word 后，常常会出现列宽错乱、中文字体不统一的问题，这些都要手动调一下。
五、几个容易踩坑的地方
最常见的问题，是直接把AI生成的通用数据库设计交上去。这样虽然页数够，但一看就不像本人项目。软著材料不怕简单，怕的是不对应。
第二个坑，是让AI根据实体类反推数据库。实体类可以作为参考，但它可能加了序列化字段、扩展字段、ORM框架注解里的临时属性，并不等于真实表结构。有条件的话，还是以数据库建表语句为准。
第三个坑，是忽略敏感信息。导出的 SQL 里可能带数据库账号、服务器地址、测试手机号、真实企业名称，甚至密钥配置。交给AI或放进文档前要脱敏。这和软著能不能通过没有直接关系，但属于基本安全意识。
第四个坑，是图表缺失。数据库设计文档里如果能放一张 ER 图，阅读体验会好很多。AI有时只能用 Mermaid 或 PlantUML 生成关系代码，复制到 Word 里并不能直接变成图片。我一般会让它先输出 Mermaid 代码，再到支持渲染的工具里导出图片，最后检查连线是否正确。
说到底，数据库设计文档生成更像一个加速整理的过程。它能把枯燥的字段搬运、格式统一、说明补全工作压缩到很短时间，但判断系统真实结构、业务含义和材料一致性的人，仍然只能是开发者自己。把真实 SQL 给足，把边界讲清楚，再做人工核对，AI生成的数据库设计文档才既省事，又经得起申报材料的检查。
