我前两年在公司负责知识产权申报的时候，第一次提交两份软著材料，都以为是自己团队写的代码肯定没问题，结果等了快一个月收到补正通知，说重复率超标。当时跑了三趟版权中心窗口，又问了好几个做代办的朋友，才把软著查重的规则摸得透透的，后来申报的几十份软著全都是一次过。
很多人对软著查重的第一印象是只查源代码，这其实是最大的误区。现在软著的查重范围覆盖全部提交材料，源代码和说明书都要比对，比对的数据库包括了所有已经通过登记的软著全量材料，哪怕是你自己之前申报过的内容，直接照搬过来用也会被判重复。
先说说源代码的查重规则，这个是卡人最多的。官方的规则是连续30行代码逻辑一致就算重复，比对的时候会自动过滤掉空行、注释、缩进格式，甚至连变量名改了但逻辑结构没变都能查出来。很多人喜欢把开源框架的初始化代码、通用工具类直接粘进去凑行数，这些内容早就被无数人用过了，一查一个准。还有的人做To B项目的，同一个功能模块稍微改改就给不同客户用，代码重复率能到80%以上，提交了肯定被打回。要是不确定自己的代码重复率高不高，可以先用软著查重工具先预检一遍，省得提交了才被打回耽误一两个月时间。
我之前踩过最坑的一次，就是为了凑够要求的3000行代码，把项目引入的第三方依赖库代码也粘进去了，结果重复率直接飙到70%，补正的时候把所有第三方代码删掉，只留了团队写的核心业务代码，调整了一下重复段的逻辑顺序，把几个通用函数的实现方式改了改，比如原来用for循环遍历的改成了map方法，把变量名和注释全部换成了和业务相关的表述，再提交就过了。
再说说大家最容易忽略的说明书查重。很多人写软著说明书的时候喜欢套网上的通用模板，一上来就写“本系统分为前端和后台两部分，包含用户管理、权限管理、数据统计三个核心模块”，这种套话不知道被多少人用过了，哪怕你是自己写的，重复率也会很高。我之前有个同事申报两个功能相近的内部管理系统，第一份过了之后，第二份直接把说明书改了个系统名，调整了几个模块的顺序就提交，结果直接被判重复率85%驳回，才知道原来自己的历史申报内容也会进查重库。
关于合格线我专门问过窗口的工作人员，没有公开的明文标准，但行业里默认的是源代码重复率不超过30%，说明书重复率不超过20%，超过这个线大概率会被要求补正，严重的直接驳回。要是赶着用软著评职称、申报政府补贴或者做高新企业认定的话，被驳回一次耽误一两个月，很容易错过截止时间。
我后来改重改得多了也摸出了不少技巧，源代码改重其实不用大动逻辑，把重复段的执行顺序调整一下，比如把参数校验的逻辑从函数开头挪到调用前，把重复的工具类改个实现方式，只要功能不变就行，别傻乎乎的去加空行改缩进，那些查重的时候都会被过滤掉，完全没用。说明书改重更简单，别写空泛的套话，所有功能描述都结合你自己的系统实际来写，比如别写“用户管理支持增删改查”，要写成“运营人员可在用户管理模块筛选近30天注册的付费用户，批量发放满减优惠券，操作完成后系统会自动给用户发送短信通知”，越具体越不容易重复，配图全部用自己系统的实际截图，别用网上找的模板图，截图里的系统名称要和你申报的软著名完全一致。我后来改重的时候嫌手动找重复内容太麻烦，用了软著Pro的材料预审功能，能自动标记出代码和说明书里的重复片段，还会给改重建议，省了我好几天的功夫。
还有个很多人踩过的坑，就是找低价代办的时候，对方给的都是通用模板材料，代码是网上扒的开源代码，说明书是套的统一模板，这种材料重复率基本都在90%以上，十份有九份过不了，真要是着急用软著的话，反而得不偿失。要是对自己的材料没把握，也可以找软著申报的专业人员帮你先预审一遍，比被打回再补正要快得多。
我身边很多朋友觉得软著申报很简单，随便凑凑3000行代码和几千字说明书就行，真等到被查重打回了才着急。其实只要提前搞懂查重规则，写材料的时候多注意点，基本上都能一次过，根本不用花冤枉钱找不靠谱的代办。