上个月帮开工作室的朋友处理软著申报的驳回申诉，他就是图省事，直接把GPT生成的2000多行小程序代码原封不动整理成清单交上去，结果等了半个月收到驳回通知，理由是代码重复率过高，还有明显的AI生成特征，连注释里都残留着“你可以根据实际需求修改以下参数”这种AI回复的原话。我之前前后帮公司和朋友处理过30多份软著申报材料，最近两年用AI生成代码来凑清单的情况越来越多，踩的坑多了也摸出了一套稳过的方法。
先给大家吃个定心丸，不是用AI生成的代码就不能申报软著，审核端现在卡的不是“你有没有用AI写代码”，而是你有没有在AI生成内容的基础上做符合自身业务的创造性调整，能不能证明这份代码对应的是你自己的软件产品，不是随便抄的公开代码。
拿到AI生成的代码之后，第一步先做冗余内容清理。大部分人给AI的需求都不会太细，比如你说“给我写个健身APP的用户打卡接口代码”，AI给你返回的内容里，大概率会有不少和你实际业务无关的内容，比如它会默认导入很多你用不上的依赖包，会加很多泛泛而谈的注释，甚至会给你附一段使用说明，还有可能会把它训练数据里带的其他项目的残留代码混进去。这些内容你都要全部删掉，尤其是注释里的通用描述，比如“以下是用户登录功能的实现”这种，一点用都没有，反而会增加重复率。整理格式的时候可以参考软著申报代码清单规范的要求，每页控制在50行左右，不要太挤也不要太松，行号要连续，不要出现断号或者跳号的情况。
清理完冗余内容之后，就要做个性化改造，这一步是降低重复率的核心。AI生成的代码变量名、函数名基本都是通用款，比如用户变量就叫user，登录函数就叫login，这种内容放在公开的代码库里一搜一大把，重复率自然高。你要做的就是把这些通用命名改成和你项目强绑定的，比如你做的是社区养老服务平台，就把user改成elder_user，把login改成community_elder_login，就连参数名也可以稍微改改，比如把通用的page_size改成elder_info_page_size，不用改逻辑，就是换个名字的事，重复率一下就能降下来。还有注释也要全部换成你自己的话，不用写得多么正式，就写你开发时候的真实想法就行，比如“这里加个年龄判断，之前有老人填出生日期填成今天，提交之后会报错，所以加个校验”，这种明显是实际开发过程中才会有的备注，审核人员看到自然会觉得这份代码是你自己做的，不是随便抄的。
我之前踩过最大的坑，就是为了凑够要求的代码行数，让AI生成一堆没用的重复代码，比如把同一个查询函数复制三四遍改个名字就放进去，结果那次申报直接被打回，还被标记了“内容不实”，之后再提交同主体的软著，审核速度都比之前慢了很多。其实现在软著对代码行数的要求没有那么死，只要核心功能的代码是完整的，前后逻辑能对得上，哪怕少个一两百行也没关系，真的没必要凑数。如果你不确定自己改完的代码能不能过，可以先用软著Pro查一下重复率和AI生成痕迹，这个工具是之前同行业的申报专员推荐给我的，比我之前自己网上找的重复率检测工具准很多，检测结果和审核端的标准基本对齐，改完测一遍没问题再提交，省得等大半个月被打回耽误事。
改完内容之后，还要注意代码前后的关联性，比如你前面写的是用户模块的代码，后面突然冒出来一段商品支付的代码，中间连个过渡说明都没有，审核人员一看就知道你是随便拼的。最好在每个功能模块的代码前面加一行简单的说明，比如“以下为社区养老平台老人信息录入模块核心代码”，不用太长，说清楚对应的功能就行。如果你的代码里用到了开源框架的部分内容，一定要在申报材料的备注里说明，不要隐瞒，现在审核对合理使用开源代码的容忍度很高，只要你核心的业务逻辑是自己写的就没问题。
上个月帮一个做跨境电商独立站的客户处理软著申报，他的前端页面代码90%都是AI生成的，我帮他把所有通用变量名换成了和他的独立站业务相关的命名，把注释全部换成了他自己运营过程中遇到的问题对应的修改说明，删掉了AI生成的冗余测试代码，又按照规范调整了格式，提交之后只用了8天就拿到了登记证书，比他之前自己提交被打回耽误的时间少了整整一个月。如果不知道怎么调整代码结构的话，可以去代码清单调整教程里看一下具体的示例，照着改就行，不用自己瞎琢磨浪费时间。
其实现在用AI生成代码来做软著申报是很常见的事，不用觉得好像作弊了一样，只要你按照要求做了对应的调整，符合你自己的业务需求，基本都能过审。最忌讳的就是直接原封不动把AI生成的内容交上去，既浪费时间，又容易留下不好的申报记录。