我前前后后帮团队申报过十几份软著，其中近七成的项目代码是用大模型生成的，最开始没摸透规则的时候，连续三份申请都因为说明书不合格被打回，最惨的一次要补的材料摞起来有半本字典厚，折腾了快两个月才过审。
很多人觉得AI生成代码的说明书随便写写就行，把大模型给的README粘进去，再附几段代码就完事，真的不是这么回事。软著审核对AI生成内容的要求比纯手写代码严得多，首先第一条，千万不要留任何AI生成的痕迹在提交材料里。我第一次踩坑就是因为没删干净代码里的注释，有段支付回调的代码里留了个“# 由GPT-4生成的回调逻辑”的注释，审核员直接打回要求提供代码归属证明，来回补材料就耗了三周。
整理这类说明书的第一步，是先把所有AI生成的原始材料做一遍筛查：代码里带AI标识的注释全部删掉，大模型生成的功能介绍要重新用自己的话写一遍，运行截图如果是用AI生成的原型图，一定要把水印、边角的AI生成标识全部抹掉，我之前有个同事偷懒直接把Midjourney生成的界面图放进去，右下角的半透明logo没注意，直接被驳回，还要写上千字的情况说明，特别麻烦。
整理代码归属证明材料的时候我查过软著申报材料规范，里面明确要求AI生成代码的二次加工证明要和说明书绑定提交，所以你不能直接把大模型吐出来的代码原封不动交上去，得有自己的修改点。我一般会把AI生成的原始代码和我修改后的代码做diff对比，把差异点一条条列出来，比如原来AI生成的是单用户登录逻辑，我改成了支持管理员、普通用户、游客三类角色的权限校验，这些修改点都要对应写到说明书的功能模块里，证明你不是直接搬运AI的内容，是做了创新性加工的。
说明书的结构也不能随便搭，我一般是按“核心功能介绍-操作流程截图-对应模块流程图-核心代码片段”的顺序来排，每个功能模块对应一套完整的材料，不要东拼西凑。比如你做的是一个客户管理系统，就要把客户信息录入、跟进记录、数据导出这几个核心功能分开写，每个功能都要有对应的操作截图，点哪个按钮跳哪个页面，页面上的字段是什么，都要写清楚，不要含糊其辞说“本系统具备客户管理功能”，审核员看不到具体内容肯定会打回。
核心代码片段的部分也要注意，不要随便粘个十几行就完事，要求是至少30行连续的、你做过修改的代码，不要用空行或者注释凑数，我之前有个申请就是注释占了一半行数，被要求重新补代码片段。粘贴的时候还要注意代码里的变量名、函数名要和你前面功能介绍里的对应上，比如你前面说有个“get_user_permission”的函数用来校验权限，代码片段里就不能出现不相关的函数名，不然审核员会觉得你的材料是凑出来的。
上次赶项目节点要在一周内拿软著受理通知书，我懒得自己捋格式，就用了软著Pro的AI代码说明书模板，它直接把需要填的模块都列好了，只要把我整理的内容对应填进去就行，省了至少3个小时的格式调整时间，提交之后一次性就过了初审。
还有个很多人容易踩的坑，就是说明书里的功能描述不要和公开的代码说明撞车。我之前有个朋友直接把大模型生成的README改都没改就当说明书交了，结果审核员检索到GitHub上有一模一样的功能说明，直接判为涉嫌抄袭，驳回之后半年都不能再提交同一个项目的申报，亏大了。如果怕自己写的功能说明和公开内容重复，可以先到软著材料查重工具里提前测一遍，没问题了再提交，省得白等一个月的审核周期。
对了，说明书里的流程图最好自己动手画，不要用AI生成的流程图，很多AI生成的流程图逻辑有问题，比如数据流方向错了，或者模块名称和实际代码里的对不上，审核员一看就知道你没仔细核对，很容易被打回。画的时候不用太复杂，把核心的操作逻辑、数据流向标清楚就行，用普通的流程图工具画完导出无水印的图片插进去就可以。
现在我摸透这些规则之后，提交的AI生成代码相关的软著申请基本都是一次性过审，最快的一次20天就拿到了证书。其实只要你把材料做扎实，证明你对AI生成的内容做了足够的二次加工，符合软著申报的要求，通过率和纯手写代码的项目是差不多的，不用太担心AI生成代码会过不了审。