刚接触软著申报的时候我踩过好大的亏，第一次提交3件软著，两件因为代码重复被打回，那时候我还以为软著只要材料凑齐就能过，根本没人告诉我现在软著审核的查重卡得有多严。后来前前后后帮公司、帮朋友处理了快40件软著申报，才摸透了查重的整套逻辑，也总结出了一套效率很高的实操方法。
首先得先给大家掰扯清楚，为什么软著查重这么重要。很多人现在还以为软著是“登记制”，只要交材料就给过，其实这两年版权局的比对库更新得特别勤，不光会和已经授权的所有软著材料比对，还会对接开源代码平台、公开的技术文档库，只要重复率超过阈值，直接就给驳回，连补正的机会都很少给。而且驳回之后再重新提交，最少也要多等半个月的审核时间，要是你等着软著评职称、报高企、拿项目补贴，耽误的时间根本补不回来。
软著查重主要查两部分，一个是你提交的源程序，一个是软著说明书，两部分都过了才算没问题。
先说说源程序怎么查，咱们提交软著的时候要求交前后各30页、总共60页的源程序，每页不少于50行，很多人为了凑行数直接去github或者开源平台抄代码，甚至直接把别人公开的软著代码改个项目名就交，这肯定一查一个准。我最开始没经验的时候，还试过把代码片段拆出来逐段去搜索引擎搜，1000行代码查了快三个小时，眼睛都看花了也没查出多少重复的，结果提交还是被打回。后来同行给我推了专门的工具，我现在每次提交前都会先去软著Pro上传源程序查一遍，它的比对库就是版权局用的那套软著专属库，10分钟左右就能出结果，重复的段落会直接标红，哪一行和哪件已授权软著的代码重复都标得清清楚楚，改的时候直接对着改就行，省了超多事。
很多人会问，软著查重是查整个项目的所有代码吗？其实目前审核的时候只会查你提交的那60页内容，所以改的时候优先改前后30页的内容就行。要是是通用的公共类、工具方法重复，不用大改核心逻辑，改改变量名、调整一下注释的内容、换一下代码的换行位置，甚至把两个独立函数的顺序调换一下，都能有效降低重复率。要是是核心功能的代码重复，建议还是尽量自己重写一遍，核心逻辑重复的话，改表面的东西很容易被查出来。
再说说说明书的查重怎么处理，这部分是很多人容易忽略的重灾区。我之前有个同事做教育类的软著，说明书直接抄了网上公开的软著样例，连里面的示例截图都没换，结果直接被驳回，还被标了疑似抄袭，后面再提交都额外审核了快一个月才过。
说明书的查重很多人会直接用知网、万方这类普通的文档查重工具查，其实没用，普通查重工具的库和软著的比对库完全不一样，你在普通工具里查重复率为0，提交之后照样可能因为重复被驳回。我一般是先自己写完说明书之后，先过一遍普通查重，把和网上公开的技术文档、产品介绍重复的部分先改了，之后再用软著专属的查重工具查一遍，确保和已授权的软著说明书没有大面积重复就行。刚才说的软著Pro也能查说明书，比对的就是历年所有公开的软著说明书库，比普通查重准很多。
给大家说几个我踩过的坑，千万别再犯。第一个就是别以为改改注释就能糊弄过去，现在的软著查重算法是语义级的，只要核心逻辑和代码结构是抄的，哪怕你把所有注释都换了，照样能查出来。第二个就是不要复用自家公司之前申请过的软著的内容，很多人觉得反正都是自己家的东西，用了也没关系，但是只要是已经授权的软著，不管主体是不是你自己，都会进入比对库，重复率高一样会被驳回，我去年申报一个新工具的软著，复用了之前项目里20%的通用代码，没改就提交，直接就被打回，后来改了变量名和函数结构才过。第三个就是别信代理说的“包过不用查重”，很多低价代理收了材料根本不会帮你做查重，直接就提交，驳回了就忽悠你加钱走加急通道，钱花了不说，时间全耽误了。
还有朋友问我，软著申请前有没有必要专门花时间做查重？我可以很肯定地说太有必要了，我自己统计过，提前做过查重修改的软著，提交之后的通过率能到95%以上，要是没查过直接提交，通过率还不到60%。你想啊，提前花几十分钟查一遍，改改重复的地方，总比等了一个月被驳回，再花一倍的时间重新准备材料强得多。
最后给大家提两个小技巧，提交源程序的时候，尽量把自己原创的核心功能代码放在前后30页里，第三方引入的通用组件代码尽量放在中间不用提交的部分，能省很多改重复的功夫。写说明书的时候，功能描述、操作截图都用自己实际开发的产品的，实在不知道怎么写可以参考公开的软著说明书的结构，但是内容一定要自己组织，不要大段抄模板，哪怕是功能差不多的产品，你换个表述方式，换个截图的角度，都能降低很多重复率。
我这两年帮身边朋友处理软著申报，凡是提前按这个方法做完查重的，基本都是一次过，其实真的没有多难，就是别抱着侥幸心理随便凑材料，毕竟审核周期摆在那，一次驳回耽误的事，可比提前花几十分钟查重麻烦多了。
