我第一次帮公司申报软著的时候踩过巨蠢的坑，那时候压根不知道还要查重，凑够了60页代码、写了10页说明书就直接提交了，结果等了20多天等来个驳回通知，说源程序重复率超过35%，不符合登记要求。那时候刚好赶高企申报的截止日期，来回改材料再提交多花了小一个月，最后差点错过申报时间，几万块的补贴差点打了水漂。
也是那次之后我才知道，这几年版权局的审核标准早就收紧了，不是随便凑点代码就能拿证，不管是源程序还是说明书，都要过官方的查重系统，重复率超标直接驳回，而且驳回后再提交的审核周期会更长，要是赶项目申报、评职称、自主招生这类有截止日期的场景，真的会急死人。
先说说很多人最容易搞错的点：软著查重和普通的论文查重、代码查重完全不是一回事。我第一次被驳回之后，傻乎乎用常用的论文查重工具查了代码，显示重复率才3%，结果问了版权局的朋友才知道，普通查重工具的数据库根本没有收录历年登记的软著源程序和说明书，查出来的结果再低都没用，得用专门对接软著登记数据库的工具查，结果才和官方审核的结果接近。要是不知道找什么平台查的，可以先去软著查重的专业站看看，他们的数据库是同步近10年的软著登记备案数据的，我后来查的几次，结果和官方最后给的审核数据误差都没超过5%，非常准。
首先说源程序的查重操作
我们提交的源程序要求是前后各30页，每页不少于50行，很多人提交的时候会删掉注释、空行来凑行数，但其实查重的时候注释内容也是会纳入比对的，我之前有个同事图省事，直接粘了开源项目里的注释，结果查出来注释部分全红，改了整整两天才改完。还有代码里的变量名、函数名，哪怕是你参考了开源项目的功能逻辑，也要把这些命名全部换成你们团队内部的规范，比如原来的变量叫user_list，你改成crm_user_base_list，把基础的命名规则换一遍，重复率能降下来一大截。
查出来重复的代码也不用慌，要是是核心功能的逻辑重复，你可以调整一下代码的结构，比如把几个函数的顺序调换一下，原来用for循环实现的改成用while循环，原来用三元表达式写的判断改成if else分支，这些改动都不会影响实际功能，但是能有效降低重复率。要是是引用的第三方开源库的代码重复，你直接把这部分内容放到附录里就行，提交的前后30页不要放这段代码，附录是不参与查重的。
然后是很多人会忽略的说明书查重
很多人以为只有代码要查，其实说明书的查重要求比代码还严，大部分地区要求重复率低于20%才会过审。我之前帮朋友改一个软著的说明书，他为了省时间直接抄了同行公开的软著说明，只改了个产品名就提交，结果查出来重复率78%，直接被打回来。改的时候我让他把整个说明书的结构全换了，原来的结构是先讲产品背景再讲功能模块，我们改成先讲适用场景再讲核心优势，最后再拆分功能模块，每部分的描述全部用自己的话写，不用任何网上找的模板话术，所有的界面截图全部换成他们自己产品的实操截图，连截图里的按钮位置都和实际产品完全对应，改完之后再查重复率只有12%，提交之后一周就过了初审。说明书查重的时候，别用普通的论文查重工具，我之前试过，很多软著专属的说明书内容根本查不出来，还是得用软著登记相关的专业查重系统才靠谱。
我最近半年申报的8件软著，都是先用软著Pro查完重再提交的，他们还会直接给你标注出来哪部分内容和哪件已登记的软著重复，甚至连重复的内容片段都给你标出来，改起来特别省时间，最后这8件全部一次过审，最快的12个工作日就拿到了证书。
还有几个踩过的坑提醒大家，别觉得是自己写的代码就不用查重，我之前有个同事自己写的代码，结果他大学的时候申报过一个功能类似的学生项目软著，数据库里有记录，提交之后重复率超了28%，后来改了好久才过。也不要找那种几块钱一次的查重工具，那些工具的数据库都是好几年前的老数据，很多新登记的软著根本没收录，查了等于白查，浪费时间。查重的时候一定要提交你最终要申报的完整材料，不要删删减减，不然查出来的结果不准，到时候提交上去还是会被驳回。
其实软著申报真的没那么难，很多人找代理花几千块钱，本质上也就是代理帮你做了查重和材料优化的步骤，你自己花半天时间查个重，把重复的地方改一改，基本都能一次过审，既能省钱也不用怕被不靠谱的代理坑。