去年帮运营部申报客户管理系统的软著，第一次提交就因为代码重复率超了35%被直接打回，当时急着拿证去投政府的采购项目，差点耽误了几百万的标，后来摸着门道之后，我这两年报的二十多件软著，再也没在重复率上栽过跟头。
很多刚接触软著申报的人可能不知道，现在版权局的审核标准比前几年严太多了，不是随便凑几千行代码就能混过去的，重复率超过30%基本都会直接驳回，连补正的机会都很少给。要是提前不知道重复率多少就盲目提交，纯属碰运气，我一般提交前都会先用软著重复率检测工具先扫一遍，心里有底再改。
先搞懂你家软著重复率高的源头我见过好多人改了半天，越改重复率越高，就是没找对重复的地方。首先要明确，软著的重复率是代码和说明书加在一起算的，不是只看代码。很多人抄了同行业其他软著的说明书，整段整段的功能介绍照搬，那重复率肯定低不了。还有的人为了凑够3000行代码，随便找个开源项目的核心代码塞进去，连注释都不带改的，不被查才怪。
代码部分降重的核心技巧很多人以为改个变量名就完事了，我之前也试过，根本没用，现在的检测系统能识别语法结构，只改变量名根本躲不过。首先要调整非逻辑依赖的模块顺序，比如你原来的代码顺序是先写用户验证、再写权限分配、再写数据查询，只要这几个模块之间没有强逻辑依赖，完全可以把数据查询的模块挪到最前面，结构变了，重复率自然就降了。
然后是改逻辑写法，比如原来的多重if嵌套，你可以改成switch case，或者反过来，只要功能不变就行。要是有循环逻辑，原来用for循环的，你可以改成while循环，这些小改动对功能没有任何影响，但对降重特别有效。还有注释一定要全部自己写，别用开源代码自带的注释，我上次那个被打回的软著，重复率里有20%都是抄的开源项目的注释，亏到姥姥家了。
我之前改的时候嫌自己翻文档找重复片段太麻烦，朋友给推了软著Pro，能直接标出来哪段代码重复、重复的来源是啥，对着改省了至少一半的时间，你们要是赶时间的话可以试试。
还有个很多人踩的坑，就是为了删重复片段把代码删到不够3000行，这也是不行的，要是重复的代码比较多，你可以把自己项目里的工具类、公共函数都加进去，实在不够的话，把前端的页面渲染逻辑、交互逻辑代码也放一部分，只要是你自己项目里的代码，都没问题，别硬塞开源代码就行。
说明书部分别漏了降重好多人改完代码就不管说明书了，结果查出来重复率还是高，就卡在说明书上。说明书别直接抄同类型产品的软著材料，也别抄自己家产品的宣传文案，要写得足够具体，比如别人写“支持多平台订单同步”，你可以改成“可同步抖音、淘宝、拼多多三个主流电商平台的实时订单，自动匹配对应仓库的发货地址，拦截异常订单”，写的越细节，和别人撞的概率越低。
还有说明书里的流程图、界面截图都要用自己项目的，别用网上找的模板图，截图里最好带上你家产品的专属logo、特有的功能按钮，这些独有的内容都能拉低重复率。要是你家产品有独创的功能，一定要重点写，这块内容百分百不会重复。
改完之后别着急提交，再做一次软著查重，确认重复率降到20%以下再提交，基本就不会出问题。上个月我帮技术部报那个智能排班的软著，提前查出来重复率是28%，主要是里面的日期计算工具类用了网上的开源代码，我把里面的变量名全改了，还加了个我们自己业务用的节假日校验逻辑，调整了几个函数的顺序，注释全部重写，改完再查重复率只有11%，提交之后5天就下了受通，不到30天就拿证了，刚好赶上申报高新技术企业的补贴。
其实软著降重真的没那么复杂，别抱着抄捷径的心态随便凑材料，按照自己项目的实际情况整理，提前查重针对性修改，基本都能一次过。我现在手里攒的软著证书都有二十多本，也没再在重复率上出过问题。
