最近帮一个朋友整理软件著作权申报材料，他丢给我一份用AI生成的数据库设计文档，说二十分钟就搞定了。我打开一看，格式挺像样，表名、字段、类型、主键、外键都有，甚至还带了索引说明。可往下翻两页，问题就出来了：用户表里同时出现了user_id、uid、id三个字段；订单状态一会儿是数字，一会儿是中文；有些表名叫news_info，注释里写的却是商品管理。
这种文档如果只是内部看看，修修还能用；但放进软著申请材料里，风险就比较大。软著审查虽然不是逐行验证代码，但材料之间要能对得上。你前面写的系统功能、后面附的数据库设计、源代码里出现的表名字段，最好是一套体系。AI写得再漂亮，和你真实程序不一致，也容易让材料显得拼凑。
我现在的做法，是把AI当成一个会写初稿的助理，而不是直接替我定稿的人。尤其是AI生成数据库设计文档这件事，最有价值的地方不是让它凭空编，而是先给它足够明确的上下文。
先把真实表结构喂给它，比让它自由发挥靠谱得多
很多人使用AI时喜欢直接输入“帮我生成一份电商系统数据库设计文档”，这种提示词出来的内容通常很通用。用户表、订单表、商品表、购物车表倒是齐全，但字段未必符合你的系统。比如你实际项目里手机号字段叫mobile，AI可能写成phone；密码字段叫pwd_hash，它可能写成password；创建时间叫create_time，它可能统一写成created_at。
如果时间紧，我一般会先从项目里导出真实的SQL建表语句，或者把数据库管理工具里的表结构复制出来，再让AI按软著材料的写法整理。提示词可以很具体：请根据以下MySQL建表语句，生成数据库设计说明，保留真实表名和字段名，补充字段含义、类型、长度、是否为空、主键、默认值和表说明；不要虚构不存在的字段；文档语言使用中文；每张表用一段文字说明用途，再列出字段表。
这样做的好处是，AI生成出来的内容至少和代码同源。软著材料里最忌讳的就是文档一套、源码一套。审查老师翻到源代码时，如果看到的类名、Mapper里的表名和设计文档完全不搭，材料可信度就会下降。
AI最容易编过头，尤其是外键和索引
我改过几份AI文档，发现它特别喜欢“补全”。明明项目没有设置物理外键，它会自作主张加上FOREIGN KEY；明明表里只有主键索引，它能写出uk_user_mobile、idx_order_status等一堆索引；有些逻辑删除字段根本不存在，它也会加个del_flag。
这对专业开发来说可能一眼就能看出来，但很多申报软著的人并不是全职后端，或者项目是外包、课程设计、历史系统二开，他们很容易被AI那套规范写法带跑。我的建议是，凡是涉及约束、索引、关联关系的内容，都要回到SQL或实体类里核对。文档可以写逻辑关联，比如“订单表的user_id对应用户表主键”，但不要轻易写数据库建立了外键约束，除非你真的有。
字段类型也要小心。AI经常把tinyint写成int，把varchar(32)写成varchar(255)，把decimal(10,2)写成double。金额字段尤其不能含糊。我一般会要求AI保留原DDL中的类型和长度，然后人工抽查核心表：用户表、订单表、支付表、权限表、业务主表。这些表在源代码里出现频率高，也最容易被比对到。
软著文档不是技术博客，说明重点要落在“设计”上
数据库设计文档放到软著材料里，不只是把字段罗列出来。它要能说明这个软件的数据是怎么组织的，各模块之间怎么流转。很多AI初稿的问题，是看起来很规范，却没有项目自己的业务味道。
比如一个设备巡检系统，不能只写“创建时间、更新时间、备注”。你得把巡检计划、巡检路线、巡检点位、异常上报、整改记录这些表之间的关系讲清楚。计划按周期生成任务，任务包含多个点位，点位提交检查结果，异常再生成整改单。这样的描述能和软件功能说明、操作界面截图对应起来，材料才像一个完整系统。
我通常会让AI先整理三张内容：数据库环境说明、表结构汇总、核心表字段明细。然后自己补一段设计约定，例如主键统一使用bigint自增，状态字段使用tinyint编码，时间字段统一为datetime，逻辑删除使用delete_status。注意，这些约定必须是项目里真实采用的，不是为了好看硬写。
如果系统模块比较多，还可以按业务域分组。拿常见系统来说，可以分为用户权限域、业务管理域、流程审批域、系统日志域。不要一口气把几十张表按字母顺序排完，阅读体验很差，也不利于体现模块划分。软著文档虽然偏正式，但本质上还是给人看的。
提示词里要限制篇幅，不然AI会疯狂注水
刚开始用AI写文档时，我拿到过一份三十多页的结果，里面每个字段都写一大段“该字段用于存储……具有重要意义”。这种内容很虚，打印出来厚厚一本，有效信息却不多。字段说明最好控制在一句话内，能准确表达含义就行。比如order_status，就写“订单状态：0待支付，1已支付，2已取消，3已退款”，比写三段废话有用。
状态枚举值要尽量从代码常量类里找。AI可能会按常识给出一套状态码，但项目里未必相同。比如有的系统0表示正常，1表示禁用；有的系统反过来。这个地方如果不核对，文档和代码马上冲突。类似的字段还有类型、来源、优先级、审核状态，都属于容易踩坑的点。
表注释也不要只改个名字就完事。我会检查三张东西：表名是否真实存在，字段是否和SQL一致，枚举说明是否和代码一致。只要这三张过了，AI初稿的可信度就会高很多。至于排版，可以交给它处理，比如统一表头、统一标点、统一“是否为空”的写法。
截图、源码和文档之间，最好能互相印证
软著申报材料不是单一文档决定成败。很多人只盯着数据库设计文档，却忽略了前后一致性。比如功能说明里写系统支持优惠券核销，数据库里最好有优惠券表、用户领券记录表或核销字段；说明书截图里有“部门树”，数据库里也应体现部门表的parent_id层级关系。反过来，如果文档里写了很复杂的库存锁定、支付对账、消息通知表，但源代码和操作说明里完全没有，就会显得突兀。
我整理材料时，会先列一个系统模块清单，再对应到表。比如：登录注册对应用户表、角色表、菜单表；订单管理对应订单主表、订单明细表；内容管理对应栏目表、文章表、附件表。AI可以根据这个对应关系补写表用途，但模块清单最好由人来定，因为这是你最了解系统业务的部分。
还有一个小细节，软著材料里的命名风格要统一。项目实际使用snake_case，就全部按snake_case写；实体类是驼峰，数据库字段是下划线，也可以在设计约定里说明。不要一会儿userName，一会儿user_name，一会儿又来个“用户名”。这种问题AI初稿里特别常见，尤其是你同时喂了Java实体类和SQL文件时，它会混着来。
我现在常用的一套整理流程
一般拿到项目后，我会先导出建表SQL，顺手删掉和本系统无关的临时表、测试表。接着把SQL按模块分段给AI，避免一次塞太多导致漏表。让它输出HTML或Word能承接的表格格式，每张表包括字段名、类型、是否为空、键、默认值、说明。生成后，我用表清单对照数据库实际表数，再抽查核心字段和枚举。最后补上数据库概述、命名约定、模块关系以及表间关系说明。
如果项目本身表很少，比如只有十几张，就没必要让AI硬扩成大系统。软著材料并不是表越多越好，关键是能支撑软件功能。小系统就老老实实写小系统，把角色、业务单据、附件、日志这些必要内容讲清楚，比虚构一堆高级表更稳。
材料格式方面，我也建议在最终提交前统一转成PDF，表格列宽、分页标题、中文字体都检查一遍。AI生成的表格有时字段说明列特别窄，类型列特别宽，打印出来很难看。别小看这些细节，材料整理得清爽，至少阅读的人能快速看明白。
如果你平时不太熟软著材料的格式，又想省点排版时间，也可以试试 软著Pro，里面有些材料整理和生成功能比较适合边核对边完善。我的习惯仍然是：工具负责起草和排版，事实依据必须来自真实项目。
最后留个判断标准
一份能用于软著申报的数据库设计文档，不是看它写得多高级，而是看它能不能被验证。表名能在SQL里找到，字段能在代码里对应上，状态值能在常量或业务逻辑里查到，表关系能和功能说明互相支撑。满足这几点，AI生成并不可怕；不满足这几点，就算文档写得再厚，也只是一份漂亮的空架子。
所以我现在并不排斥AI，相反，它确实能把大量重复的字段搬运和排版工作省下来。但数据库设计文档牵涉到系统事实，不能一键生成后直接提交。花半小时核对核心表、枚举、索引和业务关系，往往比反复调整封面格式更重要。
