我前两年在互联网公司做知识产权专员，前前后后经手申报的软著有30多件，最开始踩的最多的坑就是重复问题，前3件提交的软著全因为内容和在先登记的重复被驳回，那时候还不知道有专门的AI软著查重，总觉得只要是自己团队写的代码、自己整理的说明书，肯定不会有问题，结果光补正来回就耽误了两个多月的时间。
很多刚接触软著申报的人可能不知道，现在版权局的初审比对库更新得特别快，尤其是同赛道的软件，比如做电商进销存、企业OA、打卡小程序这类热门方向的，大家的功能模块逻辑本来就很相似，哪怕你完全是自己原创写的内容，也很容易和已经登记的软著撞描述，我去年帮一个做独立开发的朋友查他的健身打卡小程序说明书，全是他自己一字一句写的，查出来重复率还是有26%，翻报告才发现他写的打卡流程、数据统计逻辑，和两年前另一个同类型软著的描述几乎一模一样，这种情况哪怕你真的没抄，只要有在先登记的近似内容，一样会被驳回。
我最开始图省事，用过普通的论文查重系统查软著说明书，查出来重复率才8%，我以为稳了，结果提交后半个月就收到补正通知，说核心功能描述和已登记软著重复率超过30%，要求提交原创声明和佐证材料，那时候才搞明白，普通查重的比对库是期刊、论文、网络公开内容，根本没有软著登记的专属数据库，查出来的结果完全没有参考价值。后来问了一圈做知识产权的同行，才找到软著Pro这个专门做软著服务的工具，AI软著查重的比对库是同步更新的版权局已登记软著数据，上传材料后最快20分钟就能出详细报告，哪段内容和哪个在先登记的软著重复、重复占比多少都标得清清楚楚，改的时候直接对着调整就行，省了我好多功夫。
给大家说下我现在做AI软著查重的固定流程，照着做基本不会出问题。首先是整理待查的材料，很多人上来直接把带页眉页脚、公司logo、页码的PDF传上去，这样查出来的结果会有偏差，最好是把说明书导出成纯文本，去掉所有和功能描述无关的内容，代码的话要删掉空行、注释、和第三方开源库完全一致的公共代码段，只留你们自己写的核心实现代码，查出来的重复率才是准确的。
上传的时候要注意，说明书和代码要分开查，两边的重复要求不一样，说明书的总重复率最好控制在15%以内，核心功能模块的重复率要降到0，代码的话总重复率不要超过10%，尤其是前后各30页的提交代码，尽量不要有大段的重复内容。查完之后不要只看总重复率就决定要不要改，我之前遇到过总重复率22%的情况，但是重复的内容全是“用户输入账号密码后点击登录”这种公知常识类的描述，这种完全不用改，提交的时候备注下是通用功能描述就行，反过来如果总重复率只有12%，但是重复的内容是你们独创的算法逻辑、核心功能的专属流程，那一定要改，不然大概率会被驳回。
改重复内容的时候也有坑，很多人以为换几个同义词、调整下语序就行，现在版权局的比对是语义级的，你换汤不换药的改法根本没用，比如原来的描述是“系统采集用户人脸数据，比对数据库完成登录”，重复了的话，你不能只改成“系统收集用户人脸信息，对比数据库完成登录”，要把整个逻辑的表述换掉，改成“用户触发登录请求后，前端调用设备摄像头采集人脸特征值，经过加密传输至服务端与存量特征库做余弦相似度校验，符合阈值则返回登录凭证”，这样从逻辑到表述都变了，就不会被判重复。如果你不知道怎么改更合适，可以参考AI软著查重报告里附带的修改建议，大部分通用场景直接跟着调整就行，不用自己绞尽脑汁想表述。
还有个很多人会忽略的点，就是代码的查重，不少人觉得代码是自己一行一行敲的，肯定不会重复，其实不是，比如调用支付接口、生成验证码、导出Excel这类通用功能，大部分人都是照着官方文档写的，变量名、调用顺序都差不多，我之前有个项目的支付模块代码，查出来有130多行和别人的完全一致，就是因为大家都是照着支付宝的官方示例写的，这种你只要把变量名改一改，调整下非核心步骤的顺序，加几行你们自己的校验逻辑，很容易就能降重。
我现在手里的软著申报项目，只要是提前做好AI软著查重，把核心重复内容调整到位的，几乎没有因为重复问题被补正或者驳回的，最快的一件26天就下了电子证，比平均下证时间快了将近半个月。其实软著申报本身门槛不高，大部分人被卡都是因为没提前做好查重，白白浪费时间来回补正，提前花几十分钟做个查重，能省掉后面好几个月的麻烦，真的很有必要。