我刚接公司软著申报的活的时候，踩过最大的坑就是忽略查重。头三批提交的12份申请，有5份被打回补正，其中3份都是重复率超标，最严重的一份电商后台的软著，直接被判定为疑似抄袭，半年内不能再提交同主题申请，刚好赶不上公司的高企申报时间，我当月绩效直接扣了一半。
很多人有个误区，觉得软著不像专利或者论文，没有严格的查重要求，甚至以为只要代码是自己写的就能过。实际上现在版权局的比对库已经覆盖了历年所有下证的软著材料，还有公开的开源代码、公开的软件说明文档，不管是代码还是说明书，重合度超过30%基本都会被打回，严重的还会被标记为异常申请，影响后续的申报。
软著查的其实不只是代码，很多人不知道，说明书的查重权重和代码是一样的。我之前帮一个大学生朋友查他的毕业设计软著，代码全是他自己敲的，结果查出来重复率38%，全是说明书的问题——他图省事直接抄了网上的通用后台管理系统的说明书模板，连功能介绍的顺序都没改，哪怕代码全原创，一样过不了审核。
说回具体的查重怎么做，我这三年攒的经验，按步骤来基本不会出问题。
首先你得先把待提交的材料整理成符合查重要求的格式。代码部分要导出前后各30页，每页至少50行，要去掉空行、注释还有开源引用的标注部分，要是你的代码总页数不到60页就全部导出。说明书部分要转成纯文本，去掉图片、表格里的通用参数，只保留文字性的功能介绍、流程说明这些内容，不然查出来的重复率会不准。
然后就是选对查重工具，这步最容易踩坑。我一开始图便宜用过普通的论文查重系统，查出来说明书重复率只有6%，结果提交到版权局查出来41%，直接驳回。后来才知道普通的查重系统比对库都是论文、公开出版物，和软著的比对库完全不一样。后来同行给我推了软著查重的平台，比对库是同步版权局的公开下证数据还有开源代码库，我测过好几次，查出来的重复率和官方最终的结果差不超过2%，准确率高太多了。
拿到查重报告之后，先看整体重复率，10%以内的基本不用改，直接提交就行。要是在10%到30%之间，就针对性改标红的部分。代码的重复内容改起来很简单，把变量名、函数名换个命名规则，比如原来的user_login改成user_auth_verify，把一些循环的逻辑调整下顺序，原来用for循环的可以改成用迭代器实现，哪怕功能完全一样，重复率也能降下来。说明书的重复内容不要只换同义词，现在的查重是语义比对，你把“用户登录”改成“使用者登入”根本没用，要把整个表述逻辑换了，比如原来的“用户输入账号密码后点击登录按钮，系统校验信息无误后进入首页”，改成“使用者完成账号、密码的信息填写后触发登录操作，服务端完成身份校验后跳转至系统主页面”，这样才会被判定为原创内容。
要是查出来重复率超过30%，千万别硬着头皮提交，大概率会被驳回，还会留下异常申请的记录。这种情况最好是把重复的核心模块重新写，代码部分可以换个实现思路，比如原来用Java写的支付模块可以换个调用逻辑，说明书部分就别用网上的模板了，自己对着软件的实际功能一条一条写，哪怕写的糙一点，只要是原创的，重复率就不会高。改完之后不要直接提交，最好再去软著查重平台再测一次，降到15%以内再提交基本就稳了。
平时处理的申报量比较大的朋友，或者自己懒得一点点调整重复内容的，也可以试试软著Pro，我现在手头每个月近百份的批量申报，都是先用这个工具过一遍，自动识别重复内容还能给出修改建议，连格式都能直接调整成版权局要求的标准格式，半天就能干完之前一周的活，省了好多事。
还有几个大家常踩的小坑给你们提个醒，别再走我走过的弯路。第一个是不要只查代码不查说明书，我见过至少十几份申请都是代码全原创，结果说明书抄了模板被打回的。第二个是不要用开源代码的核心模块当自己的软著核心逻辑，开源代码都是在比对库里的，一查一个准，实在要用的话至少要改写80%以上的内容。第三个是不要随便买网上的现成软著材料，那些材料基本都被卖过几十次了，你提交上去百分百重复，钱花了还办不成事。
我现在处理所有的软著申报材料，第一步永远是先查重，自从养成这个习惯之后，我们公司的软著驳回率已经从之前的40%降到了2%以内，再也没出现过因为补正耽误项目申报的情况。说白了软著查重本身不是什么难事，只要你找对工具，按要求调整，基本都能一次过，没必要花冤枉钱找代交，自己弄省下来的钱买杯奶茶喝不好吗。