去年帮公司做项目资质申报，前前后后要报8个软著，头3份提交上去都卡在了查重环节，驳回通知下来的时候我整个人都懵了——代码全是我们开发组一行行敲的，怎么就重复了？后来跑了好几次版权中心的咨询窗口，跟代办的老法师也讨教了不少，才把软著查重的规则摸得门清，后面提交的5份全是一次过审，最近一年帮朋友过的软著也有20多份，没一个卡在查重上的。
别搞错，软著查重可不是只查代码
很多第一次做软著申请的朋友压根不知道还有查重这回事，上来就把导出的全量代码和随便凑的说明书交上去，等个十几天收到驳回通知才慌神。我最开始踩的第一个坑就是以为只有代码会查重复，后来才知道官方的查重是两个维度同时走，代码和说明书只要有一个触碰到重复阈值，都会直接打回。
而且这个查重的比对库可不只是已经下证的软著库，同期提交的所有申请材料都会纳入比对范围，我之前就遇到过同园区的两家公司做同类型的 SaaS 工具，差不多时间提交的申请，说明书的功能模块结构撞了，两个都被要求补材料说明权属，折腾了快俩月才下来证。
源代码查重的核心规则我摸得透透的
很多人说源代码查重是连续30行相同就算重复，其实这个说法不全对，官方的比对逻辑是看代码片段的核心逻辑、变量命名习惯、功能模块的排布组合，哪怕你把每行的换行改了，甚至把变量名批量替换成拼音，只要逻辑块的排布和已有库里面的内容重合度太高，照样会触发预警。
我之前第二个被驳回的软著，就是把uniapp框架自带的初始化代码全贴进去了，那段代码几乎所有做小程序开发的人项目里都有，我当时图省事没删掉，直接就撞了大几十份已有的软著，重复率直接飙到40%。后来才知道，提交的代码只需要放你自己写的核心业务逻辑就行，第三方框架、开源依赖的代码完全可以删掉不用提交，省得平白增加重复概率。
还有很多人喜欢从开源项目里扒一段功能代码改改就用，要是没改透也很容易中招，我上次帮朋友改一份重复的代码，他扒了GitHub上一个开源项目的支付模块，只改了几个参数名，注释都没换，查出来重复率60%，后来我让他把变量名全改成符合自己项目命名规则的，注释全部重写，逻辑顺序也调整了下，比如把原来的先校验参数再生成订单，改成先生成临时订单再校验参数，改完之后重复率直接降到8%，提交之后一周就过了。对了，大家改完之后最好先自己查一遍重复率，我平时都是用软著Pro先预检，代码和说明书都能查，跟官方的比对规则差不离，省得提交之后等半个月才知道有问题。
最容易被忽略的说明书查重坑
我身边至少有一半人栽在说明书查重上，这个部分的查重要比代码严得多，是做语义比对的，不是说你把别人的说明书拿过来改个产品名、换几个同义词就能蒙混过关的。我之前帮同行救过一个急，他的软著被驳回是因为说明书里的功能描述和某大厂下证的同类型产品重复率70%，他说自己确实是照着人家的说明书改的，以为换个说法就行，结果哪怕句子结构都改了，功能模块的介绍顺序、每个功能的描述逻辑都差不多，还是被查出来了。
还有的人自己之前申请过V1版本的软著，申请V2版本的时候直接把旧的说明书拿过来改了个版本号就提交，照样会被驳回，因为你自己的旧材料也在比对库里，新版本的说明书至少要有30%以上的新增内容，还要明确标出来和旧版本的差异点，才不会被判重复。
我亲测有效的避坑实操技巧
这两年整理下来，我自己有一套固定的操作流程，基本上能把重复率压到10%以下，提交了几十份都没出过问题。首先是代码部分，提交的60页源码（不够的话可以多打点空行，但是不要凑无关代码）只放自己写的业务逻辑，第三方框架、开源工具的代码全部删掉，所有注释都自己写，不要用自动生成的或者开源代码里自带的注释，变量名尽量用自己团队的命名习惯，不要直接抄网上的demo里的命名。
然后是说明书部分，不要去搜别人已经下证的说明书当模板，自己按照产品的实际情况写，先写产品背景、再写核心功能、再写使用流程，每个功能的描述要结合自己产品的实际界面来写，最好配上自己产品的截图，不要用网上找的通用示意图。如果是迭代版本的软著，一定要单独加一个板块写清楚和上一个版本的差异，新增了什么功能，优化了什么逻辑，写得越清楚，越不容易被判重复。
哦对了，还有个很多人不知道的坑，就是不要找那种收费特别低的代办，我之前有个朋友找了个99块钱代报软著的，结果提交之后被驳回，查了才知道那个代办用的是通用模板代码，同一批报了几十个都是差不多的代码，他的和另外三个人的重复率超过80%，直接被版权中心列入了异常名录，半年之内都不能提交新的软著申请，亏大了。
我这两个月帮公司报的5个新版本的软著，都是自己整理的材料，整理完先用软著查重工具过了一遍，重复率都在10%以下，提交之后7个工作日就下证了，比最开始踩坑的时候省了不知道多少时间。其实只要摸清楚规则，不要偷懒，软著查重根本不是什么难事，也没必要花冤枉钱找不靠谱的代办。
